idnits 2.17.1 draft-ietf-ospf-prefix-link-attr-02.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 (December 15, 2014) is 3420 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: June 18, 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 December 15, 2014 16 OSPFv2 Prefix/Link Attribute Advertisement 17 draft-ietf-ospf-prefix-link-attr-02.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 June 18, 2015. 47 Copyright Notice 49 Copyright (c) 2014 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 | | | | | | | | 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 Address Prefix 270 The prefix itself encoded as an even multiple of 32-bit words, 271 padded with zeroed bits as necessary. This encoding consumes 272 ((PrefixLength + 31) / 32) 32-bit words. The default route is 273 represented by a prefix of length 0. 275 If this TLV is advertised multiple times for the same prefix in the 276 same OSPFv2 Extended Prefix Opaque LSA, only the first instance is 277 used by receiving OSPFv2 Routers. This situation SHOULD be logged as 278 an error. 280 If this TLV is advertised multiple times for the same prefix in 281 different OSPFv2 Extended Prefix Opaque LSAs originated by the same 282 OSPF router, the OSPF advertising router is re-originating Extended 283 Prefix Opaque LSAs for multiple prefixes and is most likely repacking 284 Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case, 285 the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the 286 smallest Instance is used by receiving OSPFv2 Routers. This 287 situation MAY be logged as a warning. 289 It is RECOMMENDED that OSPF routers advertising Extended-Prefix-TLVs 290 in different Extended Prefix Opaque LSAs re-originate these LSAs in 291 ascending order of Instance to minimize the disruption. 293 If this TLV is advertised multiple times for the same prefix in 294 different OSPFv2 Extended Prefix Opaque LSAs originated by the 295 different OSPF routers, the application using the information is 296 required to determine which OSPFv2 Extended Prefix Opaque LSA is 297 used. For example, the application could prefer the LSA providing 298 the best path to the prefix. 300 This document creates a registry for OSPF Extended Prefix sub-TLVs in 301 Section 6. 303 3. OSPFv2 Extended Link Opaque LSA 305 The OSPFv2 Extended Link Opaque LSA will be used to advertise 306 additional link attributes. Opaque LSAs are described in [OPAQUE]. 308 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 309 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 310 single router in an area. 312 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | LS age | Options | 10 | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Opaque type | Instance | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Advertising Router | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | LS sequence number | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | LS checksum | length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 +- TLVs -+ 329 | ... | 331 OSPFv2 Extended Link LSA 333 The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. 335 The format of the TLVs within the body of the OSPFv2 Extended Prefix 336 LSA is the same as Section 2. 338 3.1. OSPFv2 Extended Link TLV 340 OSPFv2 Extended Link TLV is used in order to advertise various 341 attributes of the link. It describes a single link and is 342 constructed of a set of Sub-TLVs. There are no ordering requirements 343 for the Sub-TLVs. Only one Extended Link TLV SHALL be advertised in 344 each Extended Link Opaque LSA, allowing for fine granularity changes 345 in the topology. 347 The Extended Link TLV has following format: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Link-Type | Reserved | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Link ID | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Link Data | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Sub-TLVs (variable) | 361 +- -+ 362 | | 364 OSPFv2 Extended Link TLV 366 Type 367 The TLV type. Suggested value is 1. 369 Length 370 Variable dependent on sub-TLVs. 372 Link-Type 373 Link-Type is defined in section A.4.2 of [OSPFV2]. 375 Link-ID 376 Link-ID is defined in section A.4.2 of [OSPFV2]. 378 Link Data 379 Link-Data is defined in section A.4.2 of [OSPFV2]. 381 This document creates a registry for OSPF Extended Link sub-TLVs in 382 Section 6. 384 4. Backward Compatibility 386 Since opaque OSPFv2 LSAs are optional and backward compatible 387 [OPAQUE], the extensions described herein is fully backward 388 compatible. However, future OSPFv2 extensions utilizing these 389 extensions must address backward compatibility of the corresponding 390 functionality. 392 5. Security Considerations 394 In general, new LSAs defined in this document are subject to the same 395 security concerns as those described in [OSPFV2]. Additionally, 396 implementations must assure that malformed TLV and Sub-TLV 397 permutations do not result in errors that cause hard OSPF failures. 399 6. IANA Considerations 401 This specification updates the Opaque Link-State Advertisements (LSA) 402 Option Types with the following values: 404 o 7 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Prefix 405 Opaque LSA 407 o 8 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Link Opaque 408 LSA 410 This specification also creates four new registries: 412 o OSPF Extended Prefix LSA TLVs 414 o OSPF Extended Prefix TLV Sub-TLVs 416 o OSPF Extended Link LSA TLVs 418 o OSPF Extended Link TLV Sub-TLVs 420 6.1. OSPF Extended Prefix LSA TLV Registry 422 The OSPF Extend Prefix LSA TLV registry will define top-level TLVs 423 for Extended Prefix LSAs and should be placed in the existing OSPF 424 IANA registry. New values can be allocated via IETF Consensus or 425 IESG Approval. 427 The following initial values are allocated: 429 o 0 - Reserved 431 o 1 - OSPF Extended Prefix TLV 433 Types in the range 32768-33023 are for experimental use; these will 434 not be registered with IANA, and MUST NOT be mentioned by RFCs. 436 Types in the range 33024-65535 are not to be assigned at this time. 437 Before any assignments can be made in the 33024-65535 range, there 438 MUST be an IETF specification that specifies IANA Considerations that 439 covers the range being assigned. 441 6.2. OSPF Extended Prefix TLV Sub-TLV Registry 443 The OSPF Extended Link LSA sub-TLV registry will define sub-TLVs at 444 any level of nesting for Extended Link LSAs and should be placed in 445 the existing OSPF IANA registry. New values can be allocated via 446 IETF Consensus or IESG Approval. 448 The following initial values are allocated: 450 o 0 - Reserved 452 Types in the range 32768-33023 are for experimental use; these will 453 not be registered with IANA, and MUST NOT be mentioned by RFCs. 455 Types in the range 33024-65535 are not to be assigned at this time. 456 Before any assignments can be made in the 33024-65535 range, there 457 MUST be an IETF specification that specifies IANA Considerations that 458 covers the range being assigned. 460 6.3. OSPF Extended Link LSA TLV Registry 462 The OSPF Extend Link LSA TLV registry will define top-level TLVs for 463 Extended Link LSAs and should be placed in the existing OSPF IANA 464 registry. New values can be allocated via IETF Consensus or IESG 465 Approval. 467 Following initial values are allocated: 469 o 0 - Reserved 471 o 1 - OSPFv2 Extended Link TLV 473 Types in the range 32768-33023 are for experimental use; these will 474 not be registered with IANA, and MUST NOT be mentioned by RFCs. 476 Types in the range 33024-65535 are not to be assigned at this time. 477 Before any assignments can be made in the 33024-65535 range, there 478 MUST be am IETF specification that specifies IANA Considerations that 479 covers the range being assigned. 481 6.4. OSPF Extended Link TLV Sub-TLV Registry 483 The OSPF Extended Link sub-TLV registry will define will define sub- 484 TLVs at any level of nesting for Extended Link LSAs and should be 485 placed in the existing OSPF IANA registry. New values can be 486 allocated via IETF Consensus or IESG Approval. 488 The following initial values are allocated: 490 o 0 - Reserved 492 Types in the range 32768-33023 are for experimental use; these will 493 not be registered with IANA, and MUST NOT be mentioned by RFCs. 494 Types in the range 33024-65535 are not to be assigned at this time. 495 Before any assignments can be made in the 33024-65535 range, there 496 MUST be an IETF specification that specifies IANA Considerations that 497 covers the range being assigned. 499 7. References 501 7.1. Normative References 503 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 504 OSPF Opaque LSA Option", RFC 5250, July 2008. 506 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 508 [RFC-KEYWORDS] 509 Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", RFC 2119, March 1997. 512 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 513 Extensions to OSPF", RFC 3630, September 2003. 515 7.2. Informative References 517 [I-D.ietf-ospf-ospfv3-lsa-extend] 518 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 519 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-05 520 (work in progress), November 2014. 522 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 523 Points", BCP 100, RFC 7120, January 2014. 525 Authors' Addresses 527 Peter Psenak 528 Cisco Systems 529 Apollo Business Center 530 Mlynske nivy 43 531 Bratislava, 821 09 532 Slovakia 534 Email: ppsenak@cisco.com 535 Hannes Gredler 536 Juniper Networks, Inc. 537 1194 N. Mathilda Ave. 538 Sunnyvale, CA 94089 539 USA 541 Email: hannes@juniper.net 543 Rob Shakir 544 British Telcom 545 London 546 UK 548 Email: rob.shakir@bt.com 550 Wim Henderickx 551 Alcatel-Lucent 552 Copernicuslaan 553 Antwerp, 2018 94089 554 Belgium 556 Email: wim.henderickx@alcatel-lucent.com 558 Jeff Tantsura 559 Ericsson 560 300 Holger Way 561 San Jose, CA 95134 562 USA 564 Email: jeff.tantsura@ericsson.com 566 Acee Lindem 567 Cisco Systems 568 301 Midenhall Way 569 Cary, NC 27513 570 USA 572 Email: acee@cisco.com