idnits 2.17.1 draft-hu-spring-segment-routing-proxy-forwarding-12.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 (October 23, 2020) is 1275 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 577, but not defined == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 969, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 975, 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-04 == 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-08 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: April 26, 2021 Futurewei 6 J. Yao 7 Huawei Technologies 8 C. Bowers 9 Juniper Networks 10 Y. Zhu 11 China Telecom 12 October 23, 2020 14 SR-TE Path Midpoint Protection 15 draft-hu-spring-segment-routing-proxy-forwarding-12 17 Abstract 19 Segment Routing Traffic Engineering (SR-TE) supports explicit paths 20 using segment lists containing adjacency-SIDs, node-SIDs and binding- 21 SIDs. The current SR FRR such as TI-LFA provides fast re-route 22 protection for the failure of a node along a SR-TE path by the direct 23 neighbor or say point of local repair (PLR) to the failure. However, 24 once the IGP converges, the SR FRR is no longer sufficient to forward 25 traffic of the path around the failure, since the non-neighbors of 26 the failure will no longer have a route to the failed node. This 27 document describes a mechanism for fast re-route protection against 28 the failure of a SR-TE path after the IGP converges. It provides 29 fast re-route protection for an adjacency segment, a node segment and 30 a binding segment of the path. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 26, 2021. 55 Copyright Notice 57 Copyright (c) 2020 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Proxy Forwarding . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Extensions to IGP for Proxy Forwarding . . . . . . . . . . . 4 75 3.1. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 4 76 3.1.1. Advertising Proxy Forwarding . . . . . . . . . . . . 4 77 3.1.2. Advertising Binding Segment . . . . . . . . . . . . . 7 78 3.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 10 79 3.2.1. Advertising Proxy Forwarding . . . . . . . . . . . . 10 80 3.2.2. Advertising Binding Segment . . . . . . . . . . . . . 12 81 4. Building Proxy Forwarding Table . . . . . . . . . . . . . . . 13 82 4.1. Advertising Proxy Forwarding . . . . . . . . . . . . . . 15 83 4.2. Building Proxy Forwarding Table . . . . . . . . . . . . . 15 84 5. Node Protection for Segment List . . . . . . . . . . . . . . 15 85 5.1. Next Segment is an Adjacency Segment . . . . . . . . . . 16 86 5.2. Next Segment is a Node Segment . . . . . . . . . . . . . 16 87 5.3. Next Segment is a Binding Segment . . . . . . . . . . . . 17 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 7.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 7.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 7.3. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 96 9.2. Informative References . . . . . . . . . . . . . . . . . 21 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 99 1. Introduction 101 Segment Routing Traffic Engineering (SR-TE) is a technology that 102 implements traffic engineering using a segment list. SR-TE supports 103 the creation of explicit paths using adjacency-SIDs, node-SIDs, 104 anycast-SIDs, and binding-SIDs. A node-SID in the segment list 105 defining an SR-TE path indicates a loose hop that the SR-TE path 106 should pass through. When the node fails, the network may no longer 107 be able to properly forward traffic on that SR-TE path. 109 [I-D.ietf-rtgwg-segment-routing-ti-lfa] describes an SR FRR mechanism 110 that provides fast re-route protection for the failure of a node on a 111 SR-TE path by the direct neighbor or say point of local repair (PLR) 112 to the failure. However, once the IGP converges, the SR FRR is no 113 longer sufficient to forward traffic of the path around the failure, 114 since the non-neighbors of the failure will no longer have a route to 115 the failed node and drop the traffic. 117 To solve this problem, 118 [I-D.ietf-spring-segment-protection-sr-te-paths] proposes that a hold 119 timer should be configured on every router in a network. After the 120 IGP converges on the event of a node failure, if the node-SID of the 121 failed node becomes unreachable, the forwarding changes should not be 122 communicated to the forwarding planes on all configured routers 123 (including PLRs for the failed node) until the hold timer expires. 124 This solution may not work for some cases such as some of nodes in 125 the network not supporting this solution. 127 This document describes a proxy protection/forwarding mechanism, 128 which provides more protection coverages. It considers the fast re- 129 route protection capability of every node in the network and supports 130 the fast re-route protection of the binding-SIDs on a failed node. 132 2. Proxy Forwarding 134 In the proxy forwarding mechanism, each neighbor of a possible failed 135 node advertises its SR proxy forwarding capability in its network 136 domain when it has the capability. This capability indicates that 137 the neighbor (the Proxy Forwarder) will forward traffic on behalf of 138 the failed node. A router receiving the SR Proxy Forwarding 139 capability from neighbors of a failed node will send traffic using 140 the node-SID of the failed node to the nearest Proxy Forwarder after 141 the IGP converges on the event of the failure. 143 Once the affected traffic reaches a Proxy Forwarder, it sends the 144 traffic on the post-failure shortest path to the node immediately 145 following the failed node in the segment list. 147 For a binding segment of a possible failed node, the node advertises 148 the information about the binding segment, including the binding SID 149 and the list of SIDs associated with the binding SID, to its direct 150 neighbors only. Note that the information is not advertised in the 151 network domain. 153 After the node fails and the IGP converges on the failure, the 154 traffic with the binding SID of the failed node will reach its 155 neighbor having SR Proxy Forwarding capability. Once receiving the 156 traffic, the neighbor swaps the binding SID with the list of SIDs 157 associated with the binding SID and sends the traffic along the post- 158 failure shortest path to the first node in the segment list. 160 3. Extensions to IGP for Proxy Forwarding 162 This section defines extensions to IGP for advertising the SR proxy 163 forwarding capability of a node in a network domain and the 164 information about each binding segment (including its binding SID and 165 the list of SIDs associated) of a node to its direct neighbors. 167 3.1. Extensions to OSPF 169 3.1.1. Advertising Proxy Forwarding 171 When a node P has the capability to do a SR proxy forwarding for all 172 its neighboring nodes for protecting the failures of these nodes, 173 node P advertises its SR proxy forwarding capability in its router 174 information opaque LSA, which contains a Router Functional 175 Capabilities TLV of the format as shown in Figure 1. 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type | Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Functional Capabilities | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1: Router Functional Capabilities TLV 187 One bit (called PF bit) in the Functional Capabilities field of the 188 TLV is used to indicate node P's SR proxy forwarding capability. 189 When this bit is set to one by node P, it indicates that node P is 190 capable of doing a SR proxy forwarding for its neighboring nodes. 192 For a node X in the network, it learns the prefix/node SID of node N, 193 which is originated and advertised by node N. It creates a proxy 194 prefix/node SID of node N for node P if node P is capable of doing SR 195 proxy forwarding for node N. The proxy prefix/node SID of node N for 196 node P is a copy of the prefix/node SID of node N originated by node 197 N, but stored under (or say, associated with) node P. 199 In normal operations, node X prefers to use the prefix/node SID of 200 node N. When node N fails, node X prefers to use the proxy prefix/ 201 node SID of node N. Thus node X will forward the traffic targeting 202 to the prefix/node SID of node N to node P when node N fails, and 203 node P will do a SR proxy forwarding for node N and forwarding the 204 traffic to its final destination without going through node N. After 205 node N fails, node X will keep the FIB entry to the proxy prefix/node 206 SID of node N for a given period of time. 208 Note that the behaviors of normal IP forwarding and routing 209 convergences in a network are not changed at all by the SR proxy 210 forwarding. For example, the next hop used by BGP is an IP address 211 (or prefix). The IGP and BGP converge in normal ways for changes in 212 the network. The packet with its IP destination to this next hop is 213 forwarded according to the IP forwarding table (FIB) derived from IGP 214 and BGP routes. 216 If node P can not do a SR proxy forwarding for all its neighboring 217 nodes, but for some of them, then it advertises the node SID of each 218 of the nodes as a proxy node SID, indicating that it is able to do 219 proxy forwarding for the node SID. 221 A new TLV, called Proxy Node SIDs TLV, is defined for node P to 222 advertise the node SIDs of some of its neighboring nodes. It has the 223 format as shown in Figure 2. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type (TBD1) | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Node SID Sub-TLVs | 231 : : 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 2: OSPF Proxy Node SIDs TLV 236 The Type (TBD1) is to be assigned by IANA. The TLV contains a number 237 of Node SID Sub-TLVs. The Length is the total size of the Node SID 238 Sub-TLVs included in the TLV. A Node SID Sub-TLV is the Prefix SID 239 Sub-TLV defined in [I-D.ietf-ospf-segment-routing-extensions]. 241 A proxy forwarding node P originates an Extended Prefix Opaque LSA 242 containing this new TLV. The TLV includes the Node SID Sub-TLVs for 243 the node SIDs of some of P's neighboring nodes. For each of some of 244 P's neighboring nodes, the Node SID Sub-TLV for its prefix/node SID 245 is included the TLV. This prefix/node SID is called a proxy prefix/ 246 node SID. 248 A proxy forwarding node will originate an Extended Prefix Opaque LSA, 249 which includes a Proxy Node SIDs TLV. The format of the LSA is shown 250 in Figure 3. 252 For a proxy forwarding node P, having a number of neighboring nodes, 253 P originates and maintains an Extended Prefix Opaque LSA, which 254 includes a Proxy Node SIDs TLV. The TLV contains the Prefix/Node SID 255 Sub-TLV for each of some of the neighboring nodes after node P 256 creates the corresponding proxy forwarding entries for protecting the 257 failure of some of the neighboring nodes. 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | LS age | Options | LS Type | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Opaque Type(7)| Opaque ID | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Advertising Router | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | LS sequence number | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | LS checksum | Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 : TLVs : 274 : (including Proxy Node SIDs TLV) : 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 3: OSPFv2 Extended Prefix Opaque LSA 280 When an neighboring node fails, P maintains the LSA with the TLV 281 containing the Prefix/Node SID Sub-TLV for the neighboring node for a 282 given period of time. After the given period of time, the Prefix/ 283 Node SID Sub-TLV for the neighboring node is removed from the TLV in 284 the LSA and then after a given time the corresponding proxy 285 forwarding entries for protecting the failure of the neighboring node 286 is removed. 288 For a node X in the network, it learns the prefix/node SID of node N 289 and the proxy prefix/node SID of node N. The former is originated 290 and advertised by node N, and the latter is originated and advertised 291 by the proxy forwarding node P of node N. Note that the proxy 292 Prefix/Node SID Sub-TLV for node N does not contain a prefix of node 293 N, and the prefix is the prefix associated with the prefix/node SID 294 of node N originated by node N. 296 In normal operations, node X prefers to use the prefix/node SID of 297 node N. When node N fails, node X prefers to use the proxy prefix/ 298 node SID of node N. Thus node X will forward the traffic targeting 299 to node N to node P when node N fails, and node P will do a proxy 300 forwarding for node N and forwarding the traffic to its destination 301 without going through node N. 303 3.1.2. Advertising Binding Segment 305 For a binding segment (or binding for short) on a node A, which 306 consists of a binding SID and a list of segments, node A advertises 307 an LSA containing the binding (i.e., the binding SID and the list of 308 the segments). The LSA is advertised only to each of the node A's 309 neighboring nodes. For OSPFv2, the LSA is a opaque LSA of LS type 9 310 (i.e., a link local scope LSA). 312 A binding segment is represented by binding segment TLV of the format 313 as shown in Figure 4. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type (TBD2) | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Reserved |BindingSID Type| SIDs Type | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 ~ Binding SID Sub-TLV/value ~ 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 ~ SID Sub-TLVs/values ~ 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 4: OSPF Binding Segment TLV 329 It comprises a binding SID and a list of segments (SIDs). The fields 330 of this TLV are defined as follows: 332 Type: 2 octets, its value (TBD2) is to be assigned by IANA. 334 Length: 2 octets, its value is (4 + length of Sub-TLVs/values). 336 Binding SID Type (BT): 1 octet indicates whether the binding SID is 337 represented by a Sub-TLV or a value included in the TLV. For the 338 binding SID represented by a value, it indicates the type of binding 339 SID. The following BT values are defined: 341 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., Binding 342 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 343 TLV defined in [I-D.ietf-ospf-segment-routing-extensions]. BT != 0 344 indicates that the binding SID is represented by a value. 346 o BT = 1: The binding SID value is a label, which is represented by 347 the 20 rightmost bits. The length of the value is 3 octets. 349 o BT = 2: The binding SID value is a 32-bit SID. The length of the 350 value is 4 octets. 352 SIDs Type (ST): 1 octet indicates whether the list of segments (SIDs) 353 are represented by Sub-TLVs or values included in the TLV. For the 354 SIDs represented by values, it indicates the type of SIDs. The 355 following ST values are defined: 357 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 358 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 359 TLV or a SID/Label Sub-TLV defined in 360 [I-D.ietf-ospf-segment-routing-extensions]. ST != 0 indicates that 361 the SIDs are represented by values. 363 o ST = 1: Each of the SID values is a label, which is represented by 364 the 20 rightmost bits. The length of the value is 3 octets. 366 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 367 value is 4 octets. 369 The opaque LSA of LS Type 9 containing the binding segment (i.e., the 370 binding SID and the list of the segments) has the format as shown in 371 Figure 5. It may have Opaque Type of x (the exact type is to be 372 assigned by IANA) for Binding Segment Opaque LSA. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | LS age | Options | LS Type (9) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Opaque Type(x)| Opaque ID | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Advertising Router | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | LS sequence number | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | LS checksum | Length | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 : Binding Segment TLVs : 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 5: OSPFv2 Binding Segment Opaque LSA 394 For every binding on a node A, the LSA originated by A contains a 395 binding segment TLV for it. 397 For node A running OSPFv3, it originates a link-local scoping LSA of 398 a new LSA function code (TBD3) containing binding segment TLVs for 399 the bindings on it. The format of the LSA is illustrated in 400 Figure 6. 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | LS age |0|0|0| BS-LSA (TBD3) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Link State ID | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Advertising Router | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | LS Sequence Number | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | LS checksum | Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 : Binding Segment TLVs : 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 6: OSPFv3 Binding Segment Opaque LSA 422 The U-bit is set to 0, and the scope is set to 00 for link-local 423 scoping. 425 3.2. Extensions to IS-IS 427 3.2.1. Advertising Proxy Forwarding 429 When a node P has the capability to do a SR proxy forwarding for its 430 neighboring nodes for protecting the failures of them, node P 431 advertises its SR proxy forwarding capability in its LSP, which 432 contains a Router Capability TLV of Type 242 including a SR 433 capabilities sub-TLV of sub-Type 2. 435 One bit (called PF bit as shown in Figure 7) in the Flags field of 436 the SR capabilities sub-TLV is defined to indicate node P's SR proxy 437 forwarding capability. When this bit is set to one by node P, it 438 indicates that node P is capable of doing a SR proxy forwarding for 439 its neighboring nodes. 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type (2) | Length | Flags | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Range | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 // SID/Label Sub-TLV (variable) // 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 0 1 2 3 4 5 6 7 452 +--+--+--+--+--+--+--+--+ 453 | I| V|PF| | 454 +--+--+--+--+--+--+--+--+ 455 Flags 457 Figure 7: SR Capabilities sub-TLV 459 If node P can not do a SR proxy forwarding for all its neighboring 460 nodes, but for some of them, then it advertises the node SID of each 461 of the nodes as a proxy node SID, indicating that it is able to do 462 proxy forwarding for the node SID. 464 The IS-IS SID/Label Binding TLV (suggested value 149) is defined in 465 [I-D.ietf-isis-segment-routing-extensions]. A Proxy Forwarder uses 466 the SID/Label Binding TLV to advertise the node SID of its 467 neighboring node. The Flags field of the SID/Label Binding TLV is 468 extended to include a P flag as shown in Figure 8. The prefix/node 469 SID in prefix/node SID Sub-TLV included in SID/Label Binding TLV is 470 identified as a proxy forwarding prefix/node SID. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Type | Length | Flags | RESERVED | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Range | Prefix Length | Prefix | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 // Prefix (continued, variable) // 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | SubTLVs (variable) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 0 1 2 3 4 5 6 7 485 +-+-+-+-+-+-+-+-+ 486 |F|M|S|D|A|P| | 487 +-+-+-+-+-+-+-+-+ 488 Flags 490 Figure 8: SID/Label Binding TLV 492 Where: 494 P-Flag: Proxy forwarding flag. If set, this prefix/node SID is 495 advertised by the proxy node. This TLV is used to announce that the 496 node has the ability to proxy forward the prefix/node SID. 498 When the P-flag is set in the SID/Label Binding TLV, the following 499 usage rules apply. 501 The Range, Prefix Length and Prefix field are not used. They should 502 be set to zero on transmission and ignored on receipt. 504 SID/Label Binding TLV contains a number of prefix/node SID Sub-TLVs. 505 The TLV advertised by a proxy forwarding node P contains prefix/node 506 SID Sub-TLVs for the node SIDs of P's neighbor nodes. Each of the 507 Sub-TLVs is a prefix/node SID Sub-TLV defined in 508 [I-D.ietf-isis-segment-routing-extensions]. From the SID in a 509 prefix/node SID Sub-TLV advertised by the Proxy Forwarding node, its 510 prefix can be obtained through matching corresponding prefix/node SID 511 advertised by the neighbor/protected node using TLV-135 (or 235, 236, 512 or 237) together with the prefix/node SID Sub-TLV. 514 3.2.2. Advertising Binding Segment 516 [I-D.ietf-spring-segment-routing-policy] has defined the usage of 517 binding-SID. For supporting binding SID proxy forwarding, a new IS- 518 IS TLV, called Binding Segment TLV, is defined. It contains a 519 binding SID and a list of segments (SIDs). This TLV may be 520 advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link 521 State PDUs (CS-LSP) [RFC7356]. Its format is shown in Figure 9. 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type | Length |BindingSID Type| SIDs Type | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 ~ Binding SID value/Sub-TLV ~ 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 ~ SID values/Sub-TLVs ~ 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 9: IS-IS Binding Segment TLV 535 The fields of this TLV are defined as follows: 537 Type: 1 octet Suggested value 152 (to be assigned by IANA) 539 Length: 1 octet (2 + length of Sub-TLVs/values). 541 Binding SID Type (BT): 1 octet indicates whether the binding SID is 542 represented by a Sub-TLV or a value included in the TLV. For the 543 binding SID represented by a value, it indicates the type of binding 544 SID. The following BT values are defined: 546 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., binding 547 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 548 TLV defined in [I-D.ietf-isis-segment-routing-extensions]. BT != 0 549 indicates that the binding SID is represented by a value. 551 o BT = 1: The binding SID value is a label, which is represented by 552 the 20 rightmost bits. The length of the value is 3 octets. 554 o BT = 2: The binding SID value is a 32-bit SID. The length of the 555 value is 4 octets. 557 SIDs Type (ST): 1 octet indicates whether the SIDs are represented by 558 Sub-TLVs or values included in the TLV. For the SIDs represented by 559 values, it indicates the type of SIDs. The following ST values are 560 defined: 562 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 563 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 564 TLV or a SID/Label Sub-TLV defined in 565 [I-D.ietf-isis-segment-routing-extensions]. ST != 0 indicates that 566 the SIDs are represented by values. 568 o ST = 1: Each of the SID values is a label, which is represented by 569 the 20 rightmost bits. The length of the value is 3 octets. 571 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 572 value is 4 octets. 574 4. Building Proxy Forwarding Table 576 Figure 10 is used to illustrate the SR proxy forwarding approach. 577 Each node N has SRGB = [N000-N999]. RT1 is an ingress node of SR 578 domain. RT3 is a failure node. RT2 is a Point of Local Repair (PLR) 579 node, i.e., a proxy forwarding node. Three label stacks are shown in 580 the figure. Label Stack 1 uses only adjacency-SIDs and represents 581 the path RT1->RT2->RT3->RT4->RT5. Label Stack 2 uses only node-SIDs 582 and represents the ECMP-aware path RT1->RT3->RT4->RT5. Label Stack 3 583 uses a node-SID and a binding SID. The Binding-SID with label=100 at 584 RT3 represents the ECMP-aware path RT3->RT4->RT5. So Label Stack 3, 585 which consists of the node-SID for RT3 following by Binding-SID=100, 586 represents the ECMP-aware path RT1->RT3->RT4->RT5. 588 Node SID:2 Node SID:3 589 +-----+ +-----+ 590 | |----------+ | 591 / |RT2 | | RT3 |\ 592 / +-----+ +-----+ \ 593 / | \ /| \ 594 / | \ / | \ 595 / | \ / | \ 596 / | \ / | \ 597 / | \ / | \ 598 Node SID:1 | \ / | \Node SID:4 Node SID:5 599 +-----+ | \ / | +-----+ +-----+ 600 | | | X | | |-------| | 601 | RT1 | | / \ | | RT4 | | RT5 | 602 +-----+ | / \ | +-----+ +-----+ 603 \ | / \ | / 604 \ | / \ | / 605 \ | / \ | / 606 \ | / \ | / 607 \ | / \| / 608 \ |/ | / 609 \ +-----+ +-----+ / 610 \ | | | |/ 611 \ | RT6 |-----------| RT7 | 612 +-----+ +-----+ 613 Node SID:6 Node SID:7 615 +-----------------+ +--------------+ 616 | Node SRGB | | Adj-SID | +-------+ +-------+ +-------+ 617 +-----------------+ +--------------+ |Label | |Label | |Label | 618 | RT1:[1000-1999] | |RT1->RT2:10012| |Stack 1| |Stack 2| |Stack 3| 619 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 620 | RT2:[2000-2999] | |RT2->RT3:20023| | 10012 | | 1003 | | 1003 | 621 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 622 | RT3:[3000-3999] | |RT3->RT6:30036| | 20023 | | 3004 | | 100 | 623 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 624 | RT4:[4000=4999] | |RT3->RT7:30037| | 30034 | | 4005 | 100 is 625 +-----------------+ +--------------+ +-------+ +-------+ binding SID 626 | RT5:[5000-5999] | |RT3->RT4:30034| | 40045 | to 627 +-----------------+ +--------------+ +-------+ {30034,40045} 628 | RT6:[6000-6999] | |RT7->RT4:70074| 629 +-----------------+ +--------------+ 630 | RT7:[7000-7999] | |RT4->RT5:40045| 631 +-----------------+ +--------------+ 633 Figure 10: Topology of SR-TE Path 635 4.1. Advertising Proxy Forwarding 637 If the Point of Local Repair (PLR), for example, RT2, has the 638 capability to do a SR proxy forwarding for all its neighboring nodes, 639 it must advertise this capability. If the PLR can not do a SR proxy 640 forwarding for all its neighboring nodes, but for some of them, for 641 example, RT3, then it uses proxy Node SIDs TLV to advertise the 642 prefix-SID learned from RT3. The TLV contains the Sub-TLV/value for 643 the prefix/node SID of RT3 as a proxy SID. When RT3 fails, RT2 needs 644 to maintain the Sub-TLV/value for a period of time. When the proxy 645 forwarding table corresponding to the fault node is deleted (see 646 section 3.2), the Sub-TLV/value is withdrawn. The nodes in the 647 network (for example, RT1) learn the prefix/node SID TLV advertised 648 by RT3 and the proxy Node SIDs TLV advertised by RT2. When RT3 is 649 normal, the nodes prefer prefix/node SID TLV. When the RT3 fails, 650 the proxy prefix/node SIDs TLV advertised by RT2 is preferred. 652 4.2. Building Proxy Forwarding Table 654 A SR proxy node P needs to build an independent proxy forwarding 655 table for each neighbor N. The proxy forwarding table for node N 656 contains the following information: 658 1: Node N's SRGB range and the difference between the SRGB start 659 value of node P and that of node N; 661 2: All adjacency-SID of N and Node-SID of the node pointed to by node 662 N's adjacency-SID. 664 3: The binding-SID of N and the label stack associated with the 665 binding-SID. 667 Node P (PLR) uses a proxy forwarding table based on the next segment 668 to find a node N as a backup forwarding entry to the adj-SID and 669 Node-SID of node N. When node N fails, the proxy forwarding table 670 needs to be maintained for a period of time, which is recommended for 671 30 minutes. 673 Node RT3 in the topology of Figure 1 is node N, and node RT2 is node 674 P (PLR). RT2 builds the proxy forwarding table for RT3. The 675 structure of the table and how to build the table is a local 676 implementation issue. 678 5. Node Protection for Segment List 680 Segment Routing Traffic Engineering supports the creation of explicit 681 paths using adjacency-SIDs, node-SIDs, and binding-SIDs. The label 682 stack is a combination of one or more of adjacency-SIDs, node-SIDs, 683 and binding-SIDs. This Section shows how a proxy node uses the SR 684 proxy forwarding mechanism to protect traffic to the destination node 685 when the next segment of label stack is adjacency-SIDs, node-SIDs, or 686 binding-SIDs, respectively. 688 5.1. Next Segment is an Adjacency Segment 690 As shown in Figure 1, Label Stack 1 {10012, 20023, 30034, 40045} 691 represents SR-TE strict explicit path RT1->RT2->RT3->RT4->RT5. When 692 RT3 fails, node RT2 acts as a PLR, and uses next adj-SID (30034) of 693 the label stack to lookup the proxy forwarding table built by RT2 694 locally for RT3. The path returned is the label forwarding path to 695 RT3's next hop node RT4, which bypasses RT3. The specific steps are 696 as follows: 698 a. RT1 pops top adj-SID 10012, and forwards the packet to RT2; 700 b. RT2 uses the label 20023 to identify the next hop node RT3, which 701 has failed. RT2 pops label 20023 and queries the Proxy Forwarding 702 Table corresponding to RT3 with label 30034. The Proxy Forwarding 703 Table corresponding to RT3 returns an outgoing interface and label 704 stack representing a path to RT4 that does not pass through RT3. In 705 this case, outgoing interface to RT7 with label stack 7004, satisfies 706 this requirement. 708 c. So the packet leaves RT2 out the interface to RT7 with label 709 stack {7004, 40045}. RT4 forwards it to RT4, where the original path 710 is rejoined. 712 d. RT2 forwards packets to RT7. RT7 queries the local routing table 713 to forward the packet to RT4. 715 5.2. Next Segment is a Node Segment 717 As shown in Figure 1, Label Stack 2 {1003, 3004, 4005} represents SR- 718 TE loose path RT1->RT3->RT4->RT5, where 1003 is the node SID of RT3. 720 When the node RT3 fails, the proxy forwarding TLV advertised by the 721 RT2 is preferred to direct the traffic of the RT1 to the PLR node 722 RT2. Node RT2 acts as a PLR node and queries the proxy forwarding 723 table locally built for RT3. The path returned is the label 724 forwarding path to RT3's next hop node RT4, which bypasses RT3. The 725 specific steps are as follows: 727 a. RT1 swaps label 1003 to out-label 2003 to RT3. 729 b. RT2 receives the label forwarding packet whose top label of label 730 stack is 2003, and searches for the local Routing Table, the behavior 731 found is to lookup Proxy Forwarding table due to RT3 failure. 733 c. RT2 uses 2003 as the in-label to lookup Proxy Forwarding table, 734 and the query result is forwarding the packet to RT4. 736 d. Then RT2 queries the Routing Table to RT4, using the primary or 737 backup path to RT4. The next hop is RT7. 739 e. RT2 forwards the packet to RT7. RT7 queries the local routing 740 table to forward the packet to RT4. 742 f. After RT1 convergences, node SID 1003 is preferred to the proxy 743 SID implied/advertised by RT2. 745 5.3. Next Segment is a Binding Segment 747 As shown in Figure 1, Label Stack 3 {1003, 100} represents SR-TE 748 loose path RT1->RT3->RT4->RT5, where 100 is a Binding-SID, which 749 represents segment list {30034, 40045}. 751 When the node RT3 fails, the proxy forwarding SID implied or 752 advertised by the RT2 is preferred to forward the traffic of the RT1 753 to the PLR node RT2. Node RT2 acts as a PLR node and uses Binding- 754 SID to query the proxy forwarding table locally built for RT3. The 755 path returned is the label forwarding path to RT3's next hop node 756 (RT4), which bypasses RT3. The specific steps are as follows: 758 a. RT1 swaps label 1003 to out-label 2003 to RT3. 760 b. RT2 receives the label forwarding packet whose top label of label 761 stack is 2003, and searches for the local Routing Table, the behavior 762 found is to lookup Proxy Forwarding table due to RT3 failure. 764 c. RT2 uses Binding-SID:100 (label 2003 has pop) as the in-label to 765 lookup the Next Label record of the Proxy Forwarding Table, the 766 behavior found is to swap to Segment list {30034, 40045}. 768 d. RT2 swaps Binding-SID:100 to Segment list {30034, 40045}, and 769 uses the 3034 to lookup the Next Label record of the Proxy Forwarding 770 table again. The behavior found is to forward the packet to RT4. 772 e. RT2 queries the Routing Table to RT4, using primary or backup 773 path to RT4. The next hop is RT7. 775 f. RT2 forwards packets to RT7. RT7 queries the local routing table 776 to forward the packet to RT4. 778 6. Security Considerations 780 The extensions to OSPF and IS-IS described in this document result in 781 two types of behaviors in data plane when a node in a network fails. 782 One is that for a node, which is a upstream (except for the direct 783 upstream) node of the failed node along a SR-TE path, it continues to 784 send the traffic to the failed node along the SR-TE path for an 785 extended period of time. The other is that for a node, which is the 786 direct upstream node of the failed node, it fast re-routes the 787 traffic around the failed node to the direct downstream node of the 788 failed node along the SR-TE path. These behaviors are internal to a 789 network and should not cause extra security issues. 791 7. IANA Considerations 793 7.1. OSPFv2 795 Under Subregistry Name "OSPF Router Functional Capability Bits" 796 within the "Open Shortest Path First v2 (OSPFv2) Parameters" 797 [RFC7770], IANA is requested to assign one bit for Proxy Forwarding 798 Capability as follows: 800 +============+==================+===================+ 801 | Bit number | Capability Name | Reference | 802 +============+==================+===================+ 803 | 31 | Proxy Forwarding | This document | 804 +------------+------------------+-------------------+ 806 Under Registry Name "OSPFv2 Extended Prefix Opaque LSA TLVs" 807 [RFC7684], IANA is requested to assign one new TLV value for OSPF 808 Proxy Node SIDs as follows: 810 +============+=====================+================+ 811 | TLV Value | TLV Name | Reference | 812 +============+=====================+================+ 813 | 2 | Proxy Node SIDs TLV | This document | 814 +------------+---------------------+----------------+ 816 Under Registry Name "Opaque Link-State Advertisements (LSA) Option 817 Types" [RFC5250], IANA is requested to assign new Opaque Type 818 registry values for Binding Segment LSA as follows: 820 +================+==================+================+ 821 | Registry Value | Opaque Type | Reference | 822 +================+==================+================+ 823 | 10 | Binding Segment | This document | 824 +----------------+------------------+----------------+ 826 IANA is requested to create and maintain new registries: 828 o OSPFv2 Binding Segment Opaque LSA TLVs 830 Initial values for the registry are given below. The future 831 assignments are to be made through IETF Review [RFC5226]. 833 Value TLV Name Definition 834 ----- ----------------------- ---------- 835 0 Reserved 836 1 Binding Segment TLV This Document 837 2-32767 Unassigned 838 32768-65535 Reserved 840 7.2. OSPFv3 842 Under Registry Name "OSPFv3 LSA Function Codes", IANA is requested to 843 assign new registry values for Binding Segment LSA as follows: 845 +========+========================+================+ 846 | Value | LSA Function Code Name | Reference | 847 +========+========================+================+ 848 | 16 | Binding Segment LSA | This document | 849 +--------+------------------------+----------------+ 851 IANA is requested to create and maintain new registries: 853 o OSPFv3 Binding Segment LSA TLVs 855 Initial values for the registry are given below. The future 856 assignments are to be made through IETF Review [RFC5226]. 858 Value TLV Name Definition 859 ----- ----------------------- ---------- 860 0 Reserved 861 1 Binding Segment TLV This Document 862 2-32767 Unassigned 863 32768-65535 Reserved 865 7.3. IS-IS 867 Under Registration "Segment Routing Capability" in the "sub-TLVs for 868 TLV 242" registry [I-D.ietf-isis-segment-routing-extensions], IANA is 869 requested to assign one bit flag for Proxy Forwarding Capability as 870 follows: 872 +============+=======================+===============+ 873 | Bit number | Capability Name | Reference | 874 +============+=======================+===============+ 875 | 2 | Proxy Forwarding (PF) | This document | 876 +------------+-----------------------+---------------+ 878 Under Registration "Segment Identifier/Label Binding TLV 149" 879 [I-D.ietf-isis-segment-routing-extensions], IANA is requested to 880 assign one bit P-Flag as follows: 882 +============+=================+===============+ 883 | Bit number | Flag Name | Reference | 884 +============+=================+===============+ 885 | 5 | P-Flag | This document | 886 +------------+-----------------+---------------+ 888 Under Registry Name: IS-IS TLV Codepoints, IANA is requested to 889 assign one new TLV value for IS-IS Binding Segment as follows: 891 +========+======================+===============+ 892 | Value | TLV Name | Reference | 893 +========+======================+===============+ 894 | 152 | Binding Segment TLV | This Document | 895 +--------+----------------------+---------------+ 897 8. Acknowledgements 899 The authors would like to thank Peter Psenak, Acee Lindem, Les 900 Ginsberg, Bruno Decraene and Jeff Tantsura for their comments to this 901 work. 903 9. References 905 9.1. Normative References 907 [I-D.ietf-isis-segment-routing-extensions] 908 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 909 Gredler, H., and B. Decraene, "IS-IS Extensions for 910 Segment Routing", draft-ietf-isis-segment-routing- 911 extensions-25 (work in progress), May 2019. 913 [I-D.ietf-ospf-segment-routing-extensions] 914 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 915 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 916 Extensions for Segment Routing", draft-ietf-ospf-segment- 917 routing-extensions-27 (work in progress), December 2018. 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", BCP 14, RFC 2119, 921 DOI 10.17487/RFC2119, March 1997, 922 . 924 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 925 IANA Considerations Section in RFCs", RFC 5226, 926 DOI 10.17487/RFC5226, May 2008, 927 . 929 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 930 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 931 July 2008, . 933 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 934 Scope Link State PDUs (LSPs)", RFC 7356, 935 DOI 10.17487/RFC7356, September 2014, 936 . 938 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 939 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 940 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 941 2015, . 943 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 944 S. Shaffer, "Extensions to OSPF for Advertising Optional 945 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 946 February 2016, . 948 9.2. Informative References 950 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 951 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 952 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 953 "Topology Independent Fast Reroute using Segment Routing", 954 draft-ietf-rtgwg-segment-routing-ti-lfa-04 (work in 955 progress), August 2020. 957 [I-D.ietf-spring-segment-protection-sr-te-paths] 958 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 959 "Segment Protection for SR-TE Paths", draft-ietf-spring- 960 segment-protection-sr-te-paths-00 (work in progress), 961 September 2020. 963 [I-D.ietf-spring-segment-routing-policy] 964 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 965 P. Mattes, "Segment Routing Policy Architecture", draft- 966 ietf-spring-segment-routing-policy-08 (work in progress), 967 July 2020. 969 [I-D.sivabalan-pce-binding-label-sid] 970 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 971 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 972 in PCE-based Networks.", draft-sivabalan-pce-binding- 973 label-sid-07 (work in progress), July 2019. 975 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 976 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 977 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 978 2009, . 980 Authors' Addresses 982 Zhibo Hu 983 Huawei Technologies 984 Huawei Bld., No.156 Beiqing Rd. 985 Beijing 100095 986 China 988 Email: huzhibo@huawei.com 990 Huaimo Chen 991 Futurewei 992 Boston, MA 993 USA 995 Email: Huaimo.chen@futurewei.com 997 Junda Yao 998 Huawei Technologies 999 Huawei Bld., No.156 Beiqing Rd. 1000 Beijing 100095 1001 China 1003 Email: yaojunda@huawei.com 1004 Chris Bowers 1005 Juniper Networks 1006 1194 N. Mathilda Ave. 1007 Sunnyvale, CA 94089 1008 USA 1010 Email: cbowers@juniper.net 1012 Yongqing 1013 China Telecom 1014 109, West Zhongshan Road, Tianhe District 1015 Guangzhou 510000 1016 China 1018 Email: zhuyq8@chinatelecom.cn