idnits 2.17.1 draft-hu-spring-segment-routing-proxy-forwarding-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (24 October 2021) is 908 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 583, but not defined == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 1000, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-07 == Outdated reference: A later version (-06) exists of draft-ietf-spring-segment-protection-sr-te-paths-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 Summary: 2 errors (**), 0 flaws (~~), 8 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: 27 April 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 24 October 2021 16 SR-TE Path Midpoint Restoration 17 draft-hu-spring-segment-routing-proxy-forwarding-15 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-TE path after the IGP converges. It provides the 31 restoration of the routes to an adjacency segment, a node segment and 32 a binding segment of the path. With the restoration of the routes to 33 the failure, the traffic is continuously sent to the neighbor of the 34 failure after the IGP converges. The neighbor as a PLR fast re- 35 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 RFC 2119 [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on 27 April 2022. 60 Copyright Notice 62 Copyright (c) 2021 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 67 license-info) in effect on the date of publication of this document. 68 Please review these documents carefully, as they describe your rights 69 and restrictions with respect to this document. Code Components 70 extracted from this document must include Simplified BSD License text 71 as described in Section 4.e of the Trust Legal Provisions and are 72 provided without warranty as described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Proxy Forwarding . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Extensions to IGP for Proxy Forwarding . . . . . . . . . . . 4 79 3.1. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 4 80 3.1.1. Advertising Proxy Forwarding . . . . . . . . . . . . 4 81 3.1.2. Advertising Binding Segment . . . . . . . . . . . . . 8 82 3.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 10 83 3.2.1. Advertising Proxy Forwarding . . . . . . . . . . . . 10 84 3.2.2. Advertising Binding Segment . . . . . . . . . . . . . 12 85 4. Building Proxy Forwarding Table . . . . . . . . . . . . . . . 13 86 4.1. Advertising Proxy Forwarding . . . . . . . . . . . . . . 15 87 4.2. Building Proxy Forwarding Table . . . . . . . . . . . . . 15 88 5. Use of Proxy Forwarding . . . . . . . . . . . . . . . . . . . 16 89 5.1. Next Segment is an Adjacency Segment . . . . . . . . . . 16 90 5.2. Next Segment is a Node Segment . . . . . . . . . . . . . 17 91 5.3. Next Segment is a Binding Segment . . . . . . . . . . . . 17 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 7.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 7.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 7.3. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 100 9.2. Informative References . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 Segment Routing Traffic Engineering (SR-TE) is a technology that 106 implements traffic engineering using a segment list. SR-TE supports 107 the creation of explicit paths using adjacency-SIDs, node-SIDs, 108 anycast-SIDs, and binding-SIDs. A node-SID in the segment list 109 defining an SR-TE path indicates a loose hop that the SR-TE path 110 should pass through. When the node fails, the network may no longer 111 be able to properly forward traffic on that SR-TE path. 113 [I-D.ietf-rtgwg-segment-routing-ti-lfa] describes an SR FRR mechanism 114 that provides fast re-route protection for the failure of a node on a 115 SR-TE path by the direct neighbor or say point of local repair (PLR) 116 to the failure. However, once the IGP converges, the SR FRR is no 117 longer sufficient to forward traffic of the path around the failure, 118 since the non-neighbors of the failure will no longer have a route to 119 the failed node and drop the traffic. 121 To solve this problem, 122 [I-D.ietf-spring-segment-protection-sr-te-paths] proposes that a hold 123 timer should be configured on every router in a network. After the 124 IGP converges on the event of a node failure, if the node-SID of the 125 failed node becomes unreachable, the forwarding changes should not be 126 communicated to the forwarding planes on all configured routers 127 (including PLRs for the failed node) until the hold timer expires. 128 This solution may not work for some cases such as some of nodes in 129 the network not supporting this solution. 131 This document describes a proxy forwarding mechanism for the 132 restoration of the routes to the failure of a SR-TE path after the 133 IGP converges. It provides the restoration of the routes to an 134 adjacency segment, a node segment and a binding segment on a failed 135 node along the SR-TE path. With the restoration of the routes to the 136 failure, the traffic for the SR-TE path is continuously sent to the 137 neighbor of the failure after the IGP converges. The neighbor as a 138 PLR fast re-routes the traffic around the failure. 140 2. Proxy Forwarding 142 In the proxy forwarding mechanism, each neighbor of a possible failed 143 node advertises its SR proxy forwarding capability in its network 144 domain when it has the capability. This capability indicates that 145 the neighbor (the Proxy Forwarder) will forward traffic on behalf of 146 the failed node. A router receiving the SR Proxy Forwarding 147 capability from the neighbors of a failed node will send traffic 148 using the node-SID of the failed node to the nearest Proxy Forwarder 149 after the IGP converges on the event of the failure. 151 Once the affected traffic reaches a Proxy Forwarder, it sends the 152 traffic on the post-failure shortest path to the node immediately 153 following the failed node in the segment list. 155 For a binding segment of a possible failed node, the node advertises 156 the information about the binding segment, including the binding SID 157 and the list of SIDs associated with the binding SID, to its direct 158 neighbors only. Note that the information is not advertised in the 159 network domain. 161 After the node fails and the IGP converges on the failure, the 162 traffic with the binding SID of the failed node will reach its 163 neighbor having SR Proxy Forwarding capability. Once receiving the 164 traffic, the neighbor swaps the binding SID with the list of SIDs 165 associated with the binding SID and sends the traffic along the post- 166 failure shortest path to the first node in the segment list. 168 3. Extensions to IGP for Proxy Forwarding 170 This section defines extensions to IGP for advertising the SR proxy 171 forwarding capability of a node in a network domain and the 172 information about each binding segment (including its binding SID and 173 the list of SIDs associated) of a node to its direct neighbors. 175 3.1. Extensions to OSPF 177 3.1.1. Advertising Proxy Forwarding 179 When a node P has the capability to do a SR proxy forwarding for all 180 its neighboring nodes for protecting the failures of these nodes, 181 node P advertises its SR proxy forwarding capability in its router 182 information opaque LSA, which contains a Router Functional 183 Capabilities TLV of the format as shown in Figure 1. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Functional Capabilities | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: Router Functional Capabilities TLV 195 One bit (called PF bit) in the Functional Capabilities field of the 196 TLV is used to indicate node P's SR proxy forwarding capability. 197 When this bit is set to one by node P, it indicates that node P is 198 capable of doing a SR proxy forwarding for its neighboring nodes. 200 For a node X in the network, it learns the prefix/node SID of node N, 201 which is originated and advertised by node N. It creates a proxy 202 prefix/node SID of node N for node P if node P is capable of doing SR 203 proxy forwarding for node N. The proxy prefix/node SID of node N for 204 node P is a copy of the prefix/node SID of node N originated by node 205 N, but stored under (or say, associated with) node P. The route to 206 the proxy prefix/node SID is through proxy forwarding capable nodes. 208 In normal operations, node X prefers to use the prefix/node SID of 209 node N. When node N fails, node X prefers to use the proxy prefix/ 210 node SID of node N. Thus node X will forward the traffic targeting 211 to the prefix/node SID of node N to node P when node N fails, and 212 node P will do a SR proxy forwarding for node N and forward the 213 traffic towards its final destination without going through node N. 214 After node N fails, node X will keep the FIB entry to the proxy 215 prefix/node SID of node N for a given period of time. 217 Note that the behaviors of normal IP forwarding and routing 218 convergences in a network are not changed at all by the SR proxy 219 forwarding. For example, the next hop used by BGP is an IP address 220 (or prefix). The IGP and BGP converge in normal ways for changes in 221 the network. The packet with its IP destination to this next hop is 222 forwarded according to the IP forwarding table (FIB) derived from IGP 223 and BGP routes. 225 If node P can not do a SR proxy forwarding for all its neighboring 226 nodes, but for some of them, then it advertises the node SID of each 227 of the nodes as a proxy node SID, indicating that it is able to do 228 proxy forwarding for the node SID. 230 A new TLV, called Proxy Node SIDs TLV, is defined for node P to 231 advertise the node SIDs of some of its neighboring nodes. It has the 232 format as shown in Figure 2. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type (TBD1) | Length | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Node SID Sub-TLVs | 240 : : 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 2: OSPF Proxy Node SIDs TLV 245 The Type (TBD1) is to be assigned by IANA. The TLV contains a number 246 of Node SID Sub-TLVs. The Length is the total size of the Node SID 247 Sub-TLVs included in the TLV. A Node SID Sub-TLV is the Prefix SID 248 Sub-TLV defined in [RFC8665]. 250 A proxy forwarding node P originates an Extended Prefix Opaque LSA 251 containing this new TLV. The TLV includes the Node SID Sub-TLVs for 252 the node SIDs of some of P's neighboring nodes. For each of some of 253 P's neighboring nodes, the Node SID Sub-TLV for its prefix/node SID 254 is included the TLV. This prefix/node SID is called a proxy prefix/ 255 node SID. 257 A proxy forwarding node will originate an Extended Prefix Opaque LSA, 258 which includes a Proxy Node SIDs TLV. The format of the LSA is shown 259 in Figure 3. 261 For a proxy forwarding node P, having a number of neighboring nodes, 262 P originates and maintains an Extended Prefix Opaque LSA, which 263 includes a Proxy Node SIDs TLV. The TLV contains the Prefix/Node SID 264 Sub-TLV for each of some of the neighboring nodes after node P 265 creates the corresponding proxy forwarding entries for protecting the 266 failure of some of the neighboring nodes. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | LS age | Options | LS Type | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Opaque Type(7)| Opaque ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Advertising Router | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | LS sequence number | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | LS checksum | Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 : TLVs : 283 : (including Proxy Node SIDs TLV) : 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 3: OSPFv2 Extended Prefix Opaque LSA 289 When an neighboring node fails, P maintains the LSA with the TLV 290 containing the Prefix/Node SID Sub-TLV for the neighboring node for a 291 given period of time. After the given period of time, the Prefix/ 292 Node SID Sub-TLV for the neighboring node is removed from the TLV in 293 the LSA and then after a given time the corresponding proxy 294 forwarding entries for protecting the failure of the neighboring node 295 is removed. 297 For a node X in the network, it learns the prefix/node SID of node N 298 and the proxy prefix/node SID of node N. The former is originated 299 and advertised by node N, and the latter is originated and advertised 300 by the proxy forwarding node P of node N. Note that the proxy 301 Prefix/Node SID Sub-TLV for node N does not contain a prefix of node 302 N, and the prefix is the prefix associated with the prefix/node SID 303 of node N originated by node N. 305 In normal operations, node X prefers to use the prefix/node SID of 306 node N. When node N fails, node X prefers to use the proxy prefix/ 307 node SID of node N. Thus node X will forward the traffic targeting 308 to node N to node P when node N fails, and node P will do a proxy 309 forwarding for node N and forward the traffic towards its destination 310 without going through node N. 312 3.1.2. Advertising Binding Segment 314 For a binding segment (or binding for short) on a node A, which 315 consists of a binding SID and a list of segments, node A advertises 316 an LSA containing the binding (i.e., the binding SID and the list of 317 the segments). The LSA is advertised only to each of the node A's 318 neighboring nodes. For OSPFv2, the LSA is a opaque LSA of LS type 9 319 (i.e., a link local scope LSA). 321 A binding segment is represented by binding segment TLV of the format 322 as shown in Figure 4. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type (TBD2) | Length | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Reserved |BindingSID Type| SIDs Type | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 ~ Binding SID Sub-TLV/value ~ 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 ~ SID Sub-TLVs/values ~ 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 4: OSPF Binding Segment TLV 338 It comprises a binding SID and a list of segments (SIDs). The fields 339 of this TLV are defined as follows: 341 Type: 2 octets, its value (TBD2) is to be assigned by IANA. 343 Length: 2 octets, its value is (4 + length of Sub-TLVs/values). 345 Binding SID Type (BT): 1 octet indicates whether the binding SID is 346 represented by a Sub-TLV or a value included in the TLV. For the 347 binding SID represented by a value, it indicates the type of binding 348 SID. The following BT values are defined: 350 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., Binding 351 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 352 TLV defined in [RFC8665]. BT != 0 indicates that the binding SID is 353 represented by a value. 355 o BT = 1: The binding SID value is a label, which is represented by 356 the 20 rightmost bits. The length of the value is 3 octets. 358 o BT = 2: The binding SID value is a 32-bit SID. The length of the 359 value is 4 octets. 361 SIDs Type (ST): 1 octet indicates whether the list of segments (SIDs) 362 are represented by Sub-TLVs or values included in the TLV. For the 363 SIDs represented by values, it indicates the type of SIDs. The 364 following ST values are defined: 366 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 367 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 368 TLV or a SID/Label Sub-TLV defined in [RFC8665]. ST != 0 indicates 369 that the SIDs are represented by values. 371 o ST = 1: Each of the SID values is a label, which is represented by 372 the 20 rightmost bits. The length of the value is 3 octets. 374 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 375 value is 4 octets. 377 The opaque LSA of LS Type 9 containing the binding segment (i.e., the 378 binding SID and the list of the segments) has the format as shown in 379 Figure 5. It may have Opaque Type of x (the exact type is to be 380 assigned by IANA) for Binding Segment Opaque LSA. 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | LS age | Options | LS Type (9) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Opaque Type(x)| Opaque ID | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Advertising Router | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | LS sequence number | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | LS checksum | Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 : Binding Segment TLVs : 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 5: OSPFv2 Binding Segment Opaque LSA 402 For every binding on a node A, the LSA originated by A contains a 403 binding segment TLV for it. 405 For node A running OSPFv3, it originates a link-local scoping LSA of 406 a new LSA function code (TBD3) containing binding segment TLVs for 407 the bindings on it. The format of the LSA is illustrated in 408 Figure 6. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | LS age |0|0|0| BS-LSA (TBD3) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Link State ID | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Advertising Router | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | LS Sequence Number | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | LS checksum | Length | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | | 424 : Binding Segment TLVs : 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 6: OSPFv3 Binding Segment Opaque LSA 430 The U-bit is set to 0, and the scope is set to 00 for link-local 431 scoping. 433 3.2. Extensions to IS-IS 435 3.2.1. Advertising Proxy Forwarding 437 When a node P has the capability to do a SR proxy forwarding for its 438 neighboring nodes for protecting the failures of them, node P 439 advertises its SR proxy forwarding capability in its LSP, which 440 contains a Router Capability TLV of Type 242 including a SR 441 capabilities sub-TLV of sub-Type 2. 443 One bit (called PF bit as shown in Figure 7) in the Flags field of 444 the SR capabilities sub-TLV is defined to indicate node P's SR proxy 445 forwarding capability. When this bit is set to one by node P, it 446 indicates that node P is capable of doing a SR proxy forwarding for 447 its neighboring nodes. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type (2) | Length | Flags | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Range | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 // SID/Label Sub-TLV (variable) // 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 0 1 2 3 4 5 6 7 460 +--+--+--+--+--+--+--+--+ 461 | I| V|PF| | 462 +--+--+--+--+--+--+--+--+ 463 Flags 465 Figure 7: SR Capabilities sub-TLV 467 If node P can not do a SR proxy forwarding for all its neighboring 468 nodes, but for some of them, then it advertises the node SID of each 469 of the nodes as a proxy node SID, indicating that it is able to do 470 proxy forwarding for the node SID. 472 The IS-IS SID/Label Binding TLV (suggested value 149) is defined in 473 [RFC8667]. A Proxy Forwarder uses the SID/Label Binding TLV to 474 advertise the node SID of its neighboring node. The Flags field of 475 the SID/Label Binding TLV is extended to include a P flag as shown in 476 Figure 8. The prefix/node SID in prefix/node SID Sub-TLV included in 477 SID/Label Binding TLV is identified as a proxy forwarding prefix/node 478 SID. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type | Length | Flags | RESERVED | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Range | Prefix Length | Prefix | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 // Prefix (continued, variable) // 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | SubTLVs (variable) | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 0 1 2 3 4 5 6 7 493 +-+-+-+-+-+-+-+-+ 494 |F|M|S|D|A|P| | 495 +-+-+-+-+-+-+-+-+ 496 Flags 498 Figure 8: SID/Label Binding TLV 500 Where: 502 P-Flag: Proxy forwarding flag. If set, this prefix/node SID is 503 advertised by the proxy node. This TLV is used to announce that the 504 node has the ability to proxy forward the prefix/node SID. 506 When the P-flag is set in the SID/Label Binding TLV, the following 507 usage rules apply. 509 The Range, Prefix Length and Prefix field are not used. They should 510 be set to zero on transmission and ignored on receipt. 512 SID/Label Binding TLV contains a number of prefix/node SID Sub-TLVs. 513 The TLV advertised by a proxy forwarding node P contains prefix/node 514 SID Sub-TLVs for the node SIDs of P's neighbor nodes. Each of the 515 Sub-TLVs is a prefix/node SID Sub-TLV defined in [RFC8667]. From the 516 SID in a prefix/node SID Sub-TLV advertised by the Proxy Forwarding 517 node, its prefix can be obtained through matching corresponding 518 prefix/node SID advertised by the neighbor/protected node using 519 TLV-135 (or 235, 236, or 237) together with the prefix/node SID Sub- 520 TLV. 522 3.2.2. Advertising Binding Segment 524 [I-D.ietf-spring-segment-routing-policy] has defined the usage of 525 binding-SID. For supporting binding SID proxy forwarding, a new IS- 526 IS TLV, called Binding Segment TLV, is defined. It contains a 527 binding SID and a list of segments (SIDs). This TLV may be 528 advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link 529 State PDUs (CS-LSP) [RFC7356]. Its format is shown in Figure 9. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Type | Length |BindingSID Type| SIDs Type | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 ~ Binding SID value/Sub-TLV ~ 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 ~ SID values/Sub-TLVs ~ 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Figure 9: IS-IS Binding Segment TLV 543 The fields of this TLV are defined as follows: 545 Type: 1 octet Suggested value 152 (to be assigned by IANA) 546 Length: 1 octet (2 + length of Sub-TLVs/values). 548 Binding SID Type (BT): 1 octet indicates whether the binding SID is 549 represented by a Sub-TLV or a value included in the TLV. For the 550 binding SID represented by a value, it indicates the type of binding 551 SID. The following BT values are defined: 553 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., binding 554 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 555 TLV defined in [RFC8667]. BT != 0 indicates that the binding SID is 556 represented by a value. 558 o BT = 1: The binding SID value is a label, which is represented by 559 the 20 rightmost bits. The length of the value is 3 octets. 561 o BT = 2: The binding SID value is a 32-bit SID. The length of the 562 value is 4 octets. 564 SIDs Type (ST): 1 octet indicates whether the SIDs are represented by 565 Sub-TLVs or values included in the TLV. For the SIDs represented by 566 values, it indicates the type of SIDs. The following ST values are 567 defined: 569 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 570 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 571 TLV or a SID/Label Sub-TLV defined in [RFC8667]. ST != 0 indicates 572 that the SIDs are represented by values. 574 o ST = 1: Each of the SID values is a label, which is represented by 575 the 20 rightmost bits. The length of the value is 3 octets. 577 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 578 value is 4 octets. 580 4. Building Proxy Forwarding Table 582 Figure 10 is used to illustrate the SR proxy forwarding approach. 583 Each node N has SRGB = [N000-N999]. RT1 is an ingress node of SR 584 domain. RT3 is a failure node. RT2 is a Point of Local Repair (PLR) 585 node, i.e., a proxy forwarding node. Three label stacks are shown in 586 the figure. Label Stack 1 uses only adjacency-SIDs and represents 587 the path RT1->RT2->RT3->RT4->RT5. Label Stack 2 uses only node-SIDs 588 and represents the ECMP-aware path RT1->RT3->RT4->RT5. Label Stack 3 589 uses a node-SID and a binding SID. The Binding-SID with label=100 at 590 RT3 represents the ECMP-aware path RT3->RT4->RT5. So Label Stack 3, 591 which consists of the node-SID for RT3 following by Binding-SID=100, 592 represents the ECMP-aware path RT1->RT3->RT4->RT5. 594 Node SID:2 Node SID:3 595 +-----+ +-----+ 596 | |----------+ | 597 / |RT2 | | RT3 |\ 598 / +-----+ +-----+ \ 599 / | \ /| \ 600 / | \ / | \ 601 / | \ / | \ 602 / | \ / | \ 603 / | \ / | \ 604 Node SID:1 | \ / | \Node SID:4 Node SID:5 605 +-----+ | \ / | +-----+ +-----+ 606 | | | X | | |-------| | 607 | RT1 | | / \ | | RT4 | | RT5 | 608 +-----+ | / \ | +-----+ +-----+ 609 \ | / \ | / 610 \ | / \ | / 611 \ | / \ | / 612 \ | / \ | / 613 \ | / \| / 614 \ |/ | / 615 \ +-----+ +-----+ / 616 \ | | | |/ 617 \ | RT6 |-----------| RT7 | 618 +-----+ +-----+ 619 Node SID:6 Node SID:7 621 +-----------------+ +--------------+ 622 | Node SRGB | | Adj-SID | +-------+ +-------+ +-------+ 623 +-----------------+ +--------------+ |Label | |Label | |Label | 624 | RT1:[1000-1999] | |RT1->RT2:10012| |Stack 1| |Stack 2| |Stack 3| 625 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 626 | RT2:[2000-2999] | |RT2->RT3:20023| | 10012 | | 1003 | | 1003 | 627 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 628 | RT3:[3000-3999] | |RT3->RT6:30036| | 20023 | | 3004 | | 100 | 629 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 630 | RT4:[4000=4999] | |RT3->RT7:30037| | 30034 | | 4005 | 100 is 631 +-----------------+ +--------------+ +-------+ +-------+ binding SID 632 | RT5:[5000-5999] | |RT3->RT4:30034| | 40045 | to 633 +-----------------+ +--------------+ +-------+ {30034,40045} 634 | RT6:[6000-6999] | |RT7->RT4:70074| 635 +-----------------+ +--------------+ 636 | RT7:[7000-7999] | |RT4->RT5:40045| 637 +-----------------+ +--------------+ 639 Figure 10: Topology of SR-TE Path 641 4.1. Advertising Proxy Forwarding 643 If the Point of Local Repair (PLR), for example, RT2, has the 644 capability to do a SR proxy forwarding for all its neighboring nodes, 645 it must advertise this capability. If the PLR can not do a SR proxy 646 forwarding for all its neighboring nodes, but for some of them, for 647 example, RT3, then it uses proxy Node SIDs TLV to advertise the 648 prefix-SID learned from RT3. The TLV contains the Sub-TLV/value for 649 the prefix/node SID of RT3 as a proxy SID. When RT3 fails, RT2 needs 650 to maintain the Sub-TLV/value for a period of time. When the proxy 651 forwarding table corresponding to the fault node is deleted (see 652 section 3.2), the Sub-TLV/value is withdrawn. The nodes in the 653 network (for example, RT1) learn the prefix/node SID TLV advertised 654 by RT3 and the proxy Node SIDs TLV advertised by RT2. When RT3 is 655 normal, the nodes prefer prefix/node SID TLV. When the RT3 fails, 656 the proxy prefix/node SIDs TLV advertised by RT2 is preferred. 658 4.2. Building Proxy Forwarding Table 660 A SR proxy node P needs to build an independent proxy forwarding 661 table for each neighbor N. The proxy forwarding table for node N 662 contains the following information: 664 1: Node N's SRGB range and the difference between the SRGB start 665 value of node P and that of node N; 667 2: All adjacency-SID of N and Node-SID of the node pointed to by node 668 N's adjacency-SID. 670 3: The binding-SID of N and the label stack associated with the 671 binding-SID. 673 Node P (PLR) uses a proxy forwarding table based on the next segment 674 to find a node N as a backup forwarding entry to the adj-SID and 675 Node-SID of node N. When node N fails, the proxy forwarding table 676 needs to be maintained for a period of time, which is recommended for 677 30 minutes. 679 Node RT3 in the topology of Figure 1 is node N, and node RT2 is node 680 P (PLR). RT2 builds the proxy forwarding table for RT3. RT2 681 calculates the proxy forwarding table for RT3, as shown in Figure 11. 683 +==========+===============+============+=============+==============+ 684 | In-label | SRGBDiffValue | Next Label | Action | Map Label | 685 +==========+===============+============+=============+==============+ 686 | 2003 | -1000 | 30034 | Fwd to RT4 | 2004 | 687 +----------+---------------+------------+-------------+--------------+ 688 | 30036 | Fwd to RT6 | 2006 | 689 +------------+-------------+--------------+ 690 | 30037 | Fwd to RT7 | 2007 | 691 +------------+-------------+--------------+ 692 | 100 | Swap to { 30034, 40045 } | 693 +------------+-------------+--------------+ 695 Figure 11: RT2's Proxy Forwarding Table for RT3 697 5. Use of Proxy Forwarding 699 Segment Routing Traffic Engineering supports the creation of explicit 700 paths using adjacency-SIDs, node-SIDs, and binding-SIDs. The label 701 stack is a combination of one or more of adjacency-SIDs, node-SIDs, 702 and binding-SIDs. This Section shows through example how a proxy 703 node uses the SR proxy forwarding mechanism to forward traffic to the 704 destination node when a node fails and the next segment of label 705 stack is adjacency-SIDs, node-SIDs, or binding-SIDs, respectively. 707 5.1. Next Segment is an Adjacency Segment 709 As shown in Figure 1, Label Stack 1 {10012, 20023, 30034, 40045} 710 represents SR-TE strict explicit path RT1->RT2->RT3->RT4->RT5. When 711 RT3 fails, node RT2 acts as a PLR, and uses next adj-SID (30034) of 712 the label stack to lookup the proxy forwarding table built by RT2 713 locally for RT3. The path returned is the label forwarding path to 714 RT3's next hop node RT4, which bypasses RT3. The specific steps are 715 as follows: 717 a. RT1 pops top adj-SID 10012, and forwards the packet to RT2; 719 b. RT2 uses the label 20023 to identify the next hop node RT3, which 720 has failed. RT2 pops label 20023 and queries the Proxy Forwarding 721 Table corresponding to RT3 with label 30034. The query result is 722 2004. RT2 uses 2004 as the incoming label to query the label 723 forwarding table. The next hop is RT7, and the incoming label is 724 changed to 7004. 726 c. So the packet leaves RT2 out the interface to RT7 with label 727 stack {7004, 40045}. RT4 forwards it to RT4, where the original path 728 is rejoined. 730 d. RT2 forwards packets to RT7. RT7 queries the local routing table 731 to forward the packet to RT4. 733 5.2. Next Segment is a Node Segment 735 As shown in Figure 1, Label Stack 2 {1003, 3004, 4005} represents SR- 736 TE loose path RT1->RT3->RT4->RT5, where 1003 is the node SID of RT3. 738 When the node RT3 fails, the proxy forwarding TLV advertised by the 739 RT2 is preferred to direct the traffic of the RT1 to the PLR node 740 RT2. Node RT2 acts as a PLR node and queries the proxy forwarding 741 table locally built for RT3. The path returned is the label 742 forwarding path to RT3's next hop node RT4, which bypasses RT3. The 743 specific steps are as follows: 745 a. RT1 swaps label 1003 to out-label 2003 to RT3. 747 b. RT2 receives the label forwarding packet whose top label of label 748 stack is 2003, and searches for the local Routing Table, the behavior 749 found is to lookup Proxy Forwarding table due to RT3 failure, RT2 750 pops label 2003. 752 c. RT2 uses 3004 as the in-label to lookup Proxy Forwarding table, 753 The value of Map Label calculated based on SRGBDiffValue is 2004. 754 and the query result is forwarding the packet to RT4. 756 d. Then RT2 queries the Routing Table to RT4, using the primary or 757 backup path to RT4. The next hop is RT7. 759 e. RT2 forwards the packet to RT7. RT7 queries the local routing 760 table to forward the packet to RT4. 762 f. After RT1 convergences, node SID 1003 is preferred to the proxy 763 SID implied/advertised by RT2. 765 5.3. Next Segment is a Binding Segment 767 As shown in Figure 1, Label Stack 3 {1003, 100} represents SR-TE 768 loose path RT1->RT3->RT4->RT5, where 100 is a Binding-SID, which 769 represents segment list {30034, 40045}. 771 When the node RT3 fails, the proxy forwarding SID implied or 772 advertised by the RT2 is preferred to forward the traffic of the RT1 773 to the PLR node RT2. Node RT2 acts as a PLR node and uses Binding- 774 SID to query the proxy forwarding table locally built for RT3. The 775 path returned is the label forwarding path to RT3's next hop node 776 (RT4), which bypasses RT3. The specific steps are as follows: 778 a. RT1 swaps label 1003 to out-label 2003 to RT3. 780 b. RT2 receives the label forwarding packet whose top label of label 781 stack is 2003, and searches for the local Routing Table, the behavior 782 found is to lookup Proxy Forwarding table due to RT3 failure. 784 c. RT2 uses Binding-SID:100 (label 2003 has pop) as the in-label to 785 lookup the Next Label record of the Proxy Forwarding Table, the 786 behavior found is to swap to Segment list {30034, 40045}. 788 d. RT2 swaps Binding-SID:100 to Segment list {30034, 40045}, and 789 uses the 3034 to lookup the Next Label record of the Proxy Forwarding 790 table again. The behavior found is to forward the packet to RT4. 792 e. RT2 queries the Routing Table to RT4, using primary or backup 793 path to RT4. The next hop is RT7. 795 f. RT2 forwards packets to RT7. RT7 queries the local routing table 796 to forward the packet to RT4. 798 6. Security Considerations 800 The extensions to OSPF and IS-IS described in this document result in 801 two types of behaviors in data plane when a node in a network fails. 802 One is that for a node, which is a upstream (except for the direct 803 upstream) node of the failed node along a SR-TE path, it continues to 804 send the traffic to the failed node along the SR-TE path for an 805 extended period of time. The other is that for a node, which is the 806 direct upstream node of the failed node, it fast re-routes the 807 traffic around the failed node to the direct downstream node of the 808 failed node along the SR-TE path. These behaviors are internal to a 809 network and should not cause extra security issues. 811 7. IANA Considerations 813 7.1. OSPFv2 815 Under Subregistry Name "OSPF Router Functional Capability Bits" 816 within the "Open Shortest Path First v2 (OSPFv2) Parameters" 817 [RFC7770], IANA is requested to assign one bit for Proxy Forwarding 818 Capability as follows: 820 +============+==================+===================+ 821 | Bit number | Capability Name | Reference | 822 +============+==================+===================+ 823 | 31 | Proxy Forwarding | This document | 824 +------------+------------------+-------------------+ 826 Under Registry Name "OSPFv2 Extended Prefix Opaque LSA TLVs" 827 [RFC7684], IANA is requested to assign one new TLV value for OSPF 828 Proxy Node SIDs as follows: 830 +============+=====================+================+ 831 | TLV Value | TLV Name | Reference | 832 +============+=====================+================+ 833 | 2 | Proxy Node SIDs TLV | This document | 834 +------------+---------------------+----------------+ 836 Under Registry Name "Opaque Link-State Advertisements (LSA) Option 837 Types" [RFC5250], IANA is requested to assign new Opaque Type 838 registry values for Binding Segment LSA as follows: 840 +================+==================+================+ 841 | Registry Value | Opaque Type | Reference | 842 +================+==================+================+ 843 | 10 | Binding Segment | This document | 844 +----------------+------------------+----------------+ 846 IANA is requested to create and maintain new registries: 848 o OSPFv2 Binding Segment Opaque LSA TLVs 850 Initial values for the registry are given below. The future 851 assignments are to be made through IETF Review [RFC5226]. 853 Value TLV Name Definition 854 ----- ----------------------- ---------- 855 0 Reserved 856 1 Binding Segment TLV This Document 857 2-32767 Unassigned 858 32768-65535 Reserved 860 7.2. OSPFv3 862 Under Registry Name "OSPFv3 LSA Function Codes", IANA is requested to 863 assign new registry values for Binding Segment LSA as follows: 865 +========+========================+================+ 866 | Value | LSA Function Code Name | Reference | 867 +========+========================+================+ 868 | 16 | Binding Segment LSA | This document | 869 +--------+------------------------+----------------+ 871 IANA is requested to create and maintain new registries: 873 o OSPFv3 Binding Segment LSA TLVs 875 Initial values for the registry are given below. The future 876 assignments are to be made through IETF Review [RFC5226]. 878 Value TLV Name Definition 879 ----- ----------------------- ---------- 880 0 Reserved 881 1 Binding Segment TLV This Document 882 2-32767 Unassigned 883 32768-65535 Reserved 885 7.3. IS-IS 887 Under Registration "Segment Routing Capability" in the "sub-TLVs for 888 TLV 242" registry [RFC8667], IANA is requested to assign one bit flag 889 for Proxy Forwarding Capability as follows: 891 +============+=======================+===============+ 892 | Bit number | Capability Name | Reference | 893 +============+=======================+===============+ 894 | 2 | Proxy Forwarding (PF) | This document | 895 +------------+-----------------------+---------------+ 897 Under Registration "Segment Identifier/Label Binding TLV 149" 898 [RFC8667], IANA is requested to assign one bit P-Flag as follows: 900 +============+=================+===============+ 901 | Bit number | Flag Name | Reference | 902 +============+=================+===============+ 903 | 5 | P-Flag | This document | 904 +------------+-----------------+---------------+ 906 Under Registry Name: IS-IS TLV Codepoints, IANA is requested to 907 assign one new TLV value for IS-IS Binding Segment as follows: 909 +========+======================+===============+ 910 | Value | TLV Name | Reference | 911 +========+======================+===============+ 912 | 152 | Binding Segment TLV | This Document | 913 +--------+----------------------+---------------+ 915 8. Acknowledgements 917 The authors would like to thank Peter Psenak, Acee Lindem, Les 918 Ginsberg, Bruno Decraene and Jeff Tantsura for their comments to this 919 work. 921 9. References 923 9.1. Normative References 925 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 926 Requirement Levels", BCP 14, RFC 2119, 927 DOI 10.17487/RFC2119, March 1997, 928 . 930 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 931 IANA Considerations Section in RFCs", RFC 5226, 932 DOI 10.17487/RFC5226, May 2008, 933 . 935 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 936 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 937 July 2008, . 939 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 940 Scope Link State PDUs (LSPs)", RFC 7356, 941 DOI 10.17487/RFC7356, September 2014, 942 . 944 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 945 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 946 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 947 2015, . 949 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 950 S. Shaffer, "Extensions to OSPF for Advertising Optional 951 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 952 February 2016, . 954 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 955 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 956 Extensions for Segment Routing", RFC 8665, 957 DOI 10.17487/RFC8665, December 2019, 958 . 960 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 961 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 962 Extensions for Segment Routing", RFC 8667, 963 DOI 10.17487/RFC8667, December 2019, 964 . 966 9.2. Informative References 968 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 969 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 970 Decraene, B., and D. Voyer, "Topology Independent Fast 971 Reroute using Segment Routing", Work in Progress, 972 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 973 07, 29 June 2021, . 976 [I-D.ietf-spring-segment-protection-sr-te-paths] 977 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 978 "Segment Protection for SR-TE Paths", Work in Progress, 979 Internet-Draft, draft-ietf-spring-segment-protection-sr- 980 te-paths-01, 11 July 2021, 981 . 984 [I-D.ietf-spring-segment-routing-policy] 985 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 986 P. Mattes, "Segment Routing Policy Architecture", Work in 987 Progress, Internet-Draft, draft-ietf-spring-segment- 988 routing-policy-13, 28 May 2021, 989 . 992 [I-D.sivabalan-pce-binding-label-sid] 993 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 994 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 995 in PCE-based Networks.", Work in Progress, Internet-Draft, 996 draft-sivabalan-pce-binding-label-sid-07, 8 July 2019, 997 . 1000 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1001 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1002 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 1003 2009, . 1005 Authors' Addresses 1006 Zhibo Hu 1007 Huawei Technologies 1008 Huawei Bld., No.156 Beiqing Rd. 1009 Beijing 1010 100095 1011 China 1013 Email: huzhibo@huawei.com 1015 Huaimo Chen 1016 Futurewei 1017 Boston, MA, 1018 United States of America 1020 Email: Huaimo.chen@futurewei.com 1022 Junda Yao 1023 Huawei Technologies 1024 Huawei Bld., No.156 Beiqing Rd. 1025 Beijing 1026 100095 1027 China 1029 Email: yaojunda@huawei.com 1031 Chris Bowers 1032 Juniper Networks 1033 1194 N. Mathilda Ave. 1034 Sunnyvale, CA, 94089 1035 United States of America 1037 Email: cbowers@juniper.net 1039 Yongqing 1040 China Telecom 1041 109, West Zhongshan Road, Tianhe District 1042 Guangzhou 1043 510000 1044 China 1046 Email: zhuyq8@chinatelecom.cn 1047 Yisong 1048 China Mobile 1049 510000 1050 China 1052 Email: liuyisong@chinamobile.com