Internet DRAFT - draft-xu-mpls-multi-domain-deployment-enhancement

draft-xu-mpls-multi-domain-deployment-enhancement



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