idnits 2.17.1 draft-ietf-mpls-egress-protection-framework-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 2, 2019) is 1940 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-rtgwg-bgp-pic-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Yimin Shen 3 Internet-Draft Minto Jeyananth 4 Intended status: Standards Track Juniper Networks 5 Expires: July 6, 2019 Bruno Decraene 6 Orange 7 Hannes Gredler 8 RtBrick Inc 9 Carsten Michel 10 Deutsche Telekom 11 Huaimo Chen 12 Yuanlong Jiang 13 Huawei Technologies Co., Ltd. 14 January 2, 2019 16 MPLS Egress Protection Framework 17 draft-ietf-mpls-egress-protection-framework-04 19 Abstract 21 This document specifies a fast reroute framework for protecting IP/ 22 MPLS services and MPLS transport tunnels against egress node and 23 egress link failures. In this framework, the penultimate-hop router 24 of an MPLS tunnel acts as the point of local repair (PLR) for an 25 egress node failure, and the egress router of the MPLS tunnel acts as 26 the PLR for an egress link failure. Each of them pre-establishes a 27 bypass tunnel to a protector. Upon an egress node or link failure, 28 the corresponding PLR performs local failure detection and local 29 repair, by rerouting packets over the corresponding bypass tunnel. 30 The protector in turn performs context label switching or context IP 31 forwarding to send the packets to the ultimate service 32 destination(s). This mechanism can be used to reduce traffic loss 33 before global repair reacts to the failure and control plane 34 protocols converge on the topology changes due to the failure. The 35 framework is applicable to all types of IP/MPLS services and MPLS 36 tunnels. Under the framework, service protocol extensions may be 37 further specified to support service label distribution from an 38 egress router to a protector. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on July 6, 2019. 57 Copyright Notice 59 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 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. General context-based forwarding . . . . . . . . . . . . . . 22 95 9. Example: Layer-3 VPN egress protection . . . . . . . . . . . 23 96 9.1. Egress node protection . . . . . . . . . . . . . . . . . 24 97 9.2. Egress link protection . . . . . . . . . . . . . . . . . 25 98 9.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 25 99 9.4. Other modes of VPN label allocation . . . . . . . . . . . 25 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 102 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 105 13.2. Informative References . . . . . . . . . . . . . . . . . 27 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 108 1. Introduction 110 In MPLS networks, label switched paths (LSPs) are widely used as 111 transport tunnels to carry IP and MPLS services across MPLS domains. 112 Examples of MPLS services are layer-2 VPNs, layer-3 VPNs, 113 hierarchical LSPs, and others. In general, a tunnel may carry 114 multiple services of one or multiple types, if the tunnel can satisfy 115 both individual and aggregate requirements (e.g. CoS, QoS) of these 116 services. The egress router of the tunnel hosts the service 117 instances of the services. Each MPLS service instance is responsible 118 for forwarding service packets via an egress link to the service 119 destination, based on a service label. Each IP service instance is 120 responsible for doing the same based on a service IP address. The 121 egress link is often called a PE-CE (provider edge - customer edge) 122 link or attachment circuit (AC). 124 Today, local repair based fast reroute mechanisms [RFC4090], 125 [RFC5286], [RFC7490], [RFC7812] have been widely deployed to protect 126 MPLS tunnels against transit link/node failures, with traffic 127 restoration time in the order of tens of milliseconds. Local repair 128 refers to the scenario where the router upstream to an anticipated 129 failure (aka. PLR, i.e. point of local repair) pre-establishes a 130 bypass tunnel to the router downstream of the failure (aka. MP, i.e. 131 merge point), pre-installs the forwarding state of the bypass tunnel 132 in the data plane, and uses a rapid mechanism (e.g. link layer OAM, 133 BFD, and others) to locally detect the failure in the data plane. 134 When the failure occurs, the PLR reroutes traffic through the bypass 135 tunnel to the MP, allowing the traffic to continue to flow to the 136 tunnel's egress router. 138 This document describes a fast reroute framework for egress node and 139 egress link protection. Similar to transit link/node protection, 140 this framework also relies on a PLR to perform local failure 141 detection and local repair. In egress node protection, the PLR is 142 the penultimate-hop router of a tunnel. In egress link protection, 143 the PLR is the egress router of the tunnel. The framework further 144 relies on a so-called "protector" to serve as the tailend of a bypass 145 tunnel. The protector is a router that hosts "protection service 146 instances" and has its own connectivity or paths to service 147 destinations. When a PLR does local repair, the protector is 148 responsible for performing "context label switching" for rerouted 149 MPLS service packets and "context IP forwarding" for rerouted IP 150 service packets, to allow the service packets to continue to reach 151 the service destinations. 153 This framework considers an egress node failure as a failure of a 154 tunnel, as well as a failure of all the services carried by the 155 tunnel, because service packets can no longer reach the service 156 instances on the egress router. Therefore, the framework addresses 157 egress node protection at both tunnel level and service level 158 simultaneously. Likewise, the framework considers an egress link 159 failure as a failure of all the services traversing the link, and 160 addresses egress link protection at the service level. 162 This framework requires that the destination (a CE or site) of a 163 service MUST be dual-homed or have dual paths to an MPLS network, via 164 two MPLS edge routers. One of the routers is the egress router of 165 the service's transport tunnel, and the other is a backup egress 166 router which hosts a "backup service instance". In the "co-located" 167 protector mode in this document, the backup egress router serves as 168 the protector, and hence the backup service instance acts as the 169 protection service instance. In the "centralized" protector mode 170 (Section 5.12), the protector and the backup egress router are 171 decoupled, and the protection service instance and the backup service 172 instance are hosted separately by the two routers. 174 The framework is described by mainly referring to P2P (point-to- 175 point) tunnels. However, it is equally applicable to P2MP (point-to- 176 multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to- 177 multipoint) tunnels, if a sub-LSP can be viewed as a P2P tunnel. 179 The framework is a multi-service and multi-transport framework. It 180 assumes a generic model where each service is comprised of a common 181 set of components, including a service instance, a service label, and 182 a service label distribution protocol, and the service is transported 183 over an MPLS tunnel of any type. The framework also assumes service 184 labels to be downstream assigned, i.e. assigned by egress routers. 185 Therefore, the framework is generally applicable to most existing and 186 future services. However, there are services with certain modes, 187 where a protector is unable to pre-establish forwarding state for 188 egress protection, or a PLR is prohibited from rerouting traffic to 189 any other router to avoid traffic duplication, e.g. the broadcast, 190 multicast, and unknown unicast traffic in VPLS and EVPN. These cases 191 are left for future study. Services which use upstream-assigned 192 service labels are also out of scope of this document and left for 193 future study. 195 The framework does not require extensions for the existing signaling 196 and label distribution protocols (e.g. RSVP, LDP, BGP, etc.) of MPLS 197 tunnels. It expects transport tunnels and bypass tunnels to be 198 established by using the generic mechanisms provided by the 199 protocols. On the other hand, it does not preclude extensions to the 200 protocols which may facilitate the procedures. One example of such 201 extension is [RFC8400]. The framework may need extensions for IGPs 202 and service label distribution protocols, to support protection 203 establishment and context label switching. This document provides 204 guidelines for these extensions, but the specific details SHOULD be 205 addressed in separate documents. 207 The framework is intended to complement control-plane convergence and 208 global repair, which are traditionally used to recover networks from 209 egress node and egress link failures. Control-plane convergence 210 relies on control protocols to react on the topology changes due to a 211 failure. Global repair relies an ingress router to remotely detect a 212 failure and switch traffic to an alternative path. An example of 213 global repair is the BGP Prefix Independent Convergence mechanism 214 [BGP-PIC] for BGP established services. Compared with these 215 mechanisms, this framework is considered as faster in traffic 216 restoration, due to the nature of local failure detection and local 217 repair. However, it is RECOMMENDED that the framework SHOULD be used 218 in conjunction with control-plane convergence or global repair, in 219 order to take the advantages of both approaches. That is, the 220 framework provides fast and temporary repair, and control-plane 221 convergence or global repair provides ultimate and permanent repair. 223 2. Specification of Requirements 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 227 document are to be interpreted as described in [RFC2119] and 228 [RFC8174]. 230 3. Terminology 232 Egress router - A router at the egress endpoint of a tunnel. It 233 hosts service instances for all the services carried by the tunnel, 234 and has connectivity with the destinations of the services. 236 Egress node failure - A failure of an egress router. 238 Egress link failure - A failure of the egress link (e.g. PE-CE link, 239 attachment circuit) of a service. 241 Egress failure - An egress node failure or an egress link failure. 243 Egress-protected tunnel - A tunnel whose egress router is protected 244 by a mechanism according to this framework. The egress router is 245 hence called a protected egress router. 247 Egress-protected service - An IP or MPLS service which is carried by 248 an egress-protected tunnel, and hence protected by a mechanism 249 according to this framework. 251 Backup egress router - Given an egress-protected tunnel and its 252 egress router, this is another router which has connectivity with all 253 or a subset of the destinations of the egress-protected services 254 carried by the egress-protected tunnel. 256 Backup service instance - A service instance which is hosted by a 257 backup egress router, and corresponding to an egress-protected 258 service on a protected egress router. 260 Protector - A role acted by a router as an alternate of a protected 261 egress router, to handle service packets in the event of an egress 262 failure. A protector may be physically co-located with or decoupled 263 from a backup egress router, depending on the co-located or 264 centralized protector mode. 266 Protection service instance - A service instance hosted by a 267 protector, corresponding to the service instance of an egress- 268 protected service on a protected egress router. A protection service 269 instance is a backup service instance, if the protector is co-located 270 with a backup egress router. 272 PLR - A router at the point of local repair. In egress node 273 protection, it is the penultimate-hop router on an egress-protected 274 tunnel. In egress link protection, it is the egress router of the 275 egress-protected tunnel. 277 Protected egress {E, P} - A virtual node consisting of an ordered 278 pair of egress router E and protector P. It serves as the virtual 279 destination of an egress-protected tunnel, and as the virtual 280 location of the egress-protected services carried by the tunnel. 282 Context identifier (ID) - A globally unique IP address assigned to a 283 protected egress {E, P}. 285 Context label - A non-reserved label assigned to a context ID by a 286 protector. 288 Egress-protection bypass tunnel - A tunnel used to reroute service 289 packets around an egress failure. 291 Co-located protector mode - The scenario where a protector and a 292 backup egress router are co-located as one router, and hence each 293 backup service instance serves as a protection service instance. 295 Centralized protector mode - The scenario where a protector is a 296 dedicated router, and is decoupled from backup egress routers. 298 Context label switching - Label switching performed by a protector, 299 in the label space of an egress router indicated by a context label. 301 Context IP forwarding - IP forwarding performed by a protector, in 302 the IP address space of an egress router indicated by a context 303 label. 305 4. Requirements 307 This document considers the followings as the design requirements of 308 this egress protection framework. 310 o The framework must support P2P tunnels. It should equally support 311 P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P 312 tunnel. 314 o The framework must support multi-service and multi-transport 315 networks. It must accommodate existing and future signaling and 316 label-distribution protocols of tunnels and bypass tunnels, 317 including RSVP, LDP, BGP, IGP, segment routing, and others. It 318 must also accommodate existing and future IP/MPLS services, 319 including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and 320 others. It must provide a general solution for environments where 321 different types of services and tunnels may co-exist. 323 o The framework must consider minimizing disruption during 324 deployment. It should only involve routers close to egress, and 325 be transparent to ingress routers and other transit routers. 327 o In egress node protection, for scalability and performance 328 reasons, a PLR must be agnostic to services and service labels, 329 like PLRs in transit link/node protection. It must maintain 330 bypass tunnels and bypass forwarding state on a per-transport- 331 tunnel basis, rather than per-service-destination or per-service- 332 label basis. It should also support bypass tunnel sharing between 333 transport tunnels. 335 o A PLR must be able to use its local visibility or information of 336 routing and/or TE topology to compute or resolve a path for a 337 bypass tunnel. 339 o A protector must be able to perform context label switching for 340 rerouted MPLS service packets, based on service label(s) assigned 341 by an egress router. It must be able to perform context IP 342 forwarding for rerouted IP service packets, in the public or 343 private IP address space used by an egress router. 345 o The framework must be able to work seamlessly with transit link/ 346 node protection mechanisms to achieve end-to-end coverage. 348 o The framework must be able to work in conjunction with global 349 repair and control plane convergence. 351 5. Egress node protection 353 5.1. Reference topology 355 This document refers to the following topology when describing the 356 procedures of egress node protection. 358 services 1, ..., N 359 =====================================> tunnel 361 I ------ R1 ------- PLR --------------- E ---- 362 ingress penultimate-hop egress \ 363 | . (primary \ 364 | . service \ 365 | . instances) \ 366 | . \ 367 | . \ service 368 | . destinations 369 | . / (CEs, sites) 370 | . / 371 | . bypass / 372 | . tunnel / 373 | . / 374 | ............... / 375 R2 --------------- P ---- 376 protector 377 (protection 378 service 379 instances) 381 Figure 1 383 5.2. Egress node failure and detection 385 An egress node failure refers to the failure of an MPLS tunnel's 386 egress router. At the service level, it also means a service 387 instance failure for each IP/MPLS service carried by the tunnel. 389 Ideally, an egress node failure can be detected by an adjacent router 390 (i.e. PLR in this framework) using a node liveness detection 391 mechanism, or based on a collective failure of all the links to that 392 node. However, the assumption is that the mechanisms SHOULD be 393 reasonably fast, i.e. faster than control plane failure detection and 394 remote failure detection. Otherwise, local repair will not be able 395 to provide much benefit compared to control plane convergence or 396 global repair. In general, the speed, accuracy, and reliability of a 397 mechanism are the key factors to decide its applicability in egress 398 node protection. This document provides the following guidelines in 399 this regard. 401 o If the PLR has a reasonably fast mechanism to detect and 402 differentiate a link failure (of the link between the PLR and the 403 egress node) and an egress node failure, it SHOULD set up both 404 link protection and egress node protection, and trigger one and 405 only one protection upon a corresponding failure. 407 o If the PLR has a fast mechanism to detect a link failure and an 408 egress node failure, but cannot distinguish them; Or, if the PLR 409 has a fast mechanism to detect a link failure only, but not an 410 egress node failure, the PLR has two options: 412 1. It MAY set up link protection only, and leave the egress node 413 failure to global repair and control plane convergence to 414 handle. 416 2. It MAY set up egress node protection only, and treat a link 417 failure as a trigger for the egress node protection. However, 418 the assumption is that treating a link failure as an egress 419 node failure MUST NOT have a negative impact on services. 420 Otherwise, it SHOULD adopt the previous option. 422 5.3. Protector and PLR 424 A router is assigned to the "protector" role to protect a tunnel and 425 the services carried by the tunnel against an egress node failure. 426 The protector is responsible for hosting a protection service 427 instance for each protected service, serving as the tailend of a 428 bypass tunnel, and performing context label switching and/or context 429 IP forwarding for rerouted service packets. 431 A tunnel can be protected by only one protector at a given time. 432 Multiple tunnels to a given egress router may be protected by a 433 common protector or different protectors. A protector may protect 434 multiple tunnels with a common egress router or different egress 435 routers. 437 For each tunnel, its penultimate-hop router acts as a PLR. The PLR 438 pre-establishes a bypass tunnel to the protector, and pre-installs 439 bypass forwarding state in the data plane. Upon detection of an 440 egress node failure, the PLR reroutes all the service packets 441 received on the tunnel though the bypass tunnel to the protector. 442 For MPLS service packets, the PLR keeps service labels intact in the 443 packets. The protector in turn forwards the rerouted service packets 444 towards the ultimate service destinations. Specifically, it performs 445 context label switching for MPLS service packets, based on the 446 service labels which are assigned by the protected egress router; It 447 performs context IP forwarding for IP service packets, based on their 448 destination addresses. 450 The protector MUST have its own connectivity with each service 451 destination, via a direct link or a multi-hop path, which MUST NOT 452 traverse the protected egress router or be affected by the egress 453 node failure. This also requires that each service destination MUST 454 be dual-homed or have dual paths to the egress router and a backup 455 egress router which serves as the protector. Each protection service 456 instance on the protector relies on such connectivity to set up 457 forwarding state for context label switching and context IP 458 forwarding. 460 5.4. Protected egress 462 This document introduces the notion of "protected egress" as a 463 virtual node consisting of the egress router E of a tunnel and a 464 protector P. It is denoted by an ordered pair of {E, P}, indicating 465 the primary-and-protector relationship between the two routers. It 466 serves as the virtual destination of the tunnel, and the virtual 467 location of service instances for the services carried by the tunnel. 468 Hence, the tunnel and services are considered as being "associated" 469 with the protected egress {E, P}. 471 A given egress router E may be the tailend of multiple tunnels. In 472 general, the tunnels may be protected by multiple protectors, e.g. 473 P1, P2, and so on, with each Pi protecting a subset of the tunnels. 474 Thus, these routers form multiple protected egresses, i.e. {E, P1} , 475 {E, P2}, and so on. Each tunnel is associated with one and only one 476 protected egress {E, Pi}. All the services carried by the tunnel are 477 then automatically associated with the protected egress {E, Pi}. 478 Conversely, a service associated with a protected egress {E, Pi} MUST 479 be carried by a tunnel associated with the protected egress {E, Pi}. 480 This mapping MUST be ensured by the ingress router of the tunnel and 481 the service (Section 5.5). 483 Two routers X and Y may be protectors for each other. In this case, 484 they form two distinct protected egresses {X, Y} and {Y, X}. 486 5.5. Egress-protected tunnel and service 488 A tunnel, which is associated with a protected egress {E, P}, is 489 called an egress-protected tunnel. It is associated with one and 490 only one protected egress {E, P}. Multiple egress-protected tunnels 491 may be associated with a given protected egress {E, P}. In this case, 492 they share the common egress router and protector, but may or may not 493 share a common ingress router, or a common PLR (i.e. penultimate-hop 494 router). 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 A service, which is associated with a protected egress {E, P}, is 501 called an egress-protected service. The egress router E hosts the 502 primary instance of the service, and the protector P hosts the 503 protection instance of the service. 505 An egress-protected service is associated with one and only one 506 protected egress {E, P}. Multiple egress-protected services may be 507 associated with a given protected egress {E, P}. In this case, these 508 services share the common egress router and protector, but may or may 509 not share a common egress-protected tunnel or a common ingress 510 router. 512 An egress-protected service MUST be mapped to an egress-protected 513 tunnel by its ingress router, based on the common protected egress 514 {E, P} of the service and the tunnel. This is achieved by 515 introducing the notion of "context ID" for protected egress {E, P}, 516 as described in (Section 5.7). 518 5.6. Egress-protection bypass tunnel 520 An egress-protected tunnel destined for a protected egress {E, P} 521 MUST have a bypass tunnel from its PLR to the protector P. This 522 bypass tunnel is called an egress-protection bypass tunnel. The 523 bypass tunnel is considered as logically "destined" for the protected 524 egress {E, P}. However, due to its bypass nature, it MUST be resolved 525 and established with P as the physical tailend and E as the node to 526 avoid. The bypass tunnel MUST have the property that it MUST NOT be 527 affected by the topology change caused by an egress node failure. 529 An egress-protection bypass tunnel is associated with one and only 530 one protected egress {E, P}. A PLR may share an egress-protection 531 bypass tunnel for multiple egress-protected tunnels associated with a 532 common protected egress {E, P}. For multiple egress-protected tunnels 533 associated with a common protected egress {E, P}, there may be one or 534 multiple egress-protection bypass tunnels from one or multiple PLRs 535 to the protector P, depending on the paths of the egress-protected 536 tunnels. 538 5.7. Context ID, context label, and context based forwarding 540 In this framework, a globally unique IPv4/v6 address is assigned to a 541 protected egress {E, P} to serve as the identifier of the protected 542 egress {E, P}. It is called a "context ID" due to its specific usage 543 in context label switching and context IP forwarding on the 544 protector. It is an IP address that is logically owned by both the 545 egress router and the protector. For the egress node, it indicates 546 the protector. For the protector, it indicates the egress router, 547 particularly the egress router's forwarding context. For other 548 routers in the network, it is an address reachable via both the 549 egress router and the protector in the routing domain and the TE 550 domain (Section 5.8), similar to an anycast address. 552 The main purpose of a context ID is to coordinate ingress router, 553 egress router, PLR and protector to set up egress protection. Given 554 an egress-protected service associated with a protected egress {E, 555 P}, its context ID is used as below: 557 o If the service is an MPLS service, when E distributes a service 558 label binding message to the ingress router, E attaches the 559 context ID to the message. If the service is an IP service, when 560 E advertises the service destination address to the ingress 561 router, E also attaches the context ID to the advertisement 562 message. How the context ID is encoded in the messages is a 563 choice of the service protocol. It may need protocol extensions 564 to define a "context ID" object, if there is no existing object 565 that can be used for this purpose. 567 o The ingress router uses the context ID as a destination to 568 establish or resolve an egress-protected tunnel. The ingress 569 router then maps the service to the tunnel for transportation. In 570 this process, the semantics of the context ID is transparent to 571 the ingress router. The ingress router only treats the context ID 572 as an IP address of E, and behaves in the same manner as 573 establishing or resolving a regular transport tunnel, although the 574 result should be an egress-protected tunnel. 576 o The context ID is conveyed to the PLR by the signaling protocol of 577 the egress-protected tunnel, or learned by the PLR via an IGP 578 (i.e. OSPF or ISIS) or a topology-driven label distribution 579 protocol (e.g. LDP). The PLR uses the context ID as destination 580 to establish or resolve an egress-protection bypass tunnel to P 581 while avoiding E. 583 o P maintains a dedicated label space or a dedicated IP address 584 space for E, depending on whether the service is MPLS or IP. This 585 is referred to as "E's label space" or "E's IP address space", 586 respectively. P uses the context ID to identify the space. 588 o If the service is an MPLS service, E also distributes the service 589 label binding message to P. This is the same label binding 590 message that E advertises to the ingress router, which is attached 591 with the context ID. Based on the context ID, P installs the 592 service label in an MPLS forwarding table corresponding to E's 593 label space. If the service is an IP service, P installs an IP 594 route in an IP forwarding table corresponding to E's IP address 595 space. In either case, the protection service instance on P 596 interprets the service and constructs forwarding state for the 597 route based on P's own connectivity with the service's 598 destination. 600 o P assigns a non-reserved label to the context ID. In the data 601 plane, this label represents the context ID and indicates E's 602 label space and IP address space. Therefore, it is called a 603 "context label". 605 o The PLR may establish the egress-protection bypass tunnel to P in 606 several manners. If the bypass tunnel is established by RSVP, the 607 PLR signals the bypass tunnel with the context ID as destination, 608 and P binds the context label to the bypass tunnel. If the bypass 609 tunnel is established by LDP, P advertises the context label for 610 the context ID as an IP prefix FEC. If the bypass tunnel is 611 established by the PLR in a hierarchical manner, the PLR treats 612 the context label as a one-hop LSP over a regular bypass tunnel to 613 P (e.g. a bypass tunnel to P's loopback IP address). If the 614 bypass tunnel is constructed by using segment routing, the bypass 615 tunnel is represented by a stack of SID labels with the context 616 label as the inner-most SID label (Section 5.9). In any case, the 617 bypass tunnel is a UHP tunnel whose incoming label on P is the 618 context label. 620 o During local repair, all the service packets received by P on the 621 bypass tunnel have the context label as the top label. P first 622 pops the context label. For an MPLS service packet, P further 623 looks up the service label in E's label space indicated by the 624 context label, which is called context label switching. For an IP 625 service packet, P looks up the IP destination address in E's IP 626 address space indicated by the context label, which is called 627 context IP forwarding. 629 5.8. Advertisement and path resolution for context ID 631 Path resolution and computation for a context ID are done on ingress 632 routers for egress-protected tunnels, and on PLRs for egress- 633 protection bypass tunnels. Given a protected egress {E, P} and its 634 context ID, E and P MUST coordinate the context ID in the routing 635 domain and the TE domain via IGP advertisement. The context ID MUST 636 be advertised in such a manner that all egress-protected tunnels MUST 637 have E as tailend, and all egress-protection bypass tunnels MUST have 638 P as tailend while avoiding E. 640 This document suggests three approaches: 642 1. The first approach is called "proxy mode". It requires E and P, 643 but not the PLR, to have the knowledge of the egress protection 644 schema. E and P advertise the context ID as a virtual proxy node 645 (i.e. a logical node) connected to the two routers, with the link 646 between the proxy node and E having more preferable IGP and TE 647 metrics than the link between the proxy node and P. Therefore, 648 all egress-protected tunnels destined for the context ID should 649 automatically follow the IGP or TE paths to E. Each PLR will no 650 longer view itself as a penultimate-hop, but rather two hops away 651 from the proxy node, via E. The PLR will be able to find a 652 bypass path via P to the proxy node, while the bypass tunnel 653 should actually be terminated by P. 655 2. The second approach is called "alias mode". It requires P and 656 the PLR, but not E, to have the knowledge of the egress 657 protection schema. E simply advertises the context ID as a 658 regular IP address. P advertises the context ID and the context 659 label by using a "context ID label binding" advertisement. The 660 advertisement MUST be understood by the PLR. In both routing 661 domain and TE domain, the context ID is only reachable via E. 662 This ensures that all egress-protected tunnels destined for the 663 context ID should have E as tailend. Based on the "context ID 664 label binding" advertisement, the PLR can establish an egress- 665 protection bypass tunnel in several manners (Section 5.9). The 666 "context ID label binding" advertisement is defined as IGP 667 mirroring context segment in [RFC8402], [SR-OSPF] and [SR-ISIS]. 669 These IGP extensions are generic in nature, and hence can be used 670 for egress protection purposes. 672 3. The third approach is called "stub link mode". In this mode, 673 both E and P advertise the context ID as a link to a stub 674 network, essentially modelling the context ID as an any-cast IP 675 address owned by the two routers. E, P and the PLR do not need 676 to have the knowledge of the egress protection schema. The 677 correctness of the egress-protected tunnels and the bypass 678 tunnels relies on the path computations for the any-cast IP 679 address performed by the ingress routers and PLR. Therefore, 680 care MUST be taken for the applicability of this approach to a 681 given network topology. 683 This framework considers the approaches as technically equal, and the 684 feasibility of each approach in a given network as dependent on the 685 topology, manageability, and available protocols of the network. For 686 a given context ID, all relevant routers, including primary PE, 687 protector, and PLR, must support and agree on the chosen approach. 688 The coordination between these routers can be achieved by 689 configuration. 691 In a scenario where an egress-protected tunnel is an inter-area or 692 inter-AS tunnel, its associated context ID MUST be propagated from 693 the original area/AS to other areas/AS' via IGP or BGP, so that the 694 ingress router of the tunnel can have the reachability to the context 695 ID. The propagation process of the context ID SHOULD be the same as 696 that of a regular IP address in an inter-area/AS environment. 698 5.9. Egress-protection bypass tunnel establishment 700 A PLR MUST know the context ID of a protected egress {E, P} in order 701 to establish an egress-protection bypass tunnel. The information is 702 obtained from the signaling or label distribution protocol of the 703 egress-protected tunnel. The PLR may or may not need to have the 704 knowledge of the egress protection schema. All it does is to set up 705 a bypass tunnel to a context ID while avoiding the next-hop router 706 (i.e. egress router). This is achievable by using a constraint-based 707 computation algorithm similar to those which are commonly used in the 708 computation of traffic engineering paths and loop-free alternate 709 (LFA) paths. Since the context ID is advertised in the routing 710 domain and the TE domain by IGP according to Section 5.8, the PLR 711 should be able to resolve or establish such a bypass path with the 712 protector as tailend. In some cases like the proxy mode, the PLR may 713 do so in the same manner as transit node protection. 715 An egress-protection bypass tunnel may be established via several 716 methods: 718 (1) It may be established by a signaling protocol (e.g. RSVP), with 719 the context ID as destination. The protector binds the context label 720 to the bypass tunnel. 722 (2) It may be formed by a topology driven protocol (e.g. LDP with 723 various LFA mechanisms). The protector advertises the context ID as 724 an IP prefix FEC, with the context label bound to it. 726 (3) It may be constructed as a hierarchical tunnel. When the 727 protector uses the alias mode (Section 5.8), the PLR will have the 728 knowledge of the context ID, context label, and protector (i.e. the 729 advertiser). The PLR can then establish the bypass tunnel in a 730 hierarchical manner, with the context label as a one-hop LSP over a 731 regular bypass tunnel to the protector's IP address (e.g. loopback 732 address). This regular bypass tunnel may be established by RSVP, 733 LDP, segment routing, or another protocol. 735 5.10. Local repair on PLR 737 In this framework, a PLR is agnostic to services and service labels. 738 This obviates the need to maintain bypass forwarding state on a per- 739 service basis, and allows bypass tunnel sharing between egress- 740 protected tunnels. The PLR may share an egress-protection bypass 741 tunnel for multiple egress-protected tunnels associated with a common 742 protected egress {E, P}. During local repair, the PLR reroutes all 743 service packets received on the egress-protected tunnels via the 744 egress-protection bypass tunnel. Service labels remain intact in 745 MPLS service packets. 747 Label operation during the rerouting depends on the bypass tunnel's 748 characteristics. If the bypass tunnel is a single level tunnel, the 749 rerouting will involve swapping the incoming label of an egress- 750 protected tunnel to the outgoing label of the bypass tunnel. If the 751 bypass tunnel is a hierarchical tunnel, the rerouting will involve 752 swapping the incoming label of an egress-protected tunnel to a 753 context label, and pushing the outgoing label of a regular bypass 754 tunnel. If the bypass tunnel is constructed by segment routing, the 755 rerouting will involve swapping the incoming label of an egress- 756 protected tunnel to a context label, and pushing a stack of SID 757 labels of the bypass tunnel. 759 5.11. Service label distribution from egress router to protector 761 When a protector receives a rerouted MPLS service packet, it performs 762 context label switching based on the packet's service label which is 763 assigned by the corresponding egress router. In order to achieve 764 this, the protector MUST maintain such kind of service labels in 765 dedicated label spaces on a per protected egress {E, P} basis, i.e. 766 one label space for each egress router that it protects. 768 Also, there MUST be a service label distribution protocol session 769 between each egress router and the protector. Through this protocol, 770 the protector learns the label binding of each egress-protected 771 service. This is the same label binding that the egress router 772 advertises to the service's ingress router, which is attached with a 773 context ID. The corresponding protection service instance on the 774 protector recognizes the service, and resolves forwarding state based 775 on its own connectivity with the service's destination. It then 776 installs the service label with the forwarding state in the label 777 space of the egress router, which is indicated by the context ID 778 (i.e. context label). 780 Different service protocols may use different mechanisms for such 781 kind of label distribution. Specific protocol extensions may be 782 needed on a per-protocol basis or per-service-type basis. The 783 details of the extensions SHOULD be specified in separate documents. 784 As an example, [RFC8104] specifies the LDP extensions for pseudowire 785 services. 787 5.12. Centralized protector mode 789 In this framework, it is assumed that the service destination of an 790 egress-protected service MUST be dual-homed to two edge routers of an 791 MPLS network. One of them is the protected egress router, and the 792 other is a backup egress router. So far in this document, the 793 discussion has been focusing on the scenario where a protector and a 794 backup egress router are co-located as one router. Therefore, the 795 number of protectors in a network is equal to the number of backup 796 egress routers. As another scenario, a network may assign a small 797 number of routers to serve as dedicated protectors, each protecting a 798 subset of egress routers. These protectors are called centralized 799 protectors. 801 Topologically, a centralized protector may be decoupled from all 802 backup egress routers, or it may be co-located with one backup egress 803 router while decoupled from the other backup egress routers. The 804 procedures in this section assume that a protector and a backup 805 egress router are decoupled. 807 services 1, ..., N 808 =====================================> tunnel 810 I ------ R1 ------- PLR --------------- E ---- 811 ingress penultimate-hop egress \ 812 | . (primary \ 813 | . service \ 814 | . instances) \ 815 | . \ 816 | . bypass \ service 817 R2 . tunnel destinations 818 | . / (CEs, sites) 819 | . / 820 | . / 821 | . / 822 | . tunnel / 823 | =============> / 824 P ---------------- E' --- 825 protector backup egress 826 (protection (backup 827 service service 828 instances) instances) 830 Figure 2 832 Like a co-located protector, a centralized protector hosts protection 833 service instances, receives rerouted service packets from PLRs, and 834 performs context label switching and/or context IP forwarding. For 835 each service, instead of sending service packets directly to the 836 service destination, the protector MUST send them via another 837 transport tunnel to the corresponding backup service instance on a 838 backup egress router. The backup service instance in turn forwards 839 them to the service destination. Specifically, in the case of an 840 MPLS service, the protector MUST swap the service label in each 841 received service packet to the label of the backup service advertised 842 by the backup egress router, and then push the label (or label stack) 843 of the transport tunnel. 845 In order for a centralized protector to map an egress-protected MPLS 846 service to a service hosted on a backup egress router, there MUST be 847 a service label distribution protocol session between the backup 848 egress router and the protector. Through this session, the backup 849 egress router advertises the service label of the backup service, 850 attached with the FEC of the egress-protected service and the context 851 ID of the protected egress {E, P}. Based on this information, the 852 protector associates the egress-protected service with the backup 853 service, resolves or establishes a transport tunnel to the backup 854 egress router, and accordingly sets up forwarding state for the label 855 of the egress-protected service in the label space of the egress 856 router. 858 The service label which the backup egress router advertises to the 859 protector can be the same as the label which the backup egress router 860 advertises to the ingress router(s), if and only if the forwarding 861 state of the label does not direct service packets towards the 862 protected egress router. Otherwise, the label cannot be used for 863 egress protection, because it will create a loop for the service 864 packets. In this case, the backup egress router MUST advertise a 865 unique service label for egress protection, and set up the forwarding 866 state of the label to use the backup egress router's own connectivity 867 with the service destination. 869 6. Egress link protection 871 Egress link protection is achievable through procedures similar to 872 that of egress node protection. In normal situations, an egress 873 router forwards service packets to a service destination based on a 874 service label, whose forwarding state points to an egress link. In 875 egress link protection, the egress router acts as the PLR, and 876 performs local failure detection and local repair. Specifically, the 877 egress router pre-establishes an egress-protection bypass tunnel to a 878 protector, and sets up the bypass forwarding state for the service 879 label to point to the bypass tunnel. During local repair, the egress 880 router reroutes service packets via the bypass tunnel to the 881 protector. The protector in turn forwards the packets to the service 882 destination (in the co-located protector mode, as shown in Figure-3), 883 or forwards the packets to a backup egress router (in the centralized 884 protector mode, as shown in Figure-4). 886 service 887 =====================================> tunnel 889 I ------ R1 ------- R2 --------------- E ---- 890 ingress | ............. egress \ 891 | . PLR \ 892 | . (primary \ 893 | . service \ 894 | . instance) \ 895 | . \ 896 | . bypass service 897 | . tunnel destination 898 | . / (CE, site) 899 | . / 900 | . / 901 | . / 902 | . / 903 | ............... / 904 R3 --------------- P ---- 905 protector 906 (protection 907 service 908 instance) 910 Figure 3 912 service 913 =====================================> tunnel 915 I ------ R1 ------- R2 --------------- E ---- 916 ingress | ............. egress \ 917 | . PLR \ 918 | . (primary \ 919 | . service \ 920 | . instance) \ 921 | . \ 922 | . bypass service 923 | . tunnel destination 924 | . / (CE, site) 925 | . / 926 | . / 927 | . / 928 | . tunnel / 929 | =============> / 930 R3 --------------- P ---- 931 protector backup egress 932 (protection (backup 933 service service 934 instance) instance) 936 Figure 4 938 There are two approaches to set up the bypass forwarding state on the 939 egress router, depending on whether the egress router knows the 940 service label allocated by the backup egress router. The difference 941 is that one approach requires the protector to perform context label 942 switching, and the other one does not. Both approaches are equally 943 supported by this framework, and may be used in parallel. 945 (1) The first approach applies when the egress router does not 946 know the service label allocated by the backup egress router. In 947 this case, the egress router sets up the bypass forwarding state 948 as a label push with the outgoing label of the egress-protection 949 bypass tunnel. Rerouted packets will have the egress router's 950 service label intact. Therefore, the protector MUST perform 951 context label switching, and the bypass tunnel MUST be destined 952 for the context ID of the {E, P} and established as described in 953 Section 5.9. This approach is consistent with egress node 954 protection. Hence, a protector can serve in egress node 955 protection and egress link protection in a consistent manner, and 956 both the co-located protector mode and the centralized protector 957 mode may be used (Figure-3 and Figure-4). 959 (2) The second approach applies when the egress router knows the 960 service label allocated by the backup egress router, via a label 961 distribution protocol session. In this case, the backup egress 962 router serves as the protector for egress link protection, 963 regardless of the protector of egress node protection, which 964 should be the same router in the co-located protector mode but a 965 different router in the centralized protector mode. The egress 966 router sets up the bypass forwarding state as a label swap from 967 the incoming service label to the service label of the backup 968 egress router (i.e. protector), followed by a push with the 969 outgoing label (or label stack) of the egress link protection 970 bypass tunnel. The bypass tunnel is a regular tunnel destined for 971 an IP address of the protector, instead of the context ID of the 972 {E, P}. The protector simply forwards rerouted service packets 973 based on its own service label, rather than performing context 974 label switching. In this approach, only the co-located protector 975 mode is applicable. 977 Note that for a bidirectional service, the physical link of an egress 978 link may carry service traffic bi-directionally. Therefore, an 979 egress link failure may simultaneously be an ingress link failure for 980 the traffic in the opposite direction. However, protection for 981 ingress link failure SHOULD be provided by a separate mechanism, and 982 hence is out of the scope of this document. 984 7. Global repair 986 This framework provides a fast but temporary repair for egress node 987 and egress link failures. For permanent repair, it is RECOMMENDED 988 that the services affected by a failure SHOULD be moved to an 989 alternative tunnel, or replaced by alternative services, which are 990 fully functional. This is referred to as global repair. Possible 991 triggers of global repair include control plane notifications of 992 tunnel and service status, end-to-end OAM and fault detection at 993 tunnel or service level, and others. The alternative tunnel and 994 services may be pre-established in standby state, or dynamically 995 established as a result of the triggers or network protocol 996 convergence. 998 8. General context-based forwarding 1000 So far this document has been focusing on the cases where service 1001 packets are MPLS or IP packets and protectors perform context label 1002 switching or context IP forwarding. Although this should cover most 1003 common services, it is worth mentioning that the framework is also 1004 applicable to services or sub-modes of services where service packets 1005 are layer-2 packets or encapsulated in non-IP/MPLS formats. The only 1006 specific in these cases is that a protector MUST perform context- 1007 based forwarding based on the layer-2 table or corresponding lookup 1008 table which is indicated by a context ID (i.e. context label). 1010 9. Example: Layer-3 VPN egress protection 1012 This section shows an example of egress protection for a layer-3 VPN. 1014 ---------- R1 ----------- PE2 - 1015 / (PLR) (PLR) \ 1016 ( ) / | | ( ) 1017 ( ) / | | ( ) 1018 ( site 1 )-- PE1 < | R3 ( site 2 ) 1019 ( ) \ | | ( ) 1020 ( ) \ | | ( ) 1021 \ | | / 1022 ---------- R2 ----------- PE3 - 1023 (protector) 1025 Figure 5 1027 In this example, the site 1 (subnet 203.0.113.192/26) of a given VPN 1028 is attached to PE1, and site 2 (subnet 203.0.113.128/26) is dual- 1029 homed to PE2 and PE3. PE2 is the primary PE for site 2, and PE3 is 1030 the backup PE. Each PE hosts a VPN instance. R1 and R2 are transit 1031 routers in the MPLS network. The network uses OSPF as routing 1032 protocol, and RSVP-TE as tunnel signaling protocol. The PEs use BGP 1033 to exchange VPN prefixes and VPN labels between each other. 1035 Using the framework in this document, the network assigns PE3 to be a 1036 protector for PE2 to protect the VPN traffic in the direction from 1037 site 1 to site 2. This is the co-located protector mode. Hence, PE2 1038 and PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 1039 is assigned to the protected egress {PE2, PE3}. The VPN instance on 1040 PE3 serves as a protection instance for the VPN instance on PE2. On 1041 PE3, a context label 100 is assigned to the context ID, and a label 1042 table pe2.mpls is created to represent PE2's label space. PE3 1043 installs the label 100 in its default MPLS forwarding table, with 1044 nexthop pointing to the label table pe2.mpls. PE2 and PE3 are 1045 coordinated to use the proxy mode to advertise the context ID in the 1046 routing domain and the TE domain. 1048 PE2 uses per-VRF VPN label allocation mode. It assigns a single 1049 label 9000 to the VRF of the VPN. For a given VPN prefix 1050 203.0.113.128/26 in site 2, PE2 advertises it along with the label 1051 9000 and other attributes to PE1 and PE3 via BGP. In particular, the 1052 NEXT_HOP attribute is set to the context ID 198.51.100.1. 1054 Similarly, PE3 also uses per-VRF VPN label allocation mode. It 1055 assigns a single label 10000 to the VRF of the VPN. For the VPN 1056 prefix 203.0.113.128/26 in site 2, PE3 advertises it along with the 1057 label 10000 and other attributes to PE1 and PE2 via BGP. In 1058 particular, the NEXT_HOP attribute is set to an IP address of PE3. 1060 Upon receipt and acceptance of the BGP advertisement, PE1 uses the 1061 context ID 198.51.100.1 as destination to compute a TE path for an 1062 egress-protected tunnel. The resulted path is PE1->R1->PE2. PE1 1063 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1 1064 as destination, and with the "node protection desired" flag set in 1065 the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes 1066 up, PE1 maps the VPN prefix 203.0.113.128/26 to the tunnel and 1067 installs a route for the prefix in the corresponding VRF. The 1068 route's nexthop is a push with the VPN label 9000, followed by a push 1069 with the outgoing label of the egress-protected tunnel. 1071 Upon receipt of the above BGP advertisement from PE2, PE3 (i.e. the 1072 protector) recognizes the context ID 198.51.100.1 in the NEXT_HOP 1073 attribute, and installs a route for label 9000 in the label table 1074 pe2.mpls. PE3 sets the route's nexthop to a "protection VRF". This 1075 protection VRF contains IP routes corresponding to the IP prefixes in 1076 the dual-homed site 2, including 203.0.113.128/26. The nexthops of 1077 these routes MUST be based on PE3's connectivity with site 2, even if 1078 this connectivity is not the best path in PE3's VRF due to metrics 1079 (e.g. MED, local preference, etc.), and MUST NOT use any path 1080 traversing PE2. Note that the protection VRF is a logical concept, 1081 and it may simply be PE3's own VRF if the VRF satisfies the 1082 requirement. 1084 9.1. Egress node protection 1086 R1, i.e. the penultimate-hop router of the egress-protected tunnel, 1087 serves as the PLR for egress node protection. Based on the "node 1088 protection desired" flag and the destination address (i.e. context ID 1089 198.51.100.1) of the tunnel, R1 computes a bypass path to 1090 198.51.100.1 while avoiding PE2. The resulted bypass path is 1091 R1->R2->PE3. R1 then signals the path (i.e. egress-protection bypass 1092 tunnel), with 198.51.100.1 as destination. 1094 Upon receipt of an RSVP Path message of the egress-protection bypass 1095 tunnel, PE3 recognizes the context ID 198.51.100.1 as the 1096 destination, and hence responds with the context label 100 in an RSVP 1097 Resv message. 1099 After the egress-protection bypass tunnel comes up, R1 installs a 1100 bypass nexthop for the egress-protected tunnel. The bypass nexthop 1101 is a swap from the incoming label of the egress-protected tunnel to 1102 the outgoing label of the egress-protection bypass tunnel. 1104 When R1 detects a failure of PE2, it will invoke the above bypass 1105 nexthop to reroute VPN service packets. The packets will have the 1106 label of the bypass tunnel as outer label, and the VPN label 9000 as 1107 inner label. When the packets arrive at PE3, they will have the 1108 context label 100 as outer label, and the VPN label 9000 as inner 1109 label. The context label will first be popped, and then the VPN 1110 label will be looked up in the label table pe2.mpls. The lookup will 1111 cause the VPN label to be popped, and the IP packets will finally be 1112 forwarded to site 2 based on the protection VRF. 1114 9.2. Egress link protection 1116 PE2 serves as the PLR for egress link protection. It has already 1117 learned the VPN label 10000 from PE3, and hence it uses the approach 1118 (2) described in Section 6 to set up bypass forwarding state. It 1119 signals an egress-protection bypass tunnel to PE3, by using the path 1120 PE2->R3->PE3, and PE3's IP address as destination. After the bypass 1121 tunnel comes up, PE2 installs a bypass nexthop for the VPN label 1122 9000. The bypass nexthop is a label swap from the incoming label 1123 9000 to the VPN label 10000 of PE3, followed by a label push with the 1124 outgoing label of the bypass tunnel. 1126 When PE2 detects a failure of the egress link, it will invoke the 1127 above bypass nexthop to reroute VPN service packets. The packets 1128 will have the label of the bypass tunnel as outer label, and the VPN 1129 label 10000 as inner label. When the packets arrive at PE3, the VPN 1130 label 10000 will be popped, and the IP packets will be forwarded 1131 based on the VRF indicated by on the VPN label 10000. 1133 9.3. Global repair 1135 Eventually, global repair will take effect, as control plane 1136 protocols converge on the new topology. PE1 will choose PE3 as new 1137 entrance to site 2. Before that happens, the VPN traffic has been 1138 protected by the above local repair. 1140 9.4. Other modes of VPN label allocation 1142 In the above example, PE2 uses per-VRF VPN label allocation mode, and 1143 binds a common VPN label to all the VPN prefixes which it originates. 1144 When PE3 processes the VPN label in the redirected packets, it 1145 follows the nexthop of the label route in the pe2.mpls table, by 1146 popping the VPN label and performing an IP lookup in the protection 1147 VRF. 1149 It is also possible that PE2 may use per-route or per-interface VPN 1150 label allocation mode. In either case, PE3 will have multiple label 1151 routes in the pe2.mpls table, corresponding to the VPN labels 1152 advertised by PE2. PE3 may use the same nexthop as the above for all 1153 the label routes, so that PE3 will process the redirected packets by 1154 popping a VPN label and performing an IP lookup in the protection 1155 VRF. By using this universal nexthop, PE3 does not need to learn 1156 PE2's VPN label allocation mode or construct a specific nexthop for 1157 each label route in the pe2.mpls table. 1159 10. IANA Considerations 1161 This document has no request for new IANA allocation. 1163 11. Security Considerations 1165 The framework in this document relies on fast reroute around a 1166 network failure. Specifically, service traffic is temporarily 1167 rerouted from a PLR to a protector. In the centralized protector 1168 mode, the traffic is further rerouted from the protector to a backup 1169 egress router. Such kind of fast reroute is planned and anticipated, 1170 and hence it should not be viewed as a new security threat. 1172 The framework requires a service label distribution protocol to run 1173 between an egress router and a protector. The available security 1174 measures of the protocol MAY be used to achieve a secured session 1175 between the two routers. 1177 12. Acknowledgements 1179 This document leverages work done by Yakov Rekhter, Kevin Wang and 1180 Zhaohui Zhang on MPLS egress protection. Thanks to Alexander 1181 Vainshtein, Rolf Winter, Lizhong Jin, and Krzysztof Szarkowicz for 1182 their valuable comments that helped to shape this document and 1183 improve its clarity. 1185 13. References 1187 13.1. Normative References 1189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1190 Requirement Levels", BCP 14, RFC 2119, 1191 DOI 10.17487/RFC2119, March 1997, 1192 . 1194 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1195 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1196 May 2017, . 1198 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1199 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1200 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1201 July 2018, . 1203 [SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1204 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1205 Extensions for Segment Routing", draft-ietf-ospf-segment- 1206 routing-extensions (work in progress), 2017. 1208 [SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1209 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1210 Extensions for Segment Routing", draft-ietf-isis-segment- 1211 routing-extensions (work in progress), 2017. 1213 13.2. Informative References 1215 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1216 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1217 DOI 10.17487/RFC4090, May 2005, 1218 . 1220 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1221 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1222 DOI 10.17487/RFC5286, September 2008, 1223 . 1225 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1226 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 1227 RFC 7490, DOI 10.17487/RFC7490, April 2015, 1228 . 1230 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 1231 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 1232 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 1233 . 1235 [RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, 1236 "Pseudowire (PW) Endpoint Fast Failure Protection", 1237 RFC 8104, DOI 10.17487/RFC8104, March 2017, 1238 . 1240 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 1241 "Extensions to RSVP-TE for Label Switched Path (LSP) 1242 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 1243 2018, . 1245 [BGP-PIC] Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix 1246 Independent Convergence", draft-ietf-rtgwg-bgp-pic-08.txt 1247 (work in progress), 2017. 1249 Authors' Addresses 1251 Yimin Shen 1252 Juniper Networks 1253 10 Technology Park Drive 1254 Westford, MA 01886 1255 USA 1257 Phone: +1 9785890722 1258 Email: yshen@juniper.net 1260 Minto Jeyananth 1261 Juniper Networks 1262 1133 Innovation Way 1263 Sunnyvale, CA 94089 1264 USA 1266 Phone: +1 4089367563 1267 Email: minto@juniper.net 1269 Bruno Decraene 1270 Orange 1272 Email: bruno.decraene@orange.com 1274 Hannes Gredler 1275 RtBrick Inc 1277 Email: hannes@rtbrick.com 1279 Carsten Michel 1280 Deutsche Telekom 1282 Email: c.michel@telekom.de 1283 Huaimo Chen 1284 Huawei Technologies Co., Ltd. 1286 Email: huaimo.chen@huawei.com 1288 Yuanlong Jiang 1289 Huawei Technologies Co., Ltd. 1290 Bantian, Longgang district 1291 Shenzhen 518129 1292 China 1294 Email: jiangyuanlong@huawei.com