idnits 2.17.1 draft-ietf-mpls-egress-protection-framework-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 (October 20, 2018) is 2015 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) == Outdated reference: A later version (-20) exists of draft-ietf-rtgwg-bgp-pic-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 Minto Jeyananth 4 Intended status: Standards Track Juniper Networks 5 Expires: April 23, 2019 Bruno Decraene 6 Orange 7 Hannes Gredler 8 RtBrick Inc 9 Carsten Michel 10 Deutsche Telekom 11 Huaimo Chen 12 Yuanlong Jiang 13 Huawei Technologies Co., Ltd. 14 October 20, 2018 16 MPLS Egress Protection Framework 17 draft-ietf-mpls-egress-protection-framework-03 19 Abstract 21 This document specifies a fast reroute framework for protecting IP/ 22 MPLS services and MPLS transport tunnels against egress node and 23 egress link failures. In this framework, the penultimate-hop router 24 of an MPLS tunnel acts as the point of local repair (PLR) for an 25 egress node failure, and the egress router of the MPLS tunnel acts as 26 the PLR for an egress link failure. Each of them pre-establishes a 27 bypass tunnel to a protector. Upon an egress node or link failure, 28 the corresponding PLR performs local failure detection and local 29 repair, by rerouting packets over the corresponding bypass tunnel. 30 The protector in turn performs context label switching or context IP 31 forwarding to send the packets to the ultimate service 32 destination(s). This mechanism can be used to reduce traffic loss 33 before global repair reacts to the failure and control plane 34 protocols converge on the topology changes due to the failure. The 35 framework is applicable to all types of IP/MPLS services and MPLS 36 tunnels. Under the framework, service protocol extensions may be 37 further specified to support service label distribution from an 38 egress router to a protector. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 23, 2019. 57 Copyright Notice 59 Copyright (c) 2018 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Specification of Requirements . . . . . . . . . . . . . . . . 5 76 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 78 5. Egress node protection . . . . . . . . . . . . . . . . . . . 8 79 5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8 80 5.2. Egress node failure and detection . . . . . . . . . . . . 8 81 5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9 82 5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10 83 5.5. Egress-protected tunnel and service . . . . . . . . . . . 11 84 5.6. Egress-protection bypass tunnel . . . . . . . . . . . . . 11 85 5.7. Context ID, context label, and context based forwarding . 12 86 5.8. Advertisement and path resolution for context ID . . . . 14 87 5.9. Egress-protection bypass tunnel establishment . . . . . . 15 88 5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . . 16 89 5.11. Service label distribution from egress router to 90 protector . . . . . . . . . . . . . . . . . . . . . . . . 16 91 5.12. Centralized protector mode . . . . . . . . . . . . . . . 17 92 6. Egress link protection . . . . . . . . . . . . . . . . . . . 19 93 7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 22 94 8. Example: Layer-3 VPN egress protection . . . . . . . . . . . 22 95 8.1. Egress node protection . . . . . . . . . . . . . . . . . 24 96 8.2. Egress link protection . . . . . . . . . . . . . . . . . 25 97 8.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 25 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 101 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 104 12.2. Informative References . . . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 107 1. Introduction 109 In MPLS networks, label switched paths (LSPs) are widely used as 110 transport tunnels to carry IP and MPLS services across MPLS domains. 111 Examples of MPLS services are layer-2 VPNs, layer-3 VPNs, 112 hierarchical LSPs, and others. In general, a tunnel may carry 113 multiple services of one or multiple types, if the tunnel can satisfy 114 both individual and aggregate requirements (e.g. CoS, QoS) of these 115 services. The egress router of the tunnel hosts the service 116 instances of the services. Each MPLS service instance is responsible 117 for forwarding service packets via an egress link to the service 118 destination, based on a service label. Each IP service instance is 119 responsible for doing the same based on a service IP address. The 120 egress link is often called a PE-CE (provider edge - customer edge) 121 link or attachment circuit (AC). 123 Today, local repair based fast reroute mechanisms [RFC4090], 124 [RFC5286], [RFC7490], [RFC7812] have been widely deployed to protect 125 MPLS tunnels against transit link/node failures, with traffic 126 restoration time in the order of tens of milliseconds. Local repair 127 refers to the scenario where the router upstream to an anticipated 128 failure (aka. PLR, i.e. point of local repair) pre-establishes a 129 bypass tunnel to the router downstream of the failure (aka. MP, i.e. 130 merge point), pre-installs the forwarding state of the bypass tunnel 131 in the data plane, and uses a rapid mechanism (e.g. link layer OAM, 132 BFD, and others) to locally detect the failure in the data plane. 133 When the failure occurs, the PLR reroutes traffic through the bypass 134 tunnel to the MP, allowing the traffic to continue to flow to the 135 tunnel's egress router. 137 This document describes a fast reroute framework for egress node and 138 egress link protection. Similar to transit link/node protection, 139 this framework also relies on a PLR to perform local failure 140 detection and local repair. In egress node protection, the PLR is 141 the penultimate-hop router of a tunnel. In egress link protection, 142 the PLR is the egress router of the tunnel. The framework further 143 relies on a so-called "protector" to serve as the tailend of a bypass 144 tunnel. The protector is a router that hosts "protection service 145 instances" and has its own connectivity or paths to service 146 destinations. When a PLR does local repair, the protector is 147 responsible for performing "context label switching" for rerouted 148 MPLS service packets and "context IP forwarding" for rerouted IP 149 service packets, to allow the service packets to continue to reach 150 the service destinations. 152 This framework considers an egress node failure as a failure of a 153 tunnel, as well as a failure of all the services carried by the 154 tunnel, because service packets can no longer reach the service 155 instances on the egress router. Therefore, the framework addresses 156 egress node protection at both tunnel level and service level 157 simultaneously. Likewise, the framework considers an egress link 158 failure as a failure of all the services traversing the link, and 159 addresses egress link protection at the service level. 161 This framework requires that the destination (a CE or site) of a 162 service MUST be dual-homed or have dual paths to an MPLS network, via 163 two MPLS edge routers. One of the routers is the egress router of 164 the service's transport tunnel, and the other is a backup egress 165 router which hosts a "backup service instance". In the "co-located" 166 protector mode in this document, the backup egress router serves as 167 the protector, and hence the backup service instance acts as the 168 protection service instance. In the "centralized" protector mode 169 (Section 5.12), the protector and the backup egress router are 170 decoupled, and the protection service instance and the backup service 171 instance are hosted separately by the two routers. 173 The framework is described by mainly referring to P2P (point-to- 174 point) tunnels. However, it is equally applicable to P2MP (point-to- 175 multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to- 176 multipoint) tunnels, if a sub-LSP can be viewed as a P2P tunnel. 178 The framework is a multi-service and multi-transport framework. It 179 assumes a generic model where each service is comprised of a common 180 set of components, including a service instance, a service label, and 181 a service label distribution protocol, and the service is transported 182 over an MPLS tunnel of any type. The framework also assumes service 183 labels to be downstream assigned, i.e. assigned by egress routers. 184 Therefore, the framework is generally applicable to most existing and 185 future services. Services which use upstream-assigned service labels 186 are out of scope of this document and left for future study. 188 The framework does not require extensions for the existing signaling 189 and label distribution protocols (e.g. RSVP, LDP, BGP, etc.) of MPLS 190 tunnels. It expects transport tunnels and bypass tunnels to be 191 established by using the generic mechanisms provided by the 192 protocols. On the other hand, it does not preclude extensions to the 193 protocols which may facilitate the procedures. One example of such 194 extension is [RFC8400]. The framework may need extensions for IGPs 195 and service label distribution protocols, to support protection 196 establishment and context label switching. This document provides 197 guidelines for these extensions, but the specific details SHOULD be 198 addressed in separate documents. 200 The framework is intended to complement control-plane convergence and 201 global repair, which are traditionally used to recover networks from 202 egress node and egress link failures. Control-plane convergence 203 relies on control protocols to react on the topology changes due to a 204 failure. Global repair relies an ingress router to remotely detect a 205 failure and switch traffic to an alternative path. An example of 206 global repair is the BGP Prefix Independent Convergence mechanism 207 [BGP-PIC] for BGP established services. Compared with these 208 mechanisms, this framework is considered as faster in traffic 209 restoration, due to the nature of local failure detection and local 210 repair. However, it is RECOMMENDED that the framework SHOULD be used 211 in conjunction with control-plane convergence or global repair, in 212 order to take the advantages of both approaches. That is, the 213 framework provides fast and temporary repair, and control-plane 214 convergence or global repair provides ultimate and permanent repair. 216 2. Specification of Requirements 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC2119. 222 3. Terminology 224 Egress router - A router at the egress endpoint of a tunnel. It 225 hosts service instances for all the services carried by the tunnel, 226 and has connectivity with the destinations of the services. 228 Egress node failure - A failure of an egress router. 230 Egress link failure - A failure of the egress link (e.g. PE-CE link, 231 attachment circuit) of a service. 233 Egress failure - An egress node failure or an egress link failure. 235 Egress-protected tunnel - A tunnel whose egress router is protected 236 by a mechanism according to this framework. The egress router is 237 hence called a protected egress router. 239 Egress-protected service - An IP or MPLS service which is carried by 240 an egress-protected tunnel, and hence protected by a mechanism 241 according to this framework. 243 Backup egress router - Given an egress-protected tunnel and its 244 egress router, this is another router which has connectivity with all 245 or a subset of the destinations of the egress-protected services 246 carried by the egress-protected tunnel. 248 Backup service instance - A service instance which is hosted by a 249 backup egress router, and corresponding to an egress-protected 250 service on a protected egress router. 252 Protector - A role acted by a router as an alternate of a protected 253 egress router, to handle service packets in the event of an egress 254 failure. A protector may be physically co-located with or decoupled 255 from a backup egress router, depending on the co-located or 256 centralized protector mode. 258 Protection service instance - A service instance hosted by a 259 protector, corresponding to the service instance of an egress- 260 protected service on a protected egress router. A protection service 261 instance is a backup service instance, if the protector is co-located 262 with a backup egress router. 264 PLR - A router at the point of local repair. In egress node 265 protection, it is the penultimate-hop router on an egress-protected 266 tunnel. In egress link protection, it is the egress router of the 267 egress-protected tunnel. 269 Protected egress {E, P} - A virtual node consisting of an ordered 270 pair of egress router E and protector P. It serves as the virtual 271 destination of an egress-protected tunnel, and as the virtual 272 location of the egress-protected services carried by the tunnel. 274 Context identifier (ID) - A globally unique IP address assigned to a 275 protected egress {E, P}. 277 Context label - A non-reserved label assigned to a context ID by a 278 protector. 280 Egress-protection bypass tunnel - A tunnel used to reroute service 281 packets around an egress failure. 283 Co-located protector mode - The scenario where a protector and a 284 backup egress router are co-located as one router, and hence each 285 backup service instance serves as a protection service instance. 287 Centralized protector mode - The scenario where a protector is a 288 dedicated router, and is decoupled from backup egress routers. 290 Context label switching - Label switching performed by a protector, 291 in the label space of an egress router indicated by a context label. 293 Context IP forwarding - IP forwarding performed by a protector, in 294 the IP address space of an egress router indicated by a context 295 label. 297 4. Requirements 299 This document considers the followings as the design requirements of 300 this egress protection framework. 302 o The framework must support P2P tunnels. It should equally support 303 P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P 304 tunnel. 306 o The framework must support multi-service and multi-transport 307 networks. It must accommodate existing and future signaling and 308 label-distribution protocols of tunnels and bypass tunnels, 309 including RSVP, LDP, BGP, IGP, segment routing, and others. It 310 must also accommodate existing and future IP/MPLS services, 311 including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and 312 others. It must provide a generic solution for environments where 313 different types of services and tunnels may co-exist. 315 o The framework must consider minimizing disruption during 316 deployment. It should only involve routers close to egress, and 317 be transparent to ingress routers and other transit routers. 319 o In egress node protection, for scalability and performance 320 reasons, a PLR must be agnostic to services and service labels, 321 like PLRs in transit link/node protection. It must maintain 322 bypass tunnels and bypass forwarding state on a per-transport- 323 tunnel basis, rather than per-service-destination or per-service- 324 label basis. It should also support bypass tunnel sharing between 325 transport tunnels. 327 o A PLR must be able to use its local visibility or information of 328 routing and/or TE topology to compute or resolve a path for a 329 bypass tunnel. 331 o A protector must be able to perform context label switching for 332 rerouted MPLS service packets, based on service label(s) assigned 333 by an egress router. It must be able to perform context IP 334 forwarding for rerouted IP service packets, in the public or 335 private IP address space used by an egress router. 337 o The framework must be able to work seamlessly with transit link/ 338 node protection mechanisms to achieve end-to-end coverage. 340 o The framework must be able to work in conjunction with global 341 repair and control plane convergence. 343 5. Egress node protection 345 5.1. Reference topology 347 This document refers to the following topology when describing the 348 procedures of egress node protection. 350 services 1, ..., N 351 =====================================> tunnel 353 I ------ R1 ------- PLR --------------- E ---- 354 ingress penultimate-hop egress \ 355 | . (primary \ 356 | . service \ 357 | . instances) \ 358 | . \ 359 | . \ service 360 | . destinations 361 | . / (CEs, sites) 362 | . / 363 | . bypass / 364 | . tunnel / 365 | . / 366 | ............... / 367 R2 --------------- P ---- 368 protector 369 (protection 370 service 371 instances) 373 Figure 1 375 5.2. Egress node failure and detection 377 An egress node failure refers to the failure of an MPLS tunnel's 378 egress router. At the service level, it also means a service 379 instance failure for each IP/MPLS service carried by the tunnel. 381 Ideally, an egress node failure can be detected by an adjacent router 382 (i.e. PLR in this framework) using a node liveness detection 383 mechanism, or based on a collective failure of all the links to that 384 node. However, the assumption is that the mechanisms SHOULD be 385 reasonably fast, i.e. faster than control plane failure detection and 386 remote failure detection. Otherwise, local repair will not be able 387 to provide much benefit compared to control plane convergence or 388 global repair. In general, the speed, accuracy, and reliability of a 389 mechanism are the key factors to decide its applicability in egress 390 node protection. This document provides the following guidelines in 391 this regard. 393 o If the PLR has a reasonably fast mechanism to detect and 394 differentiate a link failure (of the link between the PLR and the 395 egress node) and an egress node failure, it SHOULD set up both 396 link protection and egress node protection, and trigger one and 397 only one protection upon a corresponding failure. 399 o If the PLR has a fast mechanism to detect a link failure and an 400 egress node failure, but cannot distinguish them; Or, if the PLR 401 has a fast mechanism to detect a link failure only, but not an 402 egress node failure, the PLR has two options: 404 1. It MAY set up link protection only, and leave the egress node 405 failure to global repair and control plane convergence to 406 handle. 408 2. It MAY set up egress node protection only, and treat a link 409 failure as a trigger for the egress node protection. However, 410 the assumption is that treating a link failure as an egress 411 node failure MUST NOT have a negative impact on services. 412 Otherwise, it SHOULD adopt the previous option. 414 5.3. Protector and PLR 416 A router is assigned to the "protector" role to protect a tunnel and 417 the services carried by the tunnel against an egress node failure. 418 The protector is responsible for hosting a protection service 419 instance for each protected service, serving as the tailend of a 420 bypass tunnel, and performing context label switching and/or context 421 IP forwarding for rerouted service packets. 423 A tunnel can be protected by only one protector at a given time. 424 Multiple tunnels to a given egress router may be protected by a 425 common protector or different protectors. A protector may protect 426 multiple tunnels with a common egress router or different egress 427 routers. 429 For each tunnel, its penultimate-hop router acts as a PLR. The PLR 430 pre-establishes a bypass tunnel to the protector, and pre-installs 431 bypass forwarding state in the data plane. Upon detection of an 432 egress node failure, the PLR reroutes all the service packets 433 received on the tunnel though the bypass tunnel to the protector. 434 For MPLS service packets, the PLR keeps service labels intact in the 435 packets. The protector in turn forwards the rerouted service packets 436 towards the ultimate service destinations. Specifically, it performs 437 context label switching for MPLS service packets, based on the 438 service labels which are assigned by the protected egress router; It 439 performs context IP forwarding for IP service packets, based on their 440 destination addresses. 442 The protector MUST have its own connectivity with each service 443 destination, via a direct link or a multi-hop path, which MUST NOT 444 traverse the protected egress router or be affected by the egress 445 node failure. This also requires that each service destination MUST 446 be dual-homed or have dual paths to the egress router and a backup 447 egress router which serves as the protector. Each protection service 448 instance on the protector relies on such connectivity to set up 449 forwarding state for context label switching and context IP 450 forwarding. 452 5.4. Protected egress 454 This document introduces the notion of "protected egress" as a 455 virtual node consisting of the egress router E of a tunnel and a 456 protector P. It is denoted by an ordered pair of {E, P}, indicating 457 the primary-and-protector relationship between the two routers. It 458 serves as the virtual destination of the tunnel, and the virtual 459 location of service instances for the services carried by the tunnel. 460 Hence, the tunnel and services are considered as being "associated" 461 with the protected egress {E, P}. 463 A given egress router E may be the tailend of multiple tunnels. In 464 general, the tunnels may be protected by multiple protectors, e.g. 465 P1, P2, and so on, with each Pi protecting a subset of the tunnels. 466 Thus, these routers form multiple protected egresses, i.e. {E, P1} , 467 {E, P2}, and so on. Each tunnel is associated with one and only one 468 protected egress {E, Pi}. All the services carried by the tunnel are 469 then automatically associated with the protected egress {E, Pi}. 470 Conversely, a service associated with a protected egress {E, Pi} MUST 471 be carried by a tunnel associated with the protected egress {E, Pi}. 472 This mapping MUST be ensured by the ingress router of the tunnel and 473 the service (Section 5.5). 475 Two routers X and Y may be protectors for each other. In this case, 476 they form two distinct protected egresses {X, Y} and {Y, X}. 478 5.5. Egress-protected tunnel and service 480 A tunnel, which is associated with a protected egress {E, P}, is 481 called an egress-protected tunnel. It is associated with one and 482 only one protected egress {E, P}. Multiple egress-protected tunnels 483 may be associated with a given protected egress {E, P}. In this case, 484 they share the common egress router and protector, but may or may not 485 share a common ingress router, or a common PLR (i.e. penultimate-hop 486 router). 488 An egress-protected tunnel is considered as logically "destined" for 489 its protected egress {E, P}. However, its path MUST be resolved and 490 established with E as the physical tailend. 492 A service, which is associated with a protected egress {E, P}, is 493 called an egress-protected service. The egress router E hosts the 494 primary instance of the service, and the protector P hosts the 495 protection instance of the service. 497 An egress-protected service is associated with one and only one 498 protected egress {E, P}. Multiple egress-protected services may be 499 associated with a given protected egress {E, P}. In this case, these 500 services share the common egress router and protector, but may or may 501 not share a common egress-protected tunnel or a common ingress 502 router. 504 An egress-protected service MUST be mapped to an egress-protected 505 tunnel by its ingress router, based on the common protected egress 506 {E, P} of the service and the tunnel. This is achieved by 507 introducing the notion of "context ID" for protected egress {E, P}, 508 as described in (Section 5.7). 510 5.6. Egress-protection bypass tunnel 512 An egress-protected tunnel destined for a protected egress {E, P} 513 MUST have a bypass tunnel from its PLR to the protector P. This 514 bypass tunnel is called an egress-protection bypass tunnel. The 515 bypass tunnel is considered as logically "destined" for the protected 516 egress {E, P}. However, due to its bypass nature, it MUST be resolved 517 and established with P as the physical tailend and E as the node to 518 avoid. The bypass tunnel MUST have the property that it MUST NOT be 519 affected by the topology change caused by an egress node failure. 521 An egress-protection bypass tunnel is associated with one and only 522 one protected egress {E, P}. A PLR may share an egress-protection 523 bypass tunnel for multiple egress-protected tunnels associated with a 524 common protected egress {E, P}. For multiple egress-protected tunnels 525 associated with a common protected egress {E, P}, there may be one or 526 multiple egress-protection bypass tunnels from one or multiple PLRs 527 to the protector P, depending on the paths of the egress-protected 528 tunnels. 530 5.7. Context ID, context label, and context based forwarding 532 In this framework, a globally unique IPv4/v6 address is assigned to a 533 protected egress {E, P} to serve as the identifier of the protected 534 egress {E, P}. It is called a "context ID" due to its specific usage 535 in context label switching and context IP forwarding on the 536 protector. It is an IP address that is logically owned by both the 537 egress router and the protector. For the egress node, it indicates 538 the protector. For the protector, it indicates the egress router, 539 particularly the egress router's forwarding context. For other 540 routers in the network, it is an address reachable via both the 541 egress router and the protector in the routing domain and the TE 542 domain (Section 5.8), similar to an anycast address. 544 The main purpose of a context ID is to coordinate ingress router, 545 egress router, PLR and protector to set up egress protection. Given 546 an egress-protected service associated with a protected egress {E, 547 P}, its context ID is used as below: 549 o If the service is an MPLS service, when E distributes a service 550 label binding message to the ingress router, E attaches the 551 context ID to the message. If the service is an IP service, when 552 E advertises the service destination address to the ingress 553 router, E also attaches the context ID to the advertisement 554 message. How the context ID is encoded in the messages is a 555 choice of the service protocol. It may need protocol extensions 556 to define a "context ID" object, if there is no existing object 557 that can be used for this purpose. 559 o The ingress router uses the context ID as a destination to 560 establish or resolve an egress-protected tunnel. The ingress 561 router then maps the service to the tunnel for transportation. In 562 this process, the semantics of the context ID is transparent to 563 the ingress router. The ingress router only treats the context ID 564 as an IP address of E, and behaves in the same manner as 565 establishing or resolving a regular transport tunnel, although the 566 result should be an egress-protected tunnel. 568 o The context ID is conveyed to the PLR by the signaling protocol of 569 the egress-protected tunnel, or learned by the PLR via an IGP 570 (i.e. OSPF or ISIS) or a topology-driven label distribution 571 protocol (e.g. LDP). The PLR uses the context ID as destination 572 to establish or resolve an egress-protection bypass tunnel to P 573 while avoiding E. 575 o P maintains a dedicated label space or a dedicated IP address 576 space for E, depending on whether the service is MPLS or IP. This 577 is referred to as "E's label space" or "E's IP address space", 578 respectively. P uses the context ID to identify the space. 580 o If the service is an MPLS service, E also distributes the service 581 label binding message to P. This is the same label binding 582 message that E advertises to the ingress router, which is attached 583 with the context ID. Based on the context ID, P installs the 584 service label in an MPLS forwarding table corresponding to E's 585 label space. If the service is an IP service, P installs an IP 586 route in an IP forwarding table corresponding to E's IP address 587 space. In either case, the protection service instance on P 588 interprets the service and constructs forwarding state for the 589 route based on P's own connectivity with the service's 590 destination. 592 o P assigns a non-reserved label to the context ID. In the data 593 plane, this label represents the context ID and indicates E's 594 label space and IP address space. Therefore, it is called a 595 "context label". 597 o The PLR may establish the egress-protection bypass tunnel to P in 598 several manners. If the bypass tunnel is established by RSVP, the 599 PLR signals the bypass tunnel with the context ID as destination, 600 and P binds the context label to the bypass tunnel. If the bypass 601 tunnel is established by LDP, P advertises the context label for 602 the context ID as an IP prefix FEC. If the bypass tunnel is 603 established by the PLR in a hierarchical manner, the PLR treats 604 the context label as a one-hop LSP over a regular bypass tunnel to 605 P (e.g. a bypass tunnel to P's loopback IP address). If the 606 bypass tunnel is constructed by using segment routing, the bypass 607 tunnel is represented by a stack of SID labels with the context 608 label as the inner-most SID label (Section 5.9). In any case, the 609 bypass tunnel is a UHP tunnel whose incoming label on P is the 610 context label. 612 o During local repair, all the service packets received by P on the 613 bypass tunnel have the context label as the top label. P first 614 pops the context label. For an MPLS service packet, P further 615 looks up the service label in E's label space indicated by the 616 context label, which is called context label switching. For an IP 617 service packet, P looks up the IP destination address in E's IP 618 address space indicated by the context label, which is called 619 context IP forwarding. 621 5.8. Advertisement and path resolution for context ID 623 Path resolution and computation for a context ID are done on ingress 624 routers for egress-protected tunnels, and on PLRs for egress- 625 protection bypass tunnels. Given a protected egress {E, P} and its 626 context ID, E and P MUST coordinate the context ID in the routing 627 domain and the TE domain via IGP advertisement. The context ID MUST 628 be advertised in such a manner that all egress-protected tunnels MUST 629 have E as tailend, and all egress-protection bypass tunnels MUST have 630 P as tailend while avoiding E. 632 This document suggests three approaches: 634 1. The first approach is called "proxy mode". It requires E and P, 635 but not the PLR, to have the knowledge of the egress protection 636 schema. E and P advertise the context ID as a virtual proxy node 637 (i.e. a logical node) connected to the two routers, with the link 638 between the proxy node and E having more preferable IGP and TE 639 metrics than the link between the proxy node and P. Therefore, 640 all egress-protected tunnels destined for the context ID should 641 automatically follow the IGP or TE paths to E. Each PLR will no 642 longer view itself as a penultimate-hop, but rather two hops away 643 from the proxy node, via E. The PLR will be able to find a 644 bypass path via P to the proxy node, while the bypass tunnel 645 should actually be terminated by P. 647 2. The second approach is called "alias mode". It requires P and 648 the PLR, but not E, to have the knowledge of the egress 649 protection schema. E simply advertises the context ID as a 650 regular IP address. P advertises the context ID and the context 651 label by using a "context ID label binding" advertisement. The 652 advertisement MUST be understood by the PLR. In both routing 653 domain and TE domain, the context ID is only reachable via E. 654 This ensures that all egress-protected tunnels destined for the 655 context ID should have E as tailend. Based on the "context ID 656 label binding" advertisement, the PLR can establish an egress- 657 protection bypass tunnel in several manners (Section 5.9). The 658 "context ID label binding" advertisement is defined as IGP 659 mirroring context segment in [RFC8402], [SR-OSPF] and [SR-ISIS]. 660 These IGP extensions are generic in nature, and hence can be used 661 for egress protection purposes. 663 3. The third approach is called "stub link mode". In this mode, 664 both E and P advertise the context ID as a link to a stub 665 network, essentially modelling the context ID as an any-cast IP 666 address owned by the two routers. E, P and the PLR do not need 667 to have the knowledge of the egress protection schema. The 668 correctness of the egress-protected tunnels and the bypass 669 tunnels relies on the path computations for the any-cast IP 670 address performed by the ingress routers and PLR. Therefore, 671 care MUST be taken for the applicability of this approach to a 672 given network topology. 674 In a scenario where an egress-protected tunnel is an inter-area or 675 inter-AS tunnel, its associated context ID MUST be propagated from 676 the original area/AS to other areas/AS' via IGP or BGP, so that the 677 ingress router of the tunnel can have the reachability to the context 678 ID. The propagation process of the context ID SHOULD be the same as 679 that of a regular IP address in an inter-area/AS environment. 681 5.9. Egress-protection bypass tunnel establishment 683 A PLR MUST know the context ID of a protected egress {E, P} in order 684 to establish an egress-protection bypass tunnel. The information is 685 obtained from the signaling or label distribution protocol of the 686 egress-protected tunnel. The PLR may or may not need to have the 687 knowledge of the egress protection schema. All it does is to set up 688 a bypass tunnel to a context ID while avoiding the next-hop router 689 (i.e. egress router). This is achievable by using a constraint-based 690 computation algorithm similar to those which are commonly used in the 691 computation of traffic engineering paths and loop-free alternate 692 (LFA) paths. Since the context ID is advertised in the routing 693 domain and the TE domain by IGP according to Section 5.8, the PLR 694 should be able to resolve or establish such a bypass path with the 695 protector as tailend. In some cases like the proxy mode, the PLR may 696 do so in the same manner as transit node protection. 698 An egress-protection bypass tunnel may be established via several 699 methods: 701 (1) It may be established by a signaling protocol (e.g. RSVP), with 702 the context ID as destination. The protector binds the context label 703 to the bypass tunnel. 705 (2) It may be formed by a topology driven protocol (e.g. LDP with 706 various LFA mechanisms). The protector advertises the context ID as 707 an IP prefix FEC, with the context label bound to it. 709 (3) It may be constructed as a hierarchical tunnel. When the 710 protector uses the alias mode (Section 5.8), the PLR will have the 711 knowledge of the context ID, context label, and protector (i.e. the 712 advertiser). The PLR can then establish the bypass tunnel in a 713 hierarchical manner, with the context label as a one-hop LSP over a 714 regular bypass tunnel to the protector's IP address (e.g. loopback 715 address). This regular bypass tunnel may be established by RSVP, 716 LDP, segment routing, or another protocol. 718 5.10. Local repair on PLR 720 In this framework, a PLR is agnostic to services and service labels. 721 This obviates the need to maintain bypass forwarding state on a per- 722 service basis, and allows bypass tunnel sharing between egress- 723 protected tunnels. The PLR may share an egress-protection bypass 724 tunnel for multiple egress-protected tunnels associated with a common 725 protected egress {E, P}. During local repair, the PLR reroutes all 726 service packets received on the egress-protected tunnels via the 727 egress-protection bypass tunnel. Service labels remain intact in 728 MPLS service packets. 730 Label operation during the rerouting depends on the bypass tunnel's 731 characteristics. If the bypass tunnel is a single level tunnel, the 732 rerouting will involve swapping the incoming label of an egress- 733 protected tunnel to the outgoing label of the bypass tunnel. If the 734 bypass tunnel is a hierarchical tunnel, the rerouting will involve 735 swapping the incoming label of an egress-protected tunnel to a 736 context label, and pushing the outgoing label of a regular bypass 737 tunnel. If the bypass tunnel is constructed by segment routing, the 738 rerouting will involve swapping the incoming label of an egress- 739 protected tunnel to a context label, and pushing a stack of SID 740 labels of the bypass tunnel. 742 5.11. Service label distribution from egress router to protector 744 When a protector receives a rerouted MPLS service packet, it performs 745 context label switching based on the packet's service label which is 746 assigned by the corresponding egress router. In order to achieve 747 this, the protector MUST maintain such kind of service labels in 748 dedicated label spaces on a per protected egress {E, P} basis, i.e. 749 one label space for each egress router that it protects. 751 Also, there MUST be a service label distribution protocol session 752 between each egress router and the protector. Through this protocol, 753 the protector learns the label binding of each egress-protected 754 service. This is the same label binding that the egress router 755 advertises to the service's ingress router, which is attached with a 756 context ID. The corresponding protection service instance on the 757 protector recognizes the service, and resolves forwarding state based 758 on its own connectivity with the service's destination. It then 759 installs the service label with the forwarding state in the label 760 space of the egress router, which is indicated by the context ID 761 (i.e. context label). 763 Different service protocols may use different mechanisms for such 764 kind of label distribution. Specific protocol extensions may be 765 needed on a per-protocol basis or per-service-type basis. The 766 details of the extensions SHOULD be specified in separate documents. 767 As an example, [RFC8104] specifies the LDP extensions for pseudowire 768 services. 770 5.12. Centralized protector mode 772 In this framework, it is assumed that the service destination of an 773 egress-protected service MUST be dual-homed to two edge routers of an 774 MPLS network. One of them is the protected egress router, and the 775 other is a backup egress router. So far in this document, the 776 discussion has been focusing on the scenario where a protector and a 777 backup egress router are co-located as one router. Therefore, the 778 number of protectors in a network is equal to the number of backup 779 egress routers. As another scenario, a network may assign a small 780 number of routers to serve as dedicated protectors, each protecting a 781 subset of egress routers. These protectors are called centralized 782 protectors. 784 Topologically, a centralized protector may be decoupled from all 785 backup egress routers, or it may be co-located with one backup egress 786 router while decoupled from the other backup egress routers. The 787 procedures in this section assume that a protector and a backup 788 egress router are decoupled. 790 services 1, ..., N 791 =====================================> tunnel 793 I ------ R1 ------- PLR --------------- E ---- 794 ingress penultimate-hop egress \ 795 | . (primary \ 796 | . service \ 797 | . instances) \ 798 | . \ 799 | . bypass \ service 800 R2 . tunnel destinations 801 | . / (CEs, sites) 802 | . / 803 | . / 804 | . / 805 | . tunnel / 806 | =============> / 807 P ---------------- E' --- 808 protector backup egress 809 (protection (backup 810 service service 811 instances) instances) 813 Figure 2 815 Like a co-located protector, a centralized protector hosts protection 816 service instances, receives rerouted service packets from PLRs, and 817 performs context label switching and/or context IP forwarding. For 818 each service, instead of sending service packets directly to the 819 service destination, the protector MUST send them via another 820 transport tunnel to the corresponding backup service instance on a 821 backup egress router. The backup service instance in turn forwards 822 them to the service destination. Specifically, in the case of an 823 MPLS service, the protector MUST swap the service label in each 824 received service packet to the label of the backup service advertised 825 by the backup egress router, and then push the label (or label stack) 826 of the transport tunnel. 828 In order for a centralized protector to map an egress-protected MPLS 829 service to a service hosted on a backup egress router, there MUST be 830 a service label distribution protocol session between the backup 831 egress router and the protector. Through this session, the backup 832 egress router advertises the service label of the backup service, 833 attached with the FEC of the egress-protected service and the context 834 ID of the protected egress {E, P}. Based on this information, the 835 protector associates the egress-protected service with the backup 836 service, resolves or establishes a transport tunnel to the backup 837 egress router, and accordingly sets up forwarding state for the label 838 of the egress-protected service in the label space of the egress 839 router. 841 The service label which the backup egress router advertises to the 842 protector can be the same as the label which the backup egress router 843 advertises to the ingress router(s), if and only if the forwarding 844 state of the label does not direct service packets towards the 845 protected egress router. Otherwise, the label cannot be used for 846 egress protection, because it will create a loop for the service 847 packets. In this case, the backup egress router MUST advertise a 848 unique service label for egress protection, and set up the forwarding 849 state of the label to use the backup egress router's own connectivity 850 with the service destination. 852 6. Egress link protection 854 Egress link protection is achievable through procedures similar to 855 that of egress node protection. In normal situations, an egress 856 router forwards service packets to a service destination based on a 857 service label, whose forwarding state points to an egress link. In 858 egress link protection, the egress router acts as the PLR, and 859 performs local failure detection and local repair. Specifically, the 860 egress router pre-establishes an egress-protection bypass tunnel to a 861 protector, and sets up the bypass forwarding state for the service 862 label to point to the bypass tunnel. During local repair, the egress 863 router reroutes service packets via the bypass tunnel to the 864 protector. The protector in turn forwards the packets to the service 865 destination (in the co-located protector mode, as shown in Figure-3), 866 or forwards the packets to a backup egress router (in the centralized 867 protector mode, as shown in Figure-4). 869 service 870 =====================================> tunnel 872 I ------ R1 ------- R2 --------------- E ---- 873 ingress | ............. egress \ 874 | . PLR \ 875 | . (primary \ 876 | . service \ 877 | . instance) \ 878 | . \ 879 | . bypass service 880 | . tunnel destination 881 | . / (CE, site) 882 | . / 883 | . / 884 | . / 885 | . / 886 | ............... / 887 R3 --------------- P ---- 888 protector 889 (protection 890 service 891 instance) 893 Figure 3 895 service 896 =====================================> tunnel 898 I ------ R1 ------- R2 --------------- E ---- 899 ingress | ............. egress \ 900 | . PLR \ 901 | . (primary \ 902 | . service \ 903 | . instance) \ 904 | . \ 905 | . bypass service 906 | . tunnel destination 907 | . / (CE, site) 908 | . / 909 | . / 910 | . / 911 | . tunnel / 912 | =============> / 913 R3 --------------- P ---- 914 protector backup egress 915 (protection (backup 916 service service 917 instance) instance) 919 Figure 4 921 There are two approaches to set up the bypass forwarding state on the 922 egress router, depending on whether the egress router knows the 923 service label allocated by the backup egress router. The difference 924 is that one approach requires the protector to perform context label 925 switching, and the other one does not. Both approaches are equally 926 supported by this framework, and may be used in parallel. 928 (1) The first approach applies when the egress router does not 929 know the service label allocated by the backup egress router. In 930 this case, the egress router sets up the bypass forwarding state 931 as a label push with the outgoing label of the egress-protection 932 bypass tunnel. Rerouted packets will have the egress router's 933 service label intact. Therefore, the protector MUST perform 934 context label switching, and the bypass tunnel MUST be destined 935 for the context ID of the {E, P} and established as described in 936 Section 5.9. This approach is consistent with egress node 937 protection. Hence, a protector can serve in egress node 938 protection and egress link protection in a consistent manner, and 939 both the co-located protector mode and the centralized protector 940 mode may be used (Figure-3 and Figure-4). 942 (2) The second approach applies when the egress router knows the 943 service label allocated by the backup egress router, via a label 944 distribution protocol session. In this case, the backup egress 945 router serves as the protector for egress link protection, 946 regardless of the protector of egress node protection, which 947 should be the same router in the co-located protector mode but a 948 different router in the centralized protector mode. The egress 949 router sets up the bypass forwarding state as a label swap from 950 the incoming service label to the service label of the backup 951 egress router (i.e. protector), followed by a push with the 952 outgoing label (or label stack) of the egress link protection 953 bypass tunnel. The bypass tunnel is a regular tunnel destined for 954 an IP address of the protector, instead of the context ID of the 955 {E, P}. The protector simply forwards rerouted service packets 956 based on its own service label, rather than performing context 957 label switching. In this approach, only the co-located protector 958 mode is applicable. 960 Note that for a bidirectional service, the physical link of an egress 961 link may carry service traffic bi-directionally. Therefore, an 962 egress link failure may simultaneously be an ingress link failure for 963 the traffic in the opposite direction. However, protection for 964 ingress link failure SHOULD be provided by a separate mechanism, and 965 hence is out of the scope of this document. 967 7. Global repair 969 This framework provides a fast but temporary repair for egress node 970 and egress link failures. For permanent repair, it is RECOMMENDED 971 that the services affected by a failure SHOULD be moved to an 972 alternative tunnel, or replaced by alternative services, which are 973 fully functional. This is referred to as global repair. Possible 974 triggers of global repair include control plane notifications of 975 tunnel and service status, end-to-end OAM and fault detection at 976 tunnel or service level, and others. The alternative tunnel and 977 services may be pre-established in standby state, or dynamically 978 established as a result of the triggers or network protocol 979 convergence. 981 8. Example: Layer-3 VPN egress protection 983 This section shows an example of egress protection for a layer-3 VPN. 985 ---------- R1 ----------- PE2 - 986 / (PLR) (PLR) \ 987 ( ) / | | ( ) 988 ( ) / | | ( ) 989 ( site 1 )-- PE1 < | R3 ( site 2 ) 990 ( ) \ | | ( ) 991 ( ) \ | | ( ) 992 \ | | / 993 ---------- R2 ----------- PE3 - 994 (protector) 996 Figure 5 998 In this example, the site 1 (subnet 203.0.113.192/26) of a given VPN 999 is attached to PE1, and site 2 (subnet 203.0.113.128/26) is dual- 1000 homed to PE2 and PE3. PE2 is the primary PE for site 2, and PE3 is 1001 the backup PE. Each PE hosts a VPN instance. R1 and R2 are transit 1002 routers in the MPLS network. The network uses OSPF as routing 1003 protocol, and RSVP-TE as tunnel signaling protocol. The PEs use BGP 1004 to exchange VPN prefixes and VPN labels between each other. 1006 Using the framework in this document, the network assigns PE3 to be a 1007 protector for PE2 to protect the VPN traffic in the direction from 1008 site 1 to site 2. This is the co-located protector mode. Hence, PE2 1009 and PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 1010 is assigned to the protected egress {PE2, PE3}. The VPN instance on 1011 PE3 serves as a protection instance for the VPN instance on PE2. On 1012 PE3, a context label 100 is assigned to the context ID, and a label 1013 table pe2.mpls is created to represent PE2's label space. PE3 1014 installs the label 100 in its default MPLS forwarding table, with 1015 nexthop pointing to the label table pe2.mpls. PE2 and PE3 are 1016 coordinated to use the proxy mode to advertise the context ID in the 1017 routing domain and the TE domain. 1019 PE2 uses per-VRF VPN label allocation mode. It assigns a single 1020 label 9000 to the VRF of the VPN. For a given VPN prefix 1021 203.0.113.128/26 in site 2, PE2 advertises it along with the label 1022 9000 and other attributes to PE1 and PE3 via BGP. In particular, the 1023 NEXT_HOP attribute is set to the context ID 198.51.100.1. 1025 Similarly, PE3 also uses per-VRF VPN label allocation mode. It 1026 assigns a single label 10000 to the VRF of the VPN. For the VPN 1027 prefix 203.0.113.128/26 in site 2, PE3 advertises it along with the 1028 label 10000 and other attributes to PE1 and PE2 via BGP. In 1029 particular, the NEXT_HOP attribute is set to an IP address of PE3. 1031 Upon receipt and acceptance of the BGP advertisement, PE1 uses the 1032 context ID 198.51.100.1 as destination to compute a TE path for an 1033 egress-protected tunnel. The resulted path is PE1->R1->PE2. PE1 1034 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1 1035 as destination, and with the "node protection desired" flag set in 1036 the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes 1037 up, PE1 maps the VPN prefix 203.0.113.128/26 to the tunnel and 1038 installs a route for the prefix in the corresponding VRF. The 1039 route's nexthop is a push with the VPN label 9000, followed by a push 1040 with the outgoing label of the egress-protected tunnel. 1042 Upon receipt of the above BGP advertisement from PE2, PE3 (i.e. the 1043 protector) recognizes the context ID 198.51.100.1 in the NEXT_HOP 1044 attribute, and installs a route for label 9000 in the label table 1045 pe2.mpls. PE3 sets the route's nexthop to a "protection VRF". This 1046 protection VRF contains IP routes corresponding to the IP prefixes in 1047 the dual-homed site 2, including 203.0.113.128/26. The nexthops of 1048 these routes MUST be based on PE3's connectivity with site 2, even if 1049 this connectivity is not the best path in PE3's VRF due to metrics 1050 (e.g. MED, local preference, etc.), and MUST NOT use any path 1051 traversing PE2. Note that the protection VRF is a logical concept, 1052 and it may simply be PE3's own VRF if the VRF satisfies the 1053 requirement. 1055 8.1. Egress node protection 1057 R1, i.e. the penultimate-hop router of the egress-protected tunnel, 1058 serves as the PLR for egress node protection. Based on the "node 1059 protection desired" flag and the destination address (i.e. context ID 1060 198.51.100.1) of the tunnel, R1 computes a bypass path to 1061 198.51.100.1 while avoiding PE2. The resulted bypass path is 1062 R1->R2->PE3. R1 then signals the path (i.e. egress-protection bypass 1063 tunnel), with 198.51.100.1 as destination. 1065 Upon receipt of an RSVP Path message of the egress-protection bypass 1066 tunnel, PE3 recognizes the context ID 198.51.100.1 as the 1067 destination, and hence responds with the context label 100 in an RSVP 1068 Resv message. 1070 After the egress-protection bypass tunnel comes up, R1 installs a 1071 bypass nexthop for the egress-protected tunnel. The bypass nexthop 1072 is a swap from the incoming label of the egress-protected tunnel to 1073 the outgoing label of the egress-protection bypass tunnel. 1075 When R1 detects a failure of PE2, it will invoke the above bypass 1076 nexthop to reroute VPN service packets. The packets will have the 1077 label of the bypass tunnel as outer label, and the VPN label 9000 as 1078 inner label. When the packets arrive at PE3, they will have the 1079 context label 100 as outer label, and the VPN label 9000 as inner 1080 label. The context label will first be popped, and then the VPN 1081 label will be looked up in the label table pe2.mpls. The lookup will 1082 cause the VPN label to be popped, and the IP packets will finally be 1083 forwarded to site 2 based on the protection VRF. 1085 8.2. Egress link protection 1087 PE2 serves as the PLR for egress link protection. It has already 1088 learned the VPN label 10000 from PE3, and hence it uses the approach 1089 (2) described in Section 6 to set up bypass forwarding state. It 1090 signals an egress-protection bypass tunnel to PE3, by using the path 1091 PE2->R3->PE3, and PE3's IP address as destination. After the bypass 1092 tunnel comes up, PE2 installs a bypass nexthop for the VPN label 1093 9000. The bypass nexthop is a label swap from the incoming label 1094 9000 to the VPN label 10000 of PE3, followed by a label push with the 1095 outgoing label of the bypass tunnel. 1097 When PE2 detects a failure of the egress link, it will invoke the 1098 above bypass nexthop to reroute VPN service packets. The packets 1099 will have the label of the bypass tunnel as outer label, and the VPN 1100 label 10000 as inner label. When the packets arrive at PE3, the VPN 1101 label 10000 will be popped, and the IP packets will be forwarded 1102 based on the VRF indicated by on the VPN label 10000. 1104 8.3. Global repair 1106 Eventually, global repair will take effect, as control plane 1107 protocols converge on the new topology. PE1 will choose PE3 as new 1108 entrance to site 2. Before that happens, the VPN traffic has been 1109 protected by the above local repair. 1111 9. IANA Considerations 1113 This document has no request for new IANA allocation. 1115 10. Security Considerations 1117 The framework in this document relies on fast reroute around a 1118 network failure. Specifically, service traffic is temporarily 1119 rerouted from a PLR to a protector. In the centralized protector 1120 mode, the traffic is further rerouted from the protector to a backup 1121 egress router. Such kind of fast reroute is planned and anticipated, 1122 and hence it should not be viewed as a new security threat. 1124 The framework requires a service label distribution protocol to run 1125 between an egress router and a protector. The available security 1126 measures of the protocol MAY be used to achieve a secured session 1127 between the two routers. 1129 11. Acknowledgements 1131 This document leverages work done by Yakov Rekhter, Kevin Wang and 1132 Zhaohui Zhang on MPLS egress protection. Thanks to Alexander 1133 Vainshtein, Rolf Winter, Lizhong Jin, and Krzysztof Szarkowicz for 1134 their valuable comments that helped to shape this document and 1135 improve its clarity. 1137 12. References 1139 12.1. Normative References 1141 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1142 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1143 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1144 July 2018, . 1146 [SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1147 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1148 Extensions for Segment Routing", draft-ietf-ospf-segment- 1149 routing-extensions (work in progress), 2017. 1151 [SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1152 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1153 Extensions for Segment Routing", draft-ietf-isis-segment- 1154 routing-extensions (work in progress), 2017. 1156 12.2. Informative References 1158 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1159 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1160 DOI 10.17487/RFC4090, May 2005, 1161 . 1163 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1164 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1165 DOI 10.17487/RFC5286, September 2008, 1166 . 1168 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1169 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 1170 RFC 7490, DOI 10.17487/RFC7490, April 2015, 1171 . 1173 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 1174 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 1175 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 1176 . 1178 [RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, 1179 "Pseudowire (PW) Endpoint Fast Failure Protection", 1180 RFC 8104, DOI 10.17487/RFC8104, March 2017, 1181 . 1183 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 1184 "Extensions to RSVP-TE for Label Switched Path (LSP) 1185 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 1186 2018, . 1188 [BGP-PIC] Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix 1189 Independent Convergence", draft-ietf-rtgwg-bgp-pic-08.txt 1190 (work in progress), 2017. 1192 Authors' Addresses 1194 Yimin Shen 1195 Juniper Networks 1196 10 Technology Park Drive 1197 Westford, MA 01886 1198 USA 1200 Phone: +1 9785890722 1201 Email: yshen@juniper.net 1203 Minto Jeyananth 1204 Juniper Networks 1205 1133 Innovation Way 1206 Sunnyvale, CA 94089 1207 USA 1209 Phone: +1 4089367563 1210 Email: minto@juniper.net 1212 Bruno Decraene 1213 Orange 1215 Email: bruno.decraene@orange.com 1216 Hannes Gredler 1217 RtBrick Inc 1219 Email: hannes@rtbrick.com 1221 Carsten Michel 1222 Deutsche Telekom 1224 Email: c.michel@telekom.de 1226 Huaimo Chen 1227 Huawei Technologies Co., Ltd. 1229 Email: huaimo.chen@huawei.com 1231 Yuanlong Jiang 1232 Huawei Technologies Co., Ltd. 1233 Bantian, Longgang district 1234 Shenzhen 518129 1235 China 1237 Email: jiangyuanlong@huawei.com