idnits 2.17.00 (12 Aug 2021) /tmp/idnits44424/draft-ietf-ospf-prefix-link-attr-01.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 (September 8, 2014) is 2812 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: draft-ietf-ospf-ospfv3-lsa-extend has been published as RFC 8362 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: March 12, 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 September 8, 2014 16 OSPFv2 Prefix/Link Attribute Advertisement 17 draft-ietf-ospf-prefix-link-attr-01.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 March 12, 2015. 47 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 77 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 78 2. OSPFv2 Extended Prefix Opaque LSA . . . . . . . . . . . . . . 5 79 2.1. OSPFv2 Extended Prefix TLV . . . . . . . . . . . . . . . . 6 80 3. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . . . 8 81 3.1. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . . 9 82 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 6.1. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 11 86 6.2. OSPF Extended Prefix TLV Sub-TLV Registry . . . . . . . . 11 87 6.3. OSPF Extended Link LSA TLV Registry . . . . . . . . . . . 11 88 6.4. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 12 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 91 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 94 1. Introduction 96 OSPFv2 requires functional extension beyond what can readily be done 97 with the fixed-format Link State Advertisements (LSAs) as described 98 in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based 99 on Type-Length-Value (TLV) tuples that can be used to associate 100 additional attributes with prefixes or links. Dependent on the 101 application, these prefixes and links may or not be advertised in the 102 fixed-format LSAs. The OSPF opaque LSAs are optional and fully 103 backward compatible. This is in contrast to the approach taken in 104 OSPFv3 [OSPFV3-LSA-EXTEND] where the existing LSAs will be replaced 105 by TLV-based extended LSAs. 107 New requirements such as source/destination routing, route tagging, 108 and segment routing necessitate this extension. 110 This specification defines the following OSPFv2 opaque LSAs: 112 1. OSPFv2 Extended Prefix LSA - Allows advertisement of additional 113 attributes for prefixes advertised in Router-LSAs, Network-LSAs, 114 Network-Summary-LSAs, NSSA-LSAs, and AS-External-LSAs [OSPFV2] 116 2. OSPFv2 Extended links LSA - Allows advertisement of additional 117 attributes for links advertised in Router-LSAs. 119 Additionally, the following TLVs are defined: 121 1. OSPFv2 Extended Prefix TLV - Top-level TLV advertising attributes 122 for a prefix in the OSPFv2 Extended Prefix LSA. 124 2. OSPFv2 Extended Link TLV - Top-level TLV advertising attributes 125 for a link in the OSPFv2 Extended link LSA. 127 1.1. Requirements notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC-KEYWORDS]. 133 1.2. Acknowledgments 135 We would like to thank Anton Smirnov for his contribution. 137 Thanks to Tony Przygienda for his review and comments. 139 2. OSPFv2 Extended Prefix Opaque LSA 141 The OSPFv2 Extended Prefix Opaque LSA will be used to advertise 142 additional prefix attributes. Opaque LSAs are described in [OPAQUE]. 144 Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an 145 OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix 146 Opaque LSA depends on the scope of the advertised prefixes and is 147 under the control of the advertising router. In some cases (e.g., 148 mapping server deployment), the LSA flooding scope may be greater 149 than the scope of the corresponding prefixes. 151 The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | LS age | Options | 9, 10, or 11 | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Opaque type | Instance | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Advertising Router | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | LS sequence number | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | LS checksum | length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 +- TLVs -+ 168 | ... | 170 OSPFv2 Extended Prefix LSA 172 The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. 174 The format of the TLVs within the body of the OSPFv2 Extended Prefix 175 LSA is the same as the format used by the Traffic Engineering 176 Extensions to OSPF [TE]. The variable TLV section consists of one or 177 more nested Type/Length/Value (TLV) tuples. Nested TLVs are also 178 referred to as sub-TLVs. The format of each TLV is: 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Value... | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 TLV Format 190 The Length field defines the length of the value portion in octets 191 (thus a TLV with no value portion would have a length of 0). The TLV 192 is padded to 4-octet alignment; padding is not included in the length 193 field (so a 3-octet value would have a length of 3, but the total 194 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 195 aligned. For example, a 1-byte value would have the length field set 196 to 1, and 3 octets of padding would be added to the end of the value 197 portion of the TLV. 199 2.1. OSPFv2 Extended Prefix TLV 201 The OSPF Extended Prefix TLV is used in order to advertise additional 202 attributes associated with the prefix. Multiple OSPF Extended Prefix 203 TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA. 204 However, since the opaque LSA type defines the flooding scope, the 205 LSA flooding scope MUST satisfy the application specific requirements 206 for all the prefixes included in a single OSPFv2 Extended Prefix 207 Opaque LSA. The OSPF Extended Prefix TLV has the following format: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type | Length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Route Type | Prefix Length | AF | Reserved | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Address Prefix (variable) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Sub-TLVs (variable) | 219 +- -+ 220 | | 222 OSPFv2 Extended Prefix TLV 224 Type 225 The TLV type. Suggested value is 1. 227 Length 228 Variable dependent on sub-TLVs. 230 Route Type 231 Route type: type of the OSPF route. If the route type is 0 232 (Unspecified), the information inside the OSPF External Prefix TLV 233 applies to the prefix regardless of prefix's route-type. This is 234 useful when prefix specific attributes are advertised by an 235 external entity, which is not aware of the route-type associated 236 with the prefix. Supported types are: 238 0 - Unspecified 240 1 - Intra-Area 242 3 - Inter-Area 244 5 - AS External 246 7 - NSSA External 248 Prefix Length 249 Length in of the prefix in bits. 251 AF 252 Address family for the prefix. Currently, the only supported 253 value is 0 for IPv4 unicast. 255 Address Prefix 256 The prefix itself encoded as an even multiple of 32-bit words, 257 padded with zeroed bits as necessary. This encoding consumes 258 ((PrefixLength + 31) / 32) 32-bit words. The default route is 259 represented by a prefix of length 0. 261 If this TLV is advertised multiple times for the same prefix in the 262 same OSPFv2 Extended Prefix Opaque LSA, only the first instance is 263 used by receiving OSPFv2 Routers. This situation SHOULD be logged as 264 an error. 266 If this TLV is advertised multiple times for the same prefix in 267 different OSPFv2 Extended Prefix Opaque LSAs originated by the same 268 OSPF router, the OSPF advertising router is re-originating Extended 269 Prefix Opaque LSAs for multiple prefixes and is most likely repacking 270 Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case, 271 the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the 272 smallest Instance is used by receiving OSPFv2 Routers. This 273 situation MAY be logged as a warning. 275 It is RECOMMENDED that OSPF routers advertising Extended-Prefix-TLVs 276 in different Extended Prefix Opaque LSAs re-originate these LSAs in 277 ascending order of Instance to minimize the disruption. 279 If this TLV is advertised multiple times for the same prefix in 280 different OSPFv2 Extended Prefix Opaque LSAs originated by the 281 different OSPF routers, the application using the information is 282 required to determine which OSPFv2 Extended Prefix Opaque LSA is 283 used. For example, the application could prefer the LSA providing 284 the best path to the prefix. 286 This document creates a registry for OSPF Extended Prefix sub-TLVs in 287 Section 6. 289 3. OSPFv2 Extended Link Opaque LSA 291 The OSPFv2 Extended Link Opaque LSA will be used to advertise 292 additional link attributes. Opaque LSAs are described in [OPAQUE]. 294 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 295 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 296 single router in an area. 298 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | LS age | Options | 10 | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Opaque type | Instance | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Advertising Router | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | LS sequence number | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | LS checksum | length | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 +- TLVs -+ 315 | ... | 316 OSPFv2 Extended Link LSA 318 The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. 320 The format of the TLVs within the body of the OSPFv2 Extended Prefix 321 LSA is the same as Section 2. 323 3.1. OSPFv2 Extended Link TLV 325 OSPFv2 Extended Link TLV is used in order to advertise various 326 attributes of the link. It describes a single link and is 327 constructed of a set of Sub-TLVs. There are no ordering requirements 328 for the Sub-TLVs. Only one Extended Link TLV SHALL be advertised in 329 each Extended Link Opaque LSA, allowing for fine granularity changes 330 in the topology. 332 The Extended Link TLV has following format: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Link-Type | Reserved | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Link ID | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Link Data | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Sub-TLVs (variable) | 346 +- -+ 347 | | 349 OSPFv2 Extended Link TLV 351 Type 352 The TLV type. Suggested value is 1. 354 Length 355 Variable dependent on sub-TLVs. 357 Link-Type 358 Link-Type is defined in section A.4.2 of [OSPFV2]. 360 Link-ID 361 Link-ID is defined in section A.4.2 of [OSPFV2]. 363 Link Data 364 Link-Data is defined in section A.4.2 of [OSPFV2]. 366 This document creates a registry for OSPF Extended Link sub-TLVs in 367 Section 6. 369 4. Backward Compatibility 371 Since opaque OSPFv2 LSAs are optional and backward compatible 372 [OPAQUE], the extensions described herein is fully backward 373 compatible. However, future OSPFv2 extensions utilizing these 374 extensions must address backward compatibility of the corresponding 375 functionality. 377 5. Security Considerations 379 In general, new LSAs defined in this document are subject to the same 380 security concerns as those described in [OSPFV2]. Additionally, 381 implementations must assure that malformed TLV and Sub-TLV 382 permutations do not result in errors that cause hard OSPF failures. 384 6. IANA Considerations 386 This specification updates the Opaque Link-State Advertisements (LSA) 387 Option Types with the following values: 389 o 7 (IANA Early Allocation [EARLY-ALLOCATION]) - OSPFv2 Extended 390 Prefix Opaque LSA 392 o 8 (IANA Early Allocation [EARLY-ALLOCATION]) - OSPFv2 Extended 393 Link Opaque LSA 395 This specification also creates four new registries: 397 o OSPF Extended Prefix LSA TLVs 399 o OSPF Extended Prefix TLV Sub-TLVs 401 o OSPF Extended Link LSA TLVs 403 o OSPF Extended Link TLV Sub-TLVs 405 6.1. OSPF Extended Prefix LSA TLV Registry 407 The OSPF Extend Prefix LSA TLV registry will define top-level TLVs 408 for Extended Prefix LSAs and should be placed in the existing OSPF 409 IANA registry. New values can be allocated via IETF Consensus or 410 IESG Approval. 412 The following initial values are allocated: 414 o 0 - Reserved 416 o 1 - OSPF Extended Prefix TLV 418 Types in the range 32768-33023 are for experimental use; these will 419 not be registered with IANA, and MUST NOT be mentioned by RFCs. 421 Types in the range 33024-65535 are not to be assigned at this time. 422 Before any assignments can be made in the 33024-65535 range, there 423 MUST be an IETF specification that specifies IANA Considerations that 424 covers the range being assigned. 426 6.2. OSPF Extended Prefix TLV Sub-TLV Registry 428 The OSPF Extended Link LSA sub-TLV registry will define will define 429 sub-TLVs at any level of nesting for Extended Link LSAs and should be 430 placed in the existing OSPF IANA registry. New values can be 431 allocated via IETF Consensus or IESG Approval. 433 The following initial values are allocated: 435 o 0 - Reserved 437 Types in the range 32768-33023 are for experimental use; these will 438 not be registered with IANA, and MUST NOT be mentioned by RFCs. 440 Types in the range 33024-65535 are not to be assigned at this time. 441 Before any assignments can be made in the 33024-65535 range, there 442 MUST be an IETF specification that specifies IANA Considerations that 443 covers the range being assigned. 445 6.3. OSPF Extended Link LSA TLV Registry 447 The OSPF Extend Link LSA TLV registry will define top-level TLVs for 448 Extended Link LSAs and should be placed in the existing OSPF IANA 449 registry. New values can be allocated via IETF Consensus or IESG 450 Approval. 452 Following initial values are allocated: 454 o 0 - Reserved 456 o 1 - OSPFv2 Extended Link TLV 458 Types in the range 32768-33023 are for experimental use; these will 459 not be registered with IANA, and MUST NOT be mentioned by RFCs. 461 Types in the range 33024-65535 are not to be assigned at this time. 462 Before any assignments can be made in the 33024-65535 range, there 463 MUST be am IETF specification that specifies IANA Considerations that 464 covers the range being assigned. 466 6.4. OSPF Extended Link TLV Sub-TLV Registry 468 The OSPF Extended Link sub-TLV registry will define will define sub- 469 TLVs at any level of nesting for Extended Link LSAs and should be 470 placed in the existing OSPF IANA registry. New values can be 471 allocated via IETF Consensus or IESG Approval. 473 The following initial values are allocated: 475 o 0 - Reserved 477 Types in the range 32768-33023 are for experimental use; these will 478 not be registered with IANA, and MUST NOT be mentioned by RFCs. 479 Types in the range 33024-65535 are not to be assigned at this time. 480 Before any assignments can be made in the 33024-65535 range, there 481 MUST be an IETF specification that specifies IANA Considerations that 482 covers the range being assigned. 484 7. References 486 7.1. Normative References 488 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 489 OSPF Opaque LSA Option", RFC 5250, July 2008. 491 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 493 [RFC-KEYWORDS] 494 Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", RFC 2119, March 1997. 497 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 498 Extensions to OSPF", RFC 3630, September 2003. 500 7.2. Informative References 502 [EARLY-ALLOCATION] 503 Cotton, M., "Early Allocation of Standards Track Code 504 Points", RFC 7120, January 2014. 506 [OSPFV3-LSA-EXTEND] 507 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 508 LSA Extendibility", 509 draft-ietf-ospf-ospfv3-lsa-extend-02.txt (work in 510 progress). 512 Authors' Addresses 514 Peter Psenak 515 Cisco Systems 516 Apollo Business Center 517 Mlynske nivy 43 518 Bratislava, 821 09 519 Slovakia 521 Email: ppsenak@cisco.com 523 Hannes Gredler 524 Juniper Networks, Inc. 525 1194 N. Mathilda Ave. 526 Sunnyvale, CA 94089 527 USA 529 Email: hannes@juniper.net 531 Rob Shakir 532 British Telcom 533 London 534 UK 536 Email: rob.shakir@bt.com 537 Wim Henderickx 538 Alcatel-Lucent 539 Copernicuslaan 540 Antwerp, 2018 94089 541 Belgium 543 Email: wim.henderickx@alcatel-lucent.com 545 Jeff Tantsura 546 Ericsson 547 300 Holger Way 548 San Jose, CA 95134 549 USA 551 Email: jeff.tantsura@ericsson.com 553 Acee Lindem 554 Cisco Systems 555 301 Midenhall Way 556 Cary, NC 27513 557 USA 559 Email: acee@cisco.com