idnits 2.17.1 draft-ietf-lsr-ospfv3-srv6-extensions-01.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 (August 14, 2020) is 1351 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-07 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-08 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-17 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-08 Summary: 0 errors (**), 0 flaws (~~), 5 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: February 15, 2021 Huawei Technologies 6 K. Talaulikar, Ed. 7 P. Psenak 8 Cisco Systems 9 August 14, 2020 11 OSPFv3 Extensions for SRv6 12 draft-ietf-lsr-ospfv3-srv6-extensions-01 14 Abstract 16 Segment Routing (SR) allows for a flexible definition of end-to-end 17 paths by encoding paths as sequences of topological sub-paths, called 18 "segments". Segment Routing architecture can be implemented over an 19 MPLS data plane as well as an IPv6 data plane. This draft describes 20 the OSPFv3 extensions required to support Segment Routing over an 21 IPv6 data plane (SRv6). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 15, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. SRv6 Capabilities TLV . . . . . . . . . . . . . . . . . . . . 3 60 3. Advertisement of Supported Algorithms . . . . . . . . . . . . 5 61 4. Advertisement of SRH Operation Limits . . . . . . . . . . . . 5 62 4.1. Maximum Segments Left MSD Type . . . . . . . . . . . . . 5 63 4.2. Maximum End Pop MSD Type . . . . . . . . . . . . . . . . 5 64 4.3. Maximum H.Encaps MSD Type . . . . . . . . . . . . . . . . 5 65 4.4. Maximum End D MSD Type . . . . . . . . . . . . . . . . . 6 66 5. Advertisement of SRv6 Locator and End SIDs . . . . . . . . . 6 67 6. SRv6 Locator LSA . . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. SRv6 Locator TLV . . . . . . . . . . . . . . . . . . . . 9 69 7. Advertisment of SRv6 End SIDs . . . . . . . . . . . . . . . . 11 70 8. Advertisment of SRv6 SIDs Associated with Adjacencies . . . . 12 71 8.1. SRv6 End.X SID Sub-TLV . . . . . . . . . . . . . . . . . 13 72 8.2. SRv6 LAN End.X SID Sub-TLV . . . . . . . . . . . . . . . 15 73 9. SRv6 SID Structure Sub-TLV . . . . . . . . . . . . . . . . . 16 74 10. Advertising Endpoint Behaviors . . . . . . . . . . . . . . . 17 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 12.1. OSPF Router Information TLVs . . . . . . . . . . . . . . 19 78 12.2. OSPFv3 LSA Function Codes . . . . . . . . . . . . . . . 19 79 12.3. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . . . 19 80 12.4. OSPFv3 Locator LSA TLVs . . . . . . . . . . . . . . . . 19 81 12.5. OSPFv3 Locator LSA Sub-TLVs . . . . . . . . . . . . . . 20 82 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 85 14.2. Informative References . . . . . . . . . . . . . . . . . 22 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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]. 98 SRv6 refers to this SR instantiation on the IPv6 dataplane. The 99 network programming paradigm for SRv6 is specified in 100 [I-D.ietf-spring-srv6-network-programming] which describes several 101 well-known behaviors that can be bound to SRv6 SIDs. 103 This document specifies extensions to OSPFv3 in order to support SRv6 104 as defined in [I-D.ietf-spring-srv6-network-programming] by signaling 105 the SRv6 capabilities of the node and certain SRv6 SIDs with their 106 endpoint behaviors (e.g., End, End.X, etc.) that are instantiated on 107 the SRv6 capable router. 109 At a high level, the extensions to OSPFv3 are comprised of the 110 following: 112 1. SRv6 Capabilities TLV to advertise the SRv6 features and SRH 113 operations supported by the router 115 2. SRv6 Locator TLV to advertise the SRv6 Locator - a form of 116 summary address for the algorithm specific SIDs instantiated on 117 the router 119 3. TLVs and Sub-TLVs to advertise the SRv6 SIDs instantiated on the 120 router along with their endpoint behaviors 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2. SRv6 Capabilities TLV 132 The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise 133 its SRv6 support along with its related capabilities for SRv6 134 functionality. This is an optional top level TLV of the OSPFv3 135 Router Information LSA [RFC7770] which MUST be advertised by an SRv6 136 enabled router. 138 This TLV SHOULD be advertised only once in the OSPFv3 Router 139 Information LSA. When multiple SRv6 Capabilities TLVs are received 140 from a given router, the receiver MUST use the first occurrence of 141 the TLV in the OSPFV3 Router Information Opaque LSA. If the SRv6 142 Capabilities TLV appears in multiple OSPFv3 Router Information Opaque 143 LSAs that have different flooding scopes, the TLV in the OSPFv3 144 Router Information Opaque LSA with the area-scoped flooding scope 145 MUST be used. If the SRv6 Capabilities TLV appears in multiple 146 OSPFv3 Router Information Opaque LSAs that have the same flooding 147 scope, the TLV in the OSPFv3 Router Information Opaque LSA with the 148 numerically smallest Instance ID MUST be used and subsequent 149 instances of the TLV MUST be ignored. 151 The OSPFv3 Router Information Opaque LSA can be advertised at any of 152 the defined opaque flooding scopes (link, area, or Autonomous System 153 (AS)). For the purpose of SRv6 Capabilities TLV advertisement, area- 154 scoped flooding is REQUIRED. 156 The format of OSPFv3 SRv6 Capabilities TLV is shown below 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Type | Length | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Flags | Reserved | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Sub-TLVs... 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Where: 170 o Type: 16 bit field. Value is TBD. 172 o Length: 16 bit field. Length of Capability TLV + length of Sub- 173 TLVs 175 o Reserved : 16 bit field. SHOULD be set to 0 and MUST be ignored 176 on receipt. 178 o Flags: 16 bit field. The following flags are defined and others 179 SHOULD be set to 0 and MUST be ignored on receipt: 181 0 1 182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | |O| | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 where: 189 * O-flag: If set, then the router is capable of supporting the 190 SRH O-bit, as specified in [I-D.ietf-6man-spring-srv6-oam]. 192 The SRv6 Capabilities TLV may contain optional Sub-TLVs. No Sub-TLVs 193 are currently defined. 195 3. Advertisement of Supported Algorithms 197 SRv6 enabled OSPFv3 router advertises its algorithm support using the 198 SR Algorithm TLV defined in [RFC8665] as described in [RFC8666]. 200 4. Advertisement of SRH Operation Limits 202 An SRv6 enabled router may have different capabilities and limits 203 when it comes to SRH processing and this needs to be advertised to 204 other routers in the SRv6 domain. 206 [RFC8476] defines the means to advertise node/link specific values 207 for Maximum SID Depth (MSD) types. Node MSDs are advertised using 208 the Node MSD TLV in the OSPFv3 Router Information LSA [RFC7770] while 209 Link MSDs are advertised using the Link MSD Sub-TLV of the E-Router- 210 LSA TLV [RFC8362]. The format of the MSD types for OSPFv3 is defined 211 in [RFC8476]. 213 The MSD types for SRv6 that are defined in section 4 of 214 [I-D.ietf-lsr-isis-srv6-extensions] for IS-IS are also used by 215 OSPFv3. These MSD Types are allocated under the IGP MSD Types 216 registry maintained by IANA that are shared by IS-IS and OSPF. They 217 are described below: 219 4.1. Maximum Segments Left MSD Type 221 The Maximum Segments Left MSD Type specifies the maximum value of the 222 "SL" field [RFC8754] in the SRH of a received packet before applying 223 the Endpoint behavior associated with a SID. If no value is 224 advertised, the supported value is assumed to be 0. 226 4.2. Maximum End Pop MSD Type 228 The Maximum End Pop MSD Type specifies the maximum number of SIDs in 229 the SRH for which the router can apply Penultimate Segment Pop (PSP) 230 or Ultimate Segment Pop (USP) as defined in 231 [I-D.ietf-spring-srv6-network-programming] flavors. If the 232 advertised value is zero or no value is advertised, then it is 233 assumed that the router cannot apply PSP or USP. 235 4.3. Maximum H.Encaps MSD Type 237 The Maximum H.Encaps MSD Type specifies the maximum number of SIDs 238 that can be included as part of the "H.Encaps" behavior as defined in 239 [I-D.ietf-spring-srv6-network-programming]. If the advertised value 240 is zero then the router can apply H.Encaps only by encapsulating the 241 incoming packet in another IPv6 header without SRH the same way 242 IPinIP encapsulation is performed. If the advertised value is non- 243 zero, then the router supports both IPinIP and SRH encapsulation 244 subject to the SID limitation specified by the advertised value. 246 4.4. Maximum End D MSD Type 248 The Maximum End D MSD Type specifies the maximum number of SIDs in an 249 SRH when performing decapsulation associated with "End.Dx" behaviors 250 (e.g., "End.DX6" and "End.DT6") as defined in 251 [I-D.ietf-spring-srv6-network-programming]. If the advertised value 252 is zero or no value is advertised, then it is assumed that the router 253 cannot apply "End.DX6" or "End.DT6" behaviors if the extension header 254 right underneath the outer IPv6 header is an SRH. 256 5. Advertisement of SRv6 Locator and End SIDs 258 An SRv6 Segment Identifier (SID) is 128 bits and comprises of 259 Locator, Function and Argument parts as described in 260 [I-D.ietf-spring-srv6-network-programming]. 262 A node is provisioned with algorithm specific locators for each 263 algorithm supported by that node. Each locator is a prefix subsuming 264 all SIDs provisioned on that node which have the matching algorithm. 266 Locators MUST be advertised in the SRv6 Locator LSA (see Section 6). 267 Forwarding entries for the locators advertised in the SRv6 Locator 268 LSA MUST be installed in the forwarding plane of receiving SRv6 269 capable routers when the associated algorithm is supported by the 270 receiving node. Locators can be of different route types similar to 271 existing OSPF LSA route types - Intra-Area, Inter-Area, External, and 272 NSSA. The computation of locator reachability and their 273 advertisement are similar to how normal OSPF prefix reachability LSAs 274 are processed as part of the route computation. 276 Locators are routable and MAY also be advertised via Prefix LSAs of 277 different types - Inter-Area Prefix LSA, AS-External LSA, NSSA LSA, 278 or Intra-Area Prefix LSA (or their equivalent extended LSAs 279 [RFC8362]). Locators associated with Flexible Algorithms 280 [I-D.ietf-lsr-flex-algo] SHOULD NOT be advertised via Prefix LSAs. 281 Locators associated with algorithm 0 (for all supported topologies) 282 SHOULD be advertised in Prefix LSAs so that legacy routers (i.e., 283 routers which do NOT support SRv6) will install a forwarding entry 284 for algorithm 0 SRv6 traffic. 286 In cases where a locator advertisement is received in both in a 287 Prefix LSA and an SRv6 Locator LSA, the Prefix LSA advertisement MUST 288 be preferred when installing entries in the forwarding plane. This 289 is to prevent inconsistent forwarding entries on SRv6 capable/SRv6 290 incapable routers. 292 SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except 293 for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a 294 specific Neighbor/Link and are therefore advertised as Sub-TLVs of E- 295 Router-Link TLV. 297 SRv6 SIDs are not directly routable. SRv6 SIDs learnt by via 298 advertisements from remote routers MUST NOT be installed in the 299 forwarding plane. Reachability to SRv6 SIDs depends upon the 300 existence of a covering locator. Adherence to the rules defined in 301 this section will assure that SRv6 SIDs associated with a supported 302 algorithm will be forwarded correctly, while SRv6 SIDs associated 303 with an unsupported algorithm will be dropped. NOTE: The drop 304 behavior depends on the absence of a default/summary route covering a 305 given locator. 307 6. SRv6 Locator LSA 309 The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits 310 are dependent on the desired flooding scope for the LSA. The 311 flooding scope of the SRv6 Locator LSA depends on the scope of the 312 advertised SRv6 Locator and is under the control of the advertising 313 router. The U bit will be set indicating that the LSA should be 314 flooded even if it is not understood. 316 Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router and 317 they are distinguished by their Link State IDs (which are chosen 318 arbitrarily by the originating router). 320 The format of SRv6 Locator LSA is shown below: 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | LS age |1|S12| Function Code | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Link State ID | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Advertising Router | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | LS sequence number | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | LS checksum | Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 +- TLVs -+ 337 | ... | 339 Figure 1: SRv6 Locator LSA 341 The format of the TLVs within the body of the SRv6 Locator LSA is the 342 same as the format used by [RFC3630]. The variable TLV section 343 consists of one or more nested TLV tuples. Nested TLVs are also 344 referred to as Sub-TLVs. The format of each TLV is: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Value | 352 o 353 o 354 o 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Figure 2: SRv6 Locator LSA TLV Format 360 The Length field defines the length of the value portion in octets 361 (thus, a TLV with no value portion would have a length of 0). The 362 TLV is padded to 4-octet alignment; padding is not included in the 363 Length field (so a 3-octet value would have a length of 3, but the 364 total size of the TLV would be 8 octets). Nested TLVs are also 365 32-bit aligned. For example, a 1-byte value would have the Length 366 field set to 1, and 3 octets of padding would be added to the end of 367 the value portion of the TLV. The padding is composed of zeros. 369 6.1. SRv6 Locator TLV 371 The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA that 372 is used to advertise an SRv6 Locator, its attributes, and SIDs 373 associated with it. Multiple SRv6 Locator TLVs MAY be advertised in 374 each SRv6 Locator LSA. However, since the S12 bits define the 375 flooding scope, the LSA flooding scope MUST satisfy the application- 376 specific requirements for all the locators included in a single SRv6 377 Locator LSA. 379 When multiple SRv6 Locator TLVs are received from a given router in 380 an SRv6 Locator LSA for the same Locator, the receiver MUST use the 381 first occurrence of the TLV in the LSA. If the SRv6 Locator TLV for 382 the same Locator appears in multiple SRv6 Locator LSAs that have 383 different flooding scopes, the TLV in the SRv6 Locator LSA with the 384 area-scoped flooding scope MUST be used. If the SRv6 Locator TLV for 385 the same Locator appears in multiple SRv6 Locator LSAs that have the 386 same flooding scope, the TLV in the SRv6 Locator LSA with the 387 numerically smallest Link-State ID MUST be used and subsequent 388 instances of the TLV MUST be ignored. 390 The format of SRv6 Locator TLV is shown below: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Type | Length | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Route Type | Algorithm | Locator Length| Flags | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Metric | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Locator (128 bits) ... | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Locator cont ... | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Locator cont ... | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Locator cont ... | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Sub-TLVs (variable) | 410 +- -+ 411 | ... | 413 Figure 3: SRv6 Locator TLV 415 Where: 417 Type: 16 bit field. The value is 1 for this type. 419 Length: 16 bit field. The total length of the value portion of 420 the TLV including Sub-TLVs. 422 Route Type : 8 bit field. The type of the locator route. 423 Supported types are the ones listed below and other other types 424 MUST be ignored on receipt. 426 1 - Intra-Area 427 2 - Inter-Area 428 3 - AS External 429 4 - NSSA External 431 Figure 4 433 Algorithm: 8 bit field. Associated algorithm. Algorithm values 434 are defined in the IGP Algorithm Type registry. 436 Locator Length: 8 bit field. Carries the length of the Locator 437 prefix as the number of locator bits (1-128). 439 Flags: 8 bit field. The following flags are defined 441 0 1 2 3 4 5 6 7 442 +-+-+-+-+-+-+-+-+ 443 |N|A| Reserved | 444 +-+-+-+-+-+-+-+-+ 446 Figure 5 448 * N bit : When the locator uniquely identifies a node in the 449 network (i.e., it is provisioned on one and only one node), the 450 N bit MUST be set. Otherwise, this bit MUST be clear. 452 * A bit : When the Locator is configured as anycast, the A bit 453 SHOULD be set. Otherwise, this bit MUST be clear. If both the 454 N and A bits are set, then the receiving routers MUST ignore 455 the N bit (i.e., consider it as not set). 457 * Other flags are not defined and SHOULD be set to 0 and MUST be 458 ignored on receipt. 460 Metric : 32 bit field. The metric value associated with the 461 locator. 463 Locator : 128 bit field. This field encodes the advertised SRv6 464 Locator. 466 Sub-TLVs : Used to advertise Sub-TLVs that provide additional 467 attributes for the given SRv6 Locator and SRv6 SIDs associated 468 with it. 470 7. Advertisment of SRv6 End SIDs 472 The SRv6 End SID Sub-TLV is a Sub-TLV of the SRv6 Locator TLV in the 473 SRv6 Locator LSA (defined in Section 6). It is used to advertise the 474 SRv6 SIDs belonging to the node along with their associated endpoint 475 behaviors. SIDs associated with adjacencies are advertised as 476 described in Section 8. Every SRv6 enabled OSPFv3 router SHOULD 477 advertise at least one SRv6 SID associated with an END behavior for 478 its node as specified in [I-D.ietf-spring-srv6-network-programming]. 480 SRv6 End SIDs inherit the algorithm from the parent locator. The 481 SRv6 End SID MUST be contained in the subnet of the associated 482 Locator. SRv6 End SIDs which are NOT in a subnet of the associated 483 locator MUST be ignored. 485 The router MAY advertise multiple instances of the SRv6 End SID Sub- 486 TLV within the SRv6 Locator TLV - one for each of the SRv6 SIDs to be 487 advertised. When multiple SRv6 End SID Sub-TLVs are received in the 488 SRv6 Locator TLV from a given router for the same SRv6 SID value, the 489 receiver MUST use the first occurrence of the Sub-TLV in the SRv6 490 Locator TLV. 492 The format of SRv6 End SID Sub-TLV is shown below 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type | Length | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Flags | Reserved | Endpoint Behavior | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | SID (128 bits) ... | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | SID cont ... | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | SID cont ... | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | SID cont ... | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Sub-TLVs (variable) . . . 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 Figure 6: SRv6 End SID Sub-TLV 514 Where: 516 Type: 16 bit field. Value is 1 for this type. 518 Length: 16 bit field. The total length of the value portion of 519 the Sub-TLVs. 521 Reserved : 8 bit field. Should be set to 0 and MUST be ignored on 522 receipt. 524 Flags: 8 bit field which define the flags associated with the SID. 525 No flags are currently defined and SHOULD be set to 0 and MUST be 526 ignored on receipt. 528 Endpoint Behavior: 16 bit field. The endpoint behavior code point 529 for this SRv6 SID as defined in section 9.2 of 530 [I-D.ietf-spring-srv6-network-programming]. 532 SID : 128 bit field. This field encodes the advertised SRv6 SID. 534 Sub-TLVs : Used to advertise Sub-TLVs that provide additional 535 attributes for the given SRv6 SID. 537 8. Advertisment of SRv6 SIDs Associated with Adjacencies 539 The SRv6 endpoint behaviors are defined in 540 [I-D.ietf-spring-srv6-network-programming] include certain behaviors 541 which are specific to links or adjacencies. The most basic of these 542 which is critical for link state routing protocols like OSPFv3 is the 543 End.X behavior that is an instruction to forward to a specific 544 neighbor on a specific link. These SRv6 SIDs along with others that 545 are defined in [I-D.ietf-spring-srv6-network-programming] which are 546 specific to links or adjacencies need to be advertised by OSPFv3 so 547 that this information is available to all routers in the area to 548 influence the packet path via these SRv6 SIDs over the specific 549 adjacencies. 551 The advertisement of SRv6 SIDs and their behaviors that are specific 552 to a particular neighbor is done via two different optional Sub-TLVs 553 of the E-Router-Link TLV defined in [RFC8362] as follows: 555 o SRv6 End.X SID Sub-TLV: For OSPFv3 adjacencies over point-to-point 556 or point-to-multipoint links and the adjacency to the Designated 557 Router (DR) over broadcast and non-broadcast-multi-access (NBMA) 558 links. 560 o SRv6 LAN End.X SID Sub-TLV: For OSPFv3 adjacencies on broadcast 561 and NBMA links to the Backup DR and DR-Other neighbors. This Sub- 562 TLV includes the OSPFv3 router-id of the neighbor and thus allows 563 for an instance of this Sub-TLV for each neighbor to be explicitly 564 advertised under the E-Router-Link TLV for the same link. 566 Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one 567 unique SRv6 End.X SID corresponding to each of its neighbor. A 568 router MAY instantiate more than one SRv6 End.X SID for for a single 569 neighbor. The same SRv6 End.X SID MAY be advertised for more than 570 one neighbor. Thus multiple instances of the SRv6 End.X SID and SRv6 571 LAN End.X SID Sub-TLVs MAY be advertised within the E-Router-Link TLV 572 for a single link. 574 All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 575 Locator with the matching algorithm which is advertised by the same 576 node in an SRv6 Locator TLV. End.X SIDs which do not meet this 577 requirement MUST be ignored. This ensures that the node advertising 578 the End.X or LAN End.X SID is also advertising its corresponding 579 Locator with the algorithm that will be used for computing paths 580 destined to the SID. 582 8.1. SRv6 End.X SID Sub-TLV 584 The format of the SRv6 End.X SID Sub-TLV is shown below 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type | Length | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Endpoint Behavior | Flags | Reserved1 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Algorithm | Weight | Reserved2 | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | SID (128 bits) ... | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | SID cont ... | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | SID cont ... | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | SID cont ... | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Sub-TLVs (variable) . . . 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Where: 608 Type: 16 bit field. Value is TBD. 610 Length: 16 bit field. The total length of the value portion of 611 the TLV. 613 Endpoint Behavior: 16 bit field. The code point for the endpoint 614 behavior for this SRv6 SID as defined in section 9.2 of 615 [I-D.ietf-spring-srv6-network-programming]. 617 Flags: 8 bit field with the following definition: 619 0 1 2 3 4 5 6 7 620 +-+-+-+-+-+-+-+-+ 621 |B|S|P| Reserved| 622 +-+-+-+-+-+-+-+-+ 624 * B-Flag: Backup Flag. If set, the SID refers to a path that is 625 eligible for protection. 627 * S-Flag: Set Flag. When set, the S-Flag indicates that the 628 End.X SID refers to a set of adjacencies (and therefore MAY be 629 assigned to other adjacencies as well). 631 * P-Flag: Persistent Flag: If set, the SID is persistently 632 allocated, i.e., the SID value remains consistent across router 633 restart and session/interface flap. 635 * Reserved bits: Reserved for future use and MUST be zero when 636 originated and ignored on receipt. 638 Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored 639 on receipt. 641 Algorithm : 8 bit field. Associated algorithm. Algorithm values 642 are defined in the IGP Algorithm Type registry. 644 Weight: 8 bit field whose value represents the weight of the End.X 645 SID for the purpose of load-balancing. The use of the weight is 646 defined in [RFC8402]. 648 Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored 649 on receipt. 651 SID: 128 bit field. This field encodes the advertised SRv6 SID. 653 Sub-TLVs : Used to advertise Sub-TLVs that provide additional 654 attributes for the given SRv6 End.X SID. 656 8.2. SRv6 LAN End.X SID Sub-TLV 658 The format of the SRv6 LAN End.X SID Sub-TLV is as shown below 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Type | Length | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Endpoint Behavior | Flags | Reserved1 | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Algorithm | Weight | Reserved2 | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | OSPFv3 Router-ID of neighbor | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | SID (128 bits) ... | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | SID cont ... | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | SID cont ... | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | SID cont ... | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Sub-TLVs (variable) . . . 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Where 684 o Type: 16 bit field. Value is TBD. 686 o Length: 16 bit field. Variable 688 o Endpoint Behavior: 16 bit field. The code point for the endpoint 689 behavior for this SRv6 SID as defined in section 9.2 of 690 [I-D.ietf-spring-srv6-network-programming]. 692 o SID Flags: 8 bit field which define the flags associated with the 693 SID. No flags are currently defined and SHOULD be set to 0 and 694 MUST be ignored on receipt. 696 o Flags: 8 bit field with the following definition: 698 0 1 2 3 4 5 6 7 699 +-+-+-+-+-+-+-+-+ 700 |B|S|P| Reserved| 701 +-+-+-+-+-+-+-+-+ 702 * B-Flag: Backup Flag. If set, the SID refers to a path that is 703 eligible for protection. 705 * S-Flag: Set Flag. When set, the S-Flag indicates that the 706 End.X SID refers to a set of adjacencies (and therefore MAY be 707 assigned to other adjacencies as well). 709 * P-Flag: Persistent Flag: If set, the SID is persistently 710 allocated, i.e., the SID value remains consistent across router 711 restart and session/interface flap. 713 * Reserved bits: Reserved for future use and MUST be zero when 714 originated and ignored on receipt. 716 o Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored 717 on receipt. 719 o Algorithm : 8 bit field. Associated algorithm. Algorithm values 720 are defined in the IGP Algorithm Type registry. 722 o Weight: 8 bit field whose value represents the weight of the End.X 723 SID for the purpose of load balancing. The use of the weight is 724 defined in [RFC8402]. 726 o Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored 727 on receipt. 729 o Neighbor ID : 32 bits of OSPFv3 Router-id of the neighbor 731 o SID: 128 bit field. This field encodes the advertised SRv6 SID. 733 o Sub-TLVs : Used to advertise Sub-TLVs that provide additional 734 attributes for the given SRv6 SID. 736 9. SRv6 SID Structure Sub-TLV 738 SRv6 SID Structure Sub-TLV is used to advertise the length of each 739 individual part of the SRv6 SID as defined in 740 [I-D.ietf-spring-srv6-network-programming]. It is used as an 741 optional Sub-TLV of the following: 743 o SRv6 End SID Sub-TLV (refer Section 7) 745 o SRv6 End.X SID Sub-TLV (refer Section 8.1) 747 o SRv6 LAN End.X SID Sub-TLV (refer Section 8.2) 749 The Sub-TLV has the following format: 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Type | Length | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | LB Length | LN Length | Fun. Length | Arg. Length | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Figure 7: SRv6 SID Structure Sub-TLV 761 Where: 763 Type: 16 bit field with value TBD, see Section 12. 765 Length: 16 bit field with the value 4. 767 LB Length: 8 bit field. SRv6 SID Locator Block length in bits. 769 LN Length: 8 bit field. SRv6 SID Locator Node length in bits. 771 Function Length: 8 bit field. SRv6 SID Function length in bits. 773 Argument Length: 8 bit field. SRv6 SID Argument length in bits. 775 10. Advertising Endpoint Behaviors 777 Endpoint behaviors are defined in 778 [I-D.ietf-spring-srv6-network-programming] and 779 [I-D.ietf-6man-spring-srv6-oam]. The codepoints for the Endpoint 780 behaviors are defined in the section 9.2 of 781 [I-D.ietf-spring-srv6-network-programming]. This section lists the 782 Endpoint behaviors and their codepoints, which MAY be advertised by 783 OSPFv3 and the Sub-TLVs in which each type MAY appear. 785 |-----------------------|--------------------|-----|-------|-----------| 786 | Endpoint | Endpoint | End | End.X | LAN End.X | 787 | Behavior | Behavior Codepoint | SID | SID | SID | 788 |-----------------------|--------------------|-----|-------|-----------| 789 | End (PSP, USP, USD) | 1-4, 28-31 | Y | N | N | 790 |-----------------------|--------------------|-----|-------|-----------| 791 | End.X (PSP, USP, USD) | 5-8, 32-35 | N | Y | Y | 792 |-----------------------|--------------------|-----|-------|-----------| 793 | End.T (PSP, USP, USD) | 9-12, 36-39 | Y | N | N | 794 |-----------------------|--------------------|-----|-------|-----------| 795 | End.DX6 | 16 | N | Y | Y | 796 |-----------------------|--------------------|-----|-------|-----------| 797 | End.DX4 | 17 | N | Y | Y | 798 |-----------------------|--------------------|-----|-------|-----------| 799 | End.DT6 | 18 | Y | N | N | 800 |-----------------------|--------------------|-----|-------|-----------| 801 | End.DT4 | 19 | Y | N | N | 802 |-----------------------|--------------------|-----|-------|-----------| 803 | End.DT64 | 20 | Y | N | N | 804 |-----------------------|--------------------|-----|-------|-----------| 805 | End.OP | 40 | Y | N | N | 806 |-----------------------|--------------------|-----|-------|-----------| 807 | End.OTP | 41 | Y | N | N | 808 |-----------------------|--------------------|-----|-------|-----------| 810 Figure 8: SRv6 Endpoint Behaviors in OSPFv3 812 11. Security Considerations 814 Existing security extensions as described in [RFC5340] and [RFC8362] 815 apply to these SRv6 extensions. While OSPFv3 is under a single 816 administrative domain, there can be deployments where potential 817 attackers have access to one or more networks in the OSPFv3 routing 818 domain. In these deployments, stronger authentication mechanisms 819 such as those specified in [RFC4552] or [RFC7166] SHOULD be used. 821 Implementations MUST assure that malformed TLV and Sub-TLV defined in 822 this document are detected and do not provide a vulnerability for 823 attackers to crash the OSPFv3 router or routing process. Reception 824 of malformed TLV or Sub-TLV SHOULD be counted and/or logged for 825 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be 826 rate-limited to prevent a Denial of Service (DoS) attack (distributed 827 or otherwise) from overloading the OSPFv3 control plane. 829 12. IANA Considerations 831 This document specifies updates to multiple OSPF and OSPFv3 related 832 IANA registries as follows. 834 12.1. OSPF Router Information TLVs 836 This document proposes the following new code point in the "OSPF 837 Router Information (RI) TLVs" registry under the "OSPF Parameters" 838 registry for the new TLVs: 840 Type TBD (suggested 20): SRv6-Capabilities TLV: Refer to 841 Section 2. 843 12.2. OSPFv3 LSA Function Codes 845 This document proposes the following new code point in the "OSPFv3 846 LSA Function Codes" registry under the "OSPFv3 Parameters" registry 847 for the new SRv6 Locator LSA: 849 o Type TBD (suggested 42): SRv6 Locator LSA: Refer to Section 6. 851 12.3. OSPFv3 Extended-LSA Sub-TLVs 853 This document proposes the following new code points in the "OSPFv3 854 Extended-LSA Sub-TLVs" registry under the "OSPFv3 Parameters" 855 registry for the new Sub-TLVs: 857 o Type TBD (suggested 10): SRv6 SID Structure Sub-TLV : Refer to 858 Section 9. 860 o Type TBD (suggested 11): SRv6 End.X SID Sub-TLV : Refer to 861 Section 8.1. 863 o Type TBD (suggested 12): SRv6 LAN End.X SID Sub-TLV : Refer to 864 Section 8.2. 866 12.4. OSPFv3 Locator LSA TLVs 868 This document proposes setting up of a new "OSPFv3 Locator LSA TLVs" 869 registry that defines top-level TLVs for the OSPFv3 SRv6 Locator LSA 870 to be added under the "OSPFv3 Parameters" registry. The initial 871 code-points assignment is as below: 873 o Type 0: Reserved. 875 o Type 1: SRv6 Locator TLV : Refer to Section 6.1. 877 Types in the range 2-32767 are allocated via IETF Review or IESG 878 Approval [RFC8126]. 880 Types in the range 32768-33023 are Reserved for Experimental Use; 881 these will not be registered with IANA and MUST NOT be mentioned by 882 RFCs. 884 Types in the range 33024-45055 are to be assigned on a First Come 885 First Served (FCFS) basis. 887 Types in the range 45056-65535 are not to be assigned at this time. 888 Before any assignments can be made in the 33024-65535 range, there 889 MUST be an IETF specification that specifies IANA Considerations that 890 cover the range being assigned. 892 12.5. OSPFv3 Locator LSA Sub-TLVs 894 This document proposes setting up of a new "OSPFv3 Locator LSA Sub- 895 TLVs" registry that defines Sub-TLVs at any level of nesting for the 896 SRv6 Locator TLVs to be added under the "OSPFv3 Parameters" registry. 897 The initial code-points assignment is as below: 899 o Type 0: Reserved. 901 o Type 1: SRv6 End SID Sub-TLV : Refer to Section 7. 903 o Type 10: SRv6 SID Structure Sub-TLV : Refer to Section 9. 905 Types in the range 2-9 and 11-32767 are allocated via IETF Review or 906 IESG Approval [RFC8126]. 908 Types in the range 32768-33023 are Reserved for Experimental Use; 909 these will not be registered with IANA and MUST NOT be mentioned by 910 RFCs. 912 Types in the range 33024-45055 are to be assigned on a First Come 913 First Served (FCFS) basis. 915 Types in the range 45056-65535 are not to be assigned at this time. 916 Before any assignments can be made in the 33024-65535 range, there 917 MUST be an IETF specification that specifies IANA Considerations that 918 cover the range being assigned. 920 13. Acknowledgements 922 The authors would like to thank Acee Lindem and Chenzichao for their 923 review and comments on this document. 925 14. References 927 14.1. Normative References 929 [I-D.ietf-6man-spring-srv6-oam] 930 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 931 Chen, "Operations, Administration, and Maintenance (OAM) 932 in Segment Routing Networks with IPv6 Data plane (SRv6)", 933 draft-ietf-6man-spring-srv6-oam-07 (work in progress), 934 July 2020. 936 [I-D.ietf-lsr-isis-srv6-extensions] 937 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 938 Z. Hu, "IS-IS Extension to Support Segment Routing over 939 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 940 (work in progress), April 2020. 942 [I-D.ietf-spring-srv6-network-programming] 943 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 944 Matsushima, S., and Z. Li, "SRv6 Network Programming", 945 draft-ietf-spring-srv6-network-programming-17 (work in 946 progress), August 2020. 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, 950 DOI 10.17487/RFC2119, March 1997, 951 . 953 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 954 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 955 . 957 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 958 S. Shaffer, "Extensions to OSPF for Advertising Optional 959 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 960 February 2016, . 962 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 963 Writing an IANA Considerations Section in RFCs", BCP 26, 964 RFC 8126, DOI 10.17487/RFC8126, June 2017, 965 . 967 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 968 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 969 May 2017, . 971 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 972 F. Baker, "OSPFv3 Link State Advertisement (LSA) 973 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 974 2018, . 976 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 977 Decraene, B., Litkowski, S., and R. Shakir, "Segment 978 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 979 July 2018, . 981 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 982 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 983 DOI 10.17487/RFC8476, December 2018, 984 . 986 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 987 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 988 Extensions for Segment Routing", RFC 8665, 989 DOI 10.17487/RFC8665, December 2019, 990 . 992 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 993 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 994 December 2019, . 996 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 997 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 998 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 999 . 1001 14.2. Informative References 1003 [I-D.ietf-lsr-flex-algo] 1004 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1005 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1006 algo-08 (work in progress), July 2020. 1008 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1009 (TE) Extensions to OSPF Version 2", RFC 3630, 1010 DOI 10.17487/RFC3630, September 2003, 1011 . 1013 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1014 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 1015 . 1017 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 1018 Authentication Trailer for OSPFv3", RFC 7166, 1019 DOI 10.17487/RFC7166, March 2014, 1020 . 1022 Authors' Addresses 1024 Zhenbin Li 1025 Huawei Technologies 1027 Email: lizhenbin@huawei.com 1029 Zhibo Hu 1030 Huawei Technologies 1032 Email: huzhibo@huawei.com 1034 Dean Cheng 1035 Huawei Technologies 1037 Email: dean.cheng@huawei.com 1039 Ketan Talaulikar (editor) 1040 Cisco Systems 1041 India 1043 Email: ketant@cisco.com 1045 Peter Psenak 1046 Cisco Systems 1047 Slovakia 1049 Email: ppsenak@cisco.com