idnits 2.17.1 draft-ietf-teas-rsvp-ingress-protection-08.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 (September 1, 2016) is 2765 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'S' is mentioned on line 130, but not defined == Missing Reference: 'Ra' is mentioned on line 133, but not defined == Missing Reference: 'Rb' is mentioned on line 133, but not defined == Missing Reference: 'L3' is mentioned on line 133, but not defined == Unused Reference: 'RFC2119' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 950, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 955, 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: March 5, 2017 Juniper Networks 6 September 1, 2016 8 Extensions to RSVP-TE for LSP Ingress FRR Protection 9 draft-ietf-teas-rsvp-ingress-protection-08.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 March 5, 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 (FRR) of the ingress node of a P2MP or P2P LSP. Ingress 112 local protection and ingress FRR protection will be used 113 exchangeably. 115 2.1. An Example of Ingress Local Protection 117 Figure 1 shows an example of using a backup P2MP LSP to locally 118 protect the ingress of a primary P2MP LSP, which is from ingress R1 119 to three egresses: L1, L2 and L3. The backup LSP is from backup 120 ingress Ra to the next hops R2 and R4 of ingress R1. 122 [R2]******[R3]*****[L1] 123 * | **** Primary LSP 124 * | ---- Backup LSP 125 * / .... BFD Session 126 * / $ Link 127 ....[R1]*******[R4]****[R5]*****[L2] $ 128 : $ $ / / * $ 129 : $ $ / / * 130 [S] $ / / * 131 $ $ / / * 132 $ $/ / * 133 [Ra]----[Rb] [L3] 135 Figure 1: Backup P2MP LSP for Locally Protecting Ingress 137 In normal operations, source S sends the traffic to primary ingress 138 R1. R1 imports the traffic into the primary LSP. 140 When source S detects the failure of R1, it switches the traffic to 141 backup ingress Ra, which imports the traffic from S into the backup 142 LSP to R1's next hops R2 and R4, where the traffic is merged into the 143 primary LSP, and then sent to egresses L1, L2 and L3. Source S 144 detects the failure of R1 and switches the traffic within 10s of ms. 146 Note that the backup ingress is one logical hop away from the 147 ingress. A logical hop is a direct link or a tunnel such as a GRE 148 tunnel, over which RSVP-TE messages may be exchanged. 150 2.2. Ingress Local Protection with FRR 152 Through using the ingress local protection and the FRR, we can 153 locally protect the ingress, all the links and the transit nodes of 154 an LSP. The traffic switchover time is within 10s of ms whenever the 155 ingress, any of the links and the transit nodes of the LSP fails. 157 The ingress node of the LSP can be locally protected through using 158 the ingress local protection. All the links and all the transit 159 nodes of the LSP can be locally protected through using the FRR. 161 3. Ingress Failure Detection 163 Exactly how to detect the failure of the ingress is out of scope. 164 However, it is necessary to discuss different modes for detecting the 165 failure because they determine what is the required behavior for the 166 source and backup ingress. 168 3.1. Source Detects Failure 170 Source Detects Failure or Source-Detect for short means that the 171 source is responsible for fast detecting the failure of the primary 172 ingress of an LSP. The backup ingress is ready to import the traffic 173 from the source into the backup LSP(s) after the backup LSP(s) is up. 175 In normal operations, the source sends the traffic to the primary 176 ingress. When the source detects the failure of the primary ingress, 177 it switches the traffic to the backup ingress, which delivers the 178 traffic to the next hops of the primary ingress through the backup 179 LSP(s), where the traffic is merged into the primary LSP. 181 For a P2P LSP, after the primary ingress fails, the backup ingress 182 MUST use a method to reliably detect the failure of the primary 183 ingress before the PATH message for the LSP expires at the next hop 184 of the primary ingress. After reliably detecting the failure, the 185 backup ingress sends/refreshes the PATH message to the next hop 186 through the backup LSP as needed. 188 After the primary ingress fails, it will not be reachable after 189 routing convergence. Thus checking whether the primary ingress 190 (address) is reachable is a possible method. 192 3.2. Backup and Source Detect Failure 194 Backup and Source Detect Failure or Backup-Source-Detect for short 195 means that both the backup ingress and the source are concurrently 196 responsible for fast detecting the failure of the primary ingress. 198 In normal operations, the source sends the traffic to the primary 199 ingress. It switches the traffic to the backup ingress when it 200 detects the failure of the primary ingress. 202 The backup ingress does not import any traffic from the source into 203 the backup LSP in normal operations. When it detects the failure of 204 the primary ingress, it imports the traffic from the source into the 205 backup LSP to the next hops of the primary ingress, where the traffic 206 is merged into the primary LSP. 208 The source-detect is preferred. It is simpler than the backup- 209 source-detect, which needs both the source and the backup ingress 210 detect the ingress failure quickly. 212 4. Backup Forwarding State 214 Before the primary ingress fails, the backup ingress is responsible 215 for creating the necessary backup LSPs. These LSPs might be multiple 216 bypass P2P LSPs that avoid the ingress. Alternately, the backup 217 ingress could choose to use a single backup P2MP LSP as a bypass or 218 detour to protect the primary ingress of a primary P2MP LSP. 220 The backup ingress may be off-path or on-path of an LSP. If a backup 221 ingress is not any node of the LSP, we call it is off-path. If a 222 backup ingress is a next-hop of the primary ingress of the LSP, we 223 call it is on-path. If it is on-path, the primary forwarding state 224 associated with the primary LSP SHOULD be clearly separated from the 225 backup LSP(s) state. 227 4.1. Forwarding State for Backup LSP 229 A forwarding entry for a backup LSP is created on the backup ingress 230 after the LSP is set up. Depending on the failure-detection mode 231 (e.g., source-detect), it may be used to forward received traffic or 232 simply be inactive (e.g., backup-source-detect) until required. In 233 either case, when the primary ingress fails, this entry is used to 234 import the traffic into the backup LSP to the next hops of the 235 primary ingress, where the traffic is merged into the primary LSP. 237 The forwarding entry for a backup LSP is a local implementation 238 issue. In one device, it may have an inactive flag. This inactive 239 forwarding entry is not used to forward any traffic normally. When 240 the primary ingress fails, it is changed to active, and thus the 241 traffic from the source is imported into the backup LSP. 243 5. Protocol Extensions 245 A new object INGRESS_PROTECTION is defined for signaling ingress 246 local protection. It is backward compatible. 248 5.1. INGRESS_PROTECTION Object 250 The INGRESS_PROTECTION object with the FAST_REROUTE object in a PATH 251 message is used to control the backup for protecting the primary 252 ingress of a primary LSP. The primary ingress MUST insert this 253 object into the PATH message to be sent to the backup ingress for 254 protecting the primary ingress. It has the following format: 256 Class-Num = TBD C-Type = 1 for INGRESS_PROTECTION_IPv4 257 C-Type = 2 for INGRESS_PROTECTION_IPv6 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Length (bytes) | Class-Num | C-Type | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Reserved (zero) | NUB | Flags | Options | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 ~ (Subobjects) ~ 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 NUB Number of Unprotected Branches 268 Flags 269 0x01 Ingress local protection available 270 0x02 Ingress local protection in use 271 0x04 Bandwidth protection 273 Options 274 0x01 Revert to Ingress 275 0x02 P2MP Backup 277 For protecting the ingress of a P2MP LSP, if the backup ingress 278 doesn't have a backup LSP to each of the next hops of the primary 279 ingress, it SHOULD clear "Ingress local protection available" and set 280 NUB to the number of the next hops to which there is no backup LSP. 282 The flags are used to communicate status information from the backup 283 ingress to the primary ingress. 285 o Ingress local protection available: The backup ingress sets this 286 flag after backup LSPs are up and ready for locally protecting the 287 primary ingress. The backup ingress sends this to the primary 288 ingress to indicate that the primary ingress is locally protected. 290 o Ingress local protection in use: The backup ingress sets this flag 291 when it detects a failure in the primary ingress. The backup 292 ingress keeps it and does not send it to the primary ingress since 293 the primary ingress is down. 295 o Bandwidth protection: The backup ingress sets this flag if the 296 backup LSPs guarantee to provide desired bandwidth for the 297 protected LSP against the primary ingress failure. 299 The options are used by the primary ingress to specify the desired 300 behavior to the backup ingress. 302 o Revert to Ingress: The primary ingress sets this option indicating 303 that the traffic for the primary LSP successfully re-signaled will 304 be switched back to the primary ingress from the backup ingress 305 when the primary ingress is restored. 307 o P2MP Backup: This option is set to ask for the backup ingress to 308 use P2MP backup LSP to protect the primary ingress. 310 The INGRESS_PROTECTION object may contain some sub objects below. 312 5.1.1. Subobject: Backup Ingress IPv4 Address 314 When the primary ingress of a protected LSP sends a PATH message with 315 an INGRESS_PROTECTION object to the backup ingress, the object MUST 316 have a Backup Ingress IPv4 Address sub object containing an IPv4 317 address belonging to the backup ingress if IPv4 is used. The Type of 318 the sub object is TBD1 (the exact number to be assigned by IANA), and 319 the body of the sub object is given below: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Backup ingress IPv4 address (4 bytes) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Backup ingress IPv4 address: An IPv4 host address of backup ingress 329 5.1.2. Subobject: Backup Ingress IPv6 Address 331 When the primary ingress of a protected LSP sends a PATH message with 332 an INGRESS_PROTECTION object to the backup ingress, the object MUST 333 have a Backup Ingress IPv6 Address sub object containing an IPv6 334 address belonging to the backup ingress if IPv6 is used. The Type of 335 the sub object is TBD2, the body of the sub object is given below: 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Backup ingress IPv6 address (16 bytes) | 341 ~ ~ 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Backup ingress IPv6 address: An IPv6 host address of backup ingress 346 5.1.3. Subobject: Ingress IPv4 Address 348 The INGRESS_PROTECTION object may have an Ingress IPv4 Address sub 349 object containing an IPv4 address belonging to the primary ingress. 350 The Type of the sub object is TBD3. The sub object has the following 351 body: 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Ingress IPv4 address (4 bytes) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Ingress IPv4 address: An IPv4 host address of ingress 361 5.1.4. Subobject: Ingress IPv6 Address 363 The INGRESS_PROTECTION object may have an Ingress IPv6 Address sub 364 object containing an IPv6 address belonging to the primary ingress. 365 The Type of the sub object is TBD4. The sub object has the following 366 body: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Ingress IPv6 address (16 bytes) | 372 ~ ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Ingress IPv6 address: An IPv6 host address of ingress 376 5.1.5. Subobject: Traffic Descriptor 378 The INGRESS_PROTECTION object may have a Traffic Descriptor sub 379 object describing the traffic to be mapped to the backup LSP on the 380 backup ingress for locally protecting the primary ingress. The Type 381 of the sub object is TBD5, TBD6, TBD7 or TBD8 for Interface, IPv4 382 Prefix, IPv6 Prefix or Application Identifier respectively. The sub 383 object has the following body: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Traffic Element 1 | 389 ~ ~ 390 | Traffic Element n | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 The Traffic Descriptor sub object may contain multiple Traffic 394 Elements of same type as follows: 396 o Interface Traffic (Type TBD5): Each of the Traffic Elements is a 397 32 bit index of an interface, from which the traffic is imported 398 into the backup LSP. 400 o IPv4 Prefix Traffic (Type TBD6): Each of the Traffic Elements is 401 an IPv4 prefix, containing an 8-bit prefix length followed by an 402 IPv4 address prefix, whose length, in bits, is specified by the 403 prefix length, padded to a byte boundary. 405 o IPv6 Prefix Traffic (Type TBD7): Each of the Traffic Elements is 406 an IPv6 prefix, containing an 8-bit prefix length followed by an 407 IPv6 address prefix, whose length, in bits, is specified by the 408 prefix length, padded to a byte boundary. 410 o Application Traffic (Type TBD8): Each of the Traffic Elements is a 411 32 bit identifier of an application, from which the traffic is 412 imported into the backup LSP. 414 5.1.6. Subobject: Label-Routes 416 The INGRESS_PROTECTION object in a PATH message from the primary 417 ingress to the backup ingress will have a Label-Routes sub object 418 containing the labels and routes that the next hops of the ingress 419 use. The Type of the sub object is TBD9. The sub object has the 420 following body: 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 ~ Subobjects ~ 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 The Subobjects in the Label-Routes are copied from those in the 429 RECORD_ROUTE objects in the RESV messages that the primary ingress 430 receives from its next hops for the primary LSP. They MUST contain 431 the first hops of the LSP, each of which is paired with its label. 433 6. Behavior of Ingress Protection 435 6.1. Overview 437 There are four parts of ingress protection: 1) setting up the 438 necessary backup LSP forwarding state; 2) identifying the failure and 439 providing the fast repair (as discussed in Sections 3 and 4); 3) 440 maintaining the RSVP-TE control plane state until a global repair is 441 done; and 4) performing the global repair(see Section 6.4). 443 There are two different proposed signaling approaches to obtain 444 ingress protection. They both use the same new INGRESS_PROTECTION 445 object. The object is sent in both PATH and RESV messages. 447 6.1.1. Relay-Message Method 449 The primary ingress relays the information for ingress protection of 450 an LSP to the backup ingress via PATH messages. Once the LSP is 451 created, the ingress of the LSP sends the backup ingress a PATH 452 message with an INGRESS_PROTECTION object with Label-Routes 453 subobject, which is populated with the next-hops and labels. This 454 provides sufficient information for the backup ingress to create the 455 appropriate forwarding state and backup LSP(s). 457 The ingress also sends the backup ingress all the other PATH messages 458 for the LSP with an empty INGRESS_PROTECTION object. An 459 INGRESS_PROTECTION object without any Traffic-Descriptor sub-object 460 is called an empty INGRESS_PROTECTION object. Thus, the backup 461 ingress has access to all the PATH messages needed for modification 462 to refresh control-plane state after a failure. 464 The advantages of this method include: 1) the primary LSP is 465 independent of the backup ingress; 2) simple; 3) less configuration; 466 and 4) less control traffic. 468 6.1.2. Proxy-Ingress Method 470 Conceptually, a proxy ingress is created that starts the RSVP 471 signaling. The explicit path of the LSP goes from the proxy ingress 472 to the backup ingress and then to the real ingress. The behavior and 473 signaling for the proxy ingress is done by the real ingress; the use 474 of a proxy ingress address avoids problems with loop detection. 476 [ traffic source ] *** Primary LSP 477 $ $ --- Backup LSP 478 $ $ $$ Link 479 $ $ 480 [ proxy ingress ] [ backup ] 481 [ & ingress ] | 482 * | 483 *****[ MP ]----| 485 Figure 2: Example Protected LSP with Proxy Ingress Node 487 The backup ingress must know the merge points or next-hops and their 488 associated labels. This is accomplished by having the RSVP PATH and 489 RESV messages go through the backup ingress, although the forwarding 490 path need not go through the backup ingress. If the backup ingress 491 fails, the ingress simply removes the INGRESS_PROTECTION object and 492 forwards the PATH messages to the LSP's next-hop(s). If the ingress 493 has its LSP configured for ingress protection, then the ingress can 494 add the backup ingress and itself to the ERO and start forwarding the 495 PATH messages to the backup ingress. 497 Slightly different behavior can apply for the on-path and off-path 498 cases. In the on-path case, the backup ingress is a next hop node 499 after the ingress for the LSP. In the off-path, the backup ingress 500 is not any next-hop node after the ingress for all associated sub- 501 LSPs. 503 The key advantage of this approach is that it minimizes the special 504 handling code requires. Because the backup ingress is on the 505 signaling path, it can receive various notifications. It easily has 506 access to all the PATH messages needed for modification to be sent to 507 refresh control-plane state after a failure. 509 6.1.3. Comparing Two Methods 511 +-------+-----------+-------+--------------+---------------+---------+ 512 |\_ Item|Primary LSP|Config |PATH Msg from |RESV Msg from |Reuse | 513 | \_ |Depends on |Proxy- |Backup Ingress|Primary Ingress|Some | 514 | \|Backup |Ingress|to Primary |to Backup |Existing | 515 |Method |Ingress |ID |Ingress |Ingress |Functions| 516 +-------+-----------+-------+--------------+---------------+---------+ 517 |Relay- | No | No | No | No | Yes- | 518 |Message| | | | | | 519 +-------+-----------+-------+--------------+---------------+---------+ 520 |Proxy- | Yes | Yes- | Yes | Yes | Yes | 521 |Ingress| | | | | | 522 +-------+-----------+-------+--------------+---------------+---------+ 524 6.2. Ingress Behavior 526 The primary ingress MUST be configured with a couple of pieces of 527 information for ingress protection. 529 o Backup Ingress Address: The primary ingress MUST know an IP 530 address for it to be included in the INGRESS_PROTECTION object. 532 o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The 533 Proxy-Ingress-Id is only used in the Record Route Object for 534 recording the proxy-ingress. If no proxy-ingress-id is specified, 535 then a local interface address that will not otherwise be included 536 in the Record Route Object can be used. A similar technique is 537 used in [RFC4090 Sec 6.1.1]. 539 o Application Traffic Identifier: The primary ingress and backup 540 ingress MUST both know what application traffic should be directed 541 into the LSP. If a list of prefixes in the Traffic Descriptor 542 sub-object will not suffice, then a commonly understood 543 Application Traffic Identifier can be sent between the primary 544 ingress and backup ingress. The exact meaning of the identifier 545 should be configured similarly at both the primary ingress and 546 backup ingress. The Application Traffic Identifier is understood 547 within the unique context of the primary ingress and backup 548 ingress. 550 o A connection between backup ingress and primary ingress: If there 551 is not any direct link between the primary ingress and the backup 552 ingress, a tunnel MUST be configured between them. 554 With this additional information, the primary ingress can create and 555 signal the necessary RSVP extensions to support ingress protection. 557 6.2.1. Relay-Message Method 559 To protect the ingress of an LSP, the ingress MUST do the following 560 after the LSP is up. 562 1. Select a PATH message. 564 2. If the backup ingress is off-path, then send it a PATH message 565 with the content from the selected PATH message and an 566 INGRESS_PROTECTION object; else (the backup ingress is a next 567 hop, i.e., on-path case) add an INGRESS_PROTECTION object into 568 the existing PATH message to the backup ingress (i.e., the next 569 hop). The object contains the Traffic-Descriptor sub-object, the 570 Backup Ingress Address sub-object and the Label-Routes sub- 571 object. The options is set to indicate whether a Backup P2MP LSP 572 is desired. The Label-Routes sub-object contains the next-hops 573 of the ingress and their labels. 575 3. For each of the other PATH messages, send the backup ingress a 576 PATH message with the content copied from the message and an 577 empty INGRESS_PROTECTION object. 579 6.2.2. Proxy-Ingress Method 581 The primary ingress is responsible for starting the RSVP signaling 582 for the proxy-ingress node. To do this, the following MUST be done 583 for the RSVP PATH message. 585 1. Compute the EROs for the LSP as normal for the ingress. 587 2. If the selected backup ingress node is not the first node on the 588 path (for all sub-LSPs), then insert at the beginning of the ERO 589 first the backup ingress node and then the ingress node. 591 3. In the PATH RRO, instead of recording the ingress node's address, 592 replace it with the Proxy-Ingress-Id. 594 4. Leave the HOP object populated as usual with information for the 595 ingress-node. 597 5. Add the INGRESS_PROTECTION object to the PATH message. Include 598 the Backup Ingress Address (IPv4 or IPv6) sub-object and the 599 Traffic-Descriptor sub-object. Set or clear the options 600 indicating that a Backup P2MP LSP is desired. 602 6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path 603 message. Indicate whether one-to-one backup is desired. 604 Indicate whether facility backup is desired. 606 7. The RSVP PATH message is sent to the backup node as normal. 608 If the ingress detects that it can't communicate with the backup 609 ingress, then the ingress SHOULD instead send the PATH message to the 610 next-hop indicated in the ERO computed in step 1. Once the ingress 611 detects that it can communicate with the backup ingress, the ingress 612 SHOULD follow the steps 1-7 to obtain ingress failure protection. 614 When the ingress node receives an RSVP PATH message with an INGRESS- 615 PROTECTION object and the object specifies that node as the ingress 616 node and the PHOP as the backup ingress node, the ingress node SHOULD 617 remove the INGRESS_PROTECTION object from the PATH message before 618 sending it out. Additionally, the ingress node MUST store that it 619 will install ingress forwarding state for the LSP rather than 620 midpoint forwarding. 622 When an RSVP RESV message is received by the ingress, it uses the 623 NHOP to determine whether the message is received from the backup 624 ingress or from a different node. The stored associated PATH message 625 contains an INGRESS_PROTECTION object that identifies the backup 626 ingress node. If the RESV message is not from the backup node, then 627 ingress forwarding state SHOULD be set up, and the INGRESS_PROTECTION 628 object MUST be added to the RESV before it is sent to the NHOP, which 629 SHOULD be the backup node. If the RESV message is from the backup 630 node, then the LSP SHOULD be considered available for use. 632 If the backup ingress node is on the forwarding path, then a RESV is 633 received with an INGRESS_PROTECTION object and an NHOP that matches 634 the backup ingress. In this case, the ingress node's address will 635 not appear after the backup ingress in the RRO. The ingress node 636 SHOULD set up ingress forwarding state, just as is done if the LSP 637 weren't ingress-node protected. 639 6.3. Backup Ingress Behavior 641 An LER determines that the ingress local protection is requested for 642 an LSP if the INGRESS_PROTECTION object is included in the PATH 643 message it receives for the LSP. The LER can further determine that 644 it is the backup ingress if one of its addresses is in the Backup 645 Ingress Address sub-object of the INGRESS_PROTECTION object. The LER 646 as the backup ingress will assume full responsibility of the ingress 647 after the primary ingress fails. In addition, the LER determines 648 that it is off-path if it is not any node of the LSP. 650 6.3.1. Backup Ingress Behavior in Off-path Case 652 The backup ingress considers itself as a PLR and the primary ingress 653 as its next hop and provides a local protection for the primary 654 ingress. It behaves very similarly to a PLR providing fast-reroute 655 where the primary ingress is considered as the failure-point to 656 protect. Where not otherwise specified, the behavior given in 657 [RFC4090] for a PLR applies. 659 The backup ingress MUST follow the control-options specified in the 660 INGRESS_PROTECTION object and the flags and specifications in the 661 FAST-REROUTE object. This applies to providing a P2MP backup if the 662 "P2MP backup" is set, a one-to-one backup if "one-to-one desired" is 663 set, facility backup if the "facility backup desired" is set, and 664 backup paths that support the desired bandwidth, and administrative- 665 colors that are requested. 667 If multiple non empty INGRESS_PROTECTION objects have been received 668 via multiple PATH messages for the same LSP, then the most recent one 669 MUST be the one used. 671 The backup ingress creates the appropriate forwarding state for the 672 backup LSP tunnel(s) to the merge point(s). 674 When the backup ingress sends a RESV message to the primary ingress, 675 it MUST add an INGRESS_PROTECTION object into the message. It MUST 676 set or clear the flags in the object to report "Ingress local 677 protection available", "Ingress local protection in use", and 678 "bandwidth protection". 680 If the backup ingress doesn't have a backup LSP tunnel to each of the 681 merge points, it SHOULD clear "Ingress local protection available" 682 and set NUB to the number of the merge points to which there is no 683 backup LSP. 685 When the primary ingress fails, the backup ingress redirects the 686 traffic from a source into the backup P2P LSPs or the backup P2MP LSP 687 transmitting the traffic to the next hops of the primary ingress, 688 where the traffic is merged into the protected LSP. 690 In this case, the backup ingress MUST keep the PATH message with the 691 INGRESS_PROTECTION object received from the primary ingress and the 692 RESV message with the INGRESS_PROTECTION object to be sent to the 693 primary ingress. The backup ingress MUST set the "local protection 694 in use" flag in the RESV message, indicating that the backup ingress 695 is actively redirecting the traffic into the backup P2P LSPs or the 696 backup P2MP LSP for locally protecting the primary ingress failure. 698 Note that the RESV message with this piece of information will not be 699 sent to the primary ingress because the primary ingress has failed. 701 If the backup ingress has not received any PATH message from the 702 primary ingress for an extended period of time (e.g., a cleanup 703 timeout interval) and a confirmed primary ingress failure did not 704 occur, then the standard RSVP soft-state removal SHOULD occur. The 705 backup ingress SHALL remove the state for the PATH message from the 706 primary ingress, and tear down the one-to-one backup LSPs for 707 protecting the primary ingress if one-to-one backup is used or unbind 708 the facility backup LSPs if facility backup is used. 710 When the backup ingress receives a PATH message from the primary 711 ingress for locally protecting the primary ingress of a protected 712 LSP, it MUST check to see if any critical information has been 713 changed. If the next hops of the primary ingress are changed, the 714 backup ingress SHALL update its backup LSP(s) accordingly. 716 6.3.1.1. Relay-Message Method 718 When the backup ingress receives a PATH message with an non empty 719 INGRESS_PROTECTION object, it examines the object to learn what 720 traffic associated with the LSP. It determines the next-hops to be 721 merged to by examining the Label-Routes sub-object in the object. 723 The backup ingress MUST store the PATH message received from the 724 primary ingress, but NOT forward it. 726 The backup ingress responds with a RESV to the PATH message received 727 from the primary ingress. If the INGRESS_PROTECTION object is not 728 "empty", the backup ingress SHALL send the RESV message with the 729 state indicating protection is available after the backup LSP(s) are 730 successfully established. 732 6.3.1.2. Proxy-Ingress Method 734 The backup ingress determines the next-hops to be merged to by 735 collecting the set of the pair of (IPv4/IPv6 sub-object, Label sub- 736 object) from the Record Route Object of each RESV that are closest to 737 the top and not the Ingress router; this should be the second to the 738 top pair. If a Label-Routes sub-object is included in the 739 INGRESS_PROTECTION object, the included IPv4/IPv6 sub-objects are 740 used to filter the set down to the specific next-hops where 741 protection is desired. A RESV message MUST have been received before 742 the Backup Ingress can create or select the appropriate backup LSP. 744 When the backup ingress receives a PATH message with the 745 INGRESS_PROTECTION object, the backup ingress examines the object to 746 learn what traffic associated with the LSP. The backup ingress 747 forwards the PATH message to the ingress node with the normal RSVP 748 changes. 750 When the backup ingress receives a RESV message with the 751 INGRESS_PROTECTION object, the backup ingress records an IMPLICIT- 752 NULL label in the RRO. Then the backup ingress forwards the RESV 753 message to the ingress node, which is acting for the proxy ingress. 755 6.3.2. Backup Ingress Behavior in On-path Case 757 An LER as the backup ingress determines that it is on-path if one of 758 its addresses is a next hop of the primary ingress (and for Proxy- 759 Ingress Method the primary ingress is not its next hop via checking 760 the PATH message with the INGRESS_PROTECTION object received from the 761 primary ingress). The LER on-path MUST send the corresponding PATH 762 messages without any INGRESS_PROTECTION object to its next hops. It 763 creates a number of backup P2P LSPs or a backup P2MP LSP from itself 764 to the other next hops (i.e., the next hops other than the backup 765 ingress) of the primary ingress. The other next hops are from the 766 Label-Routes sub object. 768 It also creates a forwarding entry, which sends/multicasts the 769 traffic from the source to the next hops of the backup ingress along 770 the protected LSP when the primary ingress fails. The traffic is 771 described by the Traffic-Descriptor. 773 After the forwarding entry is created, all the backup P2P LSPs or the 774 backup P2MP LSP is up and associated with the protected LSP, the 775 backup ingress MUST send the primary ingress the RESV message with 776 the INGRESS_PROTECTION object containing the state of the local 777 protection such as "local protection available" flag set to one, 778 which indicates that the primary ingress is locally protected. 780 When the primary ingress fails, the backup ingress sends/multicasts 781 the traffic from the source to its next hops along the protected LSP 782 and imports the traffic into each of the backup P2P LSPs or the 783 backup P2MP LSP transmitting the traffic to the other next hops of 784 the primary ingress, where the traffic is merged into protected LSP. 786 During the local repair, the backup ingress MUST continue to send the 787 PATH messages to its next hops as before, keep the PATH message with 788 the INGRESS_PROTECTION object received from the primary ingress and 789 the RESV message with the INGRESS_PROTECTION object to be sent to the 790 primary ingress. It MUST set the "local protection in use" flag in 791 the RESV message. 793 6.3.3. Failure Detection and Refresh PATH Messages 795 As described in [RFC4090], it is necessary to refresh the PATH 796 messages via the backup LSP(s). The Backup Ingress MUST wait to 797 refresh the PATH messages until it can accurately detect that the 798 ingress node has failed. An example of such an accurate detection 799 would be that the IGP has no bi-directional links to the ingress node 800 and the last change was long enough in the past that changes should 801 have been received (i.e., an IGP network convergence time or 802 approximately 2-3 seconds) or a BFD session to the primary ingress' 803 loopback address has failed and stayed failed after the network has 804 reconverged. 806 As described in [RFC4090 Section 6.4.3], the backup ingress, acting 807 as PLR, MUST modify and send any saved PATH messages associated with 808 the primary LSP to the corresponding next hops through backup LSP(s). 809 Any PATH message sent will not contain any INGRESS_PROTECTION object. 810 The RSVP_HOP object in the message contains an IP source address 811 belonging to the backup ingress. The sender template object has the 812 backup ingress address as its tunnel sender address. 814 6.4. Revertive Behavior 816 Upon a failure event in the (primary) ingress of a protected LSP, the 817 protected LSP is locally repaired by the backup ingress. There are a 818 couple of basic strategies for restoring the LSP to a full working 819 path. 821 - Revert to Primary Ingress: When the primary ingress is restored, 822 it re-signals each of the LSPs that start from the primary 823 ingress. The traffic for every LSP successfully re-signaled is 824 switched back to the primary ingress from the backup ingress. 826 - Global Repair by Backup Ingress: After determining that the 827 primary ingress of an LSP has failed, the backup ingress computes 828 a new optimal path, signals a new LSP along the new path, and 829 switches the traffic to the new LSP. 831 6.4.1. Revert to Primary Ingress 833 If "Revert to Primary Ingress" is desired for a protected LSP, the 834 (primary) ingress of the LSP SHOULD re-signal the LSP that starts 835 from the primary ingress after the primary ingress restores. After 836 the LSP is re-signaled successfully, the traffic SHOULD be switched 837 back to the primary ingress from the backup ingress on the source 838 node and redirected into the LSP starting from the primary ingress. 840 The primary ingress can specify the "Revert to Ingress" control- 841 option in the INGRESS_PROTECTION object in the PATH messages to the 842 backup ingress. After receiving the "Revert to Ingress" control- 843 option, the backup ingress MUST stop sending/refreshing PATH messages 844 for the protected LSP. 846 6.4.2. Global Repair by Backup Ingress 848 When the backup ingress has determined that the primary ingress of 849 the protected LSP has failed (e.g., via the IGP), it can compute a 850 new path and signal a new LSP along the new path so that it no longer 851 relies upon local repair. To do this, the backup ingress MUST use 852 the same tunnel sender address in the Sender Template Object and 853 allocate a LSP ID different from the one of the old LSP as the LSP-ID 854 of the new LSP. This allows the new LSP to share resources with the 855 old LSP. Alternately, the Backup Ingress can create a new LSP with 856 no bandwidth reservation that duplicates the path(s) of the protected 857 LSP, move traffic to the new LSP, delete the protected LSP, and then 858 resignal the new LSP with bandwidth. 860 7. Security Considerations 862 In principle this document does not introduce new security issues. 863 The security considerations pertaining to RFC 4090, RFC 4875 and 864 other RSVP protocols remain relevant. 866 8. IANA Considerations 868 IANA is requested to administer the assignment of new values defined 869 in this document and summarized in this section. 871 8.1. A New Class Number 873 IANA maintains a registry called "Class Names, Class Numbers, and 874 Class Types" under "Resource Reservation Protocol-Traffic Engineering 875 (RSVP-TE) Parameters". IANA is requested to assign a new Class 876 Number for new object INGRESS_PROTECTION as follows: 878 +====================+===============+============================+ 879 | Class Names | Class Numbers | Class Types | 880 +====================+===============+============================+ 881 | INGRESS_PROTECTION | 206 | 1: INGRESS_PROTECTION_IPv4 | 882 | | is suggested +----------------------------+ 883 | | | 2: INGRESS_PROTECTION_IPv6 | 884 +--------------------+---------------+----------------------------+ 886 IANA is requested to assign Types for new TLVs in the new objects as 887 follows: 889 Type Name Allowed in 890 1 BACKUP_INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4 891 2 BACKUP_INGRESS_IPv6_ADDRESS INGRESS_PROTECTION_IPv6 892 3 INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4 893 4 INGRESS_IPv6_ADDRESS INGRESS_PROTECTION_IPv6 894 5 TRAFFIC_DESCRIPTOR_INTERFACE INGRESS_PROTECTION 895 6 TRAFFIC_DESCRIPTOR_IPv4_PREFIX INGRESS_PROTECTION_IPv4 896 7 TRAFFIC_DESCRIPTOR_IPv6_PREFIX INGRESS_PROTECTION_IPv6 897 8 TRAFFIC_DESCRIPTOR_APPLICATION INGRESS_PROTECTION 898 9 LabeL_Routes INGRESS_PROTECTION 900 9. Contributors 902 Renwei Li 903 Huawei Technologies 904 2330 Central Expressway 905 Santa Clara, CA 95050 906 USA 907 Email: renwei.li@huawei.com 909 Quintin Zhao 910 Huawei Technologies 911 Boston, MA 912 USA 913 Email: quintin.zhao@huawei.com 915 Zhenbin Li 916 Huawei Technologies 917 2330 Central Expressway 918 Santa Clara, CA 95050 919 USA 920 Email: zhenbin.li@huawei.com 922 Boris Zhang 923 Telus Communications 924 200 Consilium Pl Floor 15 925 Toronto, ON M1H 3J3 926 Canada 927 Email: Boris.Zhang@telus.com 928 Markus Jork 929 Juniper Networks 930 10 Technology Park Drive 931 Westford, MA 01886 932 USA 933 Email: mjork@juniper.net 935 10. Acknowledgement 937 The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric 938 Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue, Alia 939 Atlas, Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, 940 Gregory Mirsky, and Ronhazli Adam for their valuable comments and 941 suggestions on this draft. 943 11. Normative References 945 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 946 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 947 RFC2119, March 1997, 948 . 950 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 951 Label Switching Architecture", RFC 3031, DOI 10.17487/ 952 RFC3031, January 2001, 953 . 955 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 956 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 957 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 958 . 960 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 961 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 962 DOI 10.17487/RFC4090, May 2005, 963 . 965 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 966 Yasukawa, Ed., "Extensions to Resource Reservation 967 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 968 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 969 DOI 10.17487/RFC4875, May 2007, 970 . 972 Appendix A. Problem Summary 974 There is a need for a fast and efficient protection against the 975 failure of the ingress node of a MPLS TE LSP (either P2MP LSP or P2P 976 LSP). 978 For a MPLS TE LSP, protecting the failures of its transit nodes using 979 fast-reroute (FRR) is covered in RFC 4090 for P2P LSP and RFC 4875 980 for P2MP LSP. However, protecting the failure of its ingress node 981 using FRR is not covered in either RFC 4090 or RFC 4875. The MPLS 982 Transport Profile (MPLS-TP) Linear Protection described in RFC 6378 983 can provide a protection against the failure of any transit node of a 984 LSP between the ingress node and the egress node of the LSP, but 985 cannot protect against the failure of the ingress node. 987 To protect against the failure of the (primary) ingress node of a 988 primary end to end P2MP (or P2P) TE LSP, a typical existing solution 989 is to set up a secondary backup end to end P2MP (or P2P) TE LSP from 990 a backup ingress node, which is different from the primary ingress 991 node, to the backup egress nodes (or node), which are (or is) 992 different from the primary egress nodes (or node) of the primary LSP. 993 For a P2MP TE LSP, on each of the primary (and backup) egress nodes, 994 a P2P LSP is created from the egress node to its primary (backup) 995 ingress node and configured with BFD. This is used to detect the 996 failure of the primary (backup) ingress node for the receiver to 997 switch to the backup (or primary) egress node to receive the traffic 998 after the primary (or backup) ingress node fails when both the 999 primary LSP and the secondary LSP carry the traffic. In addition, 1000 FRR may be used to provide protections against the failures of the 1001 transit nodes and the links of the primary and secondary end to end 1002 TE LSPs. 1004 There are a number of issues in this solution, which are briefed as 1005 follows: 1007 o It consumes lots of network resources. Double states need to be 1008 maintained in the network since two end to end TE LSPs are 1009 created. Double link bandwidth is reserved and used when both the 1010 primary and the secondary end to end TE LSPs carry the traffic at 1011 the same time. 1013 o More operations are needed, which include the configurations of 1014 two end to end TE LSPs and BFDs from each of the egress nodes to 1015 its corresponding ingress node. 1017 o The detection of the failure of the ingress node may not be 1018 reliable. Any failure on the path of the BFD from an egress node 1019 to an ingress node may cause the BFD down to indicate the failure 1020 of the ingress node. 1022 o The speed of protection against the failure of the ingress node 1023 may be slow. 1025 The ingress local protection proposed in this draft will resolve the 1026 above issues. 1028 The Pseudowire (PW) protection in PALS is a different level 1029 protection than the TE LSP tunnel protection in TEAS. The former is 1030 about protecting a PW, which is one level above an LSP tunnel. 1032 Draft "Dual-Homing Protection for MPLS and MPLS-TP Pseudowires" in 1033 PALS describes a framework and several scenarios for Pseudowire (PW) 1034 dual-homing protection, which protects the failures in the Attachment 1035 Circuit (AC) or PW side. For protecting a working PW (against the 1036 failure of the primary PW ingress such as PE1), an end-to-end 1037 protection PW from a backup PW ingress such as PE2 is created. The 1038 protection PW crosses the network from a PE connecting to a CE to 1039 another PE connecting to another CE. 1041 Appendix B. Authors' Addresses 1043 Huaimo Chen 1044 Huawei Technologies 1045 Boston, MA 1046 USA 1047 Email: huaimo.chen@huawei.com 1049 Raveendra Torvi 1050 Juniper Networks 1051 10 Technology Park Drive 1052 Westford, MA 01886 1053 USA 1054 Email: rtorvi@juniper.net 1055 Ning So 1056 Tata Communications 1057 2613 Fairbourne Cir. 1058 Plano, TX 75082 1059 USA 1060 Email: ningso01@gmail.com 1062 Autumn Liu 1063 Ericsson 1064 300 Holger Way 1065 San Jose, CA 95134 1066 USA 1067 Email: autumn.liu@ericsson.com 1069 Yimin Shen 1070 Juniper Networks 1071 10 Technology Park Drive 1072 Westford, MA 01886 1073 USA 1074 Email: yshen@juniper.net 1076 Tarek Saad 1077 Cisco Systems 1078 Email: tsaad@cisco.com 1080 Fengman Xu 1081 Verizon 1082 2400 N. Glenville Dr 1083 Richardson, TX 75082 1084 USA 1085 Email: fengman.xu@verizon.com 1087 Mehmet Toy 1088 USA 1089 Email: mtoy054@yahoo.com 1090 Lei Liu 1091 USA 1092 Email: liulei.kddi@gmail.com