idnits 2.17.00 (12 Aug 2021) /tmp/idnits14507/draft-ietf-teas-rsvp-egress-protection-16.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 1 instance 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 (March 18, 2018) is 1518 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 722, but not defined == Missing Reference: 'La' is mentioned on line 123, but not defined == Missing Reference: 'CE2' is mentioned on line 722, but not defined == Missing Reference: 'Lb' is mentioned on line 134, but not defined == Missing Reference: 'R1' is mentioned on line 722, but not defined == Unused Reference: 'RFC3209' is defined on line 854, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'RFC4873' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC4872' is defined on line 892, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'FRAMEWK' is defined on line 904, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 17 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: September 19, 2018 Ciena 6 T. Saad 7 Cisco Systems 8 F. Xu 9 Verizon 10 L. Huang 11 China Mobile 12 March 18, 2018 14 Extensions to RSVP-TE for LSP Egress Local Protection 15 draft-ietf-teas-rsvp-egress-protection-16.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 September 19, 2018. 41 Copyright Notice 43 Copyright (c) 2018 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. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Extensions to SERO . . . . . . . . . . . . . . . . . . . . 5 64 4.1.1. Primary Egress Subobject . . . . . . . . . . . . . . . 7 65 4.1.2. P2P LSP ID Subobject . . . . . . . . . . . . . . . . . 8 66 5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 9 67 5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 9 68 5.2. Primary Egress Behavior . . . . . . . . . . . . . . . . . 10 69 5.3. Backup Egress Behavior . . . . . . . . . . . . . . . . . . 10 70 5.4. Transit Node and PLR Behavior . . . . . . . . . . . . . . 11 71 5.4.1. Signaling for One-to-One Protection . . . . . . . . . 12 72 5.4.2. Signaling for Facility Protection . . . . . . . . . . 12 73 5.4.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 13 74 5.4.4. PLR Procedures during Local Repair . . . . . . . . . . 13 75 6. Application Traffic Considerations . . . . . . . . . . . . . . 14 76 6.1. A Typical Application . . . . . . . . . . . . . . . . . . 14 77 6.2. PLR Procedure for Applications . . . . . . . . . . . . . . 16 78 6.3. Egress Procedures for Applications . . . . . . . . . . . . 17 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 9. Co-authors and Contributors . . . . . . . . . . . . . . . . . 18 82 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 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. Egress node and 98 egress will be used exchangeably. 100 1.1. Egress Local Protection 102 In general, locally protecting an egress node of an LSP means that 103 when the egress node fails, the traffic that the LSP carries will be 104 delivered to its destination by the direct upstream node of the 105 egress node to a backup egress node. Without protecting the egress 106 node of the LSP, when the egress node fails, the traffic will be lost 107 (i.e., the traffic will not be delivered to its destination). 109 Figure 1 shows an example of using backup LSPs to locally protect 110 egress nodes L1 and L2 of a primary P2MP LSP starting from ingress 111 R1. La and Lb are the designated backup egress nodes for primary 112 egress nodes L1 and L2 respectively. The backup LSP for protecting 113 L1 is from its upstream node R3 to backup egress node La and the 114 backup LSP for protecting L2 is from R5 to Lb. 116 ******* ******* S Source 117 [R2]-----[R3]-----[L1] CEx Customer Edge 118 */ &\ \ Rx Non-Egress 119 */ &\ \ Lx Egress 120 */ &\ [CE1] *** Primary LSP 121 */ &\ / &&& Backup LSP 122 */ &\ / 123 */ [La] 124 */ 125 */ 126 */ 127 */ ******** ******** ******* 128 [S]---[R1]------[R4]------[R5]-----[L2] 129 &\ \ 130 &\ \ 131 &\ [CE2] 132 &\ / 133 &\ / 134 [Lb] 136 Figure 1: Backup LSP for Locally Protecting Egress 138 During normal operations, the traffic carried by the P2MP LSP is sent 139 through R3 to L1, which delivers the traffic to its destination CE1. 140 When R3 detects the failure of L1, R3 switches the traffic to the 141 backup LSP to backup egress node La, which delivers the traffic to 142 CE1. The time for switching the traffic is within tens of 143 milliseconds. 145 The exact mechanism by which the failure of the primary egress node 146 is detected by the upstream node R3 is out of the scope of this 147 document. 149 In the beginning, the primary P2MP LSP from ingress R1 to primary 150 egress nodes L1 and L2 is configured. It may be used to transport 151 the traffic from source S connected to R1 to destinations CE1 and CE2 152 connected to L1 and L2 respectively. 154 To protect the primary egress nodes L1 and L2, one configures on the 155 ingress R1 a backup egress node for L1, another backup egress node 156 for L2 and other options. After the configuration, the ingress sends 157 a Path message for the LSP with the information such as SEROs (refer 158 to section 4.1) containing the backup egress nodes for protecting the 159 primary egress nodes. 161 After receiving the Path message with the information, the upstream 162 node of a primary egress node sets up a backup LSP to the 163 corresponding backup egress node for protecting the primary egress 164 node. 166 2. Conventions Used in This Document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119. 172 3. Terminologies 174 The following terminologies are used in this document. 176 LSP: Label Switched Path 178 TE: Traffic Engineering 179 P2MP: Point-to-MultiPoint 181 P2P: Point-to-Point 183 LSR: Label Switching Router 185 RSVP: Resource ReSerVation Protocol 187 S2L: Source-to-Leaf 189 SERO: Secondary Explicit Route Object 191 RRO: Record Route Object 193 BFD: Bidirectional Forwarding Detection 195 VPN: Virtual Private Network 197 L3VPN: Layer 3 VPN 199 VRF: Virtual Routing and Forwarding 201 LFIB: Label Forwarding Information Base 203 UA: Upstream Assigned 205 PLR: Point of Local Repair 207 BGP: Border Gateway Protocol 209 CE: Customer Edge 211 PE: Provider Edge 213 4. Protocol Extensions 215 4.1. Extensions to SERO 217 The Secondary Explicit Route object (SERO) is defined in RFC 4873. 218 The format of the SERO is re-used. 220 The SERO used for protecting a primary egress node of a primary LSP 221 may be added into the Path messages for the LSP and sent from the 222 ingress node of the LSP to the upstream node of the egress node. It 223 contains three subobjects. 225 The first subobject (refer to RFC 4873 Section 4.2) indicates the 226 branch node that is to originate the backup LSP (to a backup egress 227 node). The branch node is typically the direct upstream node of the 228 primary egress node of the primary LSP. If the direct upstream node 229 does not support local protection against the failure of the primary 230 egress node, the branch node can be any (upstream) node on the 231 primary LSP. In this case, the backup LSP from the branch node to 232 the backup egress node protects against failures on the segment of 233 the primary LSP from the branch node to the primary egress node, 234 including the primary egress node. 236 The second subobject is an egress protection subobject, which is a 237 PROTECTION object with a new C-TYPE (TBA1). The format of the egress 238 protection subobject is defined as follows: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |L| Type | Length | Reserved | C-Type (TBA1) | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Reserved |E-Flags| 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Optional subobjects | 248 ~ ~ 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 E-Flags are defined for egress local protection. 253 Bit 31 (Egress local protection flag): It is the least significant 254 bit of the 32-bit word and is set to 1 indicating an egress local 255 protection. 257 Bit 30 (S2L sub LSP backup desired flag): It is the second least 258 significant bit of the 32-bit word and is set to 1 indicating S2L 259 sub LSP (ref to RFC 4875) is desired for protecting an egress of a 260 P2MP LSP. 262 The Reserved parts MUST be set to zero on transmission and MUST be 263 ignored on receipt. 265 Four optional subobjects are defined. They are IPv4 and IPv6 primary 266 egress node, IPv4 and IPv6 P2P LSP ID subobjects. IPv4 and IPv6 267 primary egress node subobjects indicate the IPv4 and IPv6 address of 268 the primary egress node respectively. IPv4 and IPv6 P2P LSP ID 269 subobjects contains the information for identifying IPv4 and IPv6 270 backup point-to-point (P2P) LSP tunnels respectively. Their contents 271 are described in sections 4.1.1 through 4.1.2.2. They have the 272 following format: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Type | Length | Reserved (zero) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Contents/Body of subobject | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 where Type is the type of a subobject, Length is the total size of 283 the subobject in bytes, including Type, Length and Contents fields. 284 The Reserved field MUST be set to zero on transmission and MUST be 285 ignored on receipt. 287 The third (final) subobject (refer to RFC 4873 Section 4.2) in the 288 SERO contains the egress node of the backup LSP, i.e., the address of 289 the backup egress node in the place of the merge node. 291 After the upstream node of the primary egress node as the branch node 292 receives the SERO and determines a backup egress node for the primary 293 egress node, it computes a path from itself to the backup egress node 294 and sets up a backup LSP along the path for protecting the primary 295 egress node according to the information in the FAST_REROUTE object 296 in the Path message. For example, if facility protection is desired, 297 facility protection is provided for the primary egress node. 299 The upstream node constructs a new SERO based on the SERO received 300 and adds the new SERO into the Path message for the backup LSP. The 301 new SERO also contains three subobjects as the SERO for the primary 302 LSP. The first subobject in the new SERO indicates the upstream 303 node, which may be copied from the first subobject in the SERO 304 received. The second subobject in the new SERO includes a primary 305 egress node, which indicates the address of the primary egress node. 306 The third one contains the backup egress node. 308 The upstream node updates the SERO in the Path message for the 309 primary LSP. The egress protection subobject in the SERO contains a 310 subobject called a P2P LSP ID subobject, which contains the 311 information for identifying the backup LSP. The final subobject in 312 the SERO indicates the address of the backup egress node. 314 4.1.1. Primary Egress Subobject 316 There are two primary egress subobjects. One is IPv4 primary egress 317 subobject and the other is IPv6 primary egress subobject. 319 The Type of an IPv4 primary egress subobject is 1, and the body of 320 the subobject is given below: 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | IPv4 address (4 bytes) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 o IPv4 address: IPv4 address of the primary egress node 330 The Type of an IPv6 primary egress subobject is 2, and the body of 331 the subobject is shown below: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | IPv6 address (16 bytes) | 337 ~ ~ 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 o IPv6 address: The IPv6 address of the primary egress node 342 4.1.2. P2P LSP ID Subobject 344 A P2P LSP ID subobject contains the information for identifying a 345 backup point-to-point (P2P) LSP tunnel. 347 4.1.2.1. IPv4 P2P LSP ID Subobject 349 The Type of an IPv4 P2P LSP ID subobject is 3, and the body of the 350 subobject is shown below: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | P2P LSP Tunnel Egress IPv4 Address | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Reserved (MUST be zero) | Tunnel ID | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Extended Tunnel ID | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 o P2P LSP Tunnel Egress IPv4 Address: 363 IPv4 address of the egress node of the tunnel 364 o Tunnel ID (ref to RFC 4875 and RFC 3209): 365 A 16-bit identifier being constant over the life of the tunnel 366 occupies the least significant 16 bits of the 32 bit word. 367 o Extended Tunnel ID (ref to RFC 4875 and RFC 3209): 368 A 4-byte identifier being constant over the life of the tunnel 370 4.1.2.2. IPv6 P2P LSP ID Subobject 372 The Type of an IPv6 P2P LSP ID subobject is 4, and the body of the 373 subobject is illustrated below: 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 ~ P2P LSP Tunnel Egress IPv6 Address (16 bytes) ~ 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Reserved (MUST be zero) | Tunnel ID | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 ~ Extended Tunnel ID (16 bytes) ~ 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 o P2P LSP Tunnel Egress IPv6 Address: 386 IPv6 address of the egress node of the tunnel 387 o Tunnel ID (ref to RFC 4875 and RFC 3209): 388 A 16-bit identifier being constant over the life of the tunnel 389 occupies the least significant 16 bits of the 32 bit word. 390 o Extended Tunnel ID (ref to RFC 4875 and RFC 3209): 391 A 16-byte identifier being constant over the life of the tunnel 393 5. Egress Protection Behaviors 395 5.1. Ingress Behavior 397 To protect a primary egress node of an LSP, the ingress MUST set the 398 "label recording desired" flag and the "node protection desired" flag 399 in the SESSION_ATTRIBUTE object. 401 If one-to-one backup or facility backup is desired to protect a 402 primary egress node of an LSP, the ingress MUST include a 403 FAST_REROUTE object and set the "One-to-One Backup Desired" or 404 "Facility Backup Desired" flag respectively. 406 If S2L Sub LSP backup is desired to protect a primary egress node of 407 a P2MP LSP, the ingress MUST set the "S2L Sub LSP Backup Desired" 408 flag in an SERO object. 410 The decision to instantiate a backup egress for protecting the 411 primary egress of an LSP can be initiated by either the ingress or 412 the primary egress of that LSP, but not both. 414 A backup egress node MUST be configured on the ingress of an LSP to 415 protect a primary egress node of the LSP if and only if the backup 416 egress node is not configured on the primary egress node (refer to 417 section 5.2). 419 The ingress MUST send a Path message for the LSP with the objects 420 above and the SEROs for protecting egress nodes of the LSP if 421 protection of the egress nodes is desired. For each primary egress 422 node of the LSP to be protected, the ingress MUST add an SERO object 423 into the Path message if the backup egress node or some options are 424 given. If the backup egress node is given, then the final subobject 425 in the SERO contains it; otherwise the address in the final subobject 426 is zero. 428 5.2. Primary Egress Behavior 430 To protect a primary egress node of an LSP, a backup egress node MUST 431 be configured on the primary egress node of the LSP to protect the 432 primary egress node if and only if the backup egress node is not 433 configured on the ingress of the LSP (refer to section 5.1). 435 If the backup egress node is configured on the primary egress node of 436 the LSP, the primary egress node MUST send its upstream node a Resv 437 message for the LSP with an SERO for protecting the primary egress 438 node. It sets the flags in the SERO in the same way as an ingress. 440 If the LSP carries the service traffic with a service label, the 441 primary egress node sends its corresponding backup egress node the 442 information about the service label as a UA label and the related 443 forwarding. 445 5.3. Backup Egress Behavior 447 When a backup egress node receives a Path message for an LSP, it 448 determines whether the LSP is used for egress local protection 449 through checking the SERO with egress protection subobject in the 450 message. If there is an egress protection subobject in the Path 451 message for the LSP and the Egress local protection flag in the 452 object is set to one, the LSP is the backup LSP for egress local 453 protection. The primary egress node to be protected is in the 454 primary egress subobject in the SERO. 456 When the backup egress node receives the information about a UA label 457 and its related forwarding from the primary egress node, it uses the 458 backup LSP label as a context label and creates a forwarding entry 459 using the information about the UA label and the related forwarding. 460 This forwarding entry is in a forwarding table for the primary egress 461 node. 463 When the primary egress node fails, its upstream node switches the 464 traffic from the primary LSP to the backup LSP to the backup egress 465 node, which delivers the traffic to its receiver such as CE using the 466 backup LSP label as a context label to get the forwarding table for 467 the primary egress node and the service label as UA label to find the 468 forwarding entry in the table to forward the traffic to the receiver. 470 5.4. Transit Node and PLR Behavior 472 If a transit node of an LSP receives the Path message with the SEROs 473 and it is not an upstream node of any primary egress node of the LSP 474 as a branch node, it MUST forward them unchanged. 476 If the transit node is the upstream node of a primary egress node to 477 be protected as a branch node, it determines the backup egress node, 478 obtains a path for the backup LSP and sets up the backup LSP along 479 the path. If the upstream node receives the Resv message with an 480 SERO object, it MUST sends its upstream node the Resv message without 481 the object. 483 The PLR (upstream node of the primary egress node as the branch node) 484 MUST extract the backup egress node from the respective SERO object 485 in either a Path or a Resv message. If no matching SERO object is 486 found, the PLR tries to find the backup egress node, which is not the 487 primary egress node but has the same IP address as the destination IP 488 address of the LSP. 490 Note that if a backup egress node is not configured explicitly for 491 protecting a primary egress node, the primary egress node and the 492 backup egress node SHOULD have a same local address configured, and 493 the cost to the local address on the backup egress node SHOULD be 494 much bigger than the cost to the local address on the primary egress 495 node. Thus primary egress node and backup egress node is considered 496 as a virtual node. Note that the backup egress node is different 497 from this local address (e.g., from the primary egress node' view). 498 In other words, it is identified by an address different from this 499 local address. 501 After obtaining the backup egress node, the PLR computes a backup 502 path from itself to the backup egress node and sets up a backup LSP 503 along the path. It excludes the segment including the primary egress 504 node to be protected when computing the path. The PLR sends the 505 primary egress node a Path message with an SERO for the primary LSP, 506 which indicates the backup egress node by the final subobject in the 507 SERO. The PLR puts an SERO into the Path messages for the backup 508 LSP, which indicates the primary egress node. 510 The PLR MUST provide one-to-one backup protection for the primary 511 egress node if the "One-to-One Backup Desired" flag is set in the 512 message; otherwise, it MUST provide facility backup protection if the 513 "Facility Backup Desired flag" is set. 515 The PLR MUST set the protection flags in the RRO Sub-object for the 516 primary egress node in the Resv message according to the status of 517 the primary egress node and the backup LSP protecting the primary 518 egress node. For example, it sets the "local protection available" 519 and the "node protection" flag indicating that the primary egress 520 node is protected when the backup LSP is up and ready for protecting 521 the primary egress node. 523 5.4.1. Signaling for One-to-One Protection 525 The behavior of the upstream node of a primary egress node of an LSP 526 as a PLR is the same as that of a PLR for one-to-one backup described 527 in RFC 4090 except for that the upstream node as a PLR creates a 528 backup LSP from itself to a backup egress node in a session different 529 from the primary LSP. 531 If the LSP is a P2MP LSP and a primary egress node of the LSP is also 532 a transit node (i.e., bud node), the upstream node of the primary 533 egress node as a PLR creates a backup LSP from itself to each of the 534 next hops of the primary egress node. 536 When the PLR detects the failure of the primary egress node, it 537 switches the packets from the primary LSP to the backup LSP to the 538 backup egress node. For the failure of the bud node of a P2MP LSP, 539 the PLR also switches the packets to the backup LSPs to the bud 540 node's next hops, where the packets are merged into the primary LSP. 542 5.4.2. Signaling for Facility Protection 544 Except for backup LSP and downstream label, the behavior of the 545 upstream node of the primary egress node of a primary LSP as a PLR 546 follows the PLR behavior for facility backup described in RFC 4090. 548 For a number of primary P2P LSPs going through the same PLR to the 549 same primary egress node, the primary egress node of these LSPs MAY 550 be protected by one backup LSP from the PLR to the backup egress node 551 designated for protecting the primary egress node. 553 The PLR selects or creates a backup LSP from itself to the backup 554 egress node. If there is a backup LSP that satisfies the constraints 555 given in the Path message, then this one is selected; otherwise, a 556 new backup LSP to the backup egress node is created. 558 After getting the backup LSP, the PLR associates the backup LSP with 559 a primary LSP for protecting its primary egress node. The PLR 560 records that the backup LSP is used to protect the primary LSP 561 against its primary egress node failure and MUST include an SERO 562 object in the Path message for the primary LSP. The object MUST 563 contain the backup LSP ID. It indicates that the primary egress node 564 MUST send the backup egress node the service label as UA label and 565 the information about forwarding the traffic to its destination using 566 the label if there is a service carried by the LSP and the primary 567 LSP label as UA label if the label is not implicit null. How UA 568 label is sent is out of scope for this document. 570 When the PLR detects the failure of the primary egress node, it 571 redirects the packets from the primary LSP into the backup LSP to 572 backup egress node and keeps the primary LSP label from the primary 573 egress node in the label stack if the label is not implicit null. 574 The backup egress node delivers the packets to the same destinations 575 as the primary egress node using the backup LSP label as context 576 label and the labels under as UA labels. 578 5.4.3. Signaling for S2L Sub LSP Protection 580 The S2L Sub LSP Protection uses a S2L Sub LSP (ref to RFC 4875) as a 581 backup LSP to protect a primary egress node of a P2MP LSP. The PLR 582 MUST determine to protect a primary egress node of a P2MP LSP via S2L 583 sub LSP protection when it receives a Path message with flag "S2L Sub 584 LSP Backup Desired" set. 586 The PLR MUST set up the backup S2L sub LSP to the backup egress node, 587 create and maintain its state in the same way as of setting up a 588 source to leaf (S2L) sub LSP defined in RFC 4875 from the signaling's 589 point of view. It computes a path for the backup LSP from itself to 590 the backup egress node, constructs and sends a Path message along the 591 path, receives and processes a Resv message responding to the Path 592 message. 594 After receiving the Resv message for the backup LSP, the PLR creates 595 a forwarding entry with an inactive state or flag called inactive 596 forwarding entry. This inactive forwarding entry is not used to 597 forward any data traffic during normal operations. 599 When the PLR detects the failure of the primary egress node, it 600 changes the forwarding entry for the backup LSP to active. Thus, the 601 PLR forwards the traffic to the backup egress through the backup LSP, 602 which sends the traffic to its destination. 604 5.4.4. PLR Procedures during Local Repair 606 When the upstream node of a primary egress node of an LSP as a PLR 607 detects the failure of the primary egress node, it follows the 608 procedures defined in section 6.5 of RFC 4090. It SHOULD notify the 609 ingress about the failure of the primary egress node in the same way 610 as a PLR notifies the ingress about the failure of a transit node. 612 Moreover, the PLR MUST let the upstream part of the primary LSP stay 613 alive after the primary egress node fails through sending Resv 614 message to its upstream node along the primary LSP. The downstream 615 part of the primary LSP from the PLR to the primary egress node 616 SHOULD be removed. When a bypass LSP from the PLR to a backup egress 617 node protects the primary egress node, the PLR MUST NOT send any Path 618 message for the primary LSP through the bypass LSP to the backup 619 egress node. 621 In the local revertive mode, the PLR will re-signal each of the 622 primary LSPs that were routed over the restored resource once it 623 detects that the resource is restored. Every primary LSP 624 successfully re-signaled along the restored resource will be switched 625 back. 627 Note that the procedure for protecting the primary egress node is 628 triggered on the PLR if the primary egress node failure is 629 determined. If link (from PLR to primary egress node) failure and 630 primary egress node alive are determined, then link protection 631 procedure is triggered on the PLR. How to determine these is out of 632 scope for this document. 634 6. Application Traffic Considerations 636 This section focuses on an example with application traffic carried 637 by P2P LSPs. 639 6.1. A Typical Application 641 L3VPN is a typical application. Figure 2 below shows a simple VPN, 642 which consists of two CEs, CE1 and CE2, connected to two PEs, R1 and 643 L1, respectively. There is a P2P LSP from R1 to L1, which is 644 represented by stars (****). This LSP is called the primary LSP. R1 645 is the ingress of the LSP and L1 is the (primary) egress node of the 646 LSP. R1 sends the VPN traffic received from CE1 through the P2P LSP 647 to L1, which delivers the traffic to CE2. R1 sends the VPN traffic 648 with a LSP label and a VPN label via the LSP. When the traffic 649 reaches the egress node L1 of the LSP, L1 pops the LSP label and uses 650 the VPN label to deliver the traffic to CE2. 652 In previous solutions based on ingress protection to protect the VPN 653 traffic against failure of the egress node L1 of the LSP, when the 654 egress node fails, the ingress R1 of the LSP does the reroute (refer 655 to Figure 2). This solution entailed: 657 1. A multi-hop BFD session between ingress R1 and egress node L1 of 658 primary LSP. The BFD session is represented by dots (....). 660 2. A backup LSP from ingress R1 to backup egress node La, which is 661 indicated by ands (&&&&). 663 3. La sends R1 a VPN backup label and related information via BGP. 665 4. R1 has a VRF with two sets of routes for CE2: one set uses the 666 primary LSP and L1 as next hop; the other uses the backup LSP and 667 La as next hop. 669 ***** ***** 670 CE1,CE2 in [R2]-----[R3]-----[L1] **** Primary LSP 671 one VPN */ : \ &&&& Backup LSP 672 */ .................: \ .... BFD Session 673 [CE1]--[R1] ..: [CE2] 674 &\ / 675 &\ / 676 [R4]-----[R5]-----[La](BGP sends R1 VPN backup label) 677 &&&&& &&&&& 679 Figure 2: Protect Egress for L3VPN Traffic 681 In normal operations, R1 sends the VPN traffic from CE1 through the 682 primary LSP with the VPN label received from L1 as inner label to L1, 683 which delivers the traffic to CE2 using the VPN label. 685 When R1 detects the failure of L1, R1 sends the traffic from CE1 via 686 the backup LSP with the VPN backup label received from La as inner 687 label to La, which delivers the traffic to CE2 using the VPN backup 688 label. 690 The solution defined in this document using egress local protection 691 for protecting L3VPN traffic entails (refer to Figure 3): 693 1. A BFD session between R3 (i.e., upstream of L1) and egress node 694 L1 of the primary LSP. This is different from the BFD session in 695 Figure 2, which is multi-hop between ingress R1 and egress node 696 L1. The PLR R3 is closer to L1 than the ingress R1. It may 697 detect the failure of the egress node L1 faster and more 698 reliably. Therefore, this solution can provide faster protection 699 for failure of an egress node. 701 2. A backup LSP from R3 to backup egress node La. This is different 702 from the backup LSP in Figure 2, which is an end to end LSP from 703 ingress R1 to backup egress node La. 705 3. Primary egress node L1 sends backup egress node La the VPN label 706 as UA label and related information. The backup egress node La 707 uses the backup LSP label as a context label and creates a 708 forwarding entry using the VPN label in a LFIB for the primary 709 egress node L1. 711 4. L1 and La is virtualized as one node (or address). R1 has a VRF 712 with one set of routes for CE2, using the primary LSP from R1 to 713 L1 and virtualized node as next hop. This can be achieved by 714 configuring a same local address on L1 and La, using the address 715 as a destination of the LSP and BGP next hop for the VPN traffic. 716 The cost to L1 is configured to be less than the cost to La. 718 ***** ***** 719 CE1,CE2 in [R2]-----[R3]-----[L1] **** Primary LSP 720 one VPN */ &\:.....: \ &&&& Backup LSP 721 */ &\ \ .... BFD Session 722 [CE1]--[R1] &\ [CE2] 723 &\ / 724 &\ / 725 [La](VPN label from L1 as UA label) 727 Figure 3: Locally Protect Egress for L3VPN Traffic 729 In normal operations, R1 sends the VPN traffic from CE1 via the 730 primary LSP with the VPN label as inner label to L1, which delivers 731 the traffic to CE2 using the VPN label. 733 When the primary egress node L1 fails, its upstream node R3 detects 734 it and switches the VPN traffic from the primary LSP to the backup 735 LSP to La, which delivers the traffic to CE2 using the backup LSP 736 label as a context label to get the LFIB for L1 and the VPN label as 737 UA label to find the forwarding entry in the LFIB to forward the 738 traffic to CE2. 740 6.2. PLR Procedure for Applications 742 When the PLR gets a backup LSP from itself to a backup egress node 743 for protecting a primary egress node of a primary LSP, it includes an 744 SERO object in the Path message for the primary LSP. The object 745 contains the ID information of the backup LSP and indicates that the 746 primary egress node sends the backup egress node the application 747 traffic label (e.g., the VPN label) as UA label when needed. 749 6.3. Egress Procedures for Applications 751 When a primary egress node of an LSP sends the ingress of the LSP a 752 label for an application such as a VPN label, it sends the backup 753 egress node for protecting the primary egress node the label as a UA 754 label. Exactly how the label is sent is out of scope for this 755 document. 757 When the backup egress node receives a UA label from the primary 758 egress node, it adds a forwarding entry with the label into the LFIB 759 for the primary egress node. When the backup egress node receives a 760 packet from the backup LSP, it uses the top label as a context label 761 to find the LFIB for the primary egress node and the inner label to 762 deliver the packet to the same destination as the primary egress node 763 according to the LFIB. 765 7. Security Considerations 767 This document builds upon existing work, specifically the security 768 considerations of RFCs 4090, 4875, 3209 and 2205 continue to apply. 769 Additionally, protecting a primary egress node of a P2P LSP carrying 770 service traffic through a backup egress node requires an out-of-band 771 communication between the primary egress node and the backup egress 772 node, in order for the primary egress node to convey a service label 773 as UA label and its related forwarding information to the backup 774 egress node. It is important to confirm that the identifiers used to 775 identify the primary and backup egress nodes in the LSP are verified 776 to match with the identifiers used in the out-of-band protocol (such 777 as BGP). 779 8. IANA Considerations 781 IANA maintains a registry called "Class Names, Class Numbers, and 782 Class Types" under "Resource Reservation Protocol (RSVP) Parameters". 783 IANA is requested to assign a new C-Type under PROTECTION object 784 class, Class Number 37: 786 Value Description Definition 787 ----- ----------- ---------- 788 TBA1(suggested value 3) Egress Protection Section 4.1 790 IANA is requested to create and maintain a new registry under 791 PROTECTION object class (Class Number 37) and Egress Protection 792 (C-Type TBA1). Initial values for the registry are given below. The 793 future assignments are to be made through IETF Review (RFC 8216). 795 Value Name Definition 796 ----- ---- ---------- 797 0 Reserved 798 1 IPv4_PRIMARY_EGRESS Section 4.1.1 799 2 IPv6_PRIMARY_EGRESS Section 4.1.1 800 3 IPv4_P2P_LSP_ID Section 4.1.2 801 4 IPv6_P2P_LSP_ID Section 4.1.2 802 5-127 Unassigned 803 128-255 Reserved 805 9. Co-authors and Contributors 807 1. Co-authors 809 Ning So 810 Tata 811 E-mail: ningso01@gmail.com 813 Mehmet Toy 814 Verizon 815 E-mail: mehmet.toy@verizon.com 817 Lei Liu 818 Fujitsu 819 E-mail: lliu@us.fujitsu.com 821 Zhenbin Li 822 Huawei Technologies 823 Email: lizhenbin@huawei.com 825 2. Contributors 827 Boris Zhang 828 Telus Communications 829 Email: Boris.Zhang@telus.com 831 Nan Meng 832 Huawei Technologies 833 Email: mengnan@huawei.com 834 Prejeeth Kaladharan 835 Huawei Technologies 836 Email: prejeeth@gmail.com 838 Vic Liu 839 China Mobile 840 Email: liu.cmri@gmail.com 842 10. Acknowledgement 844 The authors would like to thank Richard Li, Nobo Akiya, Lou Berger, 845 Jeffrey Zhang, Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, 846 Michael Yue, Daniel King, Rob Rennison, Neil Harrison, Kannan 847 Sampath, Yimin Shen, Ronhazli Adam and Quintin Zhao for their 848 valuable comments and suggestions on this draft. 850 11. References 852 11.1. Normative References 854 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 855 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 856 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 857 . 859 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 860 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 861 DOI 10.17487/RFC4090, May 2005, 862 . 864 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 865 Yasukawa, Ed., "Extensions to Resource Reservation 866 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 867 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 868 DOI 10.17487/RFC4875, May 2007, 869 . 871 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 872 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 873 May 2007, . 875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 876 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 877 RFC2119, March 1997, 878 . 880 11.2. Informative References 882 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 883 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 884 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 885 September 1997, . 887 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 888 Label Assignment and Context-Specific Label Space", 889 RFC 5331, DOI 10.17487/RFC5331, August 2008, 890 . 892 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 893 Ed., "RSVP-TE Extensions in Support of End-to-End 894 Generalized Multi-Protocol Label Switching (GMPLS) 895 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 896 . 898 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 899 Switching (GMPLS) Signaling Resource ReserVation Protocol- 900 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 901 DOI 10.17487/RFC3473, January 2003, 902 . 904 [FRAMEWK] Shen, Y., Jeyananth, M., Decraene, B., and H. Gredler, 905 "MPLS Egress Protection Framework", 906 draft-shen-mpls-egress-protection-framework , 907 October 2016. 909 Authors' Addresses 911 Huaimo Chen 912 Huawei Technologies 913 Boston, MA 914 USA 916 Email: huaimo.chen@huawei.com 918 Autumn Liu 919 Ciena 920 USA 922 Email: hliu@ciena.com 923 Tarek Saad 924 Cisco Systems 926 Email: tsaad@cisco.com 928 Fengman Xu 929 Verizon 930 2400 N. Glenville Dr 931 Richardson, TX 75082 932 USA 934 Email: fengman.xu@verizon.com 936 Lu Huang 937 China Mobile 938 No.32 Xuanwumen West Street, Xicheng District 939 Beijing, 100053 940 China 942 Email: huanglu@chinamobile.com