idnits 2.17.1 draft-ietf-ospf-ospfv3-lsa-extend-18.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 (November 21, 2017) is 2345 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: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-10 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: May 25, 2018 D. Goethals 6 Nokia 7 V. Reddy Vallem 9 F. Baker 11 November 21, 2017 13 OSPFv3 LSA Extendibility 14 draft-ietf-ospf-ospfv3-lsa-extend-18.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 May 25, 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 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 100 10.2. Informative References . . . . . . . . . . . . . . . . . 31 101 Appendix A. Appendix A - Global Configuration Parameters . . . . 31 102 Appendix B. Appendix B - Area Configuration Parameters . . . . . 31 103 Appendix C. Appendix C - Deprecated LSA Extension Backward 104 Compatibility . . . . . . . . . . . . . . . . . . . 32 105 C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 34 106 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 34 107 C.2. Global Configuration Parameters . . . . . . . . . . . . . 35 108 C.3. Area Configuration Parameters . . . . . . . . . . . . . . 36 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 111 1. Introduction 113 OSPFv3 requires functional extension beyond what can readily be done 114 with the fixed-format Link State Advertisement (LSA) as described in 115 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 116 OSPFv3 links and advertised IPv6 prefixes must be advertised in 117 separate LSAs and correlated to the fixed-format LSAs. This document 118 extends the LSA format by encoding the existing OSPFv3 LSA 119 information in Type-Length-Value (TLV) tuples and allowing 120 advertisement of additional information with additional TLVs. 121 Backward compatibility mechanisms are also described. 123 A similar extension was previously proposed in support of multi- 124 topology routing. Additional requirements for OSPFv3 LSA extension 125 include source/destination routing, route tagging, and others. 127 A final requirement is to limit the changes to OSPFv3 to those 128 necessary for TLV-based LSAs. For the most part, the semantics of 129 existing OSPFv3 LSAs are retained for their TLV-based successor LSAs 130 described herein. Additionally, encoding details, e.g., the 131 representation of IPv6 prefixes as described in section A.4.1 in RFC 132 5340 [OSPFV3], have been retained. This requirement was included to 133 increase the expedience of IETF adoption and deployment. 135 The following aspects of OSPFv3 LSA extension are described: 137 1. Extended LSA Types 139 2. Extended LSA TLVs 140 3. Extended LSA Formats 142 4. Backward Compatibility 144 1.1. Requirements notation 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC-KEYWORDS]. 150 1.2. OSPFv3 LSA Terminology 152 The TLV-based OSPFv3 LSAs described in this document will be referred 153 to as Extended LSAs. The OSPFv3 fixed-format LSAs [OSPFV3] will be 154 referred to as Legacy LSAs. 156 1.3. Acknowledgments 158 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 159 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 161 Thanks for Peter Psenak for significant contributions to the backward 162 compatibility mechanisms. 164 Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony 165 Przygienda for review of the draft versions and discussions of 166 backward compatibility. 168 Thanks to Alan Davey for review and comments including the suggestion 169 to separate the extended LSA TLV definitions from the extended LSAs 170 definitions. 172 Thanks to David Lamparter for review and suggestions on backward 173 compatibility. 175 Thanks to Karsten Thomann, Chris Bowers, Meng Zhang, and Nagendra 176 Kumar for review and editorial comments. 178 The RFC text was produced using Marshall Rose's xml2rfc tool. 180 2. OSPFv3 Extended LSA Types 182 In order to provide backward compatibility, new LSA codes must be 183 allocated. There are eight fixed-format LSAs defined in RFC 5340 184 [OSPFV3]. For ease of implementation and debugging, the LSA function 185 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 186 added. The alternative to this mapping was to allocate a bit in the 187 LS Type indicating the new LSA format. However, this would have used 188 one half the LSA function code space for the migration of the eight 189 original fixed-format LSAs. For backward compatibility, the U-bit 190 will be set in LS Type so that the LSAs will be flooded by OSPFv3 191 routers that do not understand them. 193 LSA function code LS Type Description 194 ---------------------------------------------------- 195 33 0xA021 E-Router-LSA 196 34 0xA022 E-Network-LSA 197 35 0xA023 E-Inter-Area-Prefix-LSA 198 36 0xA024 E-Inter-Area-Router-LSA 199 37 0xC025 E-AS-External-LSA 200 38 N/A Unused (Not to be allocated) 201 39 0xA027 E-Type-7-LSA 202 40 0x8028 E-Link-LSA 203 41 0xA029 E-Intra-Area-Prefix-LSA 205 OSPFv3 Extended LSA Types 207 3. OSPFv3 Extended LSA TLVs 209 The format of the TLVs within the body of the extended LSAs is the 210 same as the format used by the Traffic Engineering Extensions to OSPF 211 [TE]. The variable TLV section consists of one or more nested 212 Type/Length/Value (TLV) tuples. Nested TLVs are also referred to as 213 sub-TLVs. The format of each TLV is: 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type | Length | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Value... | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 TLV Format 225 The Length field defines the length of the value portion in octets 226 (thus a TLV with no value portion would have a length of 0). The TLV 227 is padded to 4-octet alignment; padding is not included in the length 228 field (so a 3-octet value would have a length of 3, but the total 229 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 230 aligned. For example, a 1-byte value would have the length field set 231 to 1, and 3 octets of padding would be added to the end of the value 232 portion of the TLV. 234 This document defines the following top-level TLV types: 236 o 0 - Reserved 238 o 1 - Router-Link TLV 240 o 2 - Attached-Routers TLV 242 o 3 - Inter-Area Prefix TLV 244 o 4 - Inter-Area Router TLV 246 o 5 - External Prefix TLV 248 o 6 - Intra-Area Prefix TLV 250 o 7 - IPv6 Link-Local Address TLV 252 o 8 - IPv4 Link-Local Address TLV 254 Additionally, this document defines the following sub-TLV types: 256 o 0 - Reserved 258 o 1 - IPv6 Forwarding Address sub-TLV 260 o 2 - IPv4 Forwarding Address sub-TLV 262 o 3 - Route Tag sub-TLV 264 In general, TLVs and sub-TLVs MAY occur in any order and the 265 specification should define whether the TLV or sub-TLV is required 266 and the behavior when there are multiple occurances of the TLV or 267 sub-TLVs. 269 For backward compatibility, an LSA is not considered malformed from a 270 TLV perspective unless either a required TLV is missing or a 271 specified TLV is less than the minimum required length. Refer to 272 Section 6.3 for more information on TLV backward compatibility. 274 3.1. Prefix Options Extensions 276 The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The 277 applicability of the LA-bit is expanded and it SHOULD be set in 278 Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when 279 the advertised host IPv6 address, i.e., PrefixLength = 128, is an 280 interface address. In RFC 5340, the LA-bit is only set in Intra- 281 Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3]). This will allow a 282 stable address to be advertised without having to configure a 283 separate loopback address in every OSPFv3 area. 285 3.1.1. N-bit Prefix Option 287 Additionally, the N-bit prefix option is defined. The figure below 288 shows the position of the N-bit in the prefix options (pending IANA 289 allocation). This corresponds to the value 0x20. 291 0 1 2 3 4 5 6 7 292 +--+--+--+--+--+--+--+--+ 293 | | | N|DN| P| x|LA|NU| 294 +--+--+--+--+--+--+--+--+ 296 The Prefix Options field 298 The N-bit is set in PrefixOptions for a host address 299 (PrefixLength=128) that identifies the advertising router. While it 300 is similar to the LA-bit, there are two differences. The advertising 301 router MAY choose NOT to set the N-bit even when the above conditions 302 are met. If the N-bit is set and the PrefixLength is NOT 128, the 303 N-bit MUST be ignored. Additionally, the N-bit is propagated in the 304 PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an 305 Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set 306 in the PrefixOptions. Similarly, the N-bit is propagated in the 307 PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS- 308 External-LSA corresponding to an NSSA route as described in section 3 309 of RFC 3101 ([NSSA]). The N-bit is to the Inter-Area-Prefix-TLV 310 (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- 311 Prefix-TLV (Section 3.7) The N-bit is useful for applications such as 312 identifying the prefixes corresponding to Node Segment Identifiers 313 (SIDs) in Segment Routing [SEGMENT-ROUTING]. 315 3.2. Router-Link TLV 317 The Router-Link TLV defines a single router link and the field 318 definitions correspond directly to links in the OSPFv3 Router-LSA, 319 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 320 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 321 MUST be ignored. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | 1 (Router-Link) | TLV Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type | 0 | Metric | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Interface ID | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Neighbor Interface ID | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Neighbor Router ID | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 . . 337 . sub-TLVs . 338 . . 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Router-Link TLV 343 3.3. Attached-Routers TLV 345 The Attached-Routers TLV defines all the routers attached to an 346 OSPFv3 multi-access network. The field definitions correspond 347 directly to content of the OSPFv3 Network-LSA, section A.4.4, 348 [OSPFV3]. The Attached-Routers TLV is only applicable to the E- 349 Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST be 350 ignored. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | 2 (Attached-Routers) | TLV Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Adjacent Neighbor Router ID | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 . . 360 . Additional Adjacent Neighbors . 361 . . 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Attached-Routers TLV 366 There are two reasons for not having a separate TLV or sub-TLV for 367 each adjacent neighbor. The first is to discourage using the E- 368 Network-LSA for more than its current role of solely advertising the 369 routers attached to a multi-access network. The router's metric as 370 well as the attributes of individual attached routers should be 371 advertised in their respective E-Router-LSAs. The second reason is 372 that there is only a single E-Network-LSA per multi-access link with 373 the Link State ID set to the Designated Router's Interface ID and, 374 consequently, compact encoding has been chosen to decrease the 375 likelihood that the size of the E-Network-LSA will require IPv6 376 fragmentation when advertised in an OSPFv3 Link State Update packet. 378 3.4. Inter-Area-Prefix TLV 380 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 381 The field definitions correspond directly to the content of an OSPFv3 382 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 383 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. 384 Additionally, the PrefixOptions are extended as described in 385 Section 3.1. The Inter-Area-Prefix TLV is only applicable to the E- 386 Inter-Area-Prefix-LSA (Section 4.3). Inclusion in other Extended 387 LSAs MUST be ignored. 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | 3 (Inter-Area Prefix) | TLV Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | 0 | Metric | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | PrefixLength | PrefixOptions | 0 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Address Prefix | 399 | ... | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 . . 402 . sub-TLVs . 403 . . 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Inter-Area Prefix TLV 408 3.5. Inter-Area-Router TLV 410 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 411 Boundary Router (ASBR) reachable in another area. The field 412 definitions correspond directly to the content of an OSPFv3 Inter- 413 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 414 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 415 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | 4 (Inter-Area Router) | TLV Length | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | 0 | Options | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | 0 | Metric | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Destination Router ID | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 . . 429 . sub-TLVs . 430 . . 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Inter-Area Router TLV 435 3.6. External-Prefix TLV 437 The External-Prefix TLV defines a single OSPFv3 external prefix. 438 With the exception of omitted fields noted below, the field 439 definitions correspond directly to the content of an OSPFv3 IPv6 440 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 441 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 442 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 443 and the E-NSSA-LSA (Section 4.6). Additionally, the PrefixOptions 444 are extended as described in Section 3.1. Inclusion in other 445 Extended LSAs MUST be ignored. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | 5 (External Prefix) | TLV Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | |E| | | Metric | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | PrefixLength | PrefixOptions | 0 | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Address Prefix | 457 | ... | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 . . 460 . sub-TLVs . 461 . . 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 External Prefix TLV 466 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 467 and External Route Tag are now sub-TLVs. Given the Referenced LS 468 type and Referenced Link State ID from the AS-External-LSA have never 469 been used or even specified, they have been omitted from the External 470 Prefix TLV. If there were ever a requirement for a referenced LSA, 471 it could be satisfied with a sub-TLV. 473 The following sub-TLVs are defined for optional inclusion in the 474 External Prefix TLV: 476 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.10) 478 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.11) 480 o 3 - Route Tag sub-TLV (Section 3.12) 482 3.7. Intra-Area-Prefix TLV 484 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 485 The field definitions correspond directly to the content of an OSPFv3 486 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 487 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 488 TLV is only applicable to the E-Link-LSA (Section 4.7) and the E- 489 Intra-Area-Prefix-LSA (Section 4.8). Additionally, the PrefixOptions 490 are extended as described in Section 3.1. Inclusion in other 491 Extended LSAs MUST be ignored. 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | 6 (Intra-Area Prefix) | TLV Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | 0 | Metric | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | PrefixLength | PrefixOptions | 0 | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Address Prefix | 503 | ... | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 . . 506 . sub-TLVs . 507 . . 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Intra-Area Prefix TLV 512 3.8. IPv6 Link-Local Address TLV 514 The IPv6 Link-Local Address TLV is to be used with IPv6 address 515 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 516 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 517 other Extended LSAs MUST be ignored. 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | 7 (IPv6 Local-Local Address) | TLV Length | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 +- -+ 526 | | 527 +- IPv6 Link-Local Interface Address -+ 528 | | 529 +- -+ 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 . . 533 . sub-TLVs . 534 . . 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 IPv6 Link-Local Address TLV 539 3.9. IPv4 Link-Local Address TLV 541 The IPv4 Link-Local Address TLV is to be used with IPv4 address 542 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 543 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 544 other Extended LSAs MUST be ignored. 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | 8 (IPv4 Local-Local Address) | TLV Length | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | IPv4 Link-Local Interface Address | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 . . 554 . sub-TLVs . 555 . . 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 IPv4 Link-Local Address TLV 560 3.10. IPv6-Forwarding-Address Sub-TLV 562 The IPv6 Forwarding Address TLV has identical semantics to the 563 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 564 Forwarding Address TLV is applicable to the External-Prefix TLV 565 (Section 3.6). Specification as a sub-TLV of other TLVs is not 566 defined herein. The sub-TLV is optional and the first specified 567 instance is used as the Forwarding Address as defined in [OSPFV3]. 568 Instances subsequent to the first MUST be ignored. 570 The IPv6 Forwarding Address TLV is to be used with IPv6 address 571 families as defined in [OSPFV3-AF] It MUST be ignored for other 572 address families. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | 1 - Forwarding Address | sub-TLV Length | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | | 580 +- -+ 581 | | 582 +- Forwarding Address -+ 583 | | 584 +- -+ 585 | | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Forwarding Address Tag TLV 590 3.11. IPv4-Forwarding-Address Sub-TLV 592 The IPv4 Forwarding Address TLV has identical semantics to the 593 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 594 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 595 applicable to the External-Prefix TLV (Section 3.6). Specification 596 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 597 optional and the first specified instance is used as the Forwarding 598 Address as defined in [OSPFV3]. Instances subsequent to the first 599 MUST be ignored. 601 The IPv4 Forwarding Address TLV is to be used with IPv3 address 602 families as defined in [OSPFV3-AF] It MUST be ignored for other 603 address families. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | 2 - Forwarding Address | sub-TLV Length | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Forwarding Address | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Forwarding Address Tag TLV 615 3.12. Route-Tag Sub-TLV 617 The optional Route Tag sub-TLV has identical semantics to the 618 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 619 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). 620 Specification as a sub-TLV of other TLVs is not defined herein. The 621 sub-TLV is optional and the first specified instance is used as the 622 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 623 MUST be ignored. 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | 3 - Route Tag | sub-TLV Length | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Route Tag | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Route Tag Sub-TLV 635 4. OSPFv3 Extended LSAs 637 This section specifies the OSPFv3 Extended LSA formats and encoding. 638 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 639 LSAs specifed in [OSPFV3]. 641 4.1. OSPFv3 E-Router-LSA 643 The E-Router-LSA has an LS Type of 0xA021 and has the same base 644 information content as the Router-LSA defined in section A.4.3 of 645 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 646 extendable and represented as TLVs. 648 0 1 2 3 649 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 650 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | LS Age |1|0|1| 0x21 | 652 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Link State ID | 654 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Advertising Router | 656 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | LS Sequence Number | 658 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | LS Checksum | Length | 660 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | 0 |Nt|x|V|E|B| Options | 662 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 . . 664 . TLVs . 665 . . 666 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Extended Router-LSA 670 Other than having a differnt LS Type, all LSA Header fields are the 671 same as defined for the Router-LSA. Initially, only the top-level 672 Router-Link TLV Section 3.2 is applicable and an E-Router-LSA may 673 include multiple Router-Link TLVs. Like the existing Router-LSA, the 674 LSA length is used to determine the end of the LSA including TLVs. 676 4.2. OSPFv3 E-Network-LSA 678 The E-Network-LSA has an LS Type of 0xA022 and has the same base 679 information content as the Network-LSA defined in section A.4.4 of 680 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 681 extendable and represented as TLVs. 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | LS Age |1|0|1| 0x22 | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Link State ID | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Advertising Router | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | LS Sequence Number | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | LS Checksum | Length | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | 0 | Options | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 . . 699 . TLVs . 700 . . 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 E-Network-LSA 705 Other than having a differnt LS Type, all LSA Header fields are the 706 same as defined for the Network-LSA. Like the existing Network-LSA, 707 the LSA length is used to determine the end of the LSA including 708 TLVs. Initially, only the top-level Attached-Routers TLV Section 3.3 709 is applicable. If the Attached-Router TLV is not included in the E- 710 Network-LSA, it is treated as malformed as described in Section 5. 711 Instances of the Attached-Router TLV subsequent to the first MUST be 712 ignored. 714 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 716 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 717 base information content as the Inter-Area-Prefix-LSA defined in 718 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 719 Prefix-LSA, it is fully extendable and represented as TLVs. 721 0 1 2 3 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | LS Age |1|0|1| 0x23 | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Link State ID | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Advertising Router | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | LS Sequence Number | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | LS Checksum | Length | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 . . 735 . TLVs . 736 . . 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 E-Inter-Area-Prefix-LSA 741 Other than having a differnt LS Type, all LSA Header fields are the 742 same as defined for the Inter-Area-Prefix-LSA. In order to retain 743 compatibility and semantics with the current OSPFv3 specification, 744 each Inter-Area-Prefix LSA MUST contain a single Inter-Area Prefix 745 TLV. This will facilitate migration and avoid changes to functions 746 such as incremental SPF computation. 748 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 749 determine the end of the LSA including TLV. Initially, only the top- 750 level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the 751 Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, 752 it is treated as malformed as described in Section 5. Instances of 753 the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 755 4.4. OSPFv3 E-Inter-Area-Router-LSA 757 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 758 base information content as the Inter-Area-Router-LSAE defined in 759 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 760 LSA, it is fully extendable and represented as TLVs. 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | LS Age |1|0|1| 0x24 | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Link State ID | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Advertising Router | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | LS Sequence Number | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | LS Checksum | Length | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 . . 776 . TLVs . 777 . . 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 E-Inter-Area-Router-LSA 782 Other than having a differnt LS Type, all LSA Header fields are the 783 same as defined for the Inter-Area-Router-LSA. In order to retain 784 compatibility and semantics with the current OSPFv3 specification, 785 each Inter-Area-Router LSA MUST contain a single Inter-Area Router 786 TLV. This will facilitate migration and avoid changes to functions 787 such as incremental SPF computation. 789 Like the existing Inter-Area-Router-LSA, the LSA length is used to 790 determine the end of the LSA including TLV. Initially, only the top- 791 level Inter-Area-Router TLV (Section 3.5) is applicable. If the 792 Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, 793 it is treated as malformed as described in Section 5. Instances of 794 the Inter-Area-Router TLV subsequent to the first MUST be ignored. 796 4.5. OSPFv3 E-AS-External-LSA 798 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 799 information content as the AS-External-LSA defined in section A.4.7 800 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 801 fully extendable and represented as TLVs. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | LS Age |1|1|0| 0x25 | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Link State ID | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Advertising Router | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | LS Sequence Number | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | LS Checksum | Length | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 . . 817 . TLVs . 818 . . 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 E-AS-External-LSA 823 Other than having a differnt LS Type, all LSA Header fields are the 824 same as defined for the AS-External-LSA. In order to retain 825 compatibility and semantics with the current OSPFv3 specification, 826 each LSA MUST contain a single External Prefix TLV. This will 827 facilitate migration and avoid changes to OSPFv3 processes such as 828 incremental SPF computation. 830 Like the existing AS-External-LSA, the LSA length is used to 831 determine the end of the LSA including sub-TLVs. Initially, only the 832 top-level External-Prefix TLV (Section 3.6) is applicable. If the 833 External-Prefix TLV is not included in the E-External-AS-LSA, it is 834 treated as malformed as described in Section 5. Instances of the 835 External-Prefix TLV subsequent to the first MUST be ignored. 837 4.6. OSPFv3 E-NSSA-LSA 839 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 840 External-LSA Section 4.5. This is the same relationship as exists 841 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 842 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 843 area flooding scope. Future requirements may dictate that supported 844 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 845 However, future requirements are beyond the scope of this document. 847 4.7. OSPFv3 E-Link-LSA 849 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 850 information content as the Link-LSA defined in section A.4.9 of 851 [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 852 and represented as TLVs. 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | LS Age |1|0|0| 0x28 | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Link State ID | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Advertising Router | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | LS Sequence Number | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | LS Checksum | Length | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Rtr Priority | Options | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 . . 870 . TLVs . 871 . . 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 E-Link-LSA 876 Other than having a differnt LS Type, all LSA Header fields are the 877 same as defined for the Link-LSA. 879 Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address 880 TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are 881 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 882 affords advertisement of multiple intra-area prefixes. Hence, 883 multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and 884 the LSA length defines the end of the LSA including all TLVs. 886 A single instance of the IPv6 Link-Local Address TLV (Section 3.8) 887 SHOULD be included in the E-Link-LSA. Instances following the first 888 MUST be ignored. For IPv4 address families as defined in 889 [OSPFV3-AF], this TLV MUST be ignored. 891 Similarly, only a single instance of the IPv4 Link-Local Address TLV 892 (Section 3.9) SHOULD be included in the E-Link-LSA. Instances 893 following the first MUST be ignored. For OSPFv3 IPv6 address 894 families as defined in [OSPFV3-AF], this TLV MUST be ignored. 896 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 897 Address Family is not included in the E-Link-LSA, it is treated as 898 malformed as described in Section 5. 900 Future specifications may support advertisement of routing and 901 topology information for multiple address families. However, this is 902 beyond the scope of this document. 904 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 906 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 907 base information content as the Intra-Area-Prefix-LSA defined in 908 section A.4.10 of [OSPFV3] except for the Referenced LS Type. 909 However, unlike the Intra-Area-Prefix-LSA, it is fully extendable and 910 represented as TLVs. The Referenced LS Type MUST be either an E- 911 Router-LSA (0xA021) or an E-Network-LSA (0xA022). 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | LS Age |1|0|1| 0x29 | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Link State ID | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Advertising Router | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | LS Sequence Number | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | LS Checksum | Length | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | 0 | Referenced LS Type | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Referenced Link State ID | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Referenced Advertising Router | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 . . 933 . TLVs . 934 . . 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 E-Intra-Area-Prefix-LSA 939 Other than having a differnt LS Type, all LSA Header fields are the 940 same as defined for the Intra-Area-Prefix-LSA. 942 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 943 advertisement of multiple intra-area prefixes. Hence, multiple 944 Intra-Area Prefix TLVs may be specified and the LSA length defines 945 the end of the LSA including all TLVs. 947 5. Malformed OSPFv3 Extended LSA Handling 949 Extended LSAs that have inconsistent length or other encoding errors, 950 as described herein, MUST NOT be installed in the Link State 951 Database, acknowledged, or flooded. Reception of malformed LSAs 952 SHOULD be counted and/or logged for examination by the administrator 953 of the OSPFv3 Routing Domain. Note that for the purposes of length 954 validation, a TLV or Sub-TLV should not be considered invalid unless 955 the length exceeds the length of the LSA or does not meet the minimum 956 length requirements. This allows for Sub-TLVs to be added as 957 described in Section 6.3. 959 Additionally, an LSA MUST be considered malformed if it does not 960 include any required TLV or Sub-TLVs. 962 6. LSA Extension Backward Compatibility 964 In the context of this document, backward compatibility is solely 965 related to the capability of an OSPFv3 router to receive, process, 966 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 967 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 968 extensions utilizing the TLV-based LSAs is out of scope and must be 969 covered in the documents describing those extensions. Both full and, 970 if applicable, partial deployment SHOULD be specified for future TLV- 971 based OSPFv3 LSA extensions. 973 6.1. Full Extended LSA Migration 975 If ExtendedLSASupport is enabled Appendix A, OSPFv3 Extended LSAs 976 will be originated and used for the SPF computation. Individual OSPF 977 Areas can be migrated separately with the Legacy AS-External LSAs 978 being originated and used for the SPF computation. This is 979 accomplished by enabled AreaExtendedLSASupport Appendix B. 981 An OSPFv3 routing domain or area may be non-disruptively migrated 982 using separate OSPFv3 instances for the extended LSAs. Initially, 983 the OSPFv3 instances with ExtendedLSASupport will have a lower 984 preference, i.e., higher administrative distance, than the OSPFv3 985 instances originating and using the Legacy LSAs. Once the routing 986 domain or area is fully migrated and the OSPFv3 Routing Information 987 Bases (RIB) have been verified, the OSPFv3 instances using the 988 extended LSAs can be given preference. When this has been completed 989 and the routing within the OSPF routing domain or area has been 990 verified, the original OSPFv3 instance using Legacy LSAs can be 991 removed. 993 6.2. Extended LSA Spare-Mode Backward Compatibility 995 In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation 996 and will only originate extended LSAs when LSA origination is 997 required in support of addtional functionality. Furthermore, the 998 extended LSAs will only include those TLVs which require further 999 specification for that new functionality. Hence, this mode of 1000 compatibility is know as "sparse-mode". The advantage of sparse-mode 1001 is that functionality utilizing the OSPFv3 extended LSAs can be added 1002 to an existing OSFPv3 routing domain without the requirement for 1003 migration. In essence, this compatibility mode is very much like the 1004 approach taken for OSPFv2 [OSPF-PREFIX-LINK]. As with all the 1005 compatibility modes, backward compatibility for the functions 1006 utilizing the extended LSAs must be described in the IETF documents 1007 describing those functions. 1009 6.3. LSA TLV Processing Backward Compatibility 1011 This section defines the general rules for processing LSA TLVs. To 1012 ensure compatibility of future TLV-based LSA extensions, all 1013 implementations MUST adhere to these rules: 1015 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 1016 processing Extended-LSAs. 1018 2. Whether or not partial deployment of a given TLV is supported 1019 MUST be specified. 1021 3. If partial deployment is not supported, mechanisms to ensure the 1022 corresponding feature are not deployed MUST be specified in the 1023 document defining the new TLV or sub-TLV. 1025 4. If partial deployment is supported, backward compatibility and 1026 partial deployment MUST be specified in the document defining the 1027 new TLV or sub-TLV. 1029 5. If a TLV or Sub-TLV is recognized but the length is less than the 1030 minimum, then the LSA should be considered malformed and it 1031 SHOULD NOT be acknowledged. Additionally, the occurence SHOULD 1032 be logged with enough information to identify the LSA by type, 1033 originator, and sequence number and the TLV or Sub-TLV in error. 1034 Ideally, the log entry would include the hexidecimal or binary 1035 representation of the LSA including the malformed TLS or Sub-TLV. 1037 6. Documents specifying future TLVs or Sub-TLVs MUST specify the 1038 requirements for usage of those TLVs or Sub-TLVs. 1040 7. Future TLV or Sub-TLVs must be optional. However, there may be 1041 requirements for Sub-TLVs if an optional TLV is specified. 1043 7. Security Considerations 1045 In general, extendible OSPFv3 LSAs are subject to the same security 1046 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1047 implementations must assure that malformed TLV and sub-TLV 1048 permutations do not result in errors that cause hard OSPFv3 failures. 1050 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1051 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1052 mechanisms described herein would greatly simplify the extension. 1054 8. IANA Considerations 1056 This specification defines nine OSPFv3 Extended LSA types as 1057 described in Section 2. 1059 This specification also creates two registries OSPFv3 Extended-LSAs 1060 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1061 registries are common to all Extended-LSAs and their respective 1062 definitions must define where they are applicable. 1064 The OSPFv3 Extended-LSA TLV registry will define top-level TLVs for 1065 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1066 registry. New values can be allocated via IETF Consensus or IESG 1067 Approval. 1069 Nine values are allocated by this specification: 1071 o 0 - Reserved 1073 o 1 - Router-Link TLV 1075 o 2 - Attached-Routers TLV 1077 o 3 - Inter-Area Prefix TLV 1079 o 4 - Inter-Area Router TLV 1081 o 5 - External Prefix TLV 1083 o 6 - Intra-Area Prefix TLV 1085 o 7 - IPv6 Link-Local Address TLV 1087 o 8 - IPv4 Link-Local Address TLV 1088 The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any 1089 level of nesting for Extended-LSAs and should be placed in the 1090 existing OSPFv3 IANA registry. New values can be allocated via IETF 1091 Review. 1093 Three values are allocated by this specification: 1095 o 0 - Reserved 1097 o 1 - Forwarding Address 1099 o 2 - Route Tag 1101 The OSPFv3 Prefix Options registry will define a new code point for 1102 the N-bit. The value 0x20 is suggested. 1104 9. Contributors 1106 Contributors' Addresses 1108 Sina Mirtorabi 1109 Cisco Systems 1110 170 Tasman Drive 1111 San Jose, CA 95134 1112 USA 1113 Email: sina@cisco.com 1115 10. References 1117 10.1. Normative References 1119 [GRACEFUL-RESTART] 1120 Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful 1121 Restart", RFC 5187, June 2008. 1123 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1124 RFC 3101, January 2003. 1126 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1127 for IPv6", RFC 5340, July 2008. 1129 [OSPFV3-AF] 1130 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1131 Aggarwal, "Support of Address Families in OSPFv3", RFC 1132 5838, April 2010. 1134 [RFC-KEYWORDS] 1135 Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", RFC 2119, March 1997. 1138 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1139 Extensions to OSPF", RFC 3630, September 2003. 1141 10.2. Informative References 1143 [MT-OSPFV3] 1144 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1145 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt 1146 (work in progress), January 2008. 1148 [OSPF-DIGITAL-SIGNATURE] 1149 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1150 Digital Signatures", RFC 2154, June 1997. 1152 [OSPF-PREFIX-LINK] 1153 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1154 Tantsura, J., and A. Lindem, "OSPF Prefix/Link 1155 Attributes", RFC 7684, December 2015. 1157 [SEGMENT-ROUTING] 1158 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1159 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1160 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1161 segment-routing-extensions-10.txt (work in progress), July 1162 2016. 1164 Appendix A. Appendix A - Global Configuration Parameters 1166 The global configurable parameter ExtendedLSASupport will be added to 1167 the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1168 Router will originate OSPFv3 Extended LSAs and use the LSAs for the 1169 SPF computation. If ExtendedLSASupport is not enabled, a subset of 1170 OSPFv3 Extended LSAs may still be originated and used for other 1171 functions as described in Section 6.2. 1173 Appendix B. Appendix B - Area Configuration Parameters 1175 The area configurable parameter AreaExtendedLSASupport will be added 1176 to the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1177 Router will originate link and area OSPFv3 Extended LSAs and use the 1178 LSAs for the SPF computation. Legacy AS-Scoped LSAs will still be 1179 originated and used for the AS External LSA computation. If 1180 AreaExtendedLSASupport is not enabled a subset of OSPFv3 link and 1181 area Extended LSAs may still be originated and used for other 1182 functions as described in Section 6.2. 1184 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1185 disabling AreaExtendedLSASupport when ExtendedLSASupport is enabled 1186 is contradictory and MAY be prohibited by the implementation. 1188 Appendix C. Appendix C - Deprecated LSA Extension Backward 1189 Compatibility 1191 In the context of this document, backward compatibility is solely 1192 related to the capability of an OSPFv3 router to receive, process, 1193 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 1194 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 1195 extensions utilizing the TLV-based LSAs is out of scope and must be 1196 covered in the documents describing those extensions. Both full and, 1197 if applicable, partial deployment SHOULD be specified for future TLV- 1198 based OSPFv3 LSA extensions. 1200 Three distinct backward compatibility modes are supported dependent 1201 on the OSPFv3 routing domain migration requirements. For simplicity 1202 and to avoid the scaling impact of maintaining both TLV and non-TLV 1203 based versions of the same LSA within a routing domain, the basic 1204 backward compatibility mode will not allow mixing of LSA formats. 1205 Different LSA formats could still be supported with multiple OSPFv3 1206 instances and separate OSPFv3 routing domains. Additionally, a more 1207 flexible mode is provided in Appendix C.1, where both formats of LSA 1208 coexist. In order to facilitate backward compatibility, the OSPFv3 1209 options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), 1210 will contain two additional options bits. The EL-bits will be used 1211 to indicate that the OSPFv3 router's level of Extended LSA support. 1212 An OSPFv3 router configured to support extended LSAs MUST set its 1213 options field EL-bits in OSPFv3 Hello and Database Description 1214 packets as follows: 1216 B'00' 1217 None - Extended LSAs are not originated nor used in the SPF 1218 calculation (except for future functionalities as described in 1219 Section 6.2) . 1221 B'01' 1222 MixedModeOriginateOnly - Both Extended and Legacy LSAs are 1223 originated. Legacy LSAs are used in the SPF computation. 1225 B'10' 1226 MixedModeOriginateSPF - Both extended and Legacy LSAs are 1227 originated. Extended LSAs are used in the SPF computation. 1229 B'11' 1230 Full - Only extended LSAs are originated and used in the SPF 1231 computation. 1233 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 1234 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 1235 Database Description packets with the options field EL-bits set to 1236 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 1237 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 1238 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 1239 Description packets with the options field EL-bits set to None 1240 (B'00'). In this manner, OSPFv3 routers using new encodings can be 1241 completely isolated from those OSPFv3 routers depending on the RFC 1242 5340 encoding and not setting their options field EL-bits since the 1243 default setting indicates no support for extended LSAs. 1245 Finally, a mode supporting existing OSPFv3 routing domains is 1246 provided. This mode, subsequently referred to as "sparse-mode", will 1247 use the TLV-based LSAs solely in support of new functionality 1248 Section 6.2. In this compatibility mode, the EL-bits will be 1249 advertised as B'00' since the backward compatibility with the Legacy 1250 LSAs is not supported or required. 1252 1 2 1253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1255 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1257 The Options field 1259 EL-bits 1260 These bits indicate the level of Extended LSA support. 1261 B'00' - Extended LSAs are not originate nor used in the 1262 SPF calculation (except for new functionalities 1263 for future functions as described in Section 6.2). 1264 B'01' - Both extended and Legacy LSAs are originated. 1265 Non-extended LSAs are used in the SPF computation. 1266 B'10' - Both extended and Legacy LSAs are originated. 1267 Extended LSAs are used in the SPF computation. 1268 B'11' - Only extended LSA are originated and used in the 1269 SPF computation. 1271 Options Field EL-bits 1273 The EL-bits will also be set in the LSA options field in Extended and 1274 Legacy LSAs. While the value of the EL-bits has no functional 1275 significance in the LSA options field, visibility of every OSPFv3 1276 Router's extended LSA support is expected to be very useful for 1277 management and troubleshooting during the migration period. 1279 C.1. Extended LSA Mixed-Mode Backward Compatibility 1281 An implementation MAY support configuration allowing a graceful 1282 transition from the Legacy (non-TLV-based) LSAs to the extended (TLV- 1283 based) LSAs in an OSPFv3 routing domain. In these routing domains, 1284 the OSPFv3 routers configured with a value of MixedModeOriginateOnly 1285 or MixedModeOriginateSPF for ExtendedLSASupport, (Appendix C.2), MUST 1286 originate both the extended and legacy versions of the OSPFv3 LSAs 1287 described herein. For the purposes of Shortest Path First (SPF) 1288 computation, the Legacy LSAs are used for SPF computation when 1289 MixedModeOriginateOnly is configured and the extended LSAs are used 1290 when MixedModeOriginateSPF is specified. The Extended LSAs MAY be 1291 used for functions other than routing computation as long as backward 1292 compatibility is specified in the documents specifying those 1293 functions. 1295 In this manner, OSPFv3 routing domains utilizing the new encodings 1296 can be gradually migrated with a worst-case overhead cost of 1297 approximately doubling the number of LSAs in the routing domain. The 1298 transition within an OSPFv3 routing domain would progress as follows: 1300 1. Configure OSPFv3 Router ExtendedLSASupport to 1301 MixedModeOriginateOnly so that routers originate the extended 1302 LSAs. 1304 2. When all the OSPFv3 Routers have been reconfigured to 1305 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 1306 use the extended LSAs by configuring ExtendedLSASupport to 1307 MixedModeOriginateSPF. This can be done on a small subset of 1308 OSPFv3 Routers and the route tables can be verified. 1310 3. When all the OSPFv3 Routers have been reconfigured to 1311 MixedModeOriginateSPF and the routing has been verified, 1312 reconfigure OSPFv3 Routers to purge or simply not refresh the 1313 Legacy LSA by configuring ExtendedLSASupport to Full. 1315 In order to prevent OSPFv3 routing domain routing loops, the 1316 advertised metrics in the Extended LSAs and Legacy LSAs MUST be 1317 identical. 1319 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 1321 An implementation MAY also support configuration allowing graceful 1322 transition from the Legacy LSAs to the extended LSAs within a single 1323 area. In these areas, the parameter AreaExtendedLSASupport 1324 (Appendix C.3) may be configured to take precedence over the global 1325 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 1326 will only apply to link and area scoped LSAs within the area and area 1327 based SPF calculations. The default is for the 1328 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 1329 The configuration of ExtendedLSASupport will apply to AS-External 1330 LSAs even when AreaExtendedLSASupport takes precedence. 1332 When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 1333 router configured with MixedModeOriginate will use the Legacy LSAs to 1334 determine whether or not the graceful restart has completed 1335 successfully. Similarly, an OSPFv3 router configured with 1336 MixedModeOriginateSPF will use the extended LSAs. In other words, 1337 successful OSPFv3 graceful restart determination will follow the SPF 1338 calculation. 1340 C.2. Global Configuration Parameters 1342 An additional global configurable parameter will be added to the 1343 OSPFv3 protocol. 1345 ExtendedLSASupport 1346 This is an enumeration type indicating the extent to which the 1347 OSPFv3 instance supports the TLV format described herein for 1348 Extended LSAs. The valid values for the enumeration are: 1350 * None - Extended LSAs will not be originated or used in the SPF 1351 calculation. This is the default. When OSPFv3 functions 1352 requiring extended LSA are configured, and the 1353 ExtendedLSASuppport is "None", extended LSAs may be used as 1354 described in Section 6.2. 1356 * MixedModeOriginateOnly - Both extended and Legacy LSAs will be 1357 originated. OSPFv3 adjacencies will be formed with OSPFv3 1358 routers not supporting this specification. The Legacy LSAs are 1359 used for the SPF computation. 1361 * MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will 1362 be originated. OSPFv3 adjacencies will be formed with OSPFv3 1363 routers not supporting this specification. The Extended LSAs 1364 are used for the SPF computation. 1366 * Full - Extended LSAs will be originated and adjacencies will 1367 ndot be formed with OSPFv3 routers not supporting this 1368 specification. Only Extended LSAs will be originated. 1370 C.3. Area Configuration Parameters 1372 An additional area configurable parameter will be added to the OSPFv3 1373 protocol. 1375 AreaExtendedLSASupport 1376 This is an enumeration type indicating the extent to which the 1377 OSPFv3 area supports the TLV format described herein for Extended 1378 LSAs. The valid value for the enumeration are: 1380 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1381 from ExtendedLSASupport. This is the default. 1383 * None - Extended LSAs will not be originated or used in the SPF 1384 calculation. This is the default. When OSPFv3 functions 1385 requiring extended LSA are configured, and the 1386 ExtendedLSASuppport is "None", the spare-mode compatability is 1387 in effect Section 6.2. 1389 * MixedModeOriginateOnly - Both extended and legacy link and area 1390 scoped LSAs will be originated. OSPFv3 adjacencies will be 1391 formed with OSPFv3 routers not supporting this specification. 1392 The Legacy LSAs are used for the area SPF computation. 1394 * MixedModeOriginateSPF - Both extended and legacy link and area 1395 scoped LSAs will be originated. OSPFv3 adjacencies will be 1396 formed with OSPFv3 routers not supporting this specification. 1397 The Extended LSAs are used for the area SPF computation. 1399 * Full - Link and area scoped Extended LSAs will be originated 1400 and adjacencies will not be formed with OSPFv3 routers not 1401 supporting this specification. Only Extended LSAs will be 1402 originated. 1404 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1405 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1406 when Full is specified for ExtendedLSASupport is contradictory and 1407 MAY be prohibited by the implementation. 1409 Authors' Addresses 1410 Acee Lindem 1411 Cisco Systems 1412 301 Midenhall Way 1413 Cary, NC 27513 1414 USA 1416 Email: acee@cisco.com 1418 Abhay Roy 1419 Cisco Systems 1420 170 Tasman Drive 1421 San Jose, CA 95134 1422 USA 1424 Email: akr@cisco.com 1426 Dirk Goethals 1427 Nokia 1428 Copernicuslaan 50 1429 Antwerp 2018 1430 Belgium 1432 Email: dirk.goethals@nokia.com 1434 Veerendranatha Reddy Vallem 1435 Bangalore 1436 India 1438 Email: vallem.veerendra@gmail.com 1440 Fred Baker 1441 Santa Barbara, California 93117 1442 USA 1444 Email: FredBaker.IETF@gmail.com