idnits 2.17.1 draft-ietf-ospf-prefix-link-attr-03.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 (February 1, 2015) is 3372 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-05 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: August 5, 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 February 1, 2015 16 OSPFv2 Prefix/Link Attribute Advertisement 17 draft-ietf-ospf-prefix-link-attr-03.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 August 5, 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 . . . . . . . . . . . . . . . . . . . 9 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 6.1. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 10 87 6.2. OSPF Extended Prefix TLV Sub-TLV Registry . . . . . . . . 11 88 6.3. OSPF Extended Link LSA TLV Registry . . . . . . . . . . . 11 89 6.4. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 11 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 92 7.2. Informative References . . . . . . . . . . . . . . . . . 12 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 LSA - Allows advertisement of additional 114 attributes for prefixes advertised in Router-LSAs, Network-LSAs, 115 Network-Summary-LSAs, NSSA-LSAs, and AS-External-LSAs [OSPFV2] 117 2. OSPFv2 Extended links LSA - Allows advertisement of additional 118 attributes for links advertised in Router-LSAs. 120 Additionally, the following TLVs are defined: 122 1. OSPFv2 Extended Prefix TLV - Top-level TLV advertising attributes 123 for a prefix in the OSPFv2 Extended Prefix LSA. 125 2. OSPFv2 Extended Link TLV - Top-level TLV advertising attributes 126 for a link in the OSPFv2 Extended link LSA. 128 1.1. Requirements notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC-KEYWORDS]. 134 1.2. Acknowledgments 136 We would like to thank Anton Smirnov for his contribution. 138 Thanks to Tony Przygienda for his review and comments. 140 2. OSPFv2 Extended Prefix Opaque LSA 142 The OSPFv2 Extended Prefix Opaque LSA will be used to advertise 143 additional prefix attributes. Opaque LSAs are described in [OPAQUE]. 145 Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an 146 OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix 147 Opaque LSA depends on the scope of the advertised prefixes and is 148 under the control of the advertising router. In some cases (e.g., 149 mapping server deployment), the LSA flooding scope may be greater 150 than the scope of the corresponding prefixes. 152 The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | LS age | Options | 9, 10, or 11 | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Opaque type | Instance | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Advertising Router | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | LS sequence number | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | LS checksum | length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 +- TLVs -+ 169 | ... | 171 OSPFv2 Extended Prefix LSA 173 The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. 175 The format of the TLVs within the body of the OSPFv2 Extended Prefix 176 LSA is the same as the format used by the Traffic Engineering 177 Extensions to OSPF [TE]. The variable TLV section consists of one or 178 more nested Type/Length/Value (TLV) tuples. Nested TLVs are also 179 referred to as sub-TLVs. The format of each TLV is: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Value... | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 TLV Format 191 The Length field defines the length of the value portion in octets 192 (thus a TLV with no value portion would have a length of 0). The TLV 193 is padded to 4-octet alignment; padding is not included in the length 194 field (so a 3-octet value would have a length of 3, but the total 195 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 196 aligned. For example, a 1-byte value would have the length field set 197 to 1, and 3 octets of padding would be added to the end of the value 198 portion of the TLV. 200 2.1. OSPFv2 Extended Prefix TLV 202 The OSPF Extended Prefix TLV is used in order to advertise additional 203 attributes associated with the prefix. Multiple OSPF Extended Prefix 204 TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA. 205 However, since the opaque LSA type defines the flooding scope, the 206 LSA flooding scope MUST satisfy the application specific requirements 207 for all the prefixes included in a single OSPFv2 Extended Prefix 208 Opaque LSA. The OSPF Extended Prefix TLV has the following format: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type | Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Route Type | Prefix Length | AF | Flags | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Address Prefix (variable) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Sub-TLVs (variable) | 220 +- -+ 221 | | 223 OSPFv2 Extended Prefix TLV 225 Type 226 The TLV type. Suggested value is 1. 228 Length 229 Variable dependent on sub-TLVs. 231 Route Type 232 Route type: type of the OSPF route. If the route type is 0 233 (Unspecified), the information inside the OSPF External Prefix TLV 234 applies to the prefix regardless of prefix's route-type. This is 235 useful when prefix specific attributes are advertised by an 236 external entity, which is not aware of the route-type associated 237 with the prefix. Supported types are: 239 0 - Unspecified 241 1 - Intra-Area 243 3 - Inter-Area 245 5 - AS External 247 7 - NSSA External 249 Prefix Length 250 Length in of the prefix in bits. 252 AF 253 Address family for the prefix. Currently, the only supported 254 value is 0 for IPv4 unicast. 256 Flags: 1 octet field. The following flags are defined: 258 0 1 2 3 4 5 6 7 259 +--+--+--+--+--+--+--+--+ 260 |A |N | | | | | | | 261 +--+--+--+--+--+--+--+--+ 263 where: 265 A-Flag: Attach flag. An ABR generating Extended Prefix TLV for 266 inter-area prefix that is locally connected or attached in 267 other connected area SHOULD set this flag. 269 N-Flag: Set when the prefix identifies the advertising router 270 i.e., the prefix is a host prefix advertising a globally 271 reachable address typically associated with a loopback address. 273 The advertising router MAY choose to NOT set this flag even 274 when the above conditions are met. If the flag is set and the 275 prefix length is NOT a host prefix then the flag MUST be 276 ignored. The flag is preserved when OSPFv2 Extended Prefix 277 Opaque LSA is propagated between areas. 279 Address Prefix 280 The prefix itself encoded as an even multiple of 32-bit words, 281 padded with zeroed bits as necessary. This encoding consumes 282 ((PrefixLength + 31) / 32) 32-bit words. The default route is 283 represented by a prefix of length 0. 285 If this TLV is advertised multiple times for the same prefix in the 286 same OSPFv2 Extended Prefix Opaque LSA, only the first instance is 287 used by receiving OSPFv2 Routers. This situation SHOULD be logged as 288 an error. 290 If this TLV is advertised multiple times for the same prefix in 291 different OSPFv2 Extended Prefix Opaque LSAs originated by the same 292 OSPF router, the OSPF advertising router is re-originating Extended 293 Prefix Opaque LSAs for multiple prefixes and is most likely repacking 294 Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case, 295 the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the 296 smallest Instance is used by receiving OSPFv2 Routers. This 297 situation MAY be logged as a warning. 299 It is RECOMMENDED that OSPF routers advertising Extended-Prefix-TLVs 300 in different Extended Prefix Opaque LSAs re-originate these LSAs in 301 ascending order of Instance to minimize the disruption. 303 If this TLV is advertised multiple times for the same prefix in 304 different OSPFv2 Extended Prefix Opaque LSAs originated by the 305 different OSPF routers, the application using the information is 306 required to determine which OSPFv2 Extended Prefix Opaque LSA is 307 used. For example, the application could prefer the LSA providing 308 the best path to the prefix. 310 This document creates a registry for OSPF Extended Prefix sub-TLVs in 311 Section 6. 313 3. OSPFv2 Extended Link Opaque LSA 315 The OSPFv2 Extended Link Opaque LSA will be used to advertise 316 additional link attributes. Opaque LSAs are described in [OPAQUE]. 318 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 319 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 320 single router in an area. 322 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 324 0 1 2 3 325 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | LS age | Options | 10 | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Opaque type | Instance | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Advertising Router | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | LS sequence number | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | LS checksum | length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 +- TLVs -+ 339 | ... | 341 OSPFv2 Extended Link LSA 343 The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. 345 The format of the TLVs within the body of the OSPFv2 Extended Prefix 346 LSA is the same as Section 2. 348 3.1. OSPFv2 Extended Link TLV 350 OSPFv2 Extended Link TLV is used in order to advertise various 351 attributes of the link. It describes a single link and is 352 constructed of a set of Sub-TLVs. There are no ordering requirements 353 for the Sub-TLVs. Only one Extended Link TLV SHALL be advertised in 354 each Extended Link Opaque LSA, allowing for fine granularity changes 355 in the topology. 357 The Extended Link TLV has following format: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type | Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Link-Type | Reserved | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Link ID | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Link Data | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Sub-TLVs (variable) | 371 +- -+ 372 | | 374 OSPFv2 Extended Link TLV 376 Type 377 The TLV type. Suggested value is 1. 379 Length 380 Variable dependent on sub-TLVs. 382 Link-Type 383 Link-Type is defined in section A.4.2 of [OSPFV2]. 385 Link-ID 386 Link-ID is defined in section A.4.2 of [OSPFV2]. 388 Link Data 389 Link-Data is defined in section A.4.2 of [OSPFV2]. 391 This document creates a registry for OSPF Extended Link sub-TLVs in 392 Section 6. 394 4. Backward Compatibility 396 Since opaque OSPFv2 LSAs are optional and backward compatible 397 [OPAQUE], the extensions described herein is fully backward 398 compatible. However, future OSPFv2 extensions utilizing these 399 extensions must address backward compatibility of the corresponding 400 functionality. 402 5. Security Considerations 404 In general, new LSAs defined in this document are subject to the same 405 security concerns as those described in [OSPFV2]. Additionally, 406 implementations must assure that malformed TLV and Sub-TLV 407 permutations do not result in errors that cause hard OSPF failures. 409 6. IANA Considerations 411 This specification updates the Opaque Link-State Advertisements (LSA) 412 Option Types with the following values: 414 o 7 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Prefix 415 Opaque LSA 417 o 8 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Link Opaque 418 LSA 420 This specification also creates four new registries: 422 o OSPF Extended Prefix LSA TLVs 424 o OSPF Extended Prefix TLV Sub-TLVs 426 o OSPF Extended Link LSA TLVs 428 o OSPF Extended Link TLV Sub-TLVs 430 6.1. OSPF Extended Prefix LSA TLV Registry 432 The OSPF Extend Prefix LSA TLV registry will define top-level TLVs 433 for Extended Prefix LSAs and should be placed in the existing OSPF 434 IANA registry. New values can be allocated via IETF Consensus or 435 IESG Approval. 437 The following initial values are allocated: 439 o 0 - Reserved 441 o 1 - OSPF Extended Prefix TLV 443 Types in the range 32768-33023 are for experimental use; these will 444 not be registered with IANA, and MUST NOT be mentioned by RFCs. 446 Types in the range 33024-65535 are not to be assigned at this time. 447 Before any assignments can be made in the 33024-65535 range, there 448 MUST be an IETF specification that specifies IANA Considerations that 449 covers the range being assigned. 451 6.2. OSPF Extended Prefix TLV Sub-TLV Registry 453 The OSPF Extended Link LSA sub-TLV registry will define sub-TLVs at 454 any level of nesting for Extended Link LSAs and should be placed in 455 the existing OSPF IANA registry. New values can be allocated via 456 IETF Consensus or IESG Approval. 458 The following initial values are allocated: 460 o 0 - Reserved 462 Types in the range 32768-33023 are for experimental use; these will 463 not be registered with IANA, and MUST NOT be mentioned by RFCs. 465 Types in the range 33024-65535 are not to be assigned at this time. 466 Before any assignments can be made in the 33024-65535 range, there 467 MUST be an IETF specification that specifies IANA Considerations that 468 covers the range being assigned. 470 6.3. OSPF Extended Link LSA TLV Registry 472 The OSPF Extend Link LSA TLV registry will define top-level TLVs for 473 Extended Link LSAs and should be placed in the existing OSPF IANA 474 registry. New values can be allocated via IETF Consensus or IESG 475 Approval. 477 Following initial values are allocated: 479 o 0 - Reserved 481 o 1 - OSPFv2 Extended Link TLV 483 Types in the range 32768-33023 are for experimental use; these will 484 not be registered with IANA, and MUST NOT be mentioned by RFCs. 486 Types in the range 33024-65535 are not to be assigned at this time. 487 Before any assignments can be made in the 33024-65535 range, there 488 MUST be am IETF specification that specifies IANA Considerations that 489 covers the range being assigned. 491 6.4. OSPF Extended Link TLV Sub-TLV Registry 493 The OSPF Extended Link sub-TLV registry will define will define sub- 494 TLVs at any level of nesting for Extended Link LSAs and should be 495 placed in the existing OSPF IANA registry. New values can be 496 allocated via IETF Consensus or IESG Approval. 498 The following initial values are allocated: 500 o 0 - Reserved 502 Types in the range 32768-33023 are for experimental use; these will 503 not be registered with IANA, and MUST NOT be mentioned by RFCs. 504 Types in the range 33024-65535 are not to be assigned at this time. 505 Before any assignments can be made in the 33024-65535 range, there 506 MUST be an IETF specification that specifies IANA Considerations that 507 covers the range being assigned. 509 7. References 511 7.1. Normative References 513 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 514 OSPF Opaque LSA Option", RFC 5250, July 2008. 516 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 518 [RFC-KEYWORDS] 519 Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", RFC 2119, March 1997. 522 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 523 Extensions to OSPF", RFC 3630, September 2003. 525 7.2. Informative References 527 [I-D.ietf-ospf-ospfv3-lsa-extend] 528 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 529 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-05 530 (work in progress), November 2014. 532 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 533 Points", BCP 100, RFC 7120, January 2014. 535 Authors' Addresses 537 Peter Psenak 538 Cisco Systems 539 Apollo Business Center 540 Mlynske nivy 43 541 Bratislava, 821 09 542 Slovakia 544 Email: ppsenak@cisco.com 545 Hannes Gredler 546 Juniper Networks, Inc. 547 1194 N. Mathilda Ave. 548 Sunnyvale, CA 94089 549 USA 551 Email: hannes@juniper.net 553 Rob Shakir 554 British Telcom 555 London 556 UK 558 Email: rob.shakir@bt.com 560 Wim Henderickx 561 Alcatel-Lucent 562 Copernicuslaan 563 Antwerp, 2018 94089 564 Belgium 566 Email: wim.henderickx@alcatel-lucent.com 568 Jeff Tantsura 569 Ericsson 570 300 Holger Way 571 San Jose, CA 95134 572 USA 574 Email: jeff.tantsura@ericsson.com 576 Acee Lindem 577 Cisco Systems 578 301 Midenhall Way 579 Cary, NC 27513 580 USA 582 Email: acee@cisco.com