idnits 2.17.1 draft-ietf-teas-rsvp-egress-protection-09.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 (October 15, 2017) is 2385 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'CE1' is mentioned on line 588, but not defined == Missing Reference: 'La' is mentioned on line 115, but not defined == Missing Reference: 'CE2' is mentioned on line 588, but not defined == Missing Reference: 'Lb' is mentioned on line 126, but not defined == Missing Reference: 'R1' is mentioned on line 588, but not defined == Unused Reference: 'RFC3209' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'RFC4873' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC4872' is defined on line 740, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 746, but no explicit reference was found in the text == Unused Reference: 'FRAMEWK' is defined on line 752, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track A. Liu 5 Expires: April 18, 2018 Ciena 6 T. Saad 7 Cisco Systems 8 F. Xu 9 Verizon 10 L. Huang 11 China Mobile 12 October 15, 2017 14 Extensions to RSVP-TE for LSP Egress Local Protection 15 draft-ietf-teas-rsvp-egress-protection-09.txt 17 Abstract 19 This document describes extensions to Resource Reservation Protocol - 20 Traffic Engineering (RSVP-TE) for locally protecting the egress 21 node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) 22 Traffic Engineered (TE) Label Switched Path (LSP). 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 18, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Egress Local Protection . . . . . . . . . . . . . . . . . 3 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Extensions to SERO . . . . . . . . . . . . . . . . . . . . 4 64 4.1.1. Primary Egress Subobject . . . . . . . . . . . . . . . 6 65 4.1.2. P2P LSP ID Subobject . . . . . . . . . . . . . . . . . 6 66 5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 7 67 5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 7 68 5.2. Primary Egress Behavior . . . . . . . . . . . . . . . . . 8 69 5.3. Backup Egress Behavior . . . . . . . . . . . . . . . . . . 8 70 5.4. Transit Node and PLR Behavior . . . . . . . . . . . . . . 9 71 5.4.1. Signaling for One-to-One Protection . . . . . . . . . 10 72 5.4.2. Signaling for Facility Protection . . . . . . . . . . 10 73 5.4.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 11 74 5.4.4. PLR Procedures during Local Repair . . . . . . . . . . 12 75 6. Considering Application Traffic . . . . . . . . . . . . . . . 12 76 6.1. A Typical Application . . . . . . . . . . . . . . . . . . 12 77 6.2. PLR Procedure for Applications . . . . . . . . . . . . . . 13 78 6.3. Egress Procedures for Applications . . . . . . . . . . . . 14 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 9. Co-authors and Contributors . . . . . . . . . . . . . . . . . 15 82 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 RFC 4090 describes two methods for locally protecting the transit 91 nodes of a P2P LSP: one-to-one and facility protection. RFC 4875 92 specifies how these methods can be used to protect the transit nodes 93 of a P2MP LSP. These documents do not discuss the procedures for 94 locally protecting the egress node(s) of an LSP. 96 This document fills that void and specifies extensions to RSVP-TE for 97 local protection of the egress node(s) of an LSP. 99 1.1. Egress Local Protection 101 Figure 1 shows an example of using backup LSPs to locally protect 102 egresses of a primary P2MP LSP from ingress R1 to two egresses, L1 103 and L2. La and Lb are the designated backup egresses for primary 104 egresses L1 and L2 respectively. The backup LSP for protecting L1 is 105 from its upstream node R3 to backup egress La and the backup LSP for 106 protecting L2 is from R5 to Lb. 108 ******* ******* S Source 109 [R2]-----[R3]-----[L1] CEx Customer Edge 110 */ &\ \ Rx Non-Egress 111 */ &\ \ Lx Egress 112 */ &\ [CE1] *** Primary LSP 113 */ &\ / &&& Backup LSP 114 */ &\ / 115 */ [La] 116 */ 117 */ 118 */ 119 */ ******** ******** ******* 120 [S]---[R1]------[R4]------[R5]-----[L2] 121 &\ \ 122 &\ \ 123 &\ [CE2] 124 &\ / 125 &\ / 126 [Lb] 128 Figure 1: Backup LSP for Locally Protecting Egress 130 During normal operations, the traffic carried by the P2MP LSP is sent 131 through R3 to L1, which delivers the traffic to its destination CE1. 132 When R3 detects the failure of L1, R3 switches the traffic to the 133 backup LSP to backup egress La, which delivers the traffic to CE1. 134 The time for switching the traffic is within tens of milliseconds. 136 The exact mechanism by which the failure of the primary egress is 137 detected by the upstream node is out of the scope of this document. 139 2. Conventions Used in This Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119. 145 3. Terminology 147 This document uses terminologies defined in RFC 2205, RFC 3209, RFC 148 4090, RFC 4873 and RFC 4875. 150 4. Protocol Extensions 152 4.1. Extensions to SERO 154 The Secondary Explicit Route object (SERO) is defined in RFC 4873. 155 The format of the SERO is re-used. 157 The SERO used for protecting a primary egress node of a primary LSP 158 may be added into the Path messages for the LSP and sent from the 159 ingress node of the LSP to the upstream node of the egress node. It 160 contains three subobjects. 162 The first subobject indicates the branch node that is to originate 163 the backup LSP (to a backup egress node). The branch node is the 164 direct upstream node of the primary egress node of the primary LSP if 165 it can provide fast local protection for the primary egress node. 166 The branch node can be a (upstream) node on the primary LSP, but not 167 the direct upstream node if the direct upstream node does not provide 168 any fast local protection against the failure of the primary egress 169 node. In this case, the backup LSP from the branch node to the 170 backup egress node protects against failures on the segment of the 171 primary LSP from the branch node to the primary egress node, 172 including the primary egress node. 174 The final (third) subobject in the SERO contains the egress node of 175 the backup LSP, i.e., the address of the backup egress node. 177 The second subobject is an egress protection subobject, which is a 178 PROTECTION object with a new C-TYPE (3). The format of the egress 179 protection subobject is defined as follows: 181 0 1 2 3 182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |L| Type | Length | Reserved | C-Type (3) | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Reserved |E-Flags| 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Optional subobjects | 189 ~ ~ 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 E-Flags are defined for egress local protection. 194 x01 (Egress local protection bit): It is set (1) to indicate an 195 egress local protection. 197 x02 (S2L sub LSP backup desired bit): It is set (1) to indicate S2L 198 Sub LSP (ref to RFC 4875) is desired for protecting an egress of a 199 P2MP LSP. 201 The Reserved parts MUST set to zero. 203 Four optional subobjects are defined. They are IPv4 and IPv6 primary 204 egress, IPv4 and IPv6 P2P LSP ID subobjects. They have the following 205 format: 207 0 1 2 3 208 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Type | Length |Reserved (zero)| 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Contents/Body of subobject | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 where Type is the type of a subobject, Length is the total size of 216 the subobject in bytes, including Type, Length and Contents fields. 217 The Reserved field MUST be set to zero. 219 After the upstream node of the primary egress node as the branch node 220 receives the SERO and determines a backup egress node for the primary 221 egress, it computes a path from itself to the backup egress node and 222 sets up a backup LSP along the path for protecting the primary egress 223 node according to the information in the FAST_REROUTE object in the 224 Path message. For example, if facility protection is desired, 225 facility protection is provided for the primary egress node. 227 The upstream node constructs a new SERO based on the SERO received 228 and adds the new SERO into the Path message for the backup LSP. The 229 new SERO also contains three subobjects as the SERO for the primary 230 LSP. The second subobject in the new SERO includes a primary egress, 231 which indicates the address of the primary egress node. The third 232 one contains the backup egress. 234 The upstream node updates the SERO in the Path message for the 235 primary LSP. The egress protection subobject in the SERO contains a 236 subobject called a P2P LSP ID subobject, which contains the 237 information for identifying the backup LSP. The final subobject in 238 the SERO indicates the address of the backup egress node. 240 4.1.1. Primary Egress Subobject 242 There are two primary egress subobjects. One is IPv4 primary egress 243 subobject and the other is IPv6 primary egress subobject. 245 The Type of an IPv4 primary egress subobject is 1, and the body of 246 the subobject is given below: 248 0 1 2 3 249 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | IPv4 address (4 bytes) | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 o IPv4 address: IPv4 address of the primary egress node 256 The Type of an IPv6 primary egress subobject is 2, and the body of 257 the subobject is shown below: 259 0 1 2 3 260 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | IPv6 address (16 bytes) | 263 ~ ~ 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 o IPv6 address: The IPv6 address of the primary egress node 268 4.1.2. P2P LSP ID Subobject 270 A P2P LSP ID subobject contains the information for identifying a 271 backup point-to-point (P2P) LSP tunnel. 273 4.1.2.1. IPv4 P2P LSP ID Subobject 275 The Type of an IPv4 P2P LSP ID subobject is 3, and the body of the 276 subobject is shown below: 278 0 1 2 3 279 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | P2P LSP Tunnel Egress IPv4 Address | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Reserved (MUST be zero) | Tunnel ID | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Extended Tunnel ID | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 o P2P LSP Tunnel Egress IPv4 Address: 289 IPv4 address of the egress of the tunnel 290 o Tunnel ID: 291 A 16-bit identifier being constant over the life of the tunnel 292 o Extended Tunnel ID: 293 A 4-byte identifier being constant over the life of the tunnel 295 4.1.2.2. IPv6 P2P LSP ID Subobject 297 The Type of an IPv6 P2P LSP ID subobject is 4, and the body of the 298 subobject is illustrated below: 300 0 1 2 3 301 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 ~ P2P LSP Tunnel Egress IPv6 Address (16 bytes) ~ 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Reserved (MUST be zero) | Tunnel ID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 ~ Extended Tunnel ID (16 bytes) ~ 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 o P2P LSP Tunnel Egress IPv6 Address: 311 IPv6 address of the egress of the tunnel 312 o Tunnel ID: 313 A 16-bit identifier being constant over the life of the tunnel 314 o Extended Tunnel ID: 315 A 16-byte identifier being constant over the life of the tunnel 317 5. Egress Protection Behaviors 319 5.1. Ingress Behavior 321 To protect a primary egress of an LSP, the ingress MUST set the 322 "label recording desired" flag and the "node protection desired" flag 323 in the SESSION_ATTRIBUTE object. 325 If one-to-one backup or facility backup is desired to protect a 326 primary egress of an LSP, the ingress MUST include a FAST_REROUTE 327 object and set the "One-to-One Backup Desired" or "Facility Backup 328 Desired" flag respectively. 330 If S2L Sub LSP backup is desired to protect a primary egress of a 331 P2MP LSP, the ingress MUST set the "S2L Sub LSP Backup Desired" flag 332 in an SERO object. 334 A backup egress MUST be configured on the ingress of an LSP to 335 protect a primary egress of the LSP if and only if the backup egress 336 is not indicated in another place. 338 The ingress MUST send a Path message for the LSP with the objects 339 above and the SEROs for protecting egresses of the LSP. For each 340 primary egress of the LSP to be protected, the ingress MUST add an 341 SERO object into the Path message if the backup egress or some 342 options are given. If the backup egress is given, then the final 343 subobject in the SERO containts it; otherwise the address in the 344 final subobject is zero. 346 5.2. Primary Egress Behavior 348 To protect a primary egress of an LSP, a backup egress MUST be 349 configured on the primary egress of the LSP to protect the primary 350 egress if and only if the backup egress is not indicated in another 351 place. 353 If the backup egress is configured on the primary egress of the LSP, 354 the primary egress MUST send its upstream node a Resv message for the 355 LSP with an SERO for protecting the primary egress. It sets the 356 flags in the SERO in the same way as an ingress. 358 If the LSP carries the service traffic with a service label, the 359 primary egress sends its corresponding backup egress the information 360 about the service label as a UA label and the related forwarding. 362 5.3. Backup Egress Behavior 364 When a backup egress node receives a Path message for an LSP, it 365 determines whether the LSP is used for egress local protection 366 through checking the SERO with egress protection subobject in the 367 message. If there is an egress protection subobject in the Path 368 message for the LSP and the Egress local protection flag in the 369 object is set to one, the LSP is the backup LSP for egress local 370 protection. The primary egress to be protected is in the primary 371 egress subobject in the SERO. 373 When the backup egress receives the information about a UA label and 374 its related forwarding from the primary egress, it uses the backup 375 LSP label as a context label and creates a forwarding entry using the 376 information about the UA label and the related forwarding. This 377 forwarding entry is in a forwarding table for the primary egress 378 node. 380 When the primary egress node fails, its upstream node switches the 381 traffic from the primary LSP to the backup LSP to the backup egress 382 node, which delivers the traffic to its receiver such as CE using the 383 backup LSP label as a context label to get the forwarding table for 384 the primary egress node and the service label as UA label to find the 385 forwarding entry in the table to forward the traffic to the receiver. 387 5.4. Transit Node and PLR Behavior 389 If a transit node of an LSP receives the Path message with the SEROs 390 and it is not an upstream node of any primary egress of the LSP as a 391 branch node, it MUST forward them unchanged. 393 If the transit node is the upstream node of a primary egress to be 394 protected as a branch node, it determines the backup egress, obtains 395 a path for the backup LSP and sets up the backup LSP along the path. 396 If the upstream node receives the Resv message with an SERO object, 397 it MUST sends its upstream node the Resv message without the object. 399 The PLR (upstream node of the primary egress as the branch node) MUST 400 extract the backup egress from the respective SERO object in either a 401 Path or a Resv message. If no matching SERO object is found, the PLR 402 tries to find the backup egress, which is not the primary egress but 403 has the same IP address as the destination IP address of the LSP. 405 Note that if a backup egress is not configured explicitly for 406 protecting a primary egress, the primary egress and the backup egress 407 SHOULD have a same local address configured, and the cost to the 408 local address on the backup egress SHOULD be much bigger than the 409 cost to the local address on the primary egress. Thus primary egress 410 and backup egress is considered as a virtual node. Note that the 411 backup egress is different from this local address (e.g., from the 412 primary egress' view). In other words, it is identified by an 413 address different from this local address. 415 After obtaining the backup egress, the PLR computes a backup path 416 from itself to the backup egress and sets up a backup LSP along the 417 path. It excludes the segment including the primary egress to be 418 protected when computing the path. The PLR sends the primary egress 419 a Path message with an SERO for the primary LSP, which indicates the 420 backup egress by the final subobject in the SERO. The PLR puts an 421 SERO into the Path messages for the backup LSP, which indicates the 422 primary egress. 424 The PLR MUST provide one-to-one backup protection for the primary 425 egress if the "One-to-One Backup Desired" flag is set in the message; 426 otherwise, it MUST provide facility backup protection if the 427 "Facility Backup Desired flag" is set. 429 The PLR MUST set the protection flags in the RRO Sub-object for the 430 primary egress in the Resv message according to the status of the 431 primary egress and the backup LSP protecting the primary egress. For 432 example, it sets the "local protection available" and the "node 433 protection" flag indicating that the primary egress is protected when 434 the backup LSP is up and ready for protecting the primary egress. 436 5.4.1. Signaling for One-to-One Protection 438 The behavior of the upstream node of a primary egress of an LSP as a 439 PLR is the same as that of a PLR for one-to-one backup described in 440 RFC 4090 except for that the upstream node as a PLR creates a backup 441 LSP from itself to a backup egress in a session different from the 442 primary LSP. 444 If the LSP is a P2MP LSP and a primary egress of the LSP is also a 445 transit node (i.e., bud node), the upstream node of the primary 446 egress as a PLR creates a backup LSP from itself to each of the next 447 hops of the primary egress. 449 When the PLR detects the failure of the primary egress, it switches 450 the packets from the primary LSP to the backup LSP to the backup 451 egress. For the failure of the bud node of a P2MP LSP, the PLR also 452 switches the packets to the backup LSPs to the bud node's next hops, 453 where the packets are merged into the primary LSP. 455 5.4.2. Signaling for Facility Protection 457 Except for backup LSP and downstream label, the behavior of the 458 upstream node of the primary egress of a primary LSP as a PLR follows 459 the PLR behavior for facility backup described in RFC 4090. 461 For a number of primary P2P LSPs going through the same PLR to the 462 same primary egress, the primary egress of these LSPs MAY be 463 protected by one backup LSP from the PLR to the backup egress 464 designated for protecting the primary egress. 466 The PLR selects or creates a backup LSP from itself to the backup 467 egress. If there is a backup LSP that satisfies the constraints 468 given in the Path message, then this one is selected; otherwise, a 469 new backup LSP to the backup egress is created. 471 After getting the backup LSP, the PLR associates the backup LSP with 472 a primary LSP for protecting its primary egress. The PLR records 473 that the backup LSP is used to protect the primary LSP against its 474 primary egress failure and MUST include an SERO object in the Path 475 message for the primary LSP. The object MUST contain the backup LSP 476 ID. It indicates that the primary egress MUST send the backup egress 477 the service label as UA label and the information about forwarding 478 the traffic to its destination using the label if there is a service 479 carried by the LSP and the primary LSP label as UA label if the label 480 is not implicit null. How UA label is sent is out of scope for this 481 document. 483 When the PLR detects the failure of the primary egress, it redirects 484 the packets from the primary LSP into the backup LSP to backup egress 485 and keeps the primary LSP label from the primary egress in the label 486 stack if the label is not implicit null. The backup egress delivers 487 the packets to the same destinations as the primary egress using the 488 backup LSP label as context label and the labels under as UA labels. 490 5.4.3. Signaling for S2L Sub LSP Protection 492 The S2L Sub LSP Protection uses a S2L Sub LSP (ref to RFC 4875) as a 493 backup LSP to protect a primary egress of a P2MP LSP. The PLR MUST 494 determine to protect a primary egress of a P2MP LSP via S2L sub LSP 495 protection when it receives a Path message with flag "S2L Sub LSP 496 Backup Desired" set. 498 The PLR MUST set up the backup S2L sub LSP to the backup egress, 499 create and maintain its state in the same way as of setting up a 500 source to leaf (S2L) sub LSP defined in RFC 4875 from the signaling's 501 point of view. It computes a path for the backup LSP from itself to 502 the backup egress, constructs and sends a Path message along the 503 path, receives and processes a Resv message responding to the Path 504 message. 506 After receiving the Resv message for the backup LSP, the PLR creates 507 a forwarding entry with an inactive state or flag called inactive 508 forwarding entry. This inactive forwarding entry is not used to 509 forward any data traffic during normal operations. 511 When the PLR detects the failure of the primary egress, it changes 512 the forwarding entry for the backup LSP to active. Thus, the PLR 513 forwards the traffic to the backup egress through the backup LSP, 514 which sends the traffic to its destination. 516 5.4.4. PLR Procedures during Local Repair 518 When the upstream node of a primary egress of an LSP as a PLR detects 519 the failure of the primary egress, it follows the procedures defined 520 in section 6.5 of RFC 4090. It SHOULD notify the ingress about the 521 failure of the primary egress in the same way as a PLR notifies the 522 ingress about the failure of a transit node. 524 Moreover, the PLR MUST let the upstream part of the primary LSP stay 525 after the primary egress fails through sending Resv message to its 526 upstream node along the primary LSP. The downstream part of the 527 primary LSP from the PLR to the primary egress SHOULD be removed. 528 When a bypass LSP from the PLR to a backup egress protects the 529 primary egress, the PLR MUST NOT send any Path message for the 530 primary LSP through the bypass LSP to the backup egress. 532 In the local revertive mode, the PLR will re-signal each of the 533 primary LSPs that were routed over the restored resource once it 534 detects that the resource is restored. Every primary LSP 535 successfully re-signaled along the restored resource will be switched 536 back. 538 6. Considering Application Traffic 540 This section focuses on the application traffic carried by P2P LSPs. 541 When a primary egress of a P2MP LSP fails, the application traffic 542 carried by the P2MP LSP is delivered to the same destination by the 543 backup egress since the inner label if any for the traffic is a 544 upstream assigned label for every egress of the P2MP LSP. 546 6.1. A Typical Application 548 L3VPN is a typical application. An existing solution (refer to 549 Figure 2) for protecting L3VPN traffic against egress failure 550 includes: 1) A multi-hop BFD session between ingress R1 and egress L1 551 of primary LSP; 2) A backup LSP from ingress R1 to backup egress La; 552 3) La sends R1 VPN backup label and related information via BGP; 4) 553 R1 has a VRF with two sets of routes: one uses primary LSP and L1 as 554 next hop; the other uses backup LSP and La as next hop. 556 ***** ***** 557 CE1,CE2 in [R2]-----[R3]-----[L1] **** Primary LSP 558 one VPN */ : \ &&&& Backup LSP 559 */ .................: \ .... BFD Session 560 [CE1]--[R1] ..: [CE2] 561 &\ / 562 &\ / 563 [R4]-----[R5]-----[La](BGP sends R1 VPN backup label) 564 &&&&& &&&&& 566 Figure 2: Protect Egress for L3VPN Traffic 568 In normal operations, R1 sends the traffic from CE1 through primary 569 LSP with VPN label received from L1 as inner label to L1, which 570 delivers the traffic to CE2 using VPN label. 572 When R1 detects the failure of L1, R1 sends the traffic from CE1 via 573 backup LSP with VPN backup label received from La as inner label to 574 La, which delivers the traffic to CE2 using VPN backup label. 576 A new solution (refer to Figure 3) with egress local protection for 577 protecting L3VPN traffic includes: 1) A BFD session between R3 and 578 egress L1 of primary LSP; 2) A backup LSP from R3 to backup egress 579 La; 3) L1 sends La VPN label as UA label and related information; 4) 580 L1 and La is virtualized as one. This can be achieved by configuring 581 a same local address on L1 and La, using the address as a destination 582 of the LSP and BGP next hop for VPN traffic. 584 ***** ***** 585 CE1,CE2 in [R2]-----[R3]-----[L1] **** Primary LSP 586 one VPN */ &\:.....: \ &&&& Backup LSP 587 */ &\ \ .... BFD Session 588 [CE1]--[R1] &\ [CE2] 589 &\ / 590 &\ / 591 [La](VPN label from L1 as UA label) 593 Figure 3: Locally Protect Egress for L3VPN Traffic 595 When R3 detects L1's failure, R3 sends the traffic from primary LSP 596 via backup LSP to La, which delivers the traffic to CE2 using VPN 597 label as UA label under the backup LSP label as a context label. 599 6.2. PLR Procedure for Applications 601 When the PLR gets a backup LSP from itself to a backup egress for 602 protecting a primary egress of a primary LSP, it includes an SERO 603 object in the Path message for the primary LSP. The object contains 604 the ID information of the backup LSP and indicates that the primary 605 egress sends the backup egress the application traffic label (e.g., 606 VPN label) as UA label when needed. 608 6.3. Egress Procedures for Applications 610 When a primary egress of an LSP sends the ingress of the LSP a label 611 for an application such as a VPN, it sends the backup egress for 612 protecting the primary egress the label as a UA label. Exactly how 613 the label is sent is out of scope for this document. 615 When the backup egress receives a UA label from the primary egress, 616 it adds a forwarding entry with the label into the LFIB for the 617 primary egress. When the backup egress receives a packet from the 618 backup LSP, it uses the top label as a context label to find the LFIB 619 for the primary egress and the inner label to deliver the packet to 620 the same destination as the primary egress according to the LFIB. 622 7. Security Considerations 624 In principle this document does not introduce new security issues. 625 The security considerations pertaining to RFC 4090, RFC 4875 and 626 other RSVP protocols remain relevant. 628 Note that protecting a primary egress of a P2P LSP carrying service 629 traffic through a backup egress requires that the backup egress trust 630 the primary egress for the information received for a service label 631 as UA label. 633 8. IANA Considerations 635 IANA maintains a registry called "Class Names, Class Numbers, and 636 Class Types" under "Resource Reservation Protocol-Traffic Engineering 637 (RSVP-TE) Parameters". IANA is to assign a new C-Type under 638 PROTECTION object class, Class Number 37: 640 o Egress Protection: C-Type 3 642 IANA is to create and maintain a new registry under PROTECTION object 643 class, Class Number 37, C-Type 3. Initial values for the registry 644 are given below. The future assignments are to be made through IETF 645 Review. 647 Value Name Definition 648 1 IPv4_PRIMARY_EGRESS Section 4.1.1 649 2 IPv6_PRIMARY_EGRESS Section 4.1.1 650 3 IPv4_P2P_LSP_ID Section 4.1.2 651 4 IPv6_P2P_LSP_ID Section 4.1.2 653 9. Co-authors and Contributors 655 1. Co-authors 657 Ning So 658 Tata 659 E-mail: ningso01@gmail.com 661 Mehmet Toy 662 Verizon 663 E-mail: mehmet.toy@verizon.com 665 Lei Liu 666 Fujitsu 667 E-mail: lliu@us.fujitsu.com 669 Zhenbin Li 670 Huawei Technologies 671 Email: lizhenbin@huawei.com 673 2. Contributors 675 Boris Zhang 676 Telus Communications 677 Email: Boris.Zhang@telus.com 679 Nan Meng 680 Huawei Technologies 681 Email: mengnan@huawei.com 683 Prejeeth Kaladharan 684 Huawei Technologies 685 Email: prejeeth@gmail.com 686 Vic Liu 687 China Mobile 688 Email: liu.cmri@gmail.com 690 10. Acknowledgement 692 The authors would like to thank Richard Li, Nobo Akiya, Lou Berger, 693 Jeffrey Zhang, Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, 694 Michael Yue, Daniel King, Rob Rennison, Neil Harrison, Kannan 695 Sampath, Yimin Shen, Ronhazli Adam and Quintin Zhao for their 696 valuable comments and suggestions on this draft. 698 11. References 700 11.1. Normative References 702 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 703 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 704 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 705 . 707 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 708 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 709 DOI 10.17487/RFC4090, May 2005, 710 . 712 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 713 Yasukawa, Ed., "Extensions to Resource Reservation 714 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 715 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 716 DOI 10.17487/RFC4875, May 2007, 717 . 719 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 720 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 721 May 2007, . 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 725 RFC2119, March 1997, 726 . 728 11.2. Informative References 730 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 731 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 732 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 733 September 1997, . 735 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 736 Label Assignment and Context-Specific Label Space", 737 RFC 5331, DOI 10.17487/RFC5331, August 2008, 738 . 740 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 741 Ed., "RSVP-TE Extensions in Support of End-to-End 742 Generalized Multi-Protocol Label Switching (GMPLS) 743 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 744 . 746 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 747 Switching (GMPLS) Signaling Resource ReserVation Protocol- 748 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 749 DOI 10.17487/RFC3473, January 2003, 750 . 752 [FRAMEWK] Shen, Y., Jeyananth, M., Decraene, B., and H. Gredler, 753 "MPLS Egress Protection Framework", 754 draft-shen-mpls-egress-protection-framework , 755 October 2016. 757 Authors' Addresses 759 Huaimo Chen 760 Huawei Technologies 761 Boston, MA 762 USA 764 Email: huaimo.chen@huawei.com 766 Autumn Liu 767 Ciena 768 USA 770 Email: hliu@ciena.com 772 Tarek Saad 773 Cisco Systems 775 Email: tsaad@cisco.com 776 Fengman Xu 777 Verizon 778 2400 N. Glenville Dr 779 Richardson, TX 75082 780 USA 782 Email: fengman.xu@verizon.com 784 Lu Huang 785 China Mobile 786 No.32 Xuanwumen West Street, Xicheng District 787 Beijing, 100053 788 China 790 Email: huanglu@chinamobile.com