idnits 2.17.1 draft-ietf-ospf-prefix-link-attr-04.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 14, 2015) is 3299 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Psenak 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track H. Gredler 5 Expires: October 16, 2015 Juniper Networks, Inc. 6 R. Shakir 7 British Telcom 8 W. Henderickx 9 Alcatel-Lucent 10 J. Tantsura 11 Ericsson 12 A. Lindem 13 Cisco Systems 14 April 14, 2015 16 OSPFv2 Prefix/Link Attribute Advertisement 17 draft-ietf-ospf-prefix-link-attr-04.txt 19 Abstract 21 OSPFv2 requires functional extension beyond what can readily be done 22 with the fixed-format Link State Advertisements (LSAs) as described 23 in RFC 2328. This document defines OSPF opaque LSAs based on Type- 24 Length-Value (TLV) tuples that can be used to associate additional 25 attributes with prefixes or links. Dependent on the application, 26 these prefixes and links may or not be advertised in the fixed-format 27 LSAs. The OSPF opaque LSAs are optional and fully backward 28 compatible. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 16, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 78 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3 79 2. OSPFv2 Extended Prefix Opaque LSA . . . . . . . . . . . . . . 4 80 2.1. OSPFv2 Extended Prefix TLV . . . . . . . . . . . . . . . 5 81 3. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . . . 7 82 3.1. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . 8 83 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 6.1. OSPF Extended Prefix Opaque LSA TLV Registry . . . . . . 10 87 6.2. OSPF Extended Prefix TLV Sub-TLV Registry . . . . . . . . 11 88 6.3. OSPF Extended Link Opaque LSA TLV Registry . . . . . . . 11 89 6.4. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 12 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 92 7.2. Informative References . . . . . . . . . . . . . . . . . 12 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 OSPFv2 requires functional extension beyond what can readily be done 98 with the fixed-format Link State Advertisements (LSAs) as described 99 in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based 100 on Type-Length-Value (TLV) tuples that can be used to associate 101 additional attributes with prefixes or links. Dependent on the 102 application, these prefixes and links may or not be advertised in the 103 fixed-format LSAs. The OSPF opaque LSAs are optional and fully 104 backward compatible. This is in contrast to the approach taken in 105 OSPFv3 [I-D.ietf-ospf-ospfv3-lsa-extend] where the existing LSAs will 106 be replaced by TLV-based extended LSAs. 108 New requirements such as source/destination routing, route tagging, 109 and segment routing necessitate this extension. 111 This specification defines the following OSPFv2 opaque LSAs: 113 1. OSPFv2 Extended Prefix Opaque LSA - Allows advertisement of 114 additional attributes for prefixes advertised in Router-LSAs, 115 Network-LSAs, Network-Summary-LSAs, NSSA-LSAs, and AS-External- 116 LSAs [OSPFV2] 118 2. OSPFv2 Extended Link Opaque LSA - Allows advertisement of 119 additional attributes for links advertised in Router-LSAs. 121 Additionally, the following TLVs are defined: 123 1. OSPFv2 Extended Prefix TLV - Top-level TLV advertising attributes 124 for a prefix in the OSPFv2 Extended Prefix Opaque LSA. 126 2. OSPFv2 Extended Link TLV - Top-level TLV advertising attributes 127 for a link in the OSPFv2 Extended Link Opaque LSA. 129 1.1. Requirements notation 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC-KEYWORDS]. 135 1.2. Acknowledgments 137 We would like to thank Anton Smirnov for his contribution. 139 Thanks to Tony Przygienda for his review and comments. 141 2. OSPFv2 Extended Prefix Opaque LSA 143 The OSPFv2 Extended Prefix Opaque LSA will be used to advertise 144 additional prefix attributes. Opaque LSAs are described in [OPAQUE]. 146 Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an 147 OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix 148 Opaque LSA depends on the scope of the advertised prefixes and is 149 under the control of the advertising router. In some cases (e.g., 150 mapping server deployment), the LSA flooding scope may be greater 151 than the scope of the corresponding prefixes. 153 The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | LS age | Options | 9, 10, or 11 | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Opaque type | Instance | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Advertising Router | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | LS sequence number | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | LS checksum | length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | | 169 +- TLVs -+ 170 | ... | 172 OSPFv2 Extended Prefix Opaque LSA 174 The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. 176 The Instance field is an arbitrary value used to maintain multiple 177 Extended Prefix Opaque LSAs. A maximum of 16777216 Extended Prefix 178 Opaque LSAs may be sourced by a single OSPF instance. 180 The format of the TLVs within the body of the OSPFv2 Extended Prefix 181 Opaque LSA is the same as the format used by the Traffic Engineering 182 Extensions to OSPF [TE]. The variable TLV section consists of one or 183 more nested Type/Length/Value (TLV) tuples. Nested TLVs are also 184 referred to as sub-TLVs. The format of each TLV is: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Value... | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 TLV Format 196 The Length field defines the length of the value portion in octets 197 (thus a TLV with no value portion would have a length of 0). The TLV 198 is padded to 4-octet alignment; padding is not included in the length 199 field (so a 3-octet value would have a length of 3, but the total 200 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 201 aligned. For example, a 1-byte value would have the length field set 202 to 1, and 3 octets of padding would be added to the end of the value 203 portion of the TLV. 205 2.1. OSPFv2 Extended Prefix TLV 207 The OSPF Extended Prefix TLV is used to advertise additional 208 attributes associated with the prefix. Multiple OSPF Extended Prefix 209 TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA. 210 However, since the opaque LSA type defines the flooding scope, the 211 LSA flooding scope MUST satisfy the application specific requirements 212 for all the prefixes included in a single OSPFv2 Extended Prefix 213 Opaque LSA. The OSPF Extended Prefix TLV has the following format: 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 | Route Type | Prefix Length | AF | Flags | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Address Prefix (variable) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Sub-TLVs (variable) | 225 +- -+ 226 | | 228 OSPFv2 Extended Prefix TLV 230 Type 231 The TLV type. Suggested value is 1. 233 Length 234 Variable dependent on sub-TLVs. 236 Route Type 237 Route type: type of the OSPF route. If the route type is 0 238 (Unspecified), the information inside the OSPF External Prefix TLV 239 applies to the prefix regardless of prefix's route-type. This is 240 useful when prefix specific attributes are advertised by an 241 external entity, which is not aware of the route-type associated 242 with the prefix. Supported types are: 244 0 - Unspecified 246 1 - Intra-Area 248 3 - Inter-Area 250 5 - AS External 252 7 - NSSA External 254 Prefix Length 255 Length in of the prefix in bits. 257 AF 258 Address family for the prefix. Currently, the only supported 259 value is 0 for IPv4 unicast. 261 Flags: 1 octet field. The following flags are defined: 263 0 1 2 3 4 5 6 7 264 +--+--+--+--+--+--+--+--+ 265 |A |N | | | | | | | 266 +--+--+--+--+--+--+--+--+ 268 where: 270 A-Flag: Attach flag. An ABR generating Extended Prefix TLV for 271 inter-area prefix that is locally connected or attached in 272 other connected area SHOULD set this flag. 274 N-Flag: Set when the prefix identifies the advertising router 275 i.e., the prefix is a host prefix advertising a globally 276 reachable address typically associated with a loopback address. 278 The advertising router MAY choose to NOT set this flag even 279 when the above conditions are met. If the flag is set and the 280 prefix length is NOT a host prefix then the flag MUST be 281 ignored. The flag is preserved when OSPFv2 Extended Prefix 282 Opaque LSA is propagated between areas. 284 Address Prefix 285 The prefix itself encoded as an even multiple of 32-bit words, 286 padded with zeroed bits as necessary. This encoding consumes 287 ((PrefixLength + 31) / 32) 32-bit words. The default route is 288 represented by a prefix of length 0. 290 If this TLV is advertised multiple times for the same prefix in the 291 same OSPFv2 Extended Prefix Opaque LSA, only the first instance is 292 used by receiving OSPFv2 Routers. This situation SHOULD be logged as 293 an error. 295 If this TLV is advertised multiple times for the same prefix in 296 different OSPFv2 Extended Prefix Opaque LSAs originated by the same 297 OSPF router, the OSPF advertising router is re-originating Extended 298 Prefix Opaque LSAs for multiple prefixes and is most likely repacking 299 Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case, 300 the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the 301 smallest Instance is used by receiving OSPFv2 Routers. This 302 situation MAY be logged as a warning. 304 It is RECOMMENDED that OSPF routers advertising Extended Prefix TLVs 305 in different Extended Prefix Opaque LSAs re-originate these LSAs in 306 ascending order of Instance to minimize the disruption. 308 If this TLV is advertised multiple times for the same prefix in 309 different OSPFv2 Extended Prefix Opaque LSAs originated by the 310 different OSPF routers, the application using the information is 311 required to determine which OSPFv2 Extended Prefix Opaque LSA is 312 used. For example, the application could prefer the LSA providing 313 the best path to the prefix. 315 This document creates a registry for OSPF Extended Prefix sub-TLVs in 316 Section 6. 318 3. OSPFv2 Extended Link Opaque LSA 320 The OSPFv2 Extended Link Opaque LSA will be used to advertise 321 additional link attributes. Opaque LSAs are described in [OPAQUE]. 323 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 324 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 325 single router in an area. 327 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | LS age | Options | 10 | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Opaque type | Instance | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Advertising Router | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | LS sequence number | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | LS checksum | length | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 +- TLVs -+ 344 | ... | 346 OSPFv2 Extended Link Opaque LSA 348 The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. 350 The Instance field is an arbitrary value used to maintain multiple 351 Extended Link Opaque LSAs. A maximum of 16777216 Extended Link 352 Opaque LSAs may be sourced by a single OSPF instance. 354 The format of the TLVs within the body of the OSPFv2 Extended Link 355 Opaque LSA is the same as described in Section 2. 357 3.1. OSPFv2 Extended Link TLV 359 The OSPFv2 Extended Link TLV is used to advertise various attributes 360 of the link. It describes a single link and is constructed of a set 361 of Sub-TLVs. There are no ordering requirements for the Sub-TLVs. 362 Only one Extended Link TLV SHALL be advertised in each Extended Link 363 Opaque LSA, allowing for fine granularity changes in the topology. 365 The Extended Link TLV has following format: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type | Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Link-Type | Reserved | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Link ID | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Link Data | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Sub-TLVs (variable) | 379 +- -+ 380 | | 382 OSPFv2 Extended Link TLV 384 Type 385 The TLV type. Suggested value is 1. 387 Length 388 Variable dependent on sub-TLVs. 390 Link-Type 391 Link-Type is defined in section A.4.2 of [OSPFV2]. 393 Link-ID 394 Link-ID is defined in section A.4.2 of [OSPFV2]. 396 Link Data 397 Link-Data is defined in section A.4.2 of [OSPFV2]. 399 If this TLV is advertised multiple times in the same OSPFv2 Extended 400 Link Opaque LSA, only the first instance is used by receiving OSPFv2 401 Routers. This situation SHOULD be logged as an error. 403 If this TLV is advertised multiple times for the same link in 404 different OSPFv2 Extended Link Opaque LSAs originated by the same 405 OSPF router, the Extended Link TLV in the Extended Link Opaque LSA 406 with the smallest Instance is used by receiving OSPFv2 Routers. This 407 situation MAY be logged as a warning. 409 It is RECOMMENDED that OSPF routers advertising Extended Link TLVs in 410 different Extended Link Opaque LSAs re-originate these LSAs in 411 ascending order of Instance to minimize the disruption. 413 This document creates a registry for OSPF Extended Link sub-TLVs in 414 Section 6. 416 4. Backward Compatibility 418 Since opaque OSPFv2 LSAs are optional and backward compatible 419 [OPAQUE], the extensions described herein is fully backward 420 compatible. However, future OSPFv2 extensions utilizing these 421 extensions must address backward compatibility of the corresponding 422 functionality. 424 5. Security Considerations 426 In general, new LSAs defined in this document are subject to the same 427 security concerns as those described in [OSPFV2]. Additionally, 428 implementations must assure that malformed TLV and Sub-TLV 429 permutations do not result in errors that cause hard OSPF failures. 431 6. IANA Considerations 433 This specification updates the Opaque Link-State Advertisements (LSA) 434 Option Types with the following values: 436 o 7 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Prefix 437 Opaque LSA 439 o 8 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Link Opaque 440 LSA 442 This specification also creates four new registries: 444 o OSPF Extended Prefix Opaque LSA TLVs 446 o OSPF Extended Prefix TLV Sub-TLVs 448 o OSPF Extended Link Opaque LSA TLVs 450 o OSPF Extended Link TLV Sub-TLVs 452 6.1. OSPF Extended Prefix Opaque LSA TLV Registry 454 The OSPF Extend Prefix Opaque LSA TLV registry will define top-level 455 TLVs for Extended Prefix Opaque LSA and should be placed in the 456 existing OSPF IANA registry. New values can be allocated via IETF 457 Consensus or IESG Approval. 459 The following initial values are allocated: 461 o 0 - Reserved 463 o 1 - OSPF Extended Prefix TLV 465 Types in the range 32768-33023 are for experimental use; these will 466 not be registered with IANA, and MUST NOT be mentioned by RFCs. 468 Types in the range 33024-65535 are not to be assigned at this time. 469 Before any assignments can be made in the 33024-65535 range, there 470 MUST be an IETF specification that specifies IANA Considerations that 471 covers the range being assigned. 473 6.2. OSPF Extended Prefix TLV Sub-TLV Registry 475 The OSPF Extended Prefix TLV sub-TLV registry will define sub-TLVs at 476 any level of nesting for Extended Prefix TLV and should be placed in 477 the existing OSPF IANA registry. New values can be allocated via 478 IETF Consensus or IESG Approval. 480 The following initial values are allocated: 482 o 0 - Reserved 484 Types in the range 32768-33023 are for experimental use; these will 485 not be registered with IANA, and MUST NOT be mentioned by RFCs. 487 Types in the range 33024-65535 are not to be assigned at this time. 488 Before any assignments can be made in the 33024-65535 range, there 489 MUST be an IETF specification that specifies IANA Considerations that 490 covers the range being assigned. 492 6.3. OSPF Extended Link Opaque LSA TLV Registry 494 The OSPF Extended Link Opaque LSA TLV registry will define top-level 495 TLVs for Extended Link Opaque LSAs and should be placed in the 496 existing OSPF IANA registry. New values can be allocated via IETF 497 Consensus or IESG Approval. 499 Following initial values are allocated: 501 o 0 - Reserved 503 o 1 - OSPFv2 Extended Link TLV 505 Types in the range 32768-33023 are for experimental use; these will 506 not be registered with IANA, and MUST NOT be mentioned by RFCs. 508 Types in the range 33024-65535 are not to be assigned at this time. 509 Before any assignments can be made in the 33024-65535 range, there 510 MUST be am IETF specification that specifies IANA Considerations that 511 covers the range being assigned. 513 6.4. OSPF Extended Link TLV Sub-TLV Registry 515 The OSPF Extended Link TLV sub-TLV registry will define sub-TLVs at 516 any level of nesting for Extended Link TLV and should be placed in 517 the existing OSPF IANA registry. New values can be allocated via 518 IETF Consensus or IESG Approval. 520 The following initial values are allocated: 522 o 0 - Reserved 524 Types in the range 32768-33023 are for experimental use; these will 525 not be registered with IANA, and MUST NOT be mentioned by RFCs. 526 Types in the range 33024-65535 are not to be assigned at this time. 527 Before any assignments can be made in the 33024-65535 range, there 528 MUST be an IETF specification that specifies IANA Considerations that 529 covers the range being assigned. 531 7. References 533 7.1. Normative References 535 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 536 OSPF Opaque LSA Option", RFC 5250, July 2008. 538 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 540 [RFC-KEYWORDS] 541 Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", RFC 2119, March 1997. 544 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 545 Extensions to OSPF", RFC 3630, September 2003. 547 7.2. Informative References 549 [I-D.ietf-ospf-ospfv3-lsa-extend] 550 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 551 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-06 552 (work in progress), February 2015. 554 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 555 Points", BCP 100, RFC 7120, January 2014. 557 Authors' Addresses 559 Peter Psenak 560 Cisco Systems 561 Apollo Business Center 562 Mlynske nivy 43 563 Bratislava, 821 09 564 Slovakia 566 Email: ppsenak@cisco.com 568 Hannes Gredler 569 Juniper Networks, Inc. 570 1194 N. Mathilda Ave. 571 Sunnyvale, CA 94089 572 USA 574 Email: hannes@juniper.net 576 Rob Shakir 577 British Telcom 578 London 579 UK 581 Email: rob.shakir@bt.com 583 Wim Henderickx 584 Alcatel-Lucent 585 Copernicuslaan 586 Antwerp, 2018 94089 587 Belgium 589 Email: wim.henderickx@alcatel-lucent.com 591 Jeff Tantsura 592 Ericsson 593 300 Holger Way 594 San Jose, CA 95134 595 USA 597 Email: jeff.tantsura@ericsson.com 598 Acee Lindem 599 Cisco Systems 600 301 Midenhall Way 601 Cary, NC 27513 602 USA 604 Email: acee@cisco.com