idnits 2.17.1 draft-ietf-teas-rsvp-ingress-protection-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 8, 2016) is 2812 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'S' is mentioned on line 128, but not defined == Missing Reference: 'Ra' is mentioned on line 131, but not defined == Missing Reference: 'Rb' is mentioned on line 131, but not defined == Missing Reference: 'L3' is mentioned on line 131, but not defined == Unused Reference: 'RFC2119' is defined on line 943, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 948, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 953, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Experimental R. Torvi, Ed. 5 Expires: February 9, 2017 Juniper Networks 6 August 8, 2016 8 Extensions to RSVP-TE for LSP Ingress Local Protection 9 draft-ietf-teas-rsvp-ingress-protection-07.txt 11 Abstract 13 This document describes extensions to Resource Reservation Protocol - 14 Traffic Engineering (RSVP-TE) for locally protecting the ingress node 15 of a Traffic Engineered (TE) Label Switched Path (LSP), which is a 16 Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 9, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. An Example of Ingress Local Protection . . . . . . . . . . 3 55 2.2. Ingress Local Protection with FRR . . . . . . . . . . . . 4 56 3. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 4 57 3.1. Source Detects Failure . . . . . . . . . . . . . . . . . . 4 58 3.2. Backup and Source Detect Failure . . . . . . . . . . . . . 5 59 4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 5 60 4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 5 61 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 6 63 5.1.1. Subobject: Backup Ingress IPv4 Address . . . . . . . . 7 64 5.1.2. Subobject: Backup Ingress IPv6 Address . . . . . . . . 8 65 5.1.3. Subobject: Ingress IPv4 Address . . . . . . . . . . . 8 66 5.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 8 67 5.1.5. Subobject: Traffic Descriptor . . . . . . . . . . . . 9 68 5.1.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 9 69 6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 10 70 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 10 72 6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 11 73 6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 12 74 6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 12 75 6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13 76 6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 13 77 6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 14 78 6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 14 79 6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 17 80 6.3.3. Failure Detection and Refresh PATH Messages . . . . . 17 81 6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 18 82 6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 18 83 6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 19 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 8.1. A New Class Number . . . . . . . . . . . . . . . . . . . . 19 87 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 89 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21 90 A. Problem Summary . . . . . . . . . . . . . . . . . . . . . . . 22 91 B. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Co-authors 95 Ning So, Autumn Liu, Yimin Shen, Tarek Saad, Fengman Xu, Mehmet Toy, 96 Lei Liu 98 2. Introduction 100 For a MPLS LSP it is important to have a fast-reroute method for 101 protecting its ingress node and transit nodes. Protecting an ingress 102 is not covered either in the fast-reroute method defined in [RFC4090] 103 or in the P2MP fast-reroute extensions to fast-reroute in [RFC4875]. 105 An alternate approach to local protection (fast-reroute) is to use 106 global protection and set up a secondary backup LSP (whether P2MP or 107 P2P) from a backup ingress to the egresses. The main disadvantage of 108 this is that the backup LSP may reserve additional network bandwidth. 110 This specification defines a simple extension to RSVP-TE for local 111 protection of the ingress node of a P2MP or P2P LSP. 113 2.1. An Example of Ingress Local Protection 115 Figure 1 shows an example of using a backup P2MP LSP to locally 116 protect the ingress of a primary P2MP LSP, which is from ingress R1 117 to three egresses: L1, L2 and L3. The backup LSP is from backup 118 ingress Ra to the next hops R2 and R4 of ingress R1. 120 [R2]******[R3]*****[L1] 121 * | **** Primary LSP 122 * | ---- Backup LSP 123 * / .... BFD Session 124 * / $ Link 125 ....[R1]*******[R4]****[R5]*****[L2] $ 126 : $ $ / / * $ 127 : $ $ / / * 128 [S] $ / / * 129 $ $ / / * 130 $ $/ / * 131 [Ra]----[Rb] [L3] 133 Figure 1: Backup P2MP LSP for Locally Protecting Ingress 135 In normal operations, source S sends the traffic to primary ingress 136 R1. R1 imports the traffic into the primary LSP. 138 When source S detects the failure of R1, it switches the traffic to 139 backup ingress Ra, which imports the traffic from S into the backup 140 LSP to R1's next hops R2 and R4, where the traffic is merged into the 141 primary LSP, and then sent to egresses L1, L2 and L3. Source S 142 detects the failure of R1 and switches the traffic within 10s of ms. 144 Note that the backup ingress is one logical hop away from the 145 ingress. A logical hop is a direct link or a tunnel such as a GRE 146 tunnel, over which RSVP-TE messages may be exchanged. 148 2.2. Ingress Local Protection with FRR 150 Through using the ingress local protection and the FRR, we can 151 locally protect the ingress, all the links and the transit nodes of 152 an LSP. The traffic switchover time is within 10s of ms whenever the 153 ingress, any of the links and the transit nodes of the LSP fails. 155 The ingress node of the LSP can be locally protected through using 156 the ingress local protection. All the links and all the transit 157 nodes of the LSP can be locally protected through using the FRR. 159 3. Ingress Failure Detection 161 Exactly how to detect the failure of the ingress is out of scope. 162 However, it is necessary to discuss different modes for detecting the 163 failure because they determine what is the required behavior for the 164 source and backup ingress. 166 3.1. Source Detects Failure 168 Source Detects Failure or Source-Detect for short means that the 169 source is responsible for fast detecting the failure of the primary 170 ingress of an LSP. The backup ingress is ready to import the traffic 171 from the source into the backup LSP(s) after the backup LSP(s) is up. 173 In normal operations, the source sends the traffic to the primary 174 ingress. When the source detects the failure of the primary ingress, 175 it switches the traffic to the backup ingress, which delivers the 176 traffic to the next hops of the primary ingress through the backup 177 LSP(s), where the traffic is merged into the primary LSP. 179 For a P2P LSP, after the primary ingress fails, the backup ingress 180 MUST use a method to reliably detect the failure of the primary 181 ingress before the PATH message for the LSP expires at the next hop 182 of the primary ingress. After reliably detecting the failure, the 183 backup ingress sends/refreshes the PATH message to the next hop 184 through the backup LSP as needed. 186 After the primary ingress fails, it will not be reachable after 187 routing convergence. Thus checking whether the primary ingress 188 (address) is reachable is a possible method. 190 3.2. Backup and Source Detect Failure 192 Backup and Source Detect Failure or Backup-Source-Detect for short 193 means that both the backup ingress and the source are concurrently 194 responsible for fast detecting the failure of the primary ingress. 196 In normal operations, the source sends the traffic to the primary 197 ingress. It switches the traffic to the backup ingress when it 198 detects the failure of the primary ingress. 200 The backup ingress does not import any traffic from the source into 201 the backup LSP in normal operations. When it detects the failure of 202 the primary ingress, it imports the traffic from the source into the 203 backup LSP to the next hops of the primary ingress, where the traffic 204 is merged into the primary LSP. 206 The source-detect is preferred. It is simpler than the backup- 207 source-detect, which needs both the source and the backup ingress 208 detect the ingress failure quickly. 210 4. Backup Forwarding State 212 Before the primary ingress fails, the backup ingress is responsible 213 for creating the necessary backup LSPs. These LSPs might be multiple 214 bypass P2P LSPs that avoid the ingress. Alternately, the backup 215 ingress could choose to use a single backup P2MP LSP as a bypass or 216 detour to protect the primary ingress of a primary P2MP LSP. 218 The backup ingress may be off-path or on-path of an LSP. If a backup 219 ingress is not any node of the LSP, we call it is off-path. If a 220 backup ingress is a next-hop of the primary ingress of the LSP, we 221 call it is on-path. If it is on-path, the primary forwarding state 222 associated with the primary LSP SHOULD be clearly separated from the 223 backup LSP(s) state. 225 4.1. Forwarding State for Backup LSP 227 A forwarding entry for a backup LSP is created on the backup ingress 228 after the LSP is set up. Depending on the failure-detection mode 229 (e.g., source-detect), it may be used to forward received traffic or 230 simply be inactive (e.g., backup-source-detect) until required. In 231 either case, when the primary ingress fails, this entry is used to 232 import the traffic into the backup LSP to the next hops of the 233 primary ingress, where the traffic is merged into the primary LSP. 235 The forwarding entry for a backup LSP is a local implementation 236 issue. In one device, it may have an inactive flag. This inactive 237 forwarding entry is not used to forward any traffic normally. When 238 the primary ingress fails, it is changed to active, and thus the 239 traffic from the source is imported into the backup LSP. 241 5. Protocol Extensions 243 A new object INGRESS_PROTECTION is defined for signaling ingress 244 local protection. It is backward compatible. 246 5.1. INGRESS_PROTECTION Object 248 The INGRESS_PROTECTION object with the FAST_REROUTE object in a PATH 249 message is used to control the backup for protecting the primary 250 ingress of a primary LSP. The primary ingress MUST insert this 251 object into the PATH message to be sent to the backup ingress for 252 protecting the primary ingress. It has the following format: 254 Class-Num = TBD C-Type = 1 for INGRESS_PROTECTION_IPv4 255 C-Type = 2 for INGRESS_PROTECTION_IPv6 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Length (bytes) | Class-Num | C-Type | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Reserved (zero) | NUB | Flags | Options | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 ~ (Subobjects) ~ 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 NUB Number of Unprotected Branches 266 Flags 267 0x01 Ingress local protection available 268 0x02 Ingress local protection in use 269 0x04 Bandwidth protection 271 Options 272 0x01 Revert to Ingress 273 0x02 P2MP Backup 275 For protecting the ingress of a P2MP LSP, if the backup ingress 276 doesn't have a backup LSP to each of the next hops of the primary 277 ingress, it SHOULD clear "Ingress local protection available" and set 278 NUB to the number of the next hops to which there is no backup LSP. 280 The flags are used to communicate status information from the backup 281 ingress to the primary ingress. 283 o Ingress local protection available: The backup ingress sets this 284 flag after backup LSPs are up and ready for locally protecting the 285 primary ingress. The backup ingress sends this to the primary 286 ingress to indicate that the primary ingress is locally protected. 288 o Ingress local protection in use: The backup ingress sets this flag 289 when it detects a failure in the primary ingress. The backup 290 ingress keeps it and does not send it to the primary ingress since 291 the primary ingress is down. 293 o Bandwidth protection: The backup ingress sets this flag if the 294 backup LSPs guarantee to provide desired bandwidth for the 295 protected LSP against the primary ingress failure. 297 The options are used by the primary ingress to specify the desired 298 behavior to the backup ingress. 300 o Revert to Ingress: The primary ingress sets this option indicating 301 that the traffic for the primary LSP successfully re-signaled will 302 be switched back to the primary ingress from the backup ingress 303 when the primary ingress is restored. 305 o P2MP Backup: This option is set to ask for the backup ingress to 306 use P2MP backup LSP to protect the primary ingress. 308 The INGRESS_PROTECTION object may contain some sub objects below. 310 5.1.1. Subobject: Backup Ingress IPv4 Address 312 When the primary ingress of a protected LSP sends a PATH message with 313 an INGRESS_PROTECTION object to the backup ingress, the object MUST 314 have a Backup Ingress IPv4 Address sub object containing an IPv4 315 address belonging to the backup ingress if IPv4 is used. The Type of 316 the sub object is TBD1 (the exact number to be assigned by IANA), and 317 the body of the sub object is given below: 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Backup ingress IPv4 address (4 bytes) | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Backup ingress IPv4 address: An IPv4 host address of backup ingress 327 5.1.2. Subobject: Backup Ingress IPv6 Address 329 When the primary ingress of a protected LSP sends a PATH message with 330 an INGRESS_PROTECTION object to the backup ingress, the object MUST 331 have a Backup Ingress IPv6 Address sub object containing an IPv6 332 address belonging to the backup ingress if IPv6 is used. The Type of 333 the sub object is TBD2, the body of the sub object is given below: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Backup ingress IPv6 address (16 bytes) | 339 ~ ~ 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Backup ingress IPv6 address: An IPv6 host address of backup ingress 344 5.1.3. Subobject: Ingress IPv4 Address 346 The INGRESS_PROTECTION object may have an Ingress IPv4 Address sub 347 object containing an IPv4 address belonging to the primary ingress. 348 The Type of the sub object is TBD3. The sub object has the following 349 body: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Ingress IPv4 address (4 bytes) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Ingress IPv4 address: An IPv4 host address of ingress 359 5.1.4. Subobject: Ingress IPv6 Address 361 The INGRESS_PROTECTION object may have an Ingress IPv6 Address sub 362 object containing an IPv6 address belonging to the primary ingress. 363 The Type of the sub object is TBD4. The sub object has the following 364 body: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Ingress IPv6 address (16 bytes) | 370 ~ ~ 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Ingress IPv6 address: An IPv6 host address of ingress 374 5.1.5. Subobject: Traffic Descriptor 376 The INGRESS_PROTECTION object may have a Traffic Descriptor sub 377 object describing the traffic to be mapped to the backup LSP on the 378 backup ingress for locally protecting the primary ingress. The Type 379 of the sub object is TBD5, TBD6, TBD7 or TBD8 for Interface, IPv4 380 Prefix, IPv6 Prefix or Application Identifier respectively. The sub 381 object has the following body: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Traffic Element 1 | 387 ~ ~ 388 | Traffic Element n | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 The Traffic Descriptor sub object may contain multiple Traffic 392 Elements of same type as follows: 394 o Interface Traffic (Type TBD5): Each of the Traffic Elements is a 395 32 bit index of an interface, from which the traffic is imported 396 into the backup LSP. 398 o IPv4 Prefix Traffic (Type TBD6): Each of the Traffic Elements is 399 an IPv4 prefix, containing an 8-bit prefix length followed by an 400 IPv4 address prefix, whose length, in bits, is specified by the 401 prefix length, padded to a byte boundary. 403 o IPv6 Prefix Traffic (Type TBD7): Each of the Traffic Elements is 404 an IPv6 prefix, containing an 8-bit prefix length followed by an 405 IPv6 address prefix, whose length, in bits, is specified by the 406 prefix length, padded to a byte boundary. 408 o Application Traffic (Type TBD8): Each of the Traffic Elements is a 409 32 bit identifier of an application, from which the traffic is 410 imported into the backup LSP. 412 5.1.6. Subobject: Label-Routes 414 The INGRESS_PROTECTION object in a PATH message from the primary 415 ingress to the backup ingress will have a Label-Routes sub object 416 containing the labels and routes that the next hops of the ingress 417 use. The Type of the sub object is TBD9. The sub object has the 418 following body: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 ~ Subobjects ~ 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 The Subobjects in the Label-Routes are copied from those in the 427 RECORD_ROUTE objects in the RESV messages that the primary ingress 428 receives from its next hops for the primary LSP. They MUST contain 429 the first hops of the LSP, each of which is paired with its label. 431 6. Behavior of Ingress Protection 433 6.1. Overview 435 There are four parts of ingress protection: 1) setting up the 436 necessary backup LSP forwarding state; 2) identifying the failure and 437 providing the fast repair (as discussed in Sections 3 and 4); 3) 438 maintaining the RSVP-TE control plane state until a global repair is 439 done; and 4) performing the global repair(see Section 6.4). 441 There are two different proposed signaling approaches to obtain 442 ingress protection. They both use the same new INGRESS_PROTECTION 443 object. The object is sent in both PATH and RESV messages. 445 6.1.1. Relay-Message Method 447 The primary ingress relays the information for ingress protection of 448 an LSP to the backup ingress via PATH messages. Once the LSP is 449 created, the ingress of the LSP sends the backup ingress a PATH 450 message with an INGRESS_PROTECTION object with Label-Routes 451 subobject, which is populated with the next-hops and labels. This 452 provides sufficient information for the backup ingress to create the 453 appropriate forwarding state and backup LSP(s). 455 The ingress also sends the backup ingress all the other PATH messages 456 for the LSP with an empty INGRESS_PROTECTION object. An 457 INGRESS_PROTECTION object without any Traffic-Descriptor sub-object 458 is called an empty INGRESS_PROTECTION object. Thus, the backup 459 ingress has access to all the PATH messages needed for modification 460 to refresh control-plane state after a failure. 462 The advantages of this method include: 1) the primary LSP is 463 independent of the backup ingress; 2) simple; 3) less configuration; 464 and 4) less control traffic. 466 6.1.2. Proxy-Ingress Method 468 Conceptually, a proxy ingress is created that starts the RSVP 469 signaling. The explicit path of the LSP goes from the proxy ingress 470 to the backup ingress and then to the real ingress. The behavior and 471 signaling for the proxy ingress is done by the real ingress; the use 472 of a proxy ingress address avoids problems with loop detection. 474 [ traffic source ] *** Primary LSP 475 $ $ --- Backup LSP 476 $ $ $$ Link 477 $ $ 478 [ proxy ingress ] [ backup ] 479 [ & ingress ] | 480 * | 481 *****[ MP ]----| 483 Figure 2: Example Protected LSP with Proxy Ingress Node 485 The backup ingress must know the merge points or next-hops and their 486 associated labels. This is accomplished by having the RSVP PATH and 487 RESV messages go through the backup ingress, although the forwarding 488 path need not go through the backup ingress. If the backup ingress 489 fails, the ingress simply removes the INGRESS_PROTECTION object and 490 forwards the PATH messages to the LSP's next-hop(s). If the ingress 491 has its LSP configured for ingress protection, then the ingress can 492 add the backup ingress and itself to the ERO and start forwarding the 493 PATH messages to the backup ingress. 495 Slightly different behavior can apply for the on-path and off-path 496 cases. In the on-path case, the backup ingress is a next hop node 497 after the ingress for the LSP. In the off-path, the backup ingress 498 is not any next-hop node after the ingress for all associated sub- 499 LSPs. 501 The key advantage of this approach is that it minimizes the special 502 handling code requires. Because the backup ingress is on the 503 signaling path, it can receive various notifications. It easily has 504 access to all the PATH messages needed for modification to be sent to 505 refresh control-plane state after a failure. 507 6.1.3. Comparing Two Methods 509 +-------+-----------+-------+--------------+---------------+---------+ 510 |\_ Item|Primary LSP|Config |PATH Msg from |RESV Msg from |Reuse | 511 | \_ |Depends on |Proxy- |Backup Ingress|Primary Ingress|Some | 512 | \|Backup |Ingress|to Primary |to Backup |Existing | 513 |Method |Ingress |ID |Ingress |Ingress |Functions| 514 +-------+-----------+-------+--------------+---------------+---------+ 515 |Relay- | No | No | No | No | Yes- | 516 |Message| | | | | | 517 +-------+-----------+-------+--------------+---------------+---------+ 518 |Proxy- | Yes | Yes- | Yes | Yes | Yes | 519 |Ingress| | | | | | 520 +-------+-----------+-------+--------------+---------------+---------+ 522 6.2. Ingress Behavior 524 The primary ingress MUST be configured with a couple of pieces of 525 information for ingress protection. 527 o Backup Ingress Address: The primary ingress MUST know an IP 528 address for it to be included in the INGRESS_PROTECTION object. 530 o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The 531 Proxy-Ingress-Id is only used in the Record Route Object for 532 recording the proxy-ingress. If no proxy-ingress-id is specified, 533 then a local interface address that will not otherwise be included 534 in the Record Route Object can be used. A similar technique is 535 used in [RFC4090 Sec 6.1.1]. 537 o Application Traffic Identifier: The primary ingress and backup 538 ingress MUST both know what application traffic should be directed 539 into the LSP. If a list of prefixes in the Traffic Descriptor 540 sub-object will not suffice, then a commonly understood 541 Application Traffic Identifier can be sent between the primary 542 ingress and backup ingress. The exact meaning of the identifier 543 should be configured similarly at both the primary ingress and 544 backup ingress. The Application Traffic Identifier is understood 545 within the unique context of the primary ingress and backup 546 ingress. 548 o A connection between backup ingress and primary ingress: If there 549 is not any direct link between the primary ingress and the backup 550 ingress, a tunnel MUST be configured between them. 552 With this additional information, the primary ingress can create and 553 signal the necessary RSVP extensions to support ingress protection. 555 6.2.1. Relay-Message Method 557 To protect the ingress of an LSP, the ingress MUST do the following 558 after the LSP is up. 560 1. Select a PATH message. 562 2. If the backup ingress is off-path, then send it a PATH message 563 with the content from the selected PATH message and an 564 INGRESS_PROTECTION object; else (the backup ingress is a next 565 hop, i.e., on-path case) add an INGRESS_PROTECTION object into 566 the existing PATH message to the backup ingress (i.e., the next 567 hop). The object contains the Traffic-Descriptor sub-object, the 568 Backup Ingress Address sub-object and the Label-Routes sub- 569 object. The options is set to indicate whether a Backup P2MP LSP 570 is desired. The Label-Routes sub-object contains the next-hops 571 of the ingress and their labels. 573 3. For each of the other PATH messages, send the backup ingress a 574 PATH message with the content copied from the message and an 575 empty INGRESS_PROTECTION object. 577 6.2.2. Proxy-Ingress Method 579 The primary ingress is responsible for starting the RSVP signaling 580 for the proxy-ingress node. To do this, the following MUST be done 581 for the RSVP PATH message. 583 1. Compute the EROs for the LSP as normal for the ingress. 585 2. If the selected backup ingress node is not the first node on the 586 path (for all sub-LSPs), then insert at the beginning of the ERO 587 first the backup ingress node and then the ingress node. 589 3. In the PATH RRO, instead of recording the ingress node's address, 590 replace it with the Proxy-Ingress-Id. 592 4. Leave the HOP object populated as usual with information for the 593 ingress-node. 595 5. Add the INGRESS_PROTECTION object to the PATH message. Include 596 the Backup Ingress Address (IPv4 or IPv6) sub-object and the 597 Traffic-Descriptor sub-object. Set or clear the options 598 indicating that a Backup P2MP LSP is desired. 600 6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path 601 message. Indicate whether one-to-one backup is desired. 602 Indicate whether facility backup is desired. 604 7. The RSVP PATH message is sent to the backup node as normal. 606 If the ingress detects that it can't communicate with the backup 607 ingress, then the ingress SHOULD instead send the PATH message to the 608 next-hop indicated in the ERO computed in step 1. Once the ingress 609 detects that it can communicate with the backup ingress, the ingress 610 SHOULD follow the steps 1-7 to obtain ingress failure protection. 612 When the ingress node receives an RSVP PATH message with an INGRESS- 613 PROTECTION object and the object specifies that node as the ingress 614 node and the PHOP as the backup ingress node, the ingress node SHOULD 615 remove the INGRESS_PROTECTION object from the PATH message before 616 sending it out. Additionally, the ingress node MUST store that it 617 will install ingress forwarding state for the LSP rather than 618 midpoint forwarding. 620 When an RSVP RESV message is received by the ingress, it uses the 621 NHOP to determine whether the message is received from the backup 622 ingress or from a different node. The stored associated PATH message 623 contains an INGRESS_PROTECTION object that identifies the backup 624 ingress node. If the RESV message is not from the backup node, then 625 ingress forwarding state SHOULD be set up, and the INGRESS_PROTECTION 626 object MUST be added to the RESV before it is sent to the NHOP, which 627 SHOULD be the backup node. If the RESV message is from the backup 628 node, then the LSP SHOULD be considered available for use. 630 If the backup ingress node is on the forwarding path, then a RESV is 631 received with an INGRESS_PROTECTION object and an NHOP that matches 632 the backup ingress. In this case, the ingress node's address will 633 not appear after the backup ingress in the RRO. The ingress node 634 SHOULD set up ingress forwarding state, just as is done if the LSP 635 weren't ingress-node protected. 637 6.3. Backup Ingress Behavior 639 An LER determines that the ingress local protection is requested for 640 an LSP if the INGRESS_PROTECTION object is included in the PATH 641 message it receives for the LSP. The LER can further determine that 642 it is the backup ingress if one of its addresses is in the Backup 643 Ingress Address sub-object of the INGRESS_PROTECTION object. The LER 644 as the backup ingress will assume full responsibility of the ingress 645 after the primary ingress fails. In addition, the LER determines 646 that it is off-path if it is not any node of the LSP. 648 6.3.1. Backup Ingress Behavior in Off-path Case 650 The backup ingress considers itself as a PLR and the primary ingress 651 as its next hop and provides a local protection for the primary 652 ingress. It behaves very similarly to a PLR providing fast-reroute 653 where the primary ingress is considered as the failure-point to 654 protect. Where not otherwise specified, the behavior given in 655 [RFC4090] for a PLR applies. 657 The backup ingress MUST follow the control-options specified in the 658 INGRESS_PROTECTION object and the flags and specifications in the 659 FAST-REROUTE object. This applies to providing a P2MP backup if the 660 "P2MP backup" is set, a one-to-one backup if "one-to-one desired" is 661 set, facility backup if the "facility backup desired" is set, and 662 backup paths that support the desired bandwidth, and administrative- 663 colors that are requested. 665 If multiple non empty INGRESS_PROTECTION objects have been received 666 via multiple PATH messages for the same LSP, then the most recent one 667 MUST be the one used. 669 The backup ingress creates the appropriate forwarding state for the 670 backup LSP tunnel(s) to the merge point(s). 672 When the backup ingress sends a RESV message to the primary ingress, 673 it MUST add an INGRESS_PROTECTION object into the message. It MUST 674 set or clear the flags in the object to report "Ingress local 675 protection available", "Ingress local protection in use", and 676 "bandwidth protection". 678 If the backup ingress doesn't have a backup LSP tunnel to each of the 679 merge points, it SHOULD clear "Ingress local protection available" 680 and set NUB to the number of the merge points to which there is no 681 backup LSP. 683 When the primary ingress fails, the backup ingress redirects the 684 traffic from a source into the backup P2P LSPs or the backup P2MP LSP 685 transmitting the traffic to the next hops of the primary ingress, 686 where the traffic is merged into the protected LSP. 688 In this case, the backup ingress MUST keep the PATH message with the 689 INGRESS_PROTECTION object received from the primary ingress and the 690 RESV message with the INGRESS_PROTECTION object to be sent to the 691 primary ingress. The backup ingress MUST set the "local protection 692 in use" flag in the RESV message, indicating that the backup ingress 693 is actively redirecting the traffic into the backup P2P LSPs or the 694 backup P2MP LSP for locally protecting the primary ingress failure. 696 Note that the RESV message with this piece of information will not be 697 sent to the primary ingress because the primary ingress has failed. 699 If the backup ingress has not received any PATH message from the 700 primary ingress for an extended period of time (e.g., a cleanup 701 timeout interval) and a confirmed primary ingress failure did not 702 occur, then the standard RSVP soft-state removal SHOULD occur. The 703 backup ingress SHALL remove the state for the PATH message from the 704 primary ingress, and tear down the one-to-one backup LSPs for 705 protecting the primary ingress if one-to-one backup is used or unbind 706 the facility backup LSPs if facility backup is used. 708 When the backup ingress receives a PATH message from the primary 709 ingress for locally protecting the primary ingress of a protected 710 LSP, it MUST check to see if any critical information has been 711 changed. If the next hops of the primary ingress are changed, the 712 backup ingress SHALL update its backup LSP(s) accordingly. 714 6.3.1.1. Relay-Message Method 716 When the backup ingress receives a PATH message with an non empty 717 INGRESS_PROTECTION object, it examines the object to learn what 718 traffic associated with the LSP. It determines the next-hops to be 719 merged to by examining the Label-Routes sub-object in the object. 721 The backup ingress MUST store the PATH message received from the 722 primary ingress, but NOT forward it. 724 The backup ingress responds with a RESV to the PATH message received 725 from the primary ingress. If the INGRESS_PROTECTION object is not 726 "empty", the backup ingress SHALL send the RESV message with the 727 state indicating protection is available after the backup LSP(s) are 728 successfully established. 730 6.3.1.2. Proxy-Ingress Method 732 The backup ingress determines the next-hops to be merged to by 733 collecting the set of the pair of (IPv4/IPv6 sub-object, Label sub- 734 object) from the Record Route Object of each RESV that are closest to 735 the top and not the Ingress router; this should be the second to the 736 top pair. If a Label-Routes sub-object is included in the 737 INGRESS_PROTECTION object, the included IPv4/IPv6 sub-objects are 738 used to filter the set down to the specific next-hops where 739 protection is desired. A RESV message MUST have been received before 740 the Backup Ingress can create or select the appropriate backup LSP. 742 When the backup ingress receives a PATH message with the 743 INGRESS_PROTECTION object, the backup ingress examines the object to 744 learn what traffic associated with the LSP. The backup ingress 745 forwards the PATH message to the ingress node with the normal RSVP 746 changes. 748 When the backup ingress receives a RESV message with the 749 INGRESS_PROTECTION object, the backup ingress records an IMPLICIT- 750 NULL label in the RRO. Then the backup ingress forwards the RESV 751 message to the ingress node, which is acting for the proxy ingress. 753 6.3.2. Backup Ingress Behavior in On-path Case 755 An LER as the backup ingress determines that it is on-path if one of 756 its addresses is a next hop of the primary ingress (and for Proxy- 757 Ingress Method the primary ingress is not its next hop via checking 758 the PATH message with the INGRESS_PROTECTION object received from the 759 primary ingress). The LER on-path MUST send the corresponding PATH 760 messages without any INGRESS_PROTECTION object to its next hops. It 761 creates a number of backup P2P LSPs or a backup P2MP LSP from itself 762 to the other next hops (i.e., the next hops other than the backup 763 ingress) of the primary ingress. The other next hops are from the 764 Label-Routes sub object. 766 It also creates a forwarding entry, which sends/multicasts the 767 traffic from the source to the next hops of the backup ingress along 768 the protected LSP when the primary ingress fails. The traffic is 769 described by the Traffic-Descriptor. 771 After the forwarding entry is created, all the backup P2P LSPs or the 772 backup P2MP LSP is up and associated with the protected LSP, the 773 backup ingress MUST send the primary ingress the RESV message with 774 the INGRESS_PROTECTION object containing the state of the local 775 protection such as "local protection available" flag set to one, 776 which indicates that the primary ingress is locally protected. 778 When the primary ingress fails, the backup ingress sends/multicasts 779 the traffic from the source to its next hops along the protected LSP 780 and imports the traffic into each of the backup P2P LSPs or the 781 backup P2MP LSP transmitting the traffic to the other next hops of 782 the primary ingress, where the traffic is merged into protected LSP. 784 During the local repair, the backup ingress MUST continue to send the 785 PATH messages to its next hops as before, keep the PATH message with 786 the INGRESS_PROTECTION object received from the primary ingress and 787 the RESV message with the INGRESS_PROTECTION object to be sent to the 788 primary ingress. It MUST set the "local protection in use" flag in 789 the RESV message. 791 6.3.3. Failure Detection and Refresh PATH Messages 793 As described in [RFC4090], it is necessary to refresh the PATH 794 messages via the backup LSP(s). The Backup Ingress MUST wait to 795 refresh the PATH messages until it can accurately detect that the 796 ingress node has failed. An example of such an accurate detection 797 would be that the IGP has no bi-directional links to the ingress node 798 and the last change was long enough in the past that changes should 799 have been received (i.e., an IGP network convergence time or 800 approximately 2-3 seconds) or a BFD session to the primary ingress' 801 loopback address has failed and stayed failed after the network has 802 reconverged. 804 As described in [RFC4090 Section 6.4.3], the backup ingress, acting 805 as PLR, MUST modify and send any saved PATH messages associated with 806 the primary LSP to the corresponding next hops through backup LSP(s). 807 Any PATH message sent will not contain any INGRESS_PROTECTION object. 808 The RSVP_HOP object in the message contains an IP source address 809 belonging to the backup ingress. The sender template object has the 810 backup ingress address as its tunnel sender address. 812 6.4. Revertive Behavior 814 Upon a failure event in the (primary) ingress of a protected LSP, the 815 protected LSP is locally repaired by the backup ingress. There are a 816 couple of basic strategies for restoring the LSP to a full working 817 path. 819 - Revert to Primary Ingress: When the primary ingress is restored, 820 it re-signals each of the LSPs that start from the primary 821 ingress. The traffic for every LSP successfully re-signaled is 822 switched back to the primary ingress from the backup ingress. 824 - Global Repair by Backup Ingress: After determining that the 825 primary ingress of an LSP has failed, the backup ingress computes 826 a new optimal path, signals a new LSP along the new path, and 827 switches the traffic to the new LSP. 829 6.4.1. Revert to Primary Ingress 831 If "Revert to Primary Ingress" is desired for a protected LSP, the 832 (primary) ingress of the LSP SHOULD re-signal the LSP that starts 833 from the primary ingress after the primary ingress restores. After 834 the LSP is re-signaled successfully, the traffic SHOULD be switched 835 back to the primary ingress from the backup ingress on the source 836 node and redirected into the LSP starting from the primary ingress. 838 The primary ingress can specify the "Revert to Ingress" control- 839 option in the INGRESS_PROTECTION object in the PATH messages to the 840 backup ingress. After receiving the "Revert to Ingress" control- 841 option, the backup ingress MUST stop sending/refreshing PATH messages 842 for the protected LSP. 844 6.4.2. Global Repair by Backup Ingress 846 When the backup ingress has determined that the primary ingress of 847 the protected LSP has failed (e.g., via the IGP), it can compute a 848 new path and signal a new LSP along the new path so that it no longer 849 relies upon local repair. To do this, the backup ingress MUST use 850 the same tunnel sender address in the Sender Template Object and 851 allocate a LSP ID different from the one of the old LSP as the LSP-ID 852 of the new LSP. This allows the new LSP to share resources with the 853 old LSP. Alternately, the Backup Ingress can create a new LSP with 854 no bandwidth reservation that duplicates the path(s) of the protected 855 LSP, move traffic to the new LSP, delete the protected LSP, and then 856 resignal the new LSP with bandwidth. 858 7. Security Considerations 860 In principle this document does not introduce new security issues. 861 The security considerations pertaining to RFC 4090, RFC 4875 and 862 other RSVP protocols remain relevant. 864 8. IANA Considerations 866 IANA is requested to administer the assignment of new values defined 867 in this document and summarized in this section. 869 8.1. A New Class Number 871 IANA maintains a registry called "Class Names, Class Numbers, and 872 Class Types" under "Resource Reservation Protocol-Traffic Engineering 873 (RSVP-TE) Parameters". IANA is requested to assign a new Class 874 Number for new object INGRESS_PROTECTION as follows: 876 +====================+===============+============================+ 877 | Class Names | Class Numbers | Class Types | 878 +====================+===============+============================+ 879 | INGRESS_PROTECTION | 206 | 1: INGRESS_PROTECTION_IPv4 | 880 | | is suggested +----------------------------+ 881 | | | 2: INGRESS_PROTECTION_IPv6 | 882 +--------------------+---------------+----------------------------+ 884 IANA is requested to assign Types for new TLVs in the new objects as 885 follows: 887 Type Name Allowed in 888 1 BACKUP_INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4 889 2 BACKUP_INGRESS_IPv6_ADDRESS INGRESS_PROTECTION_IPv6 890 3 INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4 891 4 INGRESS_IPv6_ADDRESS INGRESS_PROTECTION_IPv6 892 5 TRAFFIC_DESCRIPTOR_INTERFACE INGRESS_PROTECTION 893 6 TRAFFIC_DESCRIPTOR_IPv4_PREFIX INGRESS_PROTECTION_IPv4 894 7 TRAFFIC_DESCRIPTOR_IPv6_PREFIX INGRESS_PROTECTION_IPv6 895 8 TRAFFIC_DESCRIPTOR_APPLICATION INGRESS_PROTECTION 896 9 LabeL_Routes INGRESS_PROTECTION 898 9. Contributors 900 Renwei Li 901 Huawei Technologies 902 2330 Central Expressway 903 Santa Clara, CA 95050 904 USA 905 Email: renwei.li@huawei.com 907 Quintin Zhao 908 Huawei Technologies 909 Boston, MA 910 USA 911 Email: quintin.zhao@huawei.com 913 Zhenbin Li 914 Huawei Technologies 915 2330 Central Expressway 916 Santa Clara, CA 95050 917 USA 918 Email: zhenbin.li@huawei.com 920 Boris Zhang 921 Telus Communications 922 200 Consilium Pl Floor 15 923 Toronto, ON M1H 3J3 924 Canada 925 Email: Boris.Zhang@telus.com 926 Markus Jork 927 Juniper Networks 928 10 Technology Park Drive 929 Westford, MA 01886 930 USA 931 Email: mjork@juniper.net 933 10. Acknowledgement 935 The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric 936 Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue, Alia 937 Atlas, Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, 938 Gregory Mirsky, and Ronhazli Adam for their valuable comments and 939 suggestions on this draft. 941 11. Normative References 943 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 944 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 945 RFC2119, March 1997, 946 . 948 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 949 Label Switching Architecture", RFC 3031, DOI 10.17487/ 950 RFC3031, January 2001, 951 . 953 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 954 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 955 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 956 . 958 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 959 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 960 DOI 10.17487/RFC4090, May 2005, 961 . 963 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 964 Yasukawa, Ed., "Extensions to Resource Reservation 965 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 966 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 967 DOI 10.17487/RFC4875, May 2007, 968 . 970 Appendix A. Problem Summary 972 There is a need for a fast and efficient protection against the 973 failure of the ingress node of a MPLS TE LSP (either P2MP LSP or P2P 974 LSP). 976 For a MPLS TE LSP, protecting the failures of its transit nodes using 977 fast-reroute (FRR) is covered in RFC 4090 for P2P LSP and RFC 4875 978 for P2MP LSP. However, protecting the failure of its ingress node 979 using FRR is not covered in either RFC 4090 or RFC 4875. The MPLS 980 Transport Profile (MPLS-TP) Linear Protection described in RFC 6378 981 can provide a protection against the failure of any transit node of a 982 LSP between the ingress node and the egress node of the LSP, but 983 cannot protect against the failure of the ingress node. 985 To protect against the failure of the (primary) ingress node of a 986 primary end to end P2MP (or P2P) TE LSP, a typical existing solution 987 is to set up a secondary backup end to end P2MP (or P2P) TE LSP from 988 a backup ingress node, which is different from the primary ingress 989 node, to the backup egress nodes (or node), which are (or is) 990 different from the primary egress nodes (or node) of the primary LSP. 991 For a P2MP TE LSP, on each of the primary (and backup) egress nodes, 992 a P2P LSP is created from the egress node to its primary (backup) 993 ingress node and configured with BFD. This is used to detect the 994 failure of the primary (backup) ingress node for the receiver to 995 switch to the backup (or primary) egress node to receive the traffic 996 after the primary (or backup) ingress node fails when both the 997 primary LSP and the secondary LSP carry the traffic. In addition, 998 FRR may be used to provide protections against the failures of the 999 transit nodes and the links of the primary and secondary end to end 1000 TE LSPs. 1002 There are a number of issues in this solution, which are briefed as 1003 follows: 1005 o It consumes lots of network resources. Double states need to be 1006 maintained in the network since two end to end TE LSPs are 1007 created. Double link bandwidth is reserved and used when both the 1008 primary and the secondary end to end TE LSPs carry the traffic at 1009 the same time. 1011 o More operations are needed, which include the configurations of 1012 two end to end TE LSPs and BFDs from each of the egress nodes to 1013 its corresponding ingress node. 1015 o The detection of the failure of the ingress node may not be 1016 reliable. Any failure on the path of the BFD from an egress node 1017 to an ingress node may cause the BFD down to indicate the failure 1018 of the ingress node. 1020 o The speed of protection against the failure of the ingress node 1021 may be slow. 1023 The ingress local protection proposed in this draft will resolve the 1024 above issues. 1026 Appendix B. Authors' Addresses 1028 Huaimo Chen 1029 Huawei Technologies 1030 Boston, MA 1031 USA 1032 Email: huaimo.chen@huawei.com 1034 Raveendra Torvi 1035 Juniper Networks 1036 10 Technology Park Drive 1037 Westford, MA 01886 1038 USA 1039 Email: rtorvi@juniper.net 1041 Ning So 1042 Tata Communications 1043 2613 Fairbourne Cir. 1044 Plano, TX 75082 1045 USA 1046 Email: ningso01@gmail.com 1048 Autumn Liu 1049 Ericsson 1050 300 Holger Way 1051 San Jose, CA 95134 1052 USA 1053 Email: autumn.liu@ericsson.com 1054 Yimin Shen 1055 Juniper Networks 1056 10 Technology Park Drive 1057 Westford, MA 01886 1058 USA 1059 Email: yshen@juniper.net 1061 Tarek Saad 1062 Cisco Systems 1063 Email: tsaad@cisco.com 1065 Fengman Xu 1066 Verizon 1067 2400 N. Glenville Dr 1068 Richardson, TX 75082 1069 USA 1070 Email: fengman.xu@verizon.com 1072 Mehmet Toy 1073 Comcast 1074 1800 Bishops Gate Blvd. 1075 Mount Laurel, NJ 08054 1076 USA 1077 Email: mehmet_toy@cable.comcast.com 1079 Lei Liu 1080 UC Davis 1081 USA 1082 Email: liulei.kddi@gmail.com