idnits 2.17.1 draft-shen-mpls-egress-protection-framework-05.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 : ---------------------------------------------------------------------------- == There are 13 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 31, 2017) is 2432 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RSVP-EP' is mentioned on line 188, but not defined -- Looks like a reference, but probably isn't: '1' on line 904 -- Looks like a reference, but probably isn't: '2' on line 1033 -- Looks like a reference, but probably isn't: '3' on line 645 -- Looks like a reference, but probably isn't: '4' on line 654 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). 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, 2018 Bruno Decraene 6 Orange 7 Hannes Gredler 8 RtBrick Inc 9 Carsten Michel 10 Deutsche Telekom 11 Huaimo Chen 12 Yuanlong Jiang 13 Huawei Technologies Co., Ltd. 14 July 31, 2017 16 MPLS Egress Protection Framework 17 draft-shen-mpls-egress-protection-framework-05 19 Abstract 21 This document specifies a fast reroute framework for protecting IP/ 22 MPLS services and MPLS transport tunnels against egress node and 23 egress link failures. In this framework, the penultimate-hop router 24 of an MPLS tunnel acts as the point of local repair (PLR) for egress 25 node failure, and the egress router of the MPLS tunnel acts as the 26 PLR for egress link failure. Each of them pre-establishes a bypass 27 tunnel to a protector. Upon an egress node or link failure, the 28 corresponding PLR performs local failure detection and local repair, 29 by rerouting packets over the corresponding bypass tunnel. The 30 protector in turn performs context label switching or context IP 31 forwarding to send the packets to ultimate service destination(s). 32 This mechanism can be used to reduce traffic loss before global 33 repair reacts to the failure and control plane protocols converge on 34 the topology changes due to the failure. The framework is applicable 35 to all types of IP/MPLS services and MPLS tunnels. Under the 36 framework, service protocol extensions may be further specified to 37 support service label distribution to protector. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on February 1, 2018. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Specification of Requirements . . . . . . . . . . . . . . . . 5 75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5. Egress node protection . . . . . . . . . . . . . . . . . . . 8 78 5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8 79 5.2. Egress node failure . . . . . . . . . . . . . . . . . . . 8 80 5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9 81 5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 9 82 5.5. Egress-protected tunnel . . . . . . . . . . . . . . . . . 10 83 5.6. Egress-protected service . . . . . . . . . . . . . . . . 10 84 5.7. Egress-protected service to egress-protected tunnel 85 mapping . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 5.8. Egress-protection bypass tunnel . . . . . . . . . . . . . 11 87 5.9. Context ID, context label, and context based forwarding . 11 88 5.10. IGP advertisement and path resolution for context ID . . 13 89 5.11. Egress-protection bypass tunnel establishment . . . . . . 14 90 5.12. Local Repair on PLR . . . . . . . . . . . . . . . . . . . 15 91 5.13. Service label distribution from egress router to 92 protector . . . . . . . . . . . . . . . . . . . . . . . . 15 93 5.14. Centralized protector mode . . . . . . . . . . . . . . . 16 94 6. Egress link protection . . . . . . . . . . . . . . . . . . . 18 95 7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 21 96 8. Example: Layer-3 VPN egress protection . . . . . . . . . . . 22 97 8.1. Egress node protection . . . . . . . . . . . . . . . . . 23 98 8.2. Egress link protection . . . . . . . . . . . . . . . . . 24 99 8.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 24 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 102 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 105 12.2. Informative References . . . . . . . . . . . . . . . . . 25 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 108 1. Introduction 110 In MPLS networks, LSPs (label switched paths) 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, given that the tunnel can 115 satisfy both individual and aggregate requirements (e.g. CoS, QoS) 116 of these services. The egress router of the tunnel must host the 117 corresponding service instances of the services. An MPLS service 118 instance is responsible for forwarding service packets via an egress 119 link to the service destination, based on a service label. An IP 120 service instance is responsible for forwarding service packets via an 121 egress link to the service destination, based on IP destination 122 address. The egress link is often called a PE-CE (provider edge - 123 customer edge) link or attachment circuit (AC). 125 Today, local repair based fast reroute mechanisms [RFC4090], 126 [RFC5286], [RFC7490], [RFC7812] have been widely deployed to protect 127 MPLS tunnels against transit link/node failures. They can achieve 128 fast restoration of traffic in the order of tens of milliseconds. 129 Local repair refers to the scenario where the router (aka. PLR, i.e. 130 point of local repair) upstream adjacent to an anticipated failure 131 pre-establishes a bypass tunnel to the router (aka. MP, i.e. merge 132 point) downstream of the failure, and pre-installs the forwarding 133 state of the bypass tunnel in the data plane. The PLR also uses a 134 rapid mechanism (e.g. link layer OAM, BFD, and others) to locally 135 detect the failure in the data plane. When the failure occurs, the 136 PLR reroutes traffic through the bypass tunnel to the MP, allowing 137 the traffic to continue to flow to the tunnel's egress router. 139 This document describes a fast reroute framework for egress node and 140 egress link protection. Similar to transit link/node protection, 141 this framework relies on a PLR to perform local failure detection and 142 local repair. In egress node protection, the PLR is the penultimate- 143 hop router of a tunnel. In egress link protection, the PLR is the 144 egress router of the tunnel. The framework relies on a so-called 145 "protector" to serve as the tailend of bypass tunnels. The protector 146 is a router that hosts some "protection service instances" and has 147 its own connectivity or paths to service destinations. When a PLR 148 does local repair, the protector is responsible for performing 149 "context label switching" for rerouted MPLS service packets and 150 "context IP forwarding" for rerouted IP service packets. Thus, the 151 service packets can continue to reach service destinations with 152 minimum disruption. 154 This framework considers an egress node failure as a failure of a 155 tunnel, as well as a failure of all the services carried by the 156 tunnel, because service packets can no longer reach the service 157 instances on the egress router. Therefore, the framework addresses 158 egress node protection at both tunnel level and service level 159 simultaneously. Likewise, the framework considers an egress link 160 failure as a failure of all the services traversing the link, and 161 addresses egress link protection at service level. 163 This framework requires that the destination (a CE or site) of a 164 service must be dual-homed or have dual paths to an MPLS network, 165 normally via two MPLS edge routers. One of them is the egress router 166 of the service's transport tunnel, and the other is a backup egress 167 router. In the "co-located" protector mode in this document, the 168 backup egress router serves as a protector, and each service instance 169 hosted on the router acts as a protection instance. In the 170 "centralized" protector mode (Section 5.14), a protector and a backup 171 egress router may be decoupled, and each service instance on the 172 backup egress router is simply considered as a "backup service 173 instance". 175 The framework is described by mainly referring to P2P (point-to- 176 point) tunnels. However, it is equally applicable to P2MP (point-to- 177 multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to- 178 multipoint) tunnels, when a sub-LSP can be viewed as a P2P tunnel. 180 The framework is a multi-service and multi-transport framework. It 181 is applicable to all existing and future types of MPLS tunnels and 182 IP/MPLS services. It does not require extensions for the existing 183 signaling and label distribution protocols (e.g. RSVP, LDP, BGP, 184 etc.) of MPLS tunnels, because transport tunnels and bypass tunnels 185 are expected to be established by using the generic mechanisms 186 provided by the protocols. However, the framework does not preclude 187 future extensions to the protocols which may facilitate the 188 procedures. One example of such extension is [RSVP-EP]. The 189 framework may need extensions for IGPs and service label distribution 190 protocols, to support protection establishment and context label 191 switching. This document provides guidelines for these extensions, 192 but the specific details should be addressed in separate documents. 194 2. Specification of Requirements 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in RFC2119. 200 3. Terminology 202 Egress router - A router at the egress endpoint of a tunnel. It 203 hosts service instances for all the services carried by the tunnel, 204 and has connectivity with the destinations of the services. 206 Egress node failure - A node failure of an egress router. 208 Egress link failure - A failure of the egress link (e.g. PE-CE link, 209 attachment circuit) of a service. 211 Egress failure - An egress node failure or an egress link failure. 213 Egress-protected tunnel - A tunnel whose egress router is protected 214 by a mechanism according to this framework. The egress router is 215 hence called a protected egress router. 217 Egress-protected service - An IP or MPLS service which is carried by 218 an egress-protected tunnel, and hence protected by a mechanism 219 according to this framework. 221 Backup egress router - Given an egress-protected tunnel and its 222 egress router, this is another router which has connectivity with all 223 or a subset of the destinations of the egress-protected services 224 carried by the egress-protected tunnel. In this framework, the 225 service instances on this router are called backup service instances, 226 and the corresponding services are called backup services. 228 Backup service instance - A service instance which is hosted by a 229 backup egress router, and corresponding to an egress-protected 230 service on a protected egress router. 232 Protector - A role acted by a router as an alternate of a protected 233 egress router, to handle service packets in the event of an egress 234 failure. It protects an egress-protected tunnel, and hosts 235 protection service instances for the egress-protected services 236 carried by the tunnel. A protector may or may not be physically co- 237 located with or decoupled from a backup egress router, depending on 238 the co-located or centralized protector mode. 240 Protection service instance - A service instance hosted by a 241 protector, protecting the service instance of an egress-protected 242 service on a protected egress router. A protection service instance 243 is a backup service instance, if the protector is co-located with a 244 backup egress router. 246 PLR - A router at point of local repair. In egress node protection, 247 it is the penultimate-hop router on an egress-protected tunnel. In 248 egress link protection, it is the egress router of the egress- 249 protected tunnel. 251 Protected egress {E, P} - A virtual node consisting of an ordered 252 pair of egress router E and protector P. It serves as the virtual 253 destination for an egress-protected tunnel. It also serves as the 254 virtual location of service instances for the egress-protected 255 services carried by the tunnel. 257 Context identifier (ID) - A globally unique IP address assigned to a 258 protected egress {E, P}. 260 Context label - A non-reserved label assigned to a context ID by a 261 protector. 263 Egress-protection bypass tunnel - A tunnel used for rerouting service 264 packets around an egress failure. In egress node protection, it is 265 established from a penultimate-hop router (i.e. PLR) to a protector, 266 bypassing a protected egress router. In egress link protection, it 267 is established from a protected egress router (i.e. PLR) to a 268 protector, bypassing an egress link. 270 Co-located protector mode - The scenario where a protector and a 271 backup egress router are co-located as one router, and hence each 272 backup service instance serves as a protection service instance. 274 Centralized protector mode - The scenario where protector is a 275 dedicated router, and is decoupled from backup egress routers. 277 Context label switching - Label switching performed by a protector, 278 in the label space of an egress router indicated by a context label. 280 Context IP forwarding - IP forwarding performed by a protector, in 281 the IP address space of an egress router indicated by a context 282 label. 284 4. Requirements 286 This document considers the followings as requirements of the egress 287 protection framework. 289 o The framework must be based on local failure detection and local 290 repair, in a manner similar to transit link/node protection. 292 o The framework must support P2P tunnels. It should equally support 293 P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P 294 tunnel. 296 o The framework must support multi-service and multi-transport 297 networks. It must accommodate existing and future signaling and 298 label-distribution protocols of tunnels and bypass tunnels, 299 including RSPV, LDP, BGP, IGP, segment routing, and others. It 300 must also accommodate existing and future IP/MPLS services, 301 including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and 302 others. It must provide a generic solution for environments where 303 different types of services and tunnels may co-exist. 305 o The framework must consider minimizing disruption for deployment. 306 It should only involve routers around egress, and be transparent 307 to ingress routers and other transit routers. 309 o In egress node protection, for scalability and performance, a PLR 310 must be agnostic with services and service labels, like PLRs in 311 transit link/node protection. It must maintain bypass tunnels and 312 bypass forwarding state on a per-transport-tunnel basis, rather 313 than per-service-destination or per-service-label basis. It 314 should also support bypass tunnel sharing between transport 315 tunnels. 317 o A PLR must be able to use its local visibility or information of 318 routing and/or TE topology to compute or resolve path for a bypass 319 tunnel to a protector. 321 o A protector must be able to perform context label switching for 322 rerouted MPLS service packets, based on service label(s) assigned 323 by an egress router. It must be able to perform context IP 324 forwarding for rerouted IP service packets, in the public or 325 private IP address space used by an egress router. 327 o The framework must be able to work seamlessly with transit link/ 328 node protection mechanisms to achieve end-to-end coverage. 330 o The framework must be able to work in conjunction with global 331 repair and control plane convergence. 333 5. Egress node protection 335 5.1. Reference topology 337 This document refers to the following topology when describing the 338 procedures for egress node protection. 340 services 1, ..., N 341 =====================================> tunnel 343 I ------ R1 ------- PLR --------------- E ---- 344 ingress penultimate-hop egress \ 345 | . (primary \ 346 | . service \ 347 | . instances) \ 348 | . \ 349 | . \ service 350 | . destinations 351 | . / (CEs, sites) 352 | . / 353 | . bypass / 354 | . tunnel / 355 | . / 356 | ............... / 357 R2 --------------- P ---- 358 protector 359 (protection 360 service 361 instances) 363 Figure 1 365 5.2. Egress node failure 367 An egress node failure refers to the failure of an MPLS tunnel's 368 egress router. At service level, it also means a service instance 369 failure for each IP/MPLS service carried by the tunnel. 371 All the local failure detection mechanisms used by PLRs in transit 372 link/node protection are applicable to egress node failure detection. 373 In a case where a PLR does not have a fast and reliable mechanism to 374 detect a node failure or distinguish between a link failure and a 375 node failure, it may conservatively treat a link failure as a node 376 failure and trigger egress node protection. 378 5.3. Protector and PLR 380 A router is assigned to the "protector" role to protect a tunnel and 381 the services carried by the tunnel against an egress node failure. 382 The protector is responsible for hosting a protection service 383 instance for each protected service, serving as the tailend of a 384 bypass tunnel, and performing context label switching and/or context 385 IP forwarding for rerouted service packets. 387 A tunnel can be protected by only one protector at a given time. 388 Multiple tunnels to a given egress router may be protected by a 389 common protector or different protectors. A protector may protect 390 multiple tunnels with a common egress router or different egress 391 routers. 393 For each tunnel, its penultimate-hop router acts as a PLR. The PLR 394 pre-establishes a bypass tunnel to the protector, and pre-installs 395 bypass forwarding state in the data plane. Upon detection of an 396 egress node failure, the PLR reroutes all the service packets 397 received on the tunnel though the bypass tunnel to the protector. 398 For MPLS service packets, the PLR keeps service labels intact in the 399 packets. The protector in turn forwards the rerouted service packets 400 towards the ultimate service destinations. Specifically, it performs 401 context label switching for MPLS service packets, based on service 402 labels assigned by the protected egress router; It performs context 403 IP forwarding for IP service packets, based on their destination 404 addresses. The protector must have its own connectivity with each 405 service destination, via a direct link or a multi-hop path, which 406 must not traverse the protected egress router or be affected by the 407 egress node failure. This also requires that each service 408 destination must be dual-homed or have dual paths to the egress 409 router and a backup egress router which serves as the protector. 410 Each protection service instance on the protector relies on such 411 connectivity to set up forwarding state for context label switching 412 and/or context IP forwarding. 414 5.4. Protected egress 416 This document introduces the notion of "protected egress" as a 417 virtual node consisting of the egress router E of a tunnel and a 418 protector P. It is denoted by an ordered pair of {E, P}, indicating 419 the primary-and-protector relationship between the two routers. It 420 serves as the virtual destination of the tunnel, and the virtual 421 location of service instances for the services carried by the tunnel. 422 The tunnel and services are considered as being "associated" with the 423 protected egress {E, P}. 425 A given egress router E may be the tailend of multiple tunnels. In 426 general, the tunnels may be protected by multiple protectors, e.g. 427 P1, P2, and so on, with each Pi protecting a subset of the tunnels. 428 Thus, these routers form multiple protected egress', i.e. {E, P1} , 429 {E, P2}, and so on. Each tunnel is associated with one and only one 430 protected egress {E, Pi}. All the services carried by the tunnel are 431 then automatically associated with the same protected egress {E, Pi}. 432 Conversely, a service associated with a protected egress {E, Pi} must 433 be carried by a tunnel associated with the same protected egress {E, 434 Pi}. This mapping must be ensured by the ingress router of the tunnel 435 and the service (Section 5.7). 437 Two routers X and Y may be protectors for each other. In this case, 438 they form two distinct protected egress {X, Y} and {Y, X}. 440 5.5. Egress-protected tunnel 442 A tunnel, which is associated with a protected egress {E, P}, is 443 called an egress-protected tunnel. It is associated with one and 444 only one protected egress {E, P}. Multiple egress-protected tunnels 445 may be associated with a given protected egress {E, P}. In this case, 446 they share the common egress router and protector, but may or may not 447 share a common ingress router, a common path, or a common PLR. 449 An egress-protected tunnel is considered as logically "destined" for 450 its protected egress {E, P}. However, its path must be resolved and 451 established with E as the physical tailend. 453 5.6. Egress-protected service 455 A service, which is associated with a protected egress {E, P}, is 456 called an egress-protected service. The egress router E hosts the 457 primary instance of the service, and the protector P hosts the 458 protection instance. 460 An egress-protected service is associated with one and only one 461 protected egress {E, P}. Multiple egress-protected services may be 462 associated with a given protected egress {E, P}. In this case, these 463 services share the common egress router and protector, but may or may 464 not share a common egress-protected tunnel or a common ingress 465 router. 467 5.7. Egress-protected service to egress-protected tunnel mapping 469 An egress-protected service must be mapped to an egress-protected 470 tunnel by its ingress router, based on the common protected egress 471 {E, P} of the service and the tunnel. This is achieved by 472 introducing the notion of "context ID" for protected egress {E, P}, 473 as described in (Section 5.9). 475 5.8. Egress-protection bypass tunnel 477 An egress-protected tunnel destined for a protected egress {E, P} 478 must have a bypass tunnel from its PLR to the protector P. This 479 bypass tunnel is called an egress-protection bypass tunnel. The 480 bypass tunnel is considered as logically "destined" for the protected 481 egress {E, P}. However, due to its bypass tunnel nature, it MUST be 482 resolved and established with P as the physical tailend and E as the 483 node to avoid. The bypass tunnel MUST have the property that it 484 should not be affected by any topology change caused by an egress 485 node failure. 487 An egress-protection bypass tunnel is associated with one and only 488 one protected egress {E, P}. A PLR may share an egress-protection 489 bypass tunnel between multiple egress-protected tunnels associated 490 with a common protected egress {E, P}. For multiple egress-protected 491 tunnels associated with a common protected egress {E, P}, there may 492 be one or multiple egress-protection bypass tunnels from one or 493 multiple PLRs to the protector P, depending on the paths of the 494 egress-protected tunnels. 496 5.9. Context ID, context label, and context based forwarding 498 In this framework, a globally unique IPv4/v6 address is assigned to a 499 protected egress {E, P} to serve as the identifier of the protected 500 egress {E, P}. It is called a "context ID" due to its specific usage 501 in context label switching and context IP forwarding on the 502 protector. It is an IP address that is logically owned by both the 503 egress router and the protector. For the egress node, it indicates 504 the protector. For the protector, it indicates the egress router, 505 particularly the egress router's forwarding context. For other 506 routers in the network, it is an address reachable via both the 507 egress router and the protector in routing domain and TE domain 508 (Section 5.10). 510 The main purpose of a context ID is to coordinate ingress router, 511 egress router, PLR and protector in setting up egress protection. 512 Given an egress-protected service associated with a protected egress 513 {E, P}, its context ID is used as below: 515 o If the service is an MPLS service, when E distributes a service 516 label binding message to the ingress router, E attaches the 517 context ID to the message. If the service is an IP service, when 518 E advertises the service destination address to the ingress 519 router, E also attaches the context ID to the advertisement 520 message. How the context ID is encoded in the messages is a 521 choice of the service protocol, and may need protocol extensions 522 to define a dedicated "context ID" object. 524 o The ingress router uses the context ID as destination to establish 525 or resolve an egress-protected tunnel. The ingress router then 526 maps the service to the tunnel for transportation. 528 o The context ID is conveyed to the PLR by the signaling protocol of 529 the egress-protected tunnel, or learned by the PLR via an IGP or 530 topology-driven label distribution protocol. The PLR uses the 531 context ID as destination to establish or resolve an egress- 532 protection bypass tunnel to P while avoiding E. 534 o P maintains a dedicated label space or a dedicated IP address 535 space for E, depending on whether the service is MPLS or IP. This 536 is referred to as "E's label space" or "E's IP address space", 537 respectively. P uses the context ID to identify the space. 539 o If the service is an MPLS service, E also distributes the service 540 label binding message to P. This is the same label binding 541 message that E advertises to the ingress router, attached with the 542 context ID. Based on the context ID, P installs the service label 543 in an MPLS forwarding table corresponding to E's label space. If 544 the service is an IP service, P installs an IP route in an IP 545 forwarding table corresponding to E's IP address space. In either 546 case, the protection service instance on P interprets the service 547 and constructs forwarding state for the route based on P's own 548 connectivity to the service's destination. 550 o P assigns a non-reserved label to the context ID. In the data 551 plane, this label represents the context ID and indicates E's 552 label space and IP address space. Therefore, it is called a 553 "context label". 555 o The PLR may establish the egress-protection bypass tunnel to P in 556 several manners. If the bypass tunnel is established by RSVP, the 557 PLR signals the bypass tunnel with the context ID as destination, 558 and P binds the context label to the bypass tunnel. If the bypass 559 tunnel is established by LDP, P advertises the context label for 560 the context ID as an IP prefix FEC. If the bypass tunnel is 561 established by the PLR in a hierarchical manner, the PLR treats 562 the context label as a one-hop LSP over a regular bypass tunnel to 563 P (e.g. a bypass tunnel to P's loopback IP address). If the 564 bypass tunnel is constructed by using segment routing, the bypass 565 tunnel is represented by a stack of SID labels with the context 566 label as the inner-most SID label (Section 5.11). In any case, 567 the bypass tunnel is a UHP tunnel whose incoming label at P is the 568 context label. 570 o During local repair, all the service packets received by P on the 571 bypass tunnel will have the context label as top label. P will 572 first pop the context label. For an MPLS service packet, P will 573 further look up the service label in E's label space indicated by 574 the context label, which is called context label switching. For 575 an IP service packet, P will look up the IP destination address in 576 E's IP address space indicated by the context label, which is 577 called context IP forwarding. 579 5.10. IGP advertisement and path resolution for context ID 581 Path resolution or computation for context ID is done on ingress 582 routers for egress-protected tunnels, and on PLRs for egress- 583 protection bypass tunnels. Therefore, given a protected egress {E, 584 P} and its context ID, E and P must coordinate in IGP advertisement 585 for the context ID in routing domain and TE domain. The context ID 586 must be advertised in such a manner that any egress-protected tunnels 587 MUST have E as tailend, and any egress-protection bypass tunnels MUST 588 have P as tailend while avoiding E. 590 This document suggests two approaches: 592 1. The first approach is called "proxy mode". It requires E and P, 593 but not PLR, to have the knowledge of the egress protection 594 schema. E and P advertise the context ID as a virtual proxy node 595 (i.e. a logical node) connected to the two routers, with the link 596 between the proxy node and E having more preferable IGP and TE 597 metrics than the link between the proxy node and P. Therefore, 598 all egress-protected tunnels destined for the context ID should 599 automatically follow the shortest IGP or TE paths to E. Each PLR 600 will no longer view itself as a penultimate-hop, but rather two 601 hops away from the proxy node, via E. The PLR will be able to 602 find a bypass path via P to the proxy node, while the bypass 603 tunnel should actually be terminated by P. 605 2. The second approach is called "alias mode". It requires P and 606 PLR, but not E, to have the knowledge of the egress protection 607 schema. E simply advertises the context ID as a regular IP 608 address. P advertises the context ID and the context label by 609 using a "context ID label binding" advertisement. The 610 advertisement must be understood by the PLR. In both routing 611 domain and TE domain, the context ID is only reachable via E. 612 This ensures that all egress-protected tunnels destined for the 613 context ID should have E as tailend. Based on the "context ID 614 label binding" advertisement, the PLR can establish an egress- 615 protection bypass tunnel in several manners (Section 5.11). The 616 "context ID label binding" advertisement may use the IGP 617 extensions for IGP mirroring context segment described in 618 [SR-ARCH], [SR-OSPF] and [SR-ISIS]. 620 5.11. Egress-protection bypass tunnel establishment 622 A PLR must know the context ID of a protected egress {E, P} in order 623 to establish an egress-protection bypass tunnel. The information is 624 obtained from the signaling or label distribution protocol of egress- 625 protected tunnel. The PLR may or may not need to have the knowledge 626 of egress protection schema. All it does is to set up a bypass 627 tunnel to a context ID while avoiding the next-hop router (i.e. 628 egress router). As the context ID is advertised in routing domain 629 and TE domain by IGP according to Section 5.10, the PLR should be 630 able to resolve or establish such a bypass path with the protector as 631 tailend. In some cases like the proxy mode, the PLR may do so in the 632 same manner as transit node protection. 634 An egress-protection bypass tunnel may be established via several 635 methods: 637 [1] It may be established by a signaling protocol (e.g. RSVP), with 638 the context ID as destination. The protector binds the context label 639 to the bypass tunnel. 641 [2] It may be formed by a topology driven protocol (e.g. LDP). The 642 protector advertises the context ID as an IP prefix FEC, and binds 643 the context label to it. 645 [3] It may be constructed as a hierarchical tunnel. When the 646 protector uses the alias mode (Section 5.10), the PLR will have the 647 knowledge of the context ID, context label, and protector (i.e. the 648 advertiser). The PLR can then establish the bypass tunnel in a 649 hierarchical manner, with the context label as a one-hop LSP over a 650 regular bypass tunnel to the protector's IP address (e.g. loopback 651 address). This regular bypass tunnel may be established by RSVP, 652 LDP, and others. 654 [4] It may be constructed by using segment routing. In this case, 655 the protector uses the alias mode (Section 5.10), and advertises the 656 context ID and context label binding as an IGP mirroring context 657 segment. The PLR can then construct the bypass tunnel as a stack of 658 SID labels, with the context label as the inner-most SID label. 660 5.12. Local Repair on PLR 662 In this framework, a PLR is agnostic with services and services 663 labels. This obviates the need to maintain bypass forwarding state 664 on per-service basis, and allows bypass tunnel sharing between 665 egress-protected tunnels. During local repair, the PLR simply 666 reroutes all service packets received on a tunnel to the 667 corresponding bypass tunnel. Service labels remain intact in MPLS 668 service packets. 670 Label operation during the rerouting depends on the bypass tunnel's 671 characteristics. If the bypass tunnel is a single level tunnel, the 672 rerouting will involve swapping the incoming label of the egress- 673 protected tunnel to the outgoing label of the bypass tunnel. If the 674 bypass tunnel is a hierarchical tunnel, the rerouting will involve 675 swapping the incoming label of the egress-protected tunnel to a 676 context label, and pushing the outgoing label of a regular bypass 677 tunnel. If the bypass tunnel is constructed by segment routing, the 678 rerouting will involve swapping the incoming label of the egress- 679 protected tunnel to a stack of SID labels, with a context label as 680 the inner-most SID label. 682 5.13. Service label distribution from egress router to protector 684 As mentioned in previous sections, when a protector receives a 685 rerouted MPLS service packet, it performs context label switching 686 based on the packet's service label which is assigned by the 687 corresponding egress router. In order to achieve this, the protector 688 MUST maintain such kind of service labels in dedicated label spaces 689 on a per protected egress {E, P} basis, i.e. one label space for each 690 egress router that it protects. 692 Also, there must be a session of service label distribution protocol 693 between each egress router and the protector. Through this protocol, 694 the protector learns the label binding of each egress-protected 695 service. This is the same label binding that the egress router 696 advertises to the corresponding ingress router, attached with a 697 context ID. The corresponding protection service instance on the 698 protector recognizes the service, and resolves forwarding state based 699 on its own connectivity with the service's destination. It then 700 installs the service label with the forwarding state in the label 701 space of the egress router, which is indicated by the context ID 702 (i.e. context label). 704 Different service protocols may use different mechanisms for such 705 kind of label distribution. Specific protocol extensions may be 706 needed on a per-protocol basis or per-service-type basis. The 707 specific details of the extensions SHOULD be specified in separate 708 documents. 710 5.14. Centralized protector mode 712 In this framework, it is assumed that the service destination of an 713 egress-protected service MUST be dual-homed to two edge routers of an 714 MPLS network. One of them is the protected egress router, and the 715 other is a backup egress router. So far in this document, the 716 discussion has been focusing on the scenario where a protector and a 717 backup egress router are co-located as one router. Therefore, the 718 number of protectors in a network is the number of backup egress 719 routers. As another scenario, a network may assign a small number of 720 routers to serve as dedicated protectors, each protecting a subset of 721 egress routers. These protectors are called centralized protectors. 723 Topologically, a centralized protector may be decoupled from all 724 backup egress routers, or it may be co-located with one backup egress 725 router while decoupled from the other backup egress routers. The 726 procedures in this section assume the scenario where a protector and 727 a backup egress router are decoupled. 729 services 1, ..., N 730 =====================================> tunnel 732 I ------ R1 ------- PLR --------------- E ---- 733 ingress penultimate-hop egress \ 734 | . (primary \ 735 | . service \ 736 | . instances) \ 737 | . \ 738 | . bypass \ service 739 R2 . tunnel destinations 740 | . / (CEs, sites) 741 | . / 742 | . / 743 | . / 744 | . tunnel / 745 | =============> / 746 P ---------------- E' --- 747 protector backup egress 748 (protection (backup 749 service service 750 instances) instances) 752 Figure 2 754 Like a co-located protector, a centralized protector hosts protection 755 service instances, receives rerouted service packets from PLRs, and 756 performs context label switching and/or context IP forwarding. For 757 each service, instead of sending service packets directly to the 758 service destination, the protector MUST send them via another 759 transport tunnel to the corresponding backup service instance on a 760 backup egress router. The backup service instance in turn forwards 761 them to the service destination. Specifically, in the case of an 762 MPLS service, the protector MUST swap the service label in each 763 received service packet to the label of the backup service advertised 764 by the backup egress router, and then push a label (or label stack) 765 of the transport tunnel. 767 In order for a centralized protector to map an egress-protected MPLS 768 service to a service hosted on a backup egress router, there MUST be 769 a session of service label distribution protocol between the backup 770 egress router and the protector. Through this session, the backup 771 egress router advertises the service label of the backup service, 772 attached with the FEC of the egress-protected service and the context 773 ID of the protected egress {E, P}. Based on this information, the 774 protector associates the egress-protected service with the backup 775 service, resolves or establishes a transport tunnel to the backup 776 egress router, and accordingly sets up forwarding state for the label 777 of the egress-protected service in the label space of the egress 778 router. 780 The service label which the backup egress router advertises to the 781 protector can be the same as the label which the backup egress router 782 advertises to ingress router(s), if and only if the forwarding state 783 of the label does not direct service packets towards the protected 784 egress router. Otherwise, the label is not usable for egress 785 protection, because it will loop rerouted service packets back to the 786 egress router, which must be avoided. In this case, the backup 787 egress router MUST advertise a unique service label dedicated for 788 egress protection, and set its forwarding state to use the backup 789 egress router's connectivity with the service destination. 791 6. Egress link protection 793 Egress link protection is achievable through similar procedures to 794 that of egress node protection. In normal situations, an egress 795 router forwards service packets to a service destination based on a 796 service label, whose forwarding state points to an egress link. In 797 egress link protection, the egress router acts as PLR, by performing 798 local failure detection and local repair. Specifically, the egress 799 router pre-establishes an egress-protection bypass tunnel to a 800 protector, and installs bypass forwarding state for the service 801 label, pointing to the bypass tunnel. During local repair, the 802 egress router reroutes service packets via the bypass tunnel to the 803 protector. The protector in turn forwards the packets to the service 804 destination (in the co-located protector mode, as shown in Figure-3), 805 or forwards the packets first to a backup egress router and then to 806 the service destination (in the centralized protector mode, as shown 807 in Figure-4). 809 service 810 =====================================> tunnel 812 I ------ R1 ------- R2 --------------- E ---- 813 ingress | ............. egress \ 814 | . PLR \ 815 | . (primary \ 816 | . service \ 817 | . instance) \ 818 | . \ 819 | . bypass service 820 | . tunnel destination 821 | . / (CE, site) 822 | . / 823 | . / 824 | . / 825 | . / 826 | ............... / 827 R3 --------------- P ---- 828 protector 829 (protection 830 service 831 instance) 833 Figure 3 835 service 836 =====================================> tunnel 838 I ------ R1 ------- R2 --------------- E ---- 839 ingress | ............. egress \ 840 | . PLR \ 841 | . (primary \ 842 | . service \ 843 | . instance) \ 844 | . \ 845 | . bypass service 846 | . tunnel destination 847 | . / (CE, site) 848 | . / 849 | . / 850 | . / 851 | . tunnel / 852 | =============> / 853 R3 --------------- P ---- 854 protector backup egress 855 (protection (backup 856 service service 857 instance) instance) 859 Figure 4 861 There are two approaches to set up the bypass forwarding state on the 862 egress router, depending on the service label distribution mode of 863 the given service. The difference is that one approach requires the 864 protector to perform context label switching, and the other one does 865 not. Therefore, the first approach is more consistent with egress 866 node protection, and hence recommended. 868 [1] The first approach applies when the egress router does not 869 know the service label advertised by the backup egress router. In 870 this case, the egress router sets up the bypass forwarding state 871 as a label push with the outgoing label of the egress-protection 872 bypass tunnel. Rerouted packets will have the egress router's 873 service label intact. Therefore, the protector MUST perform 874 context label switching, and the bypass tunnel MUST be destined 875 for the context ID of the {egress router, protector} and 876 established as described in Section 5.11. With this approach, a 877 protector can serve both egress node protection and egress link 878 protection in a consistent manner, and both the co-located 879 protector mode and the centralized protector mode may be used 880 (Figure-3 and Figure-4). 882 [2] The second approach applies when the egress router knows the 883 service label advertised by the backup egress router. This is 884 often the case where the type of service uses BGP as the service 885 label distribution protocol. Since BGP normally distributes 886 service labels over a full mesh of sessions between all PEs, the 887 egress router can automatically learn the service label of the 888 backup egress router. In this case, the backup egress router 889 serves as the protector for egress link protection, regardless of 890 the protector of egress node protection, which should be the same 891 router in the co-located protector mode but may be a different 892 router in the centralized protector mode. The egress router sets 893 up the bypass forwarding state as a label swap from the incoming 894 service label to the service label of the protector, followed by a 895 label push with the outgoing label of the egress link protection 896 bypass tunnel. The bypass tunnel is a regular tunnel destined for 897 an IP address of the protector, instead of the context ID of the 898 {egress router, protector}. The protector will simply forward 899 rerouted service packets based on its own service label, rather 900 than performing context label switching. With this approach, only 901 the co-located protector mode is applicable. 903 In a network where different types of services co-exist, the two 904 approaches may be used in parallel, or the approach [1] may be used 905 consistently for all types of services. 907 Note that for a bidirectional service, the physical link of an egress 908 link may carry service traffic bi-directionally. Therefore, a 909 failure of the physical link may be considered as an egress link 910 failure for the traffic towards the service destination, as well as 911 an ingress link failure for the traffic in the opposite direction. 912 However, protection for ingress link failure should be provided by a 913 separate mechanism, and hence is out of the scope of this framework. 915 7. Global repair 917 This framework provides a fast but temporary repair for egress node/ 918 link failures. For permanent repair, it is RECOMMENDED that the 919 traffic SHOULD be moved to an alternative tunnel or alternative 920 services which are fully functional. This is referred to as global 921 repair. Possible triggers of global repair include control plane 922 notifications of tunnel and service status, end-to-end OAM and fault 923 detection at tunnel or service levels, and others. The alternative 924 tunnel and services may be pre-established as standby, or newly 925 established as a result of the triggers or network protocol 926 convergence. 928 8. Example: Layer-3 VPN egress protection 930 This section shows an example of egress protection for a layer-3 VPN. 932 ---------- R1 ----------- PE2 - 933 / (PLR) (PLR) \ 934 ( site 1 ) / | | ( site 2 ) 935 ( ) / | | ( ) 936 ( subnet )-- PE1 < | R3 ( subnet ) 937 ( 8.0.0.0/8 ) \ | | ( 9.0.0.0/8 ) 938 ( ) \ | | ( ) 939 \ | | / 940 ---------- R2 ----------- PE3 - 941 (protector) 943 Figure 5 945 In this example, the site 1 of a given VPN is attached to PE1, and 946 site 2 is dual-homed to PE2 and PE3. PE2 is the primary PE for site 947 2, and PE3 is the backup PE. Every PE hosts a VPN instance. R1 and 948 R2 are transit routers in the MPLS network. The network uses OSPF as 949 routing protocol, and RSVP-TE as tunnel signaling protocol. The PEs 950 use BGP to exchange VPN prefixes and VPN labels between each other. 952 Using the framework in this document, the network assigns PE3 to be a 953 protector for PE2 to protect the VPN traffic in the direction from 954 site 1 to site 2. This is the co-located protector mode. Hence, PE2 955 and PE3 form a protected egress {PE2, PE3}. A context ID 1.1.1.1 is 956 assigned to the protected egress {PE2, PE3}. The VPN instance on PE3 957 serves as a protection instance for the VPN instance on PE2. On PE3, 958 a context label 100 is assigned to the context ID, and a label table 959 pe2.mpls is created to represent PE2's label space. PE3 installs the 960 label 100 in its default MPLS forwarding table, with nexthop pointing 961 to the label table pe2.mpls. PE2 and PE3 are coordinated to use the 962 proxy mode to advertise the context ID in routing domain and TE 963 domain. 965 PE2 uses per-VRF VPN label allocation mode. It assigns a single 966 label 9000 to the VRF of the VPN. For a given VPN prefix 9.0.0.0/8 967 in site 2, PE2 advertises it along with the label 9000 and other 968 attributes to PE1 and PE3 via BGP. In particular, the NEXT_HOP 969 attribute is set to the context ID 1.1.1.1. 971 Similarly, PE3 also uses per-VRF VPN label allocation mode. It 972 assigns a single label 10000 to the VRF of the VPN. For the VPN 973 prefix 9.0.0.0/8 in site 2, PE3 advertises it along with the label 974 10000 and other attributes to PE1 and PE2 via BGP. In particular, 975 the NEXT_HOP attribute is set to an IP address of PE3. 977 Upon receipt and acceptance of the BGP advertisement, PE1 uses the 978 context ID 1.1.1.1 as destination to compute a TE path for an egress- 979 protected tunnel. The resulted path is PE1->R1->PE2. PE1 then uses 980 RSVP to signal the tunnel, with the context ID 1.1.1.1 as 981 destination, and with the "node protection desired" flag set in the 982 SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes up, 983 PE1 maps the VPN prefix 9.0.0.0/8 to the tunnel and installs a route 984 for the prefix in the corresponding VRF. The route's nexthop is a 985 push with the VPN label 9000, followed by a push with the outgoing 986 label of the egress-protected tunnel. 988 Upon receipt of the above BGP advertisement from PE2, PE3 (i.e. the 989 protector) recognizes the context ID 1.1.1.1 in the NEXT_HOP 990 attribute, and installs a route for label 9000 in the label table 991 pe2.mpls. PE3 sets the route's nexthop to a "protection VRF". This 992 protection VRF contains IP routes corresponding to the IP prefixes in 993 the dual-homed site 2, including 9.0.0.0/8. The nexthops of these 994 routes MUST be based on PE3's connectivity with site 2, even if this 995 connectivity is not the best path in PE3's VRF due to metrics (e.g. 996 MED, loc preference, etc.), and MUST NOT use any path traversing PE2. 997 Note that the protection VRF is a logical concept, and it may simply 998 be PE3's own VRF if the VRF satisfies the requirement. 1000 8.1. Egress node protection 1002 R1, i.e. the penultimate-hop router of the egress-protected tunnel, 1003 serves as the PLR for egress node protection. Based on the "node 1004 protection desired" flag and the destination address (i.e. context ID 1005 1.1.1.1) of the tunnel, R1 computes a bypass path to 1.1.1.1 while 1006 avoiding PE2. The resulted bypass path is R1->R2->PE3. R1 then 1007 signals the path (i.e. egress-protection bypass tunnel), with 1.1.1.1 1008 as destination. 1010 Upon receipt of an RSVP Path message of the egress-protection bypass 1011 tunnel, PE3 recognizes the context ID 1.1.1.1 as the destination, and 1012 hence responds with the context label 100 in an RSVP Resv message. 1014 After the egress-protection bypass tunnel comes up, R1 installs a 1015 bypass nexthop for the egress-protected tunnel. The bypass nexthop 1016 is a swap from the incoming label of the egress-protected tunnel to 1017 the outgoing label of the egress-protection bypass tunnel. 1019 When R1 detects a failure of PE2, it will invoke the above bypass 1020 nexthop to reroute VPN service packets. The packets will have the 1021 label of the bypass tunnel as outer label, and the VPN label 9000 as 1022 inner label. When the packets arrive at PE3, they will have the 1023 context label 100 as outer label, and the VPN label 9000 as inner 1024 label. The context label will first be popped, and then the VPN 1025 label will be looked up in the label table pe2.mpls. The lookup will 1026 cause the VPN label to be popped, and the IP packets will finally be 1027 forwarded to site 2 based on the protection VRF. 1029 8.2. Egress link protection 1031 PE2 serves as the PLR for egress link protection. It has already 1032 learned the VPN label 10000 from PE3, and hence it uses the approach 1033 [2] described in Section 6 to set up bypass forwarding state. It 1034 signals an egress-protection bypass tunnel to PE3, by using the path 1035 PE2->R3->PE3, and PE3's IP address as destination. After the bypass 1036 tunnel comes up, PE2 installs a bypass nexthop for the VPN label 1037 9000. The bypass nexthop is a label swap from the incoming label 1038 9000 to the VPN label 10000 of PE3, followed by a label push with the 1039 outgoing label of the bypass tunnel. 1041 When PE3 detects a failure of the egress link, it will invoke the 1042 above bypass nexthop to reroute VPN service packets. The packets 1043 will have the label of the bypass tunnel as outer label, and the VPN 1044 label 10000 as inner label. When the packets arrive at PE3, the VPN 1045 label 10000 will be popped, and the IP packets will be forwarded 1046 based on the VRF indicated by on the VPN label 10000. 1048 8.3. Global repair 1050 Eventually, global repair will take effect, as control plane 1051 protocols converge on the new topology. PE1 will choose PE3 as new 1052 entrance to site 2. Before that happens, the VPN traffic has been 1053 protected by the above local repair. 1055 9. IANA Considerations 1057 This document has no request for new IANA allocation. 1059 10. Security Considerations 1061 As with any kind of fast reroute mechanisms, the framework in this 1062 document relies on traffic rerouting around a network failure. 1063 Specifically, service traffic can be temporarily rerouted by a PLR to 1064 a protector. In the centralized protector mode, the traffic can be 1065 further rerouted to a backup egress router. The rerouted traffic is 1066 planned and anticipated, and hence it should not be viewed as a new 1067 security threat. 1069 The framework requires a label distribution protocol to run between 1070 an egress router and a protector, which is achievable in a secured 1071 fashion. 1073 11. Acknowledgements 1075 This document leverages work done by Yakov Rekhter, Kevin Wang and 1076 Zhaohui Zhang on MPLS egress protection. 1078 12. References 1080 12.1. Normative References 1082 [SR-ARCH] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1083 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1084 spring-segment-routing (work in progress), 2016. 1086 [SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1087 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1088 Extensions for Segment Routing", draft-ietf-ospf-segment- 1089 routing-extensions (work in progress), 2016. 1091 [SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1092 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1093 Extensions for Segment Routing", draft-ietf-isis-segment- 1094 routing-extensions (work in progress), 2016. 1096 12.2. Informative References 1098 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1099 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1100 DOI 10.17487/RFC4090, May 2005, 1101 . 1103 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1104 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1105 DOI 10.17487/RFC5286, September 2008, 1106 . 1108 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1109 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 1110 RFC 7490, DOI 10.17487/RFC7490, April 2015, 1111 . 1113 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 1114 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 1115 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 1116 . 1118 Authors' Addresses 1120 Yimin Shen 1121 Juniper Networks 1122 10 Technology Park Drive 1123 Westford, MA 01886 1124 USA 1126 Phone: +1 9785890722 1127 Email: yshen@juniper.net 1129 Minto Jeyananth 1130 Juniper Networks 1131 1133 Innovation Way 1132 Sunnyvale, CA 94089 1133 USA 1135 Phone: +1 4089367563 1136 Email: minto@juniper.net 1138 Bruno Decraene 1139 Orange 1141 Email: bruno.decraene@orange.com 1143 Hannes Gredler 1144 RtBrick Inc 1146 Email: hannes@rtbrick.com 1148 Carsten Michel 1149 Deutsche Telekom 1151 Email: c.michel@telekom.de 1153 Huaimo Chen 1154 Huawei Technologies Co., Ltd. 1156 Email: huaimo.chen@huawei.com 1157 Yuanlong Jiang 1158 Huawei Technologies Co., Ltd. 1159 Bantian, Longgang district 1160 Shenzhen 518129 1161 China 1163 Email: jiangyuanlong@huawei.com