idnits 2.17.1 draft-li-ospf-ospfv3-srv6-extensions-05.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 20, 2019) is 1708 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 (-26) exists of draft-ietf-6man-segment-routing-header-22 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-02 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 Summary: 0 errors (**), 0 flaws (~~), 4 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: February 21, 2020 Huawei Technologies 6 K. Talaulikar 7 P. Psenak 8 Cisco Systems 9 August 20, 2019 11 OSPFv3 Extensions for SRv6 12 draft-li-ospf-ospfv3-srv6-extensions-05 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 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 21, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. SRv6-Capabilities TLV . . . . . . . . . . . . . . . . . . . . 3 67 3. Advertisement of Supported Algorithms . . . . . . . . . . . . 5 68 4. Advertisement of SRH Operation Limits . . . . . . . . . . . . 5 69 5. Advertisement of SRv6 Locator and End SIDs . . . . . . . . . 5 70 6. SRv6 Locator LSA . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. SRv6 Locator TLV . . . . . . . . . . . . . . . . . . . . 8 72 7. Advertisment of SRv6 End SIDs . . . . . . . . . . . . . . . . 10 73 8. Advertisment of SRv6 SIDs Associated with Adjacencies . . . . 11 74 8.1. SRv6 End.X SID Sub-TLV . . . . . . . . . . . . . . . . . 12 75 8.2. SRv6 LAN End.X SID Sub-TLV . . . . . . . . . . . . . . . 14 76 9. SRv6 SID Structure sub-TLV . . . . . . . . . . . . . . . . . 15 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 11.1. OSPF Router Information TLVs . . . . . . . . . . . . . . 17 80 11.2. OSPFv3 LSA Function Codes . . . . . . . . . . . . . . . 17 81 11.3. OSPFv3 Extended-LSA sub-TLVs . . . . . . . . . . . . . . 17 82 11.4. OSPFv3 Locator LSA TLVs . . . . . . . . . . . . . . . . 17 83 11.5. OSPFv3 Locator LSA sub-TLVs . . . . . . . . . . . . . . 18 84 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 13.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 Segment Routing (SR) architecture [RFC8402] specifies how a node can 93 steer a packet through an ordered list of instructions, called 94 segments. These segments are identified through Segment Identifiers 95 (SIDs). 97 Segment Routing can be instantiated on the IPv6 data plane through 98 the use of the Segment Routing Header (SRH) defined in 99 [I-D.ietf-6man-segment-routing-header]. SRv6 refers to this SR 100 instantiation on the IPv6 dataplane. The network programming 101 paradigm for SRv6 is specified in 102 [I-D.ietf-spring-srv6-network-programming] which describes several 103 well-known functions that can be bound to SRv6 SIDs. 105 This document specifies extensions to OSPFv3 in order to support SRv6 106 as defined in [I-D.ietf-spring-srv6-network-programming] by signaling 107 the SRv6 capabilities of the node and certain SRv6 SIDs with their 108 endpoint behaviors (e.g. End, End.X, etc.) that are instantiated on 109 the SRv6 capable router. 111 At a high level, the extensions to OSPFv3 comprise of the following: 113 1. SRv6 Capabilities TLV to advertise the support for SRv6 features 114 and SRH 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 associated with 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 2. SRv6-Capabilities TLV 125 When Segment Routing (SR) is instantiated using the IPv6 data plane 126 (SRv6), the list of segments is expressed using the segment routing 127 header (SRH) as defined in [I-D.ietf-6man-segment-routing-header]. 129 A router that supports SRv6 MUST be able to process the SRH as 130 described in [I-D.ietf-6man-segment-routing-header], as well as apply 131 endpoint behaviors as described in 132 [I-D.ietf-spring-srv6-network-programming]. 134 The SRv6 Capabilities TLV is designed for an OSPFv3 router to 135 advertise its SRv6 support along with its related capabilities for 136 SRv6 functionality. This is a new optional top level TLV of OSPFv3 137 Router Information LSA [RFC7770] which MUST be advertised by a SRv6 138 enabled router. 140 This TLV SHOULD be advertised only once in the OSPFv3 Router 141 Information LSA. When multiple SRv6 Capabilities TLVs are received 142 from a given router, the receiver MUST use the first occurrence of 143 the TLV in the OSPFV3 Router Information Opaque LSA. If the SRv6 144 Capabilities TLV appears in multiple OSPFv3 Router Information Opaque 145 LSAs that have different flooding scopes, the TLV in the OSPFv3 146 Router Information Opaque LSA with the area-scoped flooding scope 147 MUST be used. If the SRv6 Capabilities TLV appears in multiple 148 OSPFv3 Router Information Opaque LSAs that have the same flooding 149 scope, the TLV in the OSPFv3 Router Information Opaque LSA with the 150 numerically smallest Instance ID MUST be used and subsequent 151 instances of the TLV MUST be ignored. 153 The OSPFv3 Router Information Opaque LSA can be advertised at any of 154 the defined opaque flooding scopes (link, area, or Autonomous System 155 (AS)). For the purpose of SRv6 Capabilities TLV advertisement, area- 156 scoped flooding is REQUIRED. 158 The format of OSPFv3-SRv6-Capabilities TLV is shown below 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Type | Length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Flags | Reserved | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Sub-TLVs... 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Where: 172 o Type: 16 bit field. TBD 174 o Length: 16 bit field. Length of Capability TLV + length of Sub- 175 TLVs 177 o Reserved : 16 bit field. SHOULD be set to 0 and MUST be ignored 178 by receiver. 180 o Flags: 16 bit field. The following flags are defined: 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 router is capable of supporting SRH O-bit, 191 as specified in [I-D.ali-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 200 [I-D.ietf-ospf-segment-routing-extensions] as described in 201 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 203 4. Advertisement of SRH Operation Limits 205 A SRv6 enabled router may have different capabilities and limits when 206 it comes to SRH processing and this needs to be advertised to other 207 routers in the SRv6 domain. 209 [RFC8476] defines the means to advertise node/link specific values 210 for Maximum SID Depths (MSD) of various types. Node MSDs are 211 advertised using the Node MSD TLV in the OSPFv3 Router Information 212 LSA [RFC7770] while Link MSDs are advertised using the Link MSD sub- 213 TLV of the E-Router-LSA TLV [RFC8362]. The format of the MSD types 214 for OSPFv3 is defined in [RFC8476]. 216 The MSD types for SRv6 that are defined in 217 [I-D.ietf-lsr-isis-srv6-extensions] for IS-IS are also used by 218 OSPFv3. These MSD Types are allocated under the IGP MSD Types 219 registry maintained by IANA that are shared by IS-IS and OSPF. 221 5. Advertisement of SRv6 Locator and End SIDs 223 An SRv6 Segment Identifier (SID) is 128 bits and represented as 224 LOC:FUNCT as described in [I-D.ietf-spring-srv6-network-programming]. 226 A node is provisioned with algorithm specific locators for each 227 algorithm supported by that node. Each locator is a covering prefix 228 for all SIDs provisioned on that node which have the matching 229 algorithm. 231 Locators MUST be advertised in the SRv6 Locator LSA (see Section 6). 232 Forwarding entries for the locators advertised in the SRv6 Locator 233 LSA MUST be installed in the forwarding plane of receiving SRv6 234 capable routers when the associated algorithm is supported by the 235 receiving node. Locators can be of different route types similar to 236 existing OSPF LSA route types - Intra-Area, Inter-Area, External and 237 NSSA. The computation of locator reachability and their 238 advertisement are similar to how normal OSPF prefix reachability LSAs 239 are processed as part of the SPF computation. 241 Locators are routable and MAY also be advertised via Prefix LSAs of 242 different types - Inter-Area Prefix LSA, AS-External LSA, NSSA LSA or 243 Intra-Area Prefix LSA (or their equivalent extended LSAs [RFC8362]). 244 Locators associated with Flexible Algorithms SHOULD NOT be advertised 245 via Prefix LSAs. Locators associated with algorithm 0 (for all 246 supported topologies) SHOULD be advertised in Prefix LSAs so that 247 legacy routers (i.e., routers which do NOT support SRv6) will install 248 a forwarding entry for algorithm 0 SRv6 traffic. 250 In cases where a locator advertisement is received in both in a 251 Prefix LSA and an SRv6 Locator LSA, the Prefix LSA advertisement MUST 252 be preferred when installing entries in the forwarding plane. This 253 is to prevent inconsistent forwarding entries on SRv6 capable/SRv6 254 incapable routers. 256 SRv6 SIDs are advertised as sub-TLVs in the SRv6 Locator TLV except 257 for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a 258 specific Neighbor/Link and are therefore advertised as sub-TLVs of E- 259 Router-Link TLV. 261 SRv6 SIDs are not directly routable and MUST NOT be installed in the 262 forwarding plane. Reachability to SRv6 SIDs depends upon the 263 existence of a covering locator. Adherence to the rules defined in 264 this section will assure that SRv6 SIDs associated with a supported 265 algorithm will be forwarded correctly, while SRv6 SIDs associated 266 with an unsupported algorithm will be dropped. NOTE: The drop 267 behavior depends on the absence of a default/summary route covering a 268 given locator. 270 6. SRv6 Locator LSA 272 The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits 273 are dependent on the desired flooding scope for the LSA. The 274 flooding scope of the SRv6 Locator LSA depends on the scope of the 275 advertised SRv6 Locator and is under the control of the advertising 276 router. The U bit will be set indicating that the LSA should be 277 flooded even if it is not understood. 279 Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router and 280 they are distinguished by their Link State IDs (which are chosen 281 arbitrarily by the originating router). 283 The format of SRv6 Locator LSA is shown below: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | LS age |1|S12| Function Code | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Link State ID | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Advertising Router | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | LS sequence number | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | LS checksum | Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | | 299 +- TLVs -+ 300 | ... | 302 Figure 1: SRv6 Locator LSA 304 The format of the TLVs within the body of the SRv6 Locator LSA is the 305 same as the format used by [RFC3630]. The variable TLV section 306 consists of one or more nested TLV tuples. Nested TLVs are also 307 referred to as sub- TLVs. The format of each TLV is: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Value | 315 o 316 o 317 o 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 2: SRv6 Locator LSA TLV Format 323 The Length field defines the length of the value portion in octets 324 (thus, a TLV with no value portion would have a length of 0). The 325 TLV is padded to 4-octet alignment; padding is not included in the 326 Length field (so a 3-octet value would have a length of 3, but the 327 total size of the TLV would be 8 octets). Nested TLVs are also 328 32-bit aligned. For example, a 1-byte value would have the Length 329 field set to 1, and 3 octets of padding would be added to the end of 330 the value portion of the TLV. The padding is composed of zeros. 332 6.1. SRv6 Locator TLV 334 The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA that 335 is used to advertise a SRv6 Locator, its attributes and SIDs 336 associated with it. Multiple SRv6 Locator TLVs MAY be advertised in 337 each SRv6 Locator LSA. However, since the S12 bits define the 338 flooding scope, the LSA flooding scope MUST satisfy the application- 339 specific requirements for all the locators included in a single SRv6 340 Locator LSA. 342 When multiple SRv6 Locator TLVs are received from a given router in a 343 SRv6 Locator LSA for the same Locator, the receiver MUST use the 344 first occurrence of the TLV in the LSA. If the SRv6 Locator TLV for 345 the same Locator appears in multiple SRv6 Locator LSAs that have 346 different flooding scopes, the TLV in the SRv6 Locator LSA with the 347 area-scoped flooding scope MUST be used. If the SRv6 Locator TLV for 348 the same Locator appears in multiple SRv6 Locator LSAs that have the 349 same flooding scope, the TLV in the SRv6 Locator LSA with the 350 numerically smallest Link-State ID MUST be used and subsequent 351 instances of the TLV MUST be ignored. 353 The format of SRv6 Locator TLV is shown below: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Type | Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Route Type | Algorithm | Locator Length| Flags | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Metric | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Locator (128 bits) ... | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Locator cont ... | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Locator cont ... | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Locator cont ... | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Sub-TLVs (variable) | 373 +- -+ 374 | ... | 376 Figure 3: SRv6 Locator TLV 378 Where: 380 Type: 16 bit field. The value is 1 for this type. 382 Length: 16 bit field. The total length of the value portion of 383 the TLV including sub-TLVs. 385 Route Type : 8 bit field. The type of the locator route. 386 Supported types are the ones listed below and other other types 387 MUST be ignored by the receiver. 389 1 - Intra-Area 390 2 - Inter-Area 391 3 - AS External 392 4 - NSSA External 394 Figure 4 396 Algorithm: 8 bit field. Associated algorithm. Algorithm values 397 are defined in the IGP Algorithm Type registry. 399 Locator Length: 8 bit field. Carries the length of the Locator 400 prefix as number of bits (1-128). 402 Flags: 8 bit field. The following flags are defined 404 0 1 2 3 4 5 6 7 405 +-+-+-+-+-+-+-+-+ 406 |N|A| Reserved | 407 +-+-+-+-+-+-+-+-+ 409 Figure 5 411 * N flag : When the locator uniquely identifies a node in the 412 network (i.e. it is provisioned on one and only one node), the 413 N bit MUST be set. Otherwise, this bit MUST be clear. 415 * A bit : When the Locator is configured as anycast, the A bit 416 SHOULD be set. Otherwise, this bit MUST be clear. 418 * Other flags are not defined and SHOULD be set to 0 and MUST be 419 ignored on receipt. 421 Metric : 32 bit field. The metric value associated with the 422 locator. 424 Locator : 16 octets. This field encodes the advertised SRv6 425 Locator. 427 Sub-TLVs : Used to advertise sub-TLVs that provide additional 428 attributes for the given SRv6 Locator and SRv6 SIDs associated 429 with it. 431 7. Advertisment of SRv6 End SIDs 433 SRv6 End SID sub-TLV is a new sub-TLV of SRv6 Locator TLV in the SRv6 434 Locator LSA (defined in Section 6). It is used to advertise the SRv6 435 SIDs belonging to the node along with their associated functions. 436 SIDs associated with adjacencies are advertised as described in 437 Section 8. Every SRv6 enabled OSPFv3 router SHOULD advertise at 438 least one SRv6 SID associated with an END behavior for its node as 439 specified in [I-D.ietf-spring-srv6-network-programming]. 441 SRv6 End SIDs inherit the algorithm from the parent locator. The 442 SRv6 End SID MUST be a subnet of the associated Locator. SRv6 End 443 SIDs which are NOT a subnet of the associated locator MUST be 444 ignored. 446 The router MAY advertise multiple instances of the SRv6 End SID sub- 447 TLV within the SRv6 Locator TLV - one for each of the SRv6 SIDs to be 448 advertised. When multiple SRv6 End SID sub-TLVs are received in the 449 SRv6 Locator TLV from a given router for the same SRv6 SID value, the 450 receiver MUST use the first occurrence of the sub-TLV in the SRv6 451 Locator TLV. 453 The format of SRv6 End SID sub-TLV is shown below 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Flags | Reserved | Endpoint Behavior ID | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | SID (128 bits) ... | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | SID cont ... | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | SID cont ... | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | SID cont ... | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Sub-Sub-TLVs (variable) . . . 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 6: SRv6 End SID sub-TLV 475 Where: 477 Type: 16 bit field. Value is 1 for this type. 479 Length: 16 bit field. The total length of the value portion of 480 the sub-TLV including sub-sub-TLVs. 482 Reserved : 8 bit field. Should be set to 0 and MUST be ignored on 483 receipt. 485 Flags: 8 bit field which define the flags associated with the SID. 486 No flags are currently defined and SHOULD be set to 0 and MUST be 487 ignored on receipt. 489 Endpoint Behavior ID: 16 bit field. The endpoint behavior code 490 point for this SRv6 SID as defined in 491 [I-D.ietf-spring-srv6-network-programming]. 493 SID : 16 octets. This field encodes the advertised SRv6 SID. 495 Sub-Sub-TLVs : Used to advertise sub-sub-TLVs that provide 496 additional attributes for the given SRv6 SID. 498 8. Advertisment of SRv6 SIDs Associated with Adjacencies 500 The SRv6 endpoint behaviors are defined in 501 [I-D.ietf-spring-srv6-network-programming] include certain behaviors 502 which are specific to links or adjacencies. The most basic of this 503 which is critical for link state routing protocols like OSPFv3 is the 504 End.X behavior that is an instruction to forward to a specific 505 neighbor on a specific link. These SRv6 SIDs along with others that 506 are defined in [I-D.ietf-spring-srv6-network-programming] which are 507 specific to links or adjacencies need to be advertised by OSPFv3 so 508 that this information is available with all routers in the area to 509 influence the packet path via these SRv6 SIDs over the specific 510 adjacencies. 512 The advertising of SRv6 SIDs and their behaviors that are specific to 513 a particular neighbor are done via two different optional sub-TLVs of 514 the E-Router-Link TLV defined in [RFC8362] as follows: 516 o SRv6 End.X SID Sub-TLV: for OSPFv3 adjacency over point-to-point 517 or point-to-multipoint links and the adjacency to the Designated 518 Router (DR) over broadcast and non-broadcast-multi-access (NBMA) 519 links. 521 o SRv6 LAN End.X SID Sub-TLV: for OSPFv3 adjacency on broadcast and 522 NBMA links to the Backup DR and DR-Other neighbors. This sub-TLV 523 includes the OSPFv3 router-id of the neighbor and thus allows for 524 multiple instances of this TLV for each neighbor to be explicitly 525 advertised under the E-Router-Link TLV for the same link. 527 Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one 528 End.X function with a unique SRv6 SID corresponding to each of its 529 neighbor. A router MAY instantiate more than one SRv6 SID for the 530 End.X function for a single neighbor. The same SRv6 SID MAY be 531 advertised for the End.X function corresponding to more than one 532 neighbor. Thus multiple instances of the SRv6 End.X SID and SRv6 LAN 533 End.X SID sub-TLVs MAY be advertised within the E-Router-Link TLV for 534 a single link. 536 All End.X SIDs MUST be a subnet of a Locator with matching algorithm 537 which is advertised by the same node in an SRv6 Locator TLV. End.X 538 SIDs which do not meet this requirement MUST be ignored. 540 8.1. SRv6 End.X SID Sub-TLV 542 The format of the SRv6 End.X SID sub-TLV is shown below 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Type | Length | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Endpoint Behaviour ID | Flags | Reserved1 | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Algorithm | Weight | Reserved2 | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | SID (128 bits) ... | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | SID cont ... | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | SID cont ... | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | SID cont ... | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Sub-TLVs (variable) . . . 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Where: 566 Type is TBD 568 Length: 16 bit field. The total length of the value portion of 569 the TLV. 571 Endpoint Behaviour ID: 16 bit field. The code point for the 572 endpoint behavior for this SRv6 SID as defined in 573 [I-D.ietf-spring-srv6-network-programming]. 575 Flags: 8 bit field with the following definition: 577 0 1 2 3 4 5 6 7 578 +-+-+-+-+-+-+-+-+ 579 |B|S|P| Rsvd | 580 +-+-+-+-+-+-+-+-+ 582 * B-Flag: Backup Flag. If set, the SID refers to a path that is 583 eligible for protection. 585 * S-Flag: Set Flag. When set, the S-Flag indicates that the 586 End.X SID refers to a set of adjacencies (and therefore MAY be 587 assigned to other adjacencies as well). 589 * P-Flag: Persistent Flag: If set, the SID is persistently 590 allocated, i.e., the SID value remains consistent across router 591 restart and session/interface flap. 593 * Rsvd bits: Reserved for future use and MUST be zero when 594 originated and ignored when received. 596 Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored 597 on receipt. 599 Algorithm : 8 bit field. Associated algorithm. Algorithm values 600 are defined in the IGP Algorithm Type registry. 602 Weight: 8 bit field whose value represents the weight of the End.X 603 SID for the purpose of load balancing. The use of the weight is 604 defined in [RFC8402]. 606 Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored 607 on receipt. 609 SID: 16 octets. This field encodes the advertised SRv6 SID. 611 Sub-TLVs : Used to advertise sub-TLVs that provide additional 612 attributes for the given SRv6 End.X SID. 614 8.2. SRv6 LAN End.X SID Sub-TLV 616 The format of the SRv6 LAN End.X SID sub-TLV is as shown below 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Type | Length | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Endpoint Behaviour | Flags | Reserved1 | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Algorithm | Weight | Reserved2 | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | OSPFv3 Router-ID of neighbor | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | SID (128 bits) ... | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | SID cont ... | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | SID cont ... | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | SID cont ... | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Sub-TLVs (variable) . . . 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Where 642 o Type: TBD 644 o Length: 16 bit value. Variable 646 o Endpoint Behaviour: 16 bit field. The code point for the endpoint 647 behavior for this SRv6 SID as defined in 648 [I-D.ietf-spring-srv6-network-programming]. 650 o SID Flags: 8 bit field which define the flags associated with the 651 SID. No flags are currently defined and SHOULD be set to 0 and 652 MUST be ignored on receipt. 654 o Flags: 8 bit field with the following definition: 656 0 1 2 3 4 5 6 7 657 +-+-+-+-+-+-+-+-+ 658 |B|S|P| Rsvd | 659 +-+-+-+-+-+-+-+-+ 660 * B-Flag: Backup Flag. If set, the SID refers to a path that is 661 eligible for protection. 663 * S-Flag: Set Flag. When set, the S-Flag indicates that the 664 End.X SID refers to a set of adjacencies (and therefore MAY be 665 assigned to other adjacencies as well). 667 * P-Flag: Persistent Flag: If set, the SID is persistently 668 allocated, i.e., the SID value remains consistent across router 669 restart and session/interface flap. 671 * Rsvd bits: Reserved for future use and MUST be zero when 672 originated and ignored when received. 674 o Reserved1 : 8 bit field. Should be set to 0 and MUST be ignored 675 on receipt. 677 o Algorithm : 8 bit field. Associated algorithm. Algorithm values 678 are defined in the IGP Algorithm Type registry. 680 o Weight: 8 bit field whose value represents the weight of the End.X 681 SID for the purpose of load balancing. The use of the weight is 682 defined in [RFC8402]. 684 o Reserved2 : 16 bit field. Should be set to 0 and MUST be ignored 685 on receipt. 687 o Neighbor ID : 4 octets of OSPFv3 Router-id of the neighbor 689 o SID: 16 octets. This field encodes the advertised SRv6 SID. 691 o Sub-TLVs : Used to advertise sub-TLVs that provide additional 692 attributes for the given SRv6 SID. 694 9. SRv6 SID Structure sub-TLV 696 SRv6 SID Structure sub-TLV is used to advertise the length of each 697 individual part of the SRv6 SID as defined in 698 [I-D.ietf-spring-srv6-network-programming]. It is used as an 699 optional sub-sub-TLV of the following: 701 o SRv6 End SID sub-TLV (refer Section 7) 703 o SRv6 End.X SID sub-TLV (refer Section 8.1) 705 o SRv6 LAN End.X SID sub-TLV (refer Section 8.2) 707 The sub-TLV has the following format: 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Type | Length | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | LB Length | LN Length | Fun. Length | Arg. Length | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Figure 7: SRv6 SID Structure sub-TLV 719 Where: 721 Type: 2 octet field with value TBD, see Section 11. 723 Length: 2 octet field with the value 4. 725 LB Length: 1 octet field. SRv6 SID Locator Block length in bits. 727 LN Length: 1 octet field. SRv6 SID Locator Node length in bits. 729 Function Length: 1 octet field. SRv6 SID Function length in bits. 731 Argument Length: 1 octet field. SRv6 SID Argument length in bits. 733 10. Security Considerations 735 Existing security extensions as described in [RFC5340] and [RFC8362] 736 apply to these SRv6 extensions. While OSPFv3 is under a single 737 administrative domain, there can be deployments where potential 738 attackers have access to one or more networks in the OSPFv3 routing 739 domain. In these deployments, stronger authentication mechanisms 740 such as those specified in [RFC4552] SHOULD be used. 742 Implementations MUST assure that malformed TLV and Sub-TLV defined in 743 this document are detected and do not provide a vulnerability for 744 attackers to crash the OSPFv3 router or routing process. Reception 745 of malformed TLV or Sub-TLV SHOULD be counted and/or logged for 746 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be 747 rate-limited to prevent a Denial of Service (DoS) attack (distributed 748 or otherwise) from overloading the OSPFv3 control plane. 750 11. IANA Considerations 752 This document specifies updates to multiple OSPF and OSPFv3 related 753 IANA registries as follows. 755 11.1. OSPF Router Information TLVs 757 This document proposes the following new code point in the "OSPF 758 Router Information (RI) TLVs" registry under the "OSPF Parameters" 759 registry for the new TLVs: 761 Type TBD (suggested 17): SRv6-Capabilities TLV: Refer to 762 Section 2. 764 11.2. OSPFv3 LSA Function Codes 766 This document proposes the following new code point in the "OSPFv3 767 LSA Function Codes" registry under the "OSPFv3 Parameters" registry 768 for the new SRv6 Locator LSA: 770 o Type TBD (suggested 42): SRv6 Locator LSA: Refer to Section 6. 772 11.3. OSPFv3 Extended-LSA sub-TLVs 774 This document proposes the following new code points in the "OSPFv3 775 Extended-LSA Sub-TLVs" registry under the "OSPFv3 Parameters" 776 registry for the new sub-TLVs: 778 o Type TBD (suggested 10): SRv6 SID Structure Sub-TLV : Refer to 779 Section 9. 781 o Type TBD (suggested 11): SRv6 End.X SID Sub-TLV : Refer to 782 Section 8.1. 784 o Type TBD (suggested 12): SRv6 LAN End.X SID Sub-TLV : Refer to 785 Section 8.2. 787 11.4. OSPFv3 Locator LSA TLVs 789 This document proposes setting up of a new "OSPFv3 Locator LSA TLVs" 790 registry that defines top-level TLVs for the OSPFv3 SRv6 Locator LSA 791 to be added under the "OSPFv3 Parameters" registry. The initial 792 code-points assignment is as below: 794 o Type 0: Reserved. 796 o Type 1: SRv6 Locator TLV : Refer to Section 6.1. 798 Types in the range 2-32767 are allocated via IETF Review or IESG 799 Approval [RFC8126]. 801 Types in the range 32768-33023 are Reserved for Experimental Use; 802 these will not be registered with IANA and MUST NOT be mentioned by 803 RFCs. 805 Types in the range 33024-45055 are to be assigned on a First Come 806 First Served (FCFS) basis. 808 Types in the range 45056-65535 are not to be assigned at this time. 809 Before any assignments can be made in the 33024-65535 range, there 810 MUST be an IETF specification that specifies IANA Considerations that 811 cover the range being assigned. 813 11.5. OSPFv3 Locator LSA sub-TLVs 815 This document proposes setting up of a new "OSPFv3 Locator LSA Sub- 816 TLVs" registry that defines sub-TLVs at any level of nesting for the 817 SRv6 Locator TLVs to be added under the "OSPFv3 Parameters" registry. 818 The initial code-points assignment is as below: 820 o Type 0: Reserved. 822 o Type 1: SRv6 End SID sub-TLV : Refer to Section 7. 824 o Type 10: SRv6 SID Structure Sub-TLV : Refer to Section 9. 826 Types in the range 2-9 and 11-32767 are allocated via IETF Review or 827 IESG Approval [RFC8126]. 829 Types in the range 32768-33023 are Reserved for Experimental Use; 830 these will not be registered with IANA and MUST NOT be mentioned by 831 RFCs. 833 Types in the range 33024-45055 are to be assigned on a First Come 834 First Served (FCFS) basis. 836 Types in the range 45056-65535 are not to be assigned at this time. 837 Before any assignments can be made in the 33024-65535 range, there 838 MUST be an IETF specification that specifies IANA Considerations that 839 cover the range being assigned. 841 12. Acknowledgements 843 The authors would like to thank Chenzichao for their review and 844 comments on this document. 846 13. References 848 13.1. Normative References 850 [I-D.ali-spring-srv6-oam] 851 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 852 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 853 S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., 854 Peirens, B., Chen, M., and G. Naik, "Operations, 855 Administration, and Maintenance (OAM) in Segment Routing 856 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 857 srv6-oam-02 (work in progress), October 2018. 859 [I-D.ietf-6man-segment-routing-header] 860 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 861 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 862 Routing Header (SRH)", draft-ietf-6man-segment-routing- 863 header-22 (work in progress), August 2019. 865 [I-D.ietf-lsr-isis-srv6-extensions] 866 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 867 Z. Hu, "IS-IS Extension to Support Segment Routing over 868 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-02 869 (work in progress), July 2019. 871 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 872 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 873 Routing", draft-ietf-ospf-ospfv3-segment-routing- 874 extensions-23 (work in progress), January 2019. 876 [I-D.ietf-ospf-segment-routing-extensions] 877 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 878 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 879 Extensions for Segment Routing", draft-ietf-ospf-segment- 880 routing-extensions-27 (work in progress), December 2018. 882 [I-D.ietf-spring-srv6-network-programming] 883 Filsfils, C., Camarillo, P., Leddy, J., 884 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 885 Network Programming", draft-ietf-spring-srv6-network- 886 programming-01 (work in progress), July 2019. 888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, 890 DOI 10.17487/RFC2119, March 1997, 891 . 893 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 894 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 895 . 897 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 898 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 899 . 901 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 902 S. Shaffer, "Extensions to OSPF for Advertising Optional 903 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 904 February 2016, . 906 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 907 Writing an IANA Considerations Section in RFCs", BCP 26, 908 RFC 8126, DOI 10.17487/RFC8126, June 2017, 909 . 911 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 912 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 913 May 2017, . 915 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 916 F. Baker, "OSPFv3 Link State Advertisement (LSA) 917 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 918 2018, . 920 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 921 Decraene, B., Litkowski, S., and R. Shakir, "Segment 922 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 923 July 2018, . 925 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 926 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 927 DOI 10.17487/RFC8476, December 2018, 928 . 930 13.2. Informative References 932 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 933 (TE) Extensions to OSPF Version 2", RFC 3630, 934 DOI 10.17487/RFC3630, September 2003, 935 . 937 Authors' Addresses 939 Zhenbin Li 940 Huawei Technologies 942 Email: lizhenbin@huawei.com 944 Zhibo Hu 945 Huawei Technologies 947 Email: huzhibo@huawei.com 949 Dean Cheng 950 Huawei Technologies 952 Email: dean.cheng@huawei.com 954 Ketan Talaulikar 955 Cisco Systems 956 India 958 Email: ketant@cisco.com 960 Peter Psenak 961 Cisco Systems 962 Slovakia 964 Email: ppsenak@cisco.com