idnits 2.17.1 draft-ietf-mpls-egress-protection-framework-07.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 (July 31, 2019) is 1724 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-09 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: February 1, 2020 Bruno Decraene 6 Orange 7 Hannes Gredler 8 RtBrick Inc 9 Carsten Michel 10 Deutsche Telekom 11 Huaimo Chen 12 Huawei Technologies Co., Ltd. 13 July 31, 2019 15 MPLS Egress Protection Framework 16 draft-ietf-mpls-egress-protection-framework-07 18 Abstract 20 This document specifies a fast reroute framework for protecting IP/ 21 MPLS services and MPLS transport tunnels against egress node and 22 egress link failures. For each type of egress failure, it defines 23 the roles of point of local repair (PLR), protector, and backup 24 egress router, and the procedures of establishing a bypass tunnel 25 from a PLR to a protector. It describes the behaviors of these 26 routers in handling an egress failure, including local repair on the 27 PLR, and context-based forwarding on the protector. The framework 28 can be used to develop egress protection mechanisms to reduce traffic 29 loss before global repair reacts to an egress failure and control 30 plane protocols converge on the topology changes due to the egress 31 failure. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 1, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Specification of Requirements . . . . . . . . . . . . . . . . 5 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Egress node protection . . . . . . . . . . . . . . . . . . . 8 72 5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8 73 5.2. Egress node failure and detection . . . . . . . . . . . . 8 74 5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9 75 5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10 76 5.5. Egress-protected tunnel and service . . . . . . . . . . . 11 77 5.6. Egress-protection bypass tunnel . . . . . . . . . . . . . 11 78 5.7. Context ID, context label, and context-based forwarding . 12 79 5.8. Advertisement and path resolution for context ID . . . . 13 80 5.9. Egress-protection bypass tunnel establishment . . . . . . 15 81 5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . . 16 82 5.11. Service label distribution from egress router to 83 protector . . . . . . . . . . . . . . . . . . . . . . . . 16 84 5.12. Centralized protector mode . . . . . . . . . . . . . . . 17 85 6. Egress link protection . . . . . . . . . . . . . . . . . . . 19 86 7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 22 87 8. Operational Considerations . . . . . . . . . . . . . . . . . 22 88 9. General context-based forwarding . . . . . . . . . . . . . . 23 89 10. Example: Layer-3 VPN egress protection . . . . . . . . . . . 23 90 10.1. Egress node protection . . . . . . . . . . . . . . . . . 25 91 10.2. Egress link protection . . . . . . . . . . . . . . . . . 25 92 10.3. Global repair . . . . . . . . . . . . . . . . . . . . . 26 93 10.4. Other modes of VPN label allocation . . . . . . . . . . 26 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 95 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 96 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 99 14.2. Informative References . . . . . . . . . . . . . . . . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 102 1. Introduction 104 In MPLS networks, label switched paths (LSPs) are widely used as 105 transport tunnels to carry IP and MPLS services across MPLS domains. 106 Examples of MPLS services are layer-2 VPNs, layer-3 VPNs, 107 hierarchical LSPs, and others. In general, a tunnel may carry 108 multiple services of one or multiple types, if the tunnel satisfies 109 both individual and aggregate requirements (e.g., CoS, QoS) of these 110 services. The egress router of the tunnel hosts the service 111 instances of the services. An MPLS service instance forwards service 112 packets via an egress link to the service destination, based on a 113 service label. An IP service instance does the same based on a 114 service IP address. The egress link is often called a PE-CE 115 (provider edge - customer edge) link or attachment circuit (AC). 117 Today, local-repair-based fast reroute mechanisms ([RFC4090], 118 [RFC5286], [RFC7490], and [RFC7812]) have been widely deployed to 119 protect MPLS tunnels against transit link/node failures, with traffic 120 restoration time in the order of tens of milliseconds. Local repair 121 refers to the scenario where the router upstream to an anticipated 122 failure, a.k.a. PLR (point of local repair), pre-establishes a 123 bypass tunnel to the router downstream of the failure, a.k.a. MP 124 (merge point), pre-installs the forwarding state of the bypass tunnel 125 in the data plane, and uses a rapid mechanism (e.g., link layer OAM, 126 BFD, and others) to locally detect the failure in the data plane. 127 When the failure occurs, the PLR reroutes traffic through the bypass 128 tunnel to the MP, allowing the traffic to continue to flow to the 129 tunnel's egress router. 131 This document specifies a fast reroute framework for egress node and 132 egress link protection. Similar to transit link/node protection, 133 this framework also relies on a PLR to perform local failure 134 detection and local repair. In egress node protection, the PLR is 135 the penultimate-hop router of a tunnel. In egress link protection, 136 the PLR is the egress router of the tunnel. The framework further 137 uses a so-called "protector" to serve as the tailend of a bypass 138 tunnel. The protector is a router that hosts "protection service 139 instances" and has its own connectivity or paths to service 140 destinations. When a PLR does local repair, the protector performs 141 "context label switching" for rerouted MPLS service packets and 142 "context IP forwarding" for rerouted IP service packets, to allow the 143 service packets to continue to reach the service destinations. 145 This framework considers an egress node failure as a failure of a 146 tunnel, and a failure of all the services carried by the tunnel, as 147 service packets can no longer reach the service instances on the 148 egress router. Therefore, the framework addresses egress node 149 protection at both tunnel level and service level simultaneously. 150 Likewise, the framework considers an egress link failure as a failure 151 of all the services traversing the link, and addresses egress link 152 protection at the service level. 154 This framework requires that the destination (a CE or site) of a 155 service MUST be dual-homed or have dual paths to an MPLS network, via 156 two MPLS edge routers. One of the routers is the egress router of 157 the service's transport tunnel, and the other is a backup egress 158 router which hosts a "backup service instance". In the "co-located" 159 protector mode in this document, the backup egress router serves as 160 the protector, and hence the backup service instance acts as the 161 protection service instance. In the "centralized" protector mode 162 (Section 5.12), the protector and the backup egress router are 163 decoupled, and the protection service instance and the backup service 164 instance are hosted separately by the two routers. 166 The framework is described by mainly referring to P2P (point-to- 167 point) tunnels. However, it is equally applicable to P2MP (point-to- 168 multipoint), MP2P (multipoint-to-point), and MP2MP (multipoint-to- 169 multipoint) tunnels, as the sub-LSPs of these tunnels can be viewed 170 as P2P tunnels. 172 The framework is a multi-service and multi-transport framework. It 173 assumes a generic model where each service is comprised of a common 174 set of components, including a service instance, a service label, a 175 service label distribution protocol, and an MPLS transport tunnel. 176 The framework also assumes the service label to be downstream 177 assigned, i.e., assigned by an egress router. Therefore, the 178 framework is generally applicable to most existing and future 179 services. However, there are services with certain modes, where a 180 protector is unable to pre-establish forwarding state for egress 181 protection, or a PLR is not allowed to reroute traffic to other 182 routers in order to avoid traffic duplication, e.g., the broadcast, 183 multicast, and unknown unicast traffic in VPLS and EVPN. These cases 184 are left for future study. Services which use upstream-assigned 185 service labels are also out of scope of this document and left for 186 future study. 188 The framework does not require extensions for the existing signaling 189 and label distribution protocols (e.g., RSVP, LDP, BGP, etc.) of MPLS 190 tunnels. It assumes transport tunnels and bypass tunnels to be 191 established by using the generic procedures provided by the 192 protocols. On the other hand, it does not preclude extensions to the 193 protocols which may facilitate the procedures. One example of such 194 extension is [RFC8400]. The framework does see the need for 195 extensions of IGPs and service label distribution protocols in some 196 procedures, particularly for supporting protection establishment and 197 context label switching. This document provides guidelines for these 198 extensions, but leaves the specific details to separate documents. 200 The framework is intended to complement control-plane convergence and 201 global repair. Control-plane convergence relies on control protocols 202 to react on the topology changes due to a failure. Global repair 203 relies an ingress router to remotely detect a failure and switch 204 traffic to an alternative path. An example of global repair is the 205 BGP Prefix Independent Convergence mechanism [BGP-PIC] for BGP 206 established services. Compared with these mechanisms, this framework 207 is considered as faster in traffic restoration, due to the nature of 208 local failure detection and local repair. It is RECOMMENDED that the 209 framework be used in conjunction with control-plane convergence or 210 global repair, in order to take the advantages of both approaches. 211 That is, the framework provides fast and temporary repair, while 212 control-plane convergence or global repair provides ultimate and 213 permanent repair. 215 2. Specification of Requirements 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 219 document are to be interpreted as described in [RFC2119] and 220 [RFC8174]. 222 3. Terminology 224 Egress router - A router at the egress endpoint of a tunnel. It 225 hosts service instances for all the services carried by the tunnel, 226 and has connectivity with the destinations of the services. 228 Egress node failure - A failure of an egress router. 230 Egress link failure - A failure of the egress link (e.g., PE-CE link, 231 attachment circuit) of a service. 233 Egress failure - An egress node failure or an egress link failure. 235 Egress-protected tunnel - A tunnel whose egress router is protected 236 by a mechanism according to this framework. The egress router is 237 hence called a protected egress router. 239 Egress-protected service - An IP or MPLS service which is carried by 240 an egress-protected tunnel, and hence protected by a mechanism 241 according to this framework. 243 Backup egress router - Given an egress-protected tunnel and its 244 egress router, this is another router which has connectivity with all 245 or a subset of the destinations of the egress-protected services 246 carried by the egress-protected tunnel. 248 Backup service instance - A service instance which is hosted by a 249 backup egress router, and corresponding to an egress-protected 250 service on a protected egress router. 252 Protector - A role acted by a router as an alternate of a protected 253 egress router, to handle service packets in the event of an egress 254 failure. A protector may be physically co-located with or decoupled 255 from a backup egress router, depending on the co-located or 256 centralized protector mode. 258 Protection service instance - A service instance hosted by a 259 protector, corresponding to the service instance of an egress- 260 protected service on a protected egress router. A protection service 261 instance is a backup service instance, if the protector is co-located 262 with a backup egress router. 264 PLR - A router at the point of local repair. In egress node 265 protection, it is the penultimate-hop router on an egress-protected 266 tunnel. In egress link protection, it is the egress router of the 267 egress-protected tunnel. 269 Protected egress {E, P} - A virtual node consisting of an ordered 270 pair of egress router E and protector P. It serves as the virtual 271 destination of an egress-protected tunnel, and as the virtual 272 location of the egress-protected services carried by the tunnel. 274 Context identifier (ID) - A globally unique IP address assigned to a 275 protected egress {E, P}. 277 Context label - A non-reserved label assigned to a context ID by a 278 protector. 280 Egress-protection bypass tunnel - A tunnel used to reroute service 281 packets around an egress failure. 283 Co-located protector mode - The scenario where a protector and a 284 backup egress router are co-located as one router, and hence each 285 backup service instance serves as a protection service instance. 287 Centralized protector mode - The scenario where a protector is a 288 dedicated router, and is decoupled from backup egress routers. 290 Context label switching - Label switching performed by a protector, 291 in the label space of an egress router indicated by a context label. 293 Context IP forwarding - IP forwarding performed by a protector, in 294 the IP address space of an egress router indicated by a context 295 label. 297 4. Requirements 299 This document considers the following as the design requirements of 300 this egress protection framework. 302 o The framework must support P2P tunnels. It should equally support 303 P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P 304 tunnel. 306 o The framework must support multi-service and multi-transport 307 networks. It must accommodate existing and future signaling and 308 label-distribution protocols of tunnels and bypass tunnels, 309 including RSVP, LDP, BGP, IGP, segment routing, and others. It 310 must also accommodate existing and future IP/MPLS services, 311 including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and 312 others. It MUST provide a general solution for networks where 313 different types of services and tunnels co-exist. 315 o The framework must consider minimizing disruption during 316 deployment. It should only involve routers close to egress, and 317 be transparent to ingress routers and other transit routers. 319 o In egress node protection, for scalability and performance 320 reasons, a PLR must be agnostic to services and service labels. 321 It must maintain bypass tunnels and bypass forwarding state on a 322 per-transport-tunnel basis, rather than on a per-service- 323 destination or per-service-label basis. It should also support 324 bypass tunnel sharing between transport tunnels. 326 o A PLR must be able to use its local visibility or information of 327 routing or TE topology to compute or resolve a path for a bypass 328 tunnel. 330 o A protector must be able to perform context label switching for 331 rerouted MPLS service packets, based on service label(s) assigned 332 by an egress router. It must be able to perform context IP 333 forwarding for rerouted IP service packets, in the public or 334 private IP address space used by an egress router. 336 o The framework must be able to work seamlessly with transit link/ 337 node protection mechanisms to achieve end-to-end coverage. 339 o The framework must be able to work in conjunction with global 340 repair and control plane convergence. 342 5. Egress node protection 344 5.1. Reference topology 346 This document refers to the following topology when describing the 347 procedures of egress node protection. 349 services 1, ..., N 350 =====================================> tunnel 352 I ------ R1 ------- PLR --------------- E ---- 353 ingress penultimate-hop egress \ 354 | . (primary \ 355 | . service \ 356 | . instances) \ 357 | . \ 358 | . \ service 359 | . destinations 360 | . / (CEs, sites) 361 | . / 362 | . bypass / 363 | . tunnel / 364 | . / 365 | ............... / 366 R2 --------------- P ---- 367 protector 368 (protection 369 service 370 instances) 372 Figure 1 374 5.2. Egress node failure and detection 376 An egress node failure refers to the failure of an MPLS tunnel's 377 egress router. At the service level, it is also a service instance 378 failure for each IP/MPLS service carried by the tunnel. 380 An egress node failure can be detected by an adjacent router (i.e., 381 PLR in this framework) through a node liveness detection mechanism, 382 or a mechanism based on a collective failure of all the links to that 383 node. The mechanisms MUST be reasonably fast, i.e., faster than 384 control plane failure detection and remote failure detection. 385 Otherwise, local repair will not be able to provide much benefit 386 compared to control plane convergence or global repair. In general, 387 the speed, accuracy, and reliability of a failure detection mechanism 388 are the key factors to decide its applicability in egress node 389 protection. This document provides the following guidelines for 390 network operators to choose a proper type of protection on a PLR. 392 o If the PLR has a mechanism to detect and differentiate a link 393 failure (of the link between the PLR and the egress node) and an 394 egress node failure, it SHOULD set up both link protection and 395 egress node protection, and trigger one and only one protection 396 upon a corresponding failure. 398 o If the PLR has a fast mechanism to detect a link failure and an 399 egress node failure, but cannot distinguish them; or, if the PLR 400 has a fast mechanism to detect a link failure only, but not an 401 egress node failure, the PLR has two options: 403 1. It MAY set up link protection only, and leave the egress node 404 failure to be handled by global repair and control plane 405 convergence. 407 2. It MAY set up egress node protection only, and treat a link 408 failure as a trigger for the egress node protection. The 409 assumption is that treating a link failure as an egress node 410 failure MUST NOT have a negative impact on services. 411 Otherwise, it SHOULD adopt the previous option. 413 5.3. Protector and PLR 415 A router is assigned to the "protector" role to protect a tunnel and 416 the services carried by the tunnel against an egress node failure. 417 The protector is responsible for hosting a protection service 418 instance for each protected service, serving as the tailend of a 419 bypass tunnel, and performing context label switching and/or context 420 IP forwarding for rerouted service packets. 422 A tunnel is protected by only one protector. Multiple tunnels to a 423 given egress router may be protected by a common protector or 424 different protectors. A protector may protect multiple tunnels with 425 a common egress router or different egress routers. 427 For each tunnel, its penultimate-hop router acts as a PLR. The PLR 428 pre-establishes a bypass tunnel to the protector, and pre-installs 429 bypass forwarding state in the data plane. Upon detection of an 430 egress node failure, the PLR reroutes all the service packets 431 received on the tunnel though the bypass tunnel to the protector. 432 For MPLS service packets, the PLR keeps service labels intact in the 433 packets. The protector in turn forwards the service packets towards 434 the ultimate service destinations. Specifically, it performs context 435 label switching for MPLS service packets, based on the service labels 436 assigned by the protected egress router; it performs context IP 437 forwarding for IP service packets, based on their destination 438 addresses. 440 The protector MUST have its own connectivity with each service 441 destination, via a direct link or a multi-hop path, which MUST NOT 442 traverse the protected egress router or be affected by the egress 443 node failure. This also means that each service destination MUST be 444 dual-homed or have dual paths to the egress router and a backup 445 egress router which may serve as the protector. Each protection 446 service instance on the protector relies on such connectivity to set 447 up forwarding state for context label switching and context IP 448 forwarding. 450 5.4. Protected egress 452 This document introduces the notion of "protected egress" as a 453 virtual node consisting of the egress router E of a tunnel and a 454 protector P. It is denoted by an ordered pair of {E, P}, indicating 455 the primary-and-protector relationship between the two routers. It 456 serves as the virtual destination of the tunnel, and the virtual 457 location of service instances for the services carried by the tunnel. 458 The tunnel and services are considered as being "associated" with the 459 protected egress {E, P}. 461 A given egress router E may be the tailend of multiple tunnels. In 462 general, the tunnels may be protected by multiple protectors, e.g., 463 P1, P2, and so on, with each Pi protecting a subset of the tunnels. 464 Thus, these routers form multiple protected egresses, i.e., {E, P1}, 465 {E, P2}, and so on. Each tunnel is associated with one and only one 466 protected egress {E, Pi}. All the services carried by the tunnel are 467 then automatically associated with the protected egress {E, Pi}. 468 Conversely, a service associated with a protected egress {E, Pi} MUST 469 be carried by a tunnel associated with the protected egress {E, Pi}. 470 This mapping MUST be ensured by the ingress router of the tunnel and 471 the service (Section 5.5). 473 Two routers X and Y may be protectors for each other. In this case, 474 they form two distinct protected egresses {X, Y} and {Y, X}. 476 5.5. Egress-protected tunnel and service 478 A tunnel, which is associated with a protected egress {E, P}, is 479 called an egress-protected tunnel. It is associated with one and 480 only one protected egress {E, P}. Multiple egress-protected tunnels 481 may be associated with a given protected egress {E, P}. In this case, 482 they share the common egress router and protector, but may or may not 483 share a common ingress router, or a common PLR (i.e., penultimate-hop 484 router). 486 An egress-protected tunnel is considered as logically "destined" for 487 its protected egress {E, P}. Its path MUST be resolved and 488 established with E as the physical tailend. 490 A service, which is associated with a protected egress {E, P}, is 491 called an egress-protected service. The egress router E hosts the 492 primary instance of the service, and the protector P hosts the 493 protection instance of the service. 495 An egress-protected service is associated with one and only one 496 protected egress {E, P}. Multiple egress-protected services may be 497 associated with a given protected egress {E, P}. In this case, these 498 services share the common egress router and protector, but may or may 499 not be carried by a common egress-protected tunnel or a common 500 ingress router. 502 An egress-protected service MUST be mapped to an egress-protected 503 tunnel by its ingress router, based on the common protected egress 504 {E, P} of the service and the tunnel. This is achieved by 505 introducing the notion of "context ID" for protected egress {E, P}, 506 as described in (Section 5.7). 508 5.6. Egress-protection bypass tunnel 510 An egress-protected tunnel destined for a protected egress {E, P} 511 MUST have a bypass tunnel from its PLR to the protector P. This 512 bypass tunnel is called an egress-protection bypass tunnel. The 513 bypass tunnel is considered as logically "destined" for the protected 514 egress {E, P}. Due to its bypass nature, it MUST be established with 515 P as the physical tailend and E as the node to avoid. The bypass 516 tunnel MUST have the property that it MUST NOT be affected by the 517 topology change caused by an egress node failure. 519 An egress-protection bypass tunnel is associated with one and only 520 one protected egress {E, P}. A PLR may share an egress-protection 521 bypass tunnel for multiple egress-protected tunnels associated with a 522 common protected egress {E, P}. 524 5.7. Context ID, context label, and context-based forwarding 526 In this framework, a globally unique IPv4 or IPv6 address is assigned 527 to a protected egress {E, P} as the identifier of the protected 528 egress {E, P}. It is called a "context ID" due to its specific usage 529 in context label switching and context IP forwarding on the 530 protector. It is an IP address that is logically owned by both the 531 egress router and the protector. For the egress router, it indicates 532 the protector. For the protector, it indicates the egress router, 533 particularly the egress router's forwarding context. For other 534 routers in the network, it is an address reachable via both the 535 egress router and the protector (Section 5.8), similar to an anycast 536 address. 538 The main purpose of a context ID is to coordinate ingress router, 539 egress router, PLR and protector to establish egress protection. The 540 procedures are described below, given an egress-protected service 541 associated with a protected egress {E, P} with context ID. 543 o If the service is an MPLS service, when E distributes a service 544 label binding message to the ingress router, E attaches the 545 context ID to the message. If the service is an IP service, when 546 E advertises the service destination address to the ingress 547 router, E attaches the context ID to the advertisement message. 548 How the context ID is encoded in the messages is a choice of the 549 service protocol. A protocol extension of a "context ID" object 550 may be needed, if there is no existing mechanism for this purpose. 552 o The ingress router uses the service's context ID as the 553 destination to establish or resolve an egress-protected tunnel. 554 The ingress router then maps the service to the tunnel for 555 transportation. The semantics of the context ID is transparent to 556 the ingress router. The ingress router only treats the context ID 557 as an IP address of E, in the same manner as establishing or 558 resolving a regular transport tunnel. 560 o The context ID is conveyed to the PLR by the signaling protocol of 561 the egress-protected tunnel, or learned by the PLR via an IGP 562 (i.e., OSPF or ISIS) or a topology-driven label distribution 563 protocol (e.g., LDP). The PLR uses the context ID as destination 564 to establish or resolve an egress-protection bypass tunnel to P 565 while avoiding E. 567 o P maintains a dedicated label space and a dedicated IP address 568 space for E. They are referred to as "E's label space" and "E's 569 IP address space", respectively. P uses the context ID to 570 identify the label space and IP address space. 572 o If the service is an MPLS service, E also distributes the service 573 label binding message to P. This is the same label binding 574 message that E advertises to the ingress router, which includes 575 the context ID. Based on the context ID, P installs the service 576 label in an MPLS forwarding table corresponding to E's label 577 space. If the service is an IP service, P installs an IP route in 578 an IP forwarding table corresponding to E's IP address space. In 579 either case, the protection service instance on P constructs 580 forwarding state for the label route or IP route based on P's own 581 connectivity with the service's destination. 583 o P assigns a non-reserved label to the context ID. In the data 584 plane, this label represents the context ID and indicates E's 585 label space and IP address space. Therefore, it is called a 586 "context label". 588 o The PLR may establish the egress-protection bypass tunnel to P in 589 several manners. If the bypass tunnel is established by RSVP, the 590 PLR signals the bypass tunnel with the context ID as destination, 591 and P binds the context label to the bypass tunnel. If the bypass 592 tunnel is established by LDP, P advertises the context label for 593 the context ID as an IP prefix FEC. If the bypass tunnel is 594 established by the PLR in a hierarchical manner, the PLR treats 595 the context label as a one-hop LSP over a regular bypass tunnel to 596 P (e.g., a bypass tunnel to P's loopback IP address). If the 597 bypass tunnel is constructed by using segment routing, the bypass 598 tunnel is represented by a stack of SID labels with the context 599 label as the inner-most SID label (Section 5.9). In any case, the 600 bypass tunnel is a ultimate-hop-popping (UHP) tunnel whose 601 incoming label on P is the context label. 603 o During local repair, all the service packets received by P on the 604 bypass tunnel have the context label as the top label. P first 605 pops the context label. For an MPLS service packet, P further 606 looks up the service label in E's label space indicated by the 607 context label. Such kind of forwarding is called context label 608 switching. For an IP service packet, P looks up the IP 609 destination address in E's IP address space indicated by the 610 context label. Such kind of forwarding is called context IP 611 forwarding. 613 5.8. Advertisement and path resolution for context ID 615 Path resolution and computation for a context ID are done on ingress 616 routers for egress-protected tunnels, and on PLRs for egress- 617 protection bypass tunnels. Given a protected egress {E, P} and its 618 context ID, E and P MUST coordinate on the reachability of the 619 context ID in the routing domain and the TE domain. The context ID 620 MUST be advertised in such a manner that all egress-protected tunnels 621 MUST have E as tailend, and all egress-protection bypass tunnels MUST 622 have P as tailend while avoiding E. 624 This document suggests three approaches: 626 1. The first approach is called "proxy mode". It requires E and P, 627 but not the PLR, to have the knowledge of the egress protection 628 schema. E and P advertise the context ID as a virtual proxy node 629 (i.e., a logical node) connected to the two routers, with the 630 link between the proxy node and E having more preferable IGP and 631 TE metrics than the link between the proxy node and P. 632 Therefore, all egress-protected tunnels destined for the context 633 ID will automatically follow the IGP or TE paths to E. Each PLR 634 will no longer view itself as a penultimate-hop, but rather two 635 hops away from the proxy node, via E. The PLR will be able to 636 find a bypass path via P to the proxy node, while the bypass 637 tunnel is actually be terminated by P. 639 2. The second approach is called "alias mode". It requires P and 640 the PLR, but not E, to have the knowledge of the egress 641 protection schema. E simply advertises the context ID as an IP 642 address. P advertises the context ID and the context label by 643 using a "context ID label binding" advertisement. In both 644 routing domain and TE domain, the context ID is only reachable 645 via E. Therefore, all egress-protected tunnels destined for the 646 context ID will have E as tailend. Based on the "context ID 647 label binding" advertisement, the PLR can establish an egress- 648 protection bypass tunnel in several manners (Section 5.9). The 649 "context ID label binding" advertisement is defined as IGP 650 mirroring context segment in [RFC8402] and [SR-ISIS]. These IGP 651 extensions are generic in nature, and hence can be used for 652 egress protection purposes. It is RECOMMENDED that a similar 653 advertisement be defined for OSPF as well. 655 3. The third approach is called "stub link mode". In this mode, 656 both E and P advertise the context ID as a link to a stub 657 network, essentially modelling the context ID as an anycast IP 658 address owned by the two routers. E, P and the PLR do not need 659 to have the knowledge of the egress protection schema. The 660 correctness of the egress-protected tunnels and the bypass 661 tunnels relies on the path computations for the anycast IP 662 address performed by the ingress routers and PLR. Therefore, 663 care MUST be taken for the applicability of this approach to a 664 network. 666 This framework considers the above approaches as technically equal, 667 and the feasibility of each approach in a given network as dependent 668 on the topology, manageability, and available protocols of the 669 network. For a given context ID, all relevant routers, including 670 primary PE, protector, and PLR, MUST support and agree on the chosen 671 approach. The coordination between these routers can be achieved by 672 configuration. 674 In a scenario where an egress-protected tunnel is an inter-area or 675 inter-AS tunnel, its associated context ID MUST be propagated by IGP 676 or BGP from the original area or AS to the area or AS of the ingress 677 router. The propagation process of the context ID SHOULD be the same 678 as that of an IP address in an inter-area or inter-AS environment. 680 5.9. Egress-protection bypass tunnel establishment 682 A PLR MUST know the context ID of a protected egress {E, P} in order 683 to establish an egress-protection bypass tunnel. The information is 684 obtained from the signaling or label distribution protocol of the 685 egress-protected tunnel. The PLR may or may not need to have the 686 knowledge of the egress protection schema. All it does is to set up 687 a bypass tunnel to a context ID while avoiding the next-hop router 688 (i.e., egress router). This is achievable by using a constraint- 689 based computation algorithm similar to those commonly used for 690 traffic engineering paths and loop-free alternate (LFA) paths. Since 691 the context ID is advertised in the routing domain and the TE domain 692 by IGP according to Section 5.8, the PLR is able to resolve or 693 establish such a bypass path with the protector as tailend. In the 694 case of proxy mode, the PLR may do so in the same manner as transit 695 node protection. 697 An egress-protection bypass tunnel may be established via several 698 methods: 700 (1) It may be established by a signaling protocol (e.g., RSVP), with 701 the context ID as destination. The protector binds the context label 702 to the bypass tunnel. 704 (2) It may be formed by a topology driven protocol (e.g., LDP with 705 various LFA mechanisms). The protector advertises the context ID as 706 an IP prefix FEC, with the context label bound to it. 708 (3) It may be constructed as a hierarchical tunnel. When the 709 protector uses the alias mode (Section 5.8), the PLR will have the 710 knowledge of the context ID, context label, and protector (i.e., the 711 advertiser). The PLR can then establish the bypass tunnel in a 712 hierarchical manner, with the context label as a one-hop LSP over a 713 regular bypass tunnel to the protector's IP address (e.g., loopback 714 address). This regular bypass tunnel may be established by RSVP, 715 LDP, segment routing, or another protocol. 717 5.10. Local repair on PLR 719 In this framework, a PLR is agnostic to services and service labels. 720 This obviates the need to maintain bypass forwarding state on a per- 721 service basis, and allows bypass tunnel sharing between egress- 722 protected tunnels. The PLR may share an egress-protection bypass 723 tunnel for multiple egress-protected tunnels associated with a common 724 protected egress {E, P}. During local repair, the PLR reroutes all 725 service packets received on the egress-protected tunnels to the 726 egress-protection bypass tunnel. Service labels remain intact in 727 MPLS service packets. 729 Label operation performed by the PLR depends on the bypass tunnel's 730 characteristics. If the bypass tunnel is a single level tunnel, the 731 rerouting will involve swapping the incoming label of an egress- 732 protected tunnel to the outgoing label of the bypass tunnel. If the 733 bypass tunnel is a hierarchical tunnel, the rerouting will involve 734 swapping the incoming label of an egress-protected tunnel to a 735 context label, and pushing the outgoing label of a regular bypass 736 tunnel. If the bypass tunnel is constructed by segment routing, the 737 rerouting will involve swapping the incoming label of an egress- 738 protected tunnel to a context label, and pushing the stack of SID 739 labels of the bypass tunnel. 741 5.11. Service label distribution from egress router to protector 743 When a protector receives a rerouted MPLS service packet, it performs 744 context label switching based on the packet's service label which is 745 assigned by the corresponding egress router. In order to achieve 746 this, the protector MUST maintain the labels of egress-protected 747 services in dedicated label spaces on a per protected egress {E, P} 748 basis, i.e., one label space for each egress router that it protects. 750 Also, there MUST be a service label distribution protocol session 751 between each egress router and the protector. Through this protocol, 752 the protector learns the label binding of each egress-protected 753 service. This is the same label binding that the egress router 754 advertises to the service's ingress router, which includes a context 755 ID. The corresponding protection service instance on the protector 756 recognizes the service, and resolves forwarding state based on its 757 own connectivity with the service's destination. It then installs 758 the service label with the forwarding state in the label space of the 759 egress router, which is indicated by the context ID (i.e., context 760 label). 762 Different service protocols may use different mechanisms for such 763 kind of label distribution. Specific extensions may be needed on a 764 per-protocol basis or per-service-type basis. The details of the 765 extensions should be specified in separate documents. As an example, 766 [RFC8104] specifies the LDP extensions for pseudowire services. 768 5.12. Centralized protector mode 770 In this framework, it is assumed that the service destination of an 771 egress-protected service MUST be dual-homed to two edge routers of an 772 MPLS network. One of them is the protected egress router, and the 773 other is a backup egress router. So far in this document, the 774 discussion has been focusing on the scenario where a protector and a 775 backup egress router are co-located as one router. Therefore, the 776 number of protectors in a network is equal to the number of backup 777 egress routers. As another scenario, a network may assign a small 778 number of routers to serve as dedicated protectors, each protecting a 779 subset of egress routers. These protectors are called centralized 780 protectors. 782 Topologically, a centralized protector may be decoupled from all 783 backup egress routers, or it may be co-located with one backup egress 784 router while decoupled from the other backup egress routers. The 785 procedures in this section assume that a protector and a backup 786 egress router are decoupled. 788 services 1, ..., N 789 =====================================> tunnel 791 I ------ R1 ------- PLR --------------- E ---- 792 ingress penultimate-hop egress \ 793 | . (primary \ 794 | . service \ 795 | . instances) \ 796 | . \ 797 | . bypass \ service 798 R2 . tunnel destinations 799 | . / (CEs, sites) 800 | . / 801 | . / 802 | . / 803 | . tunnel / 804 | =============> / 805 P ---------------- E' --- 806 protector backup egress 807 (protection (backup 808 service service 809 instances) instances) 811 Figure 2 813 Like a co-located protector, a centralized protector hosts protection 814 service instances, receives rerouted service packets from PLRs, and 815 performs context label switching and/or context IP forwarding. For 816 each service, instead of sending service packets directly to the 817 service destination, the protector MUST send them via another 818 transport tunnel to the corresponding backup service instance on a 819 backup egress router. The backup service instance in turn forwards 820 the service packets to the service destination. Specifically, if the 821 service is an MPLS service, the protector MUST swap the service label 822 in each received service packet to the label of the backup service 823 advertised by the backup egress router, and then push the label (or 824 label stack) of the transport tunnel. 826 In order for a centralized protector to map an egress-protected MPLS 827 service to a service hosted on a backup egress router, there MUST be 828 a service label distribution protocol session between the backup 829 egress router and the protector. Through this session, the backup 830 egress router advertises the service label of the backup service, 831 attached with the FEC of the egress-protected service and the context 832 ID of the protected egress {E, P}. Based on this information, the 833 protector associates the egress-protected service with the backup 834 service, resolves or establishes a transport tunnel to the backup 835 egress router, and sets up forwarding state for the label of the 836 egress-protected service in the label space of the egress router. 838 The service label which the backup egress router advertises to the 839 protector can be the same as the label which the backup egress router 840 advertises to the ingress router(s), if and only if the forwarding 841 state of the label does not direct service packets towards the 842 protected egress router. Otherwise, the label MUST NOT be used for 843 egress protection, because it would create a loop for the service 844 packets. In this case, the backup egress router MUST advertise a 845 unique service label for egress protection, and set up the forwarding 846 state of the label to use the backup egress router's own connectivity 847 with the service destination. 849 6. Egress link protection 851 Egress link protection is achievable through procedures similar to 852 that of egress node protection. In normal situations, an egress 853 router forwards service packets to a service destination based on a 854 service label, whose forwarding state points to an egress link. In 855 egress link protection, the egress router acts as the PLR, and 856 performs local failure detection and local repair. Specifically, the 857 egress router pre-establishes an egress-protection bypass tunnel to a 858 protector, and sets up the bypass forwarding state for the service 859 label to point to the bypass tunnel. During local repair, the egress 860 router reroutes service packets via the bypass tunnel to the 861 protector. The protector in turn forwards the packets to the service 862 destination (in the co-located protector mode, as shown in Figure 3), 863 or forwards the packets to a backup egress router (in the centralized 864 protector mode, as shown 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 allocated 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. 925 (1) The first approach applies when the egress router does not 926 know the service label allocated 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 protected egress {E, P} and established 933 as described in Section 5.9. This approach is consistent with 934 egress node protection. Hence, a protector can serve in egress 935 node protection and egress link protection in a consistent manner, 936 and both the co-located protector mode and the centralized 937 protector mode are supported (Figure 3 and Figure 4). 939 (2) The second approach applies when the egress router knows the 940 service label allocated by the backup egress router, 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 will 944 be the same router in the co-located protector mode but a 945 different router in the centralized protector mode. The egress 946 router sets up the bypass forwarding state as a label swap from 947 the incoming service label to the service label of the backup 948 egress router (i.e., protector), followed by a push with the 949 outgoing label (or label stack) of the egress link protection 950 bypass tunnel. The bypass tunnel is a regular tunnel destined for 951 an IP address of the protector, instead of the context ID of the 952 protected egress {E, P}. The protector simply forwards rerouted 953 service packets based on its own service label, rather than 954 performing context label switching. In this approach, only the 955 co-located protector mode is applicable. 957 Note that for a bidirectional service, the physical link of an egress 958 link may carry service traffic bi-directionally. Therefore, an 959 egress link failure may simultaneously be an ingress link failure for 960 the traffic in the opposite direction. Protection for ingress link 961 failure SHOULD be provided by a separate mechanism, and hence is out 962 of the scope of this document. 964 7. Global repair 966 This framework provides a fast but temporary repair for egress node 967 and egress link failures. For permanent repair, the services 968 affected by a failure SHOULD be moved to an alternative tunnel, or 969 replaced by alternative services, which are fully functional. This 970 is referred to as global repair. Possible triggers of global repair 971 include control plane notifications of tunnel status and service 972 status, end-to-end OAM and fault detection at tunnel and service 973 level, and others. The alternative tunnel and services may be pre- 974 established in standby state, or dynamically established as a result 975 of the triggers or network protocol convergence. 977 8. Operational Considerations 979 When a PLR performs local repair, the router SHOULD generate an alert 980 for the event. The alert may be logged locally for tracking 981 purposes, or it may be sent to the operator at a management station. 982 The communication channel and protocol between the PLR and the 983 management station may vary depending on networks, and are out of the 984 scope of this document. 986 9. General context-based forwarding 988 So far, this document has been focusing on the cases where service 989 packets are MPLS or IP packets and protectors perform context label 990 switching or context IP forwarding. Although this should cover most 991 common services, it is worth mentioning that the framework is also 992 applicable to services or sub-modes of services where service packets 993 are layer-2 packets or encapsulated in non-IP/MPLS formats. The only 994 specific in these cases is that a protector MUST perform context- 995 based forwarding based on the layer-2 table or corresponding lookup 996 table which is indicated by a context ID (i.e., context label). 998 10. Example: Layer-3 VPN egress protection 1000 This section shows an example of egress protection for layer-3 IPv4 1001 and IPv6 VPNs. 1003 ---------- R1 ----------- PE2 - 1004 / (PLR) (PLR) \ 1005 ( ) / | | ( ) 1006 ( ) / | | ( ) 1007 ( site 1 )-- PE1 < | R3 ( site 2 ) 1008 ( ) \ | | ( ) 1009 ( ) \ | | ( ) 1010 \ | | / 1011 ---------- R2 ----------- PE3 - 1012 (protector) 1014 Figure 5 1016 In this example, the core network is IPv4 and MPLS. Both of the IPv4 1017 VPN and the IPv6 VPN consist of site 1 and site 2. Site 1 is 1018 connected to PE1, and site 2 is dual-homed to PE2 and PE3. Site 1 1019 includes an IPv4 subnet 203.0.113.64/26 and an IPv6 subnet 1020 2001:db8:1:1::/64. Site 2 includes an IPv4 subnet 203.0.113.128/26 1021 and an IPv6 subnet 2001:db8:1:2::/64. PE2 is the primary PE for site 1022 2, and PE3 is the backup PE. Each of PE1, PE2 and PE3 hosts an IPv4 1023 VPN instance and an IPv6 VPN instance. The PEs use BGP to exchange 1024 VPN prefixes and VPN labels between each other. In the core network, 1025 R1 and R2 are transit routers, OSPF is used as the routing protocol, 1026 and RSVP-TE as the tunnel signaling protocol. 1028 Using the framework in this document, the network assigns PE3 to be 1029 the protector of PE2 to protect the VPN traffic in the direction from 1030 site 1 to site 2. This is the co-located protector mode. PE2 and 1031 PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 is 1032 assigned to the protected egress {PE2, PE3}. (If the core network is 1033 IPv6, the context ID would be an IPv6 address.) The IPv4 and IPv6 1034 VPN instances on PE3 serve as protection instances for the 1035 corresponding VPN instances on PE2. On PE3, a context label 100 is 1036 assigned to the context ID, and a label table pe2.mpls is created to 1037 represent PE2's label space. PE3 installs label 100 in its MPLS 1038 forwarding table, with nexthop pointing to the label table pe2.mpls. 1039 PE2 and PE3 are coordinated to use the proxy mode to advertise the 1040 context ID in the routing domain and the TE domain. 1042 PE2 uses per-VRF label allocation mode for both of its IPv4 and IPv6 1043 VPN instances. It assigns label 9000 to the IPv4 VRF, and label 9001 1044 to the IPv6 VRF. For the IPv4 prefix 203.0.113.128/26 in site 2, PE2 1045 advertises it with label 9000 and NEXT_HOP 198.51.100.1 to PE1 and 1046 PE3 via BGP. Likewise, for the IPv6 prefix 2001:db8:1:2::/64 in site 1047 2, PE2 advertises it with label 9001 and NEXT_HOP 198.51.100.1 to PE1 1048 and PE3 via BGP. 1050 PE3 also uses per-VRF VPN label allocation mode for both of its IPv4 1051 and IPv6 VPN instances. It assigns label 10000 to the IPv4 VRF, and 1052 label 10001 to the IPv6 VRF. For the prefix 203.0.113.128/26 in site 1053 2, PE3 advertises it with label 10000 and NEXT_HOP as itself to PE1 1054 and PE2 via BGP. For the IPv6 prefix 2001:db8:1:2::/64 in site 2, 1055 PE3 advertises it with label 10001 and NEXT_HOP as itself to PE1 and 1056 PE2 via BGP. 1058 Upon receipt of the above BGP advertisements from PE2, PE1 uses the 1059 context ID 198.51.100.1 as destination to compute a path for an 1060 egress-protected tunnel. The resultant path is PE1->R1->PE2. PE1 1061 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1 1062 as destination, and with the "node protection desired" flag set in 1063 the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes 1064 up, PE1 maps the VPN prefixes 203.0.113.128/26 and 2001:db8:1:2::/64 1065 to the tunnel, and installs a route for each prefix in the 1066 corresponding IPv4 or IPv6 VRF. The nexthop of the route 1067 203.0.113.128/26 is a push of the VPN label 9000, followed by a push 1068 of the outgoing label of the egress-protected tunnel. The nexthop of 1069 the route 2001:db8:1:2::/64 is a push of the VPN label 9001, followed 1070 by a push of the outgoing label of the egress-protected tunnel. 1072 Upon receipt of the above BGP advertisements from PE2, PE3 recognizes 1073 the context ID 198.51.100.1 in the NEXT_HOP attribute, and installs a 1074 route for label 9000 and a route for label 9001 in the label table 1075 pe2.mpls. PE3 sets the nexthop of the route 9000 to the IPv4 1076 protection VRF, and the nexthop of the route 9001 to the IPv6 1077 protection VRF. The IPv4 protection VRF contains the routes to the 1078 IPv4 prefixes in site 2. The IPv6 protection VRF contains the routes 1079 to the IPv6 prefixes in site 2. The nexthops of these routes must be 1080 based on PE3's connectivity with site 2, even if the connectivity may 1081 not have the best metrics (e.g., MED, local preference, etc.) to be 1082 used in PE3's own VRF. The nexthops must not use any path traversing 1083 PE2. Note that the protection VRFs are a logical concept, and they 1084 may simply be PE3's own VRFs if they satisfies the requirement. 1086 10.1. Egress node protection 1088 R1, i.e., the penultimate-hop router of the egress-protected tunnel, 1089 serves as the PLR for egress node protection. Based on the "node 1090 protection desired" flag and the destination address (i.e., context 1091 ID 198.51.100.1) of the tunnel, R1 computes a bypass path to 1092 198.51.100.1 while avoiding PE2. The resultant bypass path is 1093 R1->R2->PE3. R1 then signals the path (i.e., egress-protection 1094 bypass tunnel), with 198.51.100.1 as destination. 1096 Upon receipt of an RSVP Path message of the egress-protection bypass 1097 tunnel, PE3 recognizes the context ID 198.51.100.1 as the 1098 destination, and responds with the context label 100 in an RSVP Resv 1099 message. 1101 After the egress-protection bypass tunnel comes up, R1 installs a 1102 bypass nexthop for the egress-protected tunnel. The bypass nexthop 1103 is a label swap from the incoming label of the egress-protected 1104 tunnel to the outgoing label of the egress-protection bypass tunnel. 1106 When R1 detects a failure of PE2, it will invoke the above bypass 1107 nexthop to reroute VPN packets. Each IPv4 VPN packet will have the 1108 label of the bypass tunnel as outer label, and the IPv4 VPN label 1109 9000 as inner label. Each IPv6 VPN packets will have the label of 1110 the bypass tunnel as outer label, and the IPv6 VPN label 9001 as 1111 inner label. When the packets arrive at PE3, they will have the 1112 context label 100 as outer label, and the VPN label 9000 or 9001 as 1113 inner label. The context label will first be popped, and then the 1114 VPN label will be looked up in the label table pe2.mpls. The lookup 1115 will cause the VPN label to be popped, and the IPv4 and IPv6 packets 1116 to be forwarded to site 2 based on the IPv4 and IPv6 protection VRFs, 1117 respectively. 1119 10.2. Egress link protection 1121 PE2 serves as the PLR for egress link protection. It has already 1122 learned PE3's IPv4 VPN label 10000 and IPv6 VPN label 10001. Hence 1123 it uses the approach (2) described in Section 6 to set up bypass 1124 forwarding state. It signals an egress-protection bypass tunnel to 1125 PE3, by using the path PE2->R3->PE3, and PE3's IP address as 1126 destination. After the bypass tunnel comes up, PE2 installs a bypass 1127 nexthop for the IPv4 VPN label 9000, and a bypass nexthop for the 1128 IPv6 VPN label 9001. For label 9000, the bypass nexthop is a label 1129 swap to label 10000, followed by a label push with the outgoing label 1130 of the bypass tunnel. For label 9001, the bypass nexthop is a label 1131 swap to label 10001, followed by a label push with the outgoing label 1132 of the bypass tunnel. 1134 When PE2 detects a failure of the egress link, it will invoke the 1135 above bypass nexthop to reroute VPN packets. Each IPv4 VPN packet 1136 will have the label of the bypass tunnel as outer label, and label 1137 10000 as inner label. Each IPv6 VPN packet will have the label of 1138 the bypass tunnel as outer label, and label 10001 as inner label. 1139 When the packets arrive at PE3, the VPN label 10000 or 10001 will be 1140 popped, and the exposed IPv4 and IPv6 packets will be forwarded based 1141 on PE3's IPv4 and IPv6 VRFs, respectively. 1143 10.3. Global repair 1145 Eventually, global repair will take effect, as control plane 1146 protocols converge on the new topology. PE1 will choose PE3 as a new 1147 entrance to site 2. Before that happens, the VPN traffic has been 1148 protected by the above local repair. 1150 10.4. Other modes of VPN label allocation 1152 It is also possible that PE2 may use per-route or per-interface VPN 1153 label allocation mode. In either case, PE3 will have multiple VPN 1154 label routes in the pe2.mpls table, corresponding to the VPN labels 1155 advertised by PE2. PE3 forwards rerouted packets by popping a VPN 1156 label and performing an IP lookup in the corresponding protection 1157 VRF. PE3's forwarding behavior is consistent with the above case 1158 where PE2 uses per-VRF VPN label allocation mode. PE3 does not need 1159 to know PE2's VPN label allocation mode, or construct a specific 1160 nexthop for each VPN label route in the pe2.mpls table. 1162 11. IANA Considerations 1164 This document has no request for new IANA allocation. 1166 12. Security Considerations 1168 The framework in this document involves rerouting traffic around an 1169 egress node or link failure, via a bypass path from a PLR to a 1170 protector, and ultimately to a backup egress router. The forwarding 1171 performed by the routers in the data plane is anticipated, as part of 1172 the planning of egress protection. 1174 Control plane protocols MAY be used to facilitate the provisioning of 1175 the egress protection on the routers. In particular, the framework 1176 requires a service label distribution protocol between an egress 1177 router and a protector over a secure session. The security 1178 properties of this provisioning and label distribution depend 1179 entirely on the underlying protocol chosen to implement these 1180 activities . Their associated security considerations apply. This 1181 framework introduces no new security requirements or guarantees 1182 relative to these activities. 1184 Also, the PLR, protector, and backup egress router are located close 1185 to the protected egress router, and normally in the same 1186 administrative domain. If they are not in the same administrative 1187 domain, a certain level of trust MUST be established between them in 1188 order for the protocols to run securely across the domain boundary. 1189 The basis of this trust is the security model of the protocols (as 1190 described above), and further security considerations for inter- 1191 domain scenarios should be addressed by the protocols as a common 1192 requirement. 1194 Security attacks may sometimes come from a customer domain. Such 1195 kind of attacks are not introduced by the framework in this document, 1196 and may occur regardless of the existence of egress protection. In 1197 one possible case, the egress link between an egress router and a CE 1198 could become a point of attack. An attacker that gains control of 1199 the CE might use it to simulate link failures and trigger constant 1200 and cascading activities in the network. If egress link protection 1201 is in place, egress link protection activities may also be triggered. 1202 As a general solution to defeat the attack, a damping mechanism 1203 SHOULD be used by the egress router to promptly suppress the services 1204 associated with the link or CE. The egress router would stop 1205 advertising the services, essentially detaching them from the network 1206 and eliminating the effect of the simulated link failures. 1208 From the above perspectives, this framework does not introduce any 1209 new security threat to networks. 1211 13. Acknowledgements 1213 This document leverages work done by Yakov Rekhter, Kevin Wang and 1214 Zhaohui Zhang on MPLS egress protection. Thanks to Alexander 1215 Vainshtein, Rolf Winter, Lizhong Jin, Krzysztof Szarkowicz, Roman 1216 Danyliw, and Yuanlong Jiang for their valuable comments that helped 1217 to shape this document and improve its clarity. 1219 14. References 1221 14.1. Normative References 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, 1225 DOI 10.17487/RFC2119, March 1997, 1226 . 1228 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1229 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1230 May 2017, . 1232 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1233 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1234 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1235 July 2018, . 1237 [SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1238 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1239 Extensions for Segment Routing", draft-ietf-isis-segment- 1240 routing-extensions (work in progress), 2017. 1242 14.2. Informative References 1244 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1245 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1246 DOI 10.17487/RFC4090, May 2005, 1247 . 1249 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1250 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1251 DOI 10.17487/RFC5286, September 2008, 1252 . 1254 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1255 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 1256 RFC 7490, DOI 10.17487/RFC7490, April 2015, 1257 . 1259 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 1260 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 1261 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 1262 . 1264 [RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, 1265 "Pseudowire (PW) Endpoint Fast Failure Protection", 1266 RFC 8104, DOI 10.17487/RFC8104, March 2017, 1267 . 1269 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 1270 "Extensions to RSVP-TE for Label Switched Path (LSP) 1271 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 1272 2018, . 1274 [BGP-PIC] Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix 1275 Independent Convergence", draft-ietf-rtgwg-bgp-pic-09.txt 1276 (work in progress), 2017. 1278 Authors' Addresses 1280 Yimin Shen 1281 Juniper Networks 1282 10 Technology Park Drive 1283 Westford, MA 01886 1284 USA 1286 Phone: +1 9785890722 1287 Email: yshen@juniper.net 1289 Minto Jeyananth 1290 Juniper Networks 1291 1133 Innovation Way 1292 Sunnyvale, CA 94089 1293 USA 1295 Phone: +1 4089367563 1296 Email: minto@juniper.net 1298 Bruno Decraene 1299 Orange 1301 Email: bruno.decraene@orange.com 1303 Hannes Gredler 1304 RtBrick Inc 1306 Email: hannes@rtbrick.com 1307 Carsten Michel 1308 Deutsche Telekom 1310 Email: c.michel@telekom.de 1312 Huaimo Chen 1313 Huawei Technologies Co., Ltd. 1315 Email: huaimo.chen@huawei.com