idnits 2.17.1 draft-ietf-lsr-ospfv3-srv6-extensions-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 : ---------------------------------------------------------------------------- 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 date (November 19, 2021) is 889 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) == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-11 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-18 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Link State Routing Z. Li 3 Internet-Draft Z. Hu 4 Intended status: Standards Track D. Cheng 5 Expires: May 23, 2022 Huawei Technologies 6 K. Talaulikar, Ed. 7 P. Psenak 8 Cisco Systems 9 November 19, 2021 11 OSPFv3 Extensions for SRv6 12 draft-ietf-lsr-ospfv3-srv6-extensions-03 14 Abstract 16 The Segment Routing (SR) architecture allows flexible definition of 17 the end-to-end path by encoding it as a sequence of topological 18 elements called "segments". It can be implemented over the MPLS or 19 the IPv6 data plane. This document describes the OSPFv3 extensions 20 required to support Segment Routing over the IPv6 data plane (SRv6). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 23, 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. SRv6 Capabilities TLV . . . . . . . . . . . . . . . . . . . . 3 59 3. Advertisement of Supported Algorithms . . . . . . . . . . . . 5 60 4. Advertisement of SRH Operation Limits . . . . . . . . . . . . 5 61 4.1. Maximum Segments Left MSD Type . . . . . . . . . . . . . 5 62 4.2. Maximum End Pop MSD Type . . . . . . . . . . . . . . . . 5 63 4.3. Maximum H.Encaps MSD Type . . . . . . . . . . . . . . . . 6 64 4.4. Maximum End D MSD Type . . . . . . . . . . . . . . . . . 6 65 5. SRv6 SIDs and Reachability . . . . . . . . . . . . . . . . . 6 66 5.1. SRv6 Flexible Algorithm . . . . . . . . . . . . . . . . . 7 67 6. SRv6 Locator LSA . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. SRv6 Locator TLV . . . . . . . . . . . . . . . . . . . . 9 69 7. Advertisment of SRv6 End SIDs . . . . . . . . . . . . . . . . 11 70 8. Advertisment of SRv6 SIDs Associated with Adjacencies . . . . 13 71 8.1. SRv6 End.X SID Sub-TLV . . . . . . . . . . . . . . . . . 14 72 8.2. SRv6 LAN End.X SID Sub-TLV . . . . . . . . . . . . . . . 15 73 9. SRv6 SID Structure Sub-TLV . . . . . . . . . . . . . . . . . 17 74 10. Advertising Endpoint Behaviors . . . . . . . . . . . . . . . 19 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 77 12.1. OSPF Router Information TLVs . . . . . . . . . . . . . . 20 78 12.2. OSPFv3 LSA Function Codes . . . . . . . . . . . . . . . 20 79 12.3. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . . . 20 80 12.4. OSPFv3 Locator LSA TLVs . . . . . . . . . . . . . . . . 21 81 12.5. OSPFv3 Locator LSA Sub-TLVs . . . . . . . . . . . . . . 21 82 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 85 14.2. Informative References . . . . . . . . . . . . . . . . . 24 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 88 1. Introduction 90 Segment Routing (SR) architecture [RFC8402] specifies how a node can 91 steer a packet through an ordered list of instructions, called 92 segments. These segments are identified through Segment Identifiers 93 (SIDs). 95 Segment Routing can be instantiated on the IPv6 data plane through 96 the use of the Segment Routing Header (SRH) defined in [RFC8754]. 97 SRv6 refers to this SR instantiation on the IPv6 dataplane. 99 The network programming paradigm for SRv6 is specified in [RFC8986]. 100 It describes how any behavior can be bound to a SID and how any 101 network program can be expressed as a combination of SIDs. It also 102 describes several well-known behaviors that can be bound to SRv6 103 SIDs. 105 This document specifies extensions to OSPFv3 in order to support SRv6 106 as defined in [RFC8986] by signaling the SRv6 capabilities of the 107 node and some of the SRv6 SIDs with their endpoint behaviors that are 108 instantiated on an SRv6 capable router. Familiarity with [RFC8986] 109 is necessary to understand the extensions specified in this document. 111 At a high level, the extensions to OSPFv3 are comprised of the 112 following: 114 1. SRv6 Capabilities TLV to advertise the SRv6 features and SRH 115 operations supported by the router 117 2. Several new sub-TLVs are defined to advertise various SRv6 118 Maximum SID Depths. 120 3. SRv6 Locator TLV to advertise the SRv6 Locator - a form of 121 summary address for the algorithm specific SIDs instantiated on 122 the router 124 4. TLVs and Sub-TLVs to advertise the SRv6 SIDs instantiated on the 125 router along with their endpoint behaviors 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2. SRv6 Capabilities TLV 137 The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise 138 its support for the SR Segment Endpoint Node [RFC8754] functionality 139 along with its SRv6 related capabilities. This is an optional top 140 level TLV of the OSPFv3 Router Information LSA [RFC7770] which MUST 141 be advertised by an SRv6 enabled router. 143 This TLV SHOULD be advertised only once in the OSPFv3 Router 144 Information LSA. When multiple SRv6 Capabilities TLVs are received 145 from a given router, the receiver MUST use the first occurrence of 146 the TLV in the OSPFv3 Router Information Opaque LSA. If the SRv6 147 Capabilities TLV appears in multiple OSPFv3 Router Information Opaque 148 LSAs that have different flooding scopes, the TLV in the OSPFv3 149 Router Information Opaque LSA with the area-scoped flooding scope 150 MUST be used. If the SRv6 Capabilities TLV appears in multiple 151 OSPFv3 Router Information Opaque LSAs that have the same flooding 152 scope, the TLV in the OSPFv3 Router Information Opaque LSA with the 153 numerically smallest Instance ID MUST be used and subsequent 154 instances of the TLV MUST be ignored. 156 The OSPFv3 Router Information Opaque LSA can be advertised at any of 157 the defined opaque flooding scopes (link, area, or Autonomous System 158 (AS)). For the purpose of SRv6 Capabilities TLV advertisement, area- 159 scoped flooding is REQUIRED. 161 The format of OSPFv3 SRv6 Capabilities TLV is shown below 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type | Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Flags | Reserved | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Sub-TLVs... 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Where: 175 o Type: TBD. 177 o Length: 4 + sume of the lengths of Sub-TLVs in terms of octets 179 o Reserved : 16 bit field. SHOULD be set to 0 and MUST be ignored 180 on receipt. 182 o Flags: 16 bit field. The following flags are defined and others 183 SHOULD be set to 0 and MUST be ignored on receipt: 185 0 1 186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | |O| | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 where: 193 * O-flag: If set, then the router is capable of supporting the 194 O-bit in the SRH flags, as specified in 195 [I-D.ietf-6man-spring-srv6-oam]. 197 The SRv6 Capabilities TLV may contain optional Sub-TLVs. No Sub-TLVs 198 are currently defined. 200 3. Advertisement of Supported Algorithms 202 SRv6 enabled OSPFv3 router advertises its algorithm support using the 203 SR Algorithm TLV defined in [RFC8665] as described in [RFC8666]. 205 4. Advertisement of SRH Operation Limits 207 An SRv6 enabled router may have different capabilities and limits 208 when it comes to SRH processing and this needs to be advertised to 209 other routers in the SRv6 domain. 211 [RFC8476] defines the means to advertise node and link specific 212 values for Maximum SID Depth (MSD) types. Node MSDs are advertised 213 using the Node MSD TLV in the OSPFv3 Router Information LSA [RFC7770] 214 while Link MSDs are advertised using the Link MSD Sub-TLV of the 215 Router-Link TLV [RFC8362]. The format of the MSD types for OSPFv3 is 216 defined in [RFC8476]. 218 The MSD types for SRv6 that are defined in section 4 of 219 [I-D.ietf-lsr-isis-srv6-extensions] for IS-IS are also used by 220 OSPFv3. These MSD Types are allocated under the IGP MSD Types 221 registry maintained by IANA that are shared by IS-IS and OSPF. They 222 are described below: 224 4.1. Maximum Segments Left MSD Type 226 The Maximum Segments Left MSD Type signals the maximum value of the 227 "Segments Left" field of the SRH of a received packet before applying 228 the Endpoint behavior associated with a SID. If no value is 229 advertised, the supported value is assumed to be 0. 231 4.2. Maximum End Pop MSD Type 233 The Maximum End Pop MSD Type signals the maximum number of SIDs in 234 the SRH to which the router can apply "Penultimate Segment Pop (PSP) 235 of the SRH" or "Ultimate Segment Pop (USP) of the SRH", as defined in 236 [RFC8986] flavors. If the advertised value is zero or no value is 237 advertised, then the router cannot apply PSP or USP flavors. 239 4.3. Maximum H.Encaps MSD Type 241 The Maximum H.Encaps MSD Type signals the maximum number of SIDs that 242 can be added as part of the "H.Encaps" behavior as defined in 243 [RFC8986]. If the advertised value is zero or no value is advertised 244 then the headend can apply an SR Policy that only contains one 245 segment, without inserting any SRH. A non-zero SRH Max H.encaps MSD 246 indicates that the headend can insert an SRH up to the advertised 247 value. 249 4.4. Maximum End D MSD Type 251 The Maximum End D MSD Type specifies the maximum number of SIDs 252 present in an SRH when performing decapsulation. These includes, but 253 not limited to, End.DX6, End.DT4, End.DT46, End with USD, End.X with 254 USD as defined in [RFC8986]. If the advertised value is zero or no 255 value is advertised then the router cannot apply any behavior that 256 results in decapsulation and forwarding of the inner packet if the 257 other IPv6 header contains an SRH. 259 5. SRv6 SIDs and Reachability 261 An SRv6 Segment Identifier (SID) is 128 bits and comprises of 262 Locator, Function and Argument parts as described in [RFC8986]. 264 A node is provisioned with algorithm specific locators for each 265 algorithm supported by that node. Each locator is a covering prefix 266 for all SIDs provisioned on that node which have the matching 267 algorithm. 269 Locators MUST be advertised in the SRv6 Locator TLV (see 270 Section 6.1). Forwarding entries for the locators advertised in the 271 SRv6 Locator TLV MUST be installed in the forwarding plane of 272 receiving SRv6 capable routers when the associated algorithm is 273 supported by the receiving node. Locators can be of different route 274 types similar to existing OSPFv3 route types - Intra-Area, Inter- 275 Area, External, and NSSA. The processing of the prefix advertised in 276 the SRv6 Locator TLV, the calculation of its reachability and the 277 installation in the forwarding plane follows the process defined for 278 the respective route types in base OSPFv3 [RFC5340]. 280 Locators associated with algorithm 0 and 1 SHOULD be advertised using 281 the respective OSPFv3 Extended LSA types with extended TLVs [RFC8362] 282 based on the OSPFv3 route of the locators so that legacy routers 283 (i.e., routers which do not support SRv6) will install a forwarding 284 entry for algorithm 0 and 1 SRv6 traffic. When operating in "sparse- 285 mode" of compatibility [RFC8362] these locators SHOULD be also 286 advertised using the respective base OSPFv3 LSAs [RFC5340]. 288 In cases where a locator advertisement is received via in both in a 289 prefix reachability advertisement (i.e. via base OSPFv3 LSAs and/or 290 Extended Prefix TLVs using OSPFv3 Extended LSAs) and an SRv6 Locator 291 TLV, the prefix reachability advertisement in OSPFv3 MUST be 292 preferred over the advertisement in the SRv6 Locator TLV when 293 installing entries in the forwarding plane. This is to prevent 294 inconsistent forwarding entries between SRv6 capable and SRv6 295 incapable routers. Such preference of prefix reachability 296 advertisement does not have any impact on the rest of the data 297 advertised in the SRv6 Locator TLV. 299 SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except 300 for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a 301 specific Neighbor/Link and are therefore advertised as Sub-TLVs of E- 302 Router-Link TLV. 304 SRv6 SIDs received from other nodes are not directly routable and 305 MUST NOT be installed in the forwarding plane. Reachability to SRv6 306 SIDs depends upon the existence of a covering locator. 308 Adherence to the rules defined in this section will assure that SRv6 309 SIDs associated with a supported algorithm will be forwarded 310 correctly, while SRv6 SIDs associated with an unsupported algorithm 311 will be dropped. NOTE: The drop behavior depends on the absence of a 312 default/summary route covering a given locator. 314 In order for forwarding to work correctly, the locator associated 315 with SRv6 SID advertisements must be the longest match prefix 316 installed in the forwarding plane for those SIDs. In order to ensure 317 correct forwarding, network operators should take steps to make sure 318 that this requirement is not compromised. For example, the following 319 situations should be avoided: 321 o Another locator associated with a different topology/algorithm is 322 the longest match 324 o Another base OSPFv3 prefix advertisement is the longest match 326 5.1. SRv6 Flexible Algorithm 328 [I-D.ietf-lsr-flex-algo] specifies IGP Flexible Algorithm mechanisms 329 for OSPFv3. Section 14.2 of [I-D.ietf-lsr-flex-algo] explains SRv6 330 forwarding for Flex-Algorithm and the same apply for supporting SRv6 331 Flexi-Algorithm using OSPFv3. When the algorithm value that is 332 carried in the SRv6 Locator TLV (refer Section 6.1) represents a 333 Flex-Algorithm, the procedures described in section 14.2 of 334 [I-D.ietf-lsr-flex-algo] are followed for the programming of those 335 specific SRv6 Locators. Locators associated with Flexible Algorithms 336 SHOULD NOT be advertised in the base OSPFv3 prefix reachability 337 advertisements. Advertising the Flexible Algorithm locator as 338 regular prefix reachability advertisements would make the forwarding 339 for it to follow algo 0 path. 341 The procedures like ASBR reachability advertisements and the 342 procedures for inter-area, external and NSSA route advertisement and 343 computation as specified in [I-D.ietf-lsr-flex-algo] for OSPFv3 Flex- 344 Algorithm for SR-MPLS also apply for SRv6. 346 6. SRv6 Locator LSA 348 The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits 349 are dependent on the desired flooding scope for the LSA. The 350 flooding scope of the SRv6 Locator LSA depends on the scope of the 351 advertised SRv6 Locator and is under the control of the advertising 352 router. The U bit will be set indicating that the LSA should be 353 flooded even if it is not understood. 355 Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router and 356 they are distinguished by their Link State IDs (which are chosen 357 arbitrarily by the originating router). 359 The format of SRv6 Locator LSA is shown below: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | LS age |1|S12| Function Code | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Link State ID | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Advertising Router | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | LS sequence number | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | LS checksum | Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 +- TLVs -+ 376 | ... | 378 Figure 1: SRv6 Locator LSA 380 The format of the TLVs within the body of the SRv6 Locator LSA is the 381 same as the format used by [RFC3630]. The variable TLV section 382 consists of one or more nested TLV tuples. Nested TLVs are also 383 referred to as Sub-TLVs. The format of each TLV is: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type | Length | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Value | 391 o 392 o 393 o 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 2: SRv6 Locator LSA TLV Format 399 The Length field defines the length of the value portion in octets 400 (thus, a TLV with no value portion would have a length of 0). The 401 TLV is padded to 4-octet alignment; padding is not included in the 402 Length field (so a 3-octet value would have a length of 3, but the 403 total size of the TLV would be 8 octets). Nested TLVs are also 404 32-bit aligned. For example, a 1-byte value would have the Length 405 field set to 1, and 3 octets of padding would be added to the end of 406 the value portion of the TLV. The padding is composed of zeros. 408 6.1. SRv6 Locator TLV 410 The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA that 411 is used to advertise an SRv6 Locator, its attributes, and SIDs 412 associated with it. Multiple SRv6 Locator TLVs MAY be advertised in 413 each SRv6 Locator LSA. However, since the S12 bits define the 414 flooding scope, the LSA flooding scope MUST satisfy the application- 415 specific requirements for all the locators included in a single SRv6 416 Locator LSA. 418 When multiple SRv6 Locator TLVs are received from a given router in 419 an SRv6 Locator LSA for the same Locator, the receiver MUST use the 420 first occurrence of the TLV in the LSA. If the SRv6 Locator TLV for 421 the same Locator appears in multiple SRv6 Locator LSAs that have 422 different flooding scopes, the TLV in the SRv6 Locator LSA with the 423 area-scoped flooding scope MUST be used. If the SRv6 Locator TLV for 424 the same Locator appears in multiple SRv6 Locator LSAs that have the 425 same flooding scope, the TLV in the SRv6 Locator LSA with the 426 numerically smallest Link-State ID MUST be used and subsequent 427 instances of the TLV MUST be ignored. 429 The format of SRv6 Locator TLV is shown below: 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type | Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Route Type | Algorithm | Locator Length| Flags | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Metric | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Locator (128 bits) ... | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Locator cont ... | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Locator cont ... | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Locator cont ... | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Sub-TLVs (variable) | 449 +- -+ 450 | ... | 452 Figure 3: SRv6 Locator TLV 454 Where: 456 Type: 16 bit field. The value is 1 for this type. 458 Length: 16 bit field. The total length of the value portion of 459 the TLV including Sub-TLVs in terms of octets. 461 Route Type : 8 bit field. The type of the locator route. 462 Supported types are the ones listed below and any other types MUST 463 be ignored on receipt. 465 1 - Intra-Area 466 2 - Inter-Area 467 3 - AS External 468 4 - NSSA External 470 Figure 4 472 Algorithm: 8 bit field. Associated algorithm. Algorithm values 473 are defined in the IGP Algorithm Type registry. 475 Locator Length: 8 bit field. Carries the length of the Locator 476 prefix as the number of locator bits (1-128). 478 Flags: 8 bit field. The following flags are defined 480 0 1 2 3 4 5 6 7 481 +-+-+-+-+-+-+-+-+ 482 |N|A| Reserved | 483 +-+-+-+-+-+-+-+-+ 485 Figure 5 487 * N bit : When the locator uniquely identifies a node in the 488 network (i.e., it is provisioned on one and only one node), the 489 N bit MUST be set. Otherwise, this bit MUST be clear. 491 * A bit : When the Locator is configured as anycast, the A bit 492 SHOULD be set. Otherwise, this bit MUST be clear. If both the 493 N and A bits are set, then the receiving routers MUST ignore 494 the N bit (i.e., consider it as not set). 496 * Other flags are not defined and SHOULD be set to 0 and MUST be 497 ignored on receipt. 499 Metric : One octet field. The metric value associated with the 500 locator. 502 Locator : 6 octet field. This field encodes the advertised SRv6 503 Locator. 505 Sub-TLVs : Used to advertise Sub-TLVs that provide additional 506 attributes for the given SRv6 Locator and SRv6 SIDs associated 507 with it. 509 7. Advertisment of SRv6 End SIDs 511 The SRv6 End SID Sub-TLV is a Sub-TLV of the SRv6 Locator TLV in the 512 SRv6 Locator LSA (defined in Section 6). It is used to advertise the 513 SRv6 SIDs belonging to the node along with their associated endpoint 514 behaviors. SIDs associated with adjacencies are advertised as 515 described in Section 8. Every SRv6 enabled OSPFv3 router SHOULD 516 advertise at least one SRv6 SID associated with an END behavior for 517 its node as specified in [RFC8986]. 519 SRv6 End SIDs inherit the algorithm from the parent locator. The 520 SRv6 End SID MUST be allocated from its associated locator. SRv6 End 521 SIDs that are NOT allocated from the associated locator MUST be 522 ignored. 524 The router MAY advertise multiple instances of the SRv6 End SID Sub- 525 TLV within the SRv6 Locator TLV - one for each of the SRv6 SIDs to be 526 advertised. When multiple SRv6 End SID Sub-TLVs are received in the 527 SRv6 Locator TLV from a given router for the same SRv6 SID value, the 528 receiver MUST use the first occurrence of the Sub-TLV in the SRv6 529 Locator TLV. 531 The format of SRv6 End SID Sub-TLV is shown below 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type | Length | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Flags | Reserved | Endpoint Behavior | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | SID (128 bits) ... | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | SID cont ... | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | SID cont ... | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | SID cont ... | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Sub-TLVs (variable) . . . 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Figure 6: SRv6 End SID Sub-TLV 553 Where: 555 Type: 16 bit field. Value is 1 for this type. 557 Length: 16 bit field. The total length of the value portion of 558 the Sub-TLVs. 560 Reserved : 8 bit field. Should be set to 0 and MUST be ignored on 561 receipt. 563 Flags: 8 bit field which define the flags associated with the SID. 564 No flags are currently defined and SHOULD be set to 0 and MUST be 565 ignored on receipt. 567 Endpoint Behavior: 16 bit field. The endpoint behavior code point 568 for this SRv6 SID as defined in section 9.2 of [RFC8986]. 570 SID : 6 octet field. This field encodes the advertised SRv6 SID. 572 Sub-TLVs : Used to advertise Sub-TLVs that provide additional 573 attributes for the given SRv6 SID. 575 8. Advertisment of SRv6 SIDs Associated with Adjacencies 577 The SRv6 endpoint behaviors are defined in [RFC8986] include certain 578 behaviors which are specific to links or adjacencies. The most basic 579 of these which is critical for link state routing protocols like 580 OSPFv3 is the End.X behavior that is an instruction to forward to a 581 specific neighbor on a specific link. These SRv6 SIDs along with 582 others that are defined in [RFC8986] which are specific to links or 583 adjacencies need to be advertised by OSPFv3 so that this information 584 is available to all routers in the area to influence the packet path 585 via these SRv6 SIDs over the specific adjacencies. 587 The advertisement of SRv6 SIDs and their behaviors that are specific 588 to a particular neighbor is done via two different optional Sub-TLVs 589 of the E-Router-Link TLV defined in [RFC8362] as follows: 591 o SRv6 End.X SID Sub-TLV: For OSPFv3 adjacencies over point-to-point 592 or point-to-multipoint links and the adjacency to the Designated 593 Router (DR) over broadcast and non-broadcast-multi-access (NBMA) 594 links. 596 o SRv6 LAN End.X SID Sub-TLV: For OSPFv3 adjacencies on broadcast 597 and NBMA links to the Backup DR and DR-Other neighbors. This Sub- 598 TLV includes the OSPFv3 router-id of the neighbor and thus allows 599 for an instance of this Sub-TLV for each neighbor to be explicitly 600 advertised under the E-Router-Link TLV for the same link. 602 Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one 603 unique SRv6 End.X SID corresponding to each of its neighbor. A 604 router MAY instantiate more than one SRv6 End.X SID for for a single 605 neighbor. The same SRv6 End.X SID MAY be advertised for more than 606 one neighbor. Thus multiple instances of the SRv6 End.X SID and SRv6 607 LAN End.X SID Sub-TLVs MAY be advertised within the E-Router-Link TLV 608 for a single link. 610 All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 611 Locator with the matching algorithm which is advertised by the same 612 node in an SRv6 Locator TLV. End.X SIDs which do not meet this 613 requirement MUST be ignored. This ensures that the node advertising 614 the End.X or LAN End.X SID is also advertising its corresponding 615 Locator with the algorithm that will be used for computing paths 616 destined to the SID. 618 8.1. SRv6 End.X SID Sub-TLV 620 The format of the SRv6 End.X SID Sub-TLV is shown below 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Type | Length | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Endpoint Behavior | Flags | Reserved1 | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Algorithm | Weight | Reserved2 | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | SID (128 bits) ... | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | SID cont ... | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | SID cont ... | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | SID cont ... | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Sub-TLVs (variable) . . . 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Where: 644 Type: 16 bit field. Value is TBD. 646 Length: 16 bit field. The total length of the value portion of 647 the TLV. 649 Endpoint Behavior: 16 bit field. The code point for the endpoint 650 behavior for this SRv6 SID as defined in section 9.2 of [RFC8986]. 652 Flags: 8 bit field with the following definition: 654 0 1 2 3 4 5 6 7 655 +-+-+-+-+-+-+-+-+ 656 |B|S|P| Reserved| 657 +-+-+-+-+-+-+-+-+ 659 * B-Flag: Backup Flag. If set, the SID refers to a path that is 660 eligible for protection. 662 * S-Flag: Set Flag. When set, the S-Flag indicates that the 663 End.X SID refers to a set of adjacencies (and therefore MAY be 664 assigned to other adjacencies as well). 666 * P-Flag: Persistent Flag: If set, the SID is persistently 667 allocated, i.e., the SID value remains consistent across router 668 restart and session/interface flap. 670 * Reserved bits: Reserved for future use and MUST be zero when 671 originated and ignored on receipt. 673 Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored 674 on receipt. 676 Algorithm : 8 bit field. Associated algorithm. Algorithm values 677 are defined in the IGP Algorithm Type registry. 679 Weight: 8 bit field whose value represents the weight of the End.X 680 SID for the purpose of load-balancing. The use of the weight is 681 defined in [RFC8402]. 683 Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored 684 on receipt. 686 SID: 128 bit field. This field encodes the advertised SRv6 SID. 688 Sub-TLVs : Used to advertise Sub-TLVs that provide additional 689 attributes for the given SRv6 End.X SID. 691 8.2. SRv6 LAN End.X SID Sub-TLV 693 The format of the SRv6 LAN End.X SID Sub-TLV is as shown below 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Type | Length | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Endpoint Behavior | Flags | Reserved1 | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Algorithm | Weight | Reserved2 | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | OSPFv3 Router-ID of neighbor | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | SID (128 bits) ... | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | SID cont ... | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | SID cont ... | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | SID cont ... | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Sub-TLVs (variable) . . . 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 Where 718 o Type: 16 bit field. Value is TBD. 720 o Length: 16 bit field. Variable 722 o Endpoint Behavior: 16 bit field. The code point for the endpoint 723 behavior for this SRv6 SID as defined in section 9.2 of [RFC8986]. 725 o SID Flags: 8 bit field which define the flags associated with the 726 SID. No flags are currently defined and SHOULD be set to 0 and 727 MUST be ignored on receipt. 729 o Flags: 8 bit field with the following definition: 731 0 1 2 3 4 5 6 7 732 +-+-+-+-+-+-+-+-+ 733 |B|S|P| Reserved| 734 +-+-+-+-+-+-+-+-+ 736 * B-Flag: Backup Flag. If set, the SID refers to a path that is 737 eligible for protection. 739 * S-Flag: Set Flag. When set, the S-Flag indicates that the 740 End.X SID refers to a set of adjacencies (and therefore MAY be 741 assigned to other adjacencies as well). 743 * P-Flag: Persistent Flag: If set, the SID is persistently 744 allocated, i.e., the SID value remains consistent across router 745 restart and session/interface flap. 747 * Reserved bits: Reserved for future use and MUST be zero when 748 originated and ignored on receipt. 750 o Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored 751 on receipt. 753 o Algorithm : 8 bit field. Associated algorithm. Algorithm values 754 are defined in the IGP Algorithm Type registry. 756 o Weight: 8 bit field whose value represents the weight of the End.X 757 SID for the purpose of load balancing. The use of the weight is 758 defined in [RFC8402]. 760 o Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored 761 on receipt. 763 o Neighbor ID : 32 bits of OSPFv3 Router-id of the neighbor 765 o SID: 128 bit field. This field encodes the advertised SRv6 SID. 767 o Sub-TLVs : Used to advertise Sub-TLVs that provide additional 768 attributes for the given SRv6 SID. 770 9. SRv6 SID Structure Sub-TLV 772 SRv6 SID Structure Sub-TLV is used to advertise the structure of the 773 SRv6 SID as defined in [RFC8986]. It is used as an optional Sub-TLV 774 of the following: 776 o SRv6 End SID Sub-TLV (refer Section 7) 778 o SRv6 End.X SID Sub-TLV (refer Section 8.1) 780 o SRv6 LAN End.X SID Sub-TLV (refer Section 8.2) 782 The Sub-TLV has the following format: 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Type | Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | LB Length | LN Length | Fun. Length | Arg. Length | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 Figure 7: SRv6 SID Structure Sub-TLV 794 Where: 796 Type: 16 bit field with value TBD, see Section 12. 798 Length: 16 bit field with the value 4. 800 LB Length: 8 bit field. SRv6 SID Locator Block length in bits. 802 LN Length: 8 bit field. SRv6 SID Locator Node length in bits. 804 Function Length: 8 bit field. SRv6 SID Function length in bits. 806 Argument Length: 8 bit field. SRv6 SID Argument length in bits. 808 The SRv6 SID Structure Sub-TLV MUST NOT appear more than once in its 809 parent TLV/Sub-TLV. If it appears more than once in its parent TLV/ 810 Sub-TLV, the parent TLV/Sub-TLV MUST be ignored by the receiver. 812 The sum of all four sizes advertised in SRv6 SID Structure Sub-TLV 813 MUST be less than or equal to 128 bits. If the sum of all four sizes 814 advertised in the SRv6 SID Structure Sub-Sub-TLV is larger than 128 815 bits, the parent TLV/Sub-TLV MUST be ignored by the receiver. 817 The SRv6 SID Structure Sub-TLV is intended for informational use by 818 the control and management planes. It MUST NOT be used at a transit 819 node (as defined in [RFC8754]) for forwarding packets. As an 820 example, this information could be used for: 822 o validation of SRv6 SIDs being instantiated in the network and 823 advertised via OSPFv3. These can be learnt by controllers via 824 BGP-LS and then be monitored for conformance to the SRv6 SID 825 allocation scheme chosen by the operator as described in 826 Section 3.2 of [RFC8986]. 828 o verification and the automation for securing the SRv6 domain by 829 provisioning filtering rules at SR domain boundaries as described 830 in Section 5 of [RFC8754]. 832 The details of these potential applications are outside the scope of 833 this document. 835 10. Advertising Endpoint Behaviors 837 Endpoint behaviors are defined in [RFC8986] and 838 [I-D.ietf-6man-spring-srv6-oam]. The codepoints for the Endpoint 839 behaviors are defined in the section 9.2 of [RFC8986]. This section 840 lists the Endpoint behaviors and their codepoints, which MAY be 841 advertised by OSPFv3 and the Sub-TLVs in which each type MAY appear. 843 |-----------------------|--------------------|-----|-------|-----------| 844 | Endpoint | Endpoint | End | End.X | LAN End.X | 845 | Behavior | Behavior Codepoint | SID | SID | SID | 846 |-----------------------|--------------------|-----|-------|-----------| 847 | End (PSP, USP, USD) | 1-4, 28-31 | Y | N | N | 848 |-----------------------|--------------------|-----|-------|-----------| 849 | End.X (PSP, USP, USD) | 5-8, 32-35 | N | Y | Y | 850 |-----------------------|--------------------|-----|-------|-----------| 851 | End.DX6 | 16 | N | Y | Y | 852 |-----------------------|--------------------|-----|-------|-----------| 853 | End.DX4 | 17 | N | Y | Y | 854 |-----------------------|--------------------|-----|-------|-----------| 855 | End.DT6 | 18 | Y | N | N | 856 |-----------------------|--------------------|-----|-------|-----------| 857 | End.DT4 | 19 | Y | N | N | 858 |-----------------------|--------------------|-----|-------|-----------| 859 | End.DT64 | 20 | Y | N | N | 860 |-----------------------|--------------------|-----|-------|-----------| 862 Figure 8: SRv6 Endpoint Behaviors in OSPFv3 864 11. Security Considerations 866 Existing security extensions as described in [RFC5340] and [RFC8362] 867 apply to these SRv6 extensions. While OSPFv3 is under a single 868 administrative domain, there can be deployments where potential 869 attackers have access to one or more networks in the OSPFv3 routing 870 domain. In these deployments, stronger authentication mechanisms 871 such as those specified in [RFC4552] or [RFC7166] SHOULD be used. 873 Implementations MUST assure that malformed TLV and Sub-TLV defined in 874 this document are detected and do not provide a vulnerability for 875 attackers to crash the OSPFv3 router or routing process. Reception 876 of malformed TLV or Sub-TLV SHOULD be counted and/or logged for 877 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be 878 rate-limited to prevent a Denial of Service (DoS) attack (distributed 879 or otherwise) from overloading the OSPFv3 control plane. 881 This document describes the OSPFv3 extensions required to support 882 Segment Routing over an IPv6 data plane. The security considerations 883 for Segment Routing are discussed in [RFC8402]. [RFC8986] defines 884 the SRv6 Network Programming concept and specifies the main Segment 885 Routing behaviors to enable the creation of interoperable overlays; 886 the security considerations from that document apply too. 888 The advertisement for an incorrect MSD value may have negative 889 consequences, see [RFC8476] for additional considerations. 891 Security concerns associated with the setting of the O-flag are 892 described in [I-D.ietf-6man-spring-srv6-oam]. 894 Security concerns associated with the usage of Flex-Algorithms are 895 described in [I-D.ietf-lsr-flex-algo]. 897 12. IANA Considerations 899 This document specifies updates to multiple OSPF and OSPFv3 related 900 IANA registries as follows. 902 12.1. OSPF Router Information TLVs 904 This document proposes the following new code point in the "OSPF 905 Router Information (RI) TLVs" registry under the "OSPF Parameters" 906 registry for the new TLVs: 908 Type TBD (suggested 20): SRv6-Capabilities TLV: Refer to 909 Section 2. 911 12.2. OSPFv3 LSA Function Codes 913 This document proposes the following new code point in the "OSPFv3 914 LSA Function Codes" registry under the "OSPFv3 Parameters" registry 915 for the new SRv6 Locator LSA: 917 o Type TBD (suggested 42): SRv6 Locator LSA: Refer to Section 6. 919 12.3. OSPFv3 Extended-LSA Sub-TLVs 921 This document proposes the following new code points in the "OSPFv3 922 Extended-LSA Sub-TLVs" registry under the "OSPFv3 Parameters" 923 registry for the new Sub-TLVs: 925 o Type TBD (suggested 10): SRv6 SID Structure Sub-TLV : Refer to 926 Section 9. 928 o Type TBD (suggested 11): SRv6 End.X SID Sub-TLV : Refer to 929 Section 8.1. 931 o Type TBD (suggested 12): SRv6 LAN End.X SID Sub-TLV : Refer to 932 Section 8.2. 934 12.4. OSPFv3 Locator LSA TLVs 936 This document proposes setting up of a new "OSPFv3 Locator LSA TLVs" 937 registry that defines top-level TLVs for the OSPFv3 SRv6 Locator LSA 938 to be added under the "OSPFv3 Parameters" registry. The initial 939 code-points assignment is as below: 941 o Type 0: Reserved. 943 o Type 1: SRv6 Locator TLV : Refer to Section 6.1. 945 Types in the range 2-32767 are allocated via IETF Review or IESG 946 Approval [RFC8126]. 948 Types in the range 32768-33023 are Reserved for Experimental Use; 949 these will not be registered with IANA and MUST NOT be mentioned by 950 RFCs. 952 Types in the range 33024-45055 are to be assigned on a First Come 953 First Served (FCFS) basis. 955 Types in the range 45056-65535 are not to be assigned at this time. 956 Before any assignments can be made in the 33024-65535 range, there 957 MUST be an IETF specification that specifies IANA Considerations that 958 cover the range being assigned. 960 12.5. OSPFv3 Locator LSA Sub-TLVs 962 This document proposes setting up of a new "OSPFv3 Locator LSA Sub- 963 TLVs" registry that defines Sub-TLVs at any level of nesting for the 964 SRv6 Locator TLVs to be added under the "OSPFv3 Parameters" registry. 965 The initial code-points assignment is as below: 967 o Type 0: Reserved. 969 o Type 1: SRv6 End SID Sub-TLV : Refer to Section 7. 971 o Type 10: SRv6 SID Structure Sub-TLV : Refer to Section 9. 973 Types in the range 2-9 and 11-32767 are allocated via IETF Review or 974 IESG Approval [RFC8126]. 976 Types in the range 32768-33023 are Reserved for Experimental Use; 977 these will not be registered with IANA and MUST NOT be mentioned by 978 RFCs. 980 Types in the range 33024-45055 are to be assigned on a First Come 981 First Served (FCFS) basis. 983 Types in the range 45056-65535 are not to be assigned at this time. 984 Before any assignments can be made in the 33024-65535 range, there 985 MUST be an IETF specification that specifies IANA Considerations that 986 cover the range being assigned. 988 13. Acknowledgements 990 The authors would like to thank Acee Lindem and Chenzichao for their 991 review and comments on this document. 993 14. References 995 14.1. Normative References 997 [I-D.ietf-6man-spring-srv6-oam] 998 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 999 Chen, "Operations, Administration, and Maintenance (OAM) 1000 in Segment Routing Networks with IPv6 Data plane (SRv6)", 1001 draft-ietf-6man-spring-srv6-oam-11 (work in progress), 1002 June 2021. 1004 [I-D.ietf-lsr-flex-algo] 1005 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1006 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1007 algo-18 (work in progress), October 2021. 1009 [I-D.ietf-lsr-isis-srv6-extensions] 1010 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1011 Z. Hu, "IS-IS Extensions to Support Segment Routing over 1012 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-18 1013 (work in progress), October 2021. 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, 1017 DOI 10.17487/RFC2119, March 1997, 1018 . 1020 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1021 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1022 . 1024 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1025 S. Shaffer, "Extensions to OSPF for Advertising Optional 1026 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1027 February 2016, . 1029 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1030 Writing an IANA Considerations Section in RFCs", BCP 26, 1031 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1032 . 1034 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1035 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1036 May 2017, . 1038 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 1039 F. Baker, "OSPFv3 Link State Advertisement (LSA) 1040 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 1041 2018, . 1043 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1044 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1045 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1046 July 2018, . 1048 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1049 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1050 DOI 10.17487/RFC8476, December 2018, 1051 . 1053 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 1054 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1055 Extensions for Segment Routing", RFC 8665, 1056 DOI 10.17487/RFC8665, December 2019, 1057 . 1059 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 1060 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 1061 December 2019, . 1063 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1064 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1065 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1066 . 1068 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1069 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1070 (SRv6) Network Programming", RFC 8986, 1071 DOI 10.17487/RFC8986, February 2021, 1072 . 1074 14.2. Informative References 1076 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1077 (TE) Extensions to OSPF Version 2", RFC 3630, 1078 DOI 10.17487/RFC3630, September 2003, 1079 . 1081 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1082 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 1083 . 1085 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 1086 Authentication Trailer for OSPFv3", RFC 7166, 1087 DOI 10.17487/RFC7166, March 2014, 1088 . 1090 Authors' Addresses 1092 Zhenbin Li 1093 Huawei Technologies 1095 Email: lizhenbin@huawei.com 1097 Zhibo Hu 1098 Huawei Technologies 1100 Email: huzhibo@huawei.com 1102 Dean Cheng 1103 Huawei Technologies 1105 Email: dean.cheng@huawei.com 1107 Ketan Talaulikar (editor) 1108 Cisco Systems 1109 India 1111 Email: ketant.ietf@gmail.com 1112 Peter Psenak 1113 Cisco Systems 1114 Slovakia 1116 Email: ppsenak@cisco.com