idnits 2.17.00 (12 Aug 2021) /tmp/idnits48537/draft-hu-spring-segment-routing-proxy-forwarding-19.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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (11 April 2022) is 33 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'N000-N999' is mentioned on line 246, but not defined == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 463, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Hu 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track H. Chen 5 Expires: 13 October 2022 Futurewei 6 J. Yao 7 Huawei Technologies 8 C. Bowers 9 Juniper Networks 10 Y. Zhu 11 China Telecom 12 Y. Liu 13 China Mobile 14 11 April 2022 16 SR-TE Path Midpoint Restoration 17 draft-hu-spring-segment-routing-proxy-forwarding-19 19 Abstract 21 Segment Routing Traffic Engineering (SR-TE) supports explicit paths 22 using segment lists containing adjacency-SIDs, node-SIDs and binding- 23 SIDs. The current SR FRR such as TI-LFA provides fast re-route 24 protection for the failure of a node along a SR-TE path by the direct 25 neighbor or say point of local repair (PLR) to the failure. However, 26 once the IGP converges, the SR FRR is no longer sufficient to forward 27 traffic of the path around the failure, since the non-neighbors of 28 the failure will no longer have a route to the failed node. This 29 document describes a mechanism for the restoration of the routes to 30 the failure of a SR-MPLS TE path after the IGP converges. It 31 provides the restoration of the routes to an adjacency segment, a 32 node segment and a binding segment of the path. With the restoration 33 of the routes to the failure, the traffic is continuously sent to the 34 neighbor of the failure after the IGP converges. The neighbor as a 35 PLR fast re-routes the traffic around the failure. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC2119] [RFC8174] 42 when, and only when, they appear in all capitals, as shown here. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on 13 October 2022. 61 Copyright Notice 63 Copyright (c) 2022 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Revised BSD License text as 72 described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Revised BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Proxy Forwarding . . . . . . . . . . . . . . . . . . . . . . 4 80 3. Protocol Extensions/Re-uses for Proxy Forwarding . . . . . . 4 81 3.1. Advertising Binding Segment . . . . . . . . . . . . . . . 4 82 3.2. Advertising Proxy Forwarding . . . . . . . . . . . . . . 5 83 4. Proxy Forwarding Example . . . . . . . . . . . . . . . . . . 6 84 4.1. Advertising Proxy Forwarding . . . . . . . . . . . . . . 8 85 4.2. Building Proxy Forwarding Table . . . . . . . . . . . . . 8 86 4.3. Proxy Forwarding for Binding Segment . . . . . . . . . . 9 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 91 7.2. Informative References . . . . . . . . . . . . . . . . . 11 92 Appendix A. Proxy Forwarding for Adjacency and Node Segment . . 11 93 A.1. Next Segment is an Adjacency Segment . . . . . . . . . . 11 94 A.2. Next Segment is a Node Segment . . . . . . . . . . . . . 12 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 97 1. Introduction 99 Segment Routing Traffic Engineering (SR-TE) is a technology that 100 implements traffic engineering using a segment list. SR-TE supports 101 the creation of explicit paths using adjacency-SIDs, node-SIDs, 102 anycast-SIDs, and binding-SIDs. A node-SID in the segment list 103 defining an SR-TE path indicates a loose hop that the SR-TE path 104 should pass through. When the node fails, the network may no longer 105 be able to properly forward traffic on that SR-TE path. 107 [I-D.ietf-rtgwg-segment-routing-ti-lfa] describes an SR FRR mechanism 108 that provides fast re-route protection for the failure of a node on a 109 SR-TE path by the direct neighbor or say point of local repair (PLR) 110 to the failure. However, once the IGP converges, the SR FRR is no 111 longer sufficient to forward traffic of the path around the failure, 112 since the non-neighbors of the failure will no longer have a route to 113 the failed node and drop the traffic. 115 To solve this problem, 116 [I-D.ietf-spring-segment-protection-sr-te-paths] proposes that a hold 117 timer should be configured on every router in a network. After the 118 IGP converges on the event of a node failure, if the node-SID of the 119 failed node becomes unreachable, the forwarding changes should not be 120 communicated to the forwarding planes on all configured routers 121 (including PLRs for the failed node) until the hold timer expires. 122 This solution may not work for some cases such as some of nodes in 123 the network not supporting this solution. 125 This document describes a proxy forwarding mechanism for the 126 restoration of the routes to the failure of a SR-MPLS TE path after 127 the IGP converges. It provides the restoration of the routes to an 128 adjacency segment, a node segment and a binding segment on a failed 129 node along the path. With the restoration of the routes to the 130 failure, the traffic for the SR-MPLS TE path is continuously sent to 131 the neighbor of the failure after the IGP converges. The neighbor as 132 a PLR fast re-routes the traffic around the failure. 134 1.1. Terminology 136 SR: Segment Routing. 138 PLR: Point of Local Repair. 140 LSP: Link State Protocol Data Unit (PDU) in IS-IS. 142 LSA: Link State Advertisement in OSPF. 144 LS: Link State, which is LSP or LSA. 146 2. Proxy Forwarding 148 In the proxy forwarding mechanism, each neighbor of a possible failed 149 node advertises its SR proxy forwarding capability in its network 150 domain when it has the capability. This capability indicates that 151 the neighbor (the Proxy Forwarder) will forward traffic on behalf of 152 the failed node. A router receiving the SR Proxy Forwarding 153 capability from the neighbors of a failed node will send traffic 154 using the node-SID of the failed node to the nearest Proxy Forwarder 155 after the IGP converges on the event of the failure. 157 Once the affected traffic reaches a Proxy Forwarder, it sends the 158 traffic on the post-failure shortest path to the node immediately 159 following the failed node in the segment list. 161 For a binding segment of a possible failed node, the node advertises 162 the information about the binding segment, including the binding SID 163 and the list of SIDs/segments associated with the binding SID, to its 164 direct neighbors only. Note that the information is not advertised 165 in the network domain. 167 After the node fails and the IGP converges on the failure, the 168 traffic with the binding SID of the failed node will reach its 169 neighbor having SR Proxy Forwarding capability. Once receiving the 170 traffic, the neighbor swaps the binding SID with the list of SIDs/ 171 segments associated with the binding SID and sends the traffic along 172 the post-failure shortest path to the first node in the segment list. 174 3. Protocol Extensions/Re-uses for Proxy Forwarding 176 This section describes the semantic of protocol extensions/re-uses 177 for advertising the information about each binding segment (including 178 its binding SID and the list of SIDs/segments associated with the 179 binding SID) of a node to its direct neighbors and the SR proxy 180 forwarding capability of a node in a network domain. 182 3.1. Advertising Binding Segment 184 For a binding segment (or binding for short) on a node A, which 185 consists of a binding SID and a list of SIDs/segments, node A 186 advertises an LS containing the binding (i.e., the binding SID and 187 the list of the SIDs/segments) in a binding segment TLV. The LS is 188 advertised only to each of the node A's neighboring nodes. For 189 OSPFv2, the LS is a opaque LSA of LS type 9 (i.e., a link local scope 190 LSA). For IS-IS, the TLV is advertised in Circuit Scoped Link State 191 PDUs (CS-LSP) [RFC7356]. 193 Alternatively, when a protocol (such as PCE or BGP running on a 194 controller) supports sending a binding on a node A to A, this 195 protocol may be extended to send the binding with node A to A's 196 neighbors if the controller knows the neighbors and there are 197 protocol (PCE or BGP) sessions between the controller and the 198 neighbors. 200 Note: how to send bindings of node A to A's neighbors via which 201 protocol is out of the scope of this document. 203 3.2. Advertising Proxy Forwarding 205 When a node P is able to do SR proxy forwarding for its neighboring 206 nodes for protecting the failures of these nodes, P advertises its SR 207 proxy forwarding capability for these nodes. The mirror SID 208 [RFC8402] for a node N (Neighbor of P) advertised by P using IS-IS 209 extensions [RFC8667] indicates the capability of P for N. 211 For a node X in the network, it learns the prefix/node SID of node N, 212 which is originated and advertised by node N. It creates a proxy 213 prefix/node SID of node N for node P if node P is capable of doing SR 214 proxy forwarding for node N. The proxy prefix/node SID of node N for 215 node P is a copy of the prefix/node SID of node N originated by node 216 N, but stored under (or say, associated with) node P. The route to 217 the proxy prefix/node SID is through proxy forwarding capable nodes. 219 In normal operations, node X prefers to use the prefix/node SID of 220 node N. When node N fails, node X prefers to use the proxy prefix/ 221 node SID of node N. Thus node X will forward the traffic targeting 222 to the prefix/node SID of node N to node P when node N fails, and 223 node P will do a SR proxy forwarding for node N and forward the 224 traffic towards its final destination without going through node N. 226 Note that the behaviors of normal IP forwarding and routing 227 convergences in a network are not changed at all by the SR proxy 228 forwarding. For example, the next hop used by BGP is an IP address 229 (or prefix). The IGP and BGP converge in normal ways for changes in 230 the network. The packet with its IP destination to this next hop is 231 forwarded according to the IP forwarding table (FIB) derived from IGP 232 and BGP routes. 234 Similar to IS-IS [RFC8667], OSPF should be extended for advertising 235 mirror SID to indicate the capability. Note that OSPF extensions is 236 out of the scope of this document. 238 4. Proxy Forwarding Example 240 This section illustrates the proxy forwarding for a binding SID 241 through an example. The proxy forwarding for a node SID and an 242 adjacency SID can refer to 243 [I-D.ietf-spring-segment-protection-sr-te-paths] or Appendix. 244 Figure 1 is an example network topology used to illustrate the proxy 245 forwarding mechanism for a binding SID. Each node N has SRGB = 246 [N000-N999]. RT1 is an ingress node of SR domain. RT3 is a failure 247 node. RT2 is a Point of Local Repair (PLR) node, i.e., a proxy 248 forwarding node. Label Stack 1 uses a node-SID and a binding SID. 249 The Binding-SID with label=100 at RT3 represents the ECMP-aware path 250 RT3->RT4->RT5. So Label Stack 1, which consists of the node-SID for 251 RT3 following by Binding-SID=100, represents the ECMP-aware path 252 RT1->RT3->RT4->RT5. 254 Node SID:2 Node SID:3 255 +-----+ +-----+ 256 | |----------+ | 257 / |RT2 | | RT3 |\ 258 / +-----+ +-----+ \ 259 / | \ /| \ 260 / | \ / | \ 261 / | \ / | \ 262 / | \ / | \ 263 / | \ / | \ 264 Node SID:1 | \ / | \Node SID:4 Node SID:5 265 +-----+ | \ / | +-----+ +-----+ 266 | | | X | | |-------| | 267 | RT1 | | / \ | | RT4 | | RT5 | 268 +-----+ | / \ | +-----+ +-----+ 269 \ | / \ | / 270 \ | / \ | / 271 \ | / \ | / 272 \ | / \ | / 273 \ | / \| / 274 \ |/ | / 275 \ +-----+ +-----+ / 276 \ | | | |/ 277 \ | RT6 |-----------| RT7 | 278 +-----+ +-----+ 279 Node SID:6 Node SID:7 281 +-----------------+ +--------------+ 282 | Node SRGB | | Adj-SID | +-------+ +-------+ +-------+ 283 +-----------------+ +--------------+ |Label | |Label | |Label | 284 | RT1:[1000-1999] | |RT1->RT2:10012| |Stack 3| |Stack 2| |Stack 1| 285 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 286 | RT2:[2000-2999] | |RT2->RT3:20023| | 10012 | | 1003 | | 1003 | 287 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 288 | RT3:[3000-3999] | |RT3->RT6:30036| | 20023 | | 3004 | | 100 | 289 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 290 | RT4:[4000=4999] | |RT3->RT7:30037| | 30034 | | 4005 | 100 is 291 +-----------------+ +--------------+ +-------+ +-------+ binding SID 292 | RT5:[5000-5999] | |RT3->RT4:30034| | 40045 | to 293 +-----------------+ +--------------+ +-------+ {30034,40045} 294 | RT6:[6000-6999] | |RT7->RT4:70074| 295 +-----------------+ +--------------+ 296 | RT7:[7000-7999] | |RT4->RT5:40045| 297 +-----------------+ +--------------+ 299 Figure 1: Topology of SR-TE Path 301 4.1. Advertising Proxy Forwarding 303 If the Point of Local Repair (PLR), for example, RT2, has the 304 capability to do SR proxy forwarding for its neighboring nodes such 305 as RT3, it must advertise this capability. When RT3 fails, RT2 needs 306 to maintain its SR proxy forwarding capability for a period of time. 307 When the proxy forwarding table corresponding to the fault node is 308 deleted, the capability is withdrawn. The nodes in the network (for 309 example, RT1) learn the prefix/node SID advertised by RT3 and the 310 proxy forwarding capability for RT3 advertised by RT2. When RT3 is 311 normal, the nodes prefer prefix/node SID. When the RT3 fails, the 312 proxy prefix/node SIDs of RT3 for RT2 is preferred. 314 For binding-SID 100, which is associated with segment list {30034, 315 40045}, RT3 advertises the binding (i.e., 100 bond to {30034, 40045}) 316 to its neighbors RT2, RT4 and RT7. RT2 as PLR uses the binding to 317 build an entry for proxy forwarding for binding-SID 100 in its Proxy 318 Forwarding Table for RT3. The entry is used when RT3 fails. 320 4.2. Building Proxy Forwarding Table 322 A SR proxy node P needs to build an independent proxy forwarding 323 table for each neighbor N. The proxy forwarding table for node N 324 contains the following information: 326 1: Node N's SRGB range and the difference between the SRGB start 327 value of node P and that of node N; 329 2: Every adjacency-SID of N and Node-SID of the node pointed to by 330 node N's adjacency-SID. 332 3: Every binding-SID of N and the label stack associated with the 333 binding-SID. 335 Node P (PLR) uses a proxy forwarding table based on the next segment 336 to find a node N as a backup forwarding entry to the adjacency-SID 337 and Node-SID of node N. When node N fails, the proxy forwarding 338 table needs to be maintained for a period of time, which is 339 recommended for 30 minutes. 341 Node RT3 in Figure 1 is node N, and node RT2 is node P (PLR). RT2 342 builds the proxy forwarding table for RT3. RT2 calculates the proxy 343 forwarding table for RT3, as shown in Figure 2. 345 +==========+===============+============+=============+==============+ 346 | In-label | SRGBDiffValue | Next Label | Action | Map Label | 347 +==========+===============+============+=============+==============+ 348 | 2003 | -1000 | 30034 | Fwd to RT4 | 2004 | 349 +----------+---------------+------------+-------------+--------------+ 350 | 30036 | Fwd to RT6 | 2006 | 351 +------------+-------------+--------------+ 352 | 30037 | Fwd to RT7 | 2007 | 353 +------------+-------------+--------------+ 354 | 100 | Swap to { 30034, 40045 } | 355 +------------+-------------+--------------+ 357 Figure 2: RT2's Proxy Forwarding Table for RT3 359 4.3. Proxy Forwarding for Binding Segment 361 This Section shows through example how a proxy node uses the SR proxy 362 forwarding mechanism to forward traffic to the destination node when 363 a node fails and the next segment of label stack is a binding-SID. 365 As shown in Figure 1, Label Stack 1 {1003, 100} represents SR-TE 366 loose path RT1->RT3->RT4->RT5, where 100 is a Binding-SID, which 367 represents segment list {30034, 40045}. 369 When the node RT3 fails, the proxy forwarding SID implied or 370 advertised by the RT2 is preferred to forward the traffic of the RT1 371 to the PLR node RT2. Node RT2 acts as a PLR node and uses Binding- 372 SID to query the proxy forwarding table locally built for RT3. The 373 path returned is the label forwarding path to RT3's next hop node 374 (RT4), which bypasses RT3. The specific steps are as follows: 376 a. RT1 swaps label 1003 to out-label 2003 to RT3. 378 b. RT2 receives the label forwarding packet whose top label of label 379 stack is 2003, and searches for the local Routing Table, the behavior 380 found is to lookup Proxy Forwarding table due to RT3 failure. 382 c. RT2 uses Binding-SID:100 (label 2003 has pop) as the in-label to 383 lookup the Next Label record of the Proxy Forwarding Table, the 384 behavior found is to swap to Segment list {30034, 40045}. 386 d. RT2 swaps Binding-SID:100 to Segment list {30034, 40045}, and 387 uses the 30034 to lookup the Next Label record of the Proxy 388 Forwarding table again. The behavior found is to forward the packet 389 to RT4. 391 e. RT2 queries the Routing Table to RT4, using primary or backup 392 path to RT4. The next hop is RT7. 394 f. RT2 forwards packets to RT7. RT7 queries the local routing table 395 to forward the packet to RT4. 397 5. Security Considerations 399 The extensions to OSPF and IS-IS described in this document result in 400 two types of behaviors in data plane when a node in a network fails. 401 One is that for a node, which is a upstream (except for the direct 402 upstream) node of the failed node along a SR-TE path, it continues to 403 send the traffic to the failed node along the SR-TE path for an 404 extended period of time. The other is that for a node, which is the 405 direct upstream node of the failed node, it fast re-routes the 406 traffic around the failed node to the direct downstream node of the 407 failed node along the SR-TE path. These behaviors are internal to a 408 network and should not cause extra security issues. 410 6. Acknowledgements 412 The authors would like to thank Peter Psenak, Acee Lindem, Les 413 Ginsberg, Bruno Decraene and Jeff Tantsura for their comments to this 414 work. 416 7. References 418 7.1. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 426 Scope Link State PDUs (LSPs)", RFC 7356, 427 DOI 10.17487/RFC7356, September 2014, 428 . 430 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 431 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 432 May 2017, . 434 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 435 Decraene, B., Litkowski, S., and R. Shakir, "Segment 436 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 437 July 2018, . 439 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 440 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 441 Extensions for Segment Routing", RFC 8667, 442 DOI 10.17487/RFC8667, December 2019, 443 . 445 7.2. Informative References 447 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 448 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 449 Decraene, B., and D. Voyer, "Topology Independent Fast 450 Reroute using Segment Routing", Work in Progress, 451 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 452 08, 21 January 2022, . 455 [I-D.ietf-spring-segment-protection-sr-te-paths] 456 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 457 "Segment Protection for SR-TE Paths", Work in Progress, 458 Internet-Draft, draft-ietf-spring-segment-protection-sr- 459 te-paths-03, 7 March 2022, 460 . 463 [I-D.ietf-spring-segment-routing-policy] 464 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 465 P. Mattes, "Segment Routing Policy Architecture", Work in 466 Progress, Internet-Draft, draft-ietf-spring-segment- 467 routing-policy-22, 22 March 2022, 468 . 471 Appendix A. Proxy Forwarding for Adjacency and Node Segment 473 This Section shows through example how a proxy node forward traffic 474 to the destination node when a node fails and the next segment of 475 label stack is an adjacency-SID or node-SID. 477 A.1. Next Segment is an Adjacency Segment 479 As shown in Figure 1, Label Stack 3 {10012, 20023, 30034, 40045} uses 480 only adjacency-SIDs and represents the SR-TE strict explicit path 481 RT1->RT2->RT3->RT4->RT5. When RT3 fails, node RT2 acts as a PLR, and 482 uses next adjacency-SID (30034) of the label stack to lookup the 483 proxy forwarding table built by RT2 locally for RT3. The path 484 returned is the label forwarding path to RT3's next hop node RT4, 485 which bypasses RT3. The specific steps are as follows: 487 a. RT1 pops top adjacency-SID 10012, and forwards the packet to RT2; 489 b. RT2 uses the label 20023 to identify the next hop node RT3, which 490 has failed. RT2 pops label 20023 and queries the Proxy Forwarding 491 Table corresponding to RT3 with label 30034. The query result is 492 2004. RT2 uses 2004 as the incoming label to query the label 493 forwarding table. The next hop is RT7, and the incoming label is 494 changed to 7004. 496 c. So the packet leaves RT2 out the interface to RT7 with label 497 stack {7004, 40045}. RT7 forwards it to RT4, where the original path 498 is rejoined. 500 d. RT2 forwards packets to RT7. RT7 queries the local routing table 501 to forward the packet to RT4. 503 A.2. Next Segment is a Node Segment 505 As shown in Figure 1, Label Stack 2 {1003, 3004, 4005} uses only 506 node-SIDs and represents the ECMP-aware path RT1->RT3->RT4->RT5, 507 where 1003 is the node SID of RT3. 509 When the node RT3 fails, the proxy forwarding TLV advertised by the 510 RT2 is preferred to direct the traffic of the RT1 to the PLR node 511 RT2. Node RT2 acts as a PLR node and queries the proxy forwarding 512 table locally built for RT3. The path returned is the label 513 forwarding path to RT3's next hop node RT4, which bypasses RT3. The 514 specific steps are as follows: 516 a. RT1 swaps label 1003 to out-label 2003 to RT3. 518 b. RT2 receives the label forwarding packet whose top label of label 519 stack is 2003, and searches for the local Routing Table, the behavior 520 found is to lookup Proxy Forwarding table due to RT3 failure, RT2 521 pops label 2003. 523 c. RT2 uses 3004 as the in-label to lookup Proxy Forwarding table, 524 The value of Map Label calculated based on SRGBDiffValue is 2004. 525 and the query result is forwarding the packet to RT4. 527 d. Then RT2 queries the Routing Table to RT4, using the primary or 528 backup path to RT4. The next hop is RT7. 530 e. RT2 forwards the packet to RT7. RT7 queries the local routing 531 table to forward the packet to RT4. 533 f. After RT1 convergences, node SID 1003 is preferred to the proxy 534 SID implied/advertised by RT2. 536 Authors' Addresses 538 Zhibo Hu 539 Huawei Technologies 540 Huawei Bld., No.156 Beiqing Rd. 541 Beijing 542 100095 543 China 544 Email: huzhibo@huawei.com 546 Huaimo Chen 547 Futurewei 548 Boston, MA, 549 United States of America 550 Email: Huaimo.chen@futurewei.com 552 Junda Yao 553 Huawei Technologies 554 Huawei Bld., No.156 Beiqing Rd. 555 Beijing 556 100095 557 China 558 Email: yaojunda@huawei.com 560 Chris Bowers 561 Juniper Networks 562 1194 N. Mathilda Ave. 563 Sunnyvale, CA, 94089 564 United States of America 565 Email: cbowers@juniper.net 567 Yongqing 568 China Telecom 569 109, West Zhongshan Road, Tianhe District 570 Guangzhou 571 510000 572 China 573 Email: zhuyq8@chinatelecom.cn 575 Yisong 576 China Mobile 577 510000 578 China 579 Email: liuyisong@chinamobile.com