--- 1/draft-ietf-mpls-seamless-mpls-06.txt 2014-06-28 16:14:28.196213461 -0700 +++ 2/draft-ietf-mpls-seamless-mpls-07.txt 2014-06-28 16:14:28.272215312 -0700 @@ -1,24 +1,24 @@ MPLS Working Group N. Leymann, Ed. Internet-Draft Deutsche Telekom AG Intended status: Informational B. Decraene -Expires: August 18, 2014 Orange +Expires: December 30, 2014 Orange C. Filsfils M. Konstantynowicz, Ed. Cisco Systems D. Steinberg Steinberg Consulting - February 14, 2014 + June 28, 2014 Seamless MPLS Architecture - draft-ietf-mpls-seamless-mpls-06 + draft-ietf-mpls-seamless-mpls-07 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 August 18, 2014. + This Internet-Draft will expire on December 30, 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 @@ -84,58 +84,58 @@ 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 . . . . . . . . . . . . . . . . . . 17 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17 - 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17 - 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 . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20 - 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 . . . . . . . . . . . . . . . . . 23 - 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23 + 4.7. Signalling and Label Distribution . . . . . . . . . . . . 17 + 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 19 + 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 19 + 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 19 + 5.1.2. General Network Topology . . . . . . . . . . . . . . 19 + 5.1.3. Hierarchy based on recursive BGP labeled route lookup 20 + 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 21 + 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 21 + 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 21 + 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 21 + 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 22 + 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 22 + 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 23 + 5.1.8. Network Availability . . . . . . . . . . . . . . . . 24 + 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 24 + 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 25 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent - Convergence . . . . . . . . . . . . . . . . . . . 24 - 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24 - 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 . . . . . . . . . . . . . . . . . . 31 - 5.2.1. Control and Data Plane State for Deployment Scenario - #1 . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 31 - 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31 - 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 . . . . . . . . . . . . . . . . . . . . . . 36 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 9.2. Informative References . . . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 + Convergence . . . . . . . . . . . . . . . . . . . 25 + 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 26 + 5.1.8.5. Assessing loss of connectivity upon any failure . 26 + 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 30 + 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 31 + 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 32 + 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 32 + 5.2.1. Control and Data Plane State for Deployment Scenarios 32 + 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 32 + 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 33 + 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 34 + 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 36 + 5.2.1.5. Numerical application for use case #1 . . . . . . 36 + 5.2.1.6. Numerical application for use case #2 . . . . . . 37 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 9.2. Informative References . . . . . . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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. @@ -347,28 +347,28 @@ Node and link failures are handled by rerouting the PWs (based on standard mechanisms). End customers (either residential or business customers) are connected to the access nodes using a native technology like Ethernet. The access nodes terminates the PW(s) carrying the traffic for the end customers. The link between the access node (AN) and the aggregation node (AGN) is the first MPLS enabled link. Residential Services: The service creation for all residential customers connected to the Access Nodes in an aggregation domain - is located on an Service Node connected to the AGN2x. The PW (PW1) - originated at the AN and terminates at the AGN2. A second PW is - deployed in the case where redundancy is needed on the AN (the - figure shows redundancy but this might not be the case for all ANs - in this Use Case). Additonal PWs can be deployed as well in case - more than a single service creation is needed for the residential - service (e.g. one service creation point for Internet access and a - second service creation point for IPTV services). + is located on an Service Node connected to the AGN2x. The PW + (PW1) originated at the AN and terminates at the AGN2. A second + PW is deployed in the case where redundancy is needed on the AN + (the figure shows redundancy but this might not be the case for + all ANs in this Use Case). Additonal PWs can be deployed as well + in case more than a single service creation is needed for the + residential service (e.g. one service creation point for Internet + access and a second service creation point for IPTV services). Business Sercvices: For business services the use cases shows point to point connections between two access nodes. PW2 originates at the AN and terminates on the remote AN crossing two aggregation areas and the core network. If the access node needs connections to several remote ANs the corresponding number of PWs will be originated at the AN. Nevertheless taking the number of ports available and the number of business customers on a typical access node the number of PWs will be relatively small. @@ -397,25 +397,25 @@ stage and/or between the AGN1 and AGN2 stages. The AGN2x stage is used to aggregate traffic from several AGN1x pairs. In this use case an aggregation domain is not limited to the use of a single pair of AGN2x; the deployment of several AGN2 pairs within the domain is also supported. As design goal for the scalability of the routing and forwarding within the Seamless MPLS architecture the following numbers are used: o Number of Aggregation Domains: 100 - o Number of Backbone Nodes: 1.000 + o Number of Backbone Nodes: 1,000 - o Number of Aggregation Nodes: 10.000 + o Number of Aggregation Nodes: 10,000 - o Number of Access Nodes: 100.000 + o Number of Access Nodes: 100,000 The access nodes (AN) are dual homed to two different aggregation nodes (AGN11 and AGN12) using static routing entries on the AN. The ANs are always source or sink nodes for MPLS traffic but not transit nodes. This allows a light MPLS implementation in order to reduce the complexity in the AN. The aggregation network consists of two stages with redundant connections between the stages (AGN11 is connected to AGN21 and AGN22 as well as AGN12 to AGN21 and AGN22). The gateway between the aggregation and core network is realized using the Area Border Routers (ABR). From the perspective of the @@ -641,25 +641,25 @@ customer traffic MUST be as low as possible. 3.4. Scalability 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 backbone nodes: 1,000 - o Number of aggregation nodes: 10.000 + o Number of aggregation nodes: 10,000 - o Number of access nodes: 100.000 + o Number of access nodes: 100,000 3.5. Stability o The platform should be stable under certain circumstances (e.g. missconfiguration within one area should not cause instability in other areas). o Differentiate between "All Loopbacks and Link addresses should be ping able from every where." Vs. "Link addresses are not necessary ping able from everywhere". @@ -760,20 +760,85 @@ 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 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. +4.7. Signalling and Label Distribution + + Following figures show IP/MPLS signaling and label distribution for + an LSP from AN2 to AN1 (192.0.2.1), detailing the signalling from AN1 + to AN2 (left to right) and packet forwarding from AN2 to AN1 (right + to left). It is assumed that Penultimate Hop Popping is used. + + Terminology used in the figures: + + o LDP DoD: LDP Downstream on Demand + + o LDP DU: LDP Downstream Unsolicited + + o BGP LU: BGP Label Unicast (RFC 3107) + o BGP NH: BGP Next Hop Label LYZi: L=Label, Y= node advertising the + FEC (G for AGN, B for ABR, A for AN), Z= protocol advertising it + (B for BGP, L for LDP) + + --------------------------------------------------------------------- + + AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2 + + LDP DoD -> BGP LU -> BGP LU -> LDP DoD + Next Hop Self + + 192.0.2.1 192.0.2.1 192.0.2.1 192.0.2.1 + Labels: LAL1 LAB1 LAB2 LAL2 + BGP NH: AGN1 BGP NH: ABR1 + + Figure 5: MPLS signalling for the AN / edge layer + + --------------------------------------------------------------------- + + AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2 + + | IS-IS level 2 | IS-IS level 1 -> IS-IS level 2 | + | LDPDU - LDPDU - LDPDU - LDPDU - LDPDU - LDPDU | + + FEC: AGN1 ABR1 ABR1 + Label: LGL1 LGL2 LBL1 LBL2 LBL3 LBL4 + + Figure 6: MPLS signalling and IP routing for the core layer + + --------------------------------------------------------------------- + + Static | IS-IS level 2 | IS-IS level 1 | IS-IS level 2 | Static + Routing Routing + + 192.0.2.1 -> 192.0.2/24 -> 192.0.2/20 -> 192.2/20 0/0 + AGN1 ABR1 ABR1 + + Figure 7: IP routing for the AN / edge layer + + --------------------------------------------------------------------- + + AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2 + + FEC AN1: LAL1 LAB1 LAB2 LAB2 LAB2 LAB2 LAL2 + FEC AGN1: LGL2 LBL1 LBL2 LBL3 LBL4 + /ABR1 + + Figure 8: Forwarding Plane + + --------------------------------------------------------------------- + 5. Deployment Scenarios This section describes the deployment scenarios based on the use cases and the generic architecture above. 5.1. Deployment Scenario #1 Section describing the Seamless MPLS implementation of a large european ISP. @@ -797,27 +862,27 @@ +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN / | | /| | | | | | +----+/ +-------+\/ +-------+ +------+ /+------+ | AN | /\ \/ | +----+\ +-------+ \+-------+ +------+/\ +------+ \ | | | | | | \| | +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN | | | | | | | | +-------+ +-------+ +------+ +------+ - static route ISIS L1 LDP ISIS L2 LDP + static route ISIS L1 LDP DU ISIS L2 LDP DU <-Access-><--Aggregation Domain--><---------Core---------> - Figure 5: Deployment Scenario #1 + Figure 9: Deployment Scenario #1 - As shown in Figure 5, the access nodes (AN) are connected to the + As shown in Figure 9, the access nodes (AN) are connected to the aggregation network via aggregation nodes called AGN1x, either to a single AGN1x or redundantly to two AGN1x. Each AGN1x has redundant uplinks to a pair of second-level aggregation nodes called AGN2x. Each aggregation domain is connected to the core via exactly two border routers (ABR) on the core side. There can be multiple AGN2 pairs per aggregation domain, but only one ABR pair for each aggregation domain. Each of the AGN2 in an AGN2 pair connects to one of the ABRs in the ABR pair responsible for that aggregation domain. @@ -833,55 +898,55 @@ 5.1.3. Hierarchy based on recursive BGP labeled route lookup Inline with the explanation in section 4.5, LSP hierarchy is key to a scalable seamless MPLS architecture. The LSP hierarchy in this design is achieved by: 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 + the intra-domain link-state routing protocol) and LDP DU (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. + relying on IS-IS and LDP DU 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. - LDP is used to distribute MPLS label binding information for the + LDP DU is used to distribute MPLS label binding information for the loopback addresses of all core nodes. 5.1.4.2. Aggregation The aggregation domains uses ISIS L1 as intra-domain routing protocol. All AGN loopback addresses are carried in ISIS. - As in the core, the aggregation also uses LDP to distribute MPLS + As in the core, the aggregation also uses LDP DU to distribute MPLS label bindings for the loopback addresses. 5.1.5. Access Access nodes do not have their own domain or IGP area. Instead, they directly connect to the AGN1 nodes in the aggregation domain. To keep access devices as simple as possible, ANs do not participate in ISIS. Instead, each AN has two static default routes pointing to each of @@ -893,21 +958,21 @@ The AGN1 MUST have a configured static route to the loopback address of each of the ANs it is connected to, because it cannot learn the AN loopback address in any other way. These static routes have to be monitored and invalidated if necessary using the same techniques as described above for the static default routes on the AN. The AGN1 redistributes these routes into ISIS for intra-domain reachability of all AN loopback addresses. - LDP is used for MPLS label distribution between AGN1 and AN. In + LDP DU is used for MPLS label distribution between AGN1 and AN. In order to keep the AN control plane as lightweight as possible, and to avoid the necessity for the AN to store 100.000 MPLS label bindings for each upstream AGN1 peer, LDP is deployed in downstream-on-demand (DoD) mode, described below. To allow the label bindings received via LDP DoD to be installed into the LFIB on the AN without having the specific host route to the destination loopback address, but only a default route, use of the LDP Extension for Inter-Area Label Switched Paths [RFC5283] is made. @@ -920,21 +985,21 @@ The assumption is that a given AN will only have a limited number of services configured to an even more limited number of destinations, or egress LER. Instead of learning and storing all label bindings for all possible loopback addresses within the entire Seamless MPLS network, the AN will use LDP DoD to only request the label bindings for the FECs corresponding to the loopback addresses of those egress nodes to which it has services configured. More detailed description of LDP DoD use cases for MPLS access and list of required LDP DoD procedures in the context of Seamless MPLS - design is included in [I-D.ietf-mpls-ldp-dod]. + design is included in [RFC7032]. 5.1.6. Inter-Area Routing The inter-domain MPLS connectivity from the aggregation domains to and across the core domain is realized primarily using BGP with MPLS labels ("labled BGP/SAFI4" [RFC3107]). A very limited amount of route leaking from ISIS L2 into L1 is also used. All ABR and PE nodes in the core are part of the labeled iBGP mesh, which can be either full mesh or based on route reflectors. These @@ -1071,28 +1136,28 @@ network. 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent Convergence In a hierarchical dataplane, the FIB used by the packet processing engine reflects recursions between the routes. For example, a BGP route B recursing on IGP route I whose best path is via interface O is encoded as a hierarchy of FIB entry B pointing to a FIB entry I pointing to a FIB entry 0. - BGP Prefix Independent Convergence [BGP-PIC] extends the hierarchical - dataplane with the concept of a BGP Path-List. A BGP path-list may - be abstracted as a set of primary multipath nhops and a backup nhop. - When the primary set is empty, packets destined to the BGP - destinations are rerouted via the backup nhop. + BGP Prefix Independent Convergence [I-D.rtgwg-bgp-pic] extends the + hierarchical dataplane with the concept of a BGP Path-List. A BGP + path-list may be abstracted as a set of primary multipath nhops and a + backup nhop. When the primary set is empty, packets destined to the + BGP destinations are rerouted via the backup nhop. For complete description of BGP-PIC technology and its applicability - please refer to [BGP-PIC] and [ABR-FRR]. + please refer to [I-D.rtgwg-bgp-pic] and [ABR-FRR]. Hierarchical data plane and BGP-PIC are very simple technologies to operate. Their applicability to any topology, any routing policy and any BGP unicast address family allows router vendors to enable this behavior by default. 5.1.8.4. BGP Egress Node FRR BGP egress node FRR is a Fast ReRoute solution and hence relies on local protection and the precomputation and preinstallation of the @@ -1397,21 +1462,21 @@ the inner (BGP) MPLS hierarchy, namely AGN, ABR and L3VPN PEs. For specification see [PE-FRR], [ABR-FRR], [BGP-edge-FRR##]. Both approaches have their pros and cons, and the choice is left to each Service Provider or deployment based on the different requirements. The key point is that the seamless MPLS architecture can handle fast restoration time, even for ABR failures. 5.2. Scalability Analysis -5.2.1. Control and Data Plane State for Deployment Scenario #1 +5.2.1. Control and Data Plane State for Deployment Scenarios 5.2.1.1. Introduction Let's call: o #AN the number of Access Node (AN) in the seamless MPLS domain o #AGN the number of AGgregation Node (AGN) in the seamless MPLS domain @@ -1422,54 +1487,59 @@ 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 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. + o Each Access Node needs to have up to 1,000 (1k) LSPs. LSP scale + requirement is driven by expected AN access line capacity and the + sum of LSPs required for connectivity to PE routers providing edge + services as well as a remote ANs. Number and type of services + accessed by the AN has also an impact. Hence it is very service + specific. Note that if the number of remote PE/LSPs is higher + than the capacity of the AN, some route aggregation scheme can be + enabled at the service layer, e.g. using RFC7024 for IP VPN. It + is assumed that 100 LSPs per AN (10% of total) are FECs that 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 nodes: IGP: node : #Core ~ o(1) links : 3*#Core ~ o(1) - IP prefixes : 5*#Core ~ o(1) + IP prefixes : 5*#Core + #Area ~ o(1) LDP FEC: #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) + IP FIB : 5*#Core + #Area ~ 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 @@ -1481,75 +1551,85 @@ NLRI : #AN ~ o(n) 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) + IP FIB : 5*#Core + (5*#AGN + #AN) / #Area + #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) links : 3*#AGN / #Area ~ o(1) - IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5 - / #Area) - - + + 1 loopback per core node + one aggregate per area + 5 - prefixes per AGN in the area + 1 prefix per AN in the area. + IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN + *5/ #Area) + + plus one aggregate per area (because the number of IP + prefixes is equal to 1 loopback per core node), plus 5 + prefixes per AGN in the area, plus 1 prefix per AN in the + area. LDP FEC: Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) - + + 1 loopback per core node + 1 loopback per AGN & AN node in - the area. + + plus one aggregate per area (because the number of IP + prefixes is equal to 1 loopback per core node), plus 5 + prefixes per AGN in the area, plus 1 prefix per AN in the + area. AGN FIBs grows with the number of node in the core area, in their 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 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 FIBs grow with the connectivity requirement of the services. 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 ILM (LFIB) : 1k ~ o(1) + MPLS ILM : 1k ~ o(1) if the AN is used in transit by other ANs + and hence is an LSR (use case #2 having chained AN) + + MPLS ILM : 0 ~ o(1) if the AN is not providing transit to + others ANs (use case #1 where AN are final leaf) + + MPLS NHLFE : 1k ~ o(1) 5.2.1.4. Summary 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. @@ -1581,133 +1661,134 @@ (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 Backbone Nodes 1,000 - o Number of Access Nodes 100.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 ILM (LFIB) 1 000 + o AN MPLS ILM 0 - o AGN IP FIB 2 600 + o AN MPLS NHLFE 1,000 - o AGN MPLS ILM (LFIB) 2 200 + o AGN IP FIB 2,600 - o ABR IP FIB 7 600 + o AGN MPLS ILM (LFIB) 2,200 - o ABR MPLS ILM (LFIB) 2 100 + o ABR IP FIB 6,600 - o TN IP FIB 5 000 + o ABR MPLS ILM (LFIB) 2,100 - o TN MPLS ILM (LFIB) 1 000 + o TN IP FIB 5,100 - o RR BGP NLRI 100 000 + o TN MPLS ILM (LFIB) 1,000 - o RR BGP paths 200 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 o Number of Backbone Nodes 150 - o Number of AGgregation Nodes 1.500 + o Number of AGgregation Nodes 1,500 - o Number of Access Nodes 40.000 + 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 ILM (LFIB) 1 000 + o AN MPLS ILM 1,000 - o AGN IP FIB 1 700 + o AN MPLS NHLFE 1,000 - o AGN MPLS ILM (LFIB) 1 800 + o AGN IP FIB 1,763 + o AGN MPLS ILM 1,633 - o ABR IP FIB 3 700 + o ABR IP FIB 2,363 - o ABR MPLS ILM (LFIB) 1 600 + o ABR MPLS ILM 1,533 - o TN IP FIB 750 + o TN IP FIB 780 - o TN MPLS ILM (LFIB) 150 + o TN MPLS ILM 150 - o RR BGP NLRI 40 000 + o RR BGP NLRI 40,000 - o RR BGP paths 80 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 - DeLord for their suggestions and review. + Roger Wenner, George Swallow, Kireeti Kompella, Yakov Rekhter, Mark + Tinka, Curtis Villamizar and Simon DeLord for their suggestions and + review. 7. IANA Considerations This memo does not include any requests to IANA. 8. Security Considerations The Seamless MPLS Architecture is subject to similar security threats as any MPLS LDP deployment. It is recommended that baseline security measures are considered as described in Security Framework for MPLS and GMPLS networks [RFC5920], in the LDP specification RFC5036 - [RFC5036] and in [I-D.ietf-karp-routing-tcp-analysis]including - ensuring authenticity and integrity of LDP messages, as well as - protection against spoofing and Denial of Service attacks. Some - deployments may require increased measures of network security if a - subset of Access Nodes are placed in locations with lower levels of - physical security e.g. street cabinets ( common practice for VDSL - access ). In such cases it is the responsibility of the system - designer to take into account the physical security measures ( - environmental design, mechanical or electronic access control, - intrusion detection ), as well as monitoring and auditing measures - (configuration and Operating System changes, reloads, routes - advertisements ). + [RFC5036] and in [RFC6952]including ensuring authenticity and + integrity of LDP messages, as well as protection against spoofing and + Denial of Service attacks. Some deployments may require increased + measures of network security if a subset of Access Nodes are placed + in locations with lower levels of physical security e.g. street + cabinets ( common practice for VDSL access ). In such cases it is + the responsibility of the system designer to take into account the + physical security measures ( environmental design, mechanical or + electronic access control, intrusion detection ), as well as + monitoring and auditing measures (configuration and Operating System + changes, reloads, routes advertisements ). Security aspects specific to the MPLS access network based on LDP DoD in the context of Seamless MPLS design are described in the security - section of [I-D.ietf-mpls-ldp-dod]. + section of [RFC7032]. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [ABR-FRR] Rekhter, Y., "Local Protection for LSP tail-end node failure, MPLS World Congress 2009", . - [ACM01] , , , and , "Archieving sub-second IGP convergence in - large IP networks, ACM SIGCOMM Computer Communication - Review, v.35 n.3", July 2005. - - [BGP-PIC] "BGP PIC, Technical Report", November 2007. + [ACM01] Francois, P., Filsfils, C., Evans, J., and O. Bonaventure, + "Archiving sub-second IGP convergence in large IP + networks, ACM SIGCOMM Computer Communication Review, v.35 + n.3", July 2005. [I-D.bashandy-bgp-edge-node-frr] Bashandy, A., Pithawala, B., and K. Patel, "Scalable BGP FRR Protection against Edge Node Failure", draft-bashandy- bgp-edge-node-frr-03 (work in progress), July 2012. [I-D.bashandy-bgp-frr-mirror-table] Bashandy, A., Konstantynowicz, M., and N. Kumar, "BGP FRR Protection against Edge Node Failure Using Table Mirroring with Context Labels", draft-bashandy-bgp-frr-mirror- @@ -1727,40 +1808,34 @@ [I-D.bashandy-isis-bgp-edge-node-frr] Bashandy, A., "IS-IS Extension for BGP FRR Protection against Edge Node Failure", draft-bashandy-isis-bgp-edge- node-frr-01 (work in progress), September 2012. [I-D.bashandy-mpls-ldp-bgp-frr] Bashandy, A. and K. Raza, "LDP Extension for FRR Edge Node Protection in BGP-Free LDP Core", draft-bashandy-mpls-ldp- bgp-frr-00 (work in progress), March 2012. - [I-D.ietf-karp-routing-tcp-analysis] - . - - [I-D.ietf-mpls-ldp-dod] - Beckhaus, T., Decraene, B., Tiruveedhula, K., - Konstantynowicz, M., and L. Martini, "LDP Downstream-on- - Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-09 (work - in progress), July 2013. - - [I-D.ietf-rtgwg-bgp-pic] - . - [I-D.ietf-rtgwg-remote-lfa] - . + Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. + Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-06 + (work in progress), May 2014. [I-D.minto-2547-egress-node-fast-protection] Jeganathan, J., Gredler, H., and B. Decraene, "2547 egress PE Fast Failure Protection", draft-minto-2547-egress-node- fast-protection-02 (work in progress), July 2013. + [I-D.rtgwg-bgp-pic] + Bashandy, A., Filsfils, C., and P. Mohapatra, "Abstract", + draft-rtgwg-bgp-pic-02 (work in progress), October 2013. + [PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS 2006 Conference", . [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. @@ -1771,25 +1846,36 @@ for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. - [RFC5920] . + [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. - [RFC6571] . + [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., + Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free + Alternate (LFA) Applicability in Service Provider (SP) + Networks", RFC 6571, June 2012. - [RFC7032] . + [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of + BGP, LDP, PCEP, and MSDP Issues According to the Keying + and Authentication for Routing Protocols (KARP) Design + Guide", RFC 6952, May 2013. + + [RFC7032] Beckhaus, T., Decraene, B., Tiruveedhula, K., + Konstantynowicz, M., and L. Martini, "LDP Downstream-on- + Demand in Seamless MPLS", RFC 7032, October 2013. Authors' Addresses Nicolai Leymann (editor) Deutsche Telekom AG Winterfeldtstrasse 21 Berlin 10781 DE Phone: +49 30 8353-92761