Network Working Group Quaizar Vohra Internet Draft Juniper Networks Expiration Date: Dec 2005 Dirk Steinberg Deutsche Telekom AG Andrea De Carolis Telecom Italia BGP-MPLS IP VPN extensions for ISO/CLNS VPN draft-vohra-l3vpn-bgp-clns-00.txt 1. Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 7, 2005. Vohra et al. [Page 1] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 2. Copyright Notice Copyright (C) The Internet Society (2005). 3. Abstract This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its ISO/CLNS customers. These customers may be islands of ISO/CLNS networks which are part of the Service Provider network itself and are interconnected by the Service Provider's IP core. This method reuses the 2547 style BGP-MPLS VPN model. This document defines an ISO/CLNS VPN address family and describes the corresponding ISO/CLNS VPN route distribution mechanism using "Multiprotocol BGP". 4. Introduction This document describes a mechanism by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its ISO/CLNS customers. This mechanism reuses, and extends where necessary, the "BGP/MPLS IP VPN" mechanism [2547bis] in support of ISO/CLNS. In particular, this method uses the same "peer model" as [2547bis], in which the customers' edge routers ("CE routers") send their ISO/CLNS routes to the Service Provider's edge routers ("PE routers"). BGP ("Border Gateway Protocol", [BGP, BGP-MP]) is then used by the Service Provider to exchange the routes of a particular ISO/CLNS VPN among the PE routers that are attached to that ISO/CLNS VPN. Eventually, the PE routers distribute, to the CE routers in a particular VPN, the ISO/CLNS routes from other CE routers in that VPN. This document adopts the definitions, acronyms and mechanisms described in [2547bis]. Unless otherwise stated, the mechanisms of [2547bis] apply and will not be re-described here. A VPN is said to be an ISO/CLNS VPN, when each site of this VPN is ISO/CLNS capable and is natively connected over an ISO/CLNS interface or sub- interface to the SP backbone via a Provider Edge device (PE). In a similar manner to how IPv4 VPN routes are distributed in [2547bis], BGP and its extensions are used to distribute routes from an ISO/CLNS VPN site to all the other PE routers connected to a site of the same ISO/CLNS VPN. PEs use "VPN Routing and Forwarding tables" (VRFs) to separately maintain the reachability information and Vohra et al. [Page 2] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 forwarding information of each ISO/CLNS VPN. Each ISO/CLNS VPN will have its own ISO/CLNS address space, which means that a given address may denote different systems in different VPNs. This is achieved via a new address family, the VPN-ISO Address Family. A VPN-ISO address is constructed by prepending a Route Distinguisher to the ISO/NSAP address. This document allows support of an ISO/CLNS VPN service over MPLS LSPs as well as over other tunneling techniques including GRE tunnels. This document allows support for an ISO/CLNS VPN service over an IPv4 backbone as well as over an IPv6 backbone. The ISO/CLNS VPN service supported is identical in both cases. 5. The VPN-ISO Address Family The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes from multiple "address families". We introduce the notion of the "VPN-ISO address family", that is similar to the VPN-IPv4 address family introduced in [2547bis]. A VPN-ISO address is variable in size, beginning with an 8-byte "Route Distinguisher" (RD) and ending with a 7-bytes to 19-byte ISO NSAP prefix. If two VPNs use the same ISO NSAP prefix (effectively denoting different physical systems), the PEs translate these into unique VPN-ISO address prefixes using different RDs. This ensures that if the same address is used in two different VPNs, it is possible to install two completely different routes to that address, one in each VPN. The purpose of the RD is solely to allow one to create distinct routes to a common ISO NSAP prefix, similarly to the purpose of the RD defined in [2547bis]. As it is possible per [2547bis], the RD can also be used to create multiple different routes to the very same system. This can be achieved by creating two different VPN-ISO routes that have the same ISO NSAP prefix part, but different RDs. This allows BGP to install multiple different routes to the same system, and allows policy to be used to decide which packets use which route. Note that VPN-ISO address prefixes and ISO NSAP prefixes are always considered by BGP to be incomparable. A VRF may have multiple equal-cost VPN-ISO routes for a single ISO NSAP prefix. When a packet's destination address is matched in a VRF Vohra et al. [Page 3] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 against a VPN-ISO route, only the ISO NSAP prefix part is actually matched. The Route Distinguisher format and encoding is as specified in [2547bis]. 6. VPN-ISO route distribution 6.1. Route Distribution Among PEs by BGP As described in [2547bis], if two sites of a VPN attach to PEs which are in the same Autonomous System, the PEs can distribute VPN routes to each other by means of an (IPv4 or IPv6) iBGP connection between them. Alternatively, each PE can have iBGP connections to route reflectors. Similarly, for ISO/CLNS VPN route distribution, PEs can use iBGP connections between them or use iBGP connections to route reflectors. For ISO/CLNS VPN, the iBGP connections MAY be over IPv4 or over IPv6. The PE routers exchange, via MP-BGP [MP-BGP], reachability information for the ISO NSAP prefixes in the ISO/CLNS VPNs and thereby announce themselves as the BGP Next Hop. The rules for encoding the reachability information and the BGP Next Hop address are specified in the following sections. 6.2. VPN ISO/CLNS NLRI encoding When distributing ISO/CLNS VPN routes, the advertising PE router MUST assign and distribute MPLS labels with the ISO/CLNS VPN routes. Essentially, PE routers do not distribute ISO/CLNS VPN routes, but Labeled ISO/CLNS VPN routes [MPLS-BGP]. When the advertising PE then receives a packet that has this particular advertised label, the PE will pop the MPLS stack, and process the packet appropriately (i.e. forward it directly based on the label or perform a lookup in the corresponding ISO/CLNS VPN context). The BGP Multiprotocol Extensions [BGP-MP] are used to advertise the ISO/CLNS VPN routes in the MP_REACH NLRI. The AFI and SAFI fields MUST be set as follows: - AFI: 3; for ISO NSAP - SAFI: 128; for MPLS labeled VPN unicast Vohra et al. [Page 4] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 The NLRI field itself is encoded as specified in [MPLS-BGP]. In the context of this extension, the prefix belongs to the VPN-ISO Address Family and thus consists of an 8-byte Route Distinguisher followed by an ISO NSAP prefix as specified in section 5 above. 6.2.1. BGP Next Hop encoding The encoding of the BGP Next Hop depends on whether the policy of the BGP speaker is to request that ISO/CLNS VPN traffic be transported to that BGP Next Hop using IPv4 signalled MPLS LSPs or GRE over IPv4 tunnels ("BGP speaker requesting IPv4/MPLS transport") or using IPv6 signalled MPLS LSPs or GRE over IPv6 tunnels ("BGP speaker requesting IPv6/MPLS transport"). Definition of this policy is the responsibility of the network operator and is beyond the scope of this document. We note that it is possible for that policy to request IPv4/MPLS (resp. IPv6/MPLS) transport while the BGP speakers exchange ISO/CLNS VPN reachability information over IPv6 (resp. IPv4). However, in that case, a number of operational implications are worth considering. In particular, an undetected fault affecting the IPv4/MPLS (resp. IPv6/MPLS) transport path and not affecting the IPv6 (resp. IPv4) data path, could remain undetected by BGP, which in turn may result in blackholing of traffic. Control of this policy is beyond the scope of this document and may be based on user configuration. 6.2.2. BGP Speaker requesting IPv4/MPLS transport When the ISO/CLNS VPN traffic is to be transported to the BGP speaker using IPv4 signalled MPLS LSPs or GRE over IPv4 tunnels, the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-ISO address: - whose 8-byte RD is set to zero, and - whose ISO NSAP address is encoded as an IPv4-mapped ISO NSAP address as specified in [RFC986] containing the IPv4 address of the advertising BGP speaker. This IPv4 address must be routable by the other BGP Speaker. The value of the Length of the Next Hop Network Address field in the MP_REACH_NLRI attribute shall be set to 17, where the RD accounts for 8 bytes and the IPv4-mapped ISO NSAP accounts for the remaining 9 bytes. Vohra et al. [Page 5] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 6.2.3. BGP speaker requesting IPv6/MPLS tranpsport When the ISO/CLNS VPN traffic is to be transported to the BGP speaker using IPv6 singalled MPLS LSPs or GRE over IPv6 tunnels, the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-ISO address: - whose 8-byte RD is set to zero, and - whose ISO NSAP address is encoded as an IPv6-mapped ISO NSAP address as specified in [RFC1888] containing the IPv6 address of the advertising BGP speaker. This IPv6 address must be routable by the other BGP Speaker. The value of the Length of the Next Hop Network Address field in the MP_REACH_NLRI attribute shall be set to 28, where the RD accounts for 8 bytes and the IPv6-mapped ISO NSAP accounts for the remaining 20 bytes. 6.3. Route Target The use of route target is specified in [2547bis] and applies to ISO/CLNS VPNs. Encoding of the extended community attribute is defined in [BGP-EXTCOM]. 6.4. BGP Capability Negotiation In order for two PEs to exchange labeled ISO/CLNS VPN NLRIs, they MUST use BGP Capabilities Negotiation to ensure that they both are capable of properly processing such NLRIs. This is done as specified in [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol BGP), with AFI and SAFI values as specified above in section 6.2. Vohra et al. [Page 6] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 7. Encapsulation The ingress PE Router MUST transport ISO/CLNS VPN data over the backbone towards the Egress PE router identified as the BGP Next Hop for the corresponding destination ISO/CLNS VPN prefix. When the ISO NSAP contained in the BGP Next Hop field is encoded as an IPv4-mapped ISO/NSAP address (see section 6.2.2), the ingress PE MUST use either IPv4 signalled MPLS LSPs or GRE over IPv4 tunnels . When the ISO NSAP contained in the BGP Next Hop field is encoded as an IPv6-mapped ISO/NSAP address (see section 6.2.3), the ingress PE MUST use either IPv6 signalled MPLS LSPs or GRE over IPv6 tunnels. When a PE receives a packet from an attached CE, it looks up the packet's ISO destination NSAP in the VRF corresponding to that CE. This enables it to find a VPN-ISO route. The VPN-ISO route will have an associated MPLS label and an associated BGP Next Hop. First, this MPLS label is pushed on the packet as the bottom label. Then, this labeled packet is encapsulated into an MPLS LSP or a GRE tunnel for transport to the egress PE identified by the BGP Next Hop. Details of this encapsulation depend on the actual tunneling technique as follows: As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunneling is done using IPv4 GRE tunnels or IPv6 GRE tunnels, encapsulation of the labeled ISO/CLNS VPN packet results in an MPLS-in-GRE encapsulated packet as specified in [MPLS-in-GRE]. The IPsec Transport Mode could be used to secure this GRE tunnel from ingress PE to egress PE. When tunneling is done using IPv4 GRE tunnels (whether IPsec secured or not), the Ingress PE Router MUST use the IPv4 address which is encoded in the IPv4-mapped ISO NSAP field of the BGP next hop field, as the destination address of the prepended IPv4 tunneling header. It uses one of its IPv4 addresses as the source address of the prepended IPv4 tunneling header. When tunneling is done using IPv6 GRE tunnels (whether IPsec secured or not), the Ingress PE Router MUST use the IPv6 address which is encoded in the IPv6-mapped ISO NSAP field of the BGP next hop field, as the destination address of the prepended IPv6 tunneling header. It uses one of its IPv6 addresses as the source address of the prepended IPv6 tunneling header. When tunneling is done using MPLS LSPs, the LSPs can be established using any label distribution technique (LDP [LDP], RSVP-TE [RSVP- TE]). Nevertheless, to ensure interoperability among systems that mplement this VPN architecture using MPLS LSPs as the tunneling technology, all such systems MUST support LDP [LDP]. Vohra et al. [Page 7] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 When tunneling is done using MPLS LSPs, the ingress PE Router MUST directly push the LSP tunnel label on the label stack of the labeled ISO/CLNS VPN packet (i.e. without prepending any IPv4 or IPv6 header). This pushed label corresponds to the LSP starting on the ingress PE Router and ending on the egress PE Router. The BGP Next Hop field is used to identify the egress PE router and in turn the label to be pushed on the stack. In case the ISO NSAP in the BGP Next Hop field is a IPv4-mapped (IPv6-mapped) ISO NSAP, the embedded IPv4 (IPv6) address will determine the tunnel label to push on the label stack. 8. Multi-AS Backbones The same procedures described in section 10 of [2547bis] can be used (and have the same scalability properties) to address the situation where two sites of an ISO/CLNS VPN are connected to different Autonomous Systems. However some additional points should be noted when applying these procedures for ISO/CLNS VPNs; these are further described in the remainder of this section. Approach (a): VRF-to-VRF connections at the AS (Autonomous System) border routers. This approach is the equivalent for ISO/CLNS VPNs to procedure (a) described in section 10 of [2547bis]. In the case of ISO/CLNS VPNs, ISO/CLNS needs to be activated on the inter-ASBR VRF-to-VRF (sub)interfaces. In this approach, the ASBRs exchange ISO/CLNS routes (as opposed to VPN-ISO routes). These routes may be exchanged via BGP by using multiprotocol extensions to BGP. The specification of such a mechanism is outside the scope of this document and may be specified in a separate document in future. This method does not require the use of inter-AS LSPs. Finally note that with this procedure, every AS implements its own intra-AS transport procedure, independent of other ASes, for transporting ISO/CLNS VPN traffic. Approach (b): EBGP redistribution of labeled VPN-ISO routes from AS to neighboring AS This approach is the equivalent for ISO/CLNS VPNs to procedure (b) described in section 10 of [2547bis]. With this approach, the ASBRs use EBGP to redistribute labeled VPN-ISO routes to ASBRs in other ASes. With this approach, the ASBR routers exchanging VPN-ISO routes need not be ISO/CLNS capable if they peer over IPv4 or IPv6. In that case Vohra et al. [Page 8] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 ASBRs need only understand the ISO/CLNS VPN NLRI. The exchange of labeled VPN-ISO routes MUST be carried out as described in this document. If the ASBR routers peer over IPv4 (IPV6), the BGP Next Hop Field SHALL contain an IPv4-mapped ISO NSAP (IPv6-mapped ISO NSAP). ISO/CLNS traffic corresponding to a labeled VPN-ISO route is transported from one ASBR to another directly over the MPLS label associated with that route. No further tunnelling is required if the peering ASBR routers are directly connected. As such the corresponding (security) considerations described for procedure (b) in section 10 of [2547bis] apply equally to this approach for CLNS. Finally note that with this procedure, every AS implements its own intra-AS transport procedure (IPv4/IPv6 signalled MPLS LSPs or GRE over IPv4/IPv6 tunnelling), independent of other ASes, for transporting ISO/CLNS VPN traffic. approach (c) : Multihop EBGP redistribution of labeled VPN-ISO routes between source and destination ASes, with EBGP redistribution of labeled IPv4 or IPv6 routes from AS to neighboring AS. This approach is the equivalent for exchange of VPN-ISO routes to procedure (c) described in section 10 of [2547bis] for exchange of VPN-IPv4 routes. This approach requires that the participating ASes either all use IPv4-mapped ISO address in the BGP Next Hop Field or alternatively all use IPv6-mapped ISO address in the BGP Next Hop Field. In this approach, VPN-ISO routes are neither maintained nor distributed by the ASBR routers. The ASBR routers need not be ISO/CLNS capable. An ASBR needs to maintain labeled IPv4 (or IPv6) routes to the PE routers within its AS. It uses EBGP to distribute these routes to other ASes. ASBRs in any transit ASes will also have to use EBGP to pass along the labeled IPv4 (or IPv6) routes. This results in the creation of a label switched path from ingress PE router to egress PE router whose destination is indentified by the IPv4 (IPv6) address of the nexthop PE. Now PE routers in different ASes can establish multi-hop EBGP connections to each other over IPv4 or IPv6, and can exchange labeled VPN-ISO routes over those EBGP connections. Note that the BGP Next Hop field of these distributed VPN-ISO routes will contain an IPv4-mapped ISO NSAP (IPv6-mapped ISO NSAP). The considerations described for procedure (c) in section 10 of [2547bis] with respect to possible use of route-reflectors, with respect to possible use of a third label, and with respect to LSPs Vohra et al. [Page 9] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 spanning multiple ASes apply equally to this ISO/CLNS VPN approach. 9. Security Considerations The security considerations discussed for IPv4 VPNs in section 13 of [2547bis] are equally applicable to ISO/CLNS VPNs. 10. Scalability The scalability considerations summarized for IPv4 VPNs in section 15 of [2547bis] are equally applicable to ISO/CLNS VPNs. 11. IANA Considerations This document specifies (see section 6.2) the use of the BGP AFI (Address Family Identifier) value 3, along with the BGP SAFI (Subsequent Address Family Identifier) value 128, to represent the address family "VPN-ISO Labeled Addresses", which is defined in this document. The use of AFI value 3 for ISO/CLNS is as currently specified in the IANA registry "Address Family Identifier", so IANA need take no action with respect to it. The use of SAFI value 128 is specified as "MPLS labeled VPN address" in the IANA "Subsequent Address Family Identifier" registry. This document is in line with this and no additional IANA action is needed. 12. Acknowledgements We would like to thank Pedro Marques and Yakov Rekhter who contributed to this document, and Hannes Gredler for carefully reviewing the document. Vohra et al. [Page 10] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 13. Normative References [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis, work in progress [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities Attribute", work in progress [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", June 2000, RFC2858 [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460. [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", RFC3031 [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", RFC3107 [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", RFC3032 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-4", November 2002, RFC3392 [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP Specification", RFC3036 [RFC986] Callon R., Braun H., "Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol", June 1986, RFC986 [RFC1888] Bound, J., et al., "OSI NSAPs and IPv6", June 1996, RFC1888 14. Informative References [2547-GRE] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 VPNs", draft-ietf-l3vpn-gre-ip-2547, work in progress [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", December 2001, RFC3209 [MPLS-in-GRE] Worster, T., et al., "Encapsulating MPLS in IP or GRE", draft-ietf-mpls-in-ip-or-gre, work in progress Vohra et al. [Page 11] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 15. Author Information Quaizar Vohra Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 qv@juniper.net Dirk Steinberg Deutsche Telekom AG T-Com Headquarters TE122 Am Kavalleriesand 3 D-64295 Darmstadt Germany dws@steinbergnet.net Andrea De Carolis Telecom Italia Tel: +39 0636887162 andrea.decarolis@telecomitalia.it 16. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Vohra et al. [Page 12] Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001 17. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 18. Copyright (C) The Internet Society (YYYY). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 19. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vohra et al. [Page 13]