Network Working Group Marko Kulmala Internet Draft Ville Hallivuori Tellabs Martin Halstead Nexagent Jyrki Soini TeliaSonera Expiration Date: April 2006 October 2005 Inter AS option for BGP/MPLS IP VPN draft-kulmala-l3vpn-interas-option-d-01.txt Status of this Memo 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. Abstract This document describes an additional option to the 'Multi-AS Backbones' section of [RFC2547]. This option combines per VPN VRFs at the Autonomous System Border Router (ASBR) as described in 'Option a' with EBGP redistribution of labeled VPN-IPv4 routes as described in 'Option b'. Kulmala, et al. [Page 1] Internet Draft draft-kulmala-l3vpn-interAS-option-d-01.txt October 2005 In contrast to 'Option a' however, per VPN VRFs at the ASBR are not associated to interfaces. Interfaces between ASBR pairs in separate ASes use MPLS-labeled packets to forward traffic. In this Multi-AS option, the ASBR installs VPN-IPv4 routes into VRFs. Once installed in a VRF at the ASBR, best path selection is performed, and selected routes are converted to VPN-IPv4 routes by the addition of Route Target (RT) and Route Distinguisher (RD) values as configured per VRF at the ASBR. If attached ASBR pairs belonging to separate ASes make use of this Multi-AS option, then VRF based route filtering policies via RTs is achieved directly between ASBR pairs, independent of PE based RT filtering within an AS. Table of Contents 1 Specification of Requirements ......................... 1 2 Introduction .......................................... 2 3 New Inter-AS option for BGP/MPLS IP VPNs ............... 2 4 Scope ................................................. 2 5 Option 'd' Example Route Distribution ................. 3 6 Inter-AS VPN Operation ................................ 4 6.1 Inter-AS VPN Route Distribution ....................... 4 6.2 Inter-AS Route Restriction ........................... 4 6.3 Inter-AS Address Aggregation .......................... 4 6.4 Inter-AS per VRF Access Lists ........................ 4 7 Inter-AS Quality of Service ......................... 4 8 Comparison of the Inter-AS options ..................... 5 9 Deployment Considerations ............................. 6 10 Security Considerations ............................... 6 11 Acknowledgments ....................................... 7 12 Intellectual Property Statement......................... 7 13 Full Copyright Statement .............................. 7 14 Normative References .................................. 7 15 Informative Reference ................................ 8 16 Author Information .................................... 8 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 Kulmala, et al. [Page 1] Internet Draft draft-kulmala-l3vpn-interAS-option-d-01.txt October 2005 2. Introduction Inter-AS VPN route distribution described in the Multi-AS section of [RFC2547] is currently based on three options ('a' to 'c'). Each option, when deployed in isolation potentially exhibits drawbacks that could be addressed by combining the beneficial attributes of more than a single option. Option 'a' inherently allows per VRF route readvertisement import/export policy at the AS border. Option 'b' removes the requirement for per VRF sub-interfaces with associated EBGP sessions. This additional option, called option 'd' incorporates these beneficial attributes. 3. New Inter-AS option for BGP/MPLS IP VPNs The Multi-AS section of draft-ietf-l3vpn-rfc2547bis-03.txt is amended with option 'd': d) EBGP redistribution of VRF routes as labeled VPN-IPv4 routes from AS to neighboring AS. In this procedure, PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR installs received routes to local VRFs using normal route-target based route selection. The ASBR then uses MP-EBGP to advertise labeled VPN-IPv4 routes with RT and RD values exported per ASBR VRF to its neigbouring ASBR. The nexthop of the readvertised routes is set to the advertising ASBR. The neigbouring ASBR installs VPN-IPv4 routes to local VRFs, and performs the same export readvertisement procedure towards its IBGP neighbors. 4. Scope This Inter-AS VPN option is based on IPv4 VPN services as described in [RFC2547], therefore references in this document are based on IPv4 only. This option should however not preclude its use in VPN environments based on IPv6 as described in [VPN-IPv6]. Kulmala, et al. [Page 2] Internet Draft draft-kulmala-l3vpn-interAS-option-d-01.txt October 2005 5. Option 'd' Example Route Distribution Figure 1 shows an arbitary Multi-AS VPN interconnectivity scenario between two CEs, CE1 and CE2, interconnected by Service Provider (SP) SP1 and SP2. +-----+ +-----+ ...| RR1 |... ...| RR2 |... . +-----+ . . +-----+ . . . . . . . . . +---+ +----+ +-----+ +-----+ +----+ +---+ |CE1|--|PE1 |-SP1-|ASBR1|--|ASBR2|-SP2-|PE2 |--|CE2| +---+ |VRF1| |VRF2 | |VRF3 | |VRF4| +---+ +----+ +-----+ +-----+ +----+ Routers CE1 and CE2 are members of the same VPN and require IP interconnectivity. Router CE1 is associated to VRF1 on PE1 via a VRF attachment circuit. Route R learned at VRF1 is converted by PE1 to a VPN-IPv4 route via attaching RD and RD extended community attributes as configured on VRF1. PE1 associates label L to route R and advertises this label mapping to Route Reflector RR1 which in turn advertises the VPN-IPv4 route incorporating route R to ASBR1. ASBR1 has a VRF (VRF2) assigned, applicable to a VPN to which CE1 is a member, but not associated to any attachment circuits. ASBR1 receives the VRF1 exported RT attributes from BGP and learns the label binding L associated with route R. Route R is imported from BGP into VRF2s RIB (Routing Information Base) where its RT and RD attributes assigned by PE1 are removed. ASBR1 exports route R from VRF2s RIB to BGP where RD and RT attributes, plus label binding M associated to VRF2 are attached to route R. The labeled VPN-IPv4 route incorporating route R is advertised to ASBR2 via EBGP, with a nexthop set to ASBR1. ASBR2 imports the RT values exported from VRF2 into VRF3's RIB where route Rs RT and RD attributes are removed. ASBR2 exports route R from VRF3s RIB to BGP and attaches RT and RD attributes plus label binding N associated to VRF3. Labeled VPN-IPv4 route R is now advertised to PE2 via RR2 and so on. Packets from CE2, destined for CE1 are label switched from PE2 to ASBR2. ASBR2 looks up label N (pushed on the packet by PE2) in its LIB (Label Information Base), pops label N and performs an IP lookup via VRF3's RIB whose longest match is route R. Route Rs next hop router is ASBR1. ASBR2 performs a lookup in its LIB and attaches label M to the packet and forwards the packet to ASBR1. ASBR1 looks up label M in its LIB, pops label M, looks up the destination in VRF2's RIB where a match is made on route R. Route R's next hop is PE1. ASBR1 pushes label L onto the packet and forwards the packet to PE1. Kulmala, et al. [Page 3] Internet Draft draft-kulmala-l3vpn-interAS-option-d-01.txt October 2005 6. Inter-AS VPN Operation 6.1. Inter-AS VPN Route Distribution ASBRs using option 'd' MUST NOT readvertise received VPN-IPv4 routes. Received VPN-IPv4 routes are imported into VRFs using normal RT based filtering. All labeled VPN-IPv4 routes readvertised from the ASBR MUST consist of per VRF IPv4 routes, converted to VPN-IPv4 routes by being associated to a minimum of per VRF configured RT and RD values. Labeled VPN-IPv4 routes advertised from the ASBR MUST have a nexthop set to an IP address reachable on the ASBR. VRFs configured on ASBRs in this option could be described as being 'un-attached'as they are not associated to VRF attachment circuits. ASBR created label assignments for aggregate or non-aggregate VPN-IPv4 routes associated to 'un-attached' VRFs MUST result in the ASBR, when receiving packets with these label values looking up the packet's destination address via an egress 'un-attached' VRF. These ASBR created VPN-IPV4 routes MUST NOT be readvertised to the source peer (or a Route Reflector whose clients are PE neighbours), rather route readvertisement MUST follow normal BGP route readvertisement policy specified in [BGP-4]. It SHOULD be possible to remove individual RT values in BGP update messages on a per neighbour basis. This is useful where the SP wants to separate RT values advertised to EBGP peers from RT values advertised to IBGP peers. 6.2. Per VRF route limiting The ASBR SHOULD be able to restrict the number of VPN-IPv4 routes installed per VRF. The ability to restrict numbers of routes learned on a per VRF basis SHOULD apply to routes received from EBGP neighbors. This allows existing operational processes for per customer restriction of numbers of routes to apply at the AS border. 6.3. Inter-AS Address Aggregation The ASBR SHOULD have the capability to aggregate VPN-IPv4 routes advertised per VRF. This allows existing operational processes for per customer summarization of routes to apply at the AS border. 6.4. Inter-AS per VRF Access Lists The ASBR SHOULD have the capability to apply IPv4 based ACLs to received packets on a per VRF basis. 7. Inter-AS Quality of Service It SHOULD be possible for the ASBR as a DS boundary node [DS-ARCH] operating traffic classification and conditioning functions to match on ingress and egress an application (TCP, UDP port, RTP session, data pattern etc), IP Source Address, IP Destination Address or DS field per packet, per VRF or combinations of the above. Kulmala, et al. [Page 4] Internet Draft draft-kulmala-l3vpn-interAS-option-d-01.txt October 2005 Once matched, the packets Layer 2 header (if applicable), IP DSCP and MPLS EXP bits or combinations of the above should be re-marked, and optionally shaped per traffic stream, dependant on the DS domain's TCA (Traffic Conditioning Agreement). This will assist where different DS domains have different TCA rules. Packet Switched Network (PSN) Traffic Engineering (TE) tunnels and TE PSN tunnel attributes MAY be selectable per VRF at each ASBR. In this option, Inter-AS TE tunnels can be be built AS-by-AS. ASBRs and PEs within the same AS calculate routes and create TE tunnels from VRFs to tail-end routers (ASBR VRF to PE and PE VRF to ASBR). Additional TE tunnels are then built from ASBR VRFs to attached ASBRs. This method does not require end-to-end TE LSPs with associated Inter-AS extensions as per-AS TE tunnels are linked via VRFs at the AS border. 8. Comparisons of Inter-AS options This section describes some of the attributes of the three Multi-AS options avaliable in [RFC2547bis]. Option 'a' allows for routes learned from external ASes to be redistributed into an AS via VRF based export policies at the AS border. This allows for RT and RD values to be applied per AS, rather than end-to-end across AS borders. In addition, these VRFs are able to restrict and summarize numbers of routes learned per VRF from other ASes. In contrast, options 'b' and 'c' require RT and RD values to be readvertised end-to-end from PE to PE across ASes. It could be possible to translate RT values at the AS border or Route Reflector, but this is achieved per peer, rather than via VRF based export policies. Options 'b' and 'c' therefore do not offer an equivalent level of per VRF route redistribution and VPN membership (RT and RD assignment) separation as avaliable in option 'a'. Options 'b' and 'c' require an LSP to exist from a packets ingress PE to its egress PE. The interface attaching ASBR pairs in separate ASes must therefore be MPLS enabled. In contrast to option 'a', this removes the requirement for the interface media to support multiple sub-interfaces, at least one per VRF whose traffic must pass from AS to neighbouring AS. In addition, it removes option 'a's requirement for per VPN configuration and coordination of sub-interfaces to VRF associations across AS borders. Option 'b' uses labeled VPN-IPv4 routes for route redistribution directly between attached ASBRs in separate ASes. These single ASBR to ASBR EBGP peers support routes associated to multiples of VPNs. In contrast, Option 'a' requires each sub-interface associated to a VRF to independantly distribute unlabled IPv4 addresses from PE to PE in neigbouring ASes. This requirement creates a depandancy on the PE to support a minimum of a single EBGP peer per VRF associated sub-interface whose routes need to be passed from AS to AS. Kulmala, et al. [Page 5] Internet Draft draft-kulmala-l3vpn-interAS-option-d-01.txt October 2005 Option 'a' allows RSVP signalled TE tunnels to be independantly built per VPN within each AS, without the need to expose IP addresses of tailend routers in other ASes. This is due to per VPN VRFs at the AS border PE selectivly associating traffic to TE tunnels within each AS. TE tunnel LSPs in option 'a' however do not exist from PE to PE as interfaces between PE ASBRs are not MPLS enabled. In contrast, ASBRs operating Option 'b' do not recieve PSN TE tunnel labels from PEs in other ASes, thereby making Inter-AS TE difficult to implement. Option 'c' requires Inter-AS TE extensions that in all cases expose IP addresses of tailend PEs located in other ASes. Option 'd', builds on the beneficial attributes of the various options described above by preserving per VRF route readvertisement import/export policy at the AS border as described in option 'a', while removing the requirement for per VRF sub-interfaces and associated IPv4 peers. Instead, EBGP is used to readvertise labeled VPN-IPv4 routes via single MPLS enabled interfaces as described in option 'b'. In addition, per VPN VRFs at the ASBR allow Inter-AS TE to be configured per VPN, per AS and between ASes using existing intra-AS TE techniques. 9. Deployment Considerations As EBGP is used in option 'd' to readvertise labeled VPN-IPv4 routes to neigbouring ASBRs, it is possible to seamlessly interwork with ASBRs operating interconnects based on Multi-AS option 'b' of [RFC2547]. Where attached ASBR pairs belonging to separate ASes make use of this Multi-AS option then a hierarchical approach to the allocation of RT values could be deployed. SPs should make use of existing RT allocation schemas and numbering as applicable to their intra-domain VPN service, while RTs advertised in BGP updates that transit connected ASBR pairs could be allocated from a separate pool owned by one of the connected SPs, or a third party operator. RT values assigned to VRFs at the AS border SHOULD, as per section 4.3.1 of [RFC2547] be provisioned with unique values across all ASBRs. This policy will prevent incorrect cross-connection of VPN routes into VRFs at the AS border. RD values assigned to VRFs at the AS border SHOULD, as per section 4.2 of [RFC2547] be configured with unique values across all ASBRs. If attached ASBR pairs operate this option, then RDs advertised in BGP updates will never transit from one AS to a PE in another AS. This policy will enable traffic load balancing across multi-homed ASes, while preventing the possibility of routes being lost due to incorrect best path decisions being made by Route Reflectors. 10. Security Considerations This document does not alter the security properties of BGP based VPNs as the distribution of routes and traffic forwarding methodology is unaltered from the implementation described in Option 'b' of [RFC2547]. A trust relationship between SP pairs is required as labeled VPN-IPv4 routes are forwarded between attached ASBR pairs. This option does however hide the SP's VPN topology construct (PE related RT and RD numbering). Kulmala, et al. [Page 6] Internet Draft draft-kulmala-l3vpn-interAS-option-d-01.txt October 2005 11. Acknowledgments The authors wish to acknowledge the contributions of Paul Hallanoro, Heikki Heikkila and Jouni Tiainen. 12. 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. 13. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. 14. Normative References [2547BIS] "BGP/MPLS IP VPNs", Rosen, E, Rekhter, Y. draft-ietf-l3vpn-rfc2547bis-03.txt, October 2004. Kulmala, et al. [Page 7] Internet Draft draft-kulmala-l3vpn-interAS-option-d-01.txt October 2005 15. Informative Reference [BGP-4] Rekhter, Y. and T. Li,"A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [DS-ARCH] Blake, S et al, "An Architecture for Differentiated Services", RFC 2475, December 1998 [VPN-IPv6] De Clercq et al, "BGP-MPLS IP VPN extension for IPv6 VPN", draft-ietf-l3vpn-bgp-ipv6-07.txt, July 2005. 16. Author Information Ville Hallivuori Tellabs Sinimaentie 6 FI-02630 Espoo, Finland e-mail: ville.hallivuori@tellabs.com Martin Halstead Nexagent Thames Tower Reading Berkshire RG1 1LX United Kingdom e-mail: mhalstead@nexagent.com Marko Kulmala Tellabs Sinikalliontie 7 FI-02630 Espoo, Finland e-mail: marko.kulmala@tellabs.com Jyrki Soini TeliaSonera P.O.Box 935 FI-00051 Sonera, Finland e-mail: jyrki.soini@teliasonera.com Kulmala, et al. [Page 8]