idnits 2.17.1 draft-shen-mpls-egress-protection-framework-06.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 (September 20, 2017) is 2407 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) == Missing Reference: 'RSVP-EP' is mentioned on line 194, but not defined == 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: March 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 September 20, 2017 16 MPLS Egress Protection Framework 17 draft-shen-mpls-egress-protection-framework-06 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 March 24, 2018. 57 Copyright Notice 59 Copyright (c) 2017 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 . . . . . . . . . . . . 9 81 5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 10 82 5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 11 83 5.5. Egress-protected tunnel . . . . . . . . . . . . . . . . . 11 84 5.6. Egress-protected service . . . . . . . . . . . . . . . . 12 85 5.7. Egress-protected service to egress-protected tunnel 86 mapping . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 5.8. Egress-protection bypass tunnel . . . . . . . . . . . . . 12 88 5.9. Context ID, context label, and context based forwarding . 12 89 5.10. Advertisement and path resolution for context ID . . . . 14 90 5.11. Egress-protection bypass tunnel establishment . . . . . . 15 91 5.12. Local Repair on PLR . . . . . . . . . . . . . . . . . . . 16 92 5.13. Service label distribution from egress router to 93 protector . . . . . . . . . . . . . . . . . . . . . . . . 17 94 5.14. Centralized protector mode . . . . . . . . . . . . . . . 17 95 6. Egress link protection . . . . . . . . . . . . . . . . . . . 19 96 7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 22 97 8. Example: Layer-3 VPN egress protection . . . . . . . . . . . 22 98 8.1. Egress node protection . . . . . . . . . . . . . . . . . 24 99 8.2. Egress link protection . . . . . . . . . . . . . . . . . 25 100 8.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 25 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 103 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 106 12.2. Informative References . . . . . . . . . . . . . . . . . 26 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 109 1. Introduction 111 In MPLS networks, LSPs (label switched paths) are widely used as 112 transport tunnels to carry IP and MPLS services across MPLS domains. 113 Examples of MPLS services are layer-2 VPNs, layer-3 VPNs, 114 hierarchical LSPs, and others. In general, a tunnel may carry 115 multiple services of one or multiple types, given that the tunnel can 116 satisfy both individual and aggregate requirements (e.g. CoS, QoS) 117 of these services. The egress router of the tunnel should host the 118 corresponding service instances of the services. An MPLS service 119 instance is responsible for forwarding service packets via an egress 120 link to the service destination, based on a service label. An IP 121 service instance is responsible for forwarding service packets via an 122 egress link to the service destination, based on the IP destination 123 address. The egress link is often called a PE-CE (provider edge - 124 customer edge) link or attachment circuit (AC). 126 Today, local repair based fast reroute mechanisms [RFC4090], 127 [RFC5286], [RFC7490], [RFC7812] have been widely deployed to protect 128 MPLS tunnels against transit link/node failures. They can achieve 129 fast restoration of traffic in the order of tens of milliseconds. 130 Local repair refers to the scenario where the router upstream to an 131 anticipated failure (aka. PLR, i.e. point of local repair) pre- 132 establishes a bypass tunnel to the router downstream of the failure 133 (aka. MP, i.e. merge point), and pre-installs the forwarding state 134 of the bypass tunnel in the data plane. The PLR also uses a rapid 135 mechanism (e.g. link layer OAM, BFD, and others) to locally detect 136 the failure in the data plane. When the failure occurs, the PLR 137 reroutes traffic through the bypass tunnel to the MP, allowing the 138 traffic to continue to flow to the tunnel's egress router. 140 This document describes a fast reroute framework for egress node and 141 egress link protection. Similar to transit link/node protection, 142 this framework relies on a PLR to perform local failure detection and 143 local repair. In egress node protection, the PLR is the penultimate- 144 hop router of a tunnel. In egress link protection, the PLR is the 145 egress router of the tunnel. The framework relies on a so-called 146 "protector" to serve as the tailend of bypass tunnels. The protector 147 is a router that hosts some "protection service instances" and has 148 its own connectivity or paths to service destinations. When a PLR 149 does local repair, the protector is responsible for performing 150 "context label switching" for rerouted MPLS service packets and 151 "context IP forwarding" for rerouted IP service packets. Thus, the 152 service packets can continue to reach service destinations with 153 minimum disruption. 155 This framework considers an egress node failure as a failure of a 156 tunnel, as well as a failure of all the services carried by the 157 tunnel, because service packets can no longer reach the service 158 instances on the egress router. Therefore, the framework addresses 159 egress node protection at both tunnel level and service level 160 simultaneously. Likewise, the framework considers an egress link 161 failure as a failure of all the services traversing the link, and 162 addresses egress link protection at the service level. 164 This framework requires that the destination (a CE or site) of a 165 service MUST be dual-homed or have dual paths to an MPLS network, 166 normally via two MPLS edge routers. One of them is the egress router 167 of the service's transport tunnel, and the other is a backup egress 168 router. In the "co-located" protector mode in this document, the 169 backup egress router serves as a protector, and each service instance 170 hosted on the router acts as a protection instance. In the 171 "centralized" protector mode (Section 5.14), a protector and a backup 172 egress router may be decoupled, and each service instance on the 173 backup egress router is simply considered as a "backup service 174 instance". 176 The framework is described by mainly referring to P2P (point-to- 177 point) tunnels. However, it is equally applicable to P2MP (point-to- 178 multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to- 179 multipoint) tunnels, when a sub-LSP can be viewed as a P2P tunnel. 181 The framework is a multi-service and multi-transport framework. It 182 assumes a generic model where each service is comprised of a common 183 set of components, including service instance, service label, and 184 service label distribution protocol, and transported over an MPLS 185 tunnel. Therefore, the framework is applicable to all existing and 186 future types of MPLS tunnels and IP/MPLS services. 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, because transport tunnels and bypass tunnels are expected to 191 be established by using the generic mechanisms provided by the 192 protocols. However, the framework does not preclude future 193 extensions to the protocols which may facilitate the procedures. One 194 example of such extension is [RSVP-EP]. The framework may need 195 extensions for IGPs and service label distribution protocols, to 196 support protection establishment and context label switching. This 197 document provides guidelines for these extensions, but the specific 198 details SHOULD be 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. The service instances on 248 this router are called backup service instances, and the 249 corresponding services are called backup services. 251 Backup service instance - A service instance which is hosted by a 252 backup egress router, and corresponding to an egress-protected 253 service on a protected egress router. 255 Protector - A role acted by a router as an alternate of a protected 256 egress router, to handle service packets in the event of an egress 257 failure. It protects an egress-protected tunnel, and hosts 258 protection service instances for the egress-protected services 259 carried by the tunnel. A protector may or may not be physically co- 260 located with or decoupled from a backup egress router, depending on 261 the co-located or centralized protector mode. 263 Protection service instance - A service instance hosted by a 264 protector, protecting the service instance of an egress-protected 265 service on a protected egress router. A protection service instance 266 is a backup service instance, if the protector is co-located with a 267 backup egress router. 269 PLR - A router at the point of local repair. In egress node 270 protection, it is the penultimate-hop router on an egress-protected 271 tunnel. In egress link protection, it is the egress router of the 272 egress-protected tunnel. 274 Protected egress {E, P} - A virtual node consisting of an ordered 275 pair of egress router E and protector P. It serves as the virtual 276 destination for an egress-protected tunnel. It also serves as the 277 virtual location of service instances for the egress-protected 278 services carried by the tunnel. 280 Context identifier (ID) - A globally unique IP address assigned to a 281 protected egress {E, P}. 283 Context label - A non-reserved label assigned to a context ID by a 284 protector. 286 Egress-protection bypass tunnel - A tunnel used for rerouting service 287 packets around an egress failure. In egress node protection, it is 288 established from a penultimate-hop router (i.e. PLR) to a protector, 289 bypassing a protected egress router. In egress link protection, it 290 is established from a protected egress router (i.e. PLR) to a 291 protector, bypassing an egress link. 293 Co-located protector mode - The scenario where a protector and a 294 backup egress router are co-located as one router, and hence each 295 backup service instance serves as a protection service instance. 297 Centralized protector mode - The scenario where a protector is a 298 dedicated router, and is decoupled from backup egress routers. 300 Context label switching - Label switching performed by a protector, 301 in the label space of an egress router indicated by a context label. 303 Context IP forwarding - IP forwarding performed by a protector, in 304 the IP address space of an egress router indicated by a context 305 label. 307 4. Requirements 309 This document considers the followings as the design requirements of 310 this egress protection framework. 312 o The framework must support P2P tunnels. It should equally support 313 P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P 314 tunnel. 316 o The framework must support multi-service and multi-transport 317 networks. It must accommodate existing and future signaling and 318 label-distribution protocols of tunnels and bypass tunnels, 319 including RSPV, LDP, BGP, IGP, segment routing, and others. It 320 must also accommodate existing and future IP/MPLS services, 321 including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and 322 others. It must provide a generic solution for environments where 323 different types of services and tunnels may co-exist. 325 o The framework must consider minimizing disruption for deployment. 326 It should only involve routers close to egress, and be transparent 327 to ingress routers and other transit routers. 329 o In egress node protection, for scalability and performance 330 reasons, a PLR must be agnostic to services and service labels, 331 like PLRs in transit link/node protection. It must maintain 332 bypass tunnels and bypass forwarding state on a per-transport- 333 tunnel basis, rather than per-service-destination or per-service- 334 label basis. It should also support bypass tunnel sharing between 335 transport tunnels. 337 o A PLR must be able to use its local visibility or information of 338 routing and/or TE topology to compute or resolve a path for a 339 bypass tunnel to a protector. 341 o A protector must be able to perform context label switching for 342 rerouted MPLS service packets, based on service label(s) assigned 343 by an egress router. It must be able to perform context IP 344 forwarding for rerouted IP service packets, in the public or 345 private IP address space used by an egress router. 347 o The framework must be able to work seamlessly with transit link/ 348 node protection mechanisms to achieve end-to-end coverage. 350 o The framework must be able to work in conjunction with global 351 repair and control plane convergence. 353 5. Egress node protection 355 5.1. Reference topology 357 This document refers to the following topology when describing the 358 procedures for egress node protection. 360 services 1, ..., N 361 =====================================> tunnel 363 I ------ R1 ------- PLR --------------- E ---- 364 ingress penultimate-hop egress \ 365 | . (primary \ 366 | . service \ 367 | . instances) \ 368 | . \ 369 | . \ service 370 | . destinations 371 | . / (CEs, sites) 372 | . / 373 | . bypass / 374 | . tunnel / 375 | . / 376 | ............... / 377 R2 --------------- P ---- 378 protector 379 (protection 380 service 381 instances) 383 Figure 1 385 5.2. Egress node failure and detection 387 An egress node failure refers to the failure of an MPLS tunnel's 388 egress router. At the service level, it also means a service 389 instance failure for each IP/MPLS service carried by the tunnel. 391 Ideally, an egress node failure can be detected by an adjacent router 392 (i.e. PLR in this framework) using a node liveness detection 393 mechanism, or based on a collective failure of all the links to that 394 node. However, the assumption is that the mechanisms SHOULD be 395 reasonably fast, i.e. faster than control plane failure detection and 396 remote failure detection. Otherwise, local repair will not be able 397 to provide much gain in restoring traffic compared to control plane 398 convergence or global repair. In general, the speed, accuracy, and 399 reliability of a mechanism are the key factors to decide its 400 applicability in egress node protection. This document provides the 401 following guidelines in this regard. 403 o If the PLR has a reasonably fast mechanism to detect and 404 differentiate a link failure and an egress node failure, it SHOULD 405 set up both link protection and egress node protection, and 406 trigger one and only one protection upon a corresponding failure. 408 o If the PLR has a fast mechanism to detect a link failure and an 409 egress node failure, but cannot distinguish them; Or, if the PLR 410 has a fast mechanism to detect a link failure only, but not an 411 egress node failure, the PLR has two options: 413 1. It MAY set up link protection only, and leave the egress node 414 failure to global repair and control plane convergence to 415 handle. 417 2. It MAY set up egress node protection only, and treat a link 418 failure as a trigger for the egress node protection. However, 419 the assumption is that treating a link failure as an egress 420 node failure MUST NOT have a negative impact on services. 421 Otherwise, it SHOULD adopt the previous option. 423 5.3. Protector and PLR 425 A router is assigned to the "protector" role to protect a tunnel and 426 the services carried by the tunnel against an egress node failure. 427 The protector is responsible for hosting a protection service 428 instance for each protected service, serving as the tailend of a 429 bypass tunnel, and performing context label switching and/or context 430 IP forwarding for rerouted service packets. 432 A tunnel can be protected by only one protector at a given time. 433 Multiple tunnels to a given egress router may be protected by a 434 common protector or different protectors. A protector may protect 435 multiple tunnels with a common egress router or different egress 436 routers. 438 For each tunnel, its penultimate-hop router acts as a PLR. The PLR 439 pre-establishes a bypass tunnel to the protector, and pre-installs 440 bypass forwarding state in the data plane. Upon detection of an 441 egress node failure, the PLR reroutes all the service packets 442 received on the tunnel though the bypass tunnel to the protector. 443 For MPLS service packets, the PLR keeps service labels intact in the 444 packets. The protector in turn forwards the rerouted service packets 445 towards the ultimate service destinations. Specifically, it performs 446 context label switching for MPLS service packets, based on service 447 labels assigned by the protected egress router; It performs context 448 IP forwarding for IP service packets, based on their destination 449 addresses. 451 The protector MUST have its own connectivity with each service 452 destination, via a direct link or a multi-hop path, which MUST NOT 453 traverse the protected egress router or be affected by the egress 454 node failure. This also requires that each service destination MUST 455 be dual-homed or have dual paths to the egress router and a backup 456 egress router which serves as the protector. Each protection service 457 instance on the protector relies on such connectivity to set up 458 forwarding state for context label switching and/or context IP 459 forwarding. 461 5.4. Protected egress 463 This document introduces the notion of "protected egress" as a 464 virtual node consisting of the egress router E of a tunnel and a 465 protector P. It is denoted by an ordered pair of {E, P}, indicating 466 the primary-and-protector relationship between the two routers. It 467 serves as the virtual destination of the tunnel, and the virtual 468 location of service instances for the services carried by the tunnel. 469 The tunnel and services are considered as being "associated" with the 470 protected egress {E, P}. 472 A given egress router E may be the tailend of multiple tunnels. In 473 general, the tunnels may be protected by multiple protectors, e.g. 474 P1, P2, and so on, with each Pi protecting a subset of the tunnels. 475 Thus, these routers form multiple protected egresses, i.e. {E, P1} , 476 {E, P2}, and so on. Each tunnel is associated with one and only one 477 protected egress {E, Pi}. All the services carried by the tunnel are 478 then automatically associated with the same protected egress {E, Pi}. 479 Conversely, a service associated with a protected egress {E, Pi} MUST 480 be carried by a tunnel associated with the same protected egress {E, 481 Pi}. This mapping MUST be ensured by the ingress router of the tunnel 482 and the service (Section 5.7). 484 Two routers X and Y may be protectors for each other. In this case, 485 they form two distinct protected egresses {X, Y} and {Y, X}. 487 5.5. Egress-protected tunnel 489 A tunnel, which is associated with a protected egress {E, P}, is 490 called an egress-protected tunnel. It is associated with one and 491 only one protected egress {E, P}. Multiple egress-protected tunnels 492 may be associated with a given protected egress {E, P}. In this case, 493 they share the common egress router and protector, but may or may not 494 share a common ingress router, a common path, or a common PLR. 496 An egress-protected tunnel is considered as logically "destined" for 497 its protected egress {E, P}. However, its path MUST be resolved and 498 established with E as the physical tailend. 500 5.6. Egress-protected service 502 A service, which is associated with a protected egress {E, P}, is 503 called an egress-protected service. The egress router E hosts the 504 primary instance of the service, and the protector P hosts the 505 protection instance. 507 An egress-protected service is associated with one and only one 508 protected egress {E, P}. Multiple egress-protected services may be 509 associated with a given protected egress {E, P}. In this case, these 510 services share the common egress router and protector, but may or may 511 not share a common egress-protected tunnel or a common ingress 512 router. 514 5.7. Egress-protected service to egress-protected tunnel mapping 516 An egress-protected service MUST be mapped to an egress-protected 517 tunnel by its ingress router, based on the common protected egress 518 {E, P} of the service and the tunnel. This is achieved by 519 introducing the notion of "context ID" for protected egress {E, P}, 520 as described in (Section 5.9). 522 5.8. Egress-protection bypass tunnel 524 An egress-protected tunnel destined for a protected egress {E, P} 525 MUST have a bypass tunnel from its PLR to the protector P. This 526 bypass tunnel is called an egress-protection bypass tunnel. The 527 bypass tunnel is considered as logically "destined" for the protected 528 egress {E, P}. However, due to its bypass tunnel nature, it MUST be 529 resolved and established with P as the physical tailend and E as the 530 node to avoid. The bypass tunnel MUST have the property that it MUST 531 NOT be affected by any topology change caused by an egress node 532 failure. 534 An egress-protection bypass tunnel is associated with one and only 535 one protected egress {E, P}. A PLR may share an egress-protection 536 bypass tunnel between multiple egress-protected tunnels associated 537 with a common protected egress {E, P}. For multiple egress-protected 538 tunnels associated with a common protected egress {E, P}, there may 539 be one or multiple egress-protection bypass tunnels from one or 540 multiple PLRs to the protector P, depending on the paths of the 541 egress-protected tunnels. 543 5.9. Context ID, context label, and context based forwarding 545 In this framework, a globally unique IPv4/v6 address is assigned to a 546 protected egress {E, P} to serve as the identifier of the protected 547 egress {E, P}. It is called a "context ID" due to its specific usage 548 in context label switching and context IP forwarding on the 549 protector. It is an IP address that is logically owned by both the 550 egress router and the protector. For the egress node, it indicates 551 the protector. For the protector, it indicates the egress router, 552 particularly the egress router's forwarding context. For other 553 routers in the network, it is an address reachable via both the 554 egress router and the protector in the routing domain and the TE 555 domain (Section 5.10). 557 The main purpose of a context ID is to coordinate ingress router, 558 egress router, PLR and protector in setting up egress protection. 559 Given an egress-protected service associated with a protected egress 560 {E, P}, its context ID is used as below: 562 o If the service is an MPLS service, when E distributes a service 563 label binding message to the ingress router, E attaches the 564 context ID to the message. If the service is an IP service, when 565 E advertises the service destination address to the ingress 566 router, E also attaches the context ID to the advertisement 567 message. How the context ID is encoded in the messages is a 568 choice of the service protocol, and may need protocol extensions 569 to define a dedicated "context ID" object. 571 o The ingress router uses the context ID as destination to establish 572 or resolve an egress-protected tunnel. The ingress router then 573 maps the service to the tunnel for transportation. In this 574 process, the special semantics of the context ID is transparent to 575 the ingress router. The ingress router only views the context ID 576 as an IP address of E, and behaves in the same manner as in 577 establishing or resolving a regular transport tunnel, although the 578 end result is an egress-protected tunnel. 580 o The context ID is conveyed to the PLR by the signaling protocol of 581 the egress-protected tunnel, or learned by the PLR via an IGP or 582 topology-driven label distribution protocol. The PLR uses the 583 context ID as destination to establish or resolve an egress- 584 protection bypass tunnel to P while avoiding E. 586 o P maintains a dedicated label space or a dedicated IP address 587 space for E, depending on whether the service is MPLS or IP. This 588 is referred to as "E's label space" or "E's IP address space", 589 respectively. P uses the context ID to identify the space. 591 o If the service is an MPLS service, E also distributes the service 592 label binding message to P. This is the same label binding 593 message that E advertises to the ingress router, attached with the 594 context ID. Based on the context ID, P installs the service label 595 in an MPLS forwarding table corresponding to E's label space. If 596 the service is an IP service, P installs an IP route in an IP 597 forwarding table corresponding to E's IP address space. In either 598 case, the protection service instance on P interprets the service 599 and constructs forwarding state for the route based on P's own 600 connectivity to the service's destination. 602 o P assigns a non-reserved label to the context ID. In the data 603 plane, this label represents the context ID and indicates E's 604 label space and IP address space. Therefore, it is called a 605 "context label". 607 o The PLR may establish the egress-protection bypass tunnel to P in 608 several manners. If the bypass tunnel is established by RSVP, the 609 PLR signals the bypass tunnel with the context ID as destination, 610 and P binds the context label to the bypass tunnel. If the bypass 611 tunnel is established by LDP, P advertises the context label for 612 the context ID as an IP prefix FEC. If the bypass tunnel is 613 established by the PLR in a hierarchical manner, the PLR treats 614 the context label as a one-hop LSP over a regular bypass tunnel to 615 P (e.g. a bypass tunnel to P's loopback IP address). If the 616 bypass tunnel is constructed by using segment routing, the bypass 617 tunnel is represented by a stack of SID labels with the context 618 label as the inner-most SID label (Section 5.11). In any case, 619 the bypass tunnel is a UHP tunnel whose incoming label at P is the 620 context label. 622 o During local repair, all the service packets received by P on the 623 bypass tunnel will have the context label as top label. P will 624 first pop the context label. For an MPLS service packet, P will 625 further look up the service label in E's label space indicated by 626 the context label, which is called context label switching. For 627 an IP service packet, P will look up the IP destination address in 628 E's IP address space indicated by the context label, which is 629 called context IP forwarding. 631 5.10. Advertisement and path resolution for context ID 633 Path resolution or computation for a context ID is done on ingress 634 routers for egress-protected tunnels, and on PLRs for egress- 635 protection bypass tunnels. Therefore, given a protected egress {E, 636 P} and its context ID, E and P MUST coordinate the context ID in the 637 routing domain and the TE domain via IGP advertisement. The context 638 ID MUST be advertised in such a manner that any egress-protected 639 tunnels MUST have E as tailend, and any egress-protection bypass 640 tunnels MUST have P as tailend while avoiding E. 642 This document suggests two approaches: 644 1. The first approach is called "proxy mode". It requires E and P, 645 but not the PLR, to have the knowledge of the egress protection 646 schema. E and P advertise the context ID as a virtual proxy node 647 (i.e. a logical node) connected to the two routers, with the link 648 between the proxy node and E having more preferable IGP and TE 649 metrics than the link between the proxy node and P. Therefore, 650 all egress-protected tunnels destined for the context ID should 651 automatically follow the shortest IGP or TE paths to E. Each PLR 652 will no longer view itself as a penultimate-hop, but rather two 653 hops away from the proxy node, via E. The PLR will be able to 654 find a bypass path via P to the proxy node, while the bypass 655 tunnel should actually be terminated by P. 657 2. The second approach is called "alias mode". It requires P and 658 the PLR, but not E, to have the knowledge of the egress 659 protection schema. E simply advertises the context ID as a 660 regular IP address. P advertises the context ID and the context 661 label by using a "context ID label binding" advertisement. The 662 advertisement MUST be understood by the PLR. In both routing 663 domain and TE domain, the context ID is only reachable via E. 664 This ensures that all egress-protected tunnels destined for the 665 context ID should have E as tailend. Based on the "context ID 666 label binding" advertisement, the PLR can establish an egress- 667 protection bypass tunnel in several manners (Section 5.11). The 668 "context ID label binding" advertisement is defined as IGP 669 mirroring context segment in [SR-ARCH], [SR-OSPF] and [SR-ISIS]. 670 These IGP extensions are generic in nature, and have broad 671 applicability beyond segment routing. 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 obtain 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.11. 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 to 690 compute traffic engineering paths and loop-free alternate (LFA) 691 paths. Since the context ID is advertised in the routing domain and 692 the TE domain by IGP according to Section 5.10, the PLR should be 693 able to resolve or establish such a bypass path with the protector as 694 tailend. In some cases like the proxy mode, the PLR may do so in the 695 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, and binds the context label to it. 708 (3) It may be constructed as a hierarchical tunnel. When the 709 protector uses the alias mode (Section 5.10), 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.12. 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. During local repair, the PLR simply reroutes all 723 service packets received on a tunnel to the corresponding bypass 724 tunnel. Service labels remain intact in MPLS service packets. 726 Label operation during the rerouting depends on the bypass tunnel's 727 characteristics. If the bypass tunnel is a single level tunnel, the 728 rerouting will involve swapping the incoming label of the egress- 729 protected tunnel to the outgoing label of the bypass tunnel. If the 730 bypass tunnel is a hierarchical tunnel, the rerouting will involve 731 swapping the incoming label of the egress-protected tunnel to a 732 context label, and pushing the outgoing label of a regular bypass 733 tunnel. If the bypass tunnel is constructed by segment routing, the 734 rerouting will involve swapping the incoming label of the egress- 735 protected tunnel to a stack of SID labels, with a context label as 736 the inner-most SID label. 738 5.13. Service label distribution from egress router to protector 740 As mentioned in previous sections, when a protector receives a 741 rerouted MPLS service packet, it performs context label switching 742 based on the packet's service label which is assigned by the 743 corresponding egress router. In order to achieve this, the protector 744 MUST maintain such kind of service labels in dedicated label spaces 745 on a per protected egress {E, P} basis, i.e. one label space for each 746 egress router that it protects. 748 Also, there MUST be a service label distribution protocol session 749 between each egress router and the protector. Through this protocol, 750 the protector learns the label binding of each egress-protected 751 service. This is the same label binding that the egress router 752 advertises to the corresponding ingress router, attached with a 753 context ID. The corresponding protection service instance on the 754 protector recognizes the service, and resolves forwarding state based 755 on its own connectivity with the service's destination. It then 756 installs the service label with the forwarding state in the label 757 space of the egress router, which is indicated by the context ID 758 (i.e. context label). 760 Different service protocols may use different mechanisms for such 761 kind of label distribution. Specific protocol extensions may be 762 needed on a per-protocol basis or per-service-type basis. The 763 specific details of the extensions SHOULD be specified in separate 764 documents. 766 5.14. Centralized protector mode 768 In this framework, it is assumed that the service destination of an 769 egress-protected service MUST be dual-homed to two edge routers of an 770 MPLS network. One of them is the protected egress router, and the 771 other is a backup egress router. So far in this document, the 772 discussion has been focusing on the scenario where a protector and a 773 backup egress router are co-located as one router. Therefore, the 774 number of protectors in a network is equal to the number of backup 775 egress routers. As another scenario, a network may assign a small 776 number of routers to serve as dedicated protectors, each protecting a 777 subset of egress routers. These protectors are called centralized 778 protectors. 780 Topologically, a centralized protector may be decoupled from all 781 backup egress routers, or it may be co-located with one backup egress 782 router while decoupled from the other backup egress routers. The 783 procedures in this section assume the scenario where a protector and 784 a backup egress router are decoupled. 786 services 1, ..., N 787 =====================================> tunnel 789 I ------ R1 ------- PLR --------------- E ---- 790 ingress penultimate-hop egress \ 791 | . (primary \ 792 | . service \ 793 | . instances) \ 794 | . \ 795 | . bypass \ service 796 R2 . tunnel destinations 797 | . / (CEs, sites) 798 | . / 799 | . / 800 | . / 801 | . tunnel / 802 | =============> / 803 P ---------------- E' --- 804 protector backup egress 805 (protection (backup 806 service service 807 instances) instances) 809 Figure 2 811 Like a co-located protector, a centralized protector hosts protection 812 service instances, receives rerouted service packets from PLRs, and 813 performs context label switching and/or context IP forwarding. For 814 each service, instead of sending service packets directly to the 815 service destination, the protector MUST send them via another 816 transport tunnel to the corresponding backup service instance on a 817 backup egress router. The backup service instance in turn forwards 818 them to the service destination. Specifically, in the case of an 819 MPLS service, the protector MUST swap the service label in each 820 received service packet to the label of the backup service advertised 821 by the backup egress router, and then push a label (or label stack) 822 of the transport tunnel. 824 In order for a centralized protector to map an egress-protected MPLS 825 service to a service hosted on a backup egress router, there MUST be 826 a service label distribution protocol session between the backup 827 egress router and the protector. Through this session, the backup 828 egress router advertises the service label of the backup service, 829 attached with the FEC of the egress-protected service and the context 830 ID of the protected egress {E, P}. Based on this information, the 831 protector associates the egress-protected service with the backup 832 service, resolves or establishes a transport tunnel to the backup 833 egress router, and accordingly sets up forwarding state for the label 834 of the egress-protected service in the label space of the egress 835 router. 837 The service label which the backup egress router advertises to the 838 protector can be the same as the label which the backup egress router 839 advertises to ingress router(s), if and only if the forwarding state 840 of the label does not direct service packets towards the protected 841 egress router. Otherwise, the label is not usable for egress 842 protection, because it will loop rerouted service packets back to the 843 egress router, which MUST be avoided. In this case, the backup 844 egress router MUST advertise a unique service label dedicated for 845 egress protection, and set its forwarding state to use the backup 846 egress router's connectivity with the service destination. 848 6. Egress link protection 850 Egress link protection is achievable through similar procedures to 851 that of egress node protection. In normal situations, an egress 852 router forwards service packets to a service destination based on a 853 service label, whose forwarding state points to an egress link. In 854 egress link protection, the egress router acts as PLR, by performing 855 local failure detection and local repair. Specifically, the egress 856 router pre-establishes an egress-protection bypass tunnel to a 857 protector, and installs bypass forwarding state for the service 858 label, pointing to the bypass tunnel. During local repair, the 859 egress router reroutes service packets via the bypass tunnel to the 860 protector. The protector in turn forwards the packets to the service 861 destination (in the co-located protector mode, as shown in Figure-3), 862 or forwards the packets first to a backup egress router and then to 863 the service destination (in the centralized protector mode, as shown 864 in Figure-4). 866 service 867 =====================================> tunnel 869 I ------ R1 ------- R2 --------------- E ---- 870 ingress | ............. egress \ 871 | . PLR \ 872 | . (primary \ 873 | . service \ 874 | . instance) \ 875 | . \ 876 | . bypass service 877 | . tunnel destination 878 | . / (CE, site) 879 | . / 880 | . / 881 | . / 882 | . / 883 | ............... / 884 R3 --------------- P ---- 885 protector 886 (protection 887 service 888 instance) 890 Figure 3 892 service 893 =====================================> tunnel 895 I ------ R1 ------- R2 --------------- E ---- 896 ingress | ............. egress \ 897 | . PLR \ 898 | . (primary \ 899 | . service \ 900 | . instance) \ 901 | . \ 902 | . bypass service 903 | . tunnel destination 904 | . / (CE, site) 905 | . / 906 | . / 907 | . / 908 | . tunnel / 909 | =============> / 910 R3 --------------- P ---- 911 protector backup egress 912 (protection (backup 913 service service 914 instance) instance) 916 Figure 4 918 There are two approaches to set up the bypass forwarding state on the 919 egress router, depending on whether the egress router knows the 920 service label advertised by the backup egress router. The difference 921 is that one approach requires the protector to perform context label 922 switching, and the other one does not. Both approaches are equally 923 supported by this framework, and may be used in parallel. 925 (1) The first approach applies when the egress router does not 926 know the service label advertised by the backup egress router. In 927 this case, the egress router sets up the bypass forwarding state 928 as a label push with the outgoing label of the egress-protection 929 bypass tunnel. Rerouted packets will have the egress router's 930 service label intact. Therefore, the protector MUST perform 931 context label switching, and the bypass tunnel MUST be destined 932 for the context ID of the {E, P} and established as described in 933 Section 5.11. This approach is consistent with egress node 934 protection. A protector can serve both egress node protection and 935 egress link protection in a consistent manner, and both the co- 936 located protector mode and the centralized protector mode may be 937 used (Figure-3 and Figure-4). 939 (2) The second approach applies when the egress router knows the 940 service label advertised by the backup egress route, via a label 941 distribution protocol session. In this case, the backup egress 942 router serves as the protector for egress link protection, 943 regardless of the protector of egress node protection, which 944 should be the same router in the co-located protector mode but may 945 be a different router in the centralized protector mode. The 946 egress router sets up the bypass forwarding state as a label swap 947 from the incoming service label to the service label of the 948 protector, followed by a label push with the outgoing label of the 949 egress link protection bypass tunnel. The bypass tunnel is a 950 regular tunnel destined for an IP address of the protector, 951 instead of the context ID of the {E, P}. The protector simply 952 forwards rerouted service packets based on its own service label, 953 rather than performing context label switching. With this 954 approach, only the co-located protector mode is applicable. 956 Note that for a bidirectional service, the physical link of an egress 957 link may carry service traffic bi-directionally. Therefore, a 958 failure of the physical link may be considered as an egress link 959 failure for the traffic towards the service destination, as well as 960 an ingress link failure for the traffic in the opposite direction. 961 However, protection for ingress link failure SHOULD be provided by a 962 separate mechanism, and hence is out of the scope of this framework. 964 7. Global repair 966 This framework provides a fast but temporary repair for egress node 967 and link failures. For permanent repair, it is RECOMMENDED that the 968 traffic SHOULD be moved to an alternative tunnel or alternative 969 services which are fully functional. This is referred to as global 970 repair. Possible triggers of global repair include control plane 971 notifications of tunnel and service status, end-to-end OAM and fault 972 detection at tunnel or service levels, and others. The alternative 973 tunnel and services may be pre-established as standby, or newly 974 established as a result of the triggers or network protocol 975 convergence. 977 8. Example: Layer-3 VPN egress protection 979 This section shows an example of egress protection for a layer-3 VPN. 981 ---------- R1 ----------- PE2 - 982 / (PLR) (PLR) \ 983 ( ) / | | ( ) 984 ( ) / | | ( ) 985 ( site 1 )-- PE1 < | R3 ( site 2 ) 986 ( ) \ | | ( ) 987 ( ) \ | | ( ) 988 \ | | / 989 ---------- R2 ----------- PE3 - 990 (protector) 992 Figure 5 994 In this example, the site 1 (subnet 203.0.113.192/26) of a given VPN 995 is attached to PE1, and site 2 (subnet 203.0.113.128/26) is dual- 996 homed to PE2 and PE3. PE2 is the primary PE for site 2, and PE3 is 997 the backup PE. Each PE hosts a VPN instance. R1 and R2 are transit 998 routers in the MPLS network. The network uses OSPF as routing 999 protocol, and RSVP-TE as tunnel signaling protocol. The PEs use BGP 1000 to exchange VPN prefixes and VPN labels between each other. 1002 Using the framework in this document, the network assigns PE3 to be a 1003 protector for PE2 to protect the VPN traffic in the direction from 1004 site 1 to site 2. This is the co-located protector mode. Hence, PE2 1005 and PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 1006 is assigned to the protected egress {PE2, PE3}. The VPN instance on 1007 PE3 serves as a protection instance for the VPN instance on PE2. On 1008 PE3, a context label 100 is assigned to the context ID, and a label 1009 table pe2.mpls is created to represent PE2's label space. PE3 1010 installs the label 100 in its default MPLS forwarding table, with 1011 nexthop pointing to the label table pe2.mpls. PE2 and PE3 are 1012 coordinated to use the proxy mode to advertise the context ID in the 1013 routing domain and the TE domain. 1015 PE2 uses per-VRF VPN label allocation mode. It assigns a single 1016 label 9000 to the VRF of the VPN. For a given VPN prefix 1017 203.0.113.128/26 in site 2, PE2 advertises it along with the label 1018 9000 and other attributes to PE1 and PE3 via BGP. In particular, the 1019 NEXT_HOP attribute is set to the context ID 198.51.100.1. 1021 Similarly, PE3 also uses per-VRF VPN label allocation mode. It 1022 assigns a single label 10000 to the VRF of the VPN. For the VPN 1023 prefix 203.0.113.128/26 in site 2, PE3 advertises it along with the 1024 label 10000 and other attributes to PE1 and PE2 via BGP. In 1025 particular, the NEXT_HOP attribute is set to an IP address of PE3. 1027 Upon receipt and acceptance of the BGP advertisement, PE1 uses the 1028 context ID 198.51.100.1 as destination to compute a TE path for an 1029 egress-protected tunnel. The resulted path is PE1->R1->PE2. PE1 1030 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1 1031 as destination, and with the "node protection desired" flag set in 1032 the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes 1033 up, PE1 maps the VPN prefix 203.0.113.128/26 to the tunnel and 1034 installs a route for the prefix in the corresponding VRF. The 1035 route's nexthop is a push with the VPN label 9000, followed by a push 1036 with the outgoing label of the egress-protected tunnel. 1038 Upon receipt of the above BGP advertisement from PE2, PE3 (i.e. the 1039 protector) recognizes the context ID 198.51.100.1 in the NEXT_HOP 1040 attribute, and installs a route for label 9000 in the label table 1041 pe2.mpls. PE3 sets the route's nexthop to a "protection VRF". This 1042 protection VRF contains IP routes corresponding to the IP prefixes in 1043 the dual-homed site 2, including 203.0.113.128/26. The nexthops of 1044 these routes MUST be based on PE3's connectivity with site 2, even if 1045 this connectivity is not the best path in PE3's VRF due to metrics 1046 (e.g. MED, local preference, etc.), and MUST NOT use any path 1047 traversing PE2. Note that the protection VRF is a logical concept, 1048 and it may simply be PE3's own VRF if the VRF satisfies the 1049 requirement. 1051 8.1. Egress node protection 1053 R1, i.e. the penultimate-hop router of the egress-protected tunnel, 1054 serves as the PLR for egress node protection. Based on the "node 1055 protection desired" flag and the destination address (i.e. context ID 1056 198.51.100.1) of the tunnel, R1 computes a bypass path to 1057 198.51.100.1 while avoiding PE2. The resulted bypass path is 1058 R1->R2->PE3. R1 then signals the path (i.e. egress-protection bypass 1059 tunnel), with 198.51.100.1 as destination. 1061 Upon receipt of an RSVP Path message of the egress-protection bypass 1062 tunnel, PE3 recognizes the context ID 198.51.100.1 as the 1063 destination, and hence responds with the context label 100 in an RSVP 1064 Resv message. 1066 After the egress-protection bypass tunnel comes up, R1 installs a 1067 bypass nexthop for the egress-protected tunnel. The bypass nexthop 1068 is a swap from the incoming label of the egress-protected tunnel to 1069 the outgoing label of the egress-protection bypass tunnel. 1071 When R1 detects a failure of PE2, it will invoke the above bypass 1072 nexthop to reroute VPN service packets. The packets will have the 1073 label of the bypass tunnel as outer label, and the VPN label 9000 as 1074 inner label. When the packets arrive at PE3, they will have the 1075 context label 100 as outer label, and the VPN label 9000 as inner 1076 label. The context label will first be popped, and then the VPN 1077 label will be looked up in the label table pe2.mpls. The lookup will 1078 cause the VPN label to be popped, and the IP packets will finally be 1079 forwarded to site 2 based on the protection VRF. 1081 8.2. Egress link protection 1083 PE2 serves as the PLR for egress link protection. It has already 1084 learned the VPN label 10000 from PE3, and hence it uses the approach 1085 (2) described in Section 6 to set up bypass forwarding state. It 1086 signals an egress-protection bypass tunnel to PE3, by using the path 1087 PE2->R3->PE3, and PE3's IP address as destination. After the bypass 1088 tunnel comes up, PE2 installs a bypass nexthop for the VPN label 1089 9000. The bypass nexthop is a label swap from the incoming label 1090 9000 to the VPN label 10000 of PE3, followed by a label push with the 1091 outgoing label of the bypass tunnel. 1093 When PE3 detects a failure of the egress link, it will invoke the 1094 above bypass nexthop to reroute VPN service packets. The packets 1095 will have the label of the bypass tunnel as outer label, and the VPN 1096 label 10000 as inner label. When the packets arrive at PE3, the VPN 1097 label 10000 will be popped, and the IP packets will be forwarded 1098 based on the VRF indicated by on the VPN label 10000. 1100 8.3. Global repair 1102 Eventually, global repair will take effect, as control plane 1103 protocols converge on the new topology. PE1 will choose PE3 as new 1104 entrance to site 2. Before that happens, the VPN traffic has been 1105 protected by the above local repair. 1107 9. IANA Considerations 1109 This document has no request for new IANA allocation. 1111 10. Security Considerations 1113 The framework in this document relies on fast reroute around a 1114 network failure. Specifically, service traffic is temporarily 1115 rerouted from a PLR to a protector. In the centralized protector 1116 mode, the traffic is further rerouted from the protector to a backup 1117 egress router. Such kind of fast reroute is planned and anticipated, 1118 and hence it should not be viewed as a new security threat. 1120 The framework requires a service label distribution protocol to run 1121 between an egress router and a protector. The available security 1122 measures of the protocol MAY be used to achieve a secured session 1123 between the two routers. 1125 11. Acknowledgements 1127 This document leverages work done by Yakov Rekhter, Kevin Wang and 1128 Zhaohui Zhang on MPLS egress protection. Thanks to Alexander 1129 Vainshtein and Rolf Winter for their valuable comments that helped 1130 shape this document and improve its clarity. 1132 12. References 1134 12.1. Normative References 1136 [SR-ARCH] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1137 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1138 spring-segment-routing (work in progress), 2016. 1140 [SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1141 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1142 Extensions for Segment Routing", draft-ietf-ospf-segment- 1143 routing-extensions (work in progress), 2016. 1145 [SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1146 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1147 Extensions for Segment Routing", draft-ietf-isis-segment- 1148 routing-extensions (work in progress), 2016. 1150 12.2. Informative References 1152 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1153 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1154 DOI 10.17487/RFC4090, May 2005, 1155 . 1157 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1158 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1159 DOI 10.17487/RFC5286, September 2008, 1160 . 1162 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1163 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 1164 RFC 7490, DOI 10.17487/RFC7490, April 2015, 1165 . 1167 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 1168 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 1169 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 1170 . 1172 [BGP-PIC] Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix 1173 Independent Convergence", draft-ietf-rtgwg-bgp-pic-05.txt 1174 (work in progress), 2017. 1176 Authors' Addresses 1178 Yimin Shen 1179 Juniper Networks 1180 10 Technology Park Drive 1181 Westford, MA 01886 1182 USA 1184 Phone: +1 9785890722 1185 Email: yshen@juniper.net 1187 Minto Jeyananth 1188 Juniper Networks 1189 1133 Innovation Way 1190 Sunnyvale, CA 94089 1191 USA 1193 Phone: +1 4089367563 1194 Email: minto@juniper.net 1196 Bruno Decraene 1197 Orange 1199 Email: bruno.decraene@orange.com 1201 Hannes Gredler 1202 RtBrick Inc 1204 Email: hannes@rtbrick.com 1206 Carsten Michel 1207 Deutsche Telekom 1209 Email: c.michel@telekom.de 1210 Huaimo Chen 1211 Huawei Technologies Co., Ltd. 1213 Email: huaimo.chen@huawei.com 1215 Yuanlong Jiang 1216 Huawei Technologies Co., Ltd. 1217 Bantian, Longgang district 1218 Shenzhen 518129 1219 China 1221 Email: jiangyuanlong@huawei.com