idnits 2.17.1 draft-hu-spring-segment-routing-proxy-forwarding-03.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.bashandy-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 (April 13, 2019) is 1840 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 557, but not defined == Unused Reference: 'RFC7770' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 823, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 829, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-23 == Outdated reference: A later version (-07) exists of draft-hegde-spring-node-protection-for-sr-te-paths-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-02 == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-06 Summary: 2 errors (**), 0 flaws (~~), 10 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 H. Chen 4 Intended status: Standards Track J. Yao 5 Expires: October 15, 2019 Huawei Technologies 6 C. Bowers 7 Juniper Networks 8 Y. Zhu 9 China Telecom 10 April 13, 2019 12 SR-TE Path Midpoint Protection 13 draft-hu-spring-segment-routing-proxy-forwarding-03 15 Abstract 17 Segment Routing Traffic Engineering (SR-TE) supports the creation of 18 explicit paths using segment lists containing adjacency-sids, node- 19 sids, anycast-sids, and binding-sids. When the segment list defining 20 an SR-TE path contains a node-sid, and the node fails, the network 21 may no longer be able to properly forward traffic on that SR-TE path. 22 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] and 23 [I-D.hegde-spring-node-protection-for-sr-te-paths] describe a 24 mechanism that allows local repair actions on the direct neighbors of 25 the failed node to temporarily route traffic to the node immediately 26 following the failed node on the SR-TE path segment list. However, 27 once the IGP shortest paths have converged, the local repair 28 mechanism is no longer sufficient to continue forwarding traffic 29 using the original segment list of the SR-TE path, since the non- 30 neighbors of the failed node will no longer have a route to reach the 31 failed node. This document describes a mechanism that allows traffic 32 to continue to be forwarded on an SR-TE path for an extended period 33 of time after the failure of a node used in the path's segment list. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on October 15, 2019. 58 Copyright Notice 60 Copyright (c) 2019 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Extensions to IGP for Proxy Forwarding . . . . . . . . . . . 4 77 2.1. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 4 78 2.1.1. Advertising Proxy Forwarding . . . . . . . . . . . . 4 79 2.1.2. Advertising Binding Segment . . . . . . . . . . . . . 7 80 2.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 9 81 2.2.1. Advertising Proxy Forwarding . . . . . . . . . . . . 9 82 2.2.2. Advertising Binding Segment . . . . . . . . . . . . . 11 83 3. Building Proxy Forwarding Table . . . . . . . . . . . . . . . 13 84 3.1. Advertising Proxy Forwarding . . . . . . . . . . . . . . 15 85 3.2. Building Proxy Forwarding Table . . . . . . . . . . . . . 15 86 4. Node Protection for Segment List . . . . . . . . . . . . . . 15 87 4.1. Next Segment is an Adjacency Segment . . . . . . . . . . 16 88 4.2. Next Segment is a Node Segment . . . . . . . . . . . . . 16 89 4.3. Next Segment is a Binding Segment . . . . . . . . . . . . 17 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 95 8.2. Informative References . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 Segment Routing Traffic Engineering (SR-TE) is a technology that 102 implements traffic engineering using Segment Routing. 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 a particular node fails, it would be 107 useful to be able to continue to send traffic on an SR-TE path that 108 uses the node-sid of the failed node for an extended period of time, 109 without having to immediately modify the segment list used at the 110 ingress to the SR-TE path. 112 The first step to achieve this objective is to make the rest of the 113 routers in the network continue to forward traffic using the node-sid 114 of the failed node. If we don't do anything special, once the IGP 115 converges to take into account the failed node, a given router will 116 no longer maintain a route corresponding to the node-sid. Any 117 traffic that arrives at the router with the node-sid of the failed 118 node as the active segment will be dropped. This document addresses 119 this problem by having each neighbor of the failed node advertise its 120 SR proxy forwarding capability. This indicates that the neighbor 121 (the Proxy Forwarder) will forward traffic on behalf of the failed 122 node. A router receiving the SR Proxy Forwarding capability from 123 neighbors of a failed node will send traffic using the node-sid of 124 the failed node to the nearest Proxy Forwarder. 126 Once the affected traffic reaches a Proxy Forwarder, the Proxy 127 Forwarder sends the traffic on the post-failure shortest path to the 128 node immediately following the failed node in the segment list. 129 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] and 130 [I-D.hegde-spring-node-protection-for-sr-te-paths] describe how the 131 immediate neighbors of a failed node can accomplish this by 132 forwarding based on the first two segments in the segment list. The 133 forwarding described in these drafts was originally intended to be 134 used for only a short period of time, to provide fast-reroute 135 protection until the IGP converges. The current document proposes to 136 extend this behavior on the Proxy Forwarder until well after the IGP 137 has converged. 139 If the faulty node is a label adhesion node, the Binding-sids cannot 140 be exchanged to the label stack for its identity, and the traffic 141 will be lost before it reaches the faulty node. 143 In this document, the proxy mechanism is provided in the neighbor 144 node of the faulty node of the forwarding path to implement traffic 145 forwarding after the node with the label adhesion fails on the SR-TE 146 loose path. 148 2. Extensions to IGP for Proxy Forwarding 150 When a node has segment routing proxy forwarding capability, it 151 advertises this capability. The capability indicates that the node 152 has the ability to proxy forward the global sid of each of its 153 neighbors. When an neighbor who advertises its global sid fails, the 154 traffic can be forwarded to the proxy node. 156 2.1. Extensions to OSPF 158 2.1.1. Advertising Proxy Forwarding 160 When a node P has the capability to do a SR proxy forwarding for all 161 its neighboring nodes for protecting the failures of these nodes, 162 node P advertises its SR proxy forwarding capability in its router 163 information opaque LSA, which contains a Router Functional 164 Capabilities TLV of the format as shown in Figure 1. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Type | Length | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Functional Capabilities | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1: Router Functional Capabilities TLV 176 One bit (called PF bit) in the Functional Capabilities field of the 177 TLV is used to indicate node P's SR proxy forwarding capability. 178 When this bit is set to one by node P, it indicates that node P is 179 capable of doing a SR proxy forwarding for its neighboring nodes. 181 For a node X in the network, it learns the prefix/node SID of node N, 182 which is originated and advertised by node N. It creates a proxy 183 prefix/node SID of node N for node P if node P is capable of doing SR 184 proxy forwarding for node N. The proxy prefix/node SID of node N for 185 node P is a copy of the prefix/node SID of node N originated by node 186 N, but stored under (or say, associated with) node P. 188 In normal operations, node X prefers to use the prefix/node SID of 189 node N. When node N fails, node X prefers to use the proxy prefix/ 190 node SID of node N. Thus node X will forward the traffic targeting 191 to node N to node P when node N fails, and node P will do a SR proxy 192 forwarding for node N and forwarding the traffic to its destination 193 without going through node N. After node N fails, node X will keep 194 the proxy prefix/node SID of node N for a given period of time. 196 If node P can not do a SR proxy forwarding for all its neighboring 197 nodes, but for some of them, then it advertises the node SID of each 198 of the nodes as a proxy node SID, indicating that it is able to do 199 proxy forwarding for the node SID. 201 A new TLV, called Proxy Node SIDs TLV, is defined for node P to 202 advertise the node SIDs of some of its neighboring nodes. It has the 203 format as shown in Figure 2. 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type (TBD1) | Length | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Node SID Sub-TLVs | 211 : : 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 2: OSPF Proxy Node SIDs TLV 216 The Type (TBD1) is to be assigned by IANA. The TLV contains a number 217 of Node SID Sub-TLVs. The Length is the total size of the Node SID 218 Sub-TLVs included in the TLV. A Node SID Sub-TLV is the Prefix SID 219 Sub-TLV defined in [I-D.ietf-ospf-segment-routing-extensions]. 221 A proxy forwarding node P originates an Extended Prefix Opaque LSA 222 containing this new TLV. The TLV includes the Node SID Sub-TLVs for 223 the node SIDs of some of P's neighboring nodes. For each of some of 224 P's neighboring nodes, the Node SID Sub-TLV for its prefix/node SID 225 is included the TLV. This prefix/node SID is called a proxy prefix/ 226 node SID. 228 A proxy forwarding node will originate an Extended Prefix Opaque LSA, 229 which includes a Proxy Node SIDs TLV. The format of the LSA is shown 230 in Figure 3. 232 For a proxy forwarding node P, having a number of neighboring nodes, 233 P originates and maintains an Extended Prefix Opaque LSA, which 234 includes a Proxy Node SIDs TLV. The TLV contains the Prefix/Node SID 235 Sub-TLV for each of some of the neighboring nodes after node P 236 creates the corresponding proxy forwarding entries for protecting the 237 failure of some of the neighboring nodes. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | LS age | Options | LS Type | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Opaque Type(7)| Opaque ID | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Advertising Router | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | LS sequence number | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | LS checksum | Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 : TLVs : 254 : (including Proxy Node SIDs TLV) : 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 3: OSPFv2 Extended Prefix Opaque LSA 260 When an neighboring node fails, P maintains the LSA with the TLV 261 containing the Prefix/Node SID Sub-TLV for the neighboring node for a 262 given period of time. After the given period of time, the Prefix/ 263 Node SID Sub-TLV for the neighboring node is removed from the TLV in 264 the LSA and then after a given time the corresponding proxy 265 forwarding entries for protecting the failure of the neighboring node 266 is removed. 268 For a node X in the network, it learns the prefix/node SID of node N 269 and the proxy prefix/node SID of node N. The former is originated 270 and advertised by node N, and the latter is originated and advertised 271 by the proxy forwarding node P of node N. Note that the proxy 272 Prefix/Node SID Sub-TLV for node N does not contain a prefix of node 273 N, and the prefix is the prefix associated with the prefix/node SID 274 of node N originated by node N. 276 In normal operations, node X prefers to use the prefix/node SID of 277 node N. When node N fails, node X prefers to use the proxy prefix/ 278 node SID of node N. Thus node X will forward the traffic targeting 279 to node N to node P when node N fails, and node P will do a proxy 280 forwarding for node N and forwarding the traffic to its destination 281 without going through node N. 283 2.1.2. Advertising Binding Segment 285 For a binding segment (or binding for short) on a node A, which 286 consists of a binding SID and a list of segments, node A advertises 287 an LSA containing the binding (i.e., the binding SID and the list of 288 the segments). The LSA is advertised only to each of the node A's 289 neighboring nodes. For OSPFv2, the LSA is a opaque LSA of LS type 9 290 (i.e., a link local scope LSA). 292 A binding segment is represented by binding segment TLV of the format 293 as shown in Figure 4. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type (TBD2) | Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Reserved |BindingSID Type| SIDs Type | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 ~ Binding SID Sub-TLV/value ~ 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 ~ SID Sub-TLVs/values ~ 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 4: OSPF Binding Segment TLV 309 It comprises a binding SID and a list of segments (SIDs). The fields 310 of this TLV are defined as follows: 312 Type: 2 octets, its value (TBD2) is to be assigned by IANA. 314 Length: 2 octets, its value is (4 + length of Sub-TLVs/values). 316 Binding SID Type (BT): 1 octet indicates whether the binding SID is 317 represented by a Sub-TLV or a value included in the TLV. For the 318 binding SID represented by a value, it indicates the type of binding 319 SID. The following BT values are defined: 321 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., Binding 322 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 323 TLV defined in [I-D.ietf-ospf-segment-routing-extensions]. BT != 0 324 indicates that the binding SID is represented by a value. 326 o BT = 1: The binding SID value is a label, which is represented by 327 the 20 rightmost bits. The length of the value is 3 octets. 329 o BT = 2: The binding SID value is a 32-bit SID. The length of the 330 value is 4 octets. 332 SIDs Type (ST): 1 octet indicates whether the list of segments (SIDs) 333 are represented by Sub-TLVs or values included in the TLV. For the 334 SIDs represented by values, it indicates the type of SIDs. The 335 following ST values are defined: 337 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 338 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 339 TLV or a SID/Label Sub-TLV defined in 340 [I-D.ietf-ospf-segment-routing-extensions]. ST != 0 indicates that 341 the SIDs are represented by values. 343 o ST = 1: Each of the SID values is a label, which is represented by 344 the 20 rightmost bits. The length of the value is 3 octets. 346 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 347 value is 4 octets. 349 The opaque LSA of LS Type 9 containing the binding segment (i.e., the 350 binding SID and the list of the segments) has the format as shown in 351 Figure 5. It may have Opaque Type of x (the exact type is to be 352 assigned by IANA) for Binding Segment Opaque LSA. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | LS age | Options | LS Type (9) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Opaque Type(x)| Opaque ID | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Advertising Router | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | LS sequence number | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | LS checksum | Length | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | | 368 : Binding Segment TLVs : 369 | | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 5: OSPFv2 Binding Segment Opaque LSA 374 For every binding on a node A, the LSA originated by A contains a 375 binding segment TLV for it. 377 For node A running OSPFv3, it originates a link-local scoping LSA of 378 a new LSA function code (TBD3) containing binding segment TLVs for 379 the bindings on it. The format of the LSA is illustrated in 380 Figure 6. 382 0 1 2 3 383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | LS age |0|0|0| BS-LSA (TBD3) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Link State ID | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Advertising Router | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | LS Sequence Number | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | LS checksum | Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 : Binding Segment TLVs : 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 6: OSPFv3 Binding Segment Opaque LSA 402 The U-bit is set to 0, and the scope is set to 00 for link-local 403 scoping. 405 2.2. Extensions to IS-IS 407 2.2.1. Advertising Proxy Forwarding 409 When a node P has the capability to do a SR proxy forwarding for its 410 neighboring nodes for protecting the failures of them, node P 411 advertises its SR proxy forwarding capability in its LSP, which 412 contains a Router Capability TLV of Type 242 including a SR 413 capabilities sub-TLV of sub-Type 2. 415 One bit (called PF bit as shown in Figure 7) in the Flags field of 416 the SR capabilities sub-TLV is defined to indicate node P's SR proxy 417 forwarding capability. When this bit is set to one by node P, it 418 indicates that node P is capable of doing a SR proxy forwarding for 419 its neighboring nodes. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Type (2) | Length | Flags | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Range | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 // SID/Label Sub-TLV (variable) // 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 0 1 2 3 4 5 6 7 432 +--+--+--+--+--+--+--+--+ 433 | I| V|PF| | 434 +--+--+--+--+--+--+--+--+ 435 Flags 437 Figure 7: SR Capabilities sub-TLV 439 If node P can not do a SR proxy forwarding for all its neighboring 440 nodes, but for some of them, then it advertises the node SID of each 441 of the nodes as a proxy node SID, indicating that it is able to do 442 proxy forwarding for the node SID. 444 The IS-IS SID/Label Binding TLV (suggested value 149) is defined in 445 [I-D.ietf-isis-segment-routing-extensions]. A Proxy Forwarder uses 446 the SID/Label Binding TLV to advertise the node Sid of its 447 neighboring node. The Flags field of the SID/Label Binding TLV is 448 extended to include a P flag as shown in Figure 8. The prefix/node 449 SID in prefix/node Sid Sub-TLV included in SID/Label Binding TLV is 450 identified as a proxy forwarding prefix/node SID. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type | Length | Flags | RESERVED | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Range | Prefix Length | Prefix | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 // Prefix (continued, variable) // 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | SubTLVs (variable) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 0 1 2 3 4 5 6 7 465 +-+-+-+-+-+-+-+-+ 466 |F|M|S|D|A|P| | 467 +-+-+-+-+-+-+-+-+ 468 Flags 470 Figure 8: SID/Label Binding TLV 472 Where: 474 P-Flag: Proxy forwarding flag. If set, this prefix/node Sid is 475 advertised by the proxy node. This TLV is used to announce that the 476 node has the ability to proxy forward the prefix/node Sid. 478 When the P-flag is set in the SID/Label Binding TLV, the following 479 usage rules apply. 481 The Range, Prefix Length and Prefix field are not used. They should 482 be set to zero on transmission and ignored on receipt. 484 SID/Label Binding TLV contains a number of prefix/node SID Sub-TLVs. 485 The TLV advertised by a proxy forwarding node P contains prefix/node 486 SID Sub-TLVs for the node SIDs of P's neighbor nodes. Each of the 487 Sub-TLVs is a prefix/node SID Sub-TLV defined in 488 [I-D.ietf-isis-segment-routing-extensions]. From the SID in a 489 prefix/node SID Sub-TLV advertised by the Proxy Forwarding node, its 490 prefix can be obtained through matching corresponding prefix/node SID 491 advertised by the neighbor/protected node using TLV-135 (or 235, 236, 492 or 237) together with the prefix/node SID Sub-TLV. 494 2.2.2. Advertising Binding Segment 496 [I-D.ietf-spring-segment-routing-policy] has defined the usage of 497 binding-sid. For supporting binding sid proxy forwarding, a new IS- 498 IS TLV, called Binding Segment TLV, is defined. It contains a 499 binding SID and a list of segments (SIDs). This TLV may be 500 advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link 501 State PDUs (CS-LSP) [RFC7356]. Its format is shown in Figure 9. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type | Length |BindingSID Type| SIDs Type | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 ~ Binding SID value/Sub-TLV ~ 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 ~ SID values/Sub-TLVs ~ 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Figure 9: IS-IS Binding Segment TLV 515 The fields of this TLV are defined as follows: 517 Type: 1 octet Suggested value 152 (to be assigned by IANA) 519 Length: 1 octet (2 + length of Sub-TLVs/values). 521 Binding SID Type (BT): 1 octet indicates whether the binding SID is 522 represented by a Sub-TLV or a value included in the TLV. For the 523 binding SID represented by a value, it indicates the type of binding 524 SID. The following BT values are defined: 526 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., binding 527 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 528 TLV defined in [I-D.ietf-isis-segment-routing-extensions]. BT != 0 529 indicates that the binding SID is represented by a value. 531 o BT = 1: The binding SID value is a label, which is represented by 532 the 20 rightmost bits. The length of the value is 3 octets. 534 o BT = 2: The binding SID value is a 32-bit SID. The length of the 535 value is 4 octets. 537 SIDs Type (ST): 1 octet indicates whether the SIDs are represented by 538 Sub-TLVs or values included in the TLV. For the SIDs represented by 539 values, it indicates the type of SIDs. The following ST values are 540 defined: 542 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 543 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 544 TLV or a SID/Label Sub-TLV defined in 545 [I-D.ietf-isis-segment-routing-extensions]. ST != 0 indicates that 546 the SIDs are represented by values. 548 o ST = 1: Each of the SID values is a label, which is represented by 549 the 20 rightmost bits. The length of the value is 3 octets. 551 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 552 value is 4 octets. 554 3. Building Proxy Forwarding Table 556 Figure 10 is used to illustrate the SR proxy forwarding approach. 557 Each node N has SRGB = [N000-N999]. RT1 is an ingress node of SR 558 domain. RT3 is a failure node. RT2 is a Point of Local Repair (PLR) 559 node, i.e., a proxy forwarding node. Three label stacks are shown in 560 the figure. Label Stack 1 uses only adjacency-SIDs and represents 561 the path RT1->RT2->RT3->RT4->RT5. Label Stack 2 uses only node-SIDs 562 and represents the ECMP-aware path RT1->RT3->RT4->RT5. Label Stack 3 563 uses a node-SID and a binding SID. The Binding-SID with label=100 at 564 RT3 represents the ECMP-aware path RT3->RT4->RT5. So Label Stack 3, 565 which consists of the node-SID for RT3 following by Binding-SID=100, 566 represents the ECMP-aware path RT1->RT3->RT4->RT5. 568 Node Sid:2 Node Sid:3 569 +-----+ +-----+ 570 | |----------+ | 571 / |RT2 | | RT3 |\ 572 / +-----+ +-----+ \ 573 / | \ /| \ 574 / | \ / | \ 575 / | \ / | \ 576 / | \ / | \ 577 / | \ / | \ 578 Node Sid:1 | \ / | \Node Sid:4 Node Sid:5 579 +-----+ | \ / | +-----+ +-----+ 580 | | | X | | |-------| | 581 | RT1 | | / \ | | RT4 | | RT5 | 582 +-----+ | / \ | +-----+ +-----+ 583 \ | / \ | / 584 \ | / \ | / 585 \ | / \ | / 586 \ | / \ | / 587 \ | / \| / 588 \ |/ | / 589 \ +-----+ +-----+ / 590 \ | | | |/ 591 \ | RT6 |-----------| RT7 | 592 +-----+ +-----+ 593 Node Sid:6 Node Sid:7 595 +-----------------+ +--------------+ 596 | Node SRGB | | Adj-Sid | +-------+ +-------+ +-------+ 597 +-----------------+ +--------------+ |Label | |Label | |Label | 598 | RT1:[1000-1999] | |RT1->RT2:10012| |Stack 1| |Stack 2| |Stack 3| 599 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 600 | RT2:[2000-2999] | |RT2->RT3:20023| | 10012 | | 1003 | | 1003 | 601 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 602 | RT3:[3000-3999] | |RT3->RT6:30036| | 20023 | | 3004 | | 100 | 603 +-----------------+ +--------------+ +-------+ +-------+ +-------+ 604 | RT4:[4000=4999] | |RT3->RT7:30037| | 30034 | | 4005 | 100 is 605 +-----------------+ +--------------+ +-------+ +-------+ binding SID 606 | RT5:[5000-5999] | |RT3->RT4:30034| | 40045 | to 607 +-----------------+ +--------------+ +-------+ {30034,40045} 608 | RT6:[6000-6999] | |RT7->RT4:70074| 609 +-----------------+ +--------------+ 610 | RT7:[7000-7999] | |RT4->RT5:40045| 611 +-----------------+ +--------------+ 613 Figure 10: Topology of SR-TE Path 615 3.1. Advertising Proxy Forwarding 617 If the Point of Local Repair (PLR), for example, RT2, has the 618 capability to do a SR proxy forwarding for all its neighboring nodes, 619 it must advertises this capability. If the PLR can not do a SR proxy 620 forwarding for all its neighboring nodes, but for some of them, for 621 example, RT3, then it uses proxy Node SIDs TLV to advertise the 622 prefix-sid learned from RT3. The TLV contains the Sub-TLV/value for 623 the prefix/node sid of RT3 as a proxy SID. When RT3 fails, RT2 needs 624 to maintain the Sub-TLV/value for a period of time. When the proxy 625 forwarding table corresponding to the fault node is deleted (see 626 section 3.2), the Sub-TLV/value is withdrawn. The nodes in the 627 network (for example, RT1) learn the prefix/node Sid TLV advertised 628 by RT3 and the proxy Node SIDs TLV advertised by RT2. When RT3 is 629 normal, the nodes prefer prefix/node Sid TLV. When the RT3 fails, 630 the proxy prefix/node SIDs TLV advertised by RT2 is preferred. 632 3.2. Building Proxy Forwarding Table 634 A SR proxy node P needs to build an independent proxy forwarding 635 table for each neighbor N. The proxy forwarding table for node N 636 contains the following information: 638 1: Node N's SRGB range and the difference between the SRGB start 639 value of node P and that of node N; 641 2: All adjacency-SID of N and Node-SID of the node pointed to by node 642 N's adjacency-SID. 644 3: The binding-SID of N and the label stack associated with the 645 binding-SID. 647 Node P (PLR) uses a proxy forwarding table based on the next segment 648 to find a node N as a backup forwarding entry to the adj-SID and 649 Node-SID of node N. When node N fails, the proxy forwarding table 650 needs to be maintained for a period of time, which is recommended for 651 30 minutes. 653 Node RT3 in the topology of Figure 1 is node N, and node RT2 is node 654 P (PLR). RT2 builds the proxy forwarding table for RT3. The 655 structure of the table and how to build the table is a local 656 implementation issue. 658 4. Node Protection for Segment List 660 Segment Routing Traffic Engineering supports the creation of explicit 661 paths using adjacency-sids, node-sids, and binding-sids. The label 662 stack is a combination of one or more of adjacency-sids, node-sids, 663 and binding-sids. This Section shows how a proxy node uses the SR 664 proxy forwarding mechanism to protect traffic to the destination node 665 when the next segment of label stack is adjacency-sids, node-sids, or 666 binding-sids, respectively. 668 4.1. Next Segment is an Adjacency Segment 670 As shown in Figure 1, Label Stack 1 {10012, 20023, 30034, 40045} 671 represents SR-TE strict explicit path RT1->RT2->RT3->RT4->RT5. When 672 RT3 fails, node RT2 acts as a PLR, and uses next adj-SID (30034) of 673 the label stack to lookup the proxy forwarding table built by RT2 674 locally for RT3. The path returned is the label forwarding path to 675 RT3's next hop node RT4, which bypasses RT3. The specific steps are 676 as follows: 678 a. RT1 pops top adj-SID 10012, and forwards the packet to RT2; 680 b. RT2 uses the label 20023 to identify the next hop node RT3, which 681 has failed. RT2 pops label 20023 and queries the Proxy Forwarding 682 Table corresponding to RT3 with label 30034. The Proxy Forwarding 683 Table corresponding to RT3 returns an outgoing interface and label 684 stack representing a path to RT4 that does not pass through RT3. In 685 this case, outgoing interface to RT7 with label stack 7004, satisfies 686 this requirement. 688 c. So the packet leaves RT2 out the interface to RT7 with label 689 stack {7004, 40045}. RT4 forwards it to RT4, where the original path 690 is rejoined. 692 d. RT2 forwards packets to RT7. RT7 queries the local routing table 693 to forward the packet to RT4. 695 4.2. Next Segment is a Node Segment 697 As shown in Figure 1, Label Stack 2 {1003, 3004, 4005} represents SR- 698 TE loose path RT1->RT3->RT4->RT5, where 1003 is the node SID of RT3. 700 When the node RT3 fails, the proxy forwarding TLV advertised by the 701 RT2 is preferred to direct the traffic of the RT1 to the PLR node 702 RT2. Node RT2 acts as a PLR node and queries the proxy forwarding 703 table locally built for RT3. The path returned is the label 704 forwarding path to RT3's next hop node RT4, which bypasses RT3. The 705 specific steps are as follows: 707 a. RT1 swaps label 1003 to out-label 2003 to RT3. 709 b. RT2 receives the label forwarding packet whose top label of label 710 stack is 2003, and searches for the local Routing Table, the behavior 711 found is to lookup Proxy Forwarding table due to RT3 failure. 713 c. RT2 uses 2003 as the in-label to lookup Proxy Forwarding table, 714 and the query result is forwarding the packet to RT4. 716 d. Then RT2 querries the Routing Table to RT4, using the primary or 717 backup path to RT4. The next hop is RT7. 719 e. RT2 forwards the packet to RT7. RT7 queries the local routing 720 table to forward the packet to RT4. 722 f. After RT1 convergences, node SID 1003 is preferred to the proxy 723 SID implied/advertised by RT2. 725 4.3. Next Segment is a Binding Segment 727 As shown in Figure 1, Label Stack 3 {1003, 100} represents SR-TE 728 loose path RT1->RT3->RT4->RT5, where 100 is a Binding-Sid, which 729 represents segment list {30034, 40045}. 731 When the node RT3 fails, the proxy forwarding SID implied or 732 advertised by the RT2 is preferred to forward the traffic of the RT1 733 to the PLR node RT2. Node RT2 acts as a PLR node and uses Binding- 734 SID to query the proxy forwarding table locally built for RT3. The 735 path returned is the label forwarding path to RT3's next hop node 736 (RT4), which bypasses RT3. The specific steps are as follows: 738 a. RT1 swaps label 1003 to out-label 2003 to RT3. 740 b. RT2 receives the label forwarding packet whose top label of label 741 stack is 2003, and searches for the local Routing Table, the behavior 742 found is to lookup Proxy Forwarding table due to RT3 failure. 744 c. RT2 uses Binding-sid:100 (label 2003 has pop) as the in-label to 745 lookup the Next Label record of the Proxy Forwarding Table, the 746 behavior found is to swap to Segment list {30034, 40045}. 748 d. RT2 swaps Binding-sid:100 to Segment list {30034, 40045}, and 749 uses the 3034 to lookup the Next Label record of the Proxy Forwarding 750 table again. The behavior found is to forward the packet to RT4. 752 e. RT2 queries the Routing Table to RT4, using primary or backup 753 path to RT4. The next hop is RT7. 755 f. RT2 forwards packets to RT7. RT7 queries the local routing table 756 to forward the packet to RT4. 758 5. Security Considerations 760 TBD 762 6. IANA Considerations 764 TBD 766 7. Acknowledgements 768 The authors would like to thank Peter Psenak, Acee Lindem and Les 769 Ginsberg for their comments to this work. 771 8. References 773 8.1. Normative References 775 [I-D.ietf-isis-segment-routing-extensions] 776 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 777 Gredler, H., and B. Decraene, "IS-IS Extensions for 778 Segment Routing", draft-ietf-isis-segment-routing- 779 extensions-23 (work in progress), March 2019. 781 [I-D.ietf-ospf-segment-routing-extensions] 782 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 783 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 784 Extensions for Segment Routing", draft-ietf-ospf-segment- 785 routing-extensions-27 (work in progress), December 2018. 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, 789 DOI 10.17487/RFC2119, March 1997, 790 . 792 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 793 Scope Link State PDUs (LSPs)", RFC 7356, 794 DOI 10.17487/RFC7356, September 2014, 795 . 797 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 798 S. Shaffer, "Extensions to OSPF for Advertising Optional 799 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 800 February 2016, . 802 8.2. Informative References 804 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 805 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 806 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 807 Camarillo, "Topology Independent Fast Reroute using 808 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 809 lfa-05 (work in progress), October 2018. 811 [I-D.hegde-spring-node-protection-for-sr-te-paths] 812 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 813 "Node Protection for SR-TE Paths", draft-hegde-spring- 814 node-protection-for-sr-te-paths-04 (work in progress), 815 October 2018. 817 [I-D.ietf-spring-segment-routing-policy] 818 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 819 bogdanov@google.com, b., and P. Mattes, "Segment Routing 820 Policy Architecture", draft-ietf-spring-segment-routing- 821 policy-02 (work in progress), October 2018. 823 [I-D.sivabalan-pce-binding-label-sid] 824 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 825 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 826 in PCE-based Networks.", draft-sivabalan-pce-binding- 827 label-sid-06 (work in progress), February 2019. 829 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 830 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 831 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 832 2009, . 834 Authors' Addresses 836 Zhibo Hu 837 Huawei Technologies 838 Huawei Bld., No.156 Beiqing Rd. 839 Beijing 100095 840 China 842 Email: huzhibo@huawei.com 843 Huaimo Chen 844 Huawei Technologies 845 Boston, MA 846 USA 848 Email: Huaimo.chen@huawei.com 850 Junda Yao 851 Huawei Technologies 852 Huawei Bld., No.156 Beiqing Rd. 853 Beijing 100095 854 China 856 Email: yaojunda@huawei.com 858 Chris Bowers 859 Juniper Networks 860 1194 N. Mathilda Ave. 861 Sunnyvale, CA 94089 862 USA 864 Email: cbowers@juniper.net 866 Yongqing 867 China Telecom 868 109, West Zhongshan Road, Tianhe District 869 Guangzhou 510000 870 China 872 Email: zhuyq@gsta.com