idnits 2.17.1 draft-hu-spring-segment-routing-proxy-forwarding-14.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 (April 29, 2021) is 1092 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 585, but not defined == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 988, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 994, 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-06 == Outdated reference: A later version (-06) exists of draft-ietf-spring-segment-protection-sr-te-paths-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 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: October 31, 2021 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 April 29, 2021 16 SR-TE Path Midpoint Restoration 17 draft-hu-spring-segment-routing-proxy-forwarding-14 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 October 31, 2021. 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 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Proxy Forwarding . . . . . . . . . . . . . . . . . . . . . . 4 79 3. Extensions to IGP for Proxy Forwarding . . . . . . . . . . . 4 80 3.1. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 4 81 3.1.1. Advertising Proxy Forwarding . . . . . . . . . . . . 4 82 3.1.2. Advertising Binding Segment . . . . . . . . . . . . . 8 83 3.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 10 84 3.2.1. Advertising Proxy Forwarding . . . . . . . . . . . . 10 85 3.2.2. Advertising Binding Segment . . . . . . . . . . . . . 12 86 4. Building Proxy Forwarding Table . . . . . . . . . . . . . . . 14 87 4.1. Advertising Proxy Forwarding . . . . . . . . . . . . . . 16 88 4.2. Building Proxy Forwarding Table . . . . . . . . . . . . . 16 89 5. Use of Proxy Forwarding . . . . . . . . . . . . . . . . . . . 17 90 5.1. Next Segment is an Adjacency Segment . . . . . . . . . . 17 91 5.2. Next Segment is a Node Segment . . . . . . . . . . . . . 18 92 5.3. Next Segment is a Binding Segment . . . . . . . . . . . . 18 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 95 7.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 7.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 7.3. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 101 9.2. Informative References . . . . . . . . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 Segment Routing Traffic Engineering (SR-TE) is a technology that 107 implements traffic engineering using a segment list. SR-TE supports 108 the creation of explicit paths using adjacency-SIDs, node-SIDs, 109 anycast-SIDs, and binding-SIDs. A node-SID in the segment list 110 defining an SR-TE path indicates a loose hop that the SR-TE path 111 should pass through. When the node fails, the network may no longer 112 be able to properly forward traffic on that SR-TE path. 114 [I-D.ietf-rtgwg-segment-routing-ti-lfa] describes an SR FRR mechanism 115 that provides fast re-route protection for the failure of a node on a 116 SR-TE path by the direct neighbor or say point of local repair (PLR) 117 to the failure. However, once the IGP converges, the SR FRR is no 118 longer sufficient to forward traffic of the path around the failure, 119 since the non-neighbors of the failure will no longer have a route to 120 the failed node and drop the traffic. 122 To solve this problem, 123 [I-D.ietf-spring-segment-protection-sr-te-paths] proposes that a hold 124 timer should be configured on every router in a network. After the 125 IGP converges on the event of a node failure, if the node-SID of the 126 failed node becomes unreachable, the forwarding changes should not be 127 communicated to the forwarding planes on all configured routers 128 (including PLRs for the failed node) until the hold timer expires. 129 This solution may not work for some cases such as some of nodes in 130 the network not supporting this solution. 132 This document describes a proxy forwarding mechanism for the 133 restoration of the routes to the failure of a SR-TE path after the 134 IGP converges. It provides the restoration of the routes to an 135 adjacency segment, a node segment and a binding segment on a failed 136 node along the SR-TE path. With the restoration of the routes to the 137 failure, the traffic for the SR-TE path is continuously sent to the 138 neighbor of the failure after the IGP converges. The neighbor as a 139 PLR fast re-routes the traffic around the failure. 141 2. Proxy Forwarding 143 In the proxy forwarding mechanism, each neighbor of a possible failed 144 node advertises its SR proxy forwarding capability in its network 145 domain when it has the capability. This capability indicates that 146 the neighbor (the Proxy Forwarder) will forward traffic on behalf of 147 the failed node. A router receiving the SR Proxy Forwarding 148 capability from the neighbors of a failed node will send traffic 149 using the node-SID of the failed node to the nearest Proxy Forwarder 150 after the IGP converges on the event of the failure. 152 Once the affected traffic reaches a Proxy Forwarder, it sends the 153 traffic on the post-failure shortest path to the node immediately 154 following the failed node in the segment list. 156 For a binding segment of a possible failed node, the node advertises 157 the information about the binding segment, including the binding SID 158 and the list of SIDs associated with the binding SID, to its direct 159 neighbors only. Note that the information is not advertised in the 160 network domain. 162 After the node fails and the IGP converges on the failure, the 163 traffic with the binding SID of the failed node will reach its 164 neighbor having SR Proxy Forwarding capability. Once receiving the 165 traffic, the neighbor swaps the binding SID with the list of SIDs 166 associated with the binding SID and sends the traffic along the post- 167 failure shortest path to the first node in the segment list. 169 3. Extensions to IGP for Proxy Forwarding 171 This section defines extensions to IGP for advertising the SR proxy 172 forwarding capability of a node in a network domain and the 173 information about each binding segment (including its binding SID and 174 the list of SIDs associated) of a node to its direct neighbors. 176 3.1. Extensions to OSPF 178 3.1.1. Advertising Proxy Forwarding 180 When a node P has the capability to do a SR proxy forwarding for all 181 its neighboring nodes for protecting the failures of these nodes, 182 node P advertises its SR proxy forwarding capability in its router 183 information opaque LSA, which contains a Router Functional 184 Capabilities TLV of the format as shown in Figure 1. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Functional Capabilities | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1: Router Functional Capabilities TLV 196 One bit (called PF bit) in the Functional Capabilities field of the 197 TLV is used to indicate node P's SR proxy forwarding capability. 198 When this bit is set to one by node P, it indicates that node P is 199 capable of doing a SR proxy forwarding for its neighboring nodes. 201 For a node X in the network, it learns the prefix/node SID of node N, 202 which is originated and advertised by node N. It creates a proxy 203 prefix/node SID of node N for node P if node P is capable of doing SR 204 proxy forwarding for node N. The proxy prefix/node SID of node N for 205 node P is a copy of the prefix/node SID of node N originated by node 206 N, but stored under (or say, associated with) node P. The route to 207 the proxy prefix/node SID is through proxy forwarding capable nodes. 209 In normal operations, node X prefers to use the prefix/node SID of 210 node N. When node N fails, node X prefers to use the proxy prefix/ 211 node SID of node N. Thus node X will forward the traffic targeting 212 to the prefix/node SID of node N to node P when node N fails, and 213 node P will do a SR proxy forwarding for node N and forward the 214 traffic towards its final destination without going through node N. 215 After node N fails, node X will keep the FIB entry to the proxy 216 prefix/node SID of node N for a given period of time. 218 Note that the behaviors of normal IP forwarding and routing 219 convergences in a network are not changed at all by the SR proxy 220 forwarding. For example, the next hop used by BGP is an IP address 221 (or prefix). The IGP and BGP converge in normal ways for changes in 222 the network. The packet with its IP destination to this next hop is 223 forwarded according to the IP forwarding table (FIB) derived from IGP 224 and BGP routes. 226 If node P can not do a SR proxy forwarding for all its neighboring 227 nodes, but for some of them, then it advertises the node SID of each 228 of the nodes as a proxy node SID, indicating that it is able to do 229 proxy forwarding for the node SID. 231 A new TLV, called Proxy Node SIDs TLV, is defined for node P to 232 advertise the node SIDs of some of its neighboring nodes. It has the 233 format as shown in Figure 2. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type (TBD1) | Length | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Node SID Sub-TLVs | 241 : : 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2: OSPF Proxy Node SIDs TLV 246 The Type (TBD1) is to be assigned by IANA. The TLV contains a number 247 of Node SID Sub-TLVs. The Length is the total size of the Node SID 248 Sub-TLVs included in the TLV. A Node SID Sub-TLV is the Prefix SID 249 Sub-TLV defined in [RFC8665]. 251 A proxy forwarding node P originates an Extended Prefix Opaque LSA 252 containing this new TLV. The TLV includes the Node SID Sub-TLVs for 253 the node SIDs of some of P's neighboring nodes. For each of some of 254 P's neighboring nodes, the Node SID Sub-TLV for its prefix/node SID 255 is included the TLV. This prefix/node SID is called a proxy prefix/ 256 node SID. 258 A proxy forwarding node will originate an Extended Prefix Opaque LSA, 259 which includes a Proxy Node SIDs TLV. The format of the LSA is shown 260 in Figure 3. 262 For a proxy forwarding node P, having a number of neighboring nodes, 263 P originates and maintains an Extended Prefix Opaque LSA, which 264 includes a Proxy Node SIDs TLV. The TLV contains the Prefix/Node SID 265 Sub-TLV for each of some of the neighboring nodes after node P 266 creates the corresponding proxy forwarding entries for protecting the 267 failure of some of the neighboring nodes. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | LS age | Options | LS Type | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Opaque Type(7)| Opaque ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Advertising Router | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | LS sequence number | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | LS checksum | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 : TLVs : 284 : (including Proxy Node SIDs TLV) : 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 3: OSPFv2 Extended Prefix Opaque LSA 290 When an neighboring node fails, P maintains the LSA with the TLV 291 containing the Prefix/Node SID Sub-TLV for the neighboring node for a 292 given period of time. After the given period of time, the Prefix/ 293 Node SID Sub-TLV for the neighboring node is removed from the TLV in 294 the LSA and then after a given time the corresponding proxy 295 forwarding entries for protecting the failure of the neighboring node 296 is removed. 298 For a node X in the network, it learns the prefix/node SID of node N 299 and the proxy prefix/node SID of node N. The former is originated 300 and advertised by node N, and the latter is originated and advertised 301 by the proxy forwarding node P of node N. Note that the proxy 302 Prefix/Node SID Sub-TLV for node N does not contain a prefix of node 303 N, and the prefix is the prefix associated with the prefix/node SID 304 of node N originated by node N. 306 In normal operations, node X prefers to use the prefix/node SID of 307 node N. When node N fails, node X prefers to use the proxy prefix/ 308 node SID of node N. Thus node X will forward the traffic targeting 309 to node N to node P when node N fails, and node P will do a proxy 310 forwarding for node N and forward the traffic towards its destination 311 without going through node N. 313 3.1.2. Advertising Binding Segment 315 For a binding segment (or binding for short) on a node A, which 316 consists of a binding SID and a list of segments, node A advertises 317 an LSA containing the binding (i.e., the binding SID and the list of 318 the segments). The LSA is advertised only to each of the node A's 319 neighboring nodes. For OSPFv2, the LSA is a opaque LSA of LS type 9 320 (i.e., a link local scope LSA). 322 A binding segment is represented by binding segment TLV of the format 323 as shown in Figure 4. 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type (TBD2) | Length | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Reserved |BindingSID Type| SIDs Type | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 ~ Binding SID Sub-TLV/value ~ 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 ~ SID Sub-TLVs/values ~ 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 4: OSPF Binding Segment TLV 339 It comprises a binding SID and a list of segments (SIDs). The fields 340 of this TLV are defined as follows: 342 Type: 2 octets, its value (TBD2) is to be assigned by IANA. 344 Length: 2 octets, its value is (4 + length of Sub-TLVs/values). 346 Binding SID Type (BT): 1 octet indicates whether the binding SID is 347 represented by a Sub-TLV or a value included in the TLV. For the 348 binding SID represented by a value, it indicates the type of binding 349 SID. The following BT values are defined: 351 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., Binding 352 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 353 TLV defined in [RFC8665]. BT != 0 indicates that the binding SID is 354 represented by a value. 356 o BT = 1: The binding SID value is a label, which is represented by 357 the 20 rightmost bits. The length of the value is 3 octets. 359 o BT = 2: The binding SID value is a 32-bit SID. The length of the 360 value is 4 octets. 362 SIDs Type (ST): 1 octet indicates whether the list of segments (SIDs) 363 are represented by Sub-TLVs or values included in the TLV. For the 364 SIDs represented by values, it indicates the type of SIDs. The 365 following ST values are defined: 367 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 368 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 369 TLV or a SID/Label Sub-TLV defined in [RFC8665]. ST != 0 indicates 370 that the SIDs are represented by values. 372 o ST = 1: Each of the SID values is a label, which is represented by 373 the 20 rightmost bits. The length of the value is 3 octets. 375 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 376 value is 4 octets. 378 The opaque LSA of LS Type 9 containing the binding segment (i.e., the 379 binding SID and the list of the segments) has the format as shown in 380 Figure 5. It may have Opaque Type of x (the exact type is to be 381 assigned by IANA) for Binding Segment Opaque LSA. 383 0 1 2 3 384 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | LS age | Options | LS Type (9) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Opaque Type(x)| Opaque ID | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Advertising Router | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | LS sequence number | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | LS checksum | Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | | 397 : Binding Segment TLVs : 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Figure 5: OSPFv2 Binding Segment Opaque LSA 403 For every binding on a node A, the LSA originated by A contains a 404 binding segment TLV for it. 406 For node A running OSPFv3, it originates a link-local scoping LSA of 407 a new LSA function code (TBD3) containing binding segment TLVs for 408 the bindings on it. The format of the LSA is illustrated in 409 Figure 6. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | LS age |0|0|0| BS-LSA (TBD3) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Link State ID | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Advertising Router | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | LS Sequence Number | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | LS checksum | Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | | 425 : Binding Segment TLVs : 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 6: OSPFv3 Binding Segment Opaque LSA 431 The U-bit is set to 0, and the scope is set to 00 for link-local 432 scoping. 434 3.2. Extensions to IS-IS 436 3.2.1. Advertising Proxy Forwarding 438 When a node P has the capability to do a SR proxy forwarding for its 439 neighboring nodes for protecting the failures of them, node P 440 advertises its SR proxy forwarding capability in its LSP, which 441 contains a Router Capability TLV of Type 242 including a SR 442 capabilities sub-TLV of sub-Type 2. 444 One bit (called PF bit as shown in Figure 7) in the Flags field of 445 the SR capabilities sub-TLV is defined to indicate node P's SR proxy 446 forwarding capability. When this bit is set to one by node P, it 447 indicates that node P is capable of doing a SR proxy forwarding for 448 its neighboring nodes. 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type (2) | Length | Flags | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Range | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 // SID/Label Sub-TLV (variable) // 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 0 1 2 3 4 5 6 7 461 +--+--+--+--+--+--+--+--+ 462 | I| V|PF| | 463 +--+--+--+--+--+--+--+--+ 464 Flags 466 Figure 7: SR Capabilities sub-TLV 468 If node P can not do a SR proxy forwarding for all its neighboring 469 nodes, but for some of them, then it advertises the node SID of each 470 of the nodes as a proxy node SID, indicating that it is able to do 471 proxy forwarding for the node SID. 473 The IS-IS SID/Label Binding TLV (suggested value 149) is defined in 474 [RFC8667]. A Proxy Forwarder uses the SID/Label Binding TLV to 475 advertise the node SID of its neighboring node. The Flags field of 476 the SID/Label Binding TLV is extended to include a P flag as shown in 477 Figure 8. The prefix/node SID in prefix/node SID Sub-TLV included in 478 SID/Label Binding TLV is identified as a proxy forwarding prefix/node 479 SID. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type | Length | Flags | RESERVED | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Range | Prefix Length | Prefix | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 // Prefix (continued, variable) // 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | SubTLVs (variable) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 0 1 2 3 4 5 6 7 494 +-+-+-+-+-+-+-+-+ 495 |F|M|S|D|A|P| | 496 +-+-+-+-+-+-+-+-+ 497 Flags 499 Figure 8: SID/Label Binding TLV 501 Where: 503 P-Flag: Proxy forwarding flag. If set, this prefix/node SID is 504 advertised by the proxy node. This TLV is used to announce that the 505 node has the ability to proxy forward the prefix/node SID. 507 When the P-flag is set in the SID/Label Binding TLV, the following 508 usage rules apply. 510 The Range, Prefix Length and Prefix field are not used. They should 511 be set to zero on transmission and ignored on receipt. 513 SID/Label Binding TLV contains a number of prefix/node SID Sub-TLVs. 514 The TLV advertised by a proxy forwarding node P contains prefix/node 515 SID Sub-TLVs for the node SIDs of P's neighbor nodes. Each of the 516 Sub-TLVs is a prefix/node SID Sub-TLV defined in [RFC8667]. From the 517 SID in a prefix/node SID Sub-TLV advertised by the Proxy Forwarding 518 node, its prefix can be obtained through matching corresponding 519 prefix/node SID advertised by the neighbor/protected node using 520 TLV-135 (or 235, 236, or 237) together with the prefix/node SID Sub- 521 TLV. 523 3.2.2. Advertising Binding Segment 525 [I-D.ietf-spring-segment-routing-policy] has defined the usage of 526 binding-SID. For supporting binding SID proxy forwarding, a new IS- 527 IS TLV, called Binding Segment TLV, is defined. It contains a 528 binding SID and a list of segments (SIDs). This TLV may be 529 advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link 530 State PDUs (CS-LSP) [RFC7356]. Its format is shown in Figure 9. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type | Length |BindingSID Type| SIDs Type | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 ~ Binding SID value/Sub-TLV ~ 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 ~ SID values/Sub-TLVs ~ 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Figure 9: IS-IS Binding Segment TLV 544 The fields of this TLV are defined as follows: 546 Type: 1 octet Suggested value 152 (to be assigned by IANA) 548 Length: 1 octet (2 + length of Sub-TLVs/values). 550 Binding SID Type (BT): 1 octet indicates whether the binding SID is 551 represented by a Sub-TLV or a value included in the TLV. For the 552 binding SID represented by a value, it indicates the type of binding 553 SID. The following BT values are defined: 555 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., binding 556 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 557 TLV defined in [RFC8667]. BT != 0 indicates that the binding SID is 558 represented by a value. 560 o BT = 1: The binding SID value is a label, which is represented by 561 the 20 rightmost bits. The length of the value is 3 octets. 563 o BT = 2: The binding SID value is a 32-bit SID. The length of the 564 value is 4 octets. 566 SIDs Type (ST): 1 octet indicates whether the SIDs are represented by 567 Sub-TLVs or values included in the TLV. For the SIDs represented by 568 values, it indicates the type of SIDs. The following ST values are 569 defined: 571 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 572 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 573 TLV or a SID/Label Sub-TLV defined in [RFC8667]. ST != 0 indicates 574 that the SIDs are represented by values. 576 o ST = 1: Each of the SID values is a label, which is represented by 577 the 20 rightmost bits. The length of the value is 3 octets. 579 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 580 value is 4 octets. 582 4. Building Proxy Forwarding Table 584 Figure 10 is used to illustrate the SR proxy forwarding approach. 585 Each node N has SRGB = [N000-N999]. RT1 is an ingress node of SR 586 domain. RT3 is a failure node. RT2 is a Point of Local Repair (PLR) 587 node, i.e., a proxy forwarding node. Three label stacks are shown in 588 the figure. Label Stack 1 uses only adjacency-SIDs and represents 589 the path RT1->RT2->RT3->RT4->RT5. Label Stack 2 uses only node-SIDs 590 and represents the ECMP-aware path RT1->RT3->RT4->RT5. Label Stack 3 591 uses a node-SID and a binding SID. The Binding-SID with label=100 at 592 RT3 represents the ECMP-aware path RT3->RT4->RT5. So Label Stack 3, 593 which consists of the node-SID for RT3 following by Binding-SID=100, 594 represents the ECMP-aware path RT1->RT3->RT4->RT5. 596 Node SID:2 Node SID:3 597 +-----+ +-----+ 598 | |----------+ | 599 / |RT2 | | RT3 |\ 600 / +-----+ +-----+ \ 601 / | \ /| \ 602 / | \ / | \ 603 / | \ / | \ 604 / | \ / | \ 605 / | \ / | \ 606 Node SID:1 | \ / | \Node SID:4 Node SID:5 607 +-----+ | \ / | +-----+ +-----+ 608 | | | X | | |-------| | 609 | RT1 | | / \ | | RT4 | | RT5 | 610 +-----+ | / \ | +-----+ +-----+ 611 \ | / \ | / 612 \ | / \ | / 613 \ | / \ | / 614 \ | / \ | / 615 \ | / \| / 616 \ |/ | / 617 \ +-----+ +-----+ / 618 \ | | | |/ 619 \ | RT6 |-----------| RT7 | 620 +-----+ +-----+ 621 Node SID:6 Node SID:7 623 +-----------------+ +--------------+ 624 | Node SRGB | | Adj-SID | +-------+ +-------+ +-------+ 625 +-----------------+ +--------------+ |Label | |Label | |Label | 626 | RT1:[1000-1999] | |RT1->RT2:10012| |Stack 1| |Stack 2| |Stack 3| 627 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 628 | RT2:[2000-2999] | |RT2->RT3:20023| | 10012 | | 1003 | | 1003 | 629 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 630 | RT3:[3000-3999] | |RT3->RT6:30036| | 20023 | | 3004 | | 100 | 631 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 632 | RT4:[4000=4999] | |RT3->RT7:30037| | 30034 | | 4005 | 100 is 633 +-----------------+ +--------------+ +-------+ +-------+ binding SID 634 | RT5:[5000-5999] | |RT3->RT4:30034| | 40045 | to 635 +-----------------+ +--------------+ +-------+ {30034,40045} 636 | RT6:[6000-6999] | |RT7->RT4:70074| 637 +-----------------+ +--------------+ 638 | RT7:[7000-7999] | |RT4->RT5:40045| 639 +-----------------+ +--------------+ 641 Figure 10: Topology of SR-TE Path 643 4.1. Advertising Proxy Forwarding 645 If the Point of Local Repair (PLR), for example, RT2, has the 646 capability to do a SR proxy forwarding for all its neighboring nodes, 647 it must advertise this capability. If the PLR can not do a SR proxy 648 forwarding for all its neighboring nodes, but for some of them, for 649 example, RT3, then it uses proxy Node SIDs TLV to advertise the 650 prefix-SID learned from RT3. The TLV contains the Sub-TLV/value for 651 the prefix/node SID of RT3 as a proxy SID. When RT3 fails, RT2 needs 652 to maintain the Sub-TLV/value for a period of time. When the proxy 653 forwarding table corresponding to the fault node is deleted (see 654 section 3.2), the Sub-TLV/value is withdrawn. The nodes in the 655 network (for example, RT1) learn the prefix/node SID TLV advertised 656 by RT3 and the proxy Node SIDs TLV advertised by RT2. When RT3 is 657 normal, the nodes prefer prefix/node SID TLV. When the RT3 fails, 658 the proxy prefix/node SIDs TLV advertised by RT2 is preferred. 660 4.2. Building Proxy Forwarding Table 662 A SR proxy node P needs to build an independent proxy forwarding 663 table for each neighbor N. The proxy forwarding table for node N 664 contains the following information: 666 1: Node N's SRGB range and the difference between the SRGB start 667 value of node P and that of node N; 669 2: All adjacency-SID of N and Node-SID of the node pointed to by node 670 N's adjacency-SID. 672 3: The binding-SID of N and the label stack associated with the 673 binding-SID. 675 Node P (PLR) uses a proxy forwarding table based on the next segment 676 to find a node N as a backup forwarding entry to the adj-SID and 677 Node-SID of node N. When node N fails, the proxy forwarding table 678 needs to be maintained for a period of time, which is recommended for 679 30 minutes. 681 Node RT3 in the topology of Figure 1 is node N, and node RT2 is node 682 P (PLR). RT2 builds the proxy forwarding table for RT3. RT2 683 calculates the proxy forwarding table for RT3, as shown in Figure 11. 685 +==========+===============+============+=============+==============+ 686 | In-label | SRGBDiffValue | Next Label | Action | Map Label | 687 +==========+===============+============+=============+==============+ 688 | 2003 | -1000 | 30034 | Fwd to RT4 | 2004 | 689 +----------+---------------+------------+-------------+--------------+ 690 | 30036 | Fwd to RT6 | 2006 | 691 +------------+-------------+--------------+ 692 | 30037 | Fwd to RT7 | 2007 | 693 +------------+-------------+--------------+ 694 | 100 | Swap to { 30034, 40045 } | 695 +------------+-------------+--------------+ 697 Figure 11: RT2's Proxy Forwarding Table for RT3 699 5. Use of Proxy Forwarding 701 Segment Routing Traffic Engineering supports the creation of explicit 702 paths using adjacency-SIDs, node-SIDs, and binding-SIDs. The label 703 stack is a combination of one or more of adjacency-SIDs, node-SIDs, 704 and binding-SIDs. This Section shows through example how a proxy 705 node uses the SR proxy forwarding mechanism to forward traffic to the 706 destination node when a node fails and the next segment of label 707 stack is adjacency-SIDs, node-SIDs, or binding-SIDs, respectively. 709 5.1. Next Segment is an Adjacency Segment 711 As shown in Figure 1, Label Stack 1 {10012, 20023, 30034, 40045} 712 represents SR-TE strict explicit path RT1->RT2->RT3->RT4->RT5. When 713 RT3 fails, node RT2 acts as a PLR, and uses next adj-SID (30034) of 714 the label stack to lookup the proxy forwarding table built by RT2 715 locally for RT3. The path returned is the label forwarding path to 716 RT3's next hop node RT4, which bypasses RT3. The specific steps are 717 as follows: 719 a. RT1 pops top adj-SID 10012, and forwards the packet to RT2; 721 b. RT2 uses the label 20023 to identify the next hop node RT3, which 722 has failed. RT2 pops label 20023 and queries the Proxy Forwarding 723 Table corresponding to RT3 with label 30034. The query result is 724 2004. RT2 uses 2004 as the incoming label to query the label 725 forwarding table. The next hop is RT7, and the incoming label is 726 changed to 7004. 728 c. So the packet leaves RT2 out the interface to RT7 with label 729 stack {7004, 40045}. RT4 forwards it to RT4, where the original path 730 is rejoined. 732 d. RT2 forwards packets to RT7. RT7 queries the local routing table 733 to forward the packet to RT4. 735 5.2. Next Segment is a Node Segment 737 As shown in Figure 1, Label Stack 2 {1003, 3004, 4005} represents SR- 738 TE loose path RT1->RT3->RT4->RT5, where 1003 is the node SID of RT3. 740 When the node RT3 fails, the proxy forwarding TLV advertised by the 741 RT2 is preferred to direct the traffic of the RT1 to the PLR node 742 RT2. Node RT2 acts as a PLR node and queries the proxy forwarding 743 table locally built for RT3. The path returned is the label 744 forwarding path to RT3's next hop node RT4, which bypasses RT3. The 745 specific steps are as follows: 747 a. RT1 swaps label 1003 to out-label 2003 to RT3. 749 b. RT2 receives the label forwarding packet whose top label of label 750 stack is 2003, and searches for the local Routing Table, the behavior 751 found is to lookup Proxy Forwarding table due to RT3 failure, RT2 752 pops label 2003. 754 c. RT2 uses 3004 as the in-label to lookup Proxy Forwarding table, 755 The value of Map Label calculated based on SRGBDiffValue is 2004. 756 and the query result is forwarding the packet to RT4. 758 d. Then RT2 queries the Routing Table to RT4, using the primary or 759 backup path to RT4. The next hop is RT7. 761 e. RT2 forwards the packet to RT7. RT7 queries the local routing 762 table to forward the packet to RT4. 764 f. After RT1 convergences, node SID 1003 is preferred to the proxy 765 SID implied/advertised by RT2. 767 5.3. Next Segment is a Binding Segment 769 As shown in Figure 1, Label Stack 3 {1003, 100} represents SR-TE 770 loose path RT1->RT3->RT4->RT5, where 100 is a Binding-SID, which 771 represents segment list {30034, 40045}. 773 When the node RT3 fails, the proxy forwarding SID implied or 774 advertised by the RT2 is preferred to forward the traffic of the RT1 775 to the PLR node RT2. Node RT2 acts as a PLR node and uses Binding- 776 SID to query the proxy forwarding table locally built for RT3. The 777 path returned is the label forwarding path to RT3's next hop node 778 (RT4), which bypasses RT3. The specific steps are as follows: 780 a. RT1 swaps label 1003 to out-label 2003 to RT3. 782 b. RT2 receives the label forwarding packet whose top label of label 783 stack is 2003, and searches for the local Routing Table, the behavior 784 found is to lookup Proxy Forwarding table due to RT3 failure. 786 c. RT2 uses Binding-SID:100 (label 2003 has pop) as the in-label to 787 lookup the Next Label record of the Proxy Forwarding Table, the 788 behavior found is to swap to Segment list {30034, 40045}. 790 d. RT2 swaps Binding-SID:100 to Segment list {30034, 40045}, and 791 uses the 3034 to lookup the Next Label record of the Proxy Forwarding 792 table again. The behavior found is to forward the packet to RT4. 794 e. RT2 queries the Routing Table to RT4, using primary or backup 795 path to RT4. The next hop is RT7. 797 f. RT2 forwards packets to RT7. RT7 queries the local routing table 798 to forward the packet to RT4. 800 6. Security Considerations 802 The extensions to OSPF and IS-IS described in this document result in 803 two types of behaviors in data plane when a node in a network fails. 804 One is that for a node, which is a upstream (except for the direct 805 upstream) node of the failed node along a SR-TE path, it continues to 806 send the traffic to the failed node along the SR-TE path for an 807 extended period of time. The other is that for a node, which is the 808 direct upstream node of the failed node, it fast re-routes the 809 traffic around the failed node to the direct downstream node of the 810 failed node along the SR-TE path. These behaviors are internal to a 811 network and should not cause extra security issues. 813 7. IANA Considerations 815 7.1. OSPFv2 817 Under Subregistry Name "OSPF Router Functional Capability Bits" 818 within the "Open Shortest Path First v2 (OSPFv2) Parameters" 819 [RFC7770], IANA is requested to assign one bit for Proxy Forwarding 820 Capability as follows: 822 +============+==================+===================+ 823 | Bit number | Capability Name | Reference | 824 +============+==================+===================+ 825 | 31 | Proxy Forwarding | This document | 826 +------------+------------------+-------------------+ 828 Under Registry Name "OSPFv2 Extended Prefix Opaque LSA TLVs" 829 [RFC7684], IANA is requested to assign one new TLV value for OSPF 830 Proxy Node SIDs as follows: 832 +============+=====================+================+ 833 | TLV Value | TLV Name | Reference | 834 +============+=====================+================+ 835 | 2 | Proxy Node SIDs TLV | This document | 836 +------------+---------------------+----------------+ 838 Under Registry Name "Opaque Link-State Advertisements (LSA) Option 839 Types" [RFC5250], IANA is requested to assign new Opaque Type 840 registry values for Binding Segment LSA as follows: 842 +================+==================+================+ 843 | Registry Value | Opaque Type | Reference | 844 +================+==================+================+ 845 | 10 | Binding Segment | This document | 846 +----------------+------------------+----------------+ 848 IANA is requested to create and maintain new registries: 850 o OSPFv2 Binding Segment Opaque LSA TLVs 852 Initial values for the registry are given below. The future 853 assignments are to be made through IETF Review [RFC5226]. 855 Value TLV Name Definition 856 ----- ----------------------- ---------- 857 0 Reserved 858 1 Binding Segment TLV This Document 859 2-32767 Unassigned 860 32768-65535 Reserved 862 7.2. OSPFv3 864 Under Registry Name "OSPFv3 LSA Function Codes", IANA is requested to 865 assign new registry values for Binding Segment LSA as follows: 867 +========+========================+================+ 868 | Value | LSA Function Code Name | Reference | 869 +========+========================+================+ 870 | 16 | Binding Segment LSA | This document | 871 +--------+------------------------+----------------+ 873 IANA is requested to create and maintain new registries: 875 o OSPFv3 Binding Segment LSA TLVs 877 Initial values for the registry are given below. The future 878 assignments are to be made through IETF Review [RFC5226]. 880 Value TLV Name Definition 881 ----- ----------------------- ---------- 882 0 Reserved 883 1 Binding Segment TLV This Document 884 2-32767 Unassigned 885 32768-65535 Reserved 887 7.3. IS-IS 889 Under Registration "Segment Routing Capability" in the "sub-TLVs for 890 TLV 242" registry [RFC8667], IANA is requested to assign one bit flag 891 for Proxy Forwarding Capability as follows: 893 +============+=======================+===============+ 894 | Bit number | Capability Name | Reference | 895 +============+=======================+===============+ 896 | 2 | Proxy Forwarding (PF) | This document | 897 +------------+-----------------------+---------------+ 899 Under Registration "Segment Identifier/Label Binding TLV 149" 900 [RFC8667], IANA is requested to assign one bit P-Flag as follows: 902 +============+=================+===============+ 903 | Bit number | Flag Name | Reference | 904 +============+=================+===============+ 905 | 5 | P-Flag | This document | 906 +------------+-----------------+---------------+ 908 Under Registry Name: IS-IS TLV Codepoints, IANA is requested to 909 assign one new TLV value for IS-IS Binding Segment as follows: 911 +========+======================+===============+ 912 | Value | TLV Name | Reference | 913 +========+======================+===============+ 914 | 152 | Binding Segment TLV | This Document | 915 +--------+----------------------+---------------+ 917 8. Acknowledgements 919 The authors would like to thank Peter Psenak, Acee Lindem, Les 920 Ginsberg, Bruno Decraene and Jeff Tantsura for their comments to this 921 work. 923 9. References 925 9.1. Normative References 927 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 928 Requirement Levels", BCP 14, RFC 2119, 929 DOI 10.17487/RFC2119, March 1997, 930 . 932 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 933 IANA Considerations Section in RFCs", RFC 5226, 934 DOI 10.17487/RFC5226, May 2008, 935 . 937 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 938 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 939 July 2008, . 941 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 942 Scope Link State PDUs (LSPs)", RFC 7356, 943 DOI 10.17487/RFC7356, September 2014, 944 . 946 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 947 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 948 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 949 2015, . 951 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 952 S. Shaffer, "Extensions to OSPF for Advertising Optional 953 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 954 February 2016, . 956 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 957 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 958 Extensions for Segment Routing", RFC 8665, 959 DOI 10.17487/RFC8665, December 2019, 960 . 962 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 963 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 964 Extensions for Segment Routing", RFC 8667, 965 DOI 10.17487/RFC8667, December 2019, 966 . 968 9.2. Informative References 970 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 971 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 972 Decraene, B., and D. Voyer, "Topology Independent Fast 973 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 974 routing-ti-lfa-06 (work in progress), February 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", draft-ietf-spring- 979 segment-protection-sr-te-paths-00 (work in progress), 980 September 2020. 982 [I-D.ietf-spring-segment-routing-policy] 983 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 984 P. Mattes, "Segment Routing Policy Architecture", draft- 985 ietf-spring-segment-routing-policy-09 (work in progress), 986 November 2020. 988 [I-D.sivabalan-pce-binding-label-sid] 989 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 990 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 991 in PCE-based Networks.", draft-sivabalan-pce-binding- 992 label-sid-07 (work in progress), July 2019. 994 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 995 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 996 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 997 2009, . 999 Authors' Addresses 1001 Zhibo Hu 1002 Huawei Technologies 1003 Huawei Bld., No.156 Beiqing Rd. 1004 Beijing 100095 1005 China 1007 Email: huzhibo@huawei.com 1009 Huaimo Chen 1010 Futurewei 1011 Boston, MA 1012 USA 1014 Email: Huaimo.chen@futurewei.com 1015 Junda Yao 1016 Huawei Technologies 1017 Huawei Bld., No.156 Beiqing Rd. 1018 Beijing 100095 1019 China 1021 Email: yaojunda@huawei.com 1023 Chris Bowers 1024 Juniper Networks 1025 1194 N. Mathilda Ave. 1026 Sunnyvale, CA 94089 1027 USA 1029 Email: cbowers@juniper.net 1031 Yongqing 1032 China Telecom 1033 109, West Zhongshan Road, Tianhe District 1034 Guangzhou 510000 1035 China 1037 Email: zhuyq8@chinatelecom.cn 1039 Yisong 1040 China Mobile 1041 510000 1042 China 1044 Email: liuyisong@chinamobile.com