idnits 2.17.1 draft-ietf-mpls-egress-protection-framework-01.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 (June 22, 2018) is 2134 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) == Unused Reference: 'RFC8104' is defined on line 1174, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-rtgwg-bgp-pic-05 Summary: 0 errors (**), 0 flaws (~~), 3 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: December 24, 2018 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 June 22, 2018 16 MPLS Egress Protection Framework 17 draft-ietf-mpls-egress-protection-framework-01 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 egress 25 node failure, and the egress router of the MPLS tunnel acts as the 26 PLR for egress link failure. Each of them pre-establishes a bypass 27 tunnel to a protector. Upon an egress node or link failure, the 28 corresponding PLR performs local failure detection and local repair, 29 by rerouting packets over the corresponding bypass tunnel. The 30 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 to the 38 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 December 24, 2018. 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 should host the 116 corresponding service instances of the services. An MPLS service 117 instance is responsible for forwarding service packets via an egress 118 link to the service destination, based on a service label. An IP 119 service instance is responsible for doing the same based on a service 120 IP address. The egress link is often called a PE-CE (provider edge - 121 customer edge) 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. They can achieve 126 fast restoration of traffic in the order of tens of milliseconds. 127 Local repair refers to the scenario where the router upstream to an 128 anticipated failure (aka. PLR, i.e. point of local repair) pre- 129 establishes a bypass tunnel to the router downstream of the failure 130 (aka. MP, i.e. merge point), and pre-installs the forwarding state 131 of the bypass tunnel in the data plane. The PLR also uses a rapid 132 mechanism (e.g. link layer OAM, BFD, and others) to locally detect 133 the failure in the data plane. When the failure occurs, the PLR 134 reroutes traffic through the bypass tunnel to the MP, allowing the 135 traffic to continue to flow to the 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 relies on a PLR to perform local failure detection and 140 local repair. In egress node protection, the PLR is the penultimate- 141 hop router of a tunnel. In egress link protection, the PLR is the 142 egress router of the tunnel. The framework relies on a so-called 143 "protector" to serve as the tailend of a bypass tunnel. The 144 protector is a router that hosts "protection service instances" and 145 has its own connectivity or paths to service destinations. When a 146 PLR is doing local repair, the protector is responsible for 147 performing "context label switching" for rerouted MPLS service 148 packets and "context IP forwarding" for rerouted IP service packets. 149 Thus, the service packets can continue to reach service destinations 150 with minimum disruption. 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, 163 normally via two MPLS edge routers. One of them is the egress router 164 of the service's transport tunnel, and the other is a backup egress 165 router which hosts "backup service instances". In the "co-located" 166 protector mode in this document, the backup egress router serves as a 167 protector, and hence each backup service instance acts as a 168 protection instance. In the "centralized" protector mode 169 (Section 5.12), a protector and a backup egress router are decoupled, 170 and each protection service instance and its corresponding backup 171 service instance are hosted on separate 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, when 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 further 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 future extensions 193 to the protocols which may facilitate the procedures. One example of 194 such extension is [RSVP-EP]. The framework may need extensions for 195 IGPs 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 to achieve more 213 effective protection. That is, the framework provides fast and 214 temporary repair, and control-plane convergence or global repair 215 provides ultimate and permanent repair. 217 2. Specification of Requirements 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in RFC2119. 223 3. Terminology 225 Egress router - A router at the egress endpoint of a tunnel. It 226 hosts service instances for all the services carried by the tunnel, 227 and has connectivity with the destinations of the services. 229 Egress node failure - A failure of an egress router. 231 Egress link failure - A failure of the egress link (e.g. PE-CE link, 232 attachment circuit) of a service. 234 Egress failure - An egress node failure or an egress link failure. 236 Egress-protected tunnel - A tunnel whose egress router is protected 237 by a mechanism according to this framework. The egress router is 238 hence called a protected egress router. 240 Egress-protected service - An IP or MPLS service which is carried by 241 an egress-protected tunnel, and hence protected by a mechanism 242 according to this framework. 244 Backup egress router - Given an egress-protected tunnel and its 245 egress router, this is another router which has connectivity with all 246 or a subset of the destinations of the egress-protected services 247 carried by the egress-protected tunnel. 249 Backup service instance - A service instance which is hosted by a 250 backup egress router, and corresponding to an egress-protected 251 service on a protected egress router. 253 Protector - A role acted by a router as an alternate of a protected 254 egress router, to handle service packets in the event of an egress 255 failure. A protector may be physically co-located with or decoupled 256 from a backup egress router, depending on the co-located or 257 centralized protector mode. 259 Protection service instance - A service instance hosted by a 260 protector, corresponding to the service instance of an egress- 261 protected service on a protected egress router. A protection service 262 instance is a backup service instance, if the protector is co-located 263 with a backup egress router. 265 PLR - A router at the point of local repair. In egress node 266 protection, it is the penultimate-hop router on an egress-protected 267 tunnel. In egress link protection, it is the egress router of the 268 egress-protected tunnel. 270 Protected egress {E, P} - A virtual node consisting of an ordered 271 pair of egress router E and protector P. It serves as the virtual 272 destination of an egress-protected tunnel, and as the virtual 273 location of the egress-protected services carried by the tunnel. 275 Context identifier (ID) - A globally unique IP address assigned to a 276 protected egress {E, P}. 278 Context label - A non-reserved label assigned to a context ID by a 279 protector. 281 Egress-protection bypass tunnel - A tunnel used to reroute service 282 packets around an egress failure. 284 Co-located protector mode - The scenario where a protector and a 285 backup egress router are co-located as one router, and hence each 286 backup service instance serves as a protection service instance. 288 Centralized protector mode - The scenario where a protector is a 289 dedicated router, and is decoupled from backup egress routers. 291 Context label switching - Label switching performed by a protector, 292 in the label space of an egress router indicated by a context label. 294 Context IP forwarding - IP forwarding performed by a protector, in 295 the IP address space of an egress router indicated by a context 296 label. 298 4. Requirements 300 This document considers the followings as the design requirements of 301 this egress protection framework. 303 o The framework must support P2P tunnels. It should equally support 304 P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P 305 tunnel. 307 o The framework must support multi-service and multi-transport 308 networks. It must accommodate existing and future signaling and 309 label-distribution protocols of tunnels and bypass tunnels, 310 including RSVP, LDP, BGP, IGP, segment routing, and others. It 311 must also accommodate existing and future IP/MPLS services, 312 including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and 313 others. It must provide a generic solution for environments where 314 different types of services and tunnels may co-exist. 316 o The framework must consider minimizing disruption during 317 deployment. It should only involve routers close to egress, and 318 be transparent to ingress routers and other transit routers. 320 o In egress node protection, for scalability and performance 321 reasons, a PLR must be agnostic to services and service labels, 322 like PLRs in transit link/node protection. It must maintain 323 bypass tunnels and bypass forwarding state on a per-transport- 324 tunnel basis, rather than per-service-destination or per-service- 325 label basis. It should also support bypass tunnel sharing between 326 transport tunnels. 328 o A PLR must be able to use its local visibility or information of 329 routing and/or TE topology to compute or resolve a path for a 330 bypass tunnel to a protector. 332 o A protector must be able to perform context label switching for 333 rerouted MPLS service packets, based on service label(s) assigned 334 by an egress router. It must be able to perform context IP 335 forwarding for rerouted IP service packets, in the public or 336 private IP address space used by an egress router. 338 o The framework must be able to work seamlessly with transit link/ 339 node protection mechanisms to achieve end-to-end coverage. 341 o The framework must be able to work in conjunction with global 342 repair and control plane convergence. 344 5. Egress node protection 346 5.1. Reference topology 348 This document refers to the following topology when describing the 349 procedures of egress node protection. 351 services 1, ..., N 352 =====================================> tunnel 354 I ------ R1 ------- PLR --------------- E ---- 355 ingress penultimate-hop egress \ 356 | . (primary \ 357 | . service \ 358 | . instances) \ 359 | . \ 360 | . \ service 361 | . destinations 362 | . / (CEs, sites) 363 | . / 364 | . bypass / 365 | . tunnel / 366 | . / 367 | ............... / 368 R2 --------------- P ---- 369 protector 370 (protection 371 service 372 instances) 374 Figure 1 376 5.2. Egress node failure and detection 378 An egress node failure refers to the failure of an MPLS tunnel's 379 egress router. At the service level, it also means a service 380 instance failure for each IP/MPLS service carried by the tunnel. 382 Ideally, an egress node failure can be detected by an adjacent router 383 (i.e. PLR in this framework) using a node liveness detection 384 mechanism, or based on a collective failure of all the links to that 385 node. However, the assumption is that the mechanisms SHOULD be 386 reasonably fast, i.e. faster than control plane failure detection and 387 remote failure detection. Otherwise, local repair will not be able 388 to provide much benefit compared to control plane convergence or 389 global repair. In general, the speed, accuracy, and reliability of a 390 mechanism are the key factors to decide its applicability in egress 391 node protection. This document provides the following guidelines in 392 this regard. 394 o If the PLR has a reasonably fast mechanism to detect and 395 differentiate a link failure (of the link between the PLR and the 396 egress node) and an egress node failure, it SHOULD set up both 397 link protection and egress node protection, and trigger one and 398 only one protection upon a corresponding failure. 400 o If the PLR has a fast mechanism to detect a link failure and an 401 egress node failure, but cannot distinguish them; Or, if the PLR 402 has a fast mechanism to detect a link failure only, but not an 403 egress node failure, the PLR has two options: 405 1. It MAY set up link protection only, and leave the egress node 406 failure to global repair and control plane convergence to 407 handle. 409 2. It MAY set up egress node protection only, and treat a link 410 failure as a trigger for the egress node protection. However, 411 the assumption is that treating a link failure as an egress 412 node failure MUST NOT have a negative impact on services. 413 Otherwise, it SHOULD adopt the previous option. 415 5.3. Protector and PLR 417 A router is assigned to the "protector" role to protect a tunnel and 418 the services carried by the tunnel against an egress node failure. 419 The protector is responsible for hosting a protection service 420 instance for each protected service, serving as the tailend of a 421 bypass tunnel, and performing context label switching and/or context 422 IP forwarding for rerouted service packets. 424 A tunnel can be protected by only one protector at a given time. 425 Multiple tunnels to a given egress router may be protected by a 426 common protector or different protectors. A protector may protect 427 multiple tunnels with a common egress router or different egress 428 routers. 430 For each tunnel, its penultimate-hop router acts as a PLR. The PLR 431 pre-establishes a bypass tunnel to the protector, and pre-installs 432 bypass forwarding state in the data plane. Upon detection of an 433 egress node failure, the PLR reroutes all the service packets 434 received on the tunnel though the bypass tunnel to the protector. 435 For MPLS service packets, the PLR keeps service labels intact in the 436 packets. The protector in turn forwards the rerouted service packets 437 towards the ultimate service destinations. Specifically, it performs 438 context label switching for MPLS service packets, based on service 439 labels assigned by the protected egress router; It performs context 440 IP forwarding for IP service packets, based on their destination 441 addresses. 443 The protector MUST have its own connectivity with each service 444 destination, via a direct link or a multi-hop path, which MUST NOT 445 traverse the protected egress router or be affected by the egress 446 node failure. This also requires that each service destination MUST 447 be dual-homed or have dual paths to the egress router and a backup 448 egress router which serves as the protector. Each protection service 449 instance on the protector relies on such connectivity to set up 450 forwarding state for context label switching and/or context IP 451 forwarding. 453 5.4. Protected egress 455 This document introduces the notion of "protected egress" as a 456 virtual node consisting of the egress router E of a tunnel and a 457 protector P. It is denoted by an ordered pair of {E, P}, indicating 458 the primary-and-protector relationship between the two routers. It 459 serves as the virtual destination of the tunnel, and the virtual 460 location of service instances for the services carried by the tunnel. 461 The tunnel and services are considered as being "associated" with the 462 protected egress {E, P}. 464 A given egress router E may be the tailend of multiple tunnels. In 465 general, the tunnels may be protected by multiple protectors, e.g. 466 P1, P2, and so on, with each Pi protecting a subset of the tunnels. 467 Thus, these routers form multiple protected egresses, i.e. {E, P1} , 468 {E, P2}, and so on. Each tunnel is associated with one and only one 469 protected egress {E, Pi}. All the services carried by the tunnel are 470 then automatically associated with the same protected egress {E, Pi}. 471 Conversely, a service associated with a protected egress {E, Pi} MUST 472 be carried by a tunnel associated with the protected egress {E, Pi}. 473 This mapping MUST be ensured by the ingress router of the tunnel and 474 the service (Section 5.5). 476 Two routers X and Y may be protectors for each other. In this case, 477 they form two distinct protected egresses {X, Y} and {Y, X}. 479 5.5. Egress-protected tunnel and service 481 A tunnel, which is associated with a protected egress {E, P}, is 482 called an egress-protected tunnel. It is associated with one and 483 only one protected egress {E, P}. Multiple egress-protected tunnels 484 may be associated with a given protected egress {E, P}. In this case, 485 they share the common egress router and protector, but may or may not 486 share a common ingress router, or a common PLR (i.e. penultimate-hop 487 router). 489 An egress-protected tunnel is considered as logically "destined" for 490 its protected egress {E, P}. However, its path MUST be resolved and 491 established with E as the physical tailend. 493 A service, which is associated with a protected egress {E, P}, is 494 called an egress-protected service. The egress router E hosts the 495 primary instance of the service, and the protector P hosts the 496 protection instance of the service. 498 An egress-protected service is associated with one and only one 499 protected egress {E, P}. Multiple egress-protected services may be 500 associated with a given protected egress {E, P}. In this case, these 501 services share the common egress router and protector, but may or may 502 not share a common egress-protected tunnel or a common ingress 503 router. 505 An egress-protected service MUST be mapped to an egress-protected 506 tunnel by its ingress router, based on the common protected egress 507 {E, P} of the service and the tunnel. This is achieved by 508 introducing the notion of "context ID" for protected egress {E, P}, 509 as described in (Section 5.7). 511 5.6. Egress-protection bypass tunnel 513 An egress-protected tunnel destined for a protected egress {E, P} 514 MUST have a bypass tunnel from its PLR to the protector P. This 515 bypass tunnel is called an egress-protection bypass tunnel. The 516 bypass tunnel is considered as logically "destined" for the protected 517 egress {E, P}. However, due to its bypass nature, it MUST be resolved 518 and established with P as the physical tailend and E as the node to 519 avoid. The bypass tunnel MUST have the property that it MUST NOT be 520 affected by any topology change caused by an egress node failure. 522 An egress-protection bypass tunnel is associated with one and only 523 one protected egress {E, P}. A PLR may share an egress-protection 524 bypass tunnel for multiple egress-protected tunnels associated with a 525 common protected egress {E, P}. For multiple egress-protected tunnels 526 associated with a common protected egress {E, P}, there may be one or 527 multiple egress-protection bypass tunnels from one or multiple PLRs 528 to the protector P, depending on the paths of the egress-protected 529 tunnels. 531 5.7. Context ID, context label, and context based forwarding 533 In this framework, a globally unique IPv4/v6 address is assigned to a 534 protected egress {E, P} to serve as the identifier of the protected 535 egress {E, P}. It is called a "context ID" due to its specific usage 536 in context label switching and context IP forwarding on the 537 protector. It is an IP address that is logically owned by both the 538 egress router and the protector. For the egress node, it indicates 539 the protector. For the protector, it indicates the egress router, 540 particularly the egress router's forwarding context. For other 541 routers in the network, it is an address reachable via both the 542 egress router and the protector in the routing domain and the TE 543 domain (Section 5.8), similar to an anycast address. 545 The main purpose of a context ID is to coordinate ingress router, 546 egress router, PLR and protector in setting up egress protection. 547 Given an egress-protected service associated with a protected egress 548 {E, P}, its context ID is used as below: 550 o If the service is an MPLS service, when E distributes a service 551 label binding message to the ingress router, E attaches the 552 context ID to the message. If the service is an IP service, when 553 E advertises the service destination address to the ingress 554 router, E also attaches the context ID to the advertisement 555 message. How the context ID is encoded in the messages is a 556 choice of the service protocol, and may need protocol extensions 557 to define a "context ID" object. 559 o The ingress router uses the context ID as destination to establish 560 or resolve an egress-protected tunnel. The ingress router then 561 maps the service to the tunnel for transportation. In this 562 process, the special 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 in 565 establishing or resolving a regular transport tunnel, although the 566 end result is 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, attached with the 583 context ID. Based on the context ID, P installs the service label 584 in an MPLS forwarding table corresponding to E's label space. If 585 the service is an IP service, P installs an IP route in an IP 586 forwarding table corresponding to E's IP address space. In either 587 case, the protection service instance on P interprets the service 588 and constructs forwarding state for the route based on P's own 589 connectivity to the service's destination. 591 o P assigns a non-reserved label to the context ID. In the data 592 plane, this label represents the context ID and indicates E's 593 label space and IP address space. Therefore, it is called a 594 "context label". 596 o The PLR may establish the egress-protection bypass tunnel to P in 597 several manners. If the bypass tunnel is established by RSVP, the 598 PLR signals the bypass tunnel with the context ID as destination, 599 and P binds the context label to the bypass tunnel. If the bypass 600 tunnel is established by LDP, P advertises the context label for 601 the context ID as an IP prefix FEC. If the bypass tunnel is 602 established by the PLR in a hierarchical manner, the PLR treats 603 the context label as a one-hop LSP over a regular bypass tunnel to 604 P (e.g. a bypass tunnel to P's loopback IP address). If the 605 bypass tunnel is constructed by using segment routing, the bypass 606 tunnel is represented by a stack of SID labels with the context 607 label as the inner-most SID label (Section 5.9). In any case, the 608 bypass tunnel is a UHP tunnel whose incoming label at P is the 609 context label. 611 o During local repair, all the service packets received by P on the 612 bypass tunnel have the context label as top label. P first pops 613 the context label. For an MPLS service packet, P further looks up 614 the service label in E's label space indicated by the context 615 label, which is called context label switching. For an IP service 616 packet, P looks up the IP destination address in E's IP address 617 space indicated by the context label, which is called context IP 618 forwarding. 620 5.8. Advertisement and path resolution for context ID 622 Path resolution and computation for a context ID are done on ingress 623 routers for egress-protected tunnels, and on PLRs for egress- 624 protection bypass tunnels. Given a protected egress {E, P} and its 625 context ID, E and P MUST coordinate the context ID in the routing 626 domain and the TE domain via IGP advertisement. The context ID MUST 627 be advertised in such a manner that all egress-protected tunnels MUST 628 have E as tailend, and all egress-protection bypass tunnels MUST have 629 P as tailend while avoiding E. 631 This document suggests three approaches: 633 1. The first approach is called "proxy mode". It requires E and P, 634 but not the PLR, to have the knowledge of the egress protection 635 schema. E and P advertise the context ID as a virtual proxy node 636 (i.e. a logical node) connected to the two routers, with the link 637 between the proxy node and E having more preferable IGP and TE 638 metrics than the link between the proxy node and P. Therefore, 639 all egress-protected tunnels destined for the context ID should 640 automatically follow the shortest IGP or TE paths to E. Each PLR 641 will no longer view itself as a penultimate-hop, but rather two 642 hops away from the proxy node, via E. The PLR will be able to 643 find a bypass path via P to the proxy node, while the bypass 644 tunnel should actually be terminated by P. 646 2. The second approach is called "alias mode". It requires P and 647 the PLR, but not E, to have the knowledge of the egress 648 protection schema. E simply advertises the context ID as a 649 regular IP address. P advertises the context ID and the context 650 label by using a "context ID label binding" advertisement. The 651 advertisement MUST be understood by the PLR. In both routing 652 domain and TE domain, the context ID is only reachable via E. 653 This ensures that all egress-protected tunnels destined for the 654 context ID should have E as tailend. Based on the "context ID 655 label binding" advertisement, the PLR can establish an egress- 656 protection bypass tunnel in several manners (Section 5.9). The 657 "context ID label binding" advertisement is defined as IGP 658 mirroring context segment in [SR-ARCH], [SR-OSPF] and [SR-ISIS]. 659 These IGP extensions are generic in nature, and hence can be used 660 for egress protection purposes. 662 3. The third approach is called "stub link mode". In this mode, 663 both E and P advertise the context ID as a link to stub network, 664 essentially modelling the context ID as an any-cast IP address 665 owned by the two routers. E, P and the PLR do not need to have 666 the knowledge of the egress protection schema. The correctness 667 of the egress-protected tunnels to E and the bypass tunnels from 668 the PLR to P relies on the path computations for the any-cast IP 669 address performed by the ingress routers and PLR. Therefore, 670 care MUST be taken for the applicability of this approach to a 671 given network topology. 673 In a scenario where an egress-protected tunnel is an inter-area or 674 inter-AS tunnel, its associated context ID MUST be propagated from 675 the residing area/AS to the other areas/AS' via IGP or BGP, so that 676 the ingress router of the tunnel can have the reachability to the 677 context ID. The propagation process of the context ID SHOULD be the 678 same as that of a regular IP address in an inter-area/AS environment. 680 5.9. Egress-protection bypass tunnel establishment 682 A PLR MUST know the context ID of a protected egress {E, P} in order 683 to establish an egress-protection bypass tunnel. The information is 684 obtained from the signaling or label distribution protocol of the 685 egress-protected tunnel. The PLR may or may not need to have the 686 knowledge of the egress protection schema. All it does is to set up 687 a bypass tunnel to a context ID while avoiding the next-hop router 688 (i.e. egress router). This is achievable by using a constraint-based 689 computation algorithm similar to those which are commonly used in the 690 computation of traffic engineering paths and loop-free alternate 691 (LFA) paths. Since the context ID is advertised in the routing 692 domain and the TE domain by IGP according to Section 5.8, the PLR 693 should be able to resolve or establish such a bypass path with the 694 protector as tailend. In some cases like the proxy mode, the PLR may 695 do so in the same manner as transit node protection. 697 An egress-protection bypass tunnel may be established via several 698 methods: 700 (1) It may be established by a signaling protocol (e.g. RSVP), with 701 the context ID as destination. The protector binds the context label 702 to the bypass tunnel. 704 (2) It may be formed by a topology driven protocol (e.g. LDP with 705 various LFA mechanisms). The protector advertises the context ID as 706 an IP prefix FEC, with the context label bound to it. 708 (3) It may be constructed as a hierarchical tunnel. When the 709 protector uses the alias mode (Section 5.8), the PLR will have the 710 knowledge of the context ID, context label, and protector (i.e. the 711 advertiser). The PLR can then establish the bypass tunnel in a 712 hierarchical manner, with the context label as a one-hop LSP over a 713 regular bypass tunnel to the protector's IP address (e.g. loopback 714 address). This regular bypass tunnel may be established by RSVP, 715 LDP, segment routing, and others. 717 5.10. Local repair on PLR 719 In this framework, a PLR is agnostic to services and service labels. 720 This obviates the need to maintain bypass forwarding state on a per- 721 service basis, and allows bypass tunnel sharing between egress- 722 protected tunnels. The PLR may share an egress-protection bypass 723 tunnel for multiple egress-protected tunnels associated with a common 724 protected egress {E, P}. During local repair, the PLR reroutes all 725 service packets received on the egress-protected tunnels via the 726 egress-protection bypass tunnel. Service labels remain intact in 727 MPLS service packets. 729 Label operation during the rerouting depends on the bypass tunnel's 730 characteristics. If the bypass tunnel is a single level tunnel, the 731 rerouting will involve swapping the incoming label of an egress- 732 protected tunnel to the outgoing label of the bypass tunnel. If the 733 bypass tunnel is a hierarchical tunnel, the rerouting will involve 734 swapping the incoming label of an egress-protected tunnel to a 735 context label, and pushing the outgoing label of a regular bypass 736 tunnel. If the bypass tunnel is constructed by segment routing, the 737 rerouting will involve swapping the incoming label of an egress- 738 protected tunnel to a context label, and pushing a stack of SID 739 labels of the bypass tunnel. 741 5.11. Service label distribution from egress router to protector 743 As mentioned in previous sections, when a protector receives a 744 rerouted MPLS service packet, it performs context label switching 745 based on the packet's service label which is assigned by the 746 corresponding egress router. In order to achieve this, the protector 747 MUST maintain such kind of service labels in dedicated label spaces 748 on a per protected egress {E, P} basis, i.e. one label space for each 749 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 corresponding ingress router, 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, RFC 8104 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 the scenario where a protector and 788 a backup 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 is not usable for 846 egress protection, because it will create a loop, which MUST be 847 avoided. In this case, the backup egress router MUST advertise a 848 unique service label for egress protection, and set its forwarding 849 state to use the backup egress router's connectivity with the service 850 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 PLR, by performing 859 local failure detection and local repair. Specifically, the egress 860 router pre-establishes an egress-protection bypass tunnel to a 861 protector, and installs bypass forwarding state for the service 862 label, pointing to the bypass tunnel. During local repair, the 863 egress 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 advertised 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 advertised 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 and 938 egress link protection in a consistent manner, and both the co- 939 located protector mode and the centralized protector mode may be 940 used (Figure-3 and Figure-4). 942 (2) The second approach applies when the egress router knows the 943 service label advertised by the backup egress route, 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 may 948 be a different router in the centralized protector mode. The 949 egress router sets up the bypass forwarding state as a label swap 950 from the incoming service label to the service label of the 951 protector, followed by a push with the outgoing label (or label 952 stack) of the egress link protection bypass tunnel. The bypass 953 tunnel is a regular tunnel destined for an IP address of the 954 protector, instead of the context ID of the {E, P}. The protector 955 simply forwards rerouted service packets based on its own service 956 label, rather than performing context label switching. With this 957 approach, only the co-located protector mode is applicable. 959 Note that for a bidirectional service, the physical link of an egress 960 link may carry service traffic bi-directionally. Therefore, an 961 egress link failure may simultaneously be an ingress link failure for 962 the traffic in the opposite direction. However, protection for 963 ingress link failure SHOULD be provided by a separate mechanism, and 964 hence is out of the scope of this document. 966 7. Global repair 968 This framework provides a fast but temporary repair for egress node 969 and egress link failures. For permanent repair, it is RECOMMENDED 970 that the traffic SHOULD be moved to an alternative tunnel or 971 alternative services which are fully functional. This is referred to 972 as global repair. Possible triggers of global repair include control 973 plane notifications of tunnel and service status, end-to-end OAM and 974 fault detection at tunnel or service levels, and others. The 975 alternative tunnel and services may be pre-established as standby, or 976 dynamically established as a result of the triggers or network 977 protocol convergence. 979 8. Example: Layer-3 VPN egress protection 981 This section shows an example of egress protection for a layer-3 VPN. 983 ---------- R1 ----------- PE2 - 984 / (PLR) (PLR) \ 985 ( ) / | | ( ) 986 ( ) / | | ( ) 987 ( site 1 )-- PE1 < | R3 ( site 2 ) 988 ( ) \ | | ( ) 989 ( ) \ | | ( ) 990 \ | | / 991 ---------- R2 ----------- PE3 - 992 (protector) 994 Figure 5 996 In this example, the site 1 (subnet 203.0.113.192/26) of a given VPN 997 is attached to PE1, and site 2 (subnet 203.0.113.128/26) is dual- 998 homed to PE2 and PE3. PE2 is the primary PE for site 2, and PE3 is 999 the backup PE. Each PE hosts a VPN instance. R1 and R2 are transit 1000 routers in the MPLS network. The network uses OSPF as routing 1001 protocol, and RSVP-TE as tunnel signaling protocol. The PEs use BGP 1002 to exchange VPN prefixes and VPN labels between each other. 1004 Using the framework in this document, the network assigns PE3 to be a 1005 protector for PE2 to protect the VPN traffic in the direction from 1006 site 1 to site 2. This is the co-located protector mode. Hence, PE2 1007 and PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 1008 is assigned to the protected egress {PE2, PE3}. The VPN instance on 1009 PE3 serves as a protection instance for the VPN instance on PE2. On 1010 PE3, a context label 100 is assigned to the context ID, and a label 1011 table pe2.mpls is created to represent PE2's label space. PE3 1012 installs the label 100 in its default MPLS forwarding table, with 1013 nexthop pointing to the label table pe2.mpls. PE2 and PE3 are 1014 coordinated to use the proxy mode to advertise the context ID in the 1015 routing domain and the TE domain. 1017 PE2 uses per-VRF VPN label allocation mode. It assigns a single 1018 label 9000 to the VRF of the VPN. For a given VPN prefix 1019 203.0.113.128/26 in site 2, PE2 advertises it along with the label 1020 9000 and other attributes to PE1 and PE3 via BGP. In particular, the 1021 NEXT_HOP attribute is set to the context ID 198.51.100.1. 1023 Similarly, PE3 also uses per-VRF VPN label allocation mode. It 1024 assigns a single label 10000 to the VRF of the VPN. For the VPN 1025 prefix 203.0.113.128/26 in site 2, PE3 advertises it along with the 1026 label 10000 and other attributes to PE1 and PE2 via BGP. In 1027 particular, the NEXT_HOP attribute is set to an IP address of PE3. 1029 Upon receipt and acceptance of the BGP advertisement, PE1 uses the 1030 context ID 198.51.100.1 as destination to compute a TE path for an 1031 egress-protected tunnel. The resulted path is PE1->R1->PE2. PE1 1032 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1 1033 as destination, and with the "node protection desired" flag set in 1034 the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes 1035 up, PE1 maps the VPN prefix 203.0.113.128/26 to the tunnel and 1036 installs a route for the prefix in the corresponding VRF. The 1037 route's nexthop is a push with the VPN label 9000, followed by a push 1038 with the outgoing label of the egress-protected tunnel. 1040 Upon receipt of the above BGP advertisement from PE2, PE3 (i.e. the 1041 protector) recognizes the context ID 198.51.100.1 in the NEXT_HOP 1042 attribute, and installs a route for label 9000 in the label table 1043 pe2.mpls. PE3 sets the route's nexthop to a "protection VRF". This 1044 protection VRF contains IP routes corresponding to the IP prefixes in 1045 the dual-homed site 2, including 203.0.113.128/26. The nexthops of 1046 these routes MUST be based on PE3's connectivity with site 2, even if 1047 this connectivity is not the best path in PE3's VRF due to metrics 1048 (e.g. MED, local preference, etc.), and MUST NOT use any path 1049 traversing PE2. Note that the protection VRF is a logical concept, 1050 and it may simply be PE3's own VRF if the VRF satisfies the 1051 requirement. 1053 8.1. Egress node protection 1055 R1, i.e. the penultimate-hop router of the egress-protected tunnel, 1056 serves as the PLR for egress node protection. Based on the "node 1057 protection desired" flag and the destination address (i.e. context ID 1058 198.51.100.1) of the tunnel, R1 computes a bypass path to 1059 198.51.100.1 while avoiding PE2. The resulted bypass path is 1060 R1->R2->PE3. R1 then signals the path (i.e. egress-protection bypass 1061 tunnel), with 198.51.100.1 as destination. 1063 Upon receipt of an RSVP Path message of the egress-protection bypass 1064 tunnel, PE3 recognizes the context ID 198.51.100.1 as the 1065 destination, and hence responds with the context label 100 in an RSVP 1066 Resv message. 1068 After the egress-protection bypass tunnel comes up, R1 installs a 1069 bypass nexthop for the egress-protected tunnel. The bypass nexthop 1070 is a swap from the incoming label of the egress-protected tunnel to 1071 the outgoing label of the egress-protection bypass tunnel. 1073 When R1 detects a failure of PE2, it will invoke the above bypass 1074 nexthop to reroute VPN service packets. The packets will have the 1075 label of the bypass tunnel as outer label, and the VPN label 9000 as 1076 inner label. When the packets arrive at PE3, they will have the 1077 context label 100 as outer label, and the VPN label 9000 as inner 1078 label. The context label will first be popped, and then the VPN 1079 label will be looked up in the label table pe2.mpls. The lookup will 1080 cause the VPN label to be popped, and the IP packets will finally be 1081 forwarded to site 2 based on the protection VRF. 1083 8.2. Egress link protection 1085 PE2 serves as the PLR for egress link protection. It has already 1086 learned the VPN label 10000 from PE3, and hence it uses the approach 1087 (2) described in Section 6 to set up bypass forwarding state. It 1088 signals an egress-protection bypass tunnel to PE3, by using the path 1089 PE2->R3->PE3, and PE3's IP address as destination. After the bypass 1090 tunnel comes up, PE2 installs a bypass nexthop for the VPN label 1091 9000. The bypass nexthop is a label swap from the incoming label 1092 9000 to the VPN label 10000 of PE3, followed by a label push with the 1093 outgoing label of the bypass tunnel. 1095 When PE3 detects a failure of the egress link, it will invoke the 1096 above bypass nexthop to reroute VPN service packets. The packets 1097 will have the label of the bypass tunnel as outer label, and the VPN 1098 label 10000 as inner label. When the packets arrive at PE3, the VPN 1099 label 10000 will be popped, and the IP packets will be forwarded 1100 based on the VRF indicated by on the VPN label 10000. 1102 8.3. Global repair 1104 Eventually, global repair will take effect, as control plane 1105 protocols converge on the new topology. PE1 will choose PE3 as new 1106 entrance to site 2. Before that happens, the VPN traffic has been 1107 protected by the above local repair. 1109 9. IANA Considerations 1111 This document has no request for new IANA allocation. 1113 10. Security Considerations 1115 The framework in this document relies on fast reroute around a 1116 network failure. Specifically, service traffic is temporarily 1117 rerouted from a PLR to a protector. In the centralized protector 1118 mode, the traffic is further rerouted from the protector to a backup 1119 egress router. Such kind of fast reroute is planned and anticipated, 1120 and hence it should not be viewed as a new security threat. 1122 The framework requires a service label distribution protocol to run 1123 between an egress router and a protector. The available security 1124 measures of the protocol MAY be used to achieve a secured session 1125 between the two routers. 1127 11. Acknowledgements 1129 This document leverages work done by Yakov Rekhter, Kevin Wang and 1130 Zhaohui Zhang on MPLS egress protection. Thanks to Alexander 1131 Vainshtein, Rolf Winter, and Lizhong Jin for their valuable comments 1132 that helped shape this document and improve its clarity. 1134 12. References 1136 12.1. Normative References 1138 [SR-ARCH] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1139 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1140 spring-segment-routing (work in progress), 2017. 1142 [SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1143 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1144 Extensions for Segment Routing", draft-ietf-ospf-segment- 1145 routing-extensions (work in progress), 2017. 1147 [SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1148 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1149 Extensions for Segment Routing", draft-ietf-isis-segment- 1150 routing-extensions (work in progress), 2017. 1152 12.2. Informative References 1154 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1155 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1156 DOI 10.17487/RFC4090, May 2005, 1157 . 1159 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1160 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1161 DOI 10.17487/RFC5286, September 2008, 1162 . 1164 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1165 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 1166 RFC 7490, DOI 10.17487/RFC7490, April 2015, 1167 . 1169 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 1170 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 1171 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 1172 . 1174 [RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, 1175 "Pseudowire (PW) Endpoint Fast Failure Protection", 1176 RFC 8104, DOI 10.17487/RFC8104, March 2017, 1177 . 1179 [BGP-PIC] Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix 1180 Independent Convergence", draft-ietf-rtgwg-bgp-pic-05.txt 1181 (work in progress), 2017. 1183 [RSVP-EP] Chen, H., Liu, A., Saad, T., Xu, F., Huang, L., and N. So, 1184 "Extensions to RSVP-TE for LSP Egress Local Protection", 1185 draft-ietf-teas-rsvp-egress-protection (work in progress), 1186 2017. 1188 Authors' Addresses 1190 Yimin Shen 1191 Juniper Networks 1192 10 Technology Park Drive 1193 Westford, MA 01886 1194 USA 1196 Phone: +1 9785890722 1197 Email: yshen@juniper.net 1199 Minto Jeyananth 1200 Juniper Networks 1201 1133 Innovation Way 1202 Sunnyvale, CA 94089 1203 USA 1205 Phone: +1 4089367563 1206 Email: minto@juniper.net 1208 Bruno Decraene 1209 Orange 1211 Email: bruno.decraene@orange.com 1212 Hannes Gredler 1213 RtBrick Inc 1215 Email: hannes@rtbrick.com 1217 Carsten Michel 1218 Deutsche Telekom 1220 Email: c.michel@telekom.de 1222 Huaimo Chen 1223 Huawei Technologies Co., Ltd. 1225 Email: huaimo.chen@huawei.com 1227 Yuanlong Jiang 1228 Huawei Technologies Co., Ltd. 1229 Bantian, Longgang district 1230 Shenzhen 518129 1231 China 1233 Email: jiangyuanlong@huawei.com