Network working group X. Xu Internet Draft Z. Li Category: Informational Huawei Expires: April 2014 October 17, 2013 Multi-domain MPLS Deployment Enhancement draft-xu-mpls-multi-domain-deployment-enhancement-00 Abstract MPLS as a mature technology is increasingly deployed in large-scale networks which consists of multiple domains (e.g., IGP areas/levels and even Autonomous Systems). To scale such multi-domain MPLS deployment, the concept of hierarchical LSPs is usually resorted. This document describes an enhancement to such hierarchical multi- domain MPLS deployment architecture that could further improve the scalability of multi-domain MPLS deployment. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 17, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Xu, et al. Expires April 17, 2014 [Page 1] Internet-Draft Multi-domain MPLS Deployment Enhancement October 2013 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Conventions used in this document 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 [RFC2119]. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 3 3. Deployment Enhancement ...................................... 3 4. Conclusions ................................................. 5 5. Security Considerations...................................... 5 6. IANA Considerations ......................................... 5 7. Acknowledgements ............................................ 5 8. References .................................................. 5 8.1. Normative References ................................... 5 8.2. Informative References ................................. 5 Authors' Addresses ............................................. 6 Xu, et al. Expires April 17, 2014 [Page 2] Internet-Draft Multi-domain MPLS Deployment Enhancement October 2013 1. Introduction MPLS as a mature technology is increasingly deployed in large-scale networks which consists of multiple IGP areas/levels and even multiple Autonomous Systems (AS's) (e.g., Inter-AS L3VPN option C described in [RFC4364]). For simplicity, in the rest of this document the term "domain" would be used to refer area/level/AS. To scale such multi-domain MPLS deployment, the concept of hierarchical LSPs is usually resorted. The basic idea behind this concept is the innermost transport LSP which is across domain boundaries is actually transported over multiple outer transport LSPs which are confined within each domain (a.k.a., originated and terminated within the same domain). Such a hierarchical routing and forwarding concept allows exchange of loopback addresses and MPLS label bindings for innermost transport LSPs across these domains while preventing the above information from being flooded into domains or parts of the network that do not need them. In most cases, the innermost transport LSPs are established primarily using labeled BGP [RFC3107]. In some special cases (e.g., seamless MPLS [Seamless-MPLS]), the innermost transport LSP could also be a stitched LSP of BGP-signaled LSPs and LDP-signaled LSPs. Such a hierarchical routing and forwarding concept has greatly improved the scalability of the multi-domain MPLS deployment. However, in the case where the number of PE routers is enormous, a large amount of non-aggregatable labeled BGP routes for those PE routers would have to be advertised across domain boundaries. As stated in the seamless MPLS draft [Seamless-MPLS], "...this architecture results in carrying all loopbacks of all nodes except pure P nodes (AN, AGN, ABR and core PE) in labeled BGP, e.g., there will be in the order of 100,000 routes in labeled BGP when approaching the stated scalability goal..." Without special implementation and configuration, it would result in tremendous and unnecessary consumption of the BGP RIB and even MPLS forwarding table resources on domain boundary nodes (e.g., ABRs). Therefore, there is still room for improvement in scalability. 2. Terminology This memo makes use of the terms defined in [RFC3031] and [RFC3107]. 3. Deployment Enhancement In the hierarchical LSP case as mentioned in Section 1, the innermost transport LSP only represents a logical connectivity to the final tunnel endpoint (e.g., egress PE routers). As such, it's no problem to replace such innermost transport LSP with an IP tunnel while Xu, et al. Expires April 17, 2014 [Page 3] Internet-Draft Multi-domain MPLS Deployment Enhancement October 2013 keeping the remaining outer MPLS LSPs unchanged. In this way, there is no need for advertising no-aggregatable labeled BGP host routes across domain boundaries anymore. Instead, it only requires advertising aggregated non-labeled BGP routes across domain boundaries. To clearly understand the concept of the multi-domain MPLS deployment enhancement as suggested above, a multi-area MPLS deployment example with enhancement is illustrated as follows: /----\ /-------\ /----\ /// \\\\ /// \\\ //// \\\\ +----+ +-----+ +-----+ +----+ |PE-1| OSPF Area 1 |ABR-1| OSPF Area 0 |ABR-2| OSPF Area 2 |PE-2| +----+ +-----+ +-----+ +----+ \\\\ //// \\\ /// \\\\ //// \----/ \-------/ \----/ |<--------------------------IP Tunnel------------------------>| |<------LSP-------->|<--------LSP-------->|<--------LSP------>| In the above example, iBGP sessions are established between PEs (i.e., PE-1 and PE-2) and ABRs (e.g., ABR-1 and ABR-2). Assume loopback addresses of all PEs within area 1 are within 10.1.0.0/16 while loopback addresses of all PEs within area 2 are within 10.2.0.0/16. ABR1 would advertise a route for 10.1.0.0/16 to ABR-2 which in turn advertises that route upon receiving to PE-2. Similarly, ABR-2 would advertise a route for 10.2.0.0/16 to ABR-1 which in turn advertises that route upon receiving to PE-1. In addition, intra-domain LSPs have been established between PEs and ABRs. Assume PE-1 needs to send a packet P1 to PE-2, PE-1 would encapsulate such packet into an IP tunnel with tunnel source of PE-1's loopback address and tunnel destination of PE-2's loopback address. For example, if the packet is a MPLS IP VPN packet, the packet would be encapsulated using any IP-based encapsulation method for MPLS (e.g., MPLS-in-IP). PE-1 then performs IP forwarding lookup for the encapsulated packet P2. Since the BGP next-hop of the best route (i.e., 10.2.0.0/16) for the packet P2's destination (i.e., PE-2's loopback address) is ABR-1 and PE-1 has a LSP towards ABR-1, PE-1 therefore would transport that encapsulated packet P2 over that LSP. Upon receipt of that encapsulated packet P2 via that LSP, ABR-1 would in turn perform IP forwarding lookup for the encapsulated packet P2. Since the BGP next-hop of the best route for that packet is ABR-2 and ABR1 has a LSP towards ABR-2, ABR-1 would transport that encapsulated packet P2 via the LSP towards ABR-2. When that encapsulated packet P2 Xu, et al. Expires April 17, 2014 [Page 4] Internet-Draft Multi-domain MPLS Deployment Enhancement October 2013 arrives at ABR-2, ABR-2 would also perform IP forwarding lookup and then forward that packet P2 via a LSP towards PE-2. PE-2 decapsulates the received packet P2 and then process the resulting decapsualted packet P1 accordingly. 4. Conclusions By simply replacing the innermost transport LSP with an IP tunnel, the need for advertising non-aggregatable BGP labeled host routes across domains is eliminated. Instead, it only requires advertising aggregated non-labeled BGP routes across domains. As a result, the requirement for BGP RIB and MPLS forwarding table resources are largely reduced. Furthermore, in the multi-area/level MPLS deployment case where MPLS-TE shortcut or Forwarding Adjacency (FA) feature is enabled between ABRs, the need for running BGP between ABRs can be eliminated further. Instead, IGP route summary across area boundaries is good enough. 5. Security Considerations TBD. 6. IANA Considerations No action is required for IANA. 7. Acknowledgements Thanks to. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or GRE", RFC4023, March 2005. 8.2. Informative References [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. Xu, et al. Expires April 17, 2014 [Page 5] Internet-Draft Multi-domain MPLS Deployment Enhancement October 2013 [RFC4364] Rosen. E and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [Seamless-MPLS] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", draft-ietf-mpls-seamless-mpls-04(Work in Progress), July 2013. Authors' Addresses Xiaohu Xu Huawei Technologies, Beijing, China Phone: +86-10-60610041 Email: xuxiaohu@huawei.com Zhenbin Li Huawei Technologies, Beijing, China Phone: +86-10-60613676 Email: lizhenbin@huawei.com