idnits 2.17.1 draft-hu-spring-segment-routing-proxy-forwarding-10.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. ** The abstract seems to contain references ([I-D.hegde-spring-node-protection-for-sr-te-paths], [I-D.ietf-rtgwg-segment-routing-ti-lfa]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (August 1, 2020) is 1363 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 571, but not defined == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 963, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 969, 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-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 Summary: 3 errors (**), 0 flaws (~~), 7 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: February 2, 2021 Futurewei 6 J. Yao 7 Huawei Technologies 8 C. Bowers 9 Juniper Networks 10 Y. Zhu 11 China Telecom 12 August 1, 2020 14 SR-TE Path Midpoint Protection 15 draft-hu-spring-segment-routing-proxy-forwarding-10 17 Abstract 19 Segment Routing Traffic Engineering (SR-TE) supports the creation of 20 explicit paths using segment lists containing adjacency-SIDs, node- 21 SIDs, anycast-SIDs, and binding-SIDs. When the segment list defining 22 an SR-TE path contains a node-SID, and the node fails, the network 23 may no longer be able to properly forward traffic on that SR-TE path. 24 [I-D.ietf-rtgwg-segment-routing-ti-lfa] and 25 [I-D.hegde-spring-node-protection-for-sr-te-paths] describe a 26 mechanism that allows local repair actions on the direct neighbors of 27 the failed node to temporarily route traffic to the node immediately 28 following the failed node on the SR-TE path segment list. However, 29 once the IGP shortest paths have converged, the local repair 30 mechanism is no longer sufficient to continue forwarding traffic 31 using the original segment list of the SR-TE path, since the non- 32 neighbors of the failed node will no longer have a route to reach the 33 failed node. This document describes a mechanism that allows traffic 34 to continue to be forwarded on an SR-TE path for an extended period 35 of time after the failure of a node used in the path's segment list. 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 February 2, 2021. 60 Copyright Notice 62 Copyright (c) 2020 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. Extensions to IGP for Proxy Forwarding . . . . . . . . . . . 4 79 2.1. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 4 80 2.1.1. Advertising Proxy Forwarding . . . . . . . . . . . . 4 81 2.1.2. Advertising Binding Segment . . . . . . . . . . . . . 7 82 2.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 10 83 2.2.1. Advertising Proxy Forwarding . . . . . . . . . . . . 10 84 2.2.2. Advertising Binding Segment . . . . . . . . . . . . . 12 85 3. Building Proxy Forwarding Table . . . . . . . . . . . . . . . 13 86 3.1. Advertising Proxy Forwarding . . . . . . . . . . . . . . 15 87 3.2. Building Proxy Forwarding Table . . . . . . . . . . . . . 15 88 4. Node Protection for Segment List . . . . . . . . . . . . . . 15 89 4.1. Next Segment is an Adjacency Segment . . . . . . . . . . 16 90 4.2. Next Segment is a Node Segment . . . . . . . . . . . . . 16 91 4.3. Next Segment is a Binding Segment . . . . . . . . . . . . 17 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 6.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 6.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 6.3. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 100 8.2. Informative References . . . . . . . . . . . . . . . . . 21 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 Segment Routing Traffic Engineering (SR-TE) is a technology that 106 implements traffic engineering using Segment Routing. SR-TE supports 107 the creation of explicit paths using adjacency-SIDs, node-SIDs, 108 anycast-SIDs, and binding-SIDs. A node-SID in the segment list 109 defining an SR-TE path indicates a loose hop that the SR-TE path 110 should pass through. When a particular node fails, it would be 111 useful to be able to continue to send traffic on an SR-TE path that 112 uses the node-SID of the failed node for an extended period of time, 113 without having to immediately modify the segment list used at the 114 ingress to the SR-TE path. 116 The first step to achieve this objective is to make the rest of the 117 routers in the network continue to forward traffic using the node-SID 118 of the failed node. If we don't do anything special, once the IGP 119 converges to take into account the failed node, a given router will 120 no longer maintain a route corresponding to the node-SID. Any 121 traffic that arrives at the router with the node-SID of the failed 122 node as the active segment will be dropped. This document addresses 123 this problem by having each neighbor of the failed node advertise its 124 SR proxy forwarding capability. This indicates that the neighbor 125 (the Proxy Forwarder) will forward traffic on behalf of the failed 126 node. A router receiving the SR Proxy Forwarding capability from 127 neighbors of a failed node will send traffic using the node-SID of 128 the failed node to the nearest Proxy Forwarder. 130 Once the affected traffic reaches a Proxy Forwarder, the Proxy 131 Forwarder sends the traffic on the post-failure shortest path to the 132 node immediately following the failed node in the segment list. 133 [I-D.ietf-rtgwg-segment-routing-ti-lfa] and 134 [I-D.hegde-spring-node-protection-for-sr-te-paths] describe how the 135 immediate neighbors of a failed node can accomplish this by 136 forwarding based on the first two segments in the segment list. The 137 forwarding described in these drafts was originally intended to be 138 used for only a short period of time, to provide fast-reroute 139 protection until the IGP converges. The current document proposes to 140 extend this behavior on the Proxy Forwarder until well after the IGP 141 has converged. 143 If the faulty node is a label adhesion node, the Binding-SIDs cannot 144 be exchanged to the label stack for its identity, and the traffic 145 will be lost before it reaches the faulty node. 147 In this document, the proxy mechanism is provided in the neighbor 148 node of the faulty node of the forwarding path to implement traffic 149 forwarding after the node with the label adhesion fails on the SR-TE 150 loose path. 152 2. Extensions to IGP for Proxy Forwarding 154 When a node has segment routing proxy forwarding capability, it 155 advertises this capability. The capability indicates that the node 156 has the ability to do proxy forwarding for the global SID of each of 157 its neighbors. When an neighbor in a SR-TE path fails, the traffic 158 can be forwarded to the proxy node, which fast re-routes the traffic 159 to the node immediately following the failed node on the SR-TE path. 161 2.1. Extensions to OSPF 163 2.1.1. Advertising Proxy Forwarding 165 When a node P has the capability to do a SR proxy forwarding for all 166 its neighboring nodes for protecting the failures of these nodes, 167 node P advertises its SR proxy forwarding capability in its router 168 information opaque LSA, which contains a Router Functional 169 Capabilities TLV of the format as shown in Figure 1. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type | Length | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Functional Capabilities | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Figure 1: Router Functional Capabilities TLV 181 One bit (called PF bit) in the Functional Capabilities field of the 182 TLV is used to indicate node P's SR proxy forwarding capability. 183 When this bit is set to one by node P, it indicates that node P is 184 capable of doing a SR proxy forwarding for its neighboring nodes. 186 For a node X in the network, it learns the prefix/node SID of node N, 187 which is originated and advertised by node N. It creates a proxy 188 prefix/node SID of node N for node P if node P is capable of doing SR 189 proxy forwarding for node N. The proxy prefix/node SID of node N for 190 node P is a copy of the prefix/node SID of node N originated by node 191 N, but stored under (or say, associated with) node P. 193 In normal operations, node X prefers to use the prefix/node SID of 194 node N. When node N fails, node X prefers to use the proxy prefix/ 195 node SID of node N. Thus node X will forward the traffic targeting 196 to the prefix/node SID of node N to node P when node N fails, and 197 node P will do a SR proxy forwarding for node N and forwarding the 198 traffic to its final destination without going through node N. After 199 node N fails, node X will keep the FIB entry to the proxy prefix/node 200 SID of node N for a given period of time. 202 Note that the behaviors of normal IP forwarding and routing 203 convergences in a network are not changed at all by the SR proxy 204 forwarding. For example, the next hop used by BGP is an IP address 205 (or prefix). The IGP and BGP converge in normal ways for changes in 206 the network. The packet with its IP destination to this next hop is 207 forwarded according to the IP forwarding table (FIB) derived from IGP 208 and BGP routes. 210 If node P can not do a SR proxy forwarding for all its neighboring 211 nodes, but for some of them, then it advertises the node SID of each 212 of the nodes as a proxy node SID, indicating that it is able to do 213 proxy forwarding for the node SID. 215 A new TLV, called Proxy Node SIDs TLV, is defined for node P to 216 advertise the node SIDs of some of its neighboring nodes. It has the 217 format as shown in Figure 2. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type (TBD1) | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Node SID Sub-TLVs | 225 : : 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 2: OSPF Proxy Node SIDs TLV 230 The Type (TBD1) is to be assigned by IANA. The TLV contains a number 231 of Node SID Sub-TLVs. The Length is the total size of the Node SID 232 Sub-TLVs included in the TLV. A Node SID Sub-TLV is the Prefix SID 233 Sub-TLV defined in [I-D.ietf-ospf-segment-routing-extensions]. 235 A proxy forwarding node P originates an Extended Prefix Opaque LSA 236 containing this new TLV. The TLV includes the Node SID Sub-TLVs for 237 the node SIDs of some of P's neighboring nodes. For each of some of 238 P's neighboring nodes, the Node SID Sub-TLV for its prefix/node SID 239 is included the TLV. This prefix/node SID is called a proxy prefix/ 240 node SID. 242 A proxy forwarding node will originate an Extended Prefix Opaque LSA, 243 which includes a Proxy Node SIDs TLV. The format of the LSA is shown 244 in Figure 3. 246 For a proxy forwarding node P, having a number of neighboring nodes, 247 P originates and maintains an Extended Prefix Opaque LSA, which 248 includes a Proxy Node SIDs TLV. The TLV contains the Prefix/Node SID 249 Sub-TLV for each of some of the neighboring nodes after node P 250 creates the corresponding proxy forwarding entries for protecting the 251 failure of some of the neighboring nodes. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | LS age | Options | LS Type | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Opaque Type(7)| Opaque ID | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Advertising Router | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | LS sequence number | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | LS checksum | Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | 267 : TLVs : 268 : (including Proxy Node SIDs TLV) : 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 3: OSPFv2 Extended Prefix Opaque LSA 274 When an neighboring node fails, P maintains the LSA with the TLV 275 containing the Prefix/Node SID Sub-TLV for the neighboring node for a 276 given period of time. After the given period of time, the Prefix/ 277 Node SID Sub-TLV for the neighboring node is removed from the TLV in 278 the LSA and then after a given time the corresponding proxy 279 forwarding entries for protecting the failure of the neighboring node 280 is removed. 282 For a node X in the network, it learns the prefix/node SID of node N 283 and the proxy prefix/node SID of node N. The former is originated 284 and advertised by node N, and the latter is originated and advertised 285 by the proxy forwarding node P of node N. Note that the proxy 286 Prefix/Node SID Sub-TLV for node N does not contain a prefix of node 287 N, and the prefix is the prefix associated with the prefix/node SID 288 of node N originated by node N. 290 In normal operations, node X prefers to use the prefix/node SID of 291 node N. When node N fails, node X prefers to use the proxy prefix/ 292 node SID of node N. Thus node X will forward the traffic targeting 293 to node N to node P when node N fails, and node P will do a proxy 294 forwarding for node N and forwarding the traffic to its destination 295 without going through node N. 297 2.1.2. Advertising Binding Segment 299 For a binding segment (or binding for short) on a node A, which 300 consists of a binding SID and a list of segments, node A advertises 301 an LSA containing the binding (i.e., the binding SID and the list of 302 the segments). The LSA is advertised only to each of the node A's 303 neighboring nodes. For OSPFv2, the LSA is a opaque LSA of LS type 9 304 (i.e., a link local scope LSA). 306 A binding segment is represented by binding segment TLV of the format 307 as shown in Figure 4. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type (TBD2) | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Reserved |BindingSID Type| SIDs Type | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 ~ Binding SID Sub-TLV/value ~ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 ~ SID Sub-TLVs/values ~ 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 4: OSPF Binding Segment TLV 323 It comprises a binding SID and a list of segments (SIDs). The fields 324 of this TLV are defined as follows: 326 Type: 2 octets, its value (TBD2) is to be assigned by IANA. 328 Length: 2 octets, its value is (4 + length of Sub-TLVs/values). 330 Binding SID Type (BT): 1 octet indicates whether the binding SID is 331 represented by a Sub-TLV or a value included in the TLV. For the 332 binding SID represented by a value, it indicates the type of binding 333 SID. The following BT values are defined: 335 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., Binding 336 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 337 TLV defined in [I-D.ietf-ospf-segment-routing-extensions]. BT != 0 338 indicates that the binding SID is represented by a value. 340 o BT = 1: The binding SID value is a label, which is represented by 341 the 20 rightmost bits. The length of the value is 3 octets. 343 o BT = 2: The binding SID value is a 32-bit SID. The length of the 344 value is 4 octets. 346 SIDs Type (ST): 1 octet indicates whether the list of segments (SIDs) 347 are represented by Sub-TLVs or values included in the TLV. For the 348 SIDs represented by values, it indicates the type of SIDs. The 349 following ST values are defined: 351 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 352 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 353 TLV or a SID/Label Sub-TLV defined in 354 [I-D.ietf-ospf-segment-routing-extensions]. ST != 0 indicates that 355 the SIDs are represented by values. 357 o ST = 1: Each of the SID values is a label, which is represented by 358 the 20 rightmost bits. The length of the value is 3 octets. 360 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 361 value is 4 octets. 363 The opaque LSA of LS Type 9 containing the binding segment (i.e., the 364 binding SID and the list of the segments) has the format as shown in 365 Figure 5. It may have Opaque Type of x (the exact type is to be 366 assigned by IANA) for Binding Segment Opaque LSA. 368 0 1 2 3 369 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | LS age | Options | LS Type (9) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Opaque Type(x)| Opaque ID | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Advertising Router | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | LS sequence number | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | LS checksum | Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | | 382 : Binding Segment TLVs : 383 | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 5: OSPFv2 Binding Segment Opaque LSA 388 For every binding on a node A, the LSA originated by A contains a 389 binding segment TLV for it. 391 For node A running OSPFv3, it originates a link-local scoping LSA of 392 a new LSA function code (TBD3) containing binding segment TLVs for 393 the bindings on it. The format of the LSA is illustrated in 394 Figure 6. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | LS age |0|0|0| BS-LSA (TBD3) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Link State ID | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Advertising Router | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | LS Sequence Number | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | LS checksum | Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 : Binding Segment TLVs : 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Figure 6: OSPFv3 Binding Segment Opaque LSA 416 The U-bit is set to 0, and the scope is set to 00 for link-local 417 scoping. 419 2.2. Extensions to IS-IS 421 2.2.1. Advertising Proxy Forwarding 423 When a node P has the capability to do a SR proxy forwarding for its 424 neighboring nodes for protecting the failures of them, node P 425 advertises its SR proxy forwarding capability in its LSP, which 426 contains a Router Capability TLV of Type 242 including a SR 427 capabilities sub-TLV of sub-Type 2. 429 One bit (called PF bit as shown in Figure 7) in the Flags field of 430 the SR capabilities sub-TLV is defined to indicate node P's SR proxy 431 forwarding capability. When this bit is set to one by node P, it 432 indicates that node P is capable of doing a SR proxy forwarding for 433 its neighboring nodes. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type (2) | Length | Flags | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Range | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 // SID/Label Sub-TLV (variable) // 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 0 1 2 3 4 5 6 7 446 +--+--+--+--+--+--+--+--+ 447 | I| V|PF| | 448 +--+--+--+--+--+--+--+--+ 449 Flags 451 Figure 7: SR Capabilities sub-TLV 453 If node P can not do a SR proxy forwarding for all its neighboring 454 nodes, but for some of them, then it advertises the node SID of each 455 of the nodes as a proxy node SID, indicating that it is able to do 456 proxy forwarding for the node SID. 458 The IS-IS SID/Label Binding TLV (suggested value 149) is defined in 459 [I-D.ietf-isis-segment-routing-extensions]. A Proxy Forwarder uses 460 the SID/Label Binding TLV to advertise the node SID of its 461 neighboring node. The Flags field of the SID/Label Binding TLV is 462 extended to include a P flag as shown in Figure 8. The prefix/node 463 SID in prefix/node SID Sub-TLV included in SID/Label Binding TLV is 464 identified as a proxy forwarding prefix/node SID. 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type | Length | Flags | RESERVED | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Range | Prefix Length | Prefix | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 // Prefix (continued, variable) // 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | SubTLVs (variable) | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 0 1 2 3 4 5 6 7 479 +-+-+-+-+-+-+-+-+ 480 |F|M|S|D|A|P| | 481 +-+-+-+-+-+-+-+-+ 482 Flags 484 Figure 8: SID/Label Binding TLV 486 Where: 488 P-Flag: Proxy forwarding flag. If set, this prefix/node SID is 489 advertised by the proxy node. This TLV is used to announce that the 490 node has the ability to proxy forward the prefix/node SID. 492 When the P-flag is set in the SID/Label Binding TLV, the following 493 usage rules apply. 495 The Range, Prefix Length and Prefix field are not used. They should 496 be set to zero on transmission and ignored on receipt. 498 SID/Label Binding TLV contains a number of prefix/node SID Sub-TLVs. 499 The TLV advertised by a proxy forwarding node P contains prefix/node 500 SID Sub-TLVs for the node SIDs of P's neighbor nodes. Each of the 501 Sub-TLVs is a prefix/node SID Sub-TLV defined in 502 [I-D.ietf-isis-segment-routing-extensions]. From the SID in a 503 prefix/node SID Sub-TLV advertised by the Proxy Forwarding node, its 504 prefix can be obtained through matching corresponding prefix/node SID 505 advertised by the neighbor/protected node using TLV-135 (or 235, 236, 506 or 237) together with the prefix/node SID Sub-TLV. 508 2.2.2. Advertising Binding Segment 510 [I-D.ietf-spring-segment-routing-policy] has defined the usage of 511 binding-SID. For supporting binding SID proxy forwarding, a new IS- 512 IS TLV, called Binding Segment TLV, is defined. It contains a 513 binding SID and a list of segments (SIDs). This TLV may be 514 advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link 515 State PDUs (CS-LSP) [RFC7356]. Its format is shown in Figure 9. 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Type | Length |BindingSID Type| SIDs Type | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 ~ Binding SID value/Sub-TLV ~ 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 ~ SID values/Sub-TLVs ~ 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Figure 9: IS-IS Binding Segment TLV 529 The fields of this TLV are defined as follows: 531 Type: 1 octet Suggested value 152 (to be assigned by IANA) 533 Length: 1 octet (2 + length of Sub-TLVs/values). 535 Binding SID Type (BT): 1 octet indicates whether the binding SID is 536 represented by a Sub-TLV or a value included in the TLV. For the 537 binding SID represented by a value, it indicates the type of binding 538 SID. The following BT values are defined: 540 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., binding 541 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 542 TLV defined in [I-D.ietf-isis-segment-routing-extensions]. BT != 0 543 indicates that the binding SID is represented by a value. 545 o BT = 1: The binding SID value is a label, which is represented by 546 the 20 rightmost bits. The length of the value is 3 octets. 548 o BT = 2: The binding SID value is a 32-bit SID. The length of the 549 value is 4 octets. 551 SIDs Type (ST): 1 octet indicates whether the SIDs are represented by 552 Sub-TLVs or values included in the TLV. For the SIDs represented by 553 values, it indicates the type of SIDs. The following ST values are 554 defined: 556 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 557 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 558 TLV or a SID/Label Sub-TLV defined in 559 [I-D.ietf-isis-segment-routing-extensions]. ST != 0 indicates that 560 the SIDs are represented by values. 562 o ST = 1: Each of the SID values is a label, which is represented by 563 the 20 rightmost bits. The length of the value is 3 octets. 565 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 566 value is 4 octets. 568 3. Building Proxy Forwarding Table 570 Figure 10 is used to illustrate the SR proxy forwarding approach. 571 Each node N has SRGB = [N000-N999]. RT1 is an ingress node of SR 572 domain. RT3 is a failure node. RT2 is a Point of Local Repair (PLR) 573 node, i.e., a proxy forwarding node. Three label stacks are shown in 574 the figure. Label Stack 1 uses only adjacency-SIDs and represents 575 the path RT1->RT2->RT3->RT4->RT5. Label Stack 2 uses only node-SIDs 576 and represents the ECMP-aware path RT1->RT3->RT4->RT5. Label Stack 3 577 uses a node-SID and a binding SID. The Binding-SID with label=100 at 578 RT3 represents the ECMP-aware path RT3->RT4->RT5. So Label Stack 3, 579 which consists of the node-SID for RT3 following by Binding-SID=100, 580 represents the ECMP-aware path RT1->RT3->RT4->RT5. 582 Node SID:2 Node SID:3 583 +-----+ +-----+ 584 | |----------+ | 585 / |RT2 | | RT3 |\ 586 / +-----+ +-----+ \ 587 / | \ /| \ 588 / | \ / | \ 589 / | \ / | \ 590 / | \ / | \ 591 / | \ / | \ 592 Node SID:1 | \ / | \Node SID:4 Node SID:5 593 +-----+ | \ / | +-----+ +-----+ 594 | | | X | | |-------| | 595 | RT1 | | / \ | | RT4 | | RT5 | 596 +-----+ | / \ | +-----+ +-----+ 597 \ | / \ | / 598 \ | / \ | / 599 \ | / \ | / 600 \ | / \ | / 601 \ | / \| / 602 \ |/ | / 603 \ +-----+ +-----+ / 604 \ | | | |/ 605 \ | RT6 |-----------| RT7 | 606 +-----+ +-----+ 607 Node SID:6 Node SID:7 609 +-----------------+ +--------------+ 610 | Node SRGB | | Adj-SID | +-------+ +-------+ +-------+ 611 +-----------------+ +--------------+ |Label | |Label | |Label | 612 | RT1:[1000-1999] | |RT1->RT2:10012| |Stack 1| |Stack 2| |Stack 3| 613 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 614 | RT2:[2000-2999] | |RT2->RT3:20023| | 10012 | | 1003 | | 1003 | 615 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 616 | RT3:[3000-3999] | |RT3->RT6:30036| | 20023 | | 3004 | | 100 | 617 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 618 | RT4:[4000=4999] | |RT3->RT7:30037| | 30034 | | 4005 | 100 is 619 +-----------------+ +--------------+ +-------+ +-------+ binding SID 620 | RT5:[5000-5999] | |RT3->RT4:30034| | 40045 | to 621 +-----------------+ +--------------+ +-------+ {30034,40045} 622 | RT6:[6000-6999] | |RT7->RT4:70074| 623 +-----------------+ +--------------+ 624 | RT7:[7000-7999] | |RT4->RT5:40045| 625 +-----------------+ +--------------+ 627 Figure 10: Topology of SR-TE Path 629 3.1. Advertising Proxy Forwarding 631 If the Point of Local Repair (PLR), for example, RT2, has the 632 capability to do a SR proxy forwarding for all its neighboring nodes, 633 it must advertise this capability. If the PLR can not do a SR proxy 634 forwarding for all its neighboring nodes, but for some of them, for 635 example, RT3, then it uses proxy Node SIDs TLV to advertise the 636 prefix-SID learned from RT3. The TLV contains the Sub-TLV/value for 637 the prefix/node SID of RT3 as a proxy SID. When RT3 fails, RT2 needs 638 to maintain the Sub-TLV/value for a period of time. When the proxy 639 forwarding table corresponding to the fault node is deleted (see 640 section 3.2), the Sub-TLV/value is withdrawn. The nodes in the 641 network (for example, RT1) learn the prefix/node SID TLV advertised 642 by RT3 and the proxy Node SIDs TLV advertised by RT2. When RT3 is 643 normal, the nodes prefer prefix/node SID TLV. When the RT3 fails, 644 the proxy prefix/node SIDs TLV advertised by RT2 is preferred. 646 3.2. Building Proxy Forwarding Table 648 A SR proxy node P needs to build an independent proxy forwarding 649 table for each neighbor N. The proxy forwarding table for node N 650 contains the following information: 652 1: Node N's SRGB range and the difference between the SRGB start 653 value of node P and that of node N; 655 2: All adjacency-SID of N and Node-SID of the node pointed to by node 656 N's adjacency-SID. 658 3: The binding-SID of N and the label stack associated with the 659 binding-SID. 661 Node P (PLR) uses a proxy forwarding table based on the next segment 662 to find a node N as a backup forwarding entry to the adj-SID and 663 Node-SID of node N. When node N fails, the proxy forwarding table 664 needs to be maintained for a period of time, which is recommended for 665 30 minutes. 667 Node RT3 in the topology of Figure 1 is node N, and node RT2 is node 668 P (PLR). RT2 builds the proxy forwarding table for RT3. The 669 structure of the table and how to build the table is a local 670 implementation issue. 672 4. Node Protection for Segment List 674 Segment Routing Traffic Engineering supports the creation of explicit 675 paths using adjacency-SIDs, node-SIDs, and binding-SIDs. The label 676 stack is a combination of one or more of adjacency-SIDs, node-SIDs, 677 and binding-SIDs. This Section shows how a proxy node uses the SR 678 proxy forwarding mechanism to protect traffic to the destination node 679 when the next segment of label stack is adjacency-SIDs, node-SIDs, or 680 binding-SIDs, respectively. 682 4.1. Next Segment is an Adjacency Segment 684 As shown in Figure 1, Label Stack 1 {10012, 20023, 30034, 40045} 685 represents SR-TE strict explicit path RT1->RT2->RT3->RT4->RT5. When 686 RT3 fails, node RT2 acts as a PLR, and uses next adj-SID (30034) of 687 the label stack to lookup the proxy forwarding table built by RT2 688 locally for RT3. The path returned is the label forwarding path to 689 RT3's next hop node RT4, which bypasses RT3. The specific steps are 690 as follows: 692 a. RT1 pops top adj-SID 10012, and forwards the packet to RT2; 694 b. RT2 uses the label 20023 to identify the next hop node RT3, which 695 has failed. RT2 pops label 20023 and queries the Proxy Forwarding 696 Table corresponding to RT3 with label 30034. The Proxy Forwarding 697 Table corresponding to RT3 returns an outgoing interface and label 698 stack representing a path to RT4 that does not pass through RT3. In 699 this case, outgoing interface to RT7 with label stack 7004, satisfies 700 this requirement. 702 c. So the packet leaves RT2 out the interface to RT7 with label 703 stack {7004, 40045}. RT4 forwards it to RT4, where the original path 704 is rejoined. 706 d. RT2 forwards packets to RT7. RT7 queries the local routing table 707 to forward the packet to RT4. 709 4.2. Next Segment is a Node Segment 711 As shown in Figure 1, Label Stack 2 {1003, 3004, 4005} represents SR- 712 TE loose path RT1->RT3->RT4->RT5, where 1003 is the node SID of RT3. 714 When the node RT3 fails, the proxy forwarding TLV advertised by the 715 RT2 is preferred to direct the traffic of the RT1 to the PLR node 716 RT2. Node RT2 acts as a PLR node and queries the proxy forwarding 717 table locally built for RT3. The path returned is the label 718 forwarding path to RT3's next hop node RT4, which bypasses RT3. The 719 specific steps are as follows: 721 a. RT1 swaps label 1003 to out-label 2003 to RT3. 723 b. RT2 receives the label forwarding packet whose top label of label 724 stack is 2003, and searches for the local Routing Table, the behavior 725 found is to lookup Proxy Forwarding table due to RT3 failure. 727 c. RT2 uses 2003 as the in-label to lookup Proxy Forwarding table, 728 and the query result is forwarding the packet to RT4. 730 d. Then RT2 queries the Routing Table to RT4, using the primary or 731 backup path to RT4. The next hop is RT7. 733 e. RT2 forwards the packet to RT7. RT7 queries the local routing 734 table to forward the packet to RT4. 736 f. After RT1 convergences, node SID 1003 is preferred to the proxy 737 SID implied/advertised by RT2. 739 4.3. Next Segment is a Binding Segment 741 As shown in Figure 1, Label Stack 3 {1003, 100} represents SR-TE 742 loose path RT1->RT3->RT4->RT5, where 100 is a Binding-SID, which 743 represents segment list {30034, 40045}. 745 When the node RT3 fails, the proxy forwarding SID implied or 746 advertised by the RT2 is preferred to forward the traffic of the RT1 747 to the PLR node RT2. Node RT2 acts as a PLR node and uses Binding- 748 SID to query the proxy forwarding table locally built for RT3. The 749 path returned is the label forwarding path to RT3's next hop node 750 (RT4), which bypasses RT3. The specific steps are as follows: 752 a. RT1 swaps label 1003 to out-label 2003 to RT3. 754 b. RT2 receives the label forwarding packet whose top label of label 755 stack is 2003, and searches for the local Routing Table, the behavior 756 found is to lookup Proxy Forwarding table due to RT3 failure. 758 c. RT2 uses Binding-SID:100 (label 2003 has pop) as the in-label to 759 lookup the Next Label record of the Proxy Forwarding Table, the 760 behavior found is to swap to Segment list {30034, 40045}. 762 d. RT2 swaps Binding-SID:100 to Segment list {30034, 40045}, and 763 uses the 3034 to lookup the Next Label record of the Proxy Forwarding 764 table again. The behavior found is to forward the packet to RT4. 766 e. RT2 queries the Routing Table to RT4, using primary or backup 767 path to RT4. The next hop is RT7. 769 f. RT2 forwards packets to RT7. RT7 queries the local routing table 770 to forward the packet to RT4. 772 5. Security Considerations 774 The extensions to OSPF and IS-IS described in this document result in 775 two types of behaviors in data plane when a node in a network fails. 776 One is that for a node, which is a upstream (except for the direct 777 upstream) node of the failed node along a SR-TE path, it continues to 778 send the traffic to the failed node along the SR-TE path for an 779 extended period of time. The other is that for a node, which is the 780 direct upstream node of the failed node, it fast re-routes the 781 traffic around the failed node to the direct downstream node of the 782 failed node along the SR-TE path. These behaviors are internal to a 783 network and should not cause extra security issues. 785 6. IANA Considerations 787 6.1. OSPFv2 789 Under Subregistry Name "OSPF Router Functional Capability Bits" 790 within the "Open Shortest Path First v2 (OSPFv2) Parameters" 791 [RFC7770], IANA is requested to assign one bit for Proxy Forwarding 792 Capability as follows: 794 +============+==================+===================+ 795 | Bit number | Capability Name | Reference | 796 +============+==================+===================+ 797 | 31 | Proxy Forwarding | This document | 798 +------------+------------------+-------------------+ 800 Under Registry Name "OSPFv2 Extended Prefix Opaque LSA TLVs" 801 [RFC7684], IANA is requested to assign one new TLV value for OSPF 802 Proxy Node SIDs as follows: 804 +============+=====================+================+ 805 | TLV Value | TLV Name | Reference | 806 +============+=====================+================+ 807 | 2 | Proxy Node SIDs TLV | This document | 808 +------------+---------------------+----------------+ 810 Under Registry Name "Opaque Link-State Advertisements (LSA) Option 811 Types" [RFC5250], IANA is requested to assign new Opaque Type 812 registry values for Binding Segment LSA as follows: 814 +================+==================+================+ 815 | Registry Value | Opaque Type | Reference | 816 +================+==================+================+ 817 | 10 | Binding Segment | This document | 818 +----------------+------------------+----------------+ 820 IANA is requested to create and maintain new registries: 822 o OSPFv2 Binding Segment Opaque LSA TLVs 824 Initial values for the registry are given below. The future 825 assignments are to be made through IETF Review [RFC5226]. 827 Value TLV Name Definition 828 ----- ----------------------- ---------- 829 0 Reserved 830 1 Binding Segment TLV This Document 831 2-32767 Unassigned 832 32768-65535 Reserved 834 6.2. OSPFv3 836 Under Registry Name "OSPFv3 LSA Function Codes", IANA is requested to 837 assign new registry values for Binding Segment LSA as follows: 839 +========+========================+================+ 840 | Value | LSA Function Code Name | Reference | 841 +========+========================+================+ 842 | 16 | Binding Segment LSA | This document | 843 +--------+------------------------+----------------+ 845 IANA is requested to create and maintain new registries: 847 o OSPFv3 Binding Segment LSA TLVs 849 Initial values for the registry are given below. The future 850 assignments are to be made through IETF Review [RFC5226]. 852 Value TLV Name Definition 853 ----- ----------------------- ---------- 854 0 Reserved 855 1 Binding Segment TLV This Document 856 2-32767 Unassigned 857 32768-65535 Reserved 859 6.3. IS-IS 861 Under Registration "Segment Routing Capability" in the "sub-TLVs for 862 TLV 242" registry [I-D.ietf-isis-segment-routing-extensions], IANA is 863 requested to assign one bit flag for Proxy Forwarding Capability as 864 follows: 866 +============+=======================+===============+ 867 | Bit number | Capability Name | Reference | 868 +============+=======================+===============+ 869 | 2 | Proxy Forwarding (PF) | This document | 870 +------------+-----------------------+---------------+ 872 Under Registration "Segment Identifier/Label Binding TLV 149" 873 [I-D.ietf-isis-segment-routing-extensions], IANA is requested to 874 assign one bit P-Flag as follows: 876 +============+=================+===============+ 877 | Bit number | Flag Name | Reference | 878 +============+=================+===============+ 879 | 5 | P-Flag | This document | 880 +------------+-----------------+---------------+ 882 Under Registry Name: IS-IS TLV Codepoints, IANA is requested to 883 assign one new TLV value for IS-IS Binding Segment as follows: 885 +========+======================+===============+ 886 | Value | TLV Name | Reference | 887 +========+======================+===============+ 888 | 152 | Binding Segment TLV | This Document | 889 +--------+----------------------+---------------+ 891 7. Acknowledgements 893 The authors would like to thank Peter Psenak, Acee Lindem, Les 894 Ginsberg, Bruno Decraene and Jeff Tantsura for their comments to this 895 work. 897 8. References 899 8.1. Normative References 901 [I-D.ietf-isis-segment-routing-extensions] 902 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 903 Gredler, H., and B. Decraene, "IS-IS Extensions for 904 Segment Routing", draft-ietf-isis-segment-routing- 905 extensions-25 (work in progress), May 2019. 907 [I-D.ietf-ospf-segment-routing-extensions] 908 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 909 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 910 Extensions for Segment Routing", draft-ietf-ospf-segment- 911 routing-extensions-27 (work in progress), December 2018. 913 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 914 Requirement Levels", BCP 14, RFC 2119, 915 DOI 10.17487/RFC2119, March 1997, 916 . 918 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 919 IANA Considerations Section in RFCs", RFC 5226, 920 DOI 10.17487/RFC5226, May 2008, 921 . 923 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 924 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 925 July 2008, . 927 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 928 Scope Link State PDUs (LSPs)", RFC 7356, 929 DOI 10.17487/RFC7356, September 2014, 930 . 932 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 933 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 934 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 935 2015, . 937 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 938 S. Shaffer, "Extensions to OSPF for Advertising Optional 939 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 940 February 2016, . 942 8.2. Informative References 944 [I-D.hegde-spring-node-protection-for-sr-te-paths] 945 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 946 "Node Protection for SR-TE Paths", draft-hegde-spring- 947 node-protection-for-sr-te-paths-07 (work in progress), 948 July 2020. 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-03 (work in 955 progress), March 2020. 957 [I-D.ietf-spring-segment-routing-policy] 958 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 959 P. Mattes, "Segment Routing Policy Architecture", draft- 960 ietf-spring-segment-routing-policy-08 (work in progress), 961 July 2020. 963 [I-D.sivabalan-pce-binding-label-sid] 964 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 965 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 966 in PCE-based Networks.", draft-sivabalan-pce-binding- 967 label-sid-07 (work in progress), July 2019. 969 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 970 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 971 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 972 2009, . 974 Authors' Addresses 976 Zhibo Hu 977 Huawei Technologies 978 Huawei Bld., No.156 Beiqing Rd. 979 Beijing 100095 980 China 982 Email: huzhibo@huawei.com 984 Huaimo Chen 985 Futurewei 986 Boston, MA 987 USA 989 Email: Huaimo.chen@futurewei.com 991 Junda Yao 992 Huawei Technologies 993 Huawei Bld., No.156 Beiqing Rd. 994 Beijing 100095 995 China 997 Email: yaojunda@huawei.com 998 Chris Bowers 999 Juniper Networks 1000 1194 N. Mathilda Ave. 1001 Sunnyvale, CA 94089 1002 USA 1004 Email: cbowers@juniper.net 1006 Yongqing 1007 China Telecom 1008 109, West Zhongshan Road, Tianhe District 1009 Guangzhou 510000 1010 China 1012 Email: zhuyq8@chinatelecom.cn