idnits 2.17.1 draft-ietf-mpls-seamless-mpls-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 13, 2013) is 3999 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 ---------------------------------------------------------------------------- == Unused Reference: 'I-D.draft-bashandy-bgp-edge-node-frr-03' is defined on line 1784, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-bashandy-bgp-frr-mirror-table-00' is defined on line 1787, but no explicit reference was found in the text == Unused Reference: 'I-D.kothari-henderickx-l2vpn-vpls-multihoming' is defined on line 1813, but no explicit reference was found in the text == Unused Reference: 'I-D.raggarwa-mac-vpn' is defined on line 1825, but no explicit reference was found in the text == Unused Reference: 'I-D.sajassi-l2vpn-rvpls-bgp' is defined on line 1830, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1839, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1842, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1848, but no explicit reference was found in the text == Unused Reference: 'RFC3353' is defined on line 1852, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1857, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 1861, but no explicit reference was found in the text == Unused Reference: 'RFC5332' is defined on line 1878, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-00 == Outdated reference: A later version (-03) exists of draft-minto-2547-egress-node-fast-protection-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-ldp-dod-06 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 0 errors (**), 0 flaws (~~), 16 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: November 14, 2013 France Telecom 6 C. Filsfils 7 M. Konstantynowicz, Ed. 8 Cisco Systems 9 D. Steinberg 10 Steinberg Consulting 11 May 13, 2013 13 Seamless MPLS Architecture 14 draft-ietf-mpls-seamless-mpls-03 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 November 14, 2013. 50 Copyright Notice 52 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . 9 75 2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10 76 2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 77 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 11 78 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 79 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 12 81 3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13 82 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 13 83 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13 84 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14 85 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 86 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 14 87 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 88 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15 90 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 15 91 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 15 92 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16 93 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17 95 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17 96 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 17 97 5.1.2. General Network Topology . . . . . . . . . . . . . . 17 98 5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18 99 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 18 100 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 18 101 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 102 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 19 103 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20 104 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 21 105 5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22 106 5.1.8. Network Availability . . . . . . . . . . . . . . . . 22 107 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23 108 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23 109 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent 110 Convergence . . . . . . . . . . . . . . . . . . . 24 111 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24 112 5.1.8.5. Assessing loss of connectivity upon any failure . 25 113 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29 114 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 30 115 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30 116 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 31 117 5.2.1. Control and Data Plane State for Deployment Scenario 118 #1 . . . . . . . . . . . . . . . . . . . . . . . . . 31 119 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 31 120 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31 121 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 33 122 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34 123 5.2.1.5. Numerical application for use case #1 . . . . . . 34 124 5.2.1.6. Numerical application for use case #2 . . . . . . 35 125 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 126 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 127 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 128 8.1. Access Network Security . . . . . . . . . . . . . . . . . 37 129 8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 37 130 8.3. Control Plane Security . . . . . . . . . . . . . . . . . 38 131 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 132 9.1. Normative References . . . . . . . . . . . . . . . . . . 38 133 9.2. Informative References . . . . . . . . . . . . . . . . . 38 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 136 1. Introduction 138 MPLS as a mature and well known technology is widely deployed in 139 today's core and aggregation/metro area networks. Many metro area 140 networks are already based on MPLS delivering Ethernet services to 141 residential and business customers. Until now those deployments are 142 usually done in different domains; e.g. core and metro area networks 143 are handled as separate MPLS domains. 145 Seamless MPLS extends the core domain and integrates aggregation and 146 access domains into a single MPLS domain ("Seamless MPLS"). This 147 enables a very flexible deployment of an end to end service delivery. 148 In order to obtain a highly scalable architecture Seamless MPLS takes 149 into account that typical access devices (DSLAMs, MSAN) are lacking 150 some advanced MPLS features, and may have more scalability 151 limitations. Hence access devices are kept as simple as possible. 153 Seamless MPLS is not a new protocol suite but describes an 154 architecture by deploying existing protocols like BGP, LDP and ISIS. 155 Multiple options are possible and this document aims at defining a 156 single architecture for the main function in order to ease 157 implementation prioritization and deployments in multi vendor 158 networks. Yet the architecture should be flexible enough to allow 159 some level of personalization, depending on use cases, existing 160 deployed base and requirements. Currently, this document focus on 161 end to end unicast LSP. 163 1.1. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 1.2. Terminology 171 This document uses the following terminology 173 o Access Node (AN): An access node is a node which processes 174 customers frames or packets at Layer 2 or above. This includes 175 but is not limited to DSLAMs or OLTs (in case of (G)PON 176 deployments). Access nodes have only limited MPLS functionalities 177 in order to reduce complexity in the access network. 179 o Aggregation Node (AGN): An aggregation node (AGN) is a node which 180 aggregates several access nodes (ANs). 182 o Area Border Router (ABR): Router between aggregation and core 183 domain. 185 o Deployment Scenario: Describes which an implementation of Seamless 186 MPLS in order to fullfil the requirements derived from one or more 187 use cases. 189 o Seamless MPLS Domain: A set of MPLS equipments which can set MPLS 190 LSPs between them. 192 o Transport Node (TN): Transport nodes are used to connect access 193 nodes to service nodes, and services nodes to services nodes. 194 Transport nodes ideally have no customer or service state and are 195 therefore decoupled from service creation. 197 o Seamless MPLS (S-MPLS): Used as a generic term to describe an 198 architecture which integrates access, aggregation and core network 199 in a single MPLS domain. 201 o Service Node (SN): A service node is used to create services for 202 customers and is connected to one or more transport nodes. 203 Typical examples include Broadband Network Gateways (BNGs), video 204 servers 206 o Transport Pseudo Wire (T-PW): A transport pseudowire provides 207 service independent transport mechanisms based on Pseudo-Wires 208 within the Seamless MPLS architecture. 210 o Use Case: Describes a typical network including service creation 211 points in order to describe the requirments, typical numbers etc. 212 which need to be taken into account when applying the Seamless 213 MPLS architecture. 215 2. Motivation 217 MPLS is deployed in core and aggregation network for several years 218 and provides a mature and stable basis for large networks. In 219 addition MPLS is already used in access networks, e.g. such as 220 mobile or DSL backhaul. Today MPLS as technology is being used on 221 two different layers: 223 o the Transport Layer and 225 o the Service Layer (e.g. for MPLS VPNs) 227 In both cases the protocols and the encapsulation are identical but 228 the use of MPLS is different especially concerning the signalling, 229 the control plane, the provisioning, the scalability and the 230 frequency of updates. On the service layer only service specific 231 information is exchanged; every service can potentially deploy it's 232 own architecture and individual protocols. The services are running 233 on top of the transport layer. Nevertheless those deployments are 234 usually isolated, focussed on a single use case and not integrated 235 into an end-to-end manner. 237 The motivation of Seamless MPLS is to provide an architecture which 238 supports a wide variety of different services on a single MPLS 239 platform fully integrating access, aggregation and core network. The 240 architecture can be used for residential services, mobile backhaul, 241 business services and supports fast reroute, redundancy and load 242 balancing. Seamless MPLS provides the deployment of service creation 243 points which can be virtually everywhere in the network. This 244 enables network and service providers with a flexible service and 245 service creation. Service creation can be done based on the existing 246 requirements without the needs for dedicated service creation areas 247 on fixed locations. With the flexibility of Seamless MPLS the 248 service creation can be done anywhere in the network and easily moved 249 between different locations. 251 2.1. Why Seamless MPLS 253 Multiple SP plan to deploy networks with 10k to 100k MPLS nodes. 254 This is typically at least one order of magnitude higher than typical 255 deployments and may require a new architecture. Multiple options are 256 possible and it makes sense for the industry (both vendors and SP) to 257 restrict the options in order to ease the first deployments (e.g. 258 restrict the number of options to implement and/or scales for 259 vendors, reduce interoperability and debugging 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 299 services specific configurations between the different MPLS islands. 300 Seamless MPLS connects all MPLS domains on the MPLS transport layer 301 providing a single transport layer for all services - independent of 302 the service itself. The Seamless MPLS architecture therefore 303 decuples the service and transport layer and integrates access, 304 aggregation and core into a single platform. One of the big 305 advantages is that problems on the transport layer only need to be 306 solved once (and the solutions are available to all services). With 307 Seamless MPLS it is not necessary to use service specific 308 configurations on intermediate nodes; all services can be deployed in 309 an end to end manner. 311 2.2. Use Case #1 313 2.2.1. Description 315 In most cases at least residential and business services need to be 316 supported by a network. This section describes a Seamless MPLS use 317 case which supports such a scenario. The use case includes point to 318 point services for business customers as well as typical service 319 creation for residential customers. 321 +-------------+ 322 | Service | 323 | Creation | 324 | Residential | 325 | Customers | 326 +------+------+ 327 | 328 | 329 | 330 PW1 +-------+ +---+---+ 331 ######################### | 332 # +--+ AGN11 +---+ AGN21 + +------+ 333 # / | | /| |\ | | +--------+ 334 +--#-+/ +-------+\/ +-------+ \| | | remote | 335 | AN | /\ + CORE +---......--+ AN | 336 +--#-+\ +-------+ \+-------+ /| | ####### | 337 # \ | | | |/################### +--------+ 338 # +--+ AGN12 +---+ AGN22 +##+------+ P2P Business Service 339 ############################## 340 PW2 +-------+ +-------+ 342 Figure 2: Use Case #1: Service Creation 344 Figure 2 shows the different service creation points and the 345 corresponding pseudowires between the access nodes and the service 346 creation points. The use case does not show all PWs (e.g. not the 347 PWs needed to support redundancy) in order to keep the figure simple. 348 Node and link failures are handled by rerouting the PWs (based on 349 standard mechanisms). End customers (either residential or business 350 customers) are connected to the access nodes using a native 351 technology like Ethernet. The access nodes terminates the PW(s) 352 carrying the traffic for the end customers. The link between the 353 access node (AN) and the aggregation node (AGN) is the first MPLS 354 enabled link. 356 Residential Services: The service creation for all residential 357 customers connected to the Access Nodes in an aggregation domain 358 is located on an Service Node connected to the AGN2x. The PW 359 (PW1) originated at the AN and terminates at the AGN2. A second 360 PW is deployed in the case where redundancy is needed on the AN 361 (the figure shows redundancy but this might not be the case for 362 all ANs in this Use Case). Additonal PWs can be deployed as well 363 in case more than a single service creation is needed for the 364 residential service (e.g. one service creation point for Internet 365 access and a second service creation point for IPTV services). 367 Business Sercvices: For business services the use cases shows point 368 to point connections between two access nodes. PW2 originates at 369 the AN and terminates on the remote AN crossing two aggregation 370 areas and the core network. If the access node needs connections 371 to several remote ANs the corresponding number of PWs will be 372 originated at the AN. Nevertheless taking the number of ports 373 available and the number of business customers on a typical access 374 node the number of PWs will be relatively small. 376 +-------+ +-------+ +------+ +------+ 377 | | | | | | | | 378 +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN 379 / | | /| | | | | | 380 +----+/ +-------+\/ +-------+ +------+ /+------+ 381 | AN | /\ \/ 382 +----+\ +-------+ \+-------+ +------+/\ +------+ 383 \ | | | | | | \| | 384 +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN 385 | | | | | | | | 386 +-------+ +-------+ +------+ +------+ 388 static route ISIS L1 LDP ISIS L2 LDP 390 <-Access-><--Aggregation Domain--><---------Core---------> 392 Figure 3: Use Case #1: Redundancy 394 Figure 3 shows the redundancy at the access and aggregation network 395 deploying a two stage aggregation network (AGN1x/AGN2x). 396 Nevertheless redundancy is not a MUST in this use case. It is also 397 possible to use non redundant connection between the ANs and AGN1 398 stage and/or between the AGN1 and AGN2 stages. The AGN2x stage is 399 used to aggregate traffic from several AGN1x pairs. In this use case 400 an aggregation domain is not limited to the use of a single pair of 401 AGN2x; the deployment of several AGN2 pairs within the domain is also 402 supported. As design goal for the scalability of the routing and 403 forwarding within the Seamless MPLS architecture the following 404 numbers are used: 406 o Number of Aggregation Domains: 100 408 o Number of Backbone Nodes: 1.000 410 o Number of Aggregation Nodes: 10.000 412 o Number of Access Nodes: 100.000 414 The access nodes (AN) are dual homed to two different aggregation 415 nodes (AGN11 and AGN12) using static routing entries on the AN. The 416 ANs are always source or sink nodes for MPLS traffic but not transit 417 nodes. This allows a light MPLS implementation in order to reduce 418 the complexity in the AN. The aggregation network consists of two 419 stages with redundant connections between the stages (AGN11 is 420 connected to AGN21 and AGN22 as well as AGN12 to AGN21 and AGN22). 421 The gateway between the aggregation and core network is realized 422 using the Area Border Routers (ABR). From the perspective of the 423 MPLS transport layer all systems are clearly identified using the 424 loopback address of the system. An ingress node must be able to 425 establish a service to an arbitrary egress system by using the 426 corresponding MPLS transport label 428 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 Control Plane | 2 | 436 | IP FIB | 2 | 437 | LDP Control Plane | 200 | 438 | LDP FIB | 200 | 439 | BGP Control Plane | 0 | 440 | BGP FIB | 0 | 441 +-------------------+---------------+ 443 Table 1: Use Case #1: Typical Numbers for Access Node 445 2.3. Use Case #2 447 2.3.1. Description 449 In most cases, residential, wholesales and business services need to 450 be supported by the network. 452 +-------------+ 453 | Service | 454 | platforms | 455 |(VoIP, VoD..)| 456 | Residential | 457 | Customers | 458 +------+------+ 459 | 460 | 461 +---+ +-----+ +--+--+ +-----+ 462 |AN1|----+AGN11+--+AGN21+---+ ABR | 463 +---+ +--+--+ +--+--+ +--+--+ 464 | | | 465 +---+ +--+--+ | | +----+ 466 |AN2|----+AGN12+ | | --+ PE | 467 +---+ +--+--+ | | +----+ 468 | | | 469 . | | 470 . | | 471 . | | 472 | | | 473 +---+ +---+ +--+--+ +--+--+ +--+--+ 474 |AN4+---+AN3|----+AGN1x+--+AGN22+---+ ABR | 475 +---+ +---+ +-----+ +-----+ +-----+ 476 <-Access-><--Aggregation Domain--><---------Core---------> 478 Figure 4: Use Case #2 480 The above topology (see Figure 4) is subject to evolutions, depending 481 on AN types and capacities (in terms of number of customers and/or 482 aggregated bandwidth). For examples, AGN1x connection toward AGN2y 483 currently forms a ring but may latter evolve in a square or triangle 484 topology; AGN2y nodes may not be present... 486 Most access nodes (AN) are single attached on one aggregation node 487 using static routing entries on the AN and AGN. Some AN, are dual 488 attached on two different AGN using static routes. Some AN are used 489 as transit by some lower level AN. Static routes are expected to be 490 used between those AN. 492 IPv4, IPv6 and MPLS interconnection between the aggregation and core 493 network is realized using the Area Border Routers (ABR). Any ingress 494 node must be able to establish IPv4, IPv6 and MPLS connections to any 495 egress node in the seamless MPLS domain. 497 Regarding MPLS connectivity requirements, a full mesh of MPLS LSPs is 498 required between the ANs of an aggregation area, at least for 6PE 499 purposes. Some additional LSPs are needed between ANs and some PE in 500 the aggregation area or in the core area for access to services, 501 wholesale and enterprises services. In short, a meshing of LSP is 502 required between the AGN of the whole seamless MPLS domain. Finally, 503 LSP between any node to any node should be possible. 505 From a scalability standpoint, the following numbers are the targets: 507 o Number of Aggregation Domains: 30 509 o Number of Backbone Nodes: 150 511 o Number of Aggregation Nodes: 1.500 513 o Number of Access Nodes: 40.000 515 2.3.2. Typical Numbers 517 Table 2 shows typical numbers which are expected for Use Case #2 for 518 the purpose of establishing the transport LSPs. They do not take 519 into account the services built in addition. (e.g. 6PE will require 520 additional IPv6 routes). 522 +-------------------+---------------+ 523 | Parameter | Typical Value | 524 +-------------------+---------------+ 525 | IGP Control Plane | 2 | 526 | IP FIB | 2 | 527 | LDP Control Plane | 1000 | 528 | LDP FIB | 1000 | 529 +-------------------+---------------+ 531 Table 2: Use Case #2: Typical Numbers for Access Node 533 3. Requirements 535 The following section describes the overall requirements which need 536 to be fulfilled by the Seamless MPLS architecture. Beside the 537 general requirements of the architecture itself there are also 538 certain requirements which are related to the different network 539 nodes. 541 o End to End Transport LSP: MPLS based services (pseudowire based, 542 L3-VPN or IP) SHALL be provided by the Seamless MPLS based 543 infrastructure between any nodes. 545 o Scalability: The network SHALL be scalable to the minimum of 546 100.000 nodes. 548 o Fast convergence (sub second resilience) SHALL be supported. Fast 549 reroute (LFA) SHOULD be supported. 551 o Flexibility: The Seamless MPLS architecture SHALL be applied to a 552 wide variety of existing MPLS deployments. It SHALL use a 553 flexible approach deploying building blocks with the possiblity to 554 use certain features only if those features are needed (e.g. dual 555 homing ANs or fast reroute mechanisms). 557 o Service independence: Service and transport layer SHALL be 558 decoupled. The architecture SHALL remove the need for service 559 specific configurations on intermediate nodes. 561 o Native Multicast support: P2MP MPLS LSPs SHOULD be supported by 562 the Seamless MPLS architecture. 564 o Interoperable end to end OAM mechanisms SHALL be implemented 566 3.1. Overall 568 3.1.1. Access 570 In respect of MPLS functionality the access network should be kept as 571 simple as possible. Compared to the aggregation and/or core network 572 within Seamless MPLS a typical access node is less powerful. The 573 control plane and the forwarding should be as simple as possible. To 574 reduce the complexity and the costs of an access node not the full 575 MPLS functionality need to be supported (control and data plane). 576 The use of an IGP should be avoided. Static routing should be 577 sufficient. Required functionality to reach the required scalability 578 should be moved out of the access node. The number of access nodes 579 can be very high. The support of load balancing for layer 2 services 580 should be implemented. 582 3.1.2. Aggregation 584 The aggregation network aggregates traffic from access nodes. The 585 aggregation Node must have functionalities that enlarge the 586 scalability of the simple access nodes that are connected. The IGP 587 must be link state based. Each aggregation area must be a separated 588 area. All routes that are interarea should use an EGP to keep the 589 IGP small. The aggregation node must have the full scalability 590 concerning control plane and forwarding. The support of load 591 balancing for layer 2 services must be implemented. 593 3.1.3. Core 595 The core connects the aggregation areas. The core network elements 596 must have the full scalability concerning control plane and 597 forwarding. The IGP must be link state based. The core area must 598 not include routes from aggregation areas. All routes that are 599 interarea should use an EGP to keep the IGP small. Each area of the 600 link state based IGP should have less than 2000 routes. The support 601 of load balancing for layer 2 services must be implemented. 603 3.2. Multicast 605 Compared with unicast connectivity Multicast is more dynamic. User 606 generated messages - like joining or leaving multicast groups - are 607 interacting directly with network components in the access and 608 aggregation network (in order to build the corresponding forwarding 609 states). This leads to the need for a highly dynamic handling of 610 messages on access and aggregation nodes. Nevertheless the core 611 network SHOULD be stable and state changes triggered by user 612 generated messages SHOULD be minimized. This rises the need for an 613 hierarchy for the P2MP support in Seamless MPLS hiding the dynamic 614 behaviour of the access and aggregation nodes 616 o mLDP 618 o P2MP RSVP-TE 620 3.3. Availability 622 All network elements should be high available (99.999% availability). 623 Outage times should be as low as possible. A repair time of 50 624 milliseconds or less should be guarantied at all nodes and lines in 625 the network that are redundant. Fast convergence features SHOULD be 626 used in all control plane protocols. Local Repair functions SHOULD 627 be used wherever possible. Full redundancy is required at all 628 equipment that is shared in a network element. 630 o Power Supply 632 o Switch Fabric 634 o Routing Processor 636 A change from an active component to a standby component SHOULD 637 happen without effecting customers traffic. The Influence of 638 customer traffic MUST be as low as possible. 640 3.4. Scalability 642 The network must be highly scalable. As a minimum requirement the 643 following scalability figures should be met: 645 o Number of aggregation domains: 100 647 o Number of backbone nodes: 1.000 649 o Number of aggregation nodes: 10.000 651 o Number of access nodes: 100.000 653 3.5. Stability 655 o The platform should be stable under certain circumstances (e.g. 656 missconfiguration within one area should not cause instability in 657 other areas). 659 o Differentiate between "All Loopbacks and Link addresses should be 660 ping able from every where." Vs. "Link addresses are not 661 necessary ping able from everywhere". 663 4. Architecture 665 4.1. Overall 667 One of the key questions that emerge when designing an architecture 668 for a seamless MPLS network is how to handle the sheer size of the 669 necessary routing and MPLS label information control plane and 670 forwarding plane state resulting from the stated scalability goals 671 especially with respect to the total number of access nodes. This 672 needs to be done without overwhelming the technical scaling limits of 673 any of the involved nodes in the network (access, aggregation and 674 core) and without introducing too much complexity in the design of 675 the network while at the same time still maintaining good convergence 676 properties to allow for quick MPLS transport and service restoration 677 in case of network failures. 679 4.2. Multi-Domain MPLS networks 681 The key design paradigm that leads to a sound and scalable solution 682 is the divide and conquer approach, whereby the large problem is 683 decomposed into many smaller problems for which the solution can be 684 found using well-known standard architectures. 686 In the specific case of seamless MPLS the overall MPLS network SHOULD 687 be decomposed into multiple MPLS domains, each well within the 688 scaling limits of well-known architectures and network node 689 implementations. From an organizational and operational point of 690 view it MAY make sense to define the boundaries of such domains along 691 the pre-existing boundaries of aggregation networks and the core 692 network. 694 Examples of how networks can be decomposed include using IGP areas as 695 well as using multiple BGP autonomous systems. 697 4.3. Hierarchy 699 These MPLS domains SHOULD then be then be connected into an MPLS 700 multi-domain network in a hierarchical fashion that enables the 701 seamless exchange of loopback addresses and MPLS label bindings for 702 transport LSPs across the entire MPLS internetwork while at the same 703 time preventing the flooding of unnecessary routing and label binding 704 information into domains or parts of the network that do not need 705 them. Such a hierarchical routing and forwarding concept allows a 706 scalability in different dimensions and allows to hide the complexity 707 and size of the aggregation and access networks. 709 4.4. Intra-Domain Routing 710 The intra-domain routing within each of the MPLS domains (i.e. 711 aggregation domains and core) SHOULD utilize standard IGP protocols 712 like OSPF or ISIS. By definition, each of these domains is small 713 enough so that there are no relevant scaling limits within each IGP 714 domain, given well-known state-of-the-art IGP design principles and 715 recent router technology. 717 The intra-domain MPLS LSP setup and label distribution SHOULD utilize 718 standard protocols like LDP or RSVP. 720 4.5. Inter-Domain Routing 722 The inter-domain routing is responsible for establishing connectivity 723 between and across all MPLS domains. The inter-domain routing SHOULD 724 establish a routing and forwarding hierarchy in order to achieve the 725 scaling goals of seamless MPLS. Note that the IP aggregation usually 726 performed between region (IGP areas/AS) in IP routing does not work 727 for MPLS as MPLS is not capable of aggregating FEC (because MPLS 728 forwarding use an exact match lookup, while IP uses longest match). 730 Therefore it is RECOMMENDED to utilize protocols that support 731 indirect next-hops (like BGP with MPLS labels "labled BGP/SAFI4" 732 [RFC3107]). 734 4.6. Access 736 Compared to the aggregation and core parts of the Seamless MPLS 737 network the access part is special in two respects: 739 o The number of ndes in the access is at least one order of 740 magnitude higher than in any other part of the network. 742 o Because of the large quantity of access nodes, the cost of these 743 nodes is extremly relevant for the overall costs of the entire 744 network, i.e. acess nodes are very cost sensitive. 746 This makes it desirable to design the architecture such that the AN 747 functionality can be kept as simple as possible. This should always 748 be kept in mind when evalulating different seamless MPLS 749 architectures. The goal is to limit both the number of different 750 protocols needed on the AN as well as the scale to which each 751 protocol must perform to the absolute minimum. 753 5. Deployment Scenarios 755 This section describes the deployment scenarios based on the use 756 cases and the generic architecture above. 758 5.1. Deployment Scenario #1 760 Section describing the Seamless MPLS implementation of a large 761 european ISP. 763 5.1.1. Overview 765 This deployment scenario describes one way to implement a seamless 766 MPLS architecture. Specific to this implementation is the choice of 767 intra- and inter-domain routing and label distribution protocols, as 768 well as the details of the interworking of these protocols to achieve 769 the overall scalable hierarchical architecture. 771 5.1.2. General Network Topology 773 There are multiple aggregation domains (in the order of up to 100) 774 connected to the core in a star topology, i.e. aggregation domains 775 are never connected among themselves, but only to the core. The core 776 has its own domain. 778 +-------+ +-------+ +------+ +------+ 779 | | | | | | | | 780 +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN 781 / | | /| | | | | | 782 +----+/ +-------+\/ +-------+ +------+ /+------+ 783 | AN | /\ \/ | 784 +----+\ +-------+ \+-------+ +------+/\ +------+ 785 \ | | | | | | \| | 786 +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN 787 | | | | | | | | 788 +-------+ +-------+ +------+ +------+ 790 static route ISIS L1 LDP ISIS L2 LDP 792 <-Access-><--Aggregation Domain--><---------Core---------> 794 Figure 5: Deployment Scenario #1 796 As shown in Figure 5, the access nodes (AN) are connected to the 797 aggregation network via aggregation nodes called AGN1x, either to a 798 single AGN1x or redundantly to two AGN1x. Each AGN1x has redundant 799 uplinks to a pair of second-level aggregation nodes called AGN2x. 801 Each aggregation domain is connected to the core via exactly two 802 border routers (ABR) on the core side. There can be multiple AGN2 803 pairs per aggregation domain, but only one ABR pair for each 804 aggregation domain. Each of the AGN2 in an AGN2 pair connects to one 805 of the ABRs in the ABR pair responsible for that aggregation domain. 807 The ABRs on the core side have redundant connections to a pair of LSR 808 routers. 810 The LSR pair is also connected via a direct link. 812 The core LSR are connected to other core LSR in a partly meshed 813 topology so that there are disjunct, redundant paths from each LSR to 814 each other LSR. 816 5.1.3. Hierarchy 818 As explained before, hierarchy is the key to a scalable seamless MPLS 819 architecture. The hierarchy in this implementation is achieved by 820 forming different MPLS domains for aggregation domains and core, 821 where within each of these domains a fairly common MPLS deployment 822 using ISIS as intradomain link-state routing protocol and using LDP 823 for MPLS label distribution is used. 825 These MPLS domains are mapped to ISIS areas as follows: Aggregation 826 domains are mapped to ISIS L1 areas. The core is configured as ISIS 827 L2. The border routers connecting aggregation and core are ISIS L1L2 828 and are referred to as ABRs. From a technical and operational point 829 of view these ABRs are part of the core, althought they also belong 830 to the respective aggregation domain purely from a routing protocol 831 point of view. 833 For the interdomain-routing BGP with MPLS labels is deployed ("labled 834 BGP/SAFI4" [RFC3107]). 836 5.1.4. Intra-Area Routing 838 5.1.4.1. Core 840 The core uses ISIS L2 to distribute routing information for the 841 loopback addresses of all core nodes. The border routers (ABR) that 842 connect to the aggregation domains are also part of the respective 843 aggregation ISIS L1 area and hence ISIS L1L2. 845 LDP is used to distribute MPLS label binding information for the 846 loopback addresses of all core nodes. 848 5.1.4.2. Aggregation 850 The aggregation domains uses ISIS L1 as intra-domain routing 851 protocol. All AGN loopback addresses are carried in ISIS. 853 As in the core, the aggregation also uses LDP to distribute MPLS 854 label bindings for the loopback addresses. 856 5.1.5. Access 858 Access nodes do not have their own domain or IGP area. Instead, they 859 directly connect to the AGN1 nodes in the aggregation domain. To 860 keep access devices as simple as possible, ANs do not participate in 861 ISIS. 863 Instead, each AN has two static default routes pointing to each of 864 the AGN1 it is connected to. Appropriate techniques SHOULD be 865 deployed to make sure that a given default route is invalidated when 866 the link to an AGN1 or that node itself fails. Examples of such 867 techniques include monitoring the pysical link state for loss of 868 light/loss of frame, or using Ethernet link OAM or BFD 869 [I-D.ietf-bfd-v4v6-1hop]. 871 The AGN1 MUST have a configured static route to the loopback address 872 of each of the ANs it is connected to, because it cannot learn the AN 873 loopback address in any other way. These static routes have to be 874 monitored and invalidated if necessary using the same techniques as 875 described above for the static default routes on the AN. 877 The AGN1 redistributes these routes into ISIS for intra-domain 878 reachability of all AN loopback addresses. 880 LDP is used for MPLS label distribution between AGN1 and AN. In 881 order to keep the AN control plane as lightweight as possible, and to 882 avoid the necessity for the AN to store 100.000 MPLS label bindings 883 for each upstream AGN1 peer, LDP is deployed in downstream-on-demand 884 (DoD) mode, described below. 886 To allow the label bindings received via LDP DoD to be installed into 887 the LFIB on the AN without having the specific host route to the 888 destination loopback address, but only a default route, use of the 889 LDP Extension for Inter-Area Label Switched Paths [RFC5283] is made. 891 5.1.5.1. LDP Downstream-on-Demand (DoD) 893 LDP downstream-on-demand mode is specified in [RFC5036]. Although it 894 was originally intended to be used with ATM switch hardware, there is 895 nothing from a protocol perspective preventing its use in a regular 896 MPLS frame-based environment. In this mode the upstream LSR will 897 explicitly ask the downstream LSR for a label binding for a 898 particular FEC when needed. 900 The assumption is that a given AN will only have a limited number of 901 services configured to an even more limited number of destinations, 902 or egress LER. Instead of learning and storing all label bindings 903 for all possible loopback addresses within the entire Seamless MPLS 904 network, the AN will use LDP DoD to only request the label bindings 905 for the FECs corresponding to the loopback addresses of those egress 906 nodes to which it has services configured. 908 For LDP DoD the AGN1 MUST also ask the AN for label bindings for 909 specific FECs. FECs are necessary for all pseudowire destinations at 910 the AN. Most preferable this pseudowire destination is the LSR-ID of 911 the AN. Depending on the AN implementation and architecture multiple 912 pseudowire destination addresses and associated FECs could be needed. 913 The conclusion of this results to the following requirement: 915 o The AGN1 MUST ask the AN for label bindings for all potential 916 pseudowire destination addresses on the AN. Because the AGN (at 917 least in many cases) does not take part in the pseudowire 918 signaling an independent way of receiving the AN FEC is necessary 919 on the AGN. These potential pseudowire destinations MUST be known 920 on the AGN1, by configuration or otherwise. These are typically 921 the loopback addresses of the AN, to which a static route has been 922 configured anyway on the AGN1, as explained above. In addition to 923 these static routes, the AGN1 SHOULD be configured statically to 924 request MPLS label bindings for these loopback addresses via LDP 925 DoD. 927 o Optionally an automatism that asks for a FEC for the LSR-ID COULD 928 be implemented. A configuration switch that disables this option 929 must be implemented. The label is necessary. The way of 930 initiating the DoD-signaling of the label could be done with both 931 methods (configuration/automatism). 933 o The AN knows by configuration to which destination a pseudowire is 934 set up. The AN is always the endpoint of the pseudowire. Before 935 signalling a pseudowire the AN MUST ask (via LDP DoD) the AGN for 936 a FEC. Because of this an independent preconfiguration is not 937 necessary on the AN. 939 o The following are the triggers for ANs to request a label: 941 o 943 * When a control session (targeted LDP) to a target has to be 944 established 946 * When a service label has been received by a control session 947 (e.g. pseudo wire label) 949 5.1.6. Inter-Area Routing 951 The inter-domain MPLS connectivity from the aggregation domains to 952 and across the core domain is realized primarily using BGP with MPLS 953 labels ("labled BGP/SAFI4" [RFC3107]). A very limited amount of 954 route leaking from ISIS L2 into L1 is also used. 956 All ABR and PE nodes in the core are part of the labeled iBGP mesh, 957 which can be either full mesh or based on route reflectors. These 958 nodes advertise their respective loopback addresses (which are also 959 carried in ISIS L2) into labeled BGP. 961 Each ABR node has labeled iBGP sessions with all AGN1 nodes inside 962 the aggregation domain that they connect to the core. Since there 963 are two ABR nodes per aggregation domain, this leads to each AGN1 964 node having an iBGP sessions with each of the two ABR. Note that the 965 use of iBGP implies that the entire seamless MPLS internetwork is 966 just a single AS to which all core and aggregation nodes belong. The 967 AGN1 nodes advertise their own loopback addresses into labeled BGP, 968 in addition to these loopbacks also being in ISIS L1. 970 Additionally the AGN1 nodes also redistribute all the statically 971 configured routes to the AN loopback addresses into labeled BGP. 972 Note that as stated obove, the AGN1 MUST ask the AN for label 973 bindings for the AN loopback FECs via LDP DoD in order to have a 974 valid labeled route with a non-null label. 976 This architecture results in carrying all loopbacks of all nodes 977 except pure P nodes (AN, AGN, ABR and core PE) in labeled BGP, e.g. 978 there will be in the order of 100.000 routes in labeled BGP when 979 approaching the stated scalability goal. Note that this only affects 980 the BGP RIB size and does not necessarily imply that any node needs 981 to actually have active forwarding state (LFIB) in the same order of 982 magnitude. In fact, as will be discussed in the scalability 983 analysis, no single node needs to install all labeled BGP routes into 984 the LFIB, but each node only needs a small percentage of the RIB as 985 active forwarding state in the LFIB. And from a RIB point of view, 986 BGP is known to scale to hundreds of thousands of routes. 988 5.1.7. Labled iBGP next-hop handling 990 The ABR nodes run labeled iBGP both to the core mesh as well as to 991 the AGN1 nodes of their respective aggregation domains. Therefore 992 they operate as iBGP route reflectors, reflecting labeled routes from 993 the aggregation into the core and vice versa. 995 When reflecting routes from the core into the aggregation domain, the 996 ABR SHOULD NOT change the BGP NEXT-HOP addresses (next-hop- 997 unchanged). This is the usual behaviour for iBGP route reflection. 998 In order to make these routes resolvable to the AGN1 nodes inside the 999 aggregation domain, the ABR MUST leak all other ABR and core PE 1000 loopback addresses from ISIS L2 into ISIS L1 of the aggregation 1001 domain. Note that the number of leaked addresses is limited so that 1002 the overall scalability of the seamless MPLS architecture is not 1003 impacted. In the worst case all core loopback addresses COULD be 1004 leaked into ISIS L1, but even that would not be a scalability 1005 problem. 1007 When reflecting routes from the aggregation into the core, the ABR 1008 MUST set then BGP NEXT-HOP to its own loopback addresses (next-hop- 1009 self). This is not the default behaviour for iBGP route reflection, 1010 but requires special configuration on the ABR. Note that this also 1011 implies that the ABR MUST allocate a new local MPLS label for each 1012 labeled iBGP FEC that it reflects from the aggregation into the core. 1013 This special next-hop handling is essential for the scalability of 1014 the overall seamless MPLS architecture since it creates the required 1015 hierarchy and enables the hiding of all aggregation and access 1016 addresses behind the ABRs from an IGP point of view. Leaking of 1017 aggregation ISIS L1 loopback addresses into ISIS L2 is not necessary 1018 and MUST NOT be allowed. 1020 The resulting hierarchical inter-domain MPLS routing structure is 1021 similar to the one described in [RFC4364] section 10c, only that we 1022 use one AS with route reflection instead of using multiple ASes. 1024 5.1.8. Network Availability 1026 The seamless mpls architecture guarantees a sub-second loss of 1027 connectivity upon any link or node failures. Furthermore, in the 1028 vast majority of cases, the loss of connectivity is limited to sub- 1029 50msec. 1031 These network availability properties are provided without any 1032 degradation on scale and simplicity. This is a key achievement of 1033 the design. 1035 In the remainder of this section, we first introduce the different 1036 network availability technologies and then review their applicability 1037 for each possible failure scenario. 1039 5.1.8.1. IGP Convergence 1041 IGP convergence can be modelled as a linear process with an initial 1042 delay and a linear FIB update [ACM01]. 1044 The initial delay could conservatively be assumed to be 260msec: 1045 50msec to detect failures with BFD (most failures would be detected 1046 faster with loss of light for example or with faster BFD timers), 1047 50msec to throttle the LSP generation, 150msec to throttle the SPF 1048 computation (making sure than all the required LSP's are received 1049 even in case of SRLG failures) and 10msec for shortest-path-first 1050 tree computation. 1052 Assuming 250usec per update (conservative), this allows for 1053 (1000-260)/0.250= 2960 prefixes update within a second following the 1054 outage. More precisely, this allows for 2960 important IGP prefixes 1055 updates. Important prefixes are automatically classified by the 1056 router implementation through simple heuristic (/32 is more important 1057 than non-/32). 1059 The number of IGP important routes (loopbacks) in deployment case 1060 study 1 is much smaller than 2960, and hence sub-second IGP 1061 convergence is conservative. 1063 IGP convergence is a simple technology for the operator provided that 1064 the router vendor optimizes the default IGP behavior (no need to tune 1065 any arcane knob). 1067 5.1.8.2. Per-Prefix LFA FRR 1069 A per-prefix LFA for a destination D is a precomputed backup IGP 1070 nexthop for that destination. This backup IGP nexthop can be link 1071 protecting or node protecting [RFC5286]. 1073 The analysis of the applicability of Per-Prefix LFA in the deployment 1074 model 1 of Seamless MPLS architecture is straightforward thanks to 1075 [I-D.filsfils-rtgwg-lfa-applicability]. 1077 In deployment model 1, each aggregation network either follows the 1078 triangle or full-mesh topology. Further more, the backbone region 1079 implements a dual-plane. As a consequence, the failure of any link 1080 or node within an aggregation domain is protected by LFA FRR (sub- 1081 50msec) for all impacted IGP prefixes, whether intra-area or inter- 1082 area. No uloop may form as a result of these failures 1083 [I-D.filsfils-rtgwg-lfa-applicability]. 1085 Per-Prefix LFA FRR is generally assessed as a simple technology for 1086 the operator [I-D.filsfils-rtgwg-lfa-applicability]. It certainly is 1087 in the context of deployment case study 1 as the designer enforced 1088 triangle and full-mesh topologies in the aggregation network as well 1089 as a dual-plane core network. 1091 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent Convergence 1093 In a hierarchical dataplane, the FIB used by the packet processing 1094 engine reflects recursions between the routes. For example, a BGP 1095 route B recursing on IGP route I whose best path is via interface O 1096 is encoded as a hierarchy of FIB entry B pointing to a FIB entry I 1097 pointing to a FIB entry 0. 1099 BGP Prefix Independent Convergence [BGP-PIC] extends the hierarchical 1100 dataplane with the concept of a BGP Path-List. A BGP path-list may 1101 be abstracted as a set of primary multipath nhops and a backup nhop. 1102 When the primary set is empty, packets destined to the BGP 1103 destinations are rerouted via the backup nhop. 1105 For complete description of BGP-PIC technology and its applicability 1106 please refer to [BGP-PIC]. 1108 Hierarchical data plane and BGP-PIC are very simple technologies to 1109 operate. Their applicability to any topology, any routing policy and 1110 any BGP unicast address family allows router vendors to enable this 1111 behavior by default. 1113 5.1.8.4. BGP Egress Node FRR 1115 BGP egress node FRR is a Fast ReRoute solution and hence relies on 1116 local protection and the precomputation and preinstallation of the 1117 backup path in the FIB. BGP egress node FRR relies on a transit LSR 1118 ( Point of Local Repair, PLR ) adjacent to the failed protected BGP 1119 router to detect the failure and re-route the traffic to the backup 1120 BGP router. Number of BGP egress node FRR schemes are being 1121 investigated: [PE-FRR], [ABR-FRR], 1122 [I-D.draft-minto-2547-egress-node-fast-protection-00], 1123 [I-D.draft-minto-2547-egress-node-fast-protection-00], 1124 [I-D.draft-minto-2547-egress-node-fast-protection-00]. 1126 Differences between these schemes relate to the way backup and 1127 protected BGP routers get associated, how the protected router's BGP 1128 state is signalled to the backup BGP router(s) and if any other state 1129 is required on protected, backup and PLR routers. The schemes also 1130 differ in compatibility with IPFRR and TEFRR schemes to enable PLR to 1131 switch traffic towards the backup BGP router in case of protected BGP 1132 router failure. 1134 In the Seamless MPLS design, BGP egress node FRR schemes can protect 1135 against the failures of PE, AGN and ABR nodes with no requirements on 1136 ingress routers. 1138 5.1.8.5. Assessing loss of connectivity upon any failure 1140 We select two typical traffic flows and analyze the loss of 1141 connectivity (LoC) upon each possible failure in the Seamless MPLS 1142 design in the deployment scenario #1. 1144 o Flow F1 starts from an AN1 in a left aggregation region and ends 1145 on an AN2 in a right aggregation region. Each AN is dual-homed to 1146 two AGN's. 1148 o Flow F2 starts from a CE1 homed on L3VPN PE1 connected to the core 1149 LSRs and ends at CE2 dual-homed to L3VPN PE2 and PE3, both 1150 connected to the core LSRs. 1152 Note that due to the symmetric network topology in case study 1, uni- 1153 directional flows F1' and F2', associated with F1 and F2 and 1154 forwarded in the reversed direction (AN2 to AN1 right-to-left and PE2 1155 to PE1, respectively), take advantage of the same failure restoration 1156 mechanisms as F1 and F2. 1158 5.1.8.5.1. AN1-AGN link failure or AGN node failure 1160 F1 is impacted but LoC <50msec is possible assuming fast BFD 1161 detection and fast-switchover implementation on the AN. F2 is not 1162 impacted. 1164 5.1.8.5.2. Link or node failure within the left aggregation region 1166 F1 is impacted but LoC <50msec thanks to LFA FRR. No uloop will 1167 occur during the IGP convergence following the LFA protection. Note: 1168 if LFA is not available (other topology then case study one) or if 1169 LFA is not enabled, then the LoC would be < second as the number of 1170 impacted important IGP route in a seamless architecture is much 1171 smaller than 2960. 1173 F2 is not impacted. 1175 5.1.8.5.3. ABR node failure between left region and the core 1177 F1 is impacted but LoC <50msec thanks to LFA FRR. No uloop will 1178 occur during the IGP convergence following the LFA protection. 1180 Note: This case is also called "Local ABR failure" as the ABR which 1181 fails is the one connected to the aggregation region at the source of 1182 flow F1. 1184 Note: remember that the left region receives the routes to all the 1185 remote ABR's and that the labelled BGP routes are reflected from the 1186 core to the left region with next-hop unchanged. This ensures that 1187 the loss of the (local) ABR between the left region and the core is 1188 seen as an IGP route impact and hence can be addressed by LFA. 1190 Note: if LFA is not available (other topology then case study one) or 1191 if LFA is not enabled, then the LoC would be < second as the number 1192 of impacted important IGP routes in a seamless architecture is much 1193 smaller than 2960 routes. 1195 F2 is not impacted. 1197 5.1.8.5.4. Link or node failure within the core region 1199 F1 and F2 are impacted but LoC <50msec thanks to LFA FRR. 1201 This is specific to the particular core topology used in deployment 1202 case study 1. The core topology has been optimized 1203 [I-D.filsfils-rtgwg-lfa-applicability] for LFA applicability. 1205 As explained in [I-D.filsfils-rtgwg-lfa-applicability], another 1206 alternative to provide <50msec in this case consists in using an 1207 MPLS-TE full-mesh and MPLS-TE FRR. This is required when the 1208 designer is not able or does not want to optimize the topology for 1209 LFA applicability and he wants to achieve <50msec protection. 1211 Alternatively, simple IGP convergence would ensure a LoC < second as 1212 the number of impacted important IGP routes in a seamless 1213 architecture is much smaller than 2960 routes. 1215 5.1.8.5.5. PE2 failure 1217 F1 is not impacted. 1219 F2 is impacted and the LoC is sub-300msec thanks to IGP convergence 1220 and BGP PIC. 1222 The detection of the primary nhop failure (PE2 down) is performed by 1223 a single-area IGP convergence. 1225 In this specific case, the convergence should be much faster than 1226 90% of the IGP/BGP3107 footprint at least). 1353 If the guidelines cannot be met, then either the designer will rely 1354 on (1) augmenting native LFA coverage with remote LFA 1355 [I-D.draft-ietf-rtgwg-remote-lfa-00], or (2) augmenting native LFA 1356 coverage with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP 1357 convergence. The first option provides an automatic and fairly 1358 simple sub-50msec protection as LFA without introducing any 1359 additional protocols. The second option provides the same sub-50msec 1360 protection as LFA, but introduces additional RSVP LSPs. The thrid 1361 option optimizes for sub-50msec protection, but implies a more 1362 complex operational model. The fourth option optimizes for simple 1363 operation but only provides <1 sec protection. Up to each designer 1364 to arbitrate between these three options versus the possibility to 1365 engineer the topology for native LFA protection. 1367 A similar choice involves protection against ABR node failure and 1368 L3VPN PE node failure. The designer can either use BGP PIC or BGP 1369 egress node FRR. Up to each designer to asssess the trade-off 1370 between the valuation of sub-50msec instead of sub-1sec versus 1371 additional operational considerations related to BGP egress node FRR. 1373 5.1.8.7. Conclusion 1375 The Seamless MPLS architecture illustrated in deployment case study 1 1376 guarantees sub-50msec for majority of link and node failures by using 1377 LFA FRR, except ABR and L3PE node failures, and PE-CE link failure. 1379 L3VPN PE-CE link failure can be protected with sub-50msec 1380 restoration, by using hierarchical data plane and local-repair fast- 1381 reroute to the backup BGP nhop PE. 1383 ABR and L3PE node failure can be protected with sub-50msec 1384 restoration, by using BGP egress node FRR. 1386 Alternatively, ABR and L3PE node failure can be protected with sub- 1387 1sec restoration using BGP PIC. 1389 5.1.9. BGP Next-Hop Redundancy 1391 An aggregation domain is connected to the core network using two 1392 redundant area boarder routers, and MPLS hierarchy is applied on 1393 these ABRs. MPLS hierarchy helps scale the FIB but introduces 1394 additional complexity for the rerouting in case of ABR failure. 1395 Indeed ABR failure requires a BGP converge to update the inner MPLS 1396 hierarchy, in addition to the IGP converge to update the outer MPLS 1397 hierarchy. This is also expected to take more time as BGP 1398 convergence is performed after the IGP convergence and because the 1399 number of prefixes to update in the FIB can be significant. This is 1400 clearly a drawback, but the architecture allows for two "local 1401 protection" solutions which restore the traffic before the BGP 1402 convergence takes place. 1404 BGP PIC would be required on all edge LSR involved in the inner (BGP) 1405 MPLS hierarchy. Namely all routers except the AN which are not 1406 involved in the inner MPLS hierarchy. It involves pre-computing and 1407 pre-installing in the FIB the BGP backup path. Such back up path are 1408 activated when the IGP advertise the failure of the primary path. 1409 For specification see [BGP-PIC1, 2##]. 1411 BGP egress node FRR would be required on the egress LSR involved in 1412 the inner (BGP) MPLS hierarchy, namely AGN, ABR and L3VPN PEs. For 1413 specification see [PE-FRR], [ABR-FRR], [BGP-edge-FRR##]. 1415 Both approaches have their pros and cons, and the choice is left to 1416 each Service Provider or deployment based on the different 1417 requirements. The key point is that the seamless MPLS architecture 1418 can handle fast restoration time, even for ABR failures. 1420 5.2. Scalability Analysis 1422 5.2.1. Control and Data Plane State for Deployment Scenario #1 1424 5.2.1.1. Introduction 1426 Let's call: 1428 o #AN the number of Access Node (AN) in the seamless MPLS domain 1430 o #AGN the number of AGgregation Node (AGN) in the seamless MPLS 1431 domain 1433 o #Core the number of Core (Core) in the core network 1435 o #Area the number of aggregation routing domains. 1437 Let's take the following assumptions: 1439 o Aggregation equipments are equally spread across aggregation 1440 routing domains 1442 o the number of IGP links is three times the number of IGP nodes 1444 o the number of IGP prefixes is five times the number of IGP nodes 1445 (links prefixes + 2 loopbacks) 1447 o Access Nodes need to set up 1000 (1k) LSPs. 10% (100) are FEC 1448 which are outside of their routing domain. Those 100 remote FEC 1449 are the same for all Access Nodes of a given AGN. 1451 The following sections roughly evaluate the scalability, both in 1452 absolute numbers and relatively with the number of Access Node which 1453 is the biggest scalability factor. 1455 5.2.1.2. Core Domain 1457 The IGP & LDP core domain are not affected by the number of access 1458 nodes: 1460 IGP: 1462 node : #Core ~ o(1) 1463 links : 3*#Core ~ o(1) 1465 IP prefixes : 5*#Core ~ o(1) 1467 LDP FEC: 1469 #Core ~ o(1) 1471 Core TN FIBs grows linearly with the number of node in the core 1472 domain. In other word, they are not affected by AGN and AN nodes: 1474 Core TN: 1476 IP FIB : 5*#Core ~ o(1) 1478 MPLS LFIB : #Core ~ o(1) 1480 BGP carries all AN routes which is significant. However, all AN 1481 routes are only needed in the control plane, possibly in a dedicated 1482 BGP Route Reflector (just like for BGP/MPLS VPNs) and not in the 1483 forwarding plane. The number of routes (100k) is smaller than the 1484 number of number of routes in the Internet (300k and rising) or in 1485 major VPN SP (>500k and rising) so the target can be handled with 1486 current implementations. In addition, AN routes are internal routes 1487 whose churn and instability is smaller and more under control than 1488 external routes. 1490 BGP Route Reflector (RR) 1492 NLRI : #AN ~ o(n) 1494 path : 2*#AN ~ o(2n) 1496 ABR handles both the core and aggregations routes. They do not 1497 depend on the total number of AN nodes, but only on the number of AN 1498 in their aggregation domain. 1500 ABR: 1502 IP FIB : 5*#Core + (5*#AGN + #AN) / #Area ~ o(#AN /#Area) 1504 MPLS LFIB : #Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) 1506 5.2.1.3. Aggregation Domain 1508 In the aggregation domain, IGP & LDP are not affected by the number 1509 of access nodes outside of their domain. They are not affected by 1510 the total number of AN nodes: 1512 IGP: 1514 node : #AGN / #Area ~ o(1) 1516 links : 3*#AGN / #Area ~ o(1) 1518 IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5 1519 / #Area) 1521 + + 1 loopback per core node + one aggregate per area + 5 1522 prefixes per AGN in the area + 1 prefix per AN in the area. 1524 LDP FEC: 1526 Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) 1528 + + 1 loopback per core node + 1 loopback per AGN & AN node in 1529 the area. 1531 AGN FIBs grows with the number of node in the core area, in their 1532 aggregation area, plus the number of inter domain LSP required by the 1533 AN attached to them. They do not depend on the total number of AN 1534 nodes. In the BGP control plane, AGN also needs to handle all the AN 1535 routes. 1537 AGN: 1539 IP FIB : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5/ 1540 #Area) 1542 MPLS LFIB : #Core + (#AGN + #AN) / #Area + 100 ~ o(#AN / #Area) 1544 AN FIBs grows with its connectivity requirement. They do not depend 1545 on the number of AN, AGN, SN or any others nodes. 1547 AN: 1549 IP RIB : 1 ~ o(1) 1550 MPLS LIB : 1k ~ o(1) 1552 IP FIB : 1 ~ o(1) 1554 MPLS LFIB : 1k ~ o(1) 1556 5.2.1.4. Summary 1558 AN requirements are kept minimal. BGP is not required and the size 1559 of their FIB is limited to their own connectivity requirements. 1561 In the core area, IGP and LDP are not affected by the node in the 1562 aggregation domains. In particular they do not grow with the number 1563 of AGN or AN. 1565 In the aggregation areas, IGP and LDP are affected by the number of 1566 core nodes and the number of AGN and AN in their area. They are not 1567 affected by the total number of AGN or AN in the seamless MPLS 1568 domain. 1570 No FIB of any node is required to handle the total number of AGN or 1571 AN in the seamless MPLS domain. In other word, the number of AGN and 1572 AN in the seamless MPLS domain is not limited, if the number of areas 1573 can grow accordingly. The main limitation is the MPLS connectivity 1574 requirements on the AN, i.e. mainly the number of LSP needed on the 1575 AN. Another limitation may be the number of different LSP needed by 1576 AN attached or behind an AGN. However, given foreseen deployments 1577 and current AGN capabilities, this is not expected to be a 1578 limitation. 1580 In the control plane, BGP will typically handle all AN routes. This 1581 is significant but target deployments are well under current 1582 equipments capacities. In addition, if required, additional 1583 techniques could be used to improve this scalability, based on the 1584 experience gained with scaling BGP/MPLS VPN (e.g. route partitioning 1585 between RR planes, route filtering (static or dynamic with ORF or 1586 route refresh) between AN and on AGN to improve AGN scalability. 1588 5.2.1.5. Numerical application for use case #1 1590 As a recap, targets for deployment scenario 1 are: 1592 o Number of Aggregation Domains 100 1594 o Number of Backbone Nodes 1.000 1596 o Number of AGgregation Nodes 10.000 1597 o Number of Access Nodes 100.000 1599 This gives the following scaling numbers for each category of nodes: 1601 o AN IP FIB 1 1603 o AN MPLS LFIB 1 000 1605 o AGN IP FIB 2 600 1607 o AGN MPLS LFIB 2 200 1609 o ABR IP FIB 7 600 1611 o ABR MPLS LFIB 2 100 1613 o TN IP FIB 5 000 1615 o TN MPLS LFIB 1 000 1617 o RR BGP NLRI 100 000 1619 o RR BGP paths 200 000 1621 5.2.1.6. Numerical application for use case #2 1623 As a recap, targets for deployment scenario 1 are: 1625 o Number of Aggregation Domains 30 1627 o Number of Backbone Nodes 150 1629 o Number of AGgregation Nodes 1.500 1631 o Number of Access Nodes 40.000 1633 This gives the following scaling numbers for each category of nodes: 1635 o AN IP FIB 1 1637 o AN MPLS LFIB 1 000 1639 o AGN IP FIB 1 700 1641 o AGN MPLS LFIB 1 800 1643 o ABR IP FIB 3 700 1644 o ABR MPLS LFIB 1 600 1646 o TN IP FIB 750 1648 o TN MPLS LFIB 150 1650 o RR BGP NLRI 40 000 1652 o RR BGP paths 80 000 1654 6. Acknowledgements 1656 Many people contributed to this document. The authors would like to 1657 thank Wim Henderickx, Robert Raszuk, Thomas Beckhaus, Wilfried Maas, 1658 Roger Wenner, Kireeti Kompella, Yakov Rekhter, Mark Tinka and Simon 1659 DeLord for their suggestions and review. 1661 7. IANA Considerations 1663 This memo includes no request to IANA. 1665 All drafts are required to have an IANA considerations section (see 1666 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 1667 for a guide). If the draft does not require IANA to do anything, the 1668 section contains an explicit statement that this is the case (as 1669 above). If there are no requirements for IANA, the section will be 1670 removed during conversion into an RFC by the RFC Editor. 1672 8. Security Considerations 1674 The Seamless MPLS Architecture is subject to similar security threats 1675 as any MPLS LDP deployment. It is recommended that baseline security 1676 measures are considered as described in the LDP specification RFC5036 1677 [RFC5036] including ensuring authenticity and integrity of LDP 1678 messages, as well as protection against spoofing and Denial of 1679 Service attacks. Some deployments may require increased measures of 1680 network security if a subset of Access Nodes are placed in locations 1681 with lower levels of physical security e.g. street cabinets ( common 1682 practice for VDSL access ). In such cases it is the responsibility 1683 of the system designer to take into account the physical security 1684 measures ( environmental design, mechanical or electronic access 1685 control, intrusion detection ), as well as monitoring and auditing 1686 measures (configuration and Operating System changes, reloads, routes 1687 advertisements ). But even with all this in mind, the designer still 1688 should consider network security risks and adequate measures arising 1689 from the lower level of physical security of those locations. 1691 8.1. Access Network Security 1693 A detailed description for Access Network Security in Seamless MPLS 1694 can be found in the LDP Downstream on Demand document 1695 [I-D.ietf-mpls-ldp-dod]. 1697 8.2. Data Plane Security 1699 Data plane security risks applicable to the access MPLS network are 1700 listed below (a non-exhaustive list): 1702 a. packets from a specific access node flow to an altered transport 1703 layer or service layer destination. 1705 b. packets belonging to undefined services flow to and from the 1706 access network. 1708 c. unlabelled packets destined to remote network nodes. 1710 Following mechanisms should be considered to address listed data 1711 plane security risks: 1713 1. addressing (a) - Access and ABR LSRs SHOULD NOT accept labeled 1714 packets over a particular data link, unless from the Access or 1715 ABR LSR perspective this data link is known to attach to a 1716 trusted system based on employed authentication mechanism(s), and 1717 the top label has been distributed to the upstream neighbour by 1718 the receiving Access or ABR LSR. 1720 2. addressing (a) - ABR LSR MAY restrict network reachability for 1721 access devices to a subset of remote network LSR, based on 1722 authentication or other network security technologies employed 1723 towards Access LSRs. Restricted reachability can be enforced on 1724 the ABR LSR using local routing policies, and can be distributed 1725 towards the core MPLS network using routing policies associated 1726 with access MPLS FECs. 1728 3. addressing (b) - labeled service routes (e.g. MPLS/VPN, tLDP) 1729 are not accepted from unreliable routing peers. Detection of 1730 unreliable routing peers is achieved by engaging routing protocol 1731 detection and alarm mechanisms, and is out of scope of this 1732 document. 1734 4. addressing (a) and (b) - no successful attacks have been mounted 1735 on the control plane and has been detected. 1737 5. addressing (c) - ABR LSR MAY restrict IP network reachability to 1738 and from the access LSR. 1740 8.3. Control Plane Security 1742 Similarly to Inter-AS MPLS/VPN deployments RFC4364 [RFC4364], the 1743 data plane security depends on the security of the control plane. To 1744 ensure control plane security access LDP DoD connections MUST only be 1745 made with LDP peers that are considered trusted from the local LSR 1746 perspective, meaning they are reachable over a data link that is 1747 known to attach to a trusted system based on employed authentication 1748 mechanism(s) on the local LSR. The TCP/IP MD5 authentication option 1749 RFC5925 [RFC5925] should be used with LDP as described in LDP 1750 specification RFC5036 [RFC5036]. If TCP/IP MD5 authentication is 1751 considered not secure enough, the designer may consider using a more 1752 elaborate and advanced TCP Authentication Option (TCP-AO RFC5925 1753 [RFC5925]) for LDP session authentication. Access IGP (if used) and 1754 any routing protocols used in access network for signalling service 1755 routes SHOULD also be secured in a similar manner. For increased 1756 level of authentication in the control plane security for a subset of 1757 access locations with lower physical security, designer could also 1758 consider using: 1760 o different crypto keys for use in authentication procedures for 1761 these locations. 1763 o stricter network protection mechanisms including DoS protection, 1764 interface and session flap dampening. 1766 9. References 1768 9.1. Normative References 1770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1771 Requirement Levels", BCP 14, RFC 2119, March 1997. 1773 9.2. Informative References 1775 [ABR-FRR] Rekhter, Y., "Local Protection for LSP tail-end node 1776 failure, MPLS World Congress 2009", . 1778 [ACM01] , , , , "Archieving sub-second IGP convergence in large IP 1779 networks, ACM SIGCOMM Computer Communication Review, v.35 1780 n.3", July 2005. 1782 [BGP-PIC] , "BGP PIC, Technical Report", November 2007. 1784 [I-D.draft-bashandy-bgp-edge-node-frr-03] 1785 , . 1787 [I-D.draft-bashandy-bgp-frr-mirror-table-00] 1788 , . 1790 [I-D.draft-ietf-rtgwg-remote-lfa-00] 1791 , . 1793 [I-D.draft-minto-2547-egress-node-fast-protection-00] 1794 , . 1796 [I-D.filsfils-rtgwg-lfa-applicability] 1797 Filsfils, C., Francois, P., Shand, M., Decraene, B., 1798 Uttaro, J., Leymann, N., and M. Horneffer, "LFA 1799 applicability in SP networks", draft-filsfils-rtgwg-lfa- 1800 applicability-00 (work in progress), March 2010. 1802 [I-D.ietf-bfd-v4v6-1hop] 1803 Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single 1804 Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress), 1805 January 2010. 1807 [I-D.ietf-mpls-ldp-dod] 1808 Beckhaus, T., Decraene, B., Tiruveedhula, K., 1809 Konstantynowicz, M., and L. Martini, "LDP Downstream-on- 1810 Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-06 (work 1811 in progress), May 2013. 1813 [I-D.kothari-henderickx-l2vpn-vpls-multihoming] 1814 Kothari, B., Kompella, K., Henderickx, W., and F. Balus, 1815 "BGP based Multi-homing in Virtual Private LAN Service", 1816 draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work 1817 in progress), July 2009. 1819 [I-D.narten-iana-considerations-rfc2434bis] 1820 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1821 IANA Considerations Section in RFCs", draft-narten-iana- 1822 considerations-rfc2434bis-09 (work in progress), March 1823 2008. 1825 [I-D.raggarwa-mac-vpn] 1826 Aggarwal, R., Isaac, A., Uttaro, J., Henderickx, W., and 1827 F. Balus, "BGP MPLS Based MAC VPN", draft-raggarwa-mac- 1828 vpn-01 (work in progress), June 2010. 1830 [I-D.sajassi-l2vpn-rvpls-bgp] 1831 Sajassi, A., Patel, K., Mohapatra, P., Filsfils, C., and 1832 S. Boutros, "Routed VPLS using BGP", draft-sajassi-l2vpn- 1833 rvpls-bgp-01 (work in progress), July 2010. 1835 [PE-FRR] Le Roux, J.L., Decraene, B., and Z. Ahmad, "Fast Reroute 1836 in MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS 1837 2006 Conference", . 1839 [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, 1840 June 1999. 1842 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1843 Label Switching Architecture", RFC 3031, January 2001. 1845 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 1846 BGP-4", RFC 3107, May 2001. 1848 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1849 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1850 Tunnels", RFC 3209, December 2001. 1852 [RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, 1853 F., and F. Ansari, "Overview of IP Multicast in a Multi- 1854 Protocol Label Switching (MPLS) Environment", RFC 3353, 1855 August 2002. 1857 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1858 Text on Security Considerations", BCP 72, RFC 3552, July 1859 2003. 1861 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1862 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 1863 2005. 1865 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1866 Networks (VPNs)", RFC 4364, February 2006. 1868 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1869 Specification", RFC 5036, October 2007. 1871 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 1872 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 1873 July 2008. 1875 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1876 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1878 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 1879 Multicast Encapsulations", RFC 5332, August 2008. 1881 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1882 Authentication Option", RFC 5925, June 2010. 1884 Authors' Addresses 1886 Nicolai Leymann (editor) 1887 Deutsche Telekom AG 1888 Winterfeldtstrasse 21 1889 Berlin 10781 1890 DE 1892 Phone: +49 30 8353-92761 1893 Email: n.leymann@telekom.de 1895 Bruno Decraene 1896 France Telecom 1897 38-40 rue du General Leclerc 1898 Issy Moulineaux cedex 9 92794 1899 FR 1901 Email: bruno.decraene@orange.com 1903 Clarence Filsfils 1904 Cisco Systems 1905 Brussels 1906 Belgium 1908 Email: cfilsfil@cisco.com 1910 Maciek Konstantynowicz (editor) 1911 Cisco Systems 1912 London 1913 United Kingdom 1915 Email: maciek@cisco.com 1917 Dirk Steinberg 1918 Steinberg Consulting 1919 Ringstrasse 2 1920 Buchholz 53567 1921 DE 1923 Email: dws@steinbergnet.net