idnits 2.17.00 (12 Aug 2021) /tmp/idnits31229/draft-ietf-ospf-ospfv3-lsa-extend-19.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 (December 18, 2017) is 1615 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) -- Unexpected draft version: The latest known version of draft-ietf-ospf-mt-ospfv3 is -03, but you're referring to -04. == Outdated reference: draft-ietf-ospf-ospfv3-segment-routing-extensions has been published as RFC 8666 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft A. Roy 4 Intended status: Standards Track Cisco Systems 5 Expires: June 21, 2018 D. Goethals 6 Nokia 7 V. Reddy Vallem 9 F. Baker 11 December 18, 2017 13 OSPFv3 LSA Extendibility 14 draft-ietf-ospf-ospfv3-lsa-extend-19.txt 16 Abstract 18 OSPFv3 requires functional extension beyond what can readily be done 19 with the fixed-format Link State Advertisement (LSA) as described in 20 RFC 5340. Without LSA extension, attributes associated with OSPFv3 21 links and advertised IPv6 prefixes must be advertised in separate 22 LSAs and correlated to the fixed-format LSAs. This document extends 23 the LSA format by encoding the existing OSPFv3 LSA information in 24 Type-Length-Value (TLV) tuples and allowing advertisement of 25 additional information with additional TLVs. Backward compatibility 26 mechanisms are also described. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 21, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 64 1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4 65 1.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 66 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 4 67 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . 5 68 3.1. Prefix Options Extensions . . . . . . . . . . . . . . . . 6 69 3.1.1. N-bit Prefix Option . . . . . . . . . . . . . . . . . 7 70 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 71 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8 72 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10 73 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11 74 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12 75 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13 76 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14 77 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15 78 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 79 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 80 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 17 81 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 17 82 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17 83 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 19 84 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 20 85 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 21 86 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 22 87 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 23 88 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 24 89 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 26 90 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 27 91 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 27 92 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 27 93 6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 28 94 6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 28 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 97 8.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 29 98 8.2. OSPFv3 Extended-LSA sub-TLV Registry . . . . . . . . . . 30 99 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 102 10.2. Informative References . . . . . . . . . . . . . . . . . 31 103 Appendix A. Appendix A - Global Configuration Parameters . . . . 32 104 Appendix B. Appendix B - Area Configuration Parameters . . . . . 32 105 Appendix C. Appendix C - Deprecated LSA Extension Backward 106 Compatibility . . . . . . . . . . . . . . . . . . . 32 107 C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 34 108 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 35 109 C.2. Global Configuration Parameters . . . . . . . . . . . . . 36 110 C.3. Area Configuration Parameters . . . . . . . . . . . . . . 36 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 113 1. Introduction 115 OSPFv3 requires functional extension beyond what can readily be done 116 with the fixed-format Link State Advertisement (LSA) as described in 117 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 118 OSPFv3 links and advertised IPv6 prefixes must be advertised in 119 separate LSAs and correlated to the fixed-format LSAs. This document 120 extends the LSA format by encoding the existing OSPFv3 LSA 121 information in Type-Length-Value (TLV) tuples and allowing 122 advertisement of additional information with additional TLVs. 123 Backward compatibility mechanisms are also described. 125 A similar extension was previously proposed in support of multi- 126 topology routing. Additional requirements for OSPFv3 LSA extension 127 include source/destination routing, route tagging, and others. 129 A final requirement is to limit the changes to OSPFv3 to those 130 necessary for TLV-based LSAs. For the most part, the semantics of 131 existing OSPFv3 LSAs are retained for their TLV-based successor LSAs 132 described herein. Additionally, encoding details, e.g., the 133 representation of IPv6 prefixes as described in section A.4.1 in RFC 134 5340 [OSPFV3], have been retained. This requirement was included to 135 increase the expedience of IETF adoption and deployment. 137 The following aspects of OSPFv3 LSA extension are described: 139 1. Extended LSA Types 140 2. Extended LSA TLVs 142 3. Extended LSA Formats 144 4. Backward Compatibility 146 1.1. Requirements notation 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC-KEYWORDS]. 152 1.2. OSPFv3 LSA Terminology 154 The TLV-based OSPFv3 LSAs described in this document will be referred 155 to as Extended LSAs. The OSPFv3 fixed-format LSAs [OSPFV3] will be 156 referred to as Legacy LSAs. 158 1.3. Acknowledgments 160 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 161 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 163 Thanks for Peter Psenak for significant contributions to the backward 164 compatibility mechanisms. 166 Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony 167 Przygienda for review of the draft versions and discussions of 168 backward compatibility. 170 Thanks to Alan Davey for review and comments including the suggestion 171 to separate the extended LSA TLV definitions from the extended LSAs 172 definitions. 174 Thanks to David Lamparter for review and suggestions on backward 175 compatibility. 177 Thanks to Karsten Thomann, Chris Bowers, Meng Zhang, and Nagendra 178 Kumar for review and editorial comments. 180 The RFC text was produced using Marshall Rose's xml2rfc tool. 182 2. OSPFv3 Extended LSA Types 184 In order to provide backward compatibility, new LSA codes must be 185 allocated. There are eight fixed-format LSAs defined in RFC 5340 186 [OSPFV3]. For ease of implementation and debugging, the LSA function 187 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 188 added. The alternative to this mapping was to allocate a bit in the 189 LS Type indicating the new LSA format. However, this would have used 190 one half the LSA function code space for the migration of the eight 191 original fixed-format LSAs. For backward compatibility, the U-bit 192 will be set in LS Type so that the LSAs will be flooded by OSPFv3 193 routers that do not understand them. 195 LSA function code LS Type Description 196 ---------------------------------------------------- 197 33 0xA021 E-Router-LSA 198 34 0xA022 E-Network-LSA 199 35 0xA023 E-Inter-Area-Prefix-LSA 200 36 0xA024 E-Inter-Area-Router-LSA 201 37 0xC025 E-AS-External-LSA 202 38 N/A Unused (Not to be allocated) 203 39 0xA027 E-Type-7-LSA 204 40 0x8028 E-Link-LSA 205 41 0xA029 E-Intra-Area-Prefix-LSA 207 OSPFv3 Extended LSA Types 209 3. OSPFv3 Extended LSA TLVs 211 The format of the TLVs within the body of the extended LSAs is the 212 same as the format used by the Traffic Engineering Extensions to OSPF 213 [TE]. The variable TLV section consists of one or more nested 214 Type/Length/Value (TLV) tuples. Nested TLVs are also referred to as 215 sub-TLVs. The format of each TLV is: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Type | Length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Value... | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 TLV Format 227 The Length field defines the length of the value portion in octets 228 (thus a TLV with no value portion would have a length of 0). The TLV 229 is padded to 4-octet alignment; padding is not included in the length 230 field (so a 3-octet value would have a length of 3, but the total 231 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 232 aligned. For example, a 1-byte value would have the length field set 233 to 1, and 3 octets of padding would be added to the end of the value 234 portion of the TLV. 236 This document defines the following top-level TLV types: 238 o 0 - Reserved 240 o 1 - Router-Link TLV 242 o 2 - Attached-Routers TLV 244 o 3 - Inter-Area Prefix TLV 246 o 4 - Inter-Area Router TLV 248 o 5 - External Prefix TLV 250 o 6 - Intra-Area Prefix TLV 252 o 7 - IPv6 Link-Local Address TLV 254 o 8 - IPv4 Link-Local Address TLV 256 Additionally, this document defines the following sub-TLV types: 258 o 0 - Reserved 260 o 1 - IPv6 Forwarding Address sub-TLV 262 o 2 - IPv4 Forwarding Address sub-TLV 264 o 3 - Route Tag sub-TLV 266 In general, TLVs and sub-TLVs MAY occur in any order and the 267 specification should define whether the TLV or sub-TLV is required 268 and the behavior when there are multiple occurances of the TLV or 269 sub-TLVs. 271 For backward compatibility, an LSA is not considered malformed from a 272 TLV perspective unless either a required TLV is missing or a 273 specified TLV is less than the minimum required length. Refer to 274 Section 6.3 for more information on TLV backward compatibility. 276 3.1. Prefix Options Extensions 278 The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The 279 applicability of the LA-bit is expanded and it SHOULD be set in 280 Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when 281 the advertised host IPv6 address, i.e., PrefixLength = 128, is an 282 interface address. In RFC 5340, the LA-bit is only set in Intra- 283 Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3]). This will allow a 284 stable address to be advertised without having to configure a 285 separate loopback address in every OSPFv3 area. 287 3.1.1. N-bit Prefix Option 289 Additionally, the N-bit prefix option is defined. The figure below 290 shows the position of the N-bit in the prefix options (pending IANA 291 allocation). This corresponds to the value 0x20. 293 0 1 2 3 4 5 6 7 294 +--+--+--+--+--+--+--+--+ 295 | | | N|DN| P| x|LA|NU| 296 +--+--+--+--+--+--+--+--+ 298 The Prefix Options field 300 The N-bit is set in PrefixOptions for a host address 301 (PrefixLength=128) that identifies the advertising router. While it 302 is similar to the LA-bit, there are two differences. The advertising 303 router MAY choose NOT to set the N-bit even when the above conditions 304 are met. If the N-bit is set and the PrefixLength is NOT 128, the 305 N-bit MUST be ignored. Additionally, the N-bit is propagated in the 306 PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an 307 Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set 308 in the PrefixOptions. Similarly, the N-bit is propagated in the 309 PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS- 310 External-LSA corresponding to an NSSA route as described in section 3 311 of RFC 3101 ([NSSA]). The N-bit is to the Inter-Area-Prefix-TLV 312 (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- 313 Prefix-TLV (Section 3.7) The N-bit is useful for applications such as 314 identifying the prefixes corresponding to Node Segment Identifiers 315 (SIDs) in Segment Routing [SEGMENT-ROUTING]. 317 3.2. Router-Link TLV 319 The Router-Link TLV defines a single router link and the field 320 definitions correspond directly to links in the OSPFv3 Router-LSA, 321 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 322 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 323 MUST be ignored. 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | 1 (Router-Link) | TLV Length | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type | 0 | Metric | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Interface ID | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Neighbor Interface ID | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Neighbor Router ID | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 . . 339 . sub-TLVs . 340 . . 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Router-Link TLV 345 3.3. Attached-Routers TLV 347 The Attached-Routers TLV defines all the routers attached to an 348 OSPFv3 multi-access network. The field definitions correspond 349 directly to content of the OSPFv3 Network-LSA, section A.4.4, 350 [OSPFV3]. The Attached-Routers TLV is only applicable to the E- 351 Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST be 352 ignored. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | 2 (Attached-Routers) | TLV Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Adjacent Neighbor Router ID | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 . . 362 . Additional Adjacent Neighbors . 363 . . 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Attached-Routers TLV 368 There are two reasons for not having a separate TLV or sub-TLV for 369 each adjacent neighbor. The first is to discourage using the E- 370 Network-LSA for more than its current role of solely advertising the 371 routers attached to a multi-access network. The router's metric as 372 well as the attributes of individual attached routers should be 373 advertised in their respective E-Router-LSAs. The second reason is 374 that there is only a single E-Network-LSA per multi-access link with 375 the Link State ID set to the Designated Router's Interface ID and, 376 consequently, compact encoding has been chosen to decrease the 377 likelihood that the size of the E-Network-LSA will require IPv6 378 fragmentation when advertised in an OSPFv3 Link State Update packet. 380 3.4. Inter-Area-Prefix TLV 382 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 383 The field definitions correspond directly to the content of an OSPFv3 384 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 385 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. 386 Additionally, the PrefixOptions are extended as described in 387 Section 3.1. The Inter-Area-Prefix TLV is only applicable to the E- 388 Inter-Area-Prefix-LSA (Section 4.3). Inclusion in other Extended 389 LSAs MUST be ignored. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | 3 (Inter-Area Prefix) | TLV Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | 0 | Metric | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | PrefixLength | PrefixOptions | 0 | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Address Prefix | 401 | ... | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 . . 404 . sub-TLVs . 405 . . 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Inter-Area Prefix TLV 410 3.5. Inter-Area-Router TLV 412 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 413 Boundary Router (ASBR) reachable in another area. The field 414 definitions correspond directly to the content of an OSPFv3 Inter- 415 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 416 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 417 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | 4 (Inter-Area Router) | TLV Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | 0 | Options | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | 0 | Metric | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Destination Router ID | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 . . 431 . sub-TLVs . 432 . . 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Inter-Area Router TLV 437 3.6. External-Prefix TLV 439 The External-Prefix TLV defines a single OSPFv3 external prefix. 440 With the exception of omitted fields noted below, the field 441 definitions correspond directly to the content of an OSPFv3 IPv6 442 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 443 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 444 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 445 and the E-NSSA-LSA (Section 4.6). Additionally, the PrefixOptions 446 are extended as described in Section 3.1. Inclusion in other 447 Extended LSAs MUST be ignored. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | 5 (External Prefix) | TLV Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | |E| | | Metric | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | PrefixLength | PrefixOptions | 0 | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Address Prefix | 459 | ... | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 . . 462 . sub-TLVs . 463 . . 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 External Prefix TLV 468 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 469 and External Route Tag are now sub-TLVs. Given the Referenced LS 470 type and Referenced Link State ID from the AS-External-LSA have never 471 been used or even specified, they have been omitted from the External 472 Prefix TLV. If there were ever a requirement for a referenced LSA, 473 it could be satisfied with a sub-TLV. 475 The following sub-TLVs are defined for optional inclusion in the 476 External Prefix TLV: 478 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.10) 480 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.11) 482 o 3 - Route Tag sub-TLV (Section 3.12) 484 3.7. Intra-Area-Prefix TLV 486 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 487 The field definitions correspond directly to the content of an OSPFv3 488 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 489 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 490 TLV is only applicable to the E-Link-LSA (Section 4.7) and the E- 491 Intra-Area-Prefix-LSA (Section 4.8). Additionally, the PrefixOptions 492 are extended as described in Section 3.1. Inclusion in other 493 Extended LSAs MUST be ignored. 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | 6 (Intra-Area Prefix) | TLV Length | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | 0 | Metric | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | PrefixLength | PrefixOptions | 0 | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Address Prefix | 505 | ... | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 . . 508 . sub-TLVs . 509 . . 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 Intra-Area Prefix TLV 514 3.8. IPv6 Link-Local Address TLV 516 The IPv6 Link-Local Address TLV is to be used with IPv6 address 517 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 518 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 519 other Extended LSAs MUST be ignored. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | 7 (IPv6 Local-Local Address) | TLV Length | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | | 527 +- -+ 528 | | 529 +- IPv6 Link-Local Interface Address -+ 530 | | 531 +- -+ 532 | | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 . . 535 . sub-TLVs . 536 . . 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 IPv6 Link-Local Address TLV 541 3.9. IPv4 Link-Local Address TLV 543 The IPv4 Link-Local Address TLV is to be used with IPv4 address 544 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 545 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 546 other Extended LSAs MUST be ignored. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | 8 (IPv4 Local-Local Address) | TLV Length | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | IPv4 Link-Local Interface Address | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 . . 556 . sub-TLVs . 557 . . 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 IPv4 Link-Local Address TLV 562 3.10. IPv6-Forwarding-Address Sub-TLV 564 The IPv6 Forwarding Address TLV has identical semantics to the 565 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 566 Forwarding Address TLV is applicable to the External-Prefix TLV 567 (Section 3.6). Specification as a sub-TLV of other TLVs is not 568 defined herein. The sub-TLV is optional and the first specified 569 instance is used as the Forwarding Address as defined in [OSPFV3]. 570 Instances subsequent to the first MUST be ignored. 572 The IPv6 Forwarding Address TLV is to be used with IPv6 address 573 families as defined in [OSPFV3-AF] It MUST be ignored for other 574 address families. 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | 1 - Forwarding Address | sub-TLV Length | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | | 582 +- -+ 583 | | 584 +- Forwarding Address -+ 585 | | 586 +- -+ 587 | | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 Forwarding Address Tag TLV 592 3.11. IPv4-Forwarding-Address Sub-TLV 594 The IPv4 Forwarding Address TLV has identical semantics to the 595 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 596 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 597 applicable to the External-Prefix TLV (Section 3.6). Specification 598 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 599 optional and the first specified instance is used as the Forwarding 600 Address as defined in [OSPFV3]. Instances subsequent to the first 601 MUST be ignored. 603 The IPv4 Forwarding Address TLV is to be used with IPv3 address 604 families as defined in [OSPFV3-AF] It MUST be ignored for other 605 address families. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | 2 - Forwarding Address | sub-TLV Length | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Forwarding Address | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Forwarding Address Tag TLV 617 3.12. Route-Tag Sub-TLV 619 The optional Route Tag sub-TLV has identical semantics to the 620 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 621 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). 622 Specification as a sub-TLV of other TLVs is not defined herein. The 623 sub-TLV is optional and the first specified instance is used as the 624 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 625 MUST be ignored. 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | 3 - Route Tag | sub-TLV Length | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Route Tag | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 Route Tag Sub-TLV 637 4. OSPFv3 Extended LSAs 639 This section specifies the OSPFv3 Extended LSA formats and encoding. 640 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 641 LSAs specifed in [OSPFV3]. 643 4.1. OSPFv3 E-Router-LSA 645 The E-Router-LSA has an LS Type of 0xA021 and has the same base 646 information content as the Router-LSA defined in section A.4.3 of 647 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 648 extendable and represented as TLVs. 650 0 1 2 3 651 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 652 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | LS Age |1|0|1| 0x21 | 654 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Link State ID | 656 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Advertising Router | 658 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | LS Sequence Number | 660 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | LS Checksum | Length | 662 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | 0 |Nt|x|V|E|B| Options | 664 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 . . 666 . TLVs . 667 . . 668 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Extended Router-LSA 672 Other than having a differnt LS Type, all LSA Header fields are the 673 same as defined for the Router-LSA. Initially, only the top-level 674 Router-Link TLV Section 3.2 is applicable and an E-Router-LSA may 675 include multiple Router-Link TLVs. Like the existing Router-LSA, the 676 LSA length is used to determine the end of the LSA including TLVs. 678 4.2. OSPFv3 E-Network-LSA 680 The E-Network-LSA has an LS Type of 0xA022 and has the same base 681 information content as the Network-LSA defined in section A.4.4 of 682 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 683 extendable and represented as TLVs. 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | LS Age |1|0|1| 0x22 | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Link State ID | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Advertising Router | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | LS Sequence Number | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | LS Checksum | Length | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | 0 | Options | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 . . 701 . TLVs . 702 . . 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 E-Network-LSA 707 Other than having a differnt LS Type, all LSA Header fields are the 708 same as defined for the Network-LSA. Like the existing Network-LSA, 709 the LSA length is used to determine the end of the LSA including 710 TLVs. Initially, only the top-level Attached-Routers TLV Section 3.3 711 is applicable. If the Attached-Router TLV is not included in the E- 712 Network-LSA, it is treated as malformed as described in Section 5. 713 Instances of the Attached-Router TLV subsequent to the first MUST be 714 ignored. 716 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 718 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 719 base information content as the Inter-Area-Prefix-LSA defined in 720 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 721 Prefix-LSA, it is fully extendable and represented as TLVs. 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | LS Age |1|0|1| 0x23 | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Link State ID | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Advertising Router | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | LS Sequence Number | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | LS Checksum | Length | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 . . 737 . TLVs . 738 . . 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 E-Inter-Area-Prefix-LSA 743 Other than having a differnt LS Type, all LSA Header fields are the 744 same as defined for the Inter-Area-Prefix-LSA. In order to retain 745 compatibility and semantics with the current OSPFv3 specification, 746 each Inter-Area-Prefix LSA MUST contain a single Inter-Area Prefix 747 TLV. This will facilitate migration and avoid changes to functions 748 such as incremental SPF computation. 750 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 751 determine the end of the LSA including TLV. Initially, only the top- 752 level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the 753 Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, 754 it is treated as malformed as described in Section 5. Instances of 755 the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 757 4.4. OSPFv3 E-Inter-Area-Router-LSA 759 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 760 base information content as the Inter-Area-Router-LSAE defined in 761 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 762 LSA, it is fully extendable and represented as TLVs. 764 0 1 2 3 765 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 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | LS Age |1|0|1| 0x24 | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Link State ID | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Advertising Router | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | LS Sequence Number | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | LS Checksum | Length | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 . . 778 . TLVs . 779 . . 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 E-Inter-Area-Router-LSA 784 Other than having a differnt LS Type, all LSA Header fields are the 785 same as defined for the Inter-Area-Router-LSA. In order to retain 786 compatibility and semantics with the current OSPFv3 specification, 787 each Inter-Area-Router LSA MUST contain a single Inter-Area Router 788 TLV. This will facilitate migration and avoid changes to functions 789 such as incremental SPF computation. 791 Like the existing Inter-Area-Router-LSA, the LSA length is used to 792 determine the end of the LSA including TLV. Initially, only the top- 793 level Inter-Area-Router TLV (Section 3.5) is applicable. If the 794 Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, 795 it is treated as malformed as described in Section 5. Instances of 796 the Inter-Area-Router TLV subsequent to the first MUST be ignored. 798 4.5. OSPFv3 E-AS-External-LSA 800 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 801 information content as the AS-External-LSA defined in section A.4.7 802 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 803 fully extendable and represented as TLVs. 805 0 1 2 3 806 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 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | LS Age |1|1|0| 0x25 | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Link State ID | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Advertising Router | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | LS Sequence Number | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | LS Checksum | Length | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 . . 819 . TLVs . 820 . . 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 E-AS-External-LSA 825 Other than having a differnt LS Type, all LSA Header fields are the 826 same as defined for the AS-External-LSA. In order to retain 827 compatibility and semantics with the current OSPFv3 specification, 828 each LSA MUST contain a single External Prefix TLV. This will 829 facilitate migration and avoid changes to OSPFv3 processes such as 830 incremental SPF computation. 832 Like the existing AS-External-LSA, the LSA length is used to 833 determine the end of the LSA including sub-TLVs. Initially, only the 834 top-level External-Prefix TLV (Section 3.6) is applicable. If the 835 External-Prefix TLV is not included in the E-External-AS-LSA, it is 836 treated as malformed as described in Section 5. Instances of the 837 External-Prefix TLV subsequent to the first MUST be ignored. 839 4.6. OSPFv3 E-NSSA-LSA 841 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 842 External-LSA Section 4.5. This is the same relationship as exists 843 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 844 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 845 area flooding scope. Future requirements may dictate that supported 846 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 847 However, future requirements are beyond the scope of this document. 849 4.7. OSPFv3 E-Link-LSA 851 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 852 information content as the Link-LSA defined in section A.4.9 of 853 [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 854 and represented as TLVs. 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | LS Age |1|0|0| 0x28 | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Link State ID | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Advertising Router | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | LS Sequence Number | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | LS Checksum | Length | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Rtr Priority | Options | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 . . 872 . TLVs . 873 . . 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 E-Link-LSA 878 Other than having a differnt LS Type, all LSA Header fields are the 879 same as defined for the Link-LSA. 881 Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address 882 TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are 883 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 884 affords advertisement of multiple intra-area prefixes. Hence, 885 multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and 886 the LSA length defines the end of the LSA including all TLVs. 888 A single instance of the IPv6 Link-Local Address TLV (Section 3.8) 889 SHOULD be included in the E-Link-LSA. Instances following the first 890 MUST be ignored. For IPv4 address families as defined in 891 [OSPFV3-AF], this TLV MUST be ignored. 893 Similarly, only a single instance of the IPv4 Link-Local Address TLV 894 (Section 3.9) SHOULD be included in the E-Link-LSA. Instances 895 following the first MUST be ignored. For OSPFv3 IPv6 address 896 families as defined in [OSPFV3-AF], this TLV MUST be ignored. 898 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 899 Address Family is not included in the E-Link-LSA, it is treated as 900 malformed as described in Section 5. 902 Future specifications may support advertisement of routing and 903 topology information for multiple address families. However, this is 904 beyond the scope of this document. 906 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 908 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 909 base information content as the Intra-Area-Prefix-LSA defined in 910 section A.4.10 of [OSPFV3] except for the Referenced LS Type. 911 However, unlike the Intra-Area-Prefix-LSA, it is fully extendable and 912 represented as TLVs. The Referenced LS Type MUST be either an E- 913 Router-LSA (0xA021) or an E-Network-LSA (0xA022). 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | LS Age |1|0|1| 0x29 | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Link State ID | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Advertising Router | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | LS Sequence Number | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | LS Checksum | Length | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | 0 | Referenced LS Type | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Referenced Link State ID | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Referenced Advertising Router | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 . . 935 . TLVs . 936 . . 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 E-Intra-Area-Prefix-LSA 941 Other than having a differnt LS Type, all LSA Header fields are the 942 same as defined for the Intra-Area-Prefix-LSA. 944 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 945 advertisement of multiple intra-area prefixes. Hence, multiple 946 Intra-Area Prefix TLVs may be specified and the LSA length defines 947 the end of the LSA including all TLVs. 949 5. Malformed OSPFv3 Extended LSA Handling 951 Extended LSAs that have inconsistent length or other encoding errors, 952 as described herein, MUST NOT be installed in the Link State 953 Database, acknowledged, or flooded. Reception of malformed LSAs 954 SHOULD be counted and/or logged for examination by the administrator 955 of the OSPFv3 Routing Domain. Note that for the purposes of length 956 validation, a TLV or Sub-TLV should not be considered invalid unless 957 the length exceeds the length of the LSA or does not meet the minimum 958 length requirements. This allows for Sub-TLVs to be added as 959 described in Section 6.3. 961 Additionally, an LSA MUST be considered malformed if it does not 962 include any required TLV or Sub-TLVs. 964 6. LSA Extension Backward Compatibility 966 In the context of this document, backward compatibility is solely 967 related to the capability of an OSPFv3 router to receive, process, 968 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 969 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 970 extensions utilizing the TLV-based LSAs is out of scope and must be 971 covered in the documents describing those extensions. Both full and, 972 if applicable, partial deployment SHOULD be specified for future TLV- 973 based OSPFv3 LSA extensions. 975 6.1. Full Extended LSA Migration 977 If ExtendedLSASupport is enabled Appendix A, OSPFv3 Extended LSAs 978 will be originated and used for the SPF computation. Individual OSPF 979 Areas can be migrated separately with the Legacy AS-External LSAs 980 being originated and used for the SPF computation. This is 981 accomplished by enabled AreaExtendedLSASupport Appendix B. 983 An OSPFv3 routing domain or area may be non-disruptively migrated 984 using separate OSPFv3 instances for the extended LSAs. Initially, 985 the OSPFv3 instances with ExtendedLSASupport will have a lower 986 preference, i.e., higher administrative distance, than the OSPFv3 987 instances originating and using the Legacy LSAs. Once the routing 988 domain or area is fully migrated and the OSPFv3 Routing Information 989 Bases (RIB) have been verified, the OSPFv3 instances using the 990 extended LSAs can be given preference. When this has been completed 991 and the routing within the OSPF routing domain or area has been 992 verified, the original OSPFv3 instance using Legacy LSAs can be 993 removed. 995 6.2. Extended LSA Spare-Mode Backward Compatibility 997 In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation 998 and will only originate extended LSAs when LSA origination is 999 required in support of addtional functionality. Furthermore, the 1000 extended LSAs will only include those TLVs which require further 1001 specification for that new functionality. Hence, this mode of 1002 compatibility is know as "sparse-mode". The advantage of sparse-mode 1003 is that functionality utilizing the OSPFv3 extended LSAs can be added 1004 to an existing OSFPv3 routing domain without the requirement for 1005 migration. In essence, this compatibility mode is very much like the 1006 approach taken for OSPFv2 [OSPF-PREFIX-LINK]. As with all the 1007 compatibility modes, backward compatibility for the functions 1008 utilizing the extended LSAs must be described in the IETF documents 1009 describing those functions. 1011 6.3. LSA TLV Processing Backward Compatibility 1013 This section defines the general rules for processing LSA TLVs. To 1014 ensure compatibility of future TLV-based LSA extensions, all 1015 implementations MUST adhere to these rules: 1017 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 1018 processing Extended-LSAs. 1020 2. Whether or not partial deployment of a given TLV is supported 1021 MUST be specified. 1023 3. If partial deployment is not supported, mechanisms to ensure the 1024 corresponding feature are not deployed MUST be specified in the 1025 document defining the new TLV or sub-TLV. 1027 4. If partial deployment is supported, backward compatibility and 1028 partial deployment MUST be specified in the document defining the 1029 new TLV or sub-TLV. 1031 5. If a TLV or Sub-TLV is recognized but the length is less than the 1032 minimum, then the LSA should be considered malformed and it 1033 SHOULD NOT be acknowledged. Additionally, the occurence SHOULD 1034 be logged with enough information to identify the LSA by type, 1035 originator, and sequence number and the TLV or Sub-TLV in error. 1036 Ideally, the log entry would include the hexidecimal or binary 1037 representation of the LSA including the malformed TLS or Sub-TLV. 1039 6. Documents specifying future TLVs or Sub-TLVs MUST specify the 1040 requirements for usage of those TLVs or Sub-TLVs. 1042 7. Future TLV or Sub-TLVs must be optional. However, there may be 1043 requirements for Sub-TLVs if an optional TLV is specified. 1045 7. Security Considerations 1047 In general, extendible OSPFv3 LSAs are subject to the same security 1048 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1049 implementations must assure that malformed TLV and sub-TLV 1050 permutations do not result in errors that cause hard OSPFv3 failures. 1052 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1053 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1054 mechanisms described herein would greatly simplify the extension. 1056 8. IANA Considerations 1058 This specification defines nine OSPFv3 Extended LSA types as 1059 described in Section 2. These will be added to the existing OSPFv3 1060 LSA Function Codes registry. 1062 The specification will define a new code point for the N-bit in the 1063 OSPFv3 Prefix-Options registry. The value 0x20 is suggested. 1065 This specification also creates two registries OSPFv3 Extended-LSAs 1066 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1067 registries are common to all Extended-LSAs and their respective 1068 definitions must define where they are applicable. 1070 8.1. OSPFv3 Extended-LSA TLV Registry 1072 The OSPFv3 Extended-LSA TLV registry will define top-level TLVs for 1073 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1074 registry. 1076 Nine values are allocated by this specification: 1078 o 0 - Reserved 1080 o 1 - Router-Link TLV 1082 o 2 - Attached-Routers TLV 1084 o 3 - Inter-Area Prefix TLV 1086 o 4 - Inter-Area Router TLV 1088 o 5 - External Prefix TLV 1089 o 6 - Intra-Area Prefix TLV 1091 o 7 - IPv6 Link-Local Address TLV 1093 o 8 - IPv4 Link-Local Address TLV 1095 Types in the range 9-32767 are allocated via IETF Consensus or IESG 1096 Approval. 1098 Types in the range 32768-33023 are for experimental use; these will 1099 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1101 Types in the range 33024-65535 are not to be assigned at this time. 1102 Before any assignments can be made in the 33024-65535 range, there 1103 MUST be an IETF specification that specifies IANA Considerations that 1104 covers the range being assigned. 1106 8.2. OSPFv3 Extended-LSA sub-TLV Registry 1108 The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any 1109 level of nesting for Extended-LSAs and should be placed in the 1110 existing OSPFv3 IANA registry. 1112 Four values are allocated by this specification: 1114 o 0 - Reserved 1116 o 1 - IPv6 Forwarding Address sub-TLV 1118 o 2 - IPv4 Forwarding Address sub-TLV 1120 o 3 - Route Tag sub-TLV 1122 Types in the range 4-32767 are allocated via IETF Consensus or IESG 1123 Approval. 1125 Types in the range 32768-33023 are for experimental use; these will 1126 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1128 Types in the range 33024-65535 are not to be assigned at this time. 1129 Before any assignments can be made in the 33024-65535 range, there 1130 MUST be an IETF specification that specifies IANA Considerations that 1131 covers the range being assigned. 1133 9. Contributors 1135 Contributors' Addresses 1137 Sina Mirtorabi 1138 Cisco Systems 1139 170 Tasman Drive 1140 San Jose, CA 95134 1141 USA 1142 Email: sina@cisco.com 1144 10. References 1146 10.1. Normative References 1148 [GRACEFUL-RESTART] 1149 Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful 1150 Restart", RFC 5187, June 2008. 1152 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1153 RFC 3101, January 2003. 1155 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1156 for IPv6", RFC 5340, July 2008. 1158 [OSPFV3-AF] 1159 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1160 Aggarwal, "Support of Address Families in OSPFv3", RFC 1161 5838, April 2010. 1163 [RFC-KEYWORDS] 1164 Bradner, S., "Key words for use in RFCs to Indicate 1165 Requirement Levels", RFC 2119, March 1997. 1167 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1168 Extensions to OSPF", RFC 3630, September 2003. 1170 10.2. Informative References 1172 [MT-OSPFV3] 1173 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1174 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt 1175 (work in progress), January 2008. 1177 [OSPF-DIGITAL-SIGNATURE] 1178 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1179 Digital Signatures", RFC 2154, June 1997. 1181 [OSPF-PREFIX-LINK] 1182 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1183 Tantsura, J., and A. Lindem, "OSPF Prefix/Link 1184 Attributes", RFC 7684, December 2015. 1186 [SEGMENT-ROUTING] 1187 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1188 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1189 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1190 segment-routing-extensions-10.txt (work in progress), July 1191 2016. 1193 Appendix A. Appendix A - Global Configuration Parameters 1195 The global configurable parameter ExtendedLSASupport will be added to 1196 the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1197 Router will originate OSPFv3 Extended LSAs and use the LSAs for the 1198 SPF computation. If ExtendedLSASupport is not enabled, a subset of 1199 OSPFv3 Extended LSAs may still be originated and used for other 1200 functions as described in Section 6.2. 1202 Appendix B. Appendix B - Area Configuration Parameters 1204 The area configurable parameter AreaExtendedLSASupport will be added 1205 to the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1206 Router will originate link and area OSPFv3 Extended LSAs and use the 1207 LSAs for the SPF computation. Legacy AS-Scoped LSAs will still be 1208 originated and used for the AS External LSA computation. If 1209 AreaExtendedLSASupport is not enabled a subset of OSPFv3 link and 1210 area Extended LSAs may still be originated and used for other 1211 functions as described in Section 6.2. 1213 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1214 disabling AreaExtendedLSASupport when ExtendedLSASupport is enabled 1215 is contradictory and MAY be prohibited by the implementation. 1217 Appendix C. Appendix C - Deprecated LSA Extension Backward 1218 Compatibility 1220 In the context of this document, backward compatibility is solely 1221 related to the capability of an OSPFv3 router to receive, process, 1222 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 1223 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 1224 extensions utilizing the TLV-based LSAs is out of scope and must be 1225 covered in the documents describing those extensions. Both full and, 1226 if applicable, partial deployment SHOULD be specified for future TLV- 1227 based OSPFv3 LSA extensions. 1229 Three distinct backward compatibility modes are supported dependent 1230 on the OSPFv3 routing domain migration requirements. For simplicity 1231 and to avoid the scaling impact of maintaining both TLV and non-TLV 1232 based versions of the same LSA within a routing domain, the basic 1233 backward compatibility mode will not allow mixing of LSA formats. 1234 Different LSA formats could still be supported with multiple OSPFv3 1235 instances and separate OSPFv3 routing domains. Additionally, a more 1236 flexible mode is provided in Appendix C.1, where both formats of LSA 1237 coexist. In order to facilitate backward compatibility, the OSPFv3 1238 options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), 1239 will contain two additional options bits. The EL-bits will be used 1240 to indicate that the OSPFv3 router's level of Extended LSA support. 1241 An OSPFv3 router configured to support extended LSAs MUST set its 1242 options field EL-bits in OSPFv3 Hello and Database Description 1243 packets as follows: 1245 B'00' 1246 None - Extended LSAs are not originated nor used in the SPF 1247 calculation (except for future functionalities as described in 1248 Section 6.2) . 1250 B'01' 1251 MixedModeOriginateOnly - Both Extended and Legacy LSAs are 1252 originated. Legacy LSAs are used in the SPF computation. 1254 B'10' 1255 MixedModeOriginateSPF - Both extended and Legacy LSAs are 1256 originated. Extended LSAs are used in the SPF computation. 1258 B'11' 1259 Full - Only extended LSAs are originated and used in the SPF 1260 computation. 1262 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 1263 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 1264 Database Description packets with the options field EL-bits set to 1265 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 1266 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 1267 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 1268 Description packets with the options field EL-bits set to None 1269 (B'00'). In this manner, OSPFv3 routers using new encodings can be 1270 completely isolated from those OSPFv3 routers depending on the RFC 1271 5340 encoding and not setting their options field EL-bits since the 1272 default setting indicates no support for extended LSAs. 1274 Finally, a mode supporting existing OSPFv3 routing domains is 1275 provided. This mode, subsequently referred to as "sparse-mode", will 1276 use the TLV-based LSAs solely in support of new functionality 1277 Section 6.2. In this compatibility mode, the EL-bits will be 1278 advertised as B'00' since the backward compatibility with the Legacy 1279 LSAs is not supported or required. 1281 1 2 1282 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1284 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1286 The Options field 1288 EL-bits 1289 These bits indicate the level of Extended LSA support. 1290 B'00' - Extended LSAs are not originate nor used in the 1291 SPF calculation (except for new functionalities 1292 for future functions as described in Section 6.2). 1293 B'01' - Both extended and Legacy LSAs are originated. 1294 Non-extended LSAs are used in the SPF computation. 1295 B'10' - Both extended and Legacy LSAs are originated. 1296 Extended LSAs are used in the SPF computation. 1297 B'11' - Only extended LSA are originated and used in the 1298 SPF computation. 1300 Options Field EL-bits 1302 The EL-bits will also be set in the LSA options field in Extended and 1303 Legacy LSAs. While the value of the EL-bits has no functional 1304 significance in the LSA options field, visibility of every OSPFv3 1305 Router's extended LSA support is expected to be very useful for 1306 management and troubleshooting during the migration period. 1308 C.1. Extended LSA Mixed-Mode Backward Compatibility 1310 An implementation MAY support configuration allowing a graceful 1311 transition from the Legacy (non-TLV-based) LSAs to the extended (TLV- 1312 based) LSAs in an OSPFv3 routing domain. In these routing domains, 1313 the OSPFv3 routers configured with a value of MixedModeOriginateOnly 1314 or MixedModeOriginateSPF for ExtendedLSASupport, (Appendix C.2), MUST 1315 originate both the extended and legacy versions of the OSPFv3 LSAs 1316 described herein. For the purposes of Shortest Path First (SPF) 1317 computation, the Legacy LSAs are used for SPF computation when 1318 MixedModeOriginateOnly is configured and the extended LSAs are used 1319 when MixedModeOriginateSPF is specified. The Extended LSAs MAY be 1320 used for functions other than routing computation as long as backward 1321 compatibility is specified in the documents specifying those 1322 functions. 1324 In this manner, OSPFv3 routing domains utilizing the new encodings 1325 can be gradually migrated with a worst-case overhead cost of 1326 approximately doubling the number of LSAs in the routing domain. The 1327 transition within an OSPFv3 routing domain would progress as follows: 1329 1. Configure OSPFv3 Router ExtendedLSASupport to 1330 MixedModeOriginateOnly so that routers originate the extended 1331 LSAs. 1333 2. When all the OSPFv3 Routers have been reconfigured to 1334 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 1335 use the extended LSAs by configuring ExtendedLSASupport to 1336 MixedModeOriginateSPF. This can be done on a small subset of 1337 OSPFv3 Routers and the route tables can be verified. 1339 3. When all the OSPFv3 Routers have been reconfigured to 1340 MixedModeOriginateSPF and the routing has been verified, 1341 reconfigure OSPFv3 Routers to purge or simply not refresh the 1342 Legacy LSA by configuring ExtendedLSASupport to Full. 1344 In order to prevent OSPFv3 routing domain routing loops, the 1345 advertised metrics in the Extended LSAs and Legacy LSAs MUST be 1346 identical. 1348 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 1350 An implementation MAY also support configuration allowing graceful 1351 transition from the Legacy LSAs to the extended LSAs within a single 1352 area. In these areas, the parameter AreaExtendedLSASupport 1353 (Appendix C.3) may be configured to take precedence over the global 1354 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 1355 will only apply to link and area scoped LSAs within the area and area 1356 based SPF calculations. The default is for the 1357 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 1358 The configuration of ExtendedLSASupport will apply to AS-External 1359 LSAs even when AreaExtendedLSASupport takes precedence. 1361 When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 1362 router configured with MixedModeOriginate will use the Legacy LSAs to 1363 determine whether or not the graceful restart has completed 1364 successfully. Similarly, an OSPFv3 router configured with 1365 MixedModeOriginateSPF will use the extended LSAs. In other words, 1366 successful OSPFv3 graceful restart determination will follow the SPF 1367 calculation. 1369 C.2. Global Configuration Parameters 1371 An additional global configurable parameter will be added to the 1372 OSPFv3 protocol. 1374 ExtendedLSASupport 1375 This is an enumeration type indicating the extent to which the 1376 OSPFv3 instance supports the TLV format described herein for 1377 Extended LSAs. The valid values for the enumeration are: 1379 * None - Extended LSAs will not be originated or used in the SPF 1380 calculation. This is the default. When OSPFv3 functions 1381 requiring extended LSA are configured, and the 1382 ExtendedLSASuppport is "None", extended LSAs may be used as 1383 described in Section 6.2. 1385 * MixedModeOriginateOnly - Both extended and Legacy LSAs will be 1386 originated. OSPFv3 adjacencies will be formed with OSPFv3 1387 routers not supporting this specification. The Legacy LSAs are 1388 used for the SPF computation. 1390 * MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will 1391 be originated. OSPFv3 adjacencies will be formed with OSPFv3 1392 routers not supporting this specification. The Extended LSAs 1393 are used for the SPF computation. 1395 * Full - Extended LSAs will be originated and adjacencies will 1396 ndot be formed with OSPFv3 routers not supporting this 1397 specification. Only Extended LSAs will be originated. 1399 C.3. Area Configuration Parameters 1401 An additional area configurable parameter will be added to the OSPFv3 1402 protocol. 1404 AreaExtendedLSASupport 1405 This is an enumeration type indicating the extent to which the 1406 OSPFv3 area supports the TLV format described herein for Extended 1407 LSAs. The valid value for the enumeration are: 1409 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1410 from ExtendedLSASupport. This is the default. 1412 * None - Extended LSAs will not be originated or used in the SPF 1413 calculation. This is the default. When OSPFv3 functions 1414 requiring extended LSA are configured, and the 1415 ExtendedLSASuppport is "None", the spare-mode compatability is 1416 in effect Section 6.2. 1418 * MixedModeOriginateOnly - Both extended and legacy link and area 1419 scoped LSAs will be originated. OSPFv3 adjacencies will be 1420 formed with OSPFv3 routers not supporting this specification. 1421 The Legacy LSAs are used for the area SPF computation. 1423 * MixedModeOriginateSPF - Both extended and legacy link and area 1424 scoped LSAs will be originated. OSPFv3 adjacencies will be 1425 formed with OSPFv3 routers not supporting this specification. 1426 The Extended LSAs are used for the area SPF computation. 1428 * Full - Link and area scoped Extended LSAs will be originated 1429 and adjacencies will not be formed with OSPFv3 routers not 1430 supporting this specification. Only Extended LSAs will be 1431 originated. 1433 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1434 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1435 when Full is specified for ExtendedLSASupport is contradictory and 1436 MAY be prohibited by the implementation. 1438 Authors' Addresses 1440 Acee Lindem 1441 Cisco Systems 1442 301 Midenhall Way 1443 Cary, NC 27513 1444 USA 1446 Email: acee@cisco.com 1448 Abhay Roy 1449 Cisco Systems 1450 170 Tasman Drive 1451 San Jose, CA 95134 1452 USA 1454 Email: akr@cisco.com 1455 Dirk Goethals 1456 Nokia 1457 Copernicuslaan 50 1458 Antwerp 2018 1459 Belgium 1461 Email: dirk.goethals@nokia.com 1463 Veerendranatha Reddy Vallem 1464 Bangalore 1465 India 1467 Email: vallem.veerendra@gmail.com 1469 Fred Baker 1470 Santa Barbara, California 93117 1471 USA 1473 Email: FredBaker.IETF@gmail.com