idnits 2.17.1 draft-hc-lsr-sr-proxy-fw-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 (6 March 2022) is 782 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) == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 594, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-18 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 Summary: 1 error (**), 0 flaws (~~), 5 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: 7 September 2022 Futurewei 6 J. Yao 7 Huawei Technologies 8 C. Bowers 9 Juniper Networks 10 Y. Zhu 11 China Telecom 12 Y. Liu 13 China Mobile 14 6 March 2022 16 LSR for SR Proxy Forwarding 17 draft-hc-lsr-sr-proxy-fw-00 19 Abstract 21 This document describes extensions to OSPF and IS-IS to support SR 22 proxy forwarding mechanism for fast protecting the failure of a node 23 with segments on a SR-TE path. The segments of the node include 24 adjacency, node or binding segments. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 7 September 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Extensions to IGP for Proxy Forwarding . . . . . . . . . . . 3 67 2.1. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 3 68 2.1.1. Advertising Proxy Forwarding . . . . . . . . . . . . 3 69 2.1.2. Advertising Binding Segment . . . . . . . . . . . . . 5 70 2.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 8 71 2.2.1. Advertising Proxy Forwarding . . . . . . . . . . . . 8 72 2.2.2. Advertising Binding Segment . . . . . . . . . . . . . 9 73 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 4.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.3. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 6.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 [I-D.hu-spring-segment-routing-proxy-forwarding] describes a SR proxy 87 forwarding for protection. Each neighbor of a possible failed node 88 advertises its SR proxy forwarding capability when it has the 89 capability. This capability indicates that the neighbor (the Proxy 90 Forwarder) will forward traffic on behalf of the failed node. A 91 router receiving the capability from the neighbors of a failed node 92 will send traffic using the node-SID of the failed node to the 93 nearest Proxy Forwarder after the IGP converges on the failure. 95 Once the affected traffic reaches a Proxy Forwarder, it sends the 96 traffic on the post-failure shortest path to the node immediately 97 following the failed node in the segment list. 99 For a binding segment of a possible failed node, the node advertises 100 the information about the binding segment, including the binding SID 101 and the list of SIDs associated with the binding SID, to its direct 102 neighbors only. Note that the information is not advertised in the 103 network domain. 105 After the node fails and the IGP converges on the failure, the 106 traffic with the binding SID of the failed node will reach its 107 neighbor having SR Proxy Forwarding capability. Once receiving the 108 traffic, the neighbor swaps the binding SID with the list of SIDs 109 associated with the binding SID and sends the traffic along the post- 110 failure shortest path to the first node in the segment list. 112 2. Extensions to IGP for Proxy Forwarding 114 This section defines extensions to IGP for advertising the SR proxy 115 forwarding capability of a node in a network domain and the 116 information about each binding segment (including its binding SID and 117 the list of SIDs associated) of a node to its direct neighbors. 119 2.1. Extensions to OSPF 121 2.1.1. Advertising Proxy Forwarding 123 When a node P has the capability to do a SR proxy forwarding for its 124 neighboring nodes for protecting the failures of these nodes, P 125 advertises its capability for these nodes. The mirror SID 126 [RFC8402][RFC8667] for a node N (Neighbor of P) advertised by P 127 indicates the capability of P for N. 129 Alternatively, P advertises its capability in its router information 130 opaque LSA with Router Functional Capabilities TLV [RFC7770]. One 131 bit (called PF bit) in the Functional Capabilities field of the TLV 132 is used to indicate node P's capability. When this bit is set to one 133 by node P, it indicates that node P is capable of doing a SR proxy 134 forwarding for its neighboring nodes. 136 For a node X in the network, it learns the prefix/node SID of node N, 137 which is originated and advertised by node N. It creates a proxy 138 prefix/node SID of node N for node P if node P is capable of doing SR 139 proxy forwarding for node N. The proxy prefix/node SID of node N for 140 node P is a copy of the prefix/node SID of node N originated by node 141 N, but stored under (or say, associated with) node P. The route to 142 the proxy prefix/node SID is through proxy forwarding capable nodes. 144 In normal operations, node X prefers to use the prefix/node SID of 145 node N. When node N fails, node X prefers to use the proxy prefix/ 146 node SID of node N. Thus node X will forward the traffic targeting 147 to the prefix/node SID of node N to node P when node N fails, and 148 node P will do a SR proxy forwarding for node N and forward the 149 traffic towards its final destination without going through node N. 151 Note that the behaviors of normal IP forwarding and routing 152 convergences in a network are not changed at all by the SR proxy 153 forwarding. For example, the next hop used by BGP is an IP address 154 (or prefix). The IGP and BGP converge in normal ways for changes in 155 the network. The packet with its IP destination to this next hop is 156 forwarded according to the IP forwarding table (FIB) derived from IGP 157 and BGP routes. 159 If node P can not do a SR proxy forwarding for all its neighboring 160 nodes, but for some of them, then it advertises the node SID of each 161 of the nodes as a proxy node SID, indicating that it is able to do 162 proxy forwarding for the node SID. 164 A new TLV, called Proxy Node SIDs TLV, is defined for node P to 165 advertise the node SIDs of some of its neighboring nodes. It has the 166 format as shown in Figure 1. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type (TBD1) | Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Node SID Sub-TLVs | 174 : : 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 1: OSPF Proxy Node SIDs TLV 179 The Type (TBD1) is to be assigned by IANA. The TLV contains a number 180 of Node SID Sub-TLVs. The Length is the total size of the Node SID 181 Sub-TLVs included in the TLV. A Node SID Sub-TLV is the Prefix SID 182 Sub-TLV defined in [RFC8665]. 184 A proxy forwarding node P originates an Extended Prefix Opaque LSA 185 containing this new TLV. The TLV includes the Node SID Sub-TLVs for 186 the node SIDs of some of P's neighboring nodes. For each of some of 187 P's neighboring nodes, the Node SID Sub-TLV for its prefix/node SID 188 is included the TLV. This prefix/node SID is called a proxy prefix/ 189 node SID. 191 When an neighboring node fails, P maintains the LSA with the TLV 192 containing the Prefix/Node SID Sub-TLV for the neighboring node for a 193 given period of time. After the given period of time, the Prefix/ 194 Node SID Sub-TLV for the neighboring node is removed from the TLV in 195 the LSA and then after a given time the corresponding proxy 196 forwarding entries for protecting the failure of the neighboring node 197 is removed. 199 2.1.2. Advertising Binding Segment 201 For a binding segment (or binding for short) on a node A, which 202 consists of a binding SID and a list of segments, node A advertises 203 an LSA containing the binding (i.e., the binding SID and the list of 204 the segments). The LSA is advertised only to each of the node A's 205 neighboring nodes. For OSPFv2, the LSA is a opaque LSA of LS type 9 206 (i.e., a link local scope LSA). 208 A binding segment is represented by binding segment TLV of the format 209 as shown in Figure 2. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type (TBD2) | Length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Reserved |BindingSID Type| SIDs Type | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 ~ Binding SID Sub-TLV/value ~ 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 ~ SID Sub-TLVs/values ~ 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 2: OSPF Binding Segment TLV 225 It comprises a binding SID and a list of segments (SIDs). The fields 226 of this TLV are defined as follows: 228 Type: 2 octets, its value (TBD2) is to be assigned by IANA. 230 Length: 2 octets, its value is (4 + length of Sub-TLVs/values). 232 Binding SID Type (BT): 1 octet indicates whether the binding SID is 233 represented by a Sub-TLV or a value included in the TLV. For the 234 binding SID represented by a value, it indicates the type of binding 235 SID. The following BT values are defined: 237 o BT = 0: The binding SID is represented by a Sub-TLV (i.e., Binding 238 SID Sub-TLV) in the TLV. A binding SID Sub-TLV is a SID/Label Sub- 239 TLV defined in [RFC8665]. BT != 0 indicates that the binding SID is 240 represented by a value. 242 o BT = 1: The binding SID value is a label, which is represented by 243 the 20 rightmost bits. The length of the value is 3 octets. 245 o BT = 2: The binding SID value is a 32-bit SID. The length of the 246 value is 4 octets. 248 SIDs Type (ST): 1 octet indicates whether the list of segments (SIDs) 249 are represented by Sub-TLVs or values included in the TLV. For the 250 SIDs represented by values, it indicates the type of SIDs. The 251 following ST values are defined: 253 o ST = 0: The SIDs are represented by Sub-TLVs (i.e., SID Sub-TLVs) 254 in the TLV. A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub- 255 TLV or a SID/Label Sub-TLV defined in [RFC8665]. ST != 0 indicates 256 that the SIDs are represented by values. 258 o ST = 1: Each of the SID values is a label, which is represented by 259 the 20 rightmost bits. The length of the value is 3 octets. 261 o ST = 2: Each of the SID values is a 32-bit SID. The length of the 262 value is 4 octets. 264 The opaque LSA of LS Type 9 containing the binding segment (i.e., the 265 binding SID and the list of the segments) has the format as shown in 266 Figure 3. It may have Opaque Type of x (the exact type is to be 267 assigned by IANA) for Binding Segment Opaque LSA. 269 0 1 2 3 270 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | LS age | Options | LS Type (9) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Opaque Type(x)| Opaque ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Advertising Router | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | LS sequence number | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | LS checksum | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 : Binding Segment TLVs : 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 3: OSPFv2 Binding Segment Opaque LSA 289 For every binding on a node A, the LSA originated by A contains a 290 binding segment TLV for it. 292 For node A running OSPFv3, it originates a link-local scoping LSA of 293 a new LSA function code (TBD3) containing binding segment TLVs for 294 the bindings on it. The format of the LSA is illustrated in 295 Figure 4. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | LS age |0|0|0| BS-LSA (TBD3) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Link State ID | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Advertising Router | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | LS Sequence Number | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | LS checksum | Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 : Binding Segment TLVs : 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 4: OSPFv3 Binding Segment Opaque LSA 317 The U-bit is set to 0, and the scope is set to 00 for link-local 318 scoping. 320 2.2. Extensions to IS-IS 322 2.2.1. Advertising Proxy Forwarding 324 When a node P has the capability to do a SR proxy forwarding for its 325 neighboring nodes, P advertises its capability in its LSP with a 326 Router Capability TLV of Type 242 including a SR capabilities sub-TLV 327 of sub-Type 2. 329 One bit (called PF bit) in the Flags field of the SR capabilities 330 sub-TLV is defined to indicate node P's capability. When this bit is 331 set to one by node P, it indicates that node P is capable of doing a 332 SR proxy forwarding for its neighboring nodes. 334 If node P can not do a SR proxy forwarding for all its neighboring 335 nodes, but for some of them, then it advertises the node SID of each 336 of the nodes as a proxy node SID, indicating that it is able to do 337 proxy forwarding for the node SID. 339 The IS-IS SID/Label Binding TLV (suggested value 149) is defined in 340 [RFC8667]. A Proxy Forwarder uses the SID/Label Binding TLV to 341 advertise the node SID of its neighboring node. The Flags field of 342 the SID/Label Binding TLV is extended to include a P flag as shown in 343 Figure 5. The prefix/node SID in prefix/node SID Sub-TLV included in 344 SID/Label Binding TLV is identified as a proxy forwarding prefix/node 345 SID. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Type | Length | Flags | RESERVED | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Range | Prefix Length | Prefix | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 // Prefix (continued, variable) // 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | SubTLVs (variable) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 0 1 2 3 4 5 6 7 360 +-+-+-+-+-+-+-+-+ 361 |F|M|S|D|A|P| | 362 +-+-+-+-+-+-+-+-+ 363 Flags 365 Figure 5: SID/Label Binding TLV 367 Where: 369 P-Flag: Proxy forwarding flag. If set, this prefix/node SID is 370 advertised by the proxy node. This TLV is used to announce that the 371 node has the ability to proxy forward the prefix/node SID. 373 When the P-flag is set in the SID/Label Binding TLV, the following 374 usage rules apply. 376 The Range, Prefix Length and Prefix field are not used. They should 377 be set to zero on transmission and ignored on receipt. 379 SID/Label Binding TLV contains a number of prefix/node SID Sub-TLVs. 380 The TLV advertised by a proxy forwarding node P contains prefix/node 381 SID Sub-TLVs for the node SIDs of P's neighbor nodes. Each of the 382 Sub-TLVs is a prefix/node SID Sub-TLV defined in [RFC8667]. From the 383 SID in a prefix/node SID Sub-TLV advertised by the Proxy Forwarding 384 node, its prefix can be obtained through matching corresponding 385 prefix/node SID advertised by the neighbor/protected node using 386 TLV-135 (or 235, 236, or 237) together with the prefix/node SID Sub- 387 TLV. 389 2.2.2. Advertising Binding Segment 391 For supporting binding SID proxy forwarding, a new IS-IS TLV, called 392 Binding Segment TLV, is defined. It contains a binding SID and a 393 list of segments (SIDs). This TLV is advertised in Circuit Scoped 394 Link State PDUs (CS-LSP) [RFC7356]. Its format is shown in 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 | Type | Length |BindingSID Type| SIDs Type | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 ~ Binding SID value/Sub-TLV ~ 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 ~ SID values/Sub-TLVs ~ 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure 6: IS-IS Binding Segment TLV 408 The fields of this TLV are defined as follows: 410 Type: 1 octet Suggested value 152 (to be assigned by IANA) 412 Length: 1 octet (2 + length of Sub-TLVs/values). 414 The other fields are the same as those in Figure 2. 416 3. Security Considerations 418 The extensions to OSPF and IS-IS described in this document result in 419 two types of behaviors in data plane when a node in a network fails. 420 One is that for a node, which is a upstream (except for the direct 421 upstream) node of the failed node along a SR-TE path, it continues to 422 send the traffic to the failed node along the SR-TE path for an 423 extended period of time. The other is that for a node, which is the 424 direct upstream node of the failed node, it fast re-routes the 425 traffic around the failed node to the direct downstream node of the 426 failed node along the SR-TE path. These behaviors are internal to a 427 network and should not cause extra security issues. 429 4. IANA Considerations 431 4.1. OSPFv2 433 Under Subregistry Name "OSPF Router Functional Capability Bits" 434 within the "Open Shortest Path First v2 (OSPFv2) Parameters" 435 [RFC7770], IANA is requested to assign one bit for Proxy Forwarding 436 Capability as follows: 438 +============+==================+===================+ 439 | Bit number | Capability Name | Reference | 440 +============+==================+===================+ 441 | 31 | Proxy Forwarding | This document | 442 +------------+------------------+-------------------+ 444 Under Registry Name "OSPFv2 Extended Prefix Opaque LSA TLVs" 445 [RFC7684], IANA is requested to assign one new TLV value for OSPF 446 Proxy Node SIDs as follows: 448 +============+=====================+================+ 449 | TLV Value | TLV Name | Reference | 450 +============+=====================+================+ 451 | 2 | Proxy Node SIDs TLV | This document | 452 +------------+---------------------+----------------+ 454 Under Registry Name "Opaque Link-State Advertisements (LSA) Option 455 Types" [RFC5250], IANA is requested to assign new Opaque Type 456 registry values for Binding Segment LSA as follows: 458 +================+==================+================+ 459 | Registry Value | Opaque Type | Reference | 460 +================+==================+================+ 461 | 10 | Binding Segment | This document | 462 +----------------+------------------+----------------+ 464 IANA is requested to create and maintain new registries: 466 o OSPFv2 Binding Segment Opaque LSA TLVs 468 Initial values for the registry are given below. The future 469 assignments are to be made through IETF Review [RFC5226]. 471 Value TLV Name Definition 472 ----- ----------------------- ---------- 473 0 Reserved 474 1 Binding Segment TLV This Document 475 2-32767 Unassigned 476 32768-65535 Reserved 478 4.2. OSPFv3 480 Under Registry Name "OSPFv3 LSA Function Codes", IANA is requested to 481 assign new registry values for Binding Segment LSA as follows: 483 +========+========================+================+ 484 | Value | LSA Function Code Name | Reference | 485 +========+========================+================+ 486 | 16 | Binding Segment LSA | This document | 487 +--------+------------------------+----------------+ 489 IANA is requested to create and maintain new registries: 491 o OSPFv3 Binding Segment LSA TLVs 493 Initial values for the registry are given below. The future 494 assignments are to be made through IETF Review [RFC5226]. 496 Value TLV Name Definition 497 ----- ----------------------- ---------- 498 0 Reserved 499 1 Binding Segment TLV This Document 500 2-32767 Unassigned 501 32768-65535 Reserved 503 4.3. IS-IS 505 Under Registration "Segment Routing Capability" in the "sub-TLVs for 506 TLV 242" registry [RFC8667], IANA is requested to assign one bit flag 507 for Proxy Forwarding Capability as follows: 509 +============+=======================+===============+ 510 | Bit number | Capability Name | Reference | 511 +============+=======================+===============+ 512 | 2 | Proxy Forwarding (PF) | This document | 513 +------------+-----------------------+---------------+ 515 Under Registration "Segment Identifier/Label Binding TLV 149" 516 [RFC8667], IANA is requested to assign one bit P-Flag as follows: 518 +============+=================+===============+ 519 | Bit number | Flag Name | Reference | 520 +============+=================+===============+ 521 | 5 | P-Flag | This document | 522 +------------+-----------------+---------------+ 524 Under Registry Name: IS-IS TLV Codepoints, IANA is requested to 525 assign one new TLV value for IS-IS Binding Segment as follows: 527 +========+======================+===============+ 528 | Value | TLV Name | Reference | 529 +========+======================+===============+ 530 | 152 | Binding Segment TLV | This Document | 531 +--------+----------------------+---------------+ 533 5. Acknowledgements 535 The authors would like to thank Peter Psenak, Acee Lindem, Les 536 Ginsberg, Bruno Decraene and Jeff Tantsura for their comments to this 537 work. 539 6. References 541 6.1. Normative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, 545 DOI 10.17487/RFC2119, March 1997, 546 . 548 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 549 IANA Considerations Section in RFCs", RFC 5226, 550 DOI 10.17487/RFC5226, May 2008, 551 . 553 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 554 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 555 July 2008, . 557 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 558 Scope Link State PDUs (LSPs)", RFC 7356, 559 DOI 10.17487/RFC7356, September 2014, 560 . 562 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 563 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 564 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 565 2015, . 567 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 568 S. Shaffer, "Extensions to OSPF for Advertising Optional 569 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 570 February 2016, . 572 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 573 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 574 Extensions for Segment Routing", RFC 8665, 575 DOI 10.17487/RFC8665, December 2019, 576 . 578 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 579 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 580 Extensions for Segment Routing", RFC 8667, 581 DOI 10.17487/RFC8667, December 2019, 582 . 584 6.2. Informative References 586 [I-D.hu-spring-segment-routing-proxy-forwarding] 587 Hu, Z., Chen, H., Yao, J., Bowers, C., Yongqing, and 588 Yisong, "SR-TE Path Midpoint Restoration", Work in 589 Progress, Internet-Draft, draft-hu-spring-segment-routing- 590 proxy-forwarding-18, 28 February 2022, 591 . 594 [I-D.ietf-spring-segment-routing-policy] 595 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 596 P. Mattes, "Segment Routing Policy Architecture", Work in 597 Progress, Internet-Draft, draft-ietf-spring-segment- 598 routing-policy-18, 17 February 2022, 599 . 602 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 603 Decraene, B., Litkowski, S., and R. Shakir, "Segment 604 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 605 July 2018, . 607 Authors' Addresses 609 Zhibo Hu 610 Huawei Technologies 611 Huawei Bld., No.156 Beiqing Rd. 612 Beijing 613 100095 614 China 615 Email: huzhibo@huawei.com 617 Huaimo Chen 618 Futurewei 619 Boston, MA, 620 United States of America 621 Email: Huaimo.chen@futurewei.com 623 Junda Yao 624 Huawei Technologies 625 Huawei Bld., No.156 Beiqing Rd. 626 Beijing 627 100095 628 China 629 Email: yaojunda@huawei.com 631 Chris Bowers 632 Juniper Networks 633 1194 N. Mathilda Ave. 634 Sunnyvale, CA, 94089 635 United States of America 636 Email: cbowers@juniper.net 637 Yongqing 638 China Telecom 639 109, West Zhongshan Road, Tianhe District 640 Guangzhou 641 510000 642 China 643 Email: zhuyq8@chinatelecom.cn 645 Yisong 646 China Mobile 647 510000 648 China 649 Email: liuyisong@chinamobile.com