--- 1/draft-ietf-mpls-seamless-mpls-05.txt 2014-02-14 11:14:35.417455149 -0800 +++ 2/draft-ietf-mpls-seamless-mpls-06.txt 2014-02-14 11:14:35.493456999 -0800 @@ -1,24 +1,24 @@ MPLS Working Group N. Leymann, Ed. Internet-Draft Deutsche Telekom AG Intended status: Informational B. Decraene -Expires: July 16, 2014 Orange +Expires: August 18, 2014 Orange C. Filsfils M. Konstantynowicz, Ed. Cisco Systems D. Steinberg Steinberg Consulting - January 12, 2014 + February 14, 2014 Seamless MPLS Architecture - draft-ietf-mpls-seamless-mpls-05 + draft-ietf-mpls-seamless-mpls-06 Abstract This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service @@ -38,21 +38,21 @@ 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 July 16, 2014. + This Internet-Draft will expire on August 18, 2014. Copyright Notice Copyright (c) 2014 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 @@ -82,60 +82,60 @@ 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 16 - 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16 + 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 17 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17 - 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 17 - 5.1.2. General Network Topology . . . . . . . . . . . . . . 17 - 5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18 + 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 18 + 5.1.2. General Network Topology . . . . . . . . . . . . . . 18 + 5.1.3. Hierarchy based on recursive BGP labeled route lookup 19 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 19 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 19 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 - 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20 - 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 20 - 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 21 + 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 21 + 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 22 5.1.8. Network Availability . . . . . . . . . . . . . . . . 22 - 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 22 + 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent - Convergence . . . . . . . . . . . . . . . . . . . 23 + Convergence . . . . . . . . . . . . . . . . . . . 24 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24 - 5.1.8.5. Assessing loss of connectivity upon any failure . 24 - 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 28 - 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 29 + 5.1.8.5. Assessing loss of connectivity upon any failure . 25 + 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29 + 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 30 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30 - 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 30 + 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 31 5.2.1. Control and Data Plane State for Deployment Scenario - #1 . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 30 + #1 . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 31 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31 - 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 32 - 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 33 - 5.2.1.5. Numerical application for use case #1 . . . . . . 34 + 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 33 + 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34 + 5.2.1.5. Numerical application for use case #1 . . . . . . 35 5.2.1.6. Numerical application for use case #2 . . . . . . 35 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 - 9.2. Informative References . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 9.2. Informative References . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction MPLS as a mature and well known technology is widely deployed in today's core and aggregation/metro area networks. Many metro area networks are already based on MPLS delivering Ethernet services to residential and business customers. Until now those deployments are usually done in different domains; e.g. core and metro area networks are handled as separate MPLS domains. @@ -422,30 +422,31 @@ MPLS transport layer all systems are clearly identified using the loopback address of the system. An ingress node must be able to establish a service to an arbitrary egress system by using the corresponding MPLS transport label 2.2.2. Typical Numbers Table 1 shows typical numbers which are expected for Use Case #1 (access node). - +-------------------+---------------+ + +--------------------+---------------+ | Parameter | Typical Value | - +-------------------+---------------+ - | IGP Control Plane | 2 | - | IP FIB | 2 | - | LDP Control Plane | 200 | - | LDP FIB | 200 | - | BGP Control Plane | 0 | - | BGP FIB | 0 | - +-------------------+---------------+ + +--------------------+---------------+ + | IGP RIB Entries | 2 | + | IP FIB Entries | 2 | + | LDP LIB Entries | 200 | + | MPLS NHLFE Entries | 200 | + | MPLS ILM Entries | 0 | + | BGP RIB Entries | 0 | + | BGP FIB Entries | 0 | + +--------------------+---------------+ Table 1: Use Case #1: Typical Numbers for Access Node 2.3. Use Case #2 2.3.1. Description In most cases, residential, wholesales and business services need to be supported by the network. @@ -513,28 +514,29 @@ o Number of Access Nodes: 40.000 2.3.2. Typical Numbers Table 2 shows typical numbers which are expected for Use Case #2 for the purpose of establishing the transport LSPs. They do not take into account the services built in addition. (e.g. 6PE will require additional IPv6 routes). - +-------------------+---------------+ + +--------------------+---------------+ | Parameter | Typical Value | - +-------------------+---------------+ - | IGP Control Plane | 2 | - | IP FIB | 2 | - | LDP Control Plane | 1000 | - | LDP FIB | 1000 | - +-------------------+---------------+ + +--------------------+---------------+ + | IGP RIB Entries | 2 | + | IP FIB Entries | 2 | + | LDP LIB Entries | 1,400 | + | MPLS NHLFE Entries | 1,400 | + | MPLS ILM Entries | 1,400 | + +--------------------+---------------+ Table 2: Use Case #2: Typical Numbers for Access Node 3. Requirements The following section describes the overall requirements which need to be fulfilled by the Seamless MPLS architecture. Beside the general requirements of the architecture itself there are also certain requirements which are related to the different network nodes. @@ -633,21 +635,22 @@ o Switch Fabric o Routing Processor A change from an active component to a standby component SHOULD happen without effecting customers traffic. The Influence of customer traffic MUST be as low as possible. 3.4. Scalability - The network must be highly scalable. As a minimum requirement the + The network must be highly scalable. Based on the use cases + described in Sections 2.2 and 2.3, as a minimum requirement the following scalability figures should be met: o Number of aggregation domains: 100 o Number of backbone nodes: 1.000 o Number of aggregation nodes: 10.000 o Number of access nodes: 100.000 @@ -712,49 +715,61 @@ The intra-domain routing within each of the MPLS domains (i.e. aggregation domains and core) SHOULD utilize standard IGP protocols like OSPF or ISIS. By definition, each of these domains is small enough so that there are no relevant scaling limits within each IGP domain, given well-known state-of-the-art IGP design principles and recent router technology. The intra-domain MPLS LSP setup and label distribution SHOULD utilize standard protocols like LDP or RSVP. + Note that this document describes the design based on LDP, LDP + Downstream-on-Demand and labeled BGP due to the higher degree of out- + of-the-box automation and operational simplicity as well as + compatibility with the existing backbone and backhaul designs & + deployments which use LDP and not RSVP-TE. It also assumes + relatively simple MPLS implementations on access nodes. The protocol + choices for the design described in this document have been driven by + the actual SP deployments. Design based on the hierarchy of RSVP-TE + LSPs may be an alternative, but has not been considered in this + document. + 4.5. Inter-Domain Routing The inter-domain routing is responsible for establishing connectivity between and across all MPLS domains. The inter-domain routing SHOULD establish a routing and forwarding hierarchy in order to achieve the scaling goals of seamless MPLS. Note that the IP aggregation usually performed between region (IGP areas/AS) in IP routing does not work for MPLS as MPLS is not capable of aggregating FEC (because MPLS forwarding use an exact match lookup, while IP uses longest match). Therefore it is RECOMMENDED to utilize protocols that support indirect next-hops ( e.g. using BGP to carry MPLS label information - [RFC3107] ). + [RFC3107] ). The mechanism for the LSP forwarding hierarchy is + described in Section 5.3. 4.6. Access Compared to the aggregation and core parts of the Seamless MPLS network the access part is special in two respects: - o The number of ndes in the access is at least one order of + o The number of nodes in the access is at least one order of magnitude higher than in any other part of the network. o Because of the large quantity of access nodes, the cost of these - nodes is extremly relevant for the overall costs of the entire + nodes is extremely relevant for the overall costs of the entire network, i.e. acess nodes are very cost sensitive. This makes it desirable to design the architecture such that the AN functionality can be kept as simple as possible. This should always - be kept in mind when evalulating different seamless MPLS + be kept in mind when evaluating different seamless MPLS architectures. The goal is to limit both the number of different protocols needed on the AN as well as the scale to which each protocol must perform to the absolute minimum. 5. Deployment Scenarios This section describes the deployment scenarios based on the use cases and the generic architecture above. 5.1. Deployment Scenario #1 @@ -808,39 +823,46 @@ The ABRs on the core side have redundant connections to a pair of LSR routers. The LSR pair is also connected via a direct link. The core LSR are connected to other core LSR in a partly meshed topology so that there are disjunct, redundant paths from each LSR to each other LSR. -5.1.3. Hierarchy +5.1.3. Hierarchy based on recursive BGP labeled route lookup - As explained before, hierarchy is the key to a scalable seamless MPLS - architecture. The hierarchy in this implementation is achieved by - forming different MPLS domains for aggregation domains and core, - where within each of these domains a fairly common MPLS deployment - using ISIS as intradomain link-state routing protocol and using LDP - for MPLS label distribution is used. + Inline with the explanation in section 4.5, LSP hierarchy is key to a + scalable seamless MPLS architecture. - These MPLS domains are mapped to ISIS areas as follows: Aggregation - domains are mapped to ISIS L1 areas. The core is configured as ISIS - L2. The border routers connecting aggregation and core are ISIS L1L2 - and are referred to as ABRs. From a technical and operational point - of view these ABRs are part of the core, althought they also belong - to the respective aggregation domain purely from a routing protocol - point of view. + The LSP hierarchy in this design is achieved by: - For the inter-domain routing BGP with MPLS labels is - deployed[RFC3107]. + o Forming separate MPLS domains for aggregation and core areas. + + o Intra-domain LSP connectivity provided by combination of IS-IS (as + the intra-domain link-state routing protocol) and LDP (used for + MPLS label distribution for intra-domain LSPs). + + o Inter-domain LSP connectivity provided by labeled BGP [RFC3107] + (used for MPLS label distribution for inter-domain LSP FECs) and + relying on IS-IS and LDP for intra-domain LSP connectivity between + the LSR labeled BGP speakers (AGNs and ABRs). Note that the MPLS + core notes are not carrying the labeled BGP routes. + + The aggregation and core MPLS domains are mapped to IS-IS areas as + follows: Aggregation domains are mapped to IS-IS L1 areas. The core + is configured as IS-IS L2. The border routers connecting aggregation + and core are IS-IS L1L2 and are referred to as ABRs. From a + technical and operational point of view these ABRs are part of the + core, although they also belong to the respective aggregation domain + purely from a routing protocol point of view. 5.1.4. Intra-Area Routing 5.1.4.1. Core The core uses ISIS L2 to distribute routing information for the loopback addresses of all core nodes. The border routers (ABR) that connect to the aggregation domains are also part of the respective aggregation ISIS L1 area and hence ISIS L1L2. @@ -1400,21 +1422,24 @@ Let's take the following assumptions: o Aggregation equipments are equally spread across aggregation routing domains o the number of IGP links is three times the number of IGP nodes o the number of IGP prefixes is five times the number of IGP nodes (links prefixes + 2 loopbacks) - o Access Nodes need to set up 1000 (1k) LSPs. 10% (100) are FEC + o Each Access Node needs to have up to 1,000 (1k) LSPs. This is + driven by the expected AN access line capacity, and a sum of LSPs + required for connectivity to PE routers providing edge services as + well as a remote ANs. 100 LSPs per AN (10% of total) are FECs which are outside of their routing domain. Those 100 remote FEC are the same for all Access Nodes of a given AGN. The following sections roughly evaluate the scalability, both in absolute numbers and relatively with the number of Access Node which is the biggest scalability factor. 5.2.1.2. Core Domain The IGP & LDP core domain are not affected by the number of access @@ -1432,21 +1457,21 @@ #Core ~ o(1) Core TN FIBs grows linearly with the number of node in the core domain. In other word, they are not affected by AGN and AN nodes: Core TN: IP FIB : 5*#Core ~ o(1) - MPLS LFIB : #Core ~ o(1) + MPLS ILM (LFIB) : #Core ~ o(1) BGP carries all AN routes which is significant. However, all AN routes are only needed in the control plane, possibly in a dedicated BGP Route Reflector (just like for BGP/MPLS VPNs) and not in the forwarding plane. The number of routes (100k) is smaller than the number of number of routes in the Internet (300k and rising) or in major VPN SP (>500k and rising) so the target can be handled with current implementations. In addition, AN routes are internal routes whose churn and instability is smaller and more under control than external routes. @@ -1458,21 +1483,21 @@ path : 2*#AN ~ o(2n) ABR handles both the core and aggregations routes. They do not depend on the total number of AN nodes, but only on the number of AN in their aggregation domain. ABR: IP FIB : 5*#Core + (5*#AGN + #AN) / #Area ~ o(#AN /#Area) - MPLS LFIB : #Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) + MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) 5.2.1.3. Aggregation Domain In the aggregation domain, IGP & LDP are not affected by the number of access nodes outside of their domain. They are not affected by the total number of AN nodes: IGP: node : #AGN / #Area ~ o(1) @@ -1495,96 +1521,103 @@ aggregation area, plus the number of inter domain LSP required by the AN attached to them. They do not depend on the total number of AN nodes. In the BGP control plane, AGN also needs to handle all the AN routes. AGN: IP FIB : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5/ #Area) - MPLS LFIB : #Core + (#AGN + #AN) / #Area + 100 ~ o(#AN / #Area) + MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area + 100 ~ o(#AN / + #Area) AN FIBs grows with its connectivity requirement. They do not depend on the number of AN, AGN, SN or any others nodes. AN: IP RIB : 1 ~ o(1) MPLS LIB : 1k ~ o(1) IP FIB : 1 ~ o(1) - MPLS LFIB : 1k ~ o(1) + MPLS ILM (LFIB) : 1k ~ o(1) 5.2.1.4. Summary - AN requirements are kept minimal. BGP is not required and the size - of their FIB is limited to their own connectivity requirements. + AN requirements are kept to a minimum. BGP is not required on ANs + and the size of their FIB is driven only by their own connectivity + requirements. In the FIB scale analysis described in sections + 5.2.1.x, it was assumed that any single AN will need no more than + 1,000 LSPs. This assumption is based on the expected AN access line + capacity and LSPs required for connectivity to PE routers providing + edge services as well as a sparse mesh of connectivity between ANs. - In the core area, IGP and LDP are not affected by the node in the + In the core area, IGP and LDP are not affected by the nodes in the aggregation domains. In particular they do not grow with the number - of AGN or AN. + of AGNs or ANs. In the aggregation areas, IGP and LDP are affected by the number of - core nodes and the number of AGN and AN in their area. They are not - affected by the total number of AGN or AN in the seamless MPLS + core nodes and the number of AGNs and ANs in their area. They are + not affected by the total number of AGNs or ANs in the seamless MPLS domain. - No FIB of any node is required to handle the total number of AGN or - AN in the seamless MPLS domain. In other word, the number of AGN and - AN in the seamless MPLS domain is not limited, if the number of areas - can grow accordingly. The main limitation is the MPLS connectivity - requirements on the AN, i.e. mainly the number of LSP needed on the - AN. Another limitation may be the number of different LSP needed by - AN attached or behind an AGN. However, given foreseen deployments - and current AGN capabilities, this is not expected to be a - limitation. + No FIB of any node is required to handle the total number of AGNs or + ANs in the Seamless MPLS domain. In other words, the number of AGNs + and ANs in the Seamless MPLS domain is not a limiting factor, and the + design can be scaled by growing the number of areas. The main + limitation is the MPLS connectivity requirements on the AN, i.e. + mainly the number of LSP needed per AN. Another limitation may be + the number of different LSPs required by ANs attached to specific + AGN. However, given the foreseen deployments and current AGN + capabilities, this is not expected to be a limiting factor. In the control plane, BGP will typically handle all AN routes. This - is significant but target deployments are well under current - equipments capacities. In addition, if required, additional - techniques could be used to improve this scalability, based on the - experience gained with scaling BGP/MPLS VPN (e.g. route partitioning - between RR planes, route filtering (static or dynamic with ORF or - route refresh) between AN and on AGN to improve AGN scalability. + is expected to be substantial, but again the target deployment scale + are well within the capabilities of current equipment . In addition, + if required, additional techniques could be used to improve the + scalability, based on the experience gained with scaling BGP/MPLS VPN + (e.g. route partitioning between RR planes, route filtering (static + or dynamic with ORF or route refresh) between ANs and on AGN to + improve AGN scalability. 5.2.1.5. Numerical application for use case #1 As a recap, targets for deployment scenario 1 are: o Number of Aggregation Domains 100 o Number of Backbone Nodes 1.000 o Number of AGgregation Nodes 10.000 o Number of Access Nodes 100.000 This gives the following scaling numbers for each category of nodes: o AN IP FIB 1 - o AN MPLS LFIB 1 000 + o AN MPLS ILM (LFIB) 1 000 o AGN IP FIB 2 600 - o AGN MPLS LFIB 2 200 + o AGN MPLS ILM (LFIB) 2 200 o ABR IP FIB 7 600 - o ABR MPLS LFIB 2 100 + o ABR MPLS ILM (LFIB) 2 100 o TN IP FIB 5 000 - o TN MPLS LFIB 1 000 + o TN MPLS ILM (LFIB) 1 000 o RR BGP NLRI 100 000 o RR BGP paths 200 000 5.2.1.6. Numerical application for use case #2 As a recap, targets for deployment scenario 1 are: o Number of Aggregation Domains 30 @@ -1592,33 +1625,33 @@ o Number of Backbone Nodes 150 o Number of AGgregation Nodes 1.500 o Number of Access Nodes 40.000 This gives the following scaling numbers for each category of nodes: o AN IP FIB 1 - o AN MPLS LFIB 1 000 + o AN MPLS ILM (LFIB) 1 000 o AGN IP FIB 1 700 - o AGN MPLS LFIB 1 800 + o AGN MPLS ILM (LFIB) 1 800 o ABR IP FIB 3 700 - o ABR MPLS LFIB 1 600 + o ABR MPLS ILM (LFIB) 1 600 o TN IP FIB 750 - o TN MPLS LFIB 150 + o TN MPLS ILM (LFIB) 150 o RR BGP NLRI 40 000 o RR BGP paths 80 000 6. Acknowledgements Many people contributed to this document. The authors would like to thank Wim Henderickx, Robert Raszuk, Thomas Beckhaus, Wilfried Maas, Roger Wenner, Kireeti Kompella, Yakov Rekhter, Mark Tinka and Simon