idnits 2.17.1 draft-ietf-pals-endpoint-fast-protection-05.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 (January 3, 2017) is 2669 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Yimin Shen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Rahul Aggarwal 5 Expires: July 7, 2017 Arktan, Inc 6 Wim Henderickx 7 Nokia 8 Yuanlong Jiang 9 Huawei Technologies 10 January 3, 2017 12 PW Endpoint Fast Failure Protection 13 draft-ietf-pals-endpoint-fast-protection-05 15 Abstract 17 This document specifies a fast mechanism for protecting pseudowires 18 (PWs) transported by IP/MPLS tunnels against egress endpoint 19 failures, including egress AC (attachment circuit) failure, egress PE 20 (provider edge) failure, multi-segment PW terminating PE failure, and 21 multi-segment PW switching PE failure. Operating on the basis of 22 multi-homed CE (customer edge), redundant PWs, upstream label 23 assignment and context specific label switching, the mechanism 24 enables local repair to be performed by the router upstream adjacent 25 to a failure. The router can restore a PW in the order of tens of 26 milliseconds, by rerouting traffic around the failure to a protector 27 through a pre-established bypass tunnel. Therefore, the mechanism 28 can be used to reduce traffic loss before global repair reacts to the 29 failure and the network converges on the topology changes due to the 30 failure. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 7, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 68 3. Reference Models for Egress Endpoint Failures . . . . . . . . 4 69 3.1. Single-Segment PW . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Multi-Segment PW . . . . . . . . . . . . . . . . . . . . 8 71 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 9 72 4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2. Local Repair . . . . . . . . . . . . . . . . . . . . . . 10 74 4.3. Context Identifier . . . . . . . . . . . . . . . . . . . 13 75 4.3.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 13 76 4.3.2. FEC . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.3.3. IGP Advertisement and Path Computation . . . . . . . 15 78 4.4. Protection Models . . . . . . . . . . . . . . . . . . . . 16 79 4.4.1. Co-located Protector . . . . . . . . . . . . . . . . 16 80 4.4.2. Centralized Protector . . . . . . . . . . . . . . . . 17 81 4.5. Transport Tunnel . . . . . . . . . . . . . . . . . . . . 19 82 4.6. Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . 20 83 4.7. Examples of Forwarding State . . . . . . . . . . . . . . 21 84 4.7.1. Co-located Protector Model . . . . . . . . . . . . . 21 85 4.7.2. Centralized Protector Model . . . . . . . . . . . . . 25 86 5. Restorative and Revertive Behaviors . . . . . . . . . . . . . 28 87 6. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 29 88 6.1. Egress Protection Capability TLV . . . . . . . . . . . . 30 89 6.2. PW Label Distribution from Primary PE to Protector . . . 31 90 6.3. PW Label Distribution from Backup PE to Protector . . . . 31 91 6.4. Protection FEC Element TLV . . . . . . . . . . . . . . . 32 92 6.4.1. Encoding Format for PWid with IPv4 PE Addresses . . . 33 93 6.4.2. Encoding Format for Generalized PWid with IPv4 PE 94 Addresses . . . . . . . . . . . . . . . . . . . . . . 34 95 6.4.3. Encoding Format for PWid with IPv6 PE Addresses . . . 35 96 6.4.4. Encoding Format for Generalized PWid with IPv6 PE 97 Addresses . . . . . . . . . . . . . . . . . . . . . . 36 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 39 103 10.2. Informative References . . . . . . . . . . . . . . . . . 40 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 106 1. Introduction 108 Per [RFC3985, RFC4447, RFC5659], a pseudowire (PW) or PW segment can 109 be thought of as a connection between a pair of forwarders hosted by 110 two PEs, carrying an emulated layer-2 service over a packet switched 111 network (PSN). In the single-segment PW (SS-PW) case, a forwarder 112 binds a PW to an attachment circuit (AC). In the multi-segment PW 113 (MS-PW) case, a forwarder on a terminating PE (T-PE) binds a PW 114 segment to an AC, while a forwarder on a switching PE (S-PE) binds 115 one PW segment to another PW segment. In each direction between the 116 PEs, PW packets are transported by a PSN tunnel, which is also called 117 a transport tunnel. 119 In order to protect the PW service against network failures, it is 120 necessary to protect every link and node along the entire data path. 121 For the traffic in a given direction, this include ingress AC, 122 ingress (T-)PE, intermediate routers of transport tunnel, S-PEs, 123 egress (T-)PE, and egress AC. To minimize service disruption upon a 124 failure, it is also desirable that each of these components is 125 protected by a fast protection mechanism based on local repair. Such 126 mechanism generally involves a bypass path that is pre-computed and 127 pre-installed in the data plane on the router upstream adjacent to an 128 anticipated failure. This router is referred to as a "point of local 129 repair" (PLR). The bypass path has the property that it can guide 130 traffic around the failure, while remaining unaffected by the 131 topology changes resulting from the failure. When the failure 132 occurs, the PLR can invoke the bypass path to achieve fast 133 restoration for the service. 135 Today, fast protection against ingress AC failure and ingress (T-)PE 136 failure can be achieved by using a multi-homed CE and redundant ACs, 137 such as multi-chassis link aggregation group (MC-LAG). Fast 138 protection against the failure of an intermediate router of transport 139 tunnel can be achieved through RSVP fast-reroute [RFC4090] or IP/LDP 140 fast-reroute [RFC5714, RFC5286]. However, there is no equivalent 141 mechanism that can be used against an egress AC failure, an egress 142 (T-)PE failure, or an S-PE failure. For these failures, service 143 restoration has to rely on global repair or control plane 144 convergence. Global repair normally involves the ingress CE or the 145 ingress (T-)PE switching traffic to an alternative path, based on 146 remote failure detection via PW status notification, end-to-end OAM, 147 and others. Control plane convergence relies on control protocols to 148 react on the topology changes due to a failure. Compared to local 149 repair, these mechanisms are relatively slow in reacting to a failure 150 and restoring traffic. 152 This document is intended to serve the above need. It specifies a 153 fast protection mechanism based on local repair to protect PWs 154 against the following endpoint failures. 156 a. Egress AC failure. 158 b. Egress PE failure: Link or node failure of an egress PE of an SS- 159 PW, or a T-PE of an MS-PW. 161 c. Switching PE (S-PE) failure: Link or node failure of an S-PE of 162 an MS-PW. 164 The mechanism is applicable to LDP signaled PWs. It is relevant to 165 networks with redundant PWs and multi-homed CEs. It is designed on 166 the basis of MPLS upstream label assignment and context-specific 167 label switching [RFC5331]. Fast protection refers to its ability to 168 restore traffic in the order of tens of milliseconds. Compared with 169 global repair and control plane convergence, this mechanism can 170 provide faster service restoration. However, it is intended to 171 complement these mechanisms, rather than replacing them, as networks 172 rely on them to eventually move traffic to fully functional 173 alternative paths. 175 2. Specification of Requirements 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC2119. 181 3. Reference Models for Egress Endpoint Failures 183 This document refers to the following topologies to describe egress 184 endpoint failures and protection procedures. 186 3.1. Single-Segment PW 187 |<-------------- PW1 --------------->| 189 - PE1 -------------- P1 ---------------- PE2 - 190 / \ 191 / \ 192 CE1 CE2 193 \ / 194 \ / 195 - PE3 -------------- P2 ---------------- PE4 - 197 |<-------------- PW2 --------------->| 199 Figure 1 201 In Figure 1, the IP/MPLS network consists of PE and P routers. It 202 provides a PW service between CE1 and CE2. Each CE is multi-homed 203 via two ACs to two PEs. This forms two divergent paths between the 204 CEs. The first path uses PW1 between PE1 and PE2, and the second 205 path uses PW2 between PE3 and PE4. The transport tunnels of the PWs 206 and other links between the routers are not shown in this figure for 207 clarity. 209 In general, a CE may operate the ACs in two modes when sending 210 traffic to the remote CE, i.e. active-standby mode and active-active 211 mode. 213 o In the active-standby mode, the CE chooses one AC as active AC and 214 the corresponding path as active path, and uses the other AC as 215 standby AC and the corresponding path as standby path. The CE 216 only sends traffic on the active AC as long as the active path is 217 operational. The CE will only send traffic on the standby AC 218 after it detects a failure of the active path. Note that the CE 219 may receive traffic on the active or standby AC, depending on 220 whether the remote CE chooses the same active path for the traffic 221 of the reverse direction. In this document, even if both CEs 222 choose the same active path, each CE should still anticipate 223 receiving traffic on a standby AC, because the traffic may be 224 redirected to the standby path by the fast protection mechanism. 226 o In the active-active mode, the CE treats both ACs and their 227 corresponding paths as active, and sends traffic on both ACs in a 228 load balance fashion. In the reverse direction, the CE may 229 receive traffic on both ACs. 231 The above modes assume the traffic to be data traffic which is not 232 bound to specific AC. This does not include control protocol traffic 233 between the CEs, when the CE-CE control protocol sessions or 234 adjacencies established on the two ACs are considered as distinct, 235 rather than having a primary and backup relationship. In general, a 236 dual-homed CE should not make any explicit or implicit assumptions 237 regarding specific AC from which it receives packets from the remote 238 CE. 240 For either mode, when considering the traffic flowing in a given 241 direction over an active path, this document views the ACs, PEs and 242 PWs to serve primary or backup roles. In particular, the ACs, PEs 243 and PW along this active path have primary roles, while those along 244 the other path have backup roles. Note that in the active-active 245 mode, each AC, PE, and PW on an active path has a primary role, and 246 also a backup role protecting the other path which is also active. 248 For Figure 1, the following roles are assumed for the traffic going 249 from CE1 to CE2 via PW1. 251 Primary ingress AC: CE1-PE1 253 Primary ingress PE: PE1 255 Primary PW: PW1 257 Primary egress PE: PE2 259 Primary egress AC: PE2-CE2 261 Backup ingress AC: CE1-PE3 263 Backup ingress PE: PE3 265 Backup PW: PW2 267 Backup egress PE: PE4 269 Backup egress AC: PE4-CE2 271 Based on this schema, this document describes egress endpoint 272 failures and the fast protection mechanism on the per-active-path and 273 per-direction basis. In this case, an egress AC failure refers to 274 the failure of the AC PE2-CE2, and an egress node failure refers to 275 the failure of PE2. The ultimate goal is that when a failure occurs, 276 the traffic should be locally repaired, so that it can eventually 277 reach CE2 via the backup egress PE (PE4) and the backup egress AC 278 (PE4-CE2). 280 Subsequent to the local repair, either the current active path should 281 heal after control plane converges on the new topology, or the 282 ingress CE should switch traffic from the primary path to the backup 283 path, depending on the failure scenario. In the latter case, the 284 ingress CE may perform the path switchover triggered by end-to-end 285 OAM (in-band or out-band), PW status notification, CE-PE control 286 protocols (e.g. LACP), and others. In the active-standby mode, this 287 will promote the standby path to new active path. In the active- 288 active mode, it will make the other active path carry all the traffic 289 between the two CEs. In any case, this phase of restoration falls 290 into the control plane convergence and global repair category, and 291 hence is out of the scope of this document. The purpose of the fast 292 protection mechanism in this document is to reduce traffic loss 293 before this phase of restoration takes place. 295 Note that in Figure 1, if the traffic in the reverse direction (i.e. 296 from CE2 to CE1) traverses the AC CE2-PE2 and PE2 as active path, the 297 failure of PE2 and the failure of the AC PE2-CE2 will be considered 298 as ingress failures of the traffic. If CE2 can detect the failures, 299 it may protect the traffic by switching it to the backup path via the 300 AC CE2-PE4 and PE4. However, this is categorized as ingress endpoint 301 failure protection, and hence is not handled by the mechanism 302 described in this document. 304 Figure 2 shows another possible scenario, where CE1 is single-homed 305 to PE1, while CE2 remains multi-homed to PE2 and PE4. From the 306 perspective of egress endpoint protection for the traffic going from 307 CE1 to CE2 over PW1, this scenario is the same as the scenario shown 308 in Figure 1. 310 |<-------------- PW1 --------------->| 312 ------------- P1 ---------------- PE2 - 313 / \ 314 / \ 315 CE1 -- PE1 CE2 316 \ / 317 \ / 318 ------------- P2 ---------------- PE4 - 320 |<-------------- PW2 --------------->| 322 Figure 2 324 For clarity, primary egress AC, primary egress PE, backup egress AC, 325 and backup egress PE may simply be referred to as primary AC, primary 326 PE, backup AC, and backup PE, respectively, when the context of a 327 discussion is egress endpoint. 329 3.2. Multi-Segment PW 331 |<--------------- PW1 --------------->| 332 |<----- SEG1 ----->|<----- SEG2 ----->| 334 - TPE1 -------------- SPE1 --------------- TPE2 - 335 / \ 336 / \ 337 CE1 CE2 338 \ / 339 \ / 340 - TPE3 -------------- SPE2 --------------- TPE4 - 342 |<----- SEG3 ----->|<----- SEG4 ----->| 343 |<--------------- PW2 --------------->| 345 Figure 3 347 Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW 348 environment. PW1 and PW2 are both MS-PWs. PW1 is established 349 between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at 350 SPE1. PW2 is established between TPE3 and TPE4, and switched between 351 segments SEG3 and SEG4 at SPE2. CE1 is multi-homed to TPE1 and TPE3. 352 CE2 is multi-homed to TPE2 and TPE4. The transport tunnels of the PW 353 segments are not shown in this figure for clarity. 355 In this document, the following primary and backup roles are assigned 356 for the traffic going from CE1 to CE2: 358 Primary ingress AC: CE1-TPE1 360 Primary ingress T-PE: TPE1 362 Primary PW: PW1 364 Primary S-PE: SPE1 366 Primary egress T-PE: TPE2 368 Primary egress AC: TPE2-CE2 370 Backup ingress AC: CE1-TPE3 372 Backup ingress T-PE: TPE3 374 Backup PW: PW2 376 Backup S-PE: SPE2 377 Backup egress T-PE: TPE4 379 Backup egress AC: TPE4-CE2 381 In this case, an egress AC failure refers to the failure of the AC 382 TPE2-CE2. An egress node failure refers to the failure of TPE2. An 383 S-PE failure refers to the failure of SPE1. 385 For consistency with the SS-PW scenario, primary T-PEs and a primary 386 S-PEs may simply be referred to as primary PEs in this document, 387 where specifics are not required. Similarly, backup T-PEs and backup 388 S-PEs may be referred to as backup PEs. 390 4. Theory of Operation 392 The fast protection mechanism in this document provides three types 393 of protection for PWs, corresponding to the three types of failures 394 described in Section 1. 396 a. Egress AC protection 398 b. Egress (T-)PE node protection 400 c. S-PE node protection 402 4.1. Applicability 404 The mechanism is applicable to LDP signaled PWs in an environment 405 where an egress CE is multi-homed to a primary PE and a backup PE and 406 there exists a backup PW, as described in Section 3. The procedure 407 for S-PE node protection is applicable when there exists a backup 408 S-PE on the backup PW. 410 The mechanism assumes IP/MPLS transport tunnels, and is applicable to 411 tunnels with single path and ECMPs (equal cost multiple paths). As 412 an example of ECMPs, imagine a tunnel carrying one or multiple PWs 413 and traversing a router with ECMPs to a primary PE. The ECMPs 414 consist of at least one direct link to the PE, and some multi-hop 415 paths to the PE. Due to the direct link, the router is considered as 416 a penultimate hop of the tunnel, and can perform local detection and 417 repair for an egress node failure. The router normally uses a 418 hashing algorithm to distribute PW packets over the ECMPs, on a per- 419 PW or per-flow basis. Upon a failure of the direct link, i.e. 420 transit link failure, the router removes the link from the hashing 421 algorithm, which automatically redistributes the traffic of the link 422 to the other paths of the ECMPs, achieving local repair. This 423 scenario is not the focus of this document. Upon a failure of the 424 PE, i.e. egress node failure, the router SHOULD perform local repair 425 by rerouting the entire traffic of the ECMPs, as the failure will 426 affect every path. If the router does not have a fast or reliable 427 mechanism to detect the egress node failure, it is RECOMMENDED that 428 the router SHOULD treat the failure of the direct link as an egress 429 node failure. 431 The mechanism is applicable to both best-effort and traffic 432 engineering (TE) transport tunnels. For TE transport tunnels which 433 require bandwidth protection, TE bypass tunnels with reserved 434 bandwidth MAY be used to avoid congestion for rerouted traffic. 436 It is also RECOMMENDED that the mechanism SHOULD be used in 437 conjunction with global repair and control plane convergence, in such 438 a manner that the mechanism temporarily repairs a failed path by 439 using a bypass tunnel, and global repair and control plane 440 convergence eventually move traffic to a fully functional alternative 441 path. 443 4.2. Local Repair 445 The fast protection ability of the mechanism comes from local repair 446 performed by routers upstream adjacent to failures. Each of these 447 routers is referred to as a "point of local repair" (PLR). A PLR 448 MUST be able to detect a failure by using a rapid mechanism, such as 449 physical layer failure detection, Bidirectional Forwarding Detection 450 (BFD) [RFC5880], Seamless BFD (S-BFD) [RFC7880], and others. In 451 anticipation of the failure, the PLR MUST also pre-establish a bypass 452 tunnel to a "protector", and pre-install a bypass route for the 453 bypass tunnel in the data plane. The protector is either a backup PE 454 or a router which will forward traffic to a backup PE. The bypass 455 tunnel MUST have the property that it will not be affected by the 456 topology changes due to the failure. Specifically, it MUST NOT 457 traverse the primary PE or the penultimate link of the protected 458 transport tunnel, or share any SRLG (shared risk link groups) with 459 the penultimate link. Upon detecting the failure, the PLR invokes 460 the bypass route in the data plane, and reroutes PW traffic to the 461 protector through the bypass tunnel. The protector in turn sends the 462 traffic to the target CE. This procedure is referred to as local 463 repair. 465 Different routers may serve as PLR and protector in different 466 scenarios. 468 o In egress AC protection, the PLR is the primary PE, and the 469 protector is the backup PE (Figure 4). 471 |<-------------- PW1 --------------->| 473 - PE1 -------------- P1 ---------------- PE2 - 474 / PLR \ 475 / | \ 476 CE1 bypass| CE2 477 \ | / 478 \ | / 479 - PE3 -------------- P2 ---------------- PE4 - 480 protector 482 |<-------------- PW2 --------------->| 484 Figure 4 486 o In egress PE node protection, the PLR is the penultimate hop 487 router of the transport tunnel of the primary PW, and the 488 protector is the backup PE (Figure 5). 490 |<-------------- PW1 --------------->| 492 - PE1 -------------- P1 ------- P3 ----- PE2 - 493 / PLR \ \ 494 / \ \ 495 CE1 bypass\ CE2 496 \ \ / 497 \ \ / 498 - PE3 -------------- P2 ---------------- PE4 - 499 protector 501 |<-------------- PW2 --------------->| 503 Figure 5 505 o In S-PE node protection, the PLR is the penultimate hop router of 506 the transport tunnel of the primary PW segment, and the protector 507 is the backup S-PE (Figure 6). 509 |<--------------- PW1 --------------->| 510 |<----- SEG1 ----->|<----- SEG2 ----->| 512 - TPE1 ----- P1 ----- SPE1 -------------- TPE2 - 513 / PLR \ \ 514 / \ \ 515 CE1 bypass\ CE2 516 \ \ / 517 \ \ / 518 - TPE3 --------------- SPE2 -------------- TPE4 - 519 protector 521 |<----- SEG3 ----->|<----- SEG4 ----->| 522 |<--------------- PW2 --------------->| 524 Figure 6 526 In egress AC protection, a PLR realizes its role based on 527 configuration of a "context identifier" introduced in this document 528 (Section 4.3). The PLR establishes a bypass tunnel to the protector 529 in the same fashion as a normal PSN tunnel. 531 In egress PE and S-PE node protection, a PLR is a transit router on 532 the transport tunnel, and it normally does not have knowledge of the 533 PW(s) carried by the transport tunnel. In this document, the PLR 534 simply computes and establishes a node protection bypass tunnel in 535 the same fashion as the normal IP/MPLS node protection, except that 536 with the notion of context identifier, the bypass tunnel will be 537 established from the PLR to the protector (Section 4.6). Conversely, 538 when the router is no longer a PLR for egress PE or S-PE node 539 protection due to a change in network topology or the transport 540 tunnel's path, the router should revert to the role of regular 541 transit router, including PLR for transit link and node protection. 543 In local repair, a PLR simply switches all the traffic received on 544 the transport tunnel to the bypass tunnel. This requires that the 545 protector given by the bypass tunnel MUST be intended for all the PWs 546 carried by the transport tunnel. This is achieved by the ingress PE 547 using a context identifier to associate a PW with the specific pair 548 of {primary PE, protector} and map the PW to a transport tunnel 549 destined for the same {primary PE, protector}. The ingress PE MAY map 550 multiple PWs to the transport tunnel, if they share the {primary PE, 551 protector} in common. 553 In local repair, the PLR keeps PW label intact in packets. This 554 obviates the need for the PLR to maintain bypass routes on a per-PW 555 basis, and allows bypass tunnel sharing between PWs. On the other 556 hand, this imposes a requirement on the protector that it MUST be 557 able to forward the packets based on a PW label that is assigned by 558 the primary PE, and ensure that the traffic MUST reach the target CE 559 via a backup path. From the protector's perspective, this PW label 560 is an upstream assigned label [RFC5331]. To achieve this, the 561 protector MUST learn the PW label from the primary PE prior to the 562 failure, and install proper forwarding state for the PW label in a 563 dedicated label space associated with the primary PE. During local 564 repair, the protector MUST perform PW label lookup in this label 565 space. 567 The previous examples have shown the scenarios where the protectors 568 are backup (T/S-)PEs. It is also possible that a protector is a 569 dedicated router to serve such role, separate from the backup (T/ 570 S-)PE. During local repair, the PLR still reroutes traffic to the 571 protector through a bypass tunnel. The protector then forwards the 572 traffic to the backup (T/S-)PE, which further forwards the traffic to 573 the target CE via a backup AC or a backup PW segment. More detail 574 will be described in Section 4.4. 576 4.3. Context Identifier 578 A protector may protect multiple primary PEs. The protector MUST 579 maintain a separate label space for each primary PE. Likewise, the 580 PWs terminated on a primary PE may be protected by multiple 581 protectors, each for a subset of the PWs. In any case, a given PW 582 MUST be associated with one and only one pair of {primary PE, 583 protector}. 585 This document introduces the notion of "context identifier" to 586 facilitate protection establishment. A context identifier is an 587 IPv4/v6 address assigned to each ordered pair of {primary PE, 588 protector}. The address MUST be globally unique, or unique in the 589 address space of the network where the primary PE and the protector 590 reside. 592 4.3.1. Semantics 594 The semantics of a context identifier is twofold. 596 o A context identifier identifies a primary PE and an associated 597 protector. It represents the primary PE as PW destination on a 598 per protector basis. A given primary PE may be protected by 599 multiple protectors, each for a subset of the PWs terminated on 600 the primary PE. A distinct context identifier MUST be assigned to 601 each {primary PE, protector} pair. 603 The ingress PE of a PW learns the context identifier of the PW's 604 {primary PE, protector} from the primary PE via Interface_ID TLV 606 [RFC3471, RFC3472] in the LDP Label Mapping message of the PW. 607 The ingress PE then sets up or resolves a transport tunnel with 608 the context identifier, rather than a private IP address of the 609 primary PE, as destination. This destination not only makes the 610 transport tunnel reach the primary PE, but also conveys the 611 identity of the protector to the PLR, which MUST use the context 612 identifier as destination for the bypass tunnel to the protector. 613 The ingress PE MUST map only the PWs terminated by the exact 614 primary PE and protected by the exact protector to the transport 615 tunnel. 617 o A context identifier indicates the primary PE's label space on the 618 protector. The protector may protect PWs for multiple primary 619 PEs. For each primary PE, it MUST maintain a separate label space 620 to store the PW labels assigned by that primary PE. It associates 621 a PW label with a label space via the context identifier of the 622 {primary PE, protector}, as below. 624 In addition to the normal LDP PW signaling, the primary PE MUST 625 have a targeted LDP session with the protector, and advertise PW 626 labels to the protector via LDP Label Mapping messages 627 (Section 6). The primary PE MUST attach the context identifier to 628 each message. Upon receiving the message, the protector MUST 629 install the advertised PW label in the label space identified by 630 the context identifier. 632 When a PLR sets up or resolves a bypass tunnel to the protector, 633 it MUST use the context identifier rather than a private IP 634 address of the protector as destination. The protector MUST use 635 the bypass tunnel, either the MPLS tunnel label or IP tunnel 636 destination address, as the pointer to the corresponding label 637 space. The protector MUST forward PW packets received on the 638 bypass tunnel based on label lookup in that label space. 640 4.3.2. FEC 642 In an MPLS network, a context identifier represents a FEC (Forwarding 643 Equivalence Class) for transport tunnels and bypass tunnels destined 644 for it. For examples, it may be encoded in an LDP Prefix FEC 645 Element, or in the "tunnel end point address" of an RSVP Session 646 object. The FEC is associated with unique forwarding state on PLRs 647 and protector, which cannot be shared with other FECs. Some MPLS 648 protocols (e.g. LDP) support FEC aggregation [RFC3031]. In this 649 case, FEC aggregation MUST NOT be applied to a context identifier's 650 FEC, and every router MUST assign a unique label to the FEC. 652 4.3.3. IGP Advertisement and Path Computation 654 Using a context identifier as destination for both transport tunnel 655 and bypass tunnel requires coordination between the primary PE and 656 the protector in IGP advertisement of the context identifier in 657 routing domain and TE domain. The context identifier should be 658 advertised in such a way that all the routers on the tunnels MUST be 659 able to independently reach the following common view of paths. 661 o The transport tunnel MUST have the primary PE as path endpoint. 663 o The bypass tunnel MUST have the protector as path endpoint. In 664 egress PE and S-PE node protection, the path MUST avoid the 665 primary PE. 667 There are generally two categories of approaches to achieve the 668 above. 670 o The first category does not require an ingress PE or a PLR to have 671 knowledge of the PW egress endpoint protection schema. It does 672 not require any IGP extension for context identifier 673 advertisement. A context identifier is advertised by the primary 674 PE and the protector as an address reachable via both routers. 675 The ingress PE and the PLR can compute paths by using a normal 676 method, such as Dijkstra, CSPF (constrained shortest path first), 677 LFA [RFC5286] and MRT [RFC7812]. One example is to advertise a 678 context identifier as a virtual proxy node connected to the 679 primary PE and the protector, with the link between the proxy node 680 and the primary PE having a more preferable IGP and TE metric than 681 the link between the proxy node and the protector. The transport 682 tunnel will follow the shortest path or a TE path to the primary 683 PE, and be terminated by the primary PE. The PLR will no longer 684 view itself as a penultimate hop of the transport tunnel, but 685 rather two hops away from the proxy node, via the primary PE. 686 Hence, a node protection bypass tunnel will be available via the 687 protector to the proxy node, but actually be terminated by the 688 protector. 690 o The second category requires a PLR to have knowledge of the PW 691 egress endpoint protection schema. The primary PE advertises the 692 context identifier as a regular IP address, while the protector 693 advertises it by using an explicit "context identifier" object, 694 which MUST be understood by the PLR. The "context identifier" 695 object requires an IGP extension. In both the routing domain and 696 the TE domain, the context identifier is only reachable via the 697 primary PE. This ensures that the transport tunnel is terminated 698 by the primary PE. The PLR views itself as the penultimate hop of 699 the transport tunnel, and based on the IGP "context identifier" 700 object, it establishes or resolves a bypass tunnel to the 701 advertiser (i.e. the protector), while avoiding the primary PE. 703 The mechanism in this document intends to be flexible on the approach 704 used by a network, as long as it satisfies the above requirements for 705 transport tunnel path and bypass tunnel path. In theory, the network 706 can use one approach for context ID X and another approach for 707 context ID Y. For a given context ID, all relevant routers, 708 including primary PE, protector, and PLR, must support and agree on 709 the chosen approach. The coordination between the routers can be 710 achieved by configuration. 712 4.4. Protection Models 714 There are two protection models based on the location of a protector. 715 A network MAY use either model or both. 717 4.4.1. Co-located Protector 719 In this model, the protector is a backup PE that is directly 720 connected to the target CE via a backup AC, or it is a backup S-PE on 721 a backup PW. That is, the protector is co-located with the backup 722 (S-)PE. Examples of this model have been shown in Figure 4, Figure 5 723 and Figure 6 in Section 4.2. 725 In egress AC protection and egress PE node protection, when a 726 protector receives traffic from the PLR, it forwards the traffic to 727 the CE via the backup AC. This is shown in Figure 7, where PE2 is 728 the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4 729 (backup PE) is the protector. 731 |<-------------- PW1 --------------->| 733 - PE1 -------------- P1 ------- P3 ----- PE2 ---- 734 / PLR \ PLR \ 735 / \ | \ 736 CE1 bypass\ |bypass CE2 737 \ \ | / 738 \ \ | / 739 - PE3 -------------- P2 ---------------- PE4 ---- 740 protector 742 |<-------------- PW2 --------------->| 744 Figure 7 746 In S-PE node protection, when a protector receives traffic from the 747 PLR, it forwards the traffic over the next segment of the backup PW. 749 The T-PE of the backup PW in turn forwards the traffic to the CE via 750 a backup AC. This is shown in Figure 8, where P1 is the PLR for SPE1 751 failure, and SPE2 (backup S-PE) is the protector for SPE1. SPE2 752 receives traffic from P1, swaps SEG1's label to SEG4's label, and 753 forwards the traffic over a transport tunnel to TPE4. 755 |<--------------- PW1 --------------->| 756 |<----- SEG1 ----->|<----- SEG2 ----->| 758 - TPE1 ----- P1 ----- SPE1 -------------- TPE2 - 759 / PLR \ \ 760 / \ \ 761 CE1 bypass\ CE2 762 \ \ / 763 \ \ / 764 - TPE3 --------------- SPE2 -------------- TPE4 - 765 protector 767 |<----- SEG3 ----->|<----- SEG4 ----->| 768 |<--------------- PW2 --------------->| 770 Figure 8 772 In the co-located protector model, the number of context identifiers 773 needed by a network is the number of distinct {primary PE, backup PE} 774 pairs. From the perspective of scalability, the model is suitable 775 for networks where the number of primary PEs and the average number 776 of backup PEs per primary PE are both relatively low. 778 4.4.2. Centralized Protector 780 In this model, the protector is a dedicated P router or PE router 781 that serves the role. In egress AC protection and egress PE node 782 protection, the protector may or may not be a backup PE directly 783 connected to the target CE. In S-PE node protection, the protector 784 may or may not be a backup S-PE on the backup PW. 786 In egress AC protection and egress PE node protection, if the 787 protector is not directly connected to the CE, it forwards the 788 traffic to a backup PE, which in turn forwards the traffic to the CE 789 via a backup AC. This is shown in Figure 9, where the protector 790 receives traffic from P3 (PLR for egress PE failure) or PE2 (PLR for 791 egress AC failure), swaps PW1's label to PW2's label, and forwards 792 the traffic via a transport tunnel to PE4 (backup PE). The protector 793 may be protecting other PWs and other primary PEs as well, which is 794 not shown in this figure for clarity. 796 |<------------- PW1 --------------->| 798 - PE1 ------------- P1 ------- P3 ----- PE2 -- 799 / PLR \ PLR \ 800 / \ / \ 801 / bypass\ /bypass \ 802 / \ / \ 803 CE1 protector CE2 804 \ \ / 805 \ transport\ / 806 \ tunnel \ / 807 \ \ / 808 - PE3 ------------- P2 -----------------PE4 -- 810 |<------------- PW2 --------------->| 812 Figure 9 814 In S-PE node protection, if the protector is not a backup S-PE, it 815 forwards the traffic to the backup S-PE, which in turn forwards the 816 traffic over the next segment of the backup PW. Finally, the T-PE of 817 the backup PW forwards the traffic to the CE via the backup AC. This 818 is shown in Figure 10, where the protector receives traffic from P1 819 (PLR), swaps SEG1's label to SEG3's label, and forwards the traffic 820 via a transport tunnel to SPE2 (backup S-PE). SPE2 in turn performs 821 MS-PW switching from SEG3's label to SEG4's label, and forwards the 822 traffic over a transport tunnel to TPE4 (backup T-PE). The protector 823 may be protecting other PW segments and other primary S-PEs as well, 824 which is not shown in this figure for clarity. 826 |<--------------- PW1 --------------->| 827 |<----- SEG1 ----->|<----- SEG2 ----->| 829 - TPE1 ----- P1 ----- SPE1 -------------- TPE2 - 830 / PLR \ \ 831 / \ \ 832 / bypass\ \ 833 / \ \ 834 CE1 protector CE2 835 \ \ / 836 \ transport\ / 837 \ tunnel \ / 838 \ \ / 839 - TPE3 --------------- SPE2 -------------- TPE4 - 841 |<----- SEG3 ----->|<----- SEG4 ----->| 842 |<--------------- PW2 --------------->| 844 Figure 10 846 The centralized protector model allows multiple primary PEs to share 847 one protector. Each primary PE may need only one protector. 848 Therefore, the number of context identifiers needed by a network may 849 be bound to the number of primary PEs. 851 4.5. Transport Tunnel 853 A PW is associated with a pair of {primary PE, protector}, which is 854 represented by a unique context identifier. The ingress PE of the PW 855 sets up or resolves a transport tunnel by using the context 856 identifier rather than a private IP address of the primary PE as 857 destination. This not only ensures that the PW is transported to the 858 primary PE, but also facilitates bypass tunnel establishment at PLR, 859 because the context identifier contains the identity of the protector 860 as well. This is also the case for a multi-segment PW, where the 861 ingress PE and egress PE are T/S-PEs. 863 An ingress PE learns the association between a PW and a context 864 identifier from the primary PE, which MUST advertise the context 865 identifier as a "third party next hop" via the IPv4/v6 Interface_ID 866 TLV [RFC3471, RFC3472] in the LDP Label Mapping message of the PW. 868 In an ECMP scenario, a transport tunnel may have multiple penultimate 869 hop routers. Each of them SHOULD act as a PLR independently. Also 870 in an ECMP scenario, a penultimate hop router may have ECMPs to the 871 primary PE. At least one path of the ECMPs must be a direct link to 872 the primary PE, qualifying the router as a penultimate hop. The 873 other paths of the ECMPs may be direct links or indirect paths to the 874 primary PE. In egress PE node protection and S-PE node protection, 875 when a node failure is detected, or a link failure is detected on a 876 direct link and treated as a node failure, the penultimate hop router 877 SHOULD act as a PLR and reroute the entire traffic of the ECMPs to 878 the protector. 880 4.6. Bypass Tunnel 882 A PLR may protect multiple PWs associated with one or multiple pairs 883 of {primary PE, protector}. The PLR MUST establish a bypass tunnel to 884 each protector for each context identifier associated with that 885 protector. The destination of the bypass tunnel MUST be the context 886 identifier (Section 4.3.1). Since the PLR is a transit router of the 887 transport tunnel, it SHOULD derive the context identifier from the 888 destination of the transport tunnel. 890 For examples, in Figure 7 and Figure 9, a bypass tunnel is 891 established from PE2 (PLR for egress AC failure) to the protector, 892 and another bypass tunnel is established from P3 (PLR for egress node 893 failure) to the protector. In Figure 8 and Figure 10, a bypass 894 tunnel is established from P1 (PLR for S-PE failure) to the 895 protector. 897 In local repair, a PLR reroutes traffic to the protector through a 898 bypass tunnel, with PW label intact in the packets. This normally 899 involves pushing a label to the label stack, if the bypass tunnel is 900 an MPLS tunnel, or pushing an IP header to the packets, if the bypass 901 tunnel is an IP tunnel. Upon receipt of the packets, the protector 902 forwards them based on the PW label. Specifically, the protector 903 uses the bypass tunnel as a context to determine the primary PE's 904 label space. If the bypass tunnel is an MPLS tunnel, the protector 905 should have assigned a non-reserved label to the bypass tunnel, and 906 hence this label can serve as the context. This label is also called 907 a "context label", as it is actually bound to the context identifier. 908 If the bypass tunnel is an IP tunnel, the context identifier should 909 be the destination address of IP header. 911 To be useful for local repair, a bypass tunnel MUST have the property 912 that it is not affected by any topology changes caused by the 913 failure. It MUST NOT traverse the primary PE or the penultimate link 914 of the transport tunnel, or share any SRLG with the penultimate link. 915 A bypass tunnel may be a TE tunnel with reserved bandwidth to avoid 916 traffic congestion for rerouted traffic. A bypass tunnel should 917 remain effective during local repair, until the traffic is moved to 918 an alternative path, i.e. either the same PW over a fully functional 919 transport tunnel, or another fully functional PW. 921 There is little or no benefit to protect a bypass tunnel. Therefore, 922 a bypass tunnel SHOULD NOT be protected against a transit link 923 failure, transit node failure, or egress node failure. 925 4.7. Examples of Forwarding State 927 This section provides some detailed examples of forwarding state on 928 PLR, protector, and other relevant routers. 930 A protector learns PW labels from all the primary PEs that it 931 protects (Section 6.2), and maintains the PW labels in separate label 932 spaces on a per primary PE basis. In the control plane, each label 933 space is identified by the context identifier of the corresponding 934 {primary PE, protector}. In the forwarding plane, the label space is 935 indicated by the bypass tunnel(s) destined for the context 936 identifier. 938 4.7.1. Co-located Protector Model 940 In Figure 11, PE4 is a co-located protector that protects PW1 against 941 egress AC failure and egress node failure. It maintains a label 942 space for PE2, which is identified by the context identifier of {PE2, 943 PE4}. It learns PW1's label from PE2, and installs an forwarding 944 entry for the label in that label space. The nexthop of the 945 forwarding entry indicates a label pop with outgoing interface 946 pointing to the backup AC PE4-CE2. 948 |<-------------- PW1 --------------->| 950 - PE1 -------------- P1 ------- P3 ----- PE2 ------ 951 / PLR \ PLR \ 952 / \ | \ 953 / \ | \ 954 CE1 bypass P4 P5 bypass CE2 955 \ \ | / 956 \ \ | / 957 \ \ | / 958 - PE3 -------------- P2 ---------------- PE4 ------ 959 protector 961 |<-------------- PW2 --------------->| 963 PW1's label assigned by PE2: 100 964 PW2's label assigned by PE4: 200 965 On P3: 966 Incoming label of transport tunnel to PE2: 1000 967 Outgoing label of transport tunnel to PE2: implicit null 968 Outgoing label of bypass tunnel to PE4: 2000 969 On PE2: 970 Outgoing label of bypass tunnel to PE4: 3000 971 On PE4: 972 Context label (incoming label of bypass tunnels): 999 974 Forwarding state on P3: 975 label 1000 -- primary nexthop: pop, to PE2 976 backup nexthop: swap 2000, to P4 978 Forwarding state on PE2: 979 label 100 -- primary nexthop: pop, to CE2 980 backup nexthop: push 3000, to P5 982 Forwarding state on P4: 983 label 2000 -- nexthop: swap 999, to PE4 985 Forwarding state on P5: 986 label 3000 -- nexthop: swap 999, to PE4 988 Forwarding state on PE4: 989 label 200 -- nexthop: pop, to CE2 990 label 999 -- nexthop: label table of PE2's label space 992 Label table of PE2's label space on PE4: 993 label 100 -- nexthop: pop, to CE2 995 Figure 11 997 In Figure 12, SPE2 is a co-located protector that protects PW1 998 against S-PE failure. It maintains a label space for SPE1, which is 999 identified by the context identifier of {SPE1, SPE2}. It learns 1000 SEG1's label from SPE1, and installs a forwarding entry in the label 1001 space. The nexthop of the forwarding entry indicates a label swap to 1002 SEG4's label and a label push with the label of a transport tunnel to 1003 TPE4. 1005 |<--------------- PW1 --------------->| 1006 |<----- SEG1 ----->|<----- SEG2 ----->| 1008 - TPE1 ----- P1 ----- SPE1 --- P3 ------- TPE2 - 1009 / PLR \ \ 1010 / \ \ 1011 CE1 bypass P2 CE2 1012 \ \ / 1013 \ \ / 1014 - TPE3 --------------- SPE2 --- P4 ------- TPE4 - 1015 protector 1017 |<----- SEG3 ----->|<----- SEG4 ----->| 1018 |<--------------- PW2 --------------->| 1020 SEG1's label assigned by SPE1: 100 1021 SEG2's label assigned by TPE2: 200 1022 SEG3's label assigned by SPE2: 300 1023 SEG4's label assigned by TPE4: 400 1024 On P1: 1025 Incoming label of transport tunnel to SPE1: 1000 1026 Outgoing label of transport tunnel to SPE1: implicit null 1027 Outgoing label of bypass tunnel to SPE2: 2000 1028 On SPE1: 1029 Outgoing label of transport tunnel to TPE2: 3000 1030 On SPE2: 1031 Outgoing label of transport tunnel to TPE4: 4000 1032 Context label (incoming label of bypass tunnel): 999 1034 Forwarding state on P1: 1035 label 1000 -- primary nexthop: pop, to SPE1 1036 backup nexthop: swap 2000, to P2 1038 Forwarding state on SPE1: 1039 label 100 -- nexthop: swap 200, push 3000, to P3 1041 Forwarding state on P2: 1042 label 2000 -- nexthop: swap 999, to SPE2 1044 Forwarding state on SPE2: 1045 label 300 -- nexthop: swap 400, push 4000, to P4 1046 label 999 -- nexthop: label table of SPE1's label space 1048 Label table of SPE1's label space on SPE2: 1049 label 100 -- nexthop: swap 400, push 4000, to P4 1051 Figure 12 1053 4.7.2. Centralized Protector Model 1055 In the centralized protector model, for each primary PW of which the 1056 protector is not a backup (S-)PE, the protector MUST also learn the 1057 label of the backup PW from the backup (S-)PE (Section 6.3). This is 1058 the backup (S-)PE that the protector will forward traffic to. The 1059 protector MUST install a forwarding entry with a label swap from the 1060 primary PW's label to the backup PW's label and a label push with the 1061 label of a transport tunnel to the backup (S-)PE. 1063 In Figure 13, the protector is a centralized protector that protects 1064 PW1 against egress AC failure and egress node failure. It maintains 1065 a label space for PE2, which is identified by the context identifier 1066 of {PE2, protector}. It learns PW1's label from PE2, and PW2's label 1067 from PE4. It installs a forwarding entry for PW1's label in the 1068 label space. The nexthop of the forwarding entry indicates a label 1069 swap to PW2's label and a label push with the label of a transport 1070 tunnel to PE4. 1072 |<-------------- PW1 --------------->| 1074 - PE1 ------------- P1 ------- P3 ------ PE2 ---- 1075 / PLR \ PLR \ 1076 / \ / \ 1077 / bypass P5 P6 bypass \ 1078 / \ / \ 1079 / \/ \ 1080 CE1 protector CE2 1081 \ \ / 1082 \ transport \ / 1083 \ tunnel P7 / 1084 \ \ / 1085 \ \ / 1086 - PE3 ------------- P2 ----------------- PE4 ---- 1088 |<-------------- PW2 --------------->| 1090 PW1's label assigned by PE2: 100 1091 PW2's label assigned by PE4: 200 1092 On P3: 1093 Incoming label of transport tunnel to PE2: 1000 1094 Outgoing label of transport tunnel to PE2: implicit null 1095 Outgoing label of bypass tunnel to protector: 2000 1096 On PE2: 1097 Outgoing label of bypass tunnel to protector: 3000 1098 On protector: 1099 Context label (incoming label of bypass tunnels): 999 1100 Outgoing label of transport tunnel to PE4: 4000 1102 Forwarding state on P3: 1103 label 1000 -- primary nexthop: pop, to PE2 1104 backup nexthop: swap 2000, to P5 1106 Forwarding state on PE2: 1107 label 100 -- primary nexthop: pop, to CE2 1108 backup nexthop: push 3000, to P6 1110 Forwarding state on P5: 1111 label 2000 -- nexthop: swap 999, to protector 1113 Forwarding state on P6: 1114 label 3000 -- nexthop: swap 999, to protector 1116 Forwarding state on P7: 1117 label 4000 -- nexthop: pop, to PE4 1119 Forwarding state on PE4: 1120 label 200 -- nexthop: pop, to CE2 1122 Forwarding state on protector: 1123 label 999 -- nexthop: label table of PE2's label space 1125 Label table of PE2's label space on protector: 1126 label 100 -- nexthop: swap 200, push 4000, to P7 1128 Figure 13 1130 In Figure 14, the protector is a centralized protector that protects 1131 the PW segment SEG1 of PW1 against the node failure of SPE1. It 1132 maintains a label space for SPE1, which is identified by the context 1133 identifier of {SPE1, protector}. It learns SEG1's label from SPE1, 1134 and learns SEG3's label from SPE2. It installs a forwarding entry 1135 for SEG1's label in the label space. The nexthop of the forwarding 1136 entry indicates a label swap to SEG3's label and a label push with 1137 the label of a transport tunnel to TPE4. 1139 |<--------------- PW1 --------------->| 1140 |<----- SEG1 ----->|<----- SEG2 ----->| 1142 - TPE1 ----- P1 ----- SPE1 --- P2 -------- TPE2 - 1143 / PLR \ \ 1144 / \ \ 1145 / bypass P4 \ 1146 / \ \ 1147 / \ \ 1148 CE1 protector CE2 1149 \ \ / 1150 \ \ / 1151 \ transport P5 / 1152 \ tunnel \ / 1153 \ \ / 1154 - TPE3 -------------- SPE2 --- P3 -------- TPE4 - 1156 |<----- SEG3 ----->|<----- SEG4 ----->| 1157 |<--------------- PW2 --------------->| 1159 SEG1's label assigned by SPE1: 100 1160 SEG2's label assigned by TPE2: 200 1161 SEG3's label assigned by SPE2: 300 1162 SEG4's label assigned by TPE4: 400 1163 On P1: 1164 Incoming label of transport tunnel to SPE1: 1000 1165 Outgoing label of transport tunnel to SPE1: implicit null 1166 Outgoing label of bypass tunnel to protector: 2000 1167 On SPE1: 1168 Outgoing label of transport tunnel to TPE2: 3000 1169 On SPE2: 1170 Outgoing label of transport tunnel to TPE4: 4000 1171 On protector: 1172 Context label (incoming label of bypass tunnel): 999 1173 Outgoing label of transport tunnel to SPE2: 5000 1175 Forwarding state on P1: 1176 label 1000 -- primary nexthop: pop, to SPE1 1177 backup nexthop: swap 2000, to P4 1179 Forwarding state on SPE1: 1180 label 100 -- nexthop: swap 200, push 3000, to P2 1182 Forwarding state on P4: 1183 label 2000 -- nexthop: swap 999, to protector 1185 Forwarding state on P5: 1186 label 5000 -- nexthop: pop, to SPE2 1188 Forwarding state on SPE2: 1189 label 300 -- nexthop: swap 400, push 4000, to P3 1191 Forwarding state on protector: 1192 label 999 -- nexthop: label table of SPE1's label space 1194 Label table of SPE1's label space on protector: 1195 label 100 -- nexthop: swap 300, push 5000, to P5 1197 Figure 14 1199 5. Restorative and Revertive Behaviors 1201 Subsequent to local repair, there are three strategies for a network 1202 to restore traffic to a fully functional alternative path. 1204 o Global repair 1206 If the ingress CE is multi-homed (Figure 1), it MAY switch the 1207 traffic to the backup AC which is bound to the backup PW. 1208 Alternatively, if the ingress PE hosts a backup PW (Figure 2), the 1209 ingress PE MAY switch the traffic to the backup PW. These 1210 procedures are referred to as global repair. Possible triggers of 1211 global repair include PW status notification, Virtual Circuit 1212 Connectivity Verification (VCCV) [RFC5085, RFC5885], BFD, end-to- 1213 end OAM between CEs, and others. 1215 o Control plane convergence 1217 In egress PE node protection and S-PE node protection, it is 1218 possible that the failure is limited to the link between the PLR 1219 and the primary PE, whereas the primary PE is still operational. 1220 In this case, the PLR or an upstream router on the transport 1221 tunnel MAY reroute the tunnel around the link via an alternative 1222 path to the primary PE. Thus, the transport tunnel can heal and 1223 continue to carry the PW to the primary PE. This procedure is 1224 driven by control plane convergence on the new topology. 1226 o Local reversion 1228 The PLR MAY move traffic back to the primary PW, after the failure 1229 is resolved. In egress AC protection, upon detecting that the 1230 primary AC is restored, the PLR MAY start forwarding traffic over 1231 the AC again. Likewise, in egress PE node protection and S-PE 1232 node protection, upon detecting that the primary PE is restored, 1233 the PLR MAY re-establish the transport tunnel to the primary PE, 1234 and move the traffic from the bypass tunnel back to the transport 1235 tunnel. These procedures are referred to as local reversion. 1237 It is RECOMMENDED that the fast protection mechanism SHOULD be used 1238 in conjunction with global repair. Particularly in the case of 1239 egress PE and S-PE node failures, if the ingress PE or the protector 1240 loses communication with the egress PE or S-PE for an extensive 1241 period of time, LDP session may go down. Consequently, the ingress 1242 PE may bring down the primary PW completely, or the protector may 1243 remove the forwarding entry of the primary PW label. In either case, 1244 the service will be disrupted. In other words, although the 1245 mechanism can temporarily repair traffic, control plane state may 1246 eventually expire if the failure persists. Therefore, global repair 1247 SHOULD take place in a timely manner to move traffic to a fully 1248 functional alternative path. 1250 Control plane convergence may automatically happen as control plane 1251 protocols react to the new topology. However, it is only applicable 1252 to the specific link failure scenario described above. 1254 Local reversion is optional. In the circumstances where the failure 1255 is caused by resource flapping, local reversion MAY be dampened to 1256 limit potential disruption. Local reversion MAY be disabled 1257 completely by configuration. 1259 6. LDP Extensions 1261 As described in previous sections, a targeted LDP session MUST be 1262 established between each pair of primary PE and protector. The 1263 primary PE sends Label Mapping message over this session to advertise 1264 primary PW labels to the protector. In the centralized protector 1265 model, a targeted LDP session MUST also be established between a 1266 backup (S-)PE and the protector. The backup PE sends Label Mapping 1267 message over this session to advertise backup PW labels to the 1268 protector. 1270 To support the procedures, this document defines a new "Protection 1271 FEC Element" TLV. The Label Mapping messages of both the LDP 1272 sessions above MUST carry this TLV to identify a primary PW. 1273 Specifically, in the centralized protector model, the Protection FEC 1274 Element TLV advertised by a backup (S-)PE MUST match the one 1275 advertised by the primary PE, so that the protector can associate the 1276 primary PW's label with the backup PW's label, and perform a label 1277 swap. The backup (S-)PE builds such a Protection FEC Element TLV 1278 based on local configuration. 1280 This document also defines a new "Egress Protection Capability" TLV 1281 as a new type of Capability Parameter TLV [RFC5561], to allow a 1282 protector to announce its capability of processing the above 1283 Protection FEC Element TLV and performing context specific label 1284 switching for PW labels. 1286 The procedures in this section are only applicable, if the protector 1287 advertises the Egress Protection Capability TLV, the primary PE 1288 supports the advertisement of the Protection FEC Element TLV, and in 1289 the centralized protector model, the backup PE also supports the 1290 advertisement of the Protection FEC Element TLV. 1292 6.1. Egress Protection Capability TLV 1294 A protector MUST advertise the Egress Protection Capability TLV in 1295 its Initialization message and Capability message, over the LDP 1296 session with a primary PE. In the centralized protector model, the 1297 protector MUST also advertise the TLV over the LDP session with a 1298 backup PE. The TLV carries one or multiple context identifiers. To 1299 the primary PE, the TLV MUST carry the context identifier of the 1300 {primary PE, protector}. In the centralized protector model, the TLV 1301 MUST carry to the backup PE multiple context identifiers, one for 1302 each {primary PE, protector} where the backup PE serves as a backup 1303 for the primary PE. This TLV MUST NOT be advertised by the primary 1304 PE or the backup PE to the protector. 1306 The processing of the Egress Protection Capability TLV by a receiving 1307 router MUST follow the procedures defined in [RFC5561]. In 1308 particular, the router MUST advertise PW information to the protector 1309 by using the Protection FEC Element TLV, only after it has received 1310 the Egress Protection Capability TLV from the protector. It MUST 1311 validate each context identifier included in the TLV, and advertise 1312 the information of only the PWs that are associated with the context 1313 identifier. It MUST withdraw previously advertised Protection FEC 1314 TLVs, when the protector has withdrawn a previously advertised 1315 context identifier or the entire Egress Protection Capability TLV via 1316 Capability message. 1318 The encoding of the Egress Protection Capability TLV is defined as 1319 below. It conforms to the format of Capability Parameter TLV 1320 specified in [RFC5561]. 1322 0 1 2 3 1323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 |U|F| Egress Protection (TBD) | Length | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 |S| Reserved | | 1328 +-+-+-+-+-+-+-+-+ | 1329 | | 1330 ~ Capability Data = context identifier(s) ~ 1331 | | 1332 | +-+-+-+-+-+-+-+-+ 1333 | | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 Figure 15 1338 The U-bit MUST be set to 1 so that a receiver MUST silently ignore 1339 this TLV if unknown to it, and continue processing the rest of the 1340 message. 1342 The F-bit MUST be set to 0 since this TLV is sent only in 1343 Initialization and Capability messages, which are not forwarded. 1345 The TLV Code Point is TBD. It needs to be assigned by IANA. 1347 The S-bit indicates whether the sender is advertising (S=1) or 1348 withdrawing (S=0) the capability. 1350 The "Capability Data" is encoded with the context identifiers of the 1351 {primary PE, protector} pairs for which the advertiser is the 1352 protector. 1354 6.2. PW Label Distribution from Primary PE to Protector 1356 A primary PE MUST advertise a primary PW's label to a protector by 1357 sending a Label Mapping message. The message includes a Protection 1358 FEC Element TLV (see Section 6.4 for encoding), and an Upstream- 1359 Assigned Label TLV [RFC6389] encoded with the PW's label. The 1360 combination of the Protection FEC Element TLV and the PW label 1361 represents the primary PE's forwarding state for the PW. The Label 1362 Mapping message MUST also carry an IPv4/v6 Interface_ID TLV [RFC6389, 1363 RFC3471] encoded with the context identifier of the {primary PE, 1364 protector}. 1366 The protector that receives this Label Mapping message MUST install a 1367 forwarding entry for the PW label in the label space identified by 1368 the context identifier. The nexthop of the forwarding entry MUST 1369 ensure packets to be sent towards the target CE via a backup AC or a 1370 backup (S-)PE, depending on the protection scenario. The protector 1371 MUST silently discard a Label Mapping message if the included context 1372 identifier is unknown to it. 1374 6.3. PW Label Distribution from Backup PE to Protector 1376 In the centralized protector model, a backup PE MUST advertise a 1377 backup PW's label to the protector by sending a Label Mapping 1378 message. The message includes a Protection FEC Element TLV and a 1379 Generic Label TLV encoded with the backup PW's label. This 1380 Protection FEC Element MUST be identical to the Protection FEC 1381 Element TLV that the primary PE advertises to the protector 1382 (Section 6.2). This is achieved through configuration on the backup 1383 PE. The context identifier MUST NOT be encoded in Interface_ID TLV 1384 in this message. 1386 The protector that receives this Label Mapping message MUST associate 1387 the backup PW with the primary PW, based on the common Protection FEC 1388 Element TLV. It MUST distinguish between the Label Mapping message 1389 from the primary PE and the Label Mapping message from the backup PE 1390 based on the respective presence and absence of context identifier in 1391 Interface_ID TLV. It MUST install a forwarding entry for the primary 1392 PW's label in the label space identified by the context identifier. 1393 The nexthop of the forwarding entry MUST indicate a label swap to the 1394 backup PW's label, followed by a label push or IP header push for a 1395 transport tunnel to the backup PE. 1397 6.4. Protection FEC Element TLV 1399 The Protection FEC Element TLV has type 0x83. Its format is defined 1400 as below: 1402 0 1 2 3 1403 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Type(0x83) | Reserved | Encoding Type | Length | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | | 1408 | | 1409 ~ PW Information ~ 1410 | | 1411 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 Figure 16 1417 - Encoding Type 1419 Type of encoding format of PW Information field. The following 1420 types are defined, corresponding to the PWid FEC Element and 1421 Generalized PWid FEC Element defined in [RFC4447]. 1423 1 - PWid FEC Element with IPv4 PE addresses (section 6.4.1) 1425 2 - Generalized PWid FEC Element with IPv4 PE addresses 1426 (section 6.4.2) 1428 3 - PWid FEC Element with IPv6 PE addresses (section 6.4.3) 1430 4 - Generalized PWid FEC Element with IPv6 PE addresses 1431 (section 6.4.4) 1433 - Length 1435 Length of PW Information field in octets. 1437 - PW Information 1439 Field of variable length that specifies a PW. 1441 6.4.1. Encoding Format for PWid with IPv4 PE Addresses 1443 0 1 2 3 1444 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Type(0x83) | Reserved | Enc Type(1) | Length(20) | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Ingress PE IPv4 Address | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | Egress PE IPv4 Address | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | Group ID | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | PW ID | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 |C| PW Type | Reserved | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 Figure 17 1461 - Ingress PE IPv4 Address 1463 IPv4 address of the ingress PE of PW. 1465 - Egress PE IPv4 Address 1467 IPv4 address of the egress PE of PW. 1469 - Group ID 1471 An arbitrary 32-bit value that represents a group of PWs and that 1472 is used to create groups in the PW space. 1474 - PW ID 1476 A non-zero 32-bit connection ID that, together with the PW Type 1477 field, identifies a particular PW. 1479 - Control word bit (C) 1480 A bit that flags the presence of a control word on this PW. If C 1481 = 1, control word is present; If C = 0, control word is not 1482 present. 1484 - PW Type 1486 A 15-bit quantity that represents the type of PW. 1488 6.4.2. Encoding Format for Generalized PWid with IPv4 PE Addresses 1490 0 1 2 3 1491 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Type(0x83) | Reserved | Enc Type(2) | Length | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Ingress PE IPv4 Address | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | Egress PE IPv4 Address | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 |C| PW Type | Reserved | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | AGI Type | Length | Value | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 ~ AGI Value (contd.) ~ 1504 | | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | AII Type | Length | Value | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 ~ SAII Value (contd.) ~ 1509 | | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | AII Type | Length | Value | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 ~ TAII Value (contd.) ~ 1514 | | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 Figure 18 1519 - Ingress PE IPv4 Address 1521 IPv4 address of the ingress PE of PW. 1523 - Egress PE IPv4 Address 1525 IPv4 address of the egress PE of PW. 1527 - Control word bit (C) 1528 A bit that flags the presence of a control word on this PW. If C 1529 = 1, control word is present; If C = 0, control word is not 1530 present. 1532 - PW Type 1534 A 15-bit quantity that represents the type of PW. 1536 - AGI Type, Length, Value, AGI Value 1538 Attachment Group Identifier of PW. 1540 - SAII Type, Length, Value, SAII Value 1542 Source Attachment Individual Identifier of PW. 1544 - TAII Type, Length, Value, TAII Value 1546 Target Attachment Individual Identifier of PW. 1548 6.4.3. Encoding Format for PWid with IPv6 PE Addresses 1550 0 1 2 3 1551 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Type(0x83) | Reserved | Enc Type(3) | Length(44) | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 ~ Ingress PE IPv6 Address ~ 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 ~ Egress PE IPv6 Address ~ 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Group ID | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | PW ID | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 |C| PW Type | Reserved | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 Figure 19 1568 - Ingress PE IPv6 Address 1570 IPv6 address of the ingress PE of PW. 16 octets. 1572 - Egress PE IPv6 Address 1574 IPv6 address of the egress PE of PW. 16 octets. 1576 - Group ID 1578 An arbitrary 32-bit value that represents a group of PWs and that 1579 is used to create groups in the PW space. 1581 - PW ID 1583 A non-zero 32-bit connection ID that, together with the PW Type 1584 field, identifies a particular PW. 1586 - Control word bit (C) 1588 A bit that flags the presence of a control word on this PW. If C 1589 = 1, control word is present; If C = 0, control word is not 1590 present. 1592 - PW Type 1594 A 15-bit quantity that represents the type of PW. 1596 6.4.4. Encoding Format for Generalized PWid with IPv6 PE Addresses 1597 0 1 2 3 1598 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | Type(0x83) | Reserved | Enc Type(4) | Length | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 ~ Ingress PE IPv6 Address ~ 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 ~ Egress PE IPv6 Address ~ 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 |C| PW Type | Reserved | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | AGI Type | Length | Value | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 ~ AGI Value (contd.) ~ 1611 | | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | AII Type | Length | Value | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 ~ SAII Value (contd.) ~ 1616 | | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | AII Type | Length | Value | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 ~ TAII Value (contd.) ~ 1621 | | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 Figure 20 1626 - Ingress PE IPv6 Address 1628 IPv6 address of the ingress PE of PW. 16 octets. 1630 - Egress PE IPv6 Address 1632 IPv6 address of the egress PE of PW. 16 octets. 1634 - Control word bit (C) 1636 A bit that flags the presence of a control word on this PW. If C 1637 = 1, control word is present; If C = 0, control word is not 1638 present. 1640 - PW Type 1642 A 15-bit quantity that represents the type of PW. 1644 - AGI Type, Length, Value, AGI Value 1645 Attachment Group Identifier of PW. 1647 - SAII Type, Length, Value, SAII Value 1649 Source Attachment Individual Identifier of PW. 1651 - TAII Type, Length, Value, TAII Value 1653 Target Attachment Individual Identifier of PW. 1655 7. IANA Considerations 1657 This document defines a new "Egress Protection Capability" TLV in 1658 Section 6. The document requests IANA to assign an LDP TLV code 1659 point for the TLV. 1661 This document defines a new Protection FEC Element TLV, and uses the 1662 LDP Protection FEC Type Name Space value 0x83 for it. The LDP 1663 Protection FEC Type Name Space for this value needs to reference this 1664 document, and it is requested to update this reference to the RFC 1665 number for this document. 1667 Value Hex Name Label Advertisement Discipline 1668 ------------------------------------------------------------------- 1669 131 0x83 Protection FEC Element DU 1671 8. Security Considerations 1673 In this document, PW traffic can be temporarily rerouted by a PLR to 1674 a protector. In the centralized protector scenario, the traffic can 1675 be further rerouted to a backup PE. In the control plane, there is a 1676 targeted LDP session between a primary PE and a protector. In the 1677 centralized protector scenario, there is also a targeted LDP session 1678 between a backup PE and a protector. In all scenarios, traffic 1679 rerouting via PLRs, protectors and backup PEs is planned and 1680 anticipated, and backup PEs can be used anyway to host PWs and LDP 1681 sessions. Hence, the rerouted traffic and the LDP sessions 1682 introduced in this document should not be viewed as a new security 1683 threat. 1685 In general, [RFC5920] describes the security framework for MPLS 1686 networks. [RFC3209] describes the security considerations for RSVP 1687 LSPs. [RFC5036] describes the security considerations for the base 1688 LDP specification. [RFC5561] describes the security considerations 1689 which apply when using the LDP capability mechanism. All these 1690 security framework and considerations apply to this document as well. 1692 9. Acknowledgements 1694 This document leverages work done by Hannes Gredler, Yakov Rekhter, 1695 Minto Jeyananth, Kevin Wang and several on MPLS edge protection. 1696 Thanks to Nischal Sheth and Bhupesh Kothari for their contribution. 1697 Thanks to John E Drake, Andrew G Malis, Alexander Vainshtein, Stewart 1698 Bryant, and Mach Chen for valuable comments that helped shape this 1699 document and improve its clarity. 1701 10. References 1703 10.1. Normative References 1705 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 1706 G. Heron, "Pseudowire Setup and Maintenance Using the 1707 Label Distribution Protocol (LDP)", RFC 4447, 1708 DOI 10.17487/RFC4447, April 2006, 1709 . 1711 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1712 Label Assignment and Context-Specific Label Space", 1713 RFC 5331, DOI 10.17487/RFC5331, August 2008, 1714 . 1716 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 1717 Le Roux, "LDP Capabilities", RFC 5561, 1718 DOI 10.17487/RFC5561, July 2009, 1719 . 1721 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 1722 Switching (GMPLS) Signaling Functional Description", 1723 RFC 3471, DOI 10.17487/RFC3471, January 2003, 1724 . 1726 [RFC3472] Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized 1727 Multi-Protocol Label Switching (GMPLS) Signaling 1728 Constraint-based Routed Label Distribution Protocol (CR- 1729 LDP) Extensions", RFC 3472, DOI 10.17487/RFC3472, January 1730 2003, . 1732 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 1733 Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, 1734 November 2011, . 1736 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1737 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1738 DOI 10.17487/RFC4090, May 2005, 1739 . 1741 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1742 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1743 DOI 10.17487/RFC5286, September 2008, 1744 . 1746 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 1747 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 1748 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 1749 . 1751 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1752 Label Switching Architecture", RFC 3031, 1753 DOI 10.17487/RFC3031, January 2001, 1754 . 1756 10.2. Informative References 1758 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1759 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1760 . 1762 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 1763 Edge-to-Edge (PWE3) Architecture", RFC 3985, 1764 DOI 10.17487/RFC3985, March 2005, 1765 . 1767 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1768 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1769 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1770 . 1772 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1773 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1774 October 2007, . 1776 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1777 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1778 DOI 10.17487/RFC5659, October 2009, 1779 . 1781 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1782 RFC 5714, DOI 10.17487/RFC5714, January 2010, 1783 . 1785 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1786 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1787 . 1789 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 1790 Circuit Connectivity Verification (VCCV): A Control 1791 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 1792 December 2007, . 1794 [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional 1795 Forwarding Detection (BFD) for the Pseudowire Virtual 1796 Circuit Connectivity Verification (VCCV)", RFC 5885, 1797 DOI 10.17487/RFC5885, June 2010, 1798 . 1800 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 1801 Pallagatti, "Seamless Bidirectional Forwarding Detection 1802 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 1803 . 1805 Authors' Addresses 1807 Yimin Shen 1808 Juniper Networks 1809 10 Technology Park Drive 1810 Westford, MA 01886 1811 USA 1813 Phone: +1 9785890722 1814 Email: yshen@juniper.net 1816 Rahul Aggarwal 1817 Arktan, Inc 1819 Email: raggarwa_1@yahoo.com 1821 Wim Henderickx 1822 Nokia 1823 Copernicuslaan 50 1824 2018 Antwerp 1825 Belgium 1827 Email: wim.henderickx@nokia.com 1829 Yuanlong Jiang 1830 Huawei Technologies 1832 Email: jiangyuanlong@huawei.com