Network Working Group Marko Kulmala Internet Draft Ville Hallivuori Tellabs Jyrki Soini TeliaSonera Expiration Date: August 2005 February 2005 Aggregation PE draft-kulmala-l3vpn-aggregation-pe-00.txt Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 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 operation of aggregation PE and applications for it. Aggregation PE installs VPN-IPv4 routes into VRFs and acts as BGP next hop when it readvertises VPN-IPv4 routes with MP-BGP to other PE routers. This eliminates the need to LSP connectivity (or some other type of tunnels) between packet's ingress and egress PE. Aggregation PE function can be used in multi AS backbones. If routing peering between the ASes is done between aggregation PE routers then ingress PE in one AS does not need to know reachability information to egress PE in other AS. Security is enhanced because no LSP is needed between packet's ingress and egress PEs. Another application for aggregation PE is the support of distinct IP/MPLS regional networks. It enables access network to be separate area or domain which makes the network more scalable. Kulmala, et al. [Page 1] Internet Draft draft-kulmala-l3vpn-aggregation-pe-00.txt February 2005 Table of Contents 1 Specification of Requirements ......................... 2 2 Intellectual Property Statement ....................... 2 3 Aggregation PE function ............................... 3 4 Aggregation PE function in Multi-AS Backbones .......... 4 5 Aggregation PE function in access network ............. 5 6 Security .............................................. 6 7 Quality of Service .................................... 6 8 Acknowledgments ....................................... 7 9 Intellectual Property Statement......................... 7 9 Full Copyright Statement .............................. 7 10 Normative References .................................. 7 11 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 2. 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. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Kulmala, et al. [Page 2] Internet Draft draft-kulmala-l3vpn-aggregation-pe-00.txt February 2005 3. Aggregation PE function Aggregation PE router distributes VPN-IPv4 routes to other AS by means of MP-eBGP connection. MP-iBGP is used within the AS as normal. Aggregation PE router will re-advertise the VPN-IPv4 routes that are learned from MP-BGP and imported into VRFs to other PE routers by re-exporting them from VRF RIBs. The advertising aggregation PE MUST set mp_nexthop to itself and MUST provide MPLS label that can be used to reach advertised destination. The label allocation for VPN routes is the local implementation matter in aggregation PE router. One straightforward way is to allocate distinct label for each route. Or to give same label for every route in the VRF. When VPN-IPv4 route is re-advertised, the associated route-targets MUST be replaced with export route-targets of the VRF the route is currently associated in aggregation PE router. When VPN-IPv4 route is re-advertised, the associated route distinguisher MUST be replaced with the RD of the VRF the route is currently associated in aggregation PE router. The reasons for this are: - When the same route is imported in re-advertising aggregation PE into multiple VRFs, it can be exported to MP-BGP neighbors from those VRFs with different sets of the export route targets. If the route advertised to MP-BGP neighbors had the same RD then only those RTs that were along with the best route would take effect in the receiving MP-BGP neighbour. - If multiple aggregation PEs use different route distinguishers, other PEs can use load balancing if packet's egress PE is connected to multiple aggregation PEs (multi-homing of PE router). Aggregation PE function is always useful when it is not desirable or feasible to require that all PEs have MPLS labels for LSP connectivity (or some other type of tunnels) to all remote PEs. Aggregation PE needs to keep VPN routes that it receives from PEs which is limiting scalability factor for this arrangement. There can be multiple aggregation routers that handle specific set of VPNs. Kulmala, et al. [Page 3] Internet Draft draft-kulmala-l3vpn-aggregation-pe-00.txt February 2005 4. Aggregation PE function in Multi-AS Backbones When using aggregation PE functionality at Autonomous System Border Router (ASBR) the PE routers in same AS use MP-iBGP to redistribute labelled VPN-IPv4 routes to ASBR, via Route Reflector or directly. ASBR imports the routes into appropriate VRF(s). The RD and RTs are replaced by those configured for VRF(s) in ASBR and the next hop is set to self before the routes are redistributed by MP-eBGP connection to an ASBR in other AS. When route is received from ASBR in other AS by MP-eBGP connection the similar function occurs: RD and RTs are replaced and next hop is set to self before the routes are redistributed by MP-iBGP to PEs in the AS. If there are lot of such VPNs that have sites attached to different ASes, then there can be multiple ASBR each of which holds only the routes for a subset of the VPNs. This procedure does not require label switched path between packet's ingress and egress PE. Neither does it require BGP session between ingress and egress PE; not even via Route Reflector. SPs must agree which RTs to use between the ASBRs. These RTs have meaning only for ASBR acting as aggregation PE, not for other PEs in the AS. Packet Switched Network (PSN) tunnels can be LSPs, GRE, IPinIP or any other type of tunnel. What type of PSN tunnel is used is out the scope of this document |<--MP-iBGP-->| |<--MP-eBGP->| |<--MP-iBGP-->| Attachment |<----PSN1--->| |<---PSN2--->| |<----PSN3--->| Attachment (AC) V V V V V V (AC) | +----+ +----+ +----+ +----+ | +--+ | | PE | | PE | | PE | | PE | | +--+ | | | | | | | | | | | | | | |CE|-----|VRFs|=========|VRFs|=========|VRFs|=========|VRFs|-----|CE| | | | | | | | | | | | | | | +--+ | | | |ASBR| |ASBR| | | | +--+ | +----+ +----+ +----+ +----+ | PE in Aggregation Aggregation PE in Service PE in Service PE in Service Service Provider1 Provider1 Provider2 Provider2 network network network network Figure 1: Multi-AS Backbone application for aggregation PE Kulmala, et al. [Page 4] Internet Draft draft-kulmala-l3vpn-aggregation-pe-00.txt February 2005 5. Aggregation PE function in access networks Today the network that provides RFC2547bis VPNs[2547BIS] uses IP/MPLS technology typically only in the core network. TDM, ATM, FR or Ethernet technologies provide the attachment circuits to the core edge. When IP/MPLS is deployed beyond the core then it may be beneficial to split the network into multiple domains. Today there are specifications that support that for VPLS (H-VPLS) and for VPWS (PW switching). Aggregation PE function provides support for multiple domains for RFC2547bis VPNs. When using aggregation PE router the traditional access networks and IP/MPLS access networks can interoperate seamlessly around the same core network. PE routers serving traditional access networks at core edge do not need to know anything about PE or P routers that reside in IP/MPLS access network and vice versa. In addition PEs in different IP/MPLS access networks need not be aware of PEs in other access networks. This allows clear separation of the network into the multiple domains. The basic setup is such that aggregation PE router sits at the core edge and PE resides closer to customer, perhaps in the basement of the building where customer site is located. There may be an MPLS network between aggregation PE and the PE closer to customer. Note that one physical router can act simultaneously in multiple roles (aggregation PE, ordinary PE or P). |<--MP-eBGP-->| |<--MP-iBGP->| |<--MP-eBGP-->| Attachment |<----PSN1--->| |<---PSN2--->| |<----PSN3--->| Attachment (AC) V V V V V V (AC) | +----+ +----+ +----+ +----+ | +--+ | | PE | | PE | | PE | | PE | | +--+ | | | | | | | | | | | | | | |CE|-----|VRFs|=========|VRFs|=========|VRFs|=========|VRFs|-----|CE| | | | | | | | | | | | | | | +--+ | | | | | | | | | | +--+ | +----+ +----+ +----+ +----+ | PE close Aggregation Aggregation PE close to customer PE PE to customer site site Figure 2: Access network application for aggregation PE Kulmala, et al. [Page 5] Internet Draft draft-kulmala-l3vpn-aggregation-pe-00.txt February 2005 The routes between CE router and PE router in access network can be static or can be distributed by customer IGP or by eBGP in the similar way as it occurs at PE in ordinary RFC2547bis. VPN-IPv4 routes between PE in access and aggregation PE router are distributed by means of MP-eBGP connection between them. This means that typically PEs use private AS number. PE routers within the access network can have MP-iBGP connections between each other in order to avoid unnecessary traffic through aggregation PE routers at core edge. Aggregation PE uses MP-iBGP connections(s) to readvertise VPN-IPv4 routes to the core PE routers. In this model aggregation PE router does not need to run customer specific IGP instances or eBGP sessions, instead that is done by PE closer to customer. This decreases the scalability requirements for the PE router at core edge. In this model there is no need to have LSPs between PEs in different access networks, which improves network scalability. The VPN traffic from customer sites can turn back without loading PE routers at the core edge. This is benefit compared to traditional L2 access where VPN service instances are only at core PE routers. The number of VPN routes that can be supported is unchanged compared to L2 regional/access network. If PE in access aggregates VPN routes then that aspect would be improved as well. 6. Security In the Multi-AS application the security is at similar level than in option a) in [2547BIS]. In access network application the security is at similar level than with ordinary RFC2547bis. If PE is deployed at customer premises then more careful security considerations are needed. 7. Quality of Service IETF defined DS and DS-TE can be used. In access network application DS-TE usage is easy since TE tunnels can stay within the given access/regional network. It is possible to split operator's IGP into areas and still do straightforward traffic engineering within single area.This is because aggregation PE is the next hop for RFC2547bis traffic that is destined to outside from that access network. Kulmala, et al. [Page 6] Internet Draft draft-kulmala-l3vpn-aggregation-pe-00.txt February 2005 8. Acknowledgments The authors wish to acknowledge the contributions of Paul Hallanoro, Heikki Heikkila and Jouni Tiainen. 9. 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. 10. 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. 11. 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-aggregation-pe-00.txt February 2005 12. Author Information Ville Hallivuori Tellabs Sinimaentie 6 FI-02630 Espoo, Finland e-mail: ville.hallivuori@tellabs.com Marko Kulmala Tellabs Sinimaentie 6 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]