idnits 2.17.1 draft-ietf-mpls-seamless-mpls-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2014) is 3588 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-06 == Outdated reference: A later version (-03) exists of draft-minto-2547-egress-node-fast-protection-02 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group N. Leymann, Ed. 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Informational B. Decraene 5 Expires: December 30, 2014 Orange 6 C. Filsfils 7 M. Konstantynowicz, Ed. 8 Cisco Systems 9 D. Steinberg 10 Steinberg Consulting 11 June 28, 2014 13 Seamless MPLS Architecture 14 draft-ietf-mpls-seamless-mpls-07 16 Abstract 18 This documents describes an architecture which can be used to extend 19 MPLS networks to integrate access and aggregation networks into a 20 single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is 21 based on existing and well known protocols. It provides a highly 22 flexible and a scalable architecture and the possibility to integrate 23 100.000 of nodes. The separation of the service and transport plane 24 is one of the key elements; Seamless MPLS provides end to end service 25 independent transport. Therefore it removes the need for service 26 specific configurations in network transport nodes (without end to 27 end transport MPLS, some additional services nodes/configurations 28 would be required to glue each transport domain). This draft defines 29 a routing architecture using existing standardized protocols. It 30 does not invent any new protocols or defines extensions to existing 31 protocols. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 30, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 6 72 2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 7 73 2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7 74 2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 10 75 2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10 76 2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 77 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 12 78 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 79 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 13 81 3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13 82 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 14 83 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 84 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14 85 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15 86 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15 87 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 88 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15 90 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16 91 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 16 92 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 17 93 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 4.7. Signalling and Label Distribution . . . . . . . . . . . . 17 95 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 19 96 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 19 97 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 19 98 5.1.2. General Network Topology . . . . . . . . . . . . . . 19 99 5.1.3. Hierarchy based on recursive BGP labeled route lookup 20 100 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 21 101 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 21 102 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 21 103 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 21 104 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 22 105 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 22 106 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 23 107 5.1.8. Network Availability . . . . . . . . . . . . . . . . 24 108 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 24 109 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 25 110 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent 111 Convergence . . . . . . . . . . . . . . . . . . . 25 112 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 26 113 5.1.8.5. Assessing loss of connectivity upon any failure . 26 114 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 30 115 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 31 116 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 32 117 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 32 118 5.2.1. Control and Data Plane State for Deployment Scenarios 32 119 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 32 120 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 33 121 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 34 122 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 36 123 5.2.1.5. Numerical application for use case #1 . . . . . . 36 124 5.2.1.6. Numerical application for use case #2 . . . . . . 37 125 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 126 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 127 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 128 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 129 9.1. Normative References . . . . . . . . . . . . . . . . . . 39 130 9.2. Informative References . . . . . . . . . . . . . . . . . 39 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 133 1. Introduction 135 MPLS as a mature and well known technology is widely deployed in 136 today's core and aggregation/metro area networks. Many metro area 137 networks are already based on MPLS delivering Ethernet services to 138 residential and business customers. Until now those deployments are 139 usually done in different domains; e.g. core and metro area networks 140 are handled as separate MPLS domains. 142 Seamless MPLS extends the core domain and integrates aggregation and 143 access domains into a single MPLS domain ("Seamless MPLS"). This 144 enables a very flexible deployment of an end to end service delivery. 145 In order to obtain a highly scalable architecture Seamless MPLS takes 146 into account that typical access devices (DSLAMs, MSAN) are lacking 147 some advanced MPLS features, and may have more scalability 148 limitations. Hence access devices are kept as simple as possible. 150 Seamless MPLS is not a new protocol suite but describes an 151 architecture by deploying existing protocols like BGP, LDP and ISIS. 152 Multiple options are possible and this document aims at defining a 153 single architecture for the main function in order to ease 154 implementation prioritization and deployments in multi vendor 155 networks. Yet the architecture should be flexible enough to allow 156 some level of personalization, depending on use cases, existing 157 deployed base and requirements. Currently, this document focus on 158 end to end unicast LSP. 160 1.1. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 1.2. Terminology 168 This document uses the following terminology 170 o Access Node (AN): An access node is a node which processes 171 customers frames or packets at Layer 2 or above. This includes 172 but is not limited to DSLAMs or OLTs (in case of (G)PON 173 deployments). Access nodes have only limited MPLS functionalities 174 in order to reduce complexity in the access network. 176 o Aggregation Node (AGN): An aggregation node (AGN) is a node which 177 aggregates several access nodes (ANs). 179 o Area Border Router (ABR): Router between aggregation and core 180 domain. 182 o Deployment Scenario: Describes which an implementation of Seamless 183 MPLS in order to fullfil the requirements derived from one or more 184 use cases. 186 o Seamless MPLS Domain: A set of MPLS equipments which can set MPLS 187 LSPs between them. 189 o Transport Node (TN): Transport nodes are used to connect access 190 nodes to service nodes, and services nodes to services nodes. 191 Transport nodes ideally have no customer or service state and are 192 therefore decoupled from service creation. 194 o Seamless MPLS (S-MPLS): Used as a generic term to describe an 195 architecture which integrates access, aggregation and core network 196 in a single MPLS domain. 198 o Service Node (SN): A service node is used to create services for 199 customers and is connected to one or more transport nodes. 200 Typical examples include Broadband Network Gateways (BNGs), video 201 servers 203 o Transport Pseudo Wire (T-PW): A transport pseudowire provides 204 service independent transport mechanisms based on Pseudo-Wires 205 within the Seamless MPLS architecture. 207 o Use Case: Describes a typical network including service creation 208 points in order to describe the requirments, typical numbers etc. 209 which need to be taken into account when applying the Seamless 210 MPLS architecture. 212 2. Motivation 214 MPLS is deployed in core and aggregation network for several years 215 and provides a mature and stable basis for large networks. In 216 addition MPLS is already used in access networks, e.g. such as mobile 217 or DSL backhaul. Today MPLS as technology is being used on two 218 different layers: 220 o the Transport Layer and 222 o the Service Layer (e.g. for MPLS VPNs) 224 In both cases the protocols and the encapsulation are identical but 225 the use of MPLS is different especially concerning the signalling, 226 the control plane, the provisioning, the scalability and the 227 frequency of updates. On the service layer only service specific 228 information is exchanged; every service can potentially deploy it's 229 own architecture and individual protocols. The services are running 230 on top of the transport layer. Nevertheless those deployments are 231 usually isolated, focussed on a single use case and not integrated 232 into an end-to-end manner. 234 The motivation of Seamless MPLS is to provide an architecture which 235 supports a wide variety of different services on a single MPLS 236 platform fully integrating access, aggregation and core network. The 237 architecture can be used for residential services, mobile backhaul, 238 business services and supports fast reroute, redundancy and load 239 balancing. Seamless MPLS provides the deployment of service creation 240 points which can be virtually everywhere in the network. This 241 enables network and service providers with a flexible service and 242 service creation. Service creation can be done based on the existing 243 requirements without the needs for dedicated service creation areas 244 on fixed locations. With the flexibility of Seamless MPLS the 245 service creation can be done anywhere in the network and easily moved 246 between different locations. 248 2.1. Why Seamless MPLS 250 Multiple Service Providers plan to deploy networks with 10k to 100k 251 MPLS nodes, with varying levels of MPLS LSP connectivity between 252 those nodes - sparse-mesh in access, partial-mesh in aggregation and 253 full-mesh in core. This is typically at least one order of magnitude 254 higher than current deployments and may require a new architecture. 255 Multiple options are possible and it makes sense for the industry 256 (both vendors and SP) to restrict the options in order to ease the 257 first deployments (e.g. restrict the number of options to implement 258 and/or scales for vendors, reduce interoperability and debugging 259 issues for SP). 261 Many aggregation networks are already deploying MPLS but are limited 262 to the use of MPLS per aggregation area. Those MPLS based 263 aggregation domains are connected to a core network running MPLS as 264 well. Nevertheless most of the services are not limited to an 265 aggregation domain but running between several aggregation domains 266 crossing the core network. In the past it was necessary to provide 267 connectivity between the different domains and the core on a per 268 service level and not based on MPLS (e.g. by deploying native IP- 269 Routing or Ethernet based technologies between aggregation and core). 270 In most cases service specific configurations on the border nodes 271 between core and aggregation were required. New services led to 272 additional configurations and changes in the provisioning tools (see 273 Figure 1). 275 With Seamless MPLS there are no technology boundaries and no topology 276 boundaries for the services. Network (or region) boundaries are for 277 scaling and manageability, and do not affect the service layer, since 278 the Transport Pseudowire that carries packets from the AN to the SN 279 doesn't care whether it takes two hops or twenty, nor how many region 280 boundaries it needs to cross. The network architecture is about 281 network scaling, network resilience and network manageability; the 282 service architecture is about optimal delivery: service scaling, 283 service resilience (via replicated SNs) and service manageability. 284 The two are decoupled: each can be managed separately and changed 285 independently. 287 +--------------+ +--------------+ +--------------+ 288 | Aggregation | | Core | | Aggregation | 289 | Domain #1 +---------+ Domain +---------+ Domain #2 | 290 | MPLS | ^ | MPLS | ^ | MPLS | 291 +--------------+ | +--------------+ | +--------------+ 292 | | 293 +------ service specific ------+ 294 configuration 296 Figure 1: Service Specific Configurations 298 One of the main motivations of Seamless MPLS is to get rid of service 299 specific configurations between the different MPLS islands. Seamless 300 MPLS connects all MPLS domains on the MPLS transport layer providing 301 a single transport layer for all services - independent of the 302 service itself. The Seamless MPLS architecture therefore decuples 303 the service and transport layer and integrates access, aggregation 304 and core into a single platform. One of the big advantages is that 305 problems on the transport layer only need to be solved once (and the 306 solutions are available to all services). With Seamless MPLS it is 307 not necessary to use service specific configurations on intermediate 308 nodes; all services can be deployed in an end to end manner. 310 2.2. Use Case #1 312 2.2.1. Description 314 In most cases at least residential and business services need to be 315 supported by a network. This section describes a Seamless MPLS use 316 case which supports such a scenario. The use case includes point to 317 point services for business customers as well as typical service 318 creation for residential customers. 320 +-------------+ 321 | Service | 322 | Creation | 323 | Residential | 324 | Customers | 325 +------+------+ 326 | 327 | 328 | 329 PW1 +-------+ +---+---+ 330 ######################### | 331 # +--+ AGN11 +---+ AGN21 + +------+ 332 # / | | /| |\ | | +--------+ 333 +--#-+/ +-------+\/ +-------+ \| | | remote | 334 | AN | /\ + CORE +---......--+ AN | 335 +--#-+\ +-------+ \+-------+ /| | ####### | 336 # \ | | | |/################### +--------+ 337 # +--+ AGN12 +---+ AGN22 +##+------+ P2P Business Service 338 ############################## 339 PW2 +-------+ +-------+ 341 Figure 2: Use Case #1: Service Creation 343 Figure 2 shows the different service creation points and the 344 corresponding pseudowires between the access nodes and the service 345 creation points. The use case does not show all PWs (e.g. not the 346 PWs needed to support redundancy) in order to keep the figure simple. 347 Node and link failures are handled by rerouting the PWs (based on 348 standard mechanisms). End customers (either residential or business 349 customers) are connected to the access nodes using a native 350 technology like Ethernet. The access nodes terminates the PW(s) 351 carrying the traffic for the end customers. The link between the 352 access node (AN) and the aggregation node (AGN) is the first MPLS 353 enabled link. 355 Residential Services: The service creation for all residential 356 customers connected to the Access Nodes in an aggregation domain 357 is located on an Service Node connected to the AGN2x. The PW 358 (PW1) originated at the AN and terminates at the AGN2. A second 359 PW is deployed in the case where redundancy is needed on the AN 360 (the figure shows redundancy but this might not be the case for 361 all ANs in this Use Case). Additonal PWs can be deployed as well 362 in case more than a single service creation is needed for the 363 residential service (e.g. one service creation point for Internet 364 access and a second service creation point for IPTV services). 366 Business Sercvices: For business services the use cases shows point 367 to point connections between two access nodes. PW2 originates at 368 the AN and terminates on the remote AN crossing two aggregation 369 areas and the core network. If the access node needs connections 370 to several remote ANs the corresponding number of PWs will be 371 originated at the AN. Nevertheless taking the number of ports 372 available and the number of business customers on a typical access 373 node the number of PWs will be relatively small. 375 +-------+ +-------+ +------+ +------+ 376 | | | | | | | | 377 +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN 378 / | | /| | | | | | 379 +----+/ +-------+\/ +-------+ +------+ /+------+ 380 | AN | /\ \/ 381 +----+\ +-------+ \+-------+ +------+/\ +------+ 382 \ | | | | | | \| | 383 +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN 384 | | | | | | | | 385 +-------+ +-------+ +------+ +------+ 387 static route ISIS L1 LDP ISIS L2 LDP 389 <-Access-><--Aggregation Domain--><---------Core---------> 391 Figure 3: Use Case #1: Redundancy 393 Figure 3 shows the redundancy at the access and aggregation network 394 deploying a two stage aggregation network (AGN1x/AGN2x). 395 Nevertheless redundancy is not a must in this use case. It is also 396 possible to use non redundant connection between the ANs and AGN1 397 stage and/or between the AGN1 and AGN2 stages. The AGN2x stage is 398 used to aggregate traffic from several AGN1x pairs. In this use case 399 an aggregation domain is not limited to the use of a single pair of 400 AGN2x; the deployment of several AGN2 pairs within the domain is also 401 supported. As design goal for the scalability of the routing and 402 forwarding within the Seamless MPLS architecture the following 403 numbers are used: 405 o Number of Aggregation Domains: 100 407 o Number of Backbone Nodes: 1,000 409 o Number of Aggregation Nodes: 10,000 411 o Number of Access Nodes: 100,000 413 The access nodes (AN) are dual homed to two different aggregation 414 nodes (AGN11 and AGN12) using static routing entries on the AN. The 415 ANs are always source or sink nodes for MPLS traffic but not transit 416 nodes. This allows a light MPLS implementation in order to reduce 417 the complexity in the AN. The aggregation network consists of two 418 stages with redundant connections between the stages (AGN11 is 419 connected to AGN21 and AGN22 as well as AGN12 to AGN21 and AGN22). 420 The gateway between the aggregation and core network is realized 421 using the Area Border Routers (ABR). From the perspective of the 422 MPLS transport layer all systems are clearly identified using the 423 loopback address of the system. An ingress node must be able to 424 establish a service to an arbitrary egress system by using the 425 corresponding MPLS transport label 427 2.2.2. Typical Numbers 429 Table 1 shows typical numbers which are expected for Use Case #1 430 (access node). 432 +--------------------+---------------+ 433 | Parameter | Typical Value | 434 +--------------------+---------------+ 435 | IGP RIB Entries | 2 | 436 | IP FIB Entries | 2 | 437 | LDP LIB Entries | 200 | 438 | MPLS NHLFE Entries | 200 | 439 | MPLS ILM Entries | 0 | 440 | BGP RIB Entries | 0 | 441 | BGP FIB Entries | 0 | 442 +--------------------+---------------+ 444 Table 1: Use Case #1: Typical Numbers for Access Node 446 2.3. Use Case #2 448 2.3.1. Description 450 In most cases, residential, wholesales and business services need to 451 be supported by the network. 453 +-------------+ 454 | Service | 455 | platforms | 456 |(VoIP, VoD..)| 457 | Residential | 458 | Customers | 459 +------+------+ 460 | 461 | 462 +---+ +-----+ +--+--+ +-----+ 463 |AN1|----+AGN11+--+AGN21+---+ ABR | 464 +---+ +--+--+ +--+--+ +--+--+ 465 | | | 466 +---+ +--+--+ | | +----+ 467 |AN2|----+AGN12+ | | --+ PE | 468 +---+ +--+--+ | | +----+ 469 | | | 470 . | | 471 . | | 472 . | | 473 | | | 474 +---+ +---+ +--+--+ +--+--+ +--+--+ 475 |AN4+---+AN3|----+AGN1x+--+AGN22+---+ ABR | 476 +---+ +---+ +-----+ +-----+ +-----+ 478 <-Access-><--Aggregation Domain--><---------Core---------> 480 Figure 4: Use Case #2 482 The above topology (see Figure 4) is subject to evolutions, depending 483 on AN types and capacities (in terms of number of customers and/or 484 aggregated bandwidth). For examples, AGN1x connection toward AGN2y 485 currently forms a ring but may latter evolve in a square or triangle 486 topology; AGN2y nodes may not be present... 488 Most access nodes (AN) are single attached on one aggregation node 489 using static routing entries on the AN and AGN. Some AN, are dual 490 attached on two different AGN using static routes. Some AN are used 491 as transit by some lower level AN. Static routes are expected to be 492 used between those AN. 494 IPv4, IPv6 and MPLS interconnection between the aggregation and core 495 network is realized using the Area Border Routers (ABR). Any ingress 496 node must be able to establish IPv4, IPv6 and MPLS connections to any 497 egress node in the seamless MPLS domain. 499 Regarding MPLS connectivity requirements, a full mesh of MPLS LSPs is 500 required between the ANs of an aggregation area, at least for 6PE 501 purposes. Some additional LSPs are needed between ANs and some PE in 502 the aggregation area or in the core area for access to services, 503 wholesale and enterprises services. In short, a meshing of LSP is 504 required between the AGN of the whole seamless MPLS domain. Finally, 505 LSP between any node to any node should be possible. 507 From a scalability standpoint, the following numbers are the targets: 509 o Number of Aggregation Domains: 30 511 o Number of Backbone Nodes: 150 513 o Number of Aggregation Nodes: 1.500 515 o Number of Access Nodes: 40.000 517 2.3.2. Typical Numbers 519 Table 2 shows typical numbers which are expected for Use Case #2 for 520 the purpose of establishing the transport LSPs. They do not take 521 into account the services built in addition. (e.g. 6PE will require 522 additional IPv6 routes). 524 +--------------------+---------------+ 525 | Parameter | Typical Value | 526 +--------------------+---------------+ 527 | IGP RIB Entries | 2 | 528 | IP FIB Entries | 2 | 529 | LDP LIB Entries | 1,400 | 530 | MPLS NHLFE Entries | 1,400 | 531 | MPLS ILM Entries | 1,400 | 532 +--------------------+---------------+ 534 Table 2: Use Case #2: Typical Numbers for Access Node 536 3. Requirements 538 The following section describes the overall requirements which need 539 to be fulfilled by the Seamless MPLS architecture. Beside the 540 general requirements of the architecture itself there are also 541 certain requirements which are related to the different network 542 nodes. 544 o End to End Transport LSP: MPLS based services (pseudowire based, 545 L3-VPN or IP) SHALL be provided by the Seamless MPLS based 546 infrastructure between any nodes. 548 o Scalability: The network SHALL be scalable to the minimum of 549 100.000 nodes. 551 o Fast convergence (sub second resilience) SHALL be supported. Fast 552 reroute (LFA) SHOULD be supported. 554 o Flexibility: The Seamless MPLS architecture SHALL be applied to a 555 wide variety of existing MPLS deployments. It SHALL use a 556 flexible approach deploying building blocks with the possiblity to 557 use certain features only if those features are needed (e.g. dual 558 homing ANs or fast reroute mechanisms). 560 o Service independence: Service and transport layer SHALL be 561 decoupled. The architecture SHALL remove the need for service 562 specific configurations on intermediate nodes. 564 o Native Multicast support: P2MP MPLS LSPs SHOULD be supported by 565 the Seamless MPLS architecture. 567 o Interoperable end to end OAM mechanisms SHALL be implemented 569 3.1. Overall 571 3.1.1. Access 573 In respect of MPLS functionality the access network should be kept as 574 simple as possible. Compared to the aggregation and/or core network 575 within Seamless MPLS a typical access node is less powerful. The 576 control plane and the forwarding should be as simple as possible. To 577 reduce the complexity and the costs of an access node not the full 578 MPLS functionality need to be supported (control and data plane). 579 The use of an IGP should be avoided. Static routing should be 580 sufficient. Required functionality to reach the required scalability 581 should be moved out of the access node. The number of access nodes 582 can be very high. The support of load balancing for layer 2 services 583 should be implemented. 585 3.1.2. Aggregation 587 The aggregation network aggregates traffic from access nodes. The 588 aggregation Node must have functionalities that enlarge the 589 scalability of the simple access nodes that are connected. The IGP 590 must be link state based. Each aggregation area must be a separated 591 area. All routes that are interarea should use an EGP to keep the 592 IGP small. The aggregation node must have the full scalability 593 concerning control plane and forwarding. The support of load 594 balancing for layer 2 services must be implemented. 596 3.1.3. Core 598 The core connects the aggregation areas. The core network elements 599 must have the full scalability concerning control plane and 600 forwarding. The IGP must be link state based. The core area must 601 not include routes from aggregation areas. All routes that are 602 interarea should use an EGP to keep the IGP small. Each area of the 603 link state based IGP should have less than 2000 routes. The support 604 of load balancing for layer 2 services must be implemented. 606 3.2. Multicast 608 Compared with unicast connectivity Multicast is more dynamic. User 609 generated messages - like joining or leaving multicast groups - are 610 interacting directly with network components in the access and 611 aggregation network (in order to build the corresponding forwarding 612 states). This leads to the need for a highly dynamic handling of 613 messages on access and aggregation nodes. Nevertheless the core 614 network SHOULD be stable and state changes triggered by user 615 generated messages SHOULD be minimized. This rises the need for an 616 hierarchy for the P2MP support in Seamless MPLS hiding the dynamic 617 behaviour of the access and aggregation nodes 619 o mLDP 621 o P2MP RSVP-TE 623 3.3. Availability 625 All network elements should be high available (99.999% availability). 626 Outage times should be as low as possible. A repair time of 50 627 milliseconds or less should be guarantied at all nodes and lines in 628 the network that are redundant. Fast convergence features SHOULD be 629 used in all control plane protocols. Local Repair functions SHOULD 630 be used wherever possible. Full redundancy is required at all 631 equipment that is shared in a network element. 633 o Power Supply 635 o Switch Fabric 637 o Routing Processor 639 A change from an active component to a standby component SHOULD 640 happen without effecting customers traffic. The Influence of 641 customer traffic MUST be as low as possible. 643 3.4. Scalability 645 The network must be highly scalable. Based on the use cases 646 described in Sections 2.2 and 2.3, as a minimum requirement the 647 following scalability figures should be met: 649 o Number of aggregation domains: 100 651 o Number of backbone nodes: 1,000 653 o Number of aggregation nodes: 10,000 655 o Number of access nodes: 100,000 657 3.5. Stability 659 o The platform should be stable under certain circumstances (e.g. 660 missconfiguration within one area should not cause instability in 661 other areas). 663 o Differentiate between "All Loopbacks and Link addresses should be 664 ping able from every where." Vs. "Link addresses are not 665 necessary ping able from everywhere". 667 4. Architecture 669 4.1. Overall 671 One of the key questions that emerge when designing an architecture 672 for a seamless MPLS network is how to handle the sheer size of the 673 necessary routing and MPLS label information control plane and 674 forwarding plane state resulting from the stated scalability goals 675 especially with respect to the total number of access nodes. This 676 needs to be done without overwhelming the technical scaling limits of 677 any of the involved nodes in the network (access, aggregation and 678 core) and without introducing too much complexity in the design of 679 the network while at the same time still maintaining good convergence 680 properties to allow for quick MPLS transport and service restoration 681 in case of network failures. 683 4.2. Multi-Domain MPLS networks 685 The key design paradigm that leads to a sound and scalable solution 686 is the divide and conquer approach, whereby the large problem is 687 decomposed into many smaller problems for which the solution can be 688 found using well-known standard architectures. 690 In the specific case of seamless MPLS the overall MPLS network SHOULD 691 be decomposed into multiple MPLS domains, each well within the 692 scaling limits of well-known architectures and network node 693 implementations. From an organizational and operational point of 694 view it MAY make sense to define the boundaries of such domains along 695 the pre-existing boundaries of aggregation networks and the core 696 network. 698 Examples of how networks can be decomposed include using IGP areas as 699 well as using multiple BGP autonomous systems. 701 4.3. Hierarchy 703 These MPLS domains SHOULD then be then be connected into an MPLS 704 multi-domain network in a hierarchical fashion that enables the 705 seamless exchange of loopback addresses and MPLS label bindings for 706 transport LSPs across the entire MPLS internetwork while at the same 707 time preventing the flooding of unnecessary routing and label binding 708 information into domains or parts of the network that do not need 709 them. Such a hierarchical routing and forwarding concept allows a 710 scalability in different dimensions and allows to hide the complexity 711 and size of the aggregation and access networks. 713 4.4. Intra-Domain Routing 715 The intra-domain routing within each of the MPLS domains (i.e. 716 aggregation domains and core) SHOULD utilize standard IGP protocols 717 like OSPF or ISIS. By definition, each of these domains is small 718 enough so that there are no relevant scaling limits within each IGP 719 domain, given well-known state-of-the-art IGP design principles and 720 recent router technology. 722 The intra-domain MPLS LSP setup and label distribution SHOULD utilize 723 standard protocols like LDP or RSVP. 725 Note that this document describes the design based on LDP, LDP 726 Downstream-on-Demand and labeled BGP due to the higher degree of out- 727 of-the-box automation and operational simplicity as well as 728 compatibility with the existing backbone and backhaul designs & 729 deployments which use LDP and not RSVP-TE. It also assumes 730 relatively simple MPLS implementations on access nodes. The protocol 731 choices for the design described in this document have been driven by 732 the actual SP deployments. Design based on the hierarchy of RSVP-TE 733 LSPs may be an alternative, but has not been considered in this 734 document. 736 4.5. Inter-Domain Routing 738 The inter-domain routing is responsible for establishing connectivity 739 between and across all MPLS domains. The inter-domain routing SHOULD 740 establish a routing and forwarding hierarchy in order to achieve the 741 scaling goals of seamless MPLS. Note that the IP aggregation usually 742 performed between region (IGP areas/AS) in IP routing does not work 743 for MPLS as MPLS is not capable of aggregating FEC (because MPLS 744 forwarding use an exact match lookup, while IP uses longest match). 746 Therefore it is RECOMMENDED to utilize protocols that support 747 indirect next-hops ( e.g. using BGP to carry MPLS label information 748 [RFC3107] ). The mechanism for the LSP forwarding hierarchy is 749 described in Section 5.3. 751 4.6. Access 753 Compared to the aggregation and core parts of the Seamless MPLS 754 network the access part is special in two respects: 756 o The number of nodes in the access is at least one order of 757 magnitude higher than in any other part of the network. 759 o Because of the large quantity of access nodes, the cost of these 760 nodes is extremely relevant for the overall costs of the entire 761 network, i.e. acess nodes are very cost sensitive. 763 This makes it desirable to design the architecture such that the AN 764 functionality can be kept as simple as possible. This should always 765 be kept in mind when evaluating different seamless MPLS 766 architectures. The goal is to limit both the number of different 767 protocols needed on the AN as well as the scale to which each 768 protocol must perform to the absolute minimum. 770 4.7. Signalling and Label Distribution 772 Following figures show IP/MPLS signaling and label distribution for 773 an LSP from AN2 to AN1 (192.0.2.1), detailing the signalling from AN1 774 to AN2 (left to right) and packet forwarding from AN2 to AN1 (right 775 to left). It is assumed that Penultimate Hop Popping is used. 777 Terminology used in the figures: 779 o LDP DoD: LDP Downstream on Demand 781 o LDP DU: LDP Downstream Unsolicited 783 o BGP LU: BGP Label Unicast (RFC 3107) 784 o BGP NH: BGP Next Hop Label LYZi: L=Label, Y= node advertising the 785 FEC (G for AGN, B for ABR, A for AN), Z= protocol advertising it 786 (B for BGP, L for LDP) 788 --------------------------------------------------------------------- 790 AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2 792 LDP DoD -> BGP LU -> BGP LU -> LDP DoD 793 Next Hop Self 795 192.0.2.1 192.0.2.1 192.0.2.1 192.0.2.1 796 Labels: LAL1 LAB1 LAB2 LAL2 797 BGP NH: AGN1 BGP NH: ABR1 799 Figure 5: MPLS signalling for the AN / edge layer 801 --------------------------------------------------------------------- 803 AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2 805 | IS-IS level 2 | IS-IS level 1 -> IS-IS level 2 | 806 | LDPDU - LDPDU - LDPDU - LDPDU - LDPDU - LDPDU | 808 FEC: AGN1 ABR1 ABR1 809 Label: LGL1 LGL2 LBL1 LBL2 LBL3 LBL4 811 Figure 6: MPLS signalling and IP routing for the core layer 813 --------------------------------------------------------------------- 815 Static | IS-IS level 2 | IS-IS level 1 | IS-IS level 2 | Static 816 Routing Routing 818 192.0.2.1 -> 192.0.2/24 -> 192.0.2/20 -> 192.2/20 0/0 819 AGN1 ABR1 ABR1 821 Figure 7: IP routing for the AN / edge layer 823 --------------------------------------------------------------------- 825 AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2 827 FEC AN1: LAL1 LAB1 LAB2 LAB2 LAB2 LAB2 LAL2 828 FEC AGN1: LGL2 LBL1 LBL2 LBL3 LBL4 829 /ABR1 831 Figure 8: Forwarding Plane 833 --------------------------------------------------------------------- 835 5. Deployment Scenarios 837 This section describes the deployment scenarios based on the use 838 cases and the generic architecture above. 840 5.1. Deployment Scenario #1 842 Section describing the Seamless MPLS implementation of a large 843 european ISP. 845 5.1.1. Overview 847 This deployment scenario describes one way to implement a seamless 848 MPLS architecture. Specific to this implementation is the choice of 849 intra- and inter-domain routing and label distribution protocols, as 850 well as the details of the interworking of these protocols to achieve 851 the overall scalable hierarchical architecture. 853 5.1.2. General Network Topology 855 There are multiple aggregation domains (in the order of up to 100) 856 connected to the core in a star topology, i.e. aggregation domains 857 are never connected among themselves, but only to the core. The core 858 has its own domain. 860 +-------+ +-------+ +------+ +------+ 861 | | | | | | | | 862 +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN 863 / | | /| | | | | | 864 +----+/ +-------+\/ +-------+ +------+ /+------+ 865 | AN | /\ \/ | 866 +----+\ +-------+ \+-------+ +------+/\ +------+ 867 \ | | | | | | \| | 868 +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN 869 | | | | | | | | 870 +-------+ +-------+ +------+ +------+ 872 static route ISIS L1 LDP DU ISIS L2 LDP DU 874 <-Access-><--Aggregation Domain--><---------Core---------> 876 Figure 9: Deployment Scenario #1 878 As shown in Figure 9, the access nodes (AN) are connected to the 879 aggregation network via aggregation nodes called AGN1x, either to a 880 single AGN1x or redundantly to two AGN1x. Each AGN1x has redundant 881 uplinks to a pair of second-level aggregation nodes called AGN2x. 883 Each aggregation domain is connected to the core via exactly two 884 border routers (ABR) on the core side. There can be multiple AGN2 885 pairs per aggregation domain, but only one ABR pair for each 886 aggregation domain. Each of the AGN2 in an AGN2 pair connects to one 887 of the ABRs in the ABR pair responsible for that aggregation domain. 889 The ABRs on the core side have redundant connections to a pair of LSR 890 routers. 892 The LSR pair is also connected via a direct link. 894 The core LSR are connected to other core LSR in a partly meshed 895 topology so that there are disjunct, redundant paths from each LSR to 896 each other LSR. 898 5.1.3. Hierarchy based on recursive BGP labeled route lookup 900 Inline with the explanation in section 4.5, LSP hierarchy is key to a 901 scalable seamless MPLS architecture. 903 The LSP hierarchy in this design is achieved by: 905 o Forming separate MPLS domains for aggregation and core areas. 907 o Intra-domain LSP connectivity provided by combination of IS-IS (as 908 the intra-domain link-state routing protocol) and LDP DU (used for 909 MPLS label distribution for intra-domain LSPs). 911 o Inter-domain LSP connectivity provided by labeled BGP [RFC3107] 912 (used for MPLS label distribution for inter-domain LSP FECs) and 913 relying on IS-IS and LDP DU for intra-domain LSP connectivity 914 between the LSR labeled BGP speakers (AGNs and ABRs). Note that 915 the MPLS core notes are not carrying the labeled BGP routes. 917 The aggregation and core MPLS domains are mapped to IS-IS areas as 918 follows: Aggregation domains are mapped to IS-IS L1 areas. The core 919 is configured as IS-IS L2. The border routers connecting aggregation 920 and core are IS-IS L1L2 and are referred to as ABRs. From a 921 technical and operational point of view these ABRs are part of the 922 core, although they also belong to the respective aggregation domain 923 purely from a routing protocol point of view. 925 5.1.4. Intra-Area Routing 927 5.1.4.1. Core 929 The core uses ISIS L2 to distribute routing information for the 930 loopback addresses of all core nodes. The border routers (ABR) that 931 connect to the aggregation domains are also part of the respective 932 aggregation ISIS L1 area and hence ISIS L1L2. 934 LDP DU is used to distribute MPLS label binding information for the 935 loopback addresses of all core nodes. 937 5.1.4.2. Aggregation 939 The aggregation domains uses ISIS L1 as intra-domain routing 940 protocol. All AGN loopback addresses are carried in ISIS. 942 As in the core, the aggregation also uses LDP DU to distribute MPLS 943 label bindings for the loopback addresses. 945 5.1.5. Access 947 Access nodes do not have their own domain or IGP area. Instead, they 948 directly connect to the AGN1 nodes in the aggregation domain. To 949 keep access devices as simple as possible, ANs do not participate in 950 ISIS. 952 Instead, each AN has two static default routes pointing to each of 953 the AGN1 it is connected to. Appropriate techniques SHOULD be 954 deployed to make sure that a given default route is invalidated when 955 the link to an AGN1 or that node itself fails. Examples of such 956 techniques include monitoring the pysical link state for loss of 957 light/loss of frame, or using Ethernet link OAM or BFD [RFC5881]. 959 The AGN1 MUST have a configured static route to the loopback address 960 of each of the ANs it is connected to, because it cannot learn the AN 961 loopback address in any other way. These static routes have to be 962 monitored and invalidated if necessary using the same techniques as 963 described above for the static default routes on the AN. 965 The AGN1 redistributes these routes into ISIS for intra-domain 966 reachability of all AN loopback addresses. 968 LDP DU is used for MPLS label distribution between AGN1 and AN. In 969 order to keep the AN control plane as lightweight as possible, and to 970 avoid the necessity for the AN to store 100.000 MPLS label bindings 971 for each upstream AGN1 peer, LDP is deployed in downstream-on-demand 972 (DoD) mode, described below. 974 To allow the label bindings received via LDP DoD to be installed into 975 the LFIB on the AN without having the specific host route to the 976 destination loopback address, but only a default route, use of the 977 LDP Extension for Inter-Area Label Switched Paths [RFC5283] is made. 979 5.1.5.1. LDP Downstream-on-Demand (DoD) 981 LDP downstream-on-demand mode is specified in [RFC5036]. In this 982 mode the upstream LSR will explicitly ask the downstream LSR for a 983 label binding for a particular FEC when needed. 985 The assumption is that a given AN will only have a limited number of 986 services configured to an even more limited number of destinations, 987 or egress LER. Instead of learning and storing all label bindings 988 for all possible loopback addresses within the entire Seamless MPLS 989 network, the AN will use LDP DoD to only request the label bindings 990 for the FECs corresponding to the loopback addresses of those egress 991 nodes to which it has services configured. 993 More detailed description of LDP DoD use cases for MPLS access and 994 list of required LDP DoD procedures in the context of Seamless MPLS 995 design is included in [RFC7032]. 997 5.1.6. Inter-Area Routing 999 The inter-domain MPLS connectivity from the aggregation domains to 1000 and across the core domain is realized primarily using BGP with MPLS 1001 labels ("labled BGP/SAFI4" [RFC3107]). A very limited amount of 1002 route leaking from ISIS L2 into L1 is also used. 1004 All ABR and PE nodes in the core are part of the labeled iBGP mesh, 1005 which can be either full mesh or based on route reflectors. These 1006 nodes advertise their respective loopback addresses (which are also 1007 carried in ISIS L2) into labeled BGP. 1009 Each ABR node has labeled iBGP sessions with all AGN1 nodes inside 1010 the aggregation domain that they connect to the core. Since there 1011 are two ABR nodes per aggregation domain, this leads to each AGN1 1012 node having an iBGP sessions with each of the two ABR. Note that the 1013 use of iBGP implies that the entire seamless MPLS internetwork is 1014 just a single AS to which all core and aggregation nodes belong. The 1015 AGN1 nodes advertise their own loopback addresses into labeled BGP, 1016 in addition to these loopbacks also being in ISIS L1. 1018 Additionally the AGN1 nodes also redistribute all the statically 1019 configured routes to the AN loopback addresses into labeled BGP. 1020 Note that as stated obove, the AGN1 MUST ask the AN for label 1021 bindings for the AN loopback FECs via LDP DoD in order to have a 1022 valid labeled route with a non-null label. 1024 This architecture results in carrying all loopbacks of all nodes 1025 except pure P nodes (AN, AGN, ABR and core PE) in labeled BGP, e.g. 1026 there will be in the order of 100.000 routes in labeled BGP when 1027 approaching the stated scalability goal. Note that this only affects 1028 the BGP RIB size and does not necessarily imply that any node needs 1029 to actually have active forwarding state (LFIB) in the same order of 1030 magnitude. In fact, as will be discussed in the scalability 1031 analysis, no single node needs to install all labeled BGP routes into 1032 the LFIB, but each node only needs a small percentage of the RIB as 1033 active forwarding state in the LFIB. And from a RIB point of view, 1034 BGP is known to scale to hundreds of thousands of routes. 1036 5.1.7. Labeled iBGP next-hop handling 1038 The ABR nodes run labeled iBGP both to the core mesh as well as to 1039 the AGN1 nodes of their respective aggregation domains. Therefore 1040 they operate as iBGP route reflectors, reflecting labeled routes from 1041 the aggregation into the core and vice versa. 1043 When reflecting routes from the core into the aggregation domain, the 1044 ABR SHOULD NOT change the BGP NEXT-HOP addresses (next-hop- 1045 unchanged). This is the usual behaviour for iBGP route reflection. 1046 In order to make these routes resolvable to the AGN1 nodes inside the 1047 aggregation domain, the ABR MUST leak all other ABR and core PE 1048 loopback addresses from ISIS L2 into ISIS L1 of the aggregation 1049 domain. Note that the number of leaked addresses is limited so that 1050 the overall scalability of the seamless MPLS architecture is not 1051 impacted. In the worst case all core loopback addresses COULD be 1052 leaked into ISIS L1, but even that would not be a scalability 1053 problem. 1055 When reflecting routes from the aggregation into the core, the ABR 1056 MUST set then BGP NEXT-HOP to its own loopback addresses (next-hop- 1057 self). This is not the default behaviour for iBGP route reflection, 1058 but requires special configuration on the ABR. Note that this also 1059 implies that the ABR MUST allocate a new local MPLS label for each 1060 labeled iBGP FEC that it reflects from the aggregation into the core. 1061 This special next-hop handling is essential for the scalability of 1062 the overall seamless MPLS architecture since it creates the required 1063 hierarchy and enables the hiding of all aggregation and access 1064 addresses behind the ABRs from an IGP point of view. Leaking of 1065 aggregation ISIS L1 loopback addresses into ISIS L2 is not necessary 1066 and MUST NOT be allowed. 1068 The resulting hierarchical inter-domain MPLS routing structure is 1069 similar to the one described in [RFC4364] section 10c, only that we 1070 use one AS with route reflection instead of using multiple ASes. 1072 5.1.8. Network Availability 1074 The seamless mpls architecture guarantees a sub-second loss of 1075 connectivity upon any link or node failures. Furthermore, in the 1076 vast majority of cases, the loss of connectivity is limited to sub- 1077 50msec. 1079 These network availability properties are provided without any 1080 degradation on scale and simplicity. This is a key achievement of 1081 the design. 1083 In the remainder of this section, we first introduce the different 1084 network availability technologies and then review their applicability 1085 for each possible failure scenario. 1087 5.1.8.1. IGP Convergence 1089 IGP convergence can be modelled as a linear process with an initial 1090 delay and a linear FIB update [ACM01]. 1092 The initial delay could conservatively be assumed to be 260msec: 1093 50msec to detect failures with BFD (most failures would be detected 1094 faster with loss of light for example or with faster BFD timers), 1095 50msec to throttle the LSP generation, 150msec to throttle the SPF 1096 computation (making sure than all the required LSP's are received 1097 even in case of SRLG failures) and 10msec for shortest-path-first 1098 tree computation. 1100 Assuming 250usec per update (conservative), this allows for 1101 (1000-260)/0.250= 2960 prefixes update within a second following the 1102 outage. More precisely, this allows for 2960 important IGP prefixes 1103 updates. Important prefixes are automatically classified by the 1104 router implementation through simple heuristic (/32 is more important 1105 than non-/32). 1107 The number of IGP important routes (loopbacks) in deployment case 1108 study 1 is much smaller than 2960, and hence sub-second IGP 1109 convergence is conservative. 1111 IGP convergence is a simple technology for the operator provided that 1112 the router vendor optimizes the default IGP behavior (no need to tune 1113 any arcane knob). 1115 5.1.8.2. Per-Prefix LFA FRR 1117 A per-prefix LFA for a destination D is a precomputed backup IGP 1118 nexthop for that destination. This backup IGP nexthop can be link 1119 protecting or node protecting [RFC5286]. 1121 The analysis of the applicability of Per-Prefix LFA in the deployment 1122 model 1 of Seamless MPLS architecture is straightforward thanks to 1123 [RFC6571]. 1125 In deployment model 1, each aggregation network either follows the 1126 triangle or full-mesh topology. Further more, the backbone region 1127 implements a dual-plane. As a consequence, the failure of any link 1128 or node within an aggregation domain is protected by LFA FRR (sub- 1129 50msec) for all impacted IGP prefixes, whether intra-area or inter- 1130 area. No uloop may form as a result of these failures [RFC6571]. 1132 Per-Prefix LFA FRR is generally assessed as a simple technology for 1133 the operator [RFC6571]. It certainly is in the context of deployment 1134 case study 1 as the designer enforced triangle and full-mesh 1135 topologies in the aggregation network as well as a dual-plane core 1136 network. 1138 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent Convergence 1140 In a hierarchical dataplane, the FIB used by the packet processing 1141 engine reflects recursions between the routes. For example, a BGP 1142 route B recursing on IGP route I whose best path is via interface O 1143 is encoded as a hierarchy of FIB entry B pointing to a FIB entry I 1144 pointing to a FIB entry 0. 1146 BGP Prefix Independent Convergence [I-D.rtgwg-bgp-pic] extends the 1147 hierarchical dataplane with the concept of a BGP Path-List. A BGP 1148 path-list may be abstracted as a set of primary multipath nhops and a 1149 backup nhop. When the primary set is empty, packets destined to the 1150 BGP destinations are rerouted via the backup nhop. 1152 For complete description of BGP-PIC technology and its applicability 1153 please refer to [I-D.rtgwg-bgp-pic] and [ABR-FRR]. 1155 Hierarchical data plane and BGP-PIC are very simple technologies to 1156 operate. Their applicability to any topology, any routing policy and 1157 any BGP unicast address family allows router vendors to enable this 1158 behavior by default. 1160 5.1.8.4. BGP Egress Node FRR 1162 BGP egress node FRR is a Fast ReRoute solution and hence relies on 1163 local protection and the precomputation and preinstallation of the 1164 backup path in the FIB. BGP egress node FRR relies on a transit LSR 1165 ( Point of Local Repair, PLR ) adjacent to the failed protected BGP 1166 router to detect the failure and re-route the traffic to the backup 1167 BGP router. Number of BGP egress node FRR schemes are being 1168 investigated: [PE-FRR], [ABR-FRR], 1169 [I-D.minto-2547-egress-node-fast-protection], 1170 [I-D.bashandy-bgp-edge-node-frr], 1171 [I-D.bashandy-idr-bgp-repair-label], [I-D.bashandy-mpls-ldp-bgp-frr], 1172 [I-D.bashandy-bgp-frr-mirror-table], 1173 [I-D.bashandy-bgp-frr-vector-label], 1174 [I-D.bashandy-isis-bgp-edge-node-frr]. 1176 Differences between these schemes relate to the way backup and 1177 protected BGP routers get associated, how the protected router's BGP 1178 state is signalled to the backup BGP router(s) and if any other state 1179 is required on protected, backup and PLR routers. The schemes also 1180 differ in compatibility with IP-FRR and TE-FRR schemes to enable PLR 1181 to switch traffic towards the backup BGP router in case of protected 1182 BGP router failure. 1184 In the Seamless MPLS design, BGP egress node FRR schemes can protect 1185 against the failures of PE, AGN and ABR nodes with no requirements on 1186 ingress routers. 1188 5.1.8.5. Assessing loss of connectivity upon any failure 1190 We select two typical traffic flows and analyze the loss of 1191 connectivity (LoC) upon each possible failure in the Seamless MPLS 1192 design in the deployment scenario #1. 1194 o Flow F1 starts from an AN1 in a left aggregation region and ends 1195 on an AN2 in a right aggregation region. Each AN is dual-homed to 1196 two AGN's. 1198 o Flow F2 starts from a CE1 homed on L3VPN PE1 connected to the core 1199 LSRs and ends at CE2 dual-homed to L3VPN PE2 and PE3, both 1200 connected to the core LSRs. 1202 Note that due to the symmetric network topology in case study 1, uni- 1203 directional flows F1' and F2', associated with F1 and F2 and 1204 forwarded in the reversed direction (AN2 to AN1 right-to-left and PE2 1205 to PE1, respectively), take advantage of the same failure restoration 1206 mechanisms as F1 and F2. 1208 5.1.8.5.1. AN1-AGN link failure or AGN node failure 1210 F1 is impacted but LoC <50msec is possible assuming fast BFD 1211 detection and fast-switchover implementation on the AN. F2 is not 1212 impacted. 1214 5.1.8.5.2. Link or node failure within the left aggregation region 1216 F1 is impacted but LoC <50msec thanks to LFA FRR. No uloop will 1217 occur during the IGP convergence following the LFA protection. Note: 1218 if LFA is not available (other topology then case study one) or if 1219 LFA is not enabled, then the LoC would be < second as the number of 1220 impacted important IGP route in a seamless architecture is much 1221 smaller than 2960. 1223 F2 is not impacted. 1225 5.1.8.5.3. ABR node failure between left region and the core 1227 F1 is impacted but LoC <50msec thanks to LFA FRR. No uloop will 1228 occur during the IGP convergence following the LFA protection. 1230 Note: This case is also called "Local ABR failure" as the ABR which 1231 fails is the one connected to the aggregation region at the source of 1232 flow F1. 1234 Note: remember that the left region receives the routes to all the 1235 remote ABR's and that the labelled BGP routes are reflected from the 1236 core to the left region with next-hop unchanged. This ensures that 1237 the loss of the (local) ABR between the left region and the core is 1238 seen as an IGP route impact and hence can be addressed by LFA. 1240 Note: if LFA is not available (other topology then case study one) or 1241 if LFA is not enabled, then the LoC would be < second as the number 1242 of impacted important IGP routes in a seamless architecture is much 1243 smaller than 2960 routes. 1245 F2 is not impacted. 1247 5.1.8.5.4. Link or node failure within the core region 1249 F1 and F2 are impacted but LoC <50msec thanks to LFA FRR. 1251 This is specific to the particular core topology used in deployment 1252 case study 1. The core topology has been optimized [RFC6571] for LFA 1253 applicability. 1255 As explained in [RFC6571], another alternative to provide <50msec in 1256 this case consists in using an MPLS-TE full-mesh and MPLS-TE FRR. 1257 This is required when the designer is not able or does not want to 1258 optimize the topology for LFA applicability and he wants to achieve 1259 <50msec protection. 1261 Alternatively, simple IGP convergence would ensure a LoC < second as 1262 the number of impacted important IGP routes in a seamless 1263 architecture is much smaller than 2960 routes. 1265 5.1.8.5.5. PE2 failure 1267 F1 is not impacted. 1269 F2 is impacted and the LoC is sub-300msec thanks to IGP convergence 1270 and BGP PIC. 1272 The detection of the primary nhop failure (PE2 down) is performed by 1273 a single-area IGP convergence. 1275 In this specific case, the convergence should be much faster than 1276 90% of the IGP/BGP3107 footprint at least). 1403 If the guidelines cannot be met, then either the designer will rely 1404 on (1) augmenting native LFA coverage with remote LFA 1405 [I-D.ietf-rtgwg-remote-lfa], or (2) augmenting native LFA coverage 1406 with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP convergence. 1407 The first option provides an automatic and fairly simple sub-50msec 1408 protection as LFA without introducing any additional protocols. The 1409 second option provides the same sub-50msec protection as LFA, but 1410 introduces additional RSVP LSPs. The thrid option optimizes for sub- 1411 50msec protection, but implies a more complex operational model. The 1412 fourth option optimizes for simple operation but only provides <1 sec 1413 protection. Up to each designer to arbitrate between these three 1414 options versus the possibility to engineer the topology for native 1415 LFA protection. 1417 A similar choice involves protection against ABR node failure and 1418 L3VPN PE node failure. The designer can either use BGP PIC or BGP 1419 egress node FRR. Up to each designer to asssess the trade-off 1420 between the valuation of sub-50msec instead of sub-1sec versus 1421 additional operational considerations related to BGP egress node FRR. 1423 5.1.8.7. Conclusion 1425 The Seamless MPLS architecture illustrated in deployment case study 1 1426 guarantees sub-50msec for majority of link and node failures by using 1427 LFA FRR, except ABR and L3PE node failures, and PE-CE link failure. 1429 L3VPN PE-CE link failure can be protected with sub-50msec 1430 restoration, by using hierarchical data plane and local-repair fast- 1431 reroute to the backup BGP nhop PE. 1433 ABR and L3PE node failure can be protected with sub-50msec 1434 restoration, by using BGP egress node FRR. 1436 Alternatively, ABR and L3PE node failure can be protected with sub- 1437 1sec restoration using BGP PIC. 1439 5.1.9. BGP Next-Hop Redundancy 1441 An aggregation domain is connected to the core network using two 1442 redundant area boarder routers, and MPLS hierarchy is applied on 1443 these ABRs. MPLS hierarchy helps scale the FIB but introduces 1444 additional complexity for the rerouting in case of ABR failure. 1445 Indeed ABR failure requires a BGP converge to update the inner MPLS 1446 hierarchy, in addition to the IGP converge to update the outer MPLS 1447 hierarchy. This is also expected to take more time as BGP 1448 convergence is performed after the IGP convergence and because the 1449 number of prefixes to update in the FIB can be significant. This is 1450 clearly a drawback, but the architecture allows for two "local 1451 protection" solutions which restore the traffic before the BGP 1452 convergence takes place. 1454 BGP PIC would be required on all edge LSR involved in the inner (BGP) 1455 MPLS hierarchy. Namely all routers except the AN which are not 1456 involved in the inner MPLS hierarchy. It involves pre-computing and 1457 pre-installing in the FIB the BGP backup path. Such back up path are 1458 activated when the IGP advertise the failure of the primary path. 1459 For specification see [BGP-PIC1, 2##]. 1461 BGP egress node FRR would be required on the egress LSR involved in 1462 the inner (BGP) MPLS hierarchy, namely AGN, ABR and L3VPN PEs. For 1463 specification see [PE-FRR], [ABR-FRR], [BGP-edge-FRR##]. 1465 Both approaches have their pros and cons, and the choice is left to 1466 each Service Provider or deployment based on the different 1467 requirements. The key point is that the seamless MPLS architecture 1468 can handle fast restoration time, even for ABR failures. 1470 5.2. Scalability Analysis 1472 5.2.1. Control and Data Plane State for Deployment Scenarios 1474 5.2.1.1. Introduction 1476 Let's call: 1478 o #AN the number of Access Node (AN) in the seamless MPLS domain 1480 o #AGN the number of AGgregation Node (AGN) in the seamless MPLS 1481 domain 1483 o #Core the number of Core (Core) in the core network 1485 o #Area the number of aggregation routing domains. 1487 Let's take the following assumptions: 1489 o Aggregation equipments are equally spread across aggregation 1490 routing domains 1492 o the number of IGP links is three times the number of IGP nodes 1494 o the number of IGP prefixes is five times the number of IGP nodes 1495 (links prefixes + 2 loopbacks) 1497 o Each Access Node needs to have up to 1,000 (1k) LSPs. LSP scale 1498 requirement is driven by expected AN access line capacity and the 1499 sum of LSPs required for connectivity to PE routers providing edge 1500 services as well as a remote ANs. Number and type of services 1501 accessed by the AN has also an impact. Hence it is very service 1502 specific. Note that if the number of remote PE/LSPs is higher 1503 than the capacity of the AN, some route aggregation scheme can be 1504 enabled at the service layer, e.g. using RFC7024 for IP VPN. It 1505 is assumed that 100 LSPs per AN (10% of total) are FECs that are 1506 outside of their routing domain. Those 100 remote FEC are the 1507 same for all Access Nodes of a given AGN. 1509 The following sections roughly evaluate the scalability, both in 1510 absolute numbers and relatively with the number of Access Node which 1511 is the biggest scalability factor. 1513 5.2.1.2. Core Domain 1515 The IGP & LDP core domain are not affected by the number of access 1516 nodes: 1518 IGP: 1520 node : #Core ~ o(1) 1522 links : 3*#Core ~ o(1) 1524 IP prefixes : 5*#Core + #Area ~ o(1) 1526 LDP FEC: 1528 #Core ~ o(1) 1530 Core TN FIBs grows linearly with the number of node in the core 1531 domain. In other word, they are not affected by AGN and AN nodes: 1533 Core TN: 1535 IP FIB : 5*#Core + #Area ~ o(1) 1537 MPLS ILM (LFIB) : #Core ~ o(1) 1539 BGP carries all AN routes which is significant. However, all AN 1540 routes are only needed in the control plane, possibly in a dedicated 1541 BGP Route Reflector (just like for BGP/MPLS VPNs) and not in the 1542 forwarding plane. The number of routes (100k) is smaller than the 1543 number of number of routes in the Internet (300k and rising) or in 1544 major VPN SP (>500k and rising) so the target can be handled with 1545 current implementations. In addition, AN routes are internal routes 1546 whose churn and instability is smaller and more under control than 1547 external routes. 1549 BGP Route Reflector (RR) 1551 NLRI : #AN ~ o(n) 1553 path : 2*#AN ~ o(2n) 1555 ABR handles both the core and aggregations routes. They do not 1556 depend on the total number of AN nodes, but only on the number of AN 1557 in their aggregation domain. 1559 ABR: 1561 IP FIB : 5*#Core + (5*#AGN + #AN) / #Area + #Area ~ 1562 o(#AN/#Area) 1564 MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) 1566 5.2.1.3. Aggregation Domain 1568 In the aggregation domain, IGP & LDP are not affected by the number 1569 of access nodes outside of their domain. They are not affected by 1570 the total number of AN nodes: 1572 IGP: 1574 node : #AGN / #Area ~ o(1) 1576 links : 3*#AGN / #Area ~ o(1) 1578 IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN 1579 *5/ #Area) 1580 + plus one aggregate per area (because the number of IP 1581 prefixes is equal to 1 loopback per core node), plus 5 1582 prefixes per AGN in the area, plus 1 prefix per AN in the 1583 area. 1585 LDP FEC: 1587 Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) 1589 + plus one aggregate per area (because the number of IP 1590 prefixes is equal to 1 loopback per core node), plus 5 1591 prefixes per AGN in the area, plus 1 prefix per AN in the 1592 area. 1594 AGN FIBs grows with the number of node in the core area, in their 1595 aggregation area, plus the number of inter domain LSP required by the 1596 AN attached to them. They do not depend on the total number of AN 1597 nodes. In the BGP control plane, AGN also needs to handle all the AN 1598 routes. 1600 AGN: 1602 IP FIB : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5/ 1603 #Area) 1605 MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area + 100 ~ o(#AN / 1606 #Area) 1608 AN FIBs grow with the connectivity requirement of the services. They 1609 do not depend on the number of AN, AGN, SN or any others nodes. 1611 AN: 1613 IP RIB : 1 ~ o(1) 1615 MPLS LIB : 1k ~ o(1) 1617 IP FIB : 1 ~ o(1) 1619 MPLS ILM : 1k ~ o(1) if the AN is used in transit by other ANs 1620 and hence is an LSR (use case #2 having chained AN) 1622 MPLS ILM : 0 ~ o(1) if the AN is not providing transit to 1623 others ANs (use case #1 where AN are final leaf) 1625 MPLS NHLFE : 1k ~ o(1) 1627 5.2.1.4. Summary 1629 AN requirements are kept to a minimum. BGP is not required on ANs 1630 and the size of their FIB is driven only by their own connectivity 1631 requirements. In the FIB scale analysis described in sections 1632 5.2.1.x, it was assumed that any single AN will need no more than 1633 1,000 LSPs. This assumption is based on the expected AN access line 1634 capacity and LSPs required for connectivity to PE routers providing 1635 edge services as well as a sparse mesh of connectivity between ANs. 1637 In the core area, IGP and LDP are not affected by the nodes in the 1638 aggregation domains. In particular they do not grow with the number 1639 of AGNs or ANs. 1641 In the aggregation areas, IGP and LDP are affected by the number of 1642 core nodes and the number of AGNs and ANs in their area. They are 1643 not affected by the total number of AGNs or ANs in the seamless MPLS 1644 domain. 1646 No FIB of any node is required to handle the total number of AGNs or 1647 ANs in the Seamless MPLS domain. In other words, the number of AGNs 1648 and ANs in the Seamless MPLS domain is not a limiting factor, and the 1649 design can be scaled by growing the number of areas. The main 1650 limitation is the MPLS connectivity requirements on the AN, i.e. 1651 mainly the number of LSP needed per AN. Another limitation may be 1652 the number of different LSPs required by ANs attached to specific 1653 AGN. However, given the foreseen deployments and current AGN 1654 capabilities, this is not expected to be a limiting factor. 1656 In the control plane, BGP will typically handle all AN routes. This 1657 is expected to be substantial, but again the target deployment scale 1658 are well within the capabilities of current equipment . In addition, 1659 if required, additional techniques could be used to improve the 1660 scalability, based on the experience gained with scaling BGP/MPLS VPN 1661 (e.g. route partitioning between RR planes, route filtering (static 1662 or dynamic with ORF or route refresh) between ANs and on AGN to 1663 improve AGN scalability. 1665 5.2.1.5. Numerical application for use case #1 1667 As a recap, targets for deployment scenario 1 are: 1669 o Number of Aggregation Domains 100 1671 o Number of Backbone Nodes 1,000 1673 o Number of AGgregation Nodes 10,000 1674 o Number of Access Nodes 100,000 1676 This gives the following scaling numbers for each category of nodes: 1678 o AN IP FIB 1 1680 o AN MPLS ILM 0 1682 o AN MPLS NHLFE 1,000 1684 o AGN IP FIB 2,600 1686 o AGN MPLS ILM (LFIB) 2,200 1688 o ABR IP FIB 6,600 1690 o ABR MPLS ILM (LFIB) 2,100 1692 o TN IP FIB 5,100 1694 o TN MPLS ILM (LFIB) 1,000 1696 o RR BGP NLRI 100,000 1698 o RR BGP paths 200,000 1700 5.2.1.6. Numerical application for use case #2 1702 As a recap, targets for deployment scenario 1 are: 1704 o Number of Aggregation Domains 30 1706 o Number of Backbone Nodes 150 1708 o Number of AGgregation Nodes 1,500 1710 o Number of Access Nodes 40,000 1712 This gives the following scaling numbers for each category of nodes: 1714 o AN IP FIB 1 1716 o AN MPLS ILM 1,000 1718 o AN MPLS NHLFE 1,000 1720 o AGN IP FIB 1,763 1721 o AGN MPLS ILM 1,633 1723 o ABR IP FIB 2,363 1725 o ABR MPLS ILM 1,533 1727 o TN IP FIB 780 1729 o TN MPLS ILM 150 1731 o RR BGP NLRI 40,000 1733 o RR BGP paths 80,000 1735 6. Acknowledgements 1737 Many people contributed to this document. The authors would like to 1738 thank Wim Henderickx, Robert Raszuk, Thomas Beckhaus, Wilfried Maas, 1739 Roger Wenner, George Swallow, Kireeti Kompella, Yakov Rekhter, Mark 1740 Tinka, Curtis Villamizar and Simon DeLord for their suggestions and 1741 review. 1743 7. IANA Considerations 1745 This memo does not include any requests to IANA. 1747 8. Security Considerations 1749 The Seamless MPLS Architecture is subject to similar security threats 1750 as any MPLS LDP deployment. It is recommended that baseline security 1751 measures are considered as described in Security Framework for MPLS 1752 and GMPLS networks [RFC5920], in the LDP specification RFC5036 1753 [RFC5036] and in [RFC6952]including ensuring authenticity and 1754 integrity of LDP messages, as well as protection against spoofing and 1755 Denial of Service attacks. Some deployments may require increased 1756 measures of network security if a subset of Access Nodes are placed 1757 in locations with lower levels of physical security e.g. street 1758 cabinets ( common practice for VDSL access ). In such cases it is 1759 the responsibility of the system designer to take into account the 1760 physical security measures ( environmental design, mechanical or 1761 electronic access control, intrusion detection ), as well as 1762 monitoring and auditing measures (configuration and Operating System 1763 changes, reloads, routes advertisements ). 1765 Security aspects specific to the MPLS access network based on LDP DoD 1766 in the context of Seamless MPLS design are described in the security 1767 section of [RFC7032]. 1769 9. References 1771 9.1. Normative References 1773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1774 Requirement Levels", BCP 14, RFC 2119, March 1997. 1776 9.2. Informative References 1778 [ABR-FRR] Rekhter, Y., "Local Protection for LSP tail-end node 1779 failure, MPLS World Congress 2009", . 1781 [ACM01] Francois, P., Filsfils, C., Evans, J., and O. Bonaventure, 1782 "Archiving sub-second IGP convergence in large IP 1783 networks, ACM SIGCOMM Computer Communication Review, v.35 1784 n.3", July 2005. 1786 [I-D.bashandy-bgp-edge-node-frr] 1787 Bashandy, A., Pithawala, B., and K. Patel, "Scalable BGP 1788 FRR Protection against Edge Node Failure", draft-bashandy- 1789 bgp-edge-node-frr-03 (work in progress), July 2012. 1791 [I-D.bashandy-bgp-frr-mirror-table] 1792 Bashandy, A., Konstantynowicz, M., and N. Kumar, "BGP FRR 1793 Protection against Edge Node Failure Using Table Mirroring 1794 with Context Labels", draft-bashandy-bgp-frr-mirror- 1795 table-00 (work in progress), October 2012. 1797 [I-D.bashandy-bgp-frr-vector-label] 1798 Bashandy, A., Kumar, N., and M. Konstantynowicz, "BGP FRR 1799 Protection against Edge Node Failure Using Vector Labels", 1800 draft-bashandy-bgp-frr-vector-label-00 (work in progress), 1801 July 2012. 1803 [I-D.bashandy-idr-bgp-repair-label] 1804 Bashandy, A., Pithawala, B., and J. Heitz, "Scalable, 1805 Loop-Free BGP FRR using Repair Label", draft-bashandy-idr- 1806 bgp-repair-label-04 (work in progress), May 2012. 1808 [I-D.bashandy-isis-bgp-edge-node-frr] 1809 Bashandy, A., "IS-IS Extension for BGP FRR Protection 1810 against Edge Node Failure", draft-bashandy-isis-bgp-edge- 1811 node-frr-01 (work in progress), September 2012. 1813 [I-D.bashandy-mpls-ldp-bgp-frr] 1814 Bashandy, A. and K. Raza, "LDP Extension for FRR Edge Node 1815 Protection in BGP-Free LDP Core", draft-bashandy-mpls-ldp- 1816 bgp-frr-00 (work in progress), March 2012. 1818 [I-D.ietf-rtgwg-remote-lfa] 1819 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 1820 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-06 1821 (work in progress), May 2014. 1823 [I-D.minto-2547-egress-node-fast-protection] 1824 Jeganathan, J., Gredler, H., and B. Decraene, "2547 egress 1825 PE Fast Failure Protection", draft-minto-2547-egress-node- 1826 fast-protection-02 (work in progress), July 2013. 1828 [I-D.rtgwg-bgp-pic] 1829 Bashandy, A., Filsfils, C., and P. Mohapatra, "Abstract", 1830 draft-rtgwg-bgp-pic-02 (work in progress), October 2013. 1832 [PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in 1833 MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS 1834 2006 Conference", . 1836 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 1837 BGP-4", RFC 3107, May 2001. 1839 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1840 Networks (VPNs)", RFC 4364, February 2006. 1842 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1843 Specification", RFC 5036, October 2007. 1845 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 1846 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 1847 July 2008. 1849 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1850 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1852 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1853 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 1854 2010. 1856 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1857 Networks", RFC 5920, July 2010. 1859 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 1860 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 1861 Alternate (LFA) Applicability in Service Provider (SP) 1862 Networks", RFC 6571, June 2012. 1864 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1865 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1866 and Authentication for Routing Protocols (KARP) Design 1867 Guide", RFC 6952, May 2013. 1869 [RFC7032] Beckhaus, T., Decraene, B., Tiruveedhula, K., 1870 Konstantynowicz, M., and L. Martini, "LDP Downstream-on- 1871 Demand in Seamless MPLS", RFC 7032, October 2013. 1873 Authors' Addresses 1875 Nicolai Leymann (editor) 1876 Deutsche Telekom AG 1877 Winterfeldtstrasse 21 1878 Berlin 10781 1879 DE 1881 Phone: +49 30 8353-92761 1882 Email: n.leymann@telekom.de 1884 Bruno Decraene 1885 Orange 1886 38-40 rue du General Leclerc 1887 Issy Moulineaux cedex 9 92794 1888 FR 1890 Email: bruno.decraene@orange.com 1892 Clarence Filsfils 1893 Cisco Systems 1894 Brussels 1895 Belgium 1897 Email: cfilsfil@cisco.com 1899 Maciek Konstantynowicz (editor) 1900 Cisco Systems 1901 London 1902 United Kingdom 1904 Email: maciek@cisco.com 1905 Dirk Steinberg 1906 Steinberg Consulting 1907 Ringstrasse 2 1908 Buchholz 53567 1909 DE 1911 Email: dws@steinbergnet.net