idnits 2.17.1 draft-li-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 (January 15, 2020) is 1564 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-08 == 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 Network Working Group Z. Li 3 Internet-Draft Z. Hu 4 Intended status: Standards Track D. Cheng 5 Expires: July 18, 2020 Huawei Technologies 6 K. Talaulikar 7 P. Psenak 8 Cisco Systems 9 January 15, 2020 11 OSPFv3 Extensions for SRv6 12 draft-li-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 July 18, 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. 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 top SRH in an SRH stack to which the router can apply Penultimate 232 Segment Pop (PSP) 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 SPF 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 : 16 octets. 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-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 : 16 octets. 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 SIDs MUST be subsumed by the subnet of a Locator with the 577 matching algorithm which is advertised by the same node in an SRv6 578 Locator TLV. End.X SIDs which do not meet this requirement MUST be 579 ignored. 581 8.1. SRv6 End.X SID Sub-TLV 583 The format of the SRv6 End.X SID Sub-TLV is shown below 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Type | Length | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Endpoint Behavior | Flags | Reserved1 | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Algorithm | Weight | Reserved2 | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | SID (128 bits) ... | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | SID cont ... | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | SID cont ... | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | SID cont ... | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Sub-TLVs (variable) . . . 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Where: 607 Type is TBD 609 Length: 16 bit field. The total length of the value portion of 610 the TLV. 612 Endpoint Behavior: 16 bit field. The code point for the endpoint 613 behavior for this SRv6 SID as defined in section 9.2 of 614 [I-D.ietf-spring-srv6-network-programming]. 616 Flags: 8 bit field with the following definition: 618 0 1 2 3 4 5 6 7 619 +-+-+-+-+-+-+-+-+ 620 |B|S|P| Reserved| 621 +-+-+-+-+-+-+-+-+ 623 * B-Flag: Backup Flag. If set, the SID refers to a path that is 624 eligible for protection. 626 * S-Flag: Set Flag. When set, the S-Flag indicates that the 627 End.X SID refers to a set of adjacencies (and therefore MAY be 628 assigned to other adjacencies as well). 630 * P-Flag: Persistent Flag: If set, the SID is persistently 631 allocated, i.e., the SID value remains consistent across router 632 restart and session/interface flap. 634 * Reserved bits: Reserved for future use and MUST be zero when 635 originated and ignored on receipt. 637 Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored 638 on receipt. 640 Algorithm : 8 bit field. Associated algorithm. Algorithm values 641 are defined in the IGP Algorithm Type registry. 643 Weight: 8 bit field whose value represents the weight of the End.X 644 SID for the purpose of load-balancing. The use of the weight is 645 defined in [RFC8402]. 647 Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored 648 on receipt. 650 SID: 16 octets. This field encodes the advertised SRv6 SID. 652 Sub-TLVs : Used to advertise Sub-TLVs that provide additional 653 attributes for the given SRv6 End.X SID. 655 8.2. SRv6 LAN End.X SID Sub-TLV 657 The format of the SRv6 LAN End.X SID Sub-TLV is as shown below 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Type | Length | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Endpoint Behavior | Flags | Reserved1 | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Algorithm | Weight | Reserved2 | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | OSPFv3 Router-ID of neighbor | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | SID (128 bits) ... | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | SID cont ... | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | SID cont ... | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | SID cont ... | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Sub-TLVs (variable) . . . 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 Where 683 o Type: TBD 685 o Length: 16 bit value. Variable 687 o Endpoint Behavior: 16 bit field. The code point for the endpoint 688 behavior for this SRv6 SID as defined in section 9.2 of 689 [I-D.ietf-spring-srv6-network-programming]. 691 o SID Flags: 8 bit field which define the flags associated with the 692 SID. No flags are currently defined and SHOULD be set to 0 and 693 MUST be ignored on receipt. 695 o Flags: 8 bit field with the following definition: 697 0 1 2 3 4 5 6 7 698 +-+-+-+-+-+-+-+-+ 699 |B|S|P| Reserved| 700 +-+-+-+-+-+-+-+-+ 701 * B-Flag: Backup Flag. If set, the SID refers to a path that is 702 eligible for protection. 704 * S-Flag: Set Flag. When set, the S-Flag indicates that the 705 End.X SID refers to a set of adjacencies (and therefore MAY be 706 assigned to other adjacencies as well). 708 * P-Flag: Persistent Flag: If set, the SID is persistently 709 allocated, i.e., the SID value remains consistent across router 710 restart and session/interface flap. 712 * Reserved bits: Reserved for future use and MUST be zero when 713 originated and ignored on receipt. 715 o Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored 716 on receipt. 718 o Algorithm : 8 bit field. Associated algorithm. Algorithm values 719 are defined in the IGP Algorithm Type registry. 721 o Weight: 8 bit field whose value represents the weight of the End.X 722 SID for the purpose of load balancing. The use of the weight is 723 defined in [RFC8402]. 725 o Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored 726 on receipt. 728 o Neighbor ID : 4 octets of OSPFv3 Router-id of the neighbor 730 o SID: 16 octets. This field encodes the advertised SRv6 SID. 732 o Sub-TLVs : Used to advertise Sub-TLVs that provide additional 733 attributes for the given SRv6 SID. 735 9. SRv6 SID Structure Sub-TLV 737 SRv6 SID Structure Sub-TLV is used to advertise the length of each 738 individual part of the SRv6 SID as defined in 739 [I-D.ietf-spring-srv6-network-programming]. It is used as an 740 optional Sub-TLV of the following: 742 o SRv6 End SID Sub-TLV (refer Section 7) 744 o SRv6 End.X SID Sub-TLV (refer Section 8.1) 746 o SRv6 LAN End.X SID Sub-TLV (refer Section 8.2) 748 The Sub-TLV has the following format: 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Type | Length | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | LB Length | LN Length | Fun. Length | Arg. Length | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 Figure 7: SRv6 SID Structure Sub-TLV 760 Where: 762 Type: 2 octet field with value TBD, see Section 12. 764 Length: 2 octet field with the value 4. 766 LB Length: 1 octet field. SRv6 SID Locator Block length in bits. 768 LN Length: 1 octet field. SRv6 SID Locator Node length in bits. 770 Function Length: 1 octet field. SRv6 SID Function length in bits. 772 Argument Length: 1 octet field. SRv6 SID Argument length in bits. 774 10. Advertising Endpoint Behaviors 776 Endpoint behaviors are defined in 777 [I-D.ietf-spring-srv6-network-programming] and 778 [I-D.ietf-6man-spring-srv6-oam]. The codepoints for the Endpoint 779 behaviors are defined in the section 9.2 of 780 [I-D.ietf-spring-srv6-network-programming]. This section lists the 781 Endpoint behaviors and their codepoints, which MAY be advertised by 782 OSPFv3 and the Sub-TLVs in which each type MAY appear. 784 |-----------------------|--------------------|-----|-------|-----------| 785 | Endpoint | Endpoint | End | End.X | LAN End.X | 786 | Behavior | Behavior Codepoint | SID | SID | SID | 787 |-----------------------|--------------------|-----|-------|-----------| 788 | End (PSP, USP, USD) | 1-4, 28-31 | Y | N | N | 789 |-----------------------|--------------------|-----|-------|-----------| 790 | End.X (PSP, USP, USD) | 5-8, 32-35 | N | Y | Y | 791 |-----------------------|--------------------|-----|-------|-----------| 792 | End.T (PSP, USP, USD) | 9-12, 36-39 | Y | N | N | 793 |-----------------------|--------------------|-----|-------|-----------| 794 | End.DX6 | 16 | N | Y | Y | 795 |-----------------------|--------------------|-----|-------|-----------| 796 | End.DX4 | 17 | N | Y | Y | 797 |-----------------------|--------------------|-----|-------|-----------| 798 | End.DT6 | 18 | Y | N | N | 799 |-----------------------|--------------------|-----|-------|-----------| 800 | End.DT4 | 19 | Y | N | N | 801 |-----------------------|--------------------|-----|-------|-----------| 802 | End.DT64 | 20 | Y | N | N | 803 |-----------------------|--------------------|-----|-------|-----------| 804 | End.OP | 40 | Y | N | N | 805 |-----------------------|--------------------|-----|-------|-----------| 806 | End.OTP | 41 | Y | N | N | 807 |-----------------------|--------------------|-----|-------|-----------| 809 Figure 8: SRv6 Endpoint Behaviors in OSPFv3 811 11. Security Considerations 813 Existing security extensions as described in [RFC5340] and [RFC8362] 814 apply to these SRv6 extensions. While OSPFv3 is under a single 815 administrative domain, there can be deployments where potential 816 attackers have access to one or more networks in the OSPFv3 routing 817 domain. In these deployments, stronger authentication mechanisms 818 such as those specified in [RFC4552] or [RFC7166] SHOULD be used. 820 Implementations MUST assure that malformed TLV and Sub-TLV defined in 821 this document are detected and do not provide a vulnerability for 822 attackers to crash the OSPFv3 router or routing process. Reception 823 of malformed TLV or Sub-TLV SHOULD be counted and/or logged for 824 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be 825 rate-limited to prevent a Denial of Service (DoS) attack (distributed 826 or otherwise) from overloading the OSPFv3 control plane. 828 12. IANA Considerations 830 This document specifies updates to multiple OSPF and OSPFv3 related 831 IANA registries as follows. 833 12.1. OSPF Router Information TLVs 835 This document proposes the following new code point in the "OSPF 836 Router Information (RI) TLVs" registry under the "OSPF Parameters" 837 registry for the new TLVs: 839 Type TBD (suggested 17): SRv6-Capabilities TLV: Refer to 840 Section 2. 842 12.2. OSPFv3 LSA Function Codes 844 This document proposes the following new code point in the "OSPFv3 845 LSA Function Codes" registry under the "OSPFv3 Parameters" registry 846 for the new SRv6 Locator LSA: 848 o Type TBD (suggested 42): SRv6 Locator LSA: Refer to Section 6. 850 12.3. OSPFv3 Extended-LSA Sub-TLVs 852 This document proposes the following new code points in the "OSPFv3 853 Extended-LSA Sub-TLVs" registry under the "OSPFv3 Parameters" 854 registry for the new Sub-TLVs: 856 o Type TBD (suggested 10): SRv6 SID Structure Sub-TLV : Refer to 857 Section 9. 859 o Type TBD (suggested 11): SRv6 End.X SID Sub-TLV : Refer to 860 Section 8.1. 862 o Type TBD (suggested 12): SRv6 LAN End.X SID Sub-TLV : Refer to 863 Section 8.2. 865 12.4. OSPFv3 Locator LSA TLVs 867 This document proposes setting up of a new "OSPFv3 Locator LSA TLVs" 868 registry that defines top-level TLVs for the OSPFv3 SRv6 Locator LSA 869 to be added under the "OSPFv3 Parameters" registry. The initial 870 code-points assignment is as below: 872 o Type 0: Reserved. 874 o Type 1: SRv6 Locator TLV : Refer to Section 6.1. 876 Types in the range 2-32767 are allocated via IETF Review or IESG 877 Approval [RFC8126]. 879 Types in the range 32768-33023 are Reserved for Experimental Use; 880 these will not be registered with IANA and MUST NOT be mentioned by 881 RFCs. 883 Types in the range 33024-45055 are to be assigned on a First Come 884 First Served (FCFS) basis. 886 Types in the range 45056-65535 are not to be assigned at this time. 887 Before any assignments can be made in the 33024-65535 range, there 888 MUST be an IETF specification that specifies IANA Considerations that 889 cover the range being assigned. 891 12.5. OSPFv3 Locator LSA Sub-TLVs 893 This document proposes setting up of a new "OSPFv3 Locator LSA Sub- 894 TLVs" registry that defines Sub-TLVs at any level of nesting for the 895 SRv6 Locator TLVs to be added under the "OSPFv3 Parameters" registry. 896 The initial code-points assignment is as below: 898 o Type 0: Reserved. 900 o Type 1: SRv6 End SID Sub-TLV : Refer to Section 7. 902 o Type 10: SRv6 SID Structure Sub-TLV : Refer to Section 9. 904 Types in the range 2-9 and 11-32767 are allocated via IETF Review or 905 IESG Approval [RFC8126]. 907 Types in the range 32768-33023 are Reserved for Experimental Use; 908 these will not be registered with IANA and MUST NOT be mentioned by 909 RFCs. 911 Types in the range 33024-45055 are to be assigned on a First Come 912 First Served (FCFS) basis. 914 Types in the range 45056-65535 are not to be assigned at this time. 915 Before any assignments can be made in the 33024-65535 range, there 916 MUST be an IETF specification that specifies IANA Considerations that 917 cover the range being assigned. 919 13. Acknowledgements 921 The authors would like to thank Acee Lindem and Chenzichao for their 922 review and comments on this document. 924 14. References 926 14.1. Normative References 928 [I-D.ietf-6man-segment-routing-header] 929 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 930 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 931 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 932 progress), October 2019. 934 [I-D.ietf-6man-spring-srv6-oam] 935 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 936 Chen, "Operations, Administration, and Maintenance (OAM) 937 in Segment Routing Networks with IPv6 Data plane (SRv6)", 938 draft-ietf-6man-spring-srv6-oam-03 (work in progress), 939 December 2019. 941 [I-D.ietf-lsr-isis-srv6-extensions] 942 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 943 Z. Hu, "IS-IS Extension to Support Segment Routing over 944 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-04 945 (work in progress), January 2020. 947 [I-D.ietf-spring-srv6-network-programming] 948 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 949 Matsushima, S., and Z. Li, "SRv6 Network Programming", 950 draft-ietf-spring-srv6-network-programming-08 (work in 951 progress), January 2020. 953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 954 Requirement Levels", BCP 14, RFC 2119, 955 DOI 10.17487/RFC2119, March 1997, 956 . 958 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 959 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 960 . 962 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 963 S. Shaffer, "Extensions to OSPF for Advertising Optional 964 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 965 February 2016, . 967 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 968 Writing an IANA Considerations Section in RFCs", BCP 26, 969 RFC 8126, DOI 10.17487/RFC8126, June 2017, 970 . 972 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 973 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 974 May 2017, . 976 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 977 F. Baker, "OSPFv3 Link State Advertisement (LSA) 978 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 979 2018, . 981 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 982 Decraene, B., Litkowski, S., and R. Shakir, "Segment 983 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 984 July 2018, . 986 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 987 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 988 DOI 10.17487/RFC8476, December 2018, 989 . 991 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 992 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 993 Extensions for Segment Routing", RFC 8665, 994 DOI 10.17487/RFC8665, December 2019, 995 . 997 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 998 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 999 December 2019, . 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-05 (work in progress), November 2019. 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 1040 Cisco Systems 1041 India 1043 Email: ketant@cisco.com 1045 Peter Psenak 1046 Cisco Systems 1047 Slovakia 1049 Email: ppsenak@cisco.com