idnits 2.17.1 draft-ietf-lsr-ospfv3-srv6-extensions-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 date (February 12, 2020) is 1533 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-03 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-04 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-09 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-05 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: August 15, 2020 Huawei Technologies 6 K. Talaulikar, Ed. 7 P. Psenak 8 Cisco Systems 9 February 12, 2020 11 OSPFv3 Extensions for SRv6 12 draft-ietf-lsr-ospfv3-srv6-extensions-00 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 August 15, 2020. 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 . . . . . . . . . . . . . . . . 6 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 98 [I-D.ietf-6man-segment-routing-header]. SRv6 refers to this SR 99 instantiation on the IPv6 dataplane. The network programming 100 paradigm for SRv6 is specified in 101 [I-D.ietf-spring-srv6-network-programming] which describes several 102 well-known behaviors that can be bound to SRv6 SIDs. 104 This document specifies extensions to OSPFv3 in order to support SRv6 105 as defined in [I-D.ietf-spring-srv6-network-programming] by signaling 106 the SRv6 capabilities of the node and certain SRv6 SIDs with their 107 endpoint behaviors (e.g., End, End.X, etc.) that are instantiated on 108 the SRv6 capable router. 110 At a high level, the extensions to OSPFv3 are comprised of the 111 following: 113 1. SRv6 Capabilities TLV to advertise the SRv6 features and SRH 114 operations supported by the router 116 2. SRv6 Locator TLV to advertise the SRv6 Locator - a form of 117 summary address for the algorithm specific SIDs instantiated on 118 the router 120 3. TLVs and Sub-TLVs to advertise the SRv6 SIDs instantiated on the 121 router along with their endpoint behaviors 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 2. SRv6 Capabilities TLV 133 The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise 134 its SRv6 support along with its related capabilities for SRv6 135 functionality. This is an optional top level TLV of the OSPFv3 136 Router Information LSA [RFC7770] which MUST be advertised by an SRv6 137 enabled router. 139 This TLV SHOULD be advertised only once in the OSPFv3 Router 140 Information LSA. When multiple SRv6 Capabilities TLVs are received 141 from a given router, the receiver MUST use the first occurrence of 142 the TLV in the OSPFV3 Router Information Opaque LSA. If the SRv6 143 Capabilities TLV appears in multiple OSPFv3 Router Information Opaque 144 LSAs that have different flooding scopes, the TLV in the OSPFv3 145 Router Information Opaque LSA with the area-scoped flooding scope 146 MUST be used. If the SRv6 Capabilities TLV appears in multiple 147 OSPFv3 Router Information Opaque LSAs that have the same flooding 148 scope, the TLV in the OSPFv3 Router Information Opaque LSA with the 149 numerically smallest Instance ID MUST be used and subsequent 150 instances of the TLV MUST be ignored. 152 The OSPFv3 Router Information Opaque LSA can be advertised at any of 153 the defined opaque flooding scopes (link, area, or Autonomous System 154 (AS)). For the purpose of SRv6 Capabilities TLV advertisement, area- 155 scoped flooding is REQUIRED. 157 The format of OSPFv3 SRv6 Capabilities TLV is shown below 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type | Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Flags | Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Sub-TLVs... 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Where: 171 o Type: 16 bit field. Value is TBD. 173 o Length: 16 bit field. Length of Capability TLV + length of Sub- 174 TLVs 176 o Reserved : 16 bit field. SHOULD be set to 0 and MUST be ignored 177 on receipt. 179 o Flags: 16 bit field. The following flags are defined and others 180 SHOULD be set to 0 and MUST be ignored on receipt: 182 0 1 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | |O| | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 where: 190 * O-flag: If set, then the router is capable of supporting the 191 SRH O-bit, as specified in [I-D.ietf-6man-spring-srv6-oam]. 193 The SRv6 Capabilities TLV may contain optional Sub-TLVs. No Sub-TLVs 194 are currently defined. 196 3. Advertisement of Supported Algorithms 198 SRv6 enabled OSPFv3 router advertises its algorithm support using the 199 SR Algorithm TLV defined in [RFC8665] as described in [RFC8666]. 201 4. Advertisement of SRH Operation Limits 203 An SRv6 enabled router may have different capabilities and limits 204 when it comes to SRH processing and this needs to be advertised to 205 other routers in the SRv6 domain. 207 [RFC8476] defines the means to advertise node/link specific values 208 for Maximum SID Depth (MSD) types. Node MSDs are advertised using 209 the Node MSD TLV in the OSPFv3 Router Information LSA [RFC7770] while 210 Link MSDs are advertised using the Link MSD Sub-TLV of the E-Router- 211 LSA TLV [RFC8362]. The format of the MSD types for OSPFv3 is defined 212 in [RFC8476]. 214 The MSD types for SRv6 that are defined in section 4 of 215 [I-D.ietf-lsr-isis-srv6-extensions] for IS-IS are also used by 216 OSPFv3. These MSD Types are allocated under the IGP MSD Types 217 registry maintained by IANA that are shared by IS-IS and OSPF. They 218 are described below: 220 4.1. Maximum Segments Left MSD Type 222 The Maximum Segments Left MSD Type specifies the maximum value of the 223 "SL" field [I-D.ietf-6man-segment-routing-header] in the SRH of a 224 received packet before applying the Endpoint behavior associated with 225 a SID. If no value is advertised, the supported value is assumed to 226 be 0. 228 4.2. Maximum End Pop MSD Type 230 The Maximum End Pop MSD Type specifies the maximum number of SIDs in 231 the SRH for which the router can apply Penultimate Segment Pop (PSP) 232 or Ultimate Segment Pop (USP) as defined in 233 [I-D.ietf-spring-srv6-network-programming] flavors. If the 234 advertised value is zero or no value is advertised, then it is 235 assumed that the router cannot apply PSP or USP. 237 4.3. Maximum H.Encaps MSD Type 239 The Maximum H.Encaps MSD Type specifies the maximum number of SIDs 240 that can be included as part of the "H.Encaps" behavior as defined in 241 [I-D.ietf-spring-srv6-network-programming]. If the advertised value 242 is zero then the router can apply H.Encaps only by encapsulating the 243 incoming packet in another IPv6 header without SRH the same way 244 IPinIP encapsulation is performed. If the advertised value is non- 245 zero, then the router supports both IPinIP and SRH encapsulation 246 subject to the SID limitation specified by the advertised value. 248 4.4. Maximum End D MSD Type 250 The Maximum End D MSD Type specifies the maximum number of SIDs in an 251 SRH when performing decapsulation associated with "End.Dx" behaviors 252 (e.g., "End.DX6" and "End.DT6") as defined in 253 [I-D.ietf-spring-srv6-network-programming]. If the advertised value 254 is zero or no value is advertised, then it is assumed that the router 255 cannot apply "End.DX6" or "End.DT6" behaviors if the extension header 256 right underneath the outer IPv6 header is an SRH. 258 5. Advertisement of SRv6 Locator and End SIDs 260 An SRv6 Segment Identifier (SID) is 128 bits and comprises of 261 Locator, Function and Argument parts as described in 262 [I-D.ietf-spring-srv6-network-programming]. 264 A node is provisioned with algorithm specific locators for each 265 algorithm supported by that node. Each locator is a prefix subsuming 266 all SIDs provisioned on that node which have the matching algorithm. 268 Locators MUST be advertised in the SRv6 Locator LSA (see Section 6). 269 Forwarding entries for the locators advertised in the SRv6 Locator 270 LSA MUST be installed in the forwarding plane of receiving SRv6 271 capable routers when the associated algorithm is supported by the 272 receiving node. Locators can be of different route types similar to 273 existing OSPF LSA route types - Intra-Area, Inter-Area, External, and 274 NSSA. The computation of locator reachability and their 275 advertisement are similar to how normal OSPF prefix reachability LSAs 276 are processed as part of the route computation. 278 Locators are routable and MAY also be advertised via Prefix LSAs of 279 different types - Inter-Area Prefix LSA, AS-External LSA, NSSA LSA, 280 or Intra-Area Prefix LSA (or their equivalent extended LSAs 281 [RFC8362]). Locators associated with Flexible Algorithms 282 [I-D.ietf-lsr-flex-algo] SHOULD NOT be advertised via Prefix LSAs. 283 Locators associated with algorithm 0 (for all supported topologies) 284 SHOULD be advertised in Prefix LSAs so that legacy routers (i.e., 285 routers which do NOT support SRv6) will install a forwarding entry 286 for algorithm 0 SRv6 traffic. 288 In cases where a locator advertisement is received in both in a 289 Prefix LSA and an SRv6 Locator LSA, the Prefix LSA advertisement MUST 290 be preferred when installing entries in the forwarding plane. This 291 is to prevent inconsistent forwarding entries on SRv6 capable/SRv6 292 incapable routers. 294 SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except 295 for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a 296 specific Neighbor/Link and are therefore advertised as Sub-TLVs of E- 297 Router-Link TLV. 299 SRv6 SIDs are not directly routable. SRv6 SIDs learnt by via 300 advertisements from remote routers MUST NOT be installed in the 301 forwarding plane. Reachability to SRv6 SIDs depends upon the 302 existence of a covering locator. Adherence to the rules defined in 303 this section will assure that SRv6 SIDs associated with a supported 304 algorithm will be forwarded correctly, while SRv6 SIDs associated 305 with an unsupported algorithm will be dropped. NOTE: The drop 306 behavior depends on the absence of a default/summary route covering a 307 given locator. 309 6. SRv6 Locator LSA 311 The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits 312 are dependent on the desired flooding scope for the LSA. The 313 flooding scope of the SRv6 Locator LSA depends on the scope of the 314 advertised SRv6 Locator and is under the control of the advertising 315 router. The U bit will be set indicating that the LSA should be 316 flooded even if it is not understood. 318 Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router and 319 they are distinguished by their Link State IDs (which are chosen 320 arbitrarily by the originating router). 322 The format of SRv6 Locator LSA is shown below: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | LS age |1|S12| Function Code | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Link State ID | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Advertising Router | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | LS sequence number | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | LS checksum | Length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 +- TLVs -+ 339 | ... | 341 Figure 1: SRv6 Locator LSA 343 The format of the TLVs within the body of the SRv6 Locator LSA is the 344 same as the format used by [RFC3630]. The variable TLV section 345 consists of one or more nested TLV tuples. Nested TLVs are also 346 referred to as Sub-TLVs. The format of each TLV is: 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type | Length | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Value | 354 o 355 o 356 o 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Figure 2: SRv6 Locator LSA TLV Format 362 The Length field defines the length of the value portion in octets 363 (thus, a TLV with no value portion would have a length of 0). The 364 TLV is padded to 4-octet alignment; padding is not included in the 365 Length field (so a 3-octet value would have a length of 3, but the 366 total size of the TLV would be 8 octets). Nested TLVs are also 367 32-bit aligned. For example, a 1-byte value would have the Length 368 field set to 1, and 3 octets of padding would be added to the end of 369 the value portion of the TLV. The padding is composed of zeros. 371 6.1. SRv6 Locator TLV 373 The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA that 374 is used to advertise an SRv6 Locator, its attributes, and SIDs 375 associated with it. Multiple SRv6 Locator TLVs MAY be advertised in 376 each SRv6 Locator LSA. However, since the S12 bits define the 377 flooding scope, the LSA flooding scope MUST satisfy the application- 378 specific requirements for all the locators included in a single SRv6 379 Locator LSA. 381 When multiple SRv6 Locator TLVs are received from a given router in 382 an SRv6 Locator LSA for the same Locator, the receiver MUST use the 383 first occurrence of the TLV in the LSA. If the SRv6 Locator TLV for 384 the same Locator appears in multiple SRv6 Locator LSAs that have 385 different flooding scopes, the TLV in the SRv6 Locator LSA with the 386 area-scoped flooding scope MUST be used. If the SRv6 Locator TLV for 387 the same Locator appears in multiple SRv6 Locator LSAs that have the 388 same flooding scope, the TLV in the SRv6 Locator LSA with the 389 numerically smallest Link-State ID MUST be used and subsequent 390 instances of the TLV MUST be ignored. 392 The format of SRv6 Locator TLV is shown below: 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type | Length | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Route Type | Algorithm | Locator Length| Flags | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Metric | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Locator (128 bits) ... | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Locator cont ... | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Locator cont ... | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Locator cont ... | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Sub-TLVs (variable) | 412 +- -+ 413 | ... | 415 Figure 3: SRv6 Locator TLV 417 Where: 419 Type: 16 bit field. The value is 1 for this type. 421 Length: 16 bit field. The total length of the value portion of 422 the TLV including Sub-TLVs. 424 Route Type : 8 bit field. The type of the locator route. 425 Supported types are the ones listed below and other other types 426 MUST be ignored on receipt. 428 1 - Intra-Area 429 2 - Inter-Area 430 3 - AS External 431 4 - NSSA External 433 Figure 4 435 Algorithm: 8 bit field. Associated algorithm. Algorithm values 436 are defined in the IGP Algorithm Type registry. 438 Locator Length: 8 bit field. Carries the length of the Locator 439 prefix as the number of locator bits (1-128). 441 Flags: 8 bit field. The following flags are defined 443 0 1 2 3 4 5 6 7 444 +-+-+-+-+-+-+-+-+ 445 |N|A| Reserved | 446 +-+-+-+-+-+-+-+-+ 448 Figure 5 450 * N bit : When the locator uniquely identifies a node in the 451 network (i.e., it is provisioned on one and only one node), the 452 N bit MUST be set. Otherwise, this bit MUST be clear. 454 * A bit : When the Locator is configured as anycast, the A bit 455 SHOULD be set. Otherwise, this bit MUST be clear. If both the 456 N and A bits are set, then the receiving routers MUST ignore 457 the N bit (i.e., consider it as not set). 459 * Other flags are not defined and SHOULD be set to 0 and MUST be 460 ignored on receipt. 462 Metric : 32 bit field. The metric value associated with the 463 locator. 465 Locator : 128 bit field. This field encodes the advertised SRv6 466 Locator. 468 Sub-TLVs : Used to advertise Sub-TLVs that provide additional 469 attributes for the given SRv6 Locator and SRv6 SIDs associated 470 with it. 472 7. Advertisment of SRv6 End SIDs 474 The SRv6 End SID Sub-TLV is a Sub-TLV of the SRv6 Locator TLV in the 475 SRv6 Locator LSA (defined in Section 6). It is used to advertise the 476 SRv6 SIDs belonging to the node along with their associated endpoint 477 behaviors. SIDs associated with adjacencies are advertised as 478 described in Section 8. Every SRv6 enabled OSPFv3 router SHOULD 479 advertise at least one SRv6 SID associated with an END behavior for 480 its node as specified in [I-D.ietf-spring-srv6-network-programming]. 482 SRv6 End SIDs inherit the algorithm from the parent locator. The 483 SRv6 End SID MUST be contained in the subnet of the associated 484 Locator. SRv6 End SIDs which are NOT in a subnet of the associated 485 locator MUST be ignored. 487 The router MAY advertise multiple instances of the SRv6 End SID Sub- 488 TLV within the SRv6 Locator TLV - one for each of the SRv6 SIDs to be 489 advertised. When multiple SRv6 End SID Sub-TLVs are received in the 490 SRv6 Locator TLV from a given router for the same SRv6 SID value, the 491 receiver MUST use the first occurrence of the Sub-TLV in the SRv6 492 Locator TLV. 494 The format of SRv6 End SID Sub-TLV is shown below 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type | Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Flags | Reserved | Endpoint Behavior | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | SID (128 bits) ... | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | SID cont ... | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | SID cont ... | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | SID cont ... | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Sub-TLVs (variable) . . . 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Figure 6: SRv6 End SID Sub-TLV 516 Where: 518 Type: 16 bit field. Value is 1 for this type. 520 Length: 16 bit field. The total length of the value portion of 521 the Sub-TLVs. 523 Reserved : 8 bit field. Should be set to 0 and MUST be ignored on 524 receipt. 526 Flags: 8 bit field which define the flags associated with the SID. 527 No flags are currently defined and SHOULD be set to 0 and MUST be 528 ignored on receipt. 530 Endpoint Behavior: 16 bit field. The endpoint behavior code point 531 for this SRv6 SID as defined in section 9.2 of 532 [I-D.ietf-spring-srv6-network-programming]. 534 SID : 128 bit field. This field encodes the advertised SRv6 SID. 536 Sub-TLVs : Used to advertise Sub-TLVs that provide additional 537 attributes for the given SRv6 SID. 539 8. Advertisment of SRv6 SIDs Associated with Adjacencies 541 The SRv6 endpoint behaviors are defined in 542 [I-D.ietf-spring-srv6-network-programming] include certain behaviors 543 which are specific to links or adjacencies. The most basic of these 544 which is critical for link state routing protocols like OSPFv3 is the 545 End.X behavior that is an instruction to forward to a specific 546 neighbor on a specific link. These SRv6 SIDs along with others that 547 are defined in [I-D.ietf-spring-srv6-network-programming] which are 548 specific to links or adjacencies need to be advertised by OSPFv3 so 549 that this information is available to all routers in the area to 550 influence the packet path via these SRv6 SIDs over the specific 551 adjacencies. 553 The advertisement of SRv6 SIDs and their behaviors that are specific 554 to a particular neighbor is done via two different optional Sub-TLVs 555 of the E-Router-Link TLV defined in [RFC8362] as follows: 557 o SRv6 End.X SID Sub-TLV: For OSPFv3 adjacencies over point-to-point 558 or point-to-multipoint links and the adjacency to the Designated 559 Router (DR) over broadcast and non-broadcast-multi-access (NBMA) 560 links. 562 o SRv6 LAN End.X SID Sub-TLV: For OSPFv3 adjacencies on broadcast 563 and NBMA links to the Backup DR and DR-Other neighbors. This Sub- 564 TLV includes the OSPFv3 router-id of the neighbor and thus allows 565 for an instance of this Sub-TLV for each neighbor to be explicitly 566 advertised under the E-Router-Link TLV for the same link. 568 Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one 569 unique SRv6 End.X SID corresponding to each of its neighbor. A 570 router MAY instantiate more than one SRv6 End.X SID for for a single 571 neighbor. The same SRv6 End.X SID MAY be advertised for more than 572 one neighbor. Thus multiple instances of the SRv6 End.X SID and SRv6 573 LAN End.X SID Sub-TLVs MAY be advertised within the E-Router-Link TLV 574 for a single link. 576 All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 577 Locator with the matching algorithm which is advertised by the same 578 node in an SRv6 Locator TLV. End.X SIDs which do not meet this 579 requirement MUST be ignored. This ensures that the node advertising 580 the End.X or LAN End.X SID is also advertising its corresponding 581 Locator with the algorithm that will be used for computing paths 582 destined to the SID. 584 8.1. SRv6 End.X SID Sub-TLV 586 The format of the SRv6 End.X SID Sub-TLV is shown below 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type | Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Endpoint Behavior | Flags | Reserved1 | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Algorithm | Weight | Reserved2 | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | SID (128 bits) ... | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | SID cont ... | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | SID cont ... | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | SID cont ... | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Sub-TLVs (variable) . . . 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Where: 610 Type: 16 bit field. Value is TBD. 612 Length: 16 bit field. The total length of the value portion of 613 the TLV. 615 Endpoint Behavior: 16 bit field. The code point for the endpoint 616 behavior for this SRv6 SID as defined in section 9.2 of 617 [I-D.ietf-spring-srv6-network-programming]. 619 Flags: 8 bit field with the following definition: 621 0 1 2 3 4 5 6 7 622 +-+-+-+-+-+-+-+-+ 623 |B|S|P| Reserved| 624 +-+-+-+-+-+-+-+-+ 626 * B-Flag: Backup Flag. If set, the SID refers to a path that is 627 eligible for protection. 629 * S-Flag: Set Flag. When set, the S-Flag indicates that the 630 End.X SID refers to a set of adjacencies (and therefore MAY be 631 assigned to other adjacencies as well). 633 * P-Flag: Persistent Flag: If set, the SID is persistently 634 allocated, i.e., the SID value remains consistent across router 635 restart and session/interface flap. 637 * Reserved bits: Reserved for future use and MUST be zero when 638 originated and ignored on receipt. 640 Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored 641 on receipt. 643 Algorithm : 8 bit field. Associated algorithm. Algorithm values 644 are defined in the IGP Algorithm Type registry. 646 Weight: 8 bit field whose value represents the weight of the End.X 647 SID for the purpose of load-balancing. The use of the weight is 648 defined in [RFC8402]. 650 Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored 651 on receipt. 653 SID: 128 bit field. This field encodes the advertised SRv6 SID. 655 Sub-TLVs : Used to advertise Sub-TLVs that provide additional 656 attributes for the given SRv6 End.X SID. 658 8.2. SRv6 LAN End.X SID Sub-TLV 660 The format of the SRv6 LAN End.X SID Sub-TLV is as shown below 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Type | Length | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Endpoint Behavior | Flags | Reserved1 | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Algorithm | Weight | Reserved2 | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | OSPFv3 Router-ID of neighbor | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | SID (128 bits) ... | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | SID cont ... | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | SID cont ... | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | SID cont ... | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Sub-TLVs (variable) . . . 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Where 686 o Type: 16 bit field. Value is TBD. 688 o Length: 16 bit field. Variable 690 o Endpoint Behavior: 16 bit field. The code point for the endpoint 691 behavior for this SRv6 SID as defined in section 9.2 of 692 [I-D.ietf-spring-srv6-network-programming]. 694 o SID Flags: 8 bit field which define the flags associated with the 695 SID. No flags are currently defined and SHOULD be set to 0 and 696 MUST be ignored on receipt. 698 o Flags: 8 bit field with the following definition: 700 0 1 2 3 4 5 6 7 701 +-+-+-+-+-+-+-+-+ 702 |B|S|P| Reserved| 703 +-+-+-+-+-+-+-+-+ 704 * B-Flag: Backup Flag. If set, the SID refers to a path that is 705 eligible for protection. 707 * S-Flag: Set Flag. When set, the S-Flag indicates that the 708 End.X SID refers to a set of adjacencies (and therefore MAY be 709 assigned to other adjacencies as well). 711 * P-Flag: Persistent Flag: If set, the SID is persistently 712 allocated, i.e., the SID value remains consistent across router 713 restart and session/interface flap. 715 * Reserved bits: Reserved for future use and MUST be zero when 716 originated and ignored on receipt. 718 o Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored 719 on receipt. 721 o Algorithm : 8 bit field. Associated algorithm. Algorithm values 722 are defined in the IGP Algorithm Type registry. 724 o Weight: 8 bit field whose value represents the weight of the End.X 725 SID for the purpose of load balancing. The use of the weight is 726 defined in [RFC8402]. 728 o Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored 729 on receipt. 731 o Neighbor ID : 32 bits of OSPFv3 Router-id of the neighbor 733 o SID: 128 bit field. This field encodes the advertised SRv6 SID. 735 o Sub-TLVs : Used to advertise Sub-TLVs that provide additional 736 attributes for the given SRv6 SID. 738 9. SRv6 SID Structure Sub-TLV 740 SRv6 SID Structure Sub-TLV is used to advertise the length of each 741 individual part of the SRv6 SID as defined in 742 [I-D.ietf-spring-srv6-network-programming]. It is used as an 743 optional Sub-TLV of the following: 745 o SRv6 End SID Sub-TLV (refer Section 7) 747 o SRv6 End.X SID Sub-TLV (refer Section 8.1) 749 o SRv6 LAN End.X SID Sub-TLV (refer Section 8.2) 751 The Sub-TLV has the following format: 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Type | Length | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | LB Length | LN Length | Fun. Length | Arg. Length | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 Figure 7: SRv6 SID Structure Sub-TLV 763 Where: 765 Type: 16 bit field with value TBD, see Section 12. 767 Length: 16 bit field with the value 4. 769 LB Length: 8 bit field. SRv6 SID Locator Block length in bits. 771 LN Length: 8 bit field. SRv6 SID Locator Node length in bits. 773 Function Length: 8 bit field. SRv6 SID Function length in bits. 775 Argument Length: 8 bit field. SRv6 SID Argument length in bits. 777 10. Advertising Endpoint Behaviors 779 Endpoint behaviors are defined in 780 [I-D.ietf-spring-srv6-network-programming] and 781 [I-D.ietf-6man-spring-srv6-oam]. The codepoints for the Endpoint 782 behaviors are defined in the section 9.2 of 783 [I-D.ietf-spring-srv6-network-programming]. This section lists the 784 Endpoint behaviors and their codepoints, which MAY be advertised by 785 OSPFv3 and the Sub-TLVs in which each type MAY appear. 787 |-----------------------|--------------------|-----|-------|-----------| 788 | Endpoint | Endpoint | End | End.X | LAN End.X | 789 | Behavior | Behavior Codepoint | SID | SID | SID | 790 |-----------------------|--------------------|-----|-------|-----------| 791 | End (PSP, USP, USD) | 1-4, 28-31 | Y | N | N | 792 |-----------------------|--------------------|-----|-------|-----------| 793 | End.X (PSP, USP, USD) | 5-8, 32-35 | N | Y | Y | 794 |-----------------------|--------------------|-----|-------|-----------| 795 | End.T (PSP, USP, USD) | 9-12, 36-39 | Y | N | N | 796 |-----------------------|--------------------|-----|-------|-----------| 797 | End.DX6 | 16 | N | Y | Y | 798 |-----------------------|--------------------|-----|-------|-----------| 799 | End.DX4 | 17 | N | Y | Y | 800 |-----------------------|--------------------|-----|-------|-----------| 801 | End.DT6 | 18 | Y | N | N | 802 |-----------------------|--------------------|-----|-------|-----------| 803 | End.DT4 | 19 | Y | N | N | 804 |-----------------------|--------------------|-----|-------|-----------| 805 | End.DT64 | 20 | Y | N | N | 806 |-----------------------|--------------------|-----|-------|-----------| 807 | End.OP | 40 | Y | N | N | 808 |-----------------------|--------------------|-----|-------|-----------| 809 | End.OTP | 41 | Y | N | N | 810 |-----------------------|--------------------|-----|-------|-----------| 812 Figure 8: SRv6 Endpoint Behaviors in OSPFv3 814 11. Security Considerations 816 Existing security extensions as described in [RFC5340] and [RFC8362] 817 apply to these SRv6 extensions. While OSPFv3 is under a single 818 administrative domain, there can be deployments where potential 819 attackers have access to one or more networks in the OSPFv3 routing 820 domain. In these deployments, stronger authentication mechanisms 821 such as those specified in [RFC4552] or [RFC7166] SHOULD be used. 823 Implementations MUST assure that malformed TLV and Sub-TLV defined in 824 this document are detected and do not provide a vulnerability for 825 attackers to crash the OSPFv3 router or routing process. Reception 826 of malformed TLV or Sub-TLV SHOULD be counted and/or logged for 827 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be 828 rate-limited to prevent a Denial of Service (DoS) attack (distributed 829 or otherwise) from overloading the OSPFv3 control plane. 831 12. IANA Considerations 833 This document specifies updates to multiple OSPF and OSPFv3 related 834 IANA registries as follows. 836 12.1. OSPF Router Information TLVs 838 This document proposes the following new code point in the "OSPF 839 Router Information (RI) TLVs" registry under the "OSPF Parameters" 840 registry for the new TLVs: 842 Type TBD (suggested 17): SRv6-Capabilities TLV: Refer to 843 Section 2. 845 12.2. OSPFv3 LSA Function Codes 847 This document proposes the following new code point in the "OSPFv3 848 LSA Function Codes" registry under the "OSPFv3 Parameters" registry 849 for the new SRv6 Locator LSA: 851 o Type TBD (suggested 42): SRv6 Locator LSA: Refer to Section 6. 853 12.3. OSPFv3 Extended-LSA Sub-TLVs 855 This document proposes the following new code points in the "OSPFv3 856 Extended-LSA Sub-TLVs" registry under the "OSPFv3 Parameters" 857 registry for the new Sub-TLVs: 859 o Type TBD (suggested 10): SRv6 SID Structure Sub-TLV : Refer to 860 Section 9. 862 o Type TBD (suggested 11): SRv6 End.X SID Sub-TLV : Refer to 863 Section 8.1. 865 o Type TBD (suggested 12): SRv6 LAN End.X SID Sub-TLV : Refer to 866 Section 8.2. 868 12.4. OSPFv3 Locator LSA TLVs 870 This document proposes setting up of a new "OSPFv3 Locator LSA TLVs" 871 registry that defines top-level TLVs for the OSPFv3 SRv6 Locator LSA 872 to be added under the "OSPFv3 Parameters" registry. The initial 873 code-points assignment is as below: 875 o Type 0: Reserved. 877 o Type 1: SRv6 Locator TLV : Refer to Section 6.1. 879 Types in the range 2-32767 are allocated via IETF Review or IESG 880 Approval [RFC8126]. 882 Types in the range 32768-33023 are Reserved for Experimental Use; 883 these will not be registered with IANA and MUST NOT be mentioned by 884 RFCs. 886 Types in the range 33024-45055 are to be assigned on a First Come 887 First Served (FCFS) basis. 889 Types in the range 45056-65535 are not to be assigned at this time. 890 Before any assignments can be made in the 33024-65535 range, there 891 MUST be an IETF specification that specifies IANA Considerations that 892 cover the range being assigned. 894 12.5. OSPFv3 Locator LSA Sub-TLVs 896 This document proposes setting up of a new "OSPFv3 Locator LSA Sub- 897 TLVs" registry that defines Sub-TLVs at any level of nesting for the 898 SRv6 Locator TLVs to be added under the "OSPFv3 Parameters" registry. 899 The initial code-points assignment is as below: 901 o Type 0: Reserved. 903 o Type 1: SRv6 End SID Sub-TLV : Refer to Section 7. 905 o Type 10: SRv6 SID Structure Sub-TLV : Refer to Section 9. 907 Types in the range 2-9 and 11-32767 are allocated via IETF Review or 908 IESG Approval [RFC8126]. 910 Types in the range 32768-33023 are Reserved for Experimental Use; 911 these will not be registered with IANA and MUST NOT be mentioned by 912 RFCs. 914 Types in the range 33024-45055 are to be assigned on a First Come 915 First Served (FCFS) basis. 917 Types in the range 45056-65535 are not to be assigned at this time. 918 Before any assignments can be made in the 33024-65535 range, there 919 MUST be an IETF specification that specifies IANA Considerations that 920 cover the range being assigned. 922 13. Acknowledgements 924 The authors would like to thank Acee Lindem and Chenzichao for their 925 review and comments on this document. 927 14. References 929 14.1. Normative References 931 [I-D.ietf-6man-segment-routing-header] 932 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 933 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 934 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 935 progress), October 2019. 937 [I-D.ietf-6man-spring-srv6-oam] 938 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 939 Chen, "Operations, Administration, and Maintenance (OAM) 940 in Segment Routing Networks with IPv6 Data plane (SRv6)", 941 draft-ietf-6man-spring-srv6-oam-03 (work in progress), 942 December 2019. 944 [I-D.ietf-lsr-isis-srv6-extensions] 945 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 946 Z. Hu, "IS-IS Extension to Support Segment Routing over 947 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-04 948 (work in progress), January 2020. 950 [I-D.ietf-spring-srv6-network-programming] 951 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 952 Matsushima, S., and Z. Li, "SRv6 Network Programming", 953 draft-ietf-spring-srv6-network-programming-09 (work in 954 progress), February 2020. 956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 957 Requirement Levels", BCP 14, RFC 2119, 958 DOI 10.17487/RFC2119, March 1997, 959 . 961 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 962 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 963 . 965 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 966 S. Shaffer, "Extensions to OSPF for Advertising Optional 967 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 968 February 2016, . 970 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 971 Writing an IANA Considerations Section in RFCs", BCP 26, 972 RFC 8126, DOI 10.17487/RFC8126, June 2017, 973 . 975 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 976 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 977 May 2017, . 979 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 980 F. Baker, "OSPFv3 Link State Advertisement (LSA) 981 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 982 2018, . 984 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 985 Decraene, B., Litkowski, S., and R. Shakir, "Segment 986 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 987 July 2018, . 989 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 990 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 991 DOI 10.17487/RFC8476, December 2018, 992 . 994 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 995 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 996 Extensions for Segment Routing", RFC 8665, 997 DOI 10.17487/RFC8665, December 2019, 998 . 1000 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 1001 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 1002 December 2019, . 1004 14.2. Informative References 1006 [I-D.ietf-lsr-flex-algo] 1007 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1008 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1009 algo-05 (work in progress), November 2019. 1011 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1012 (TE) Extensions to OSPF Version 2", RFC 3630, 1013 DOI 10.17487/RFC3630, September 2003, 1014 . 1016 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1017 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 1018 . 1020 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 1021 Authentication Trailer for OSPFv3", RFC 7166, 1022 DOI 10.17487/RFC7166, March 2014, 1023 . 1025 Authors' Addresses 1027 Zhenbin Li 1028 Huawei Technologies 1030 Email: lizhenbin@huawei.com 1032 Zhibo Hu 1033 Huawei Technologies 1035 Email: huzhibo@huawei.com 1037 Dean Cheng 1038 Huawei Technologies 1040 Email: dean.cheng@huawei.com 1042 Ketan Talaulikar (editor) 1043 Cisco Systems 1044 India 1046 Email: ketant@cisco.com 1048 Peter Psenak 1049 Cisco Systems 1050 Slovakia 1052 Email: ppsenak@cisco.com