idnits 2.17.00 (12 Aug 2021) /tmp/idnits53834/draft-ietf-ospf-lsa-extend-00.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 (August 11, 2014) is 2833 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-multi-instance has been published as RFC 6549 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 S. Previdi 4 Intended status: Standards Track C. Filsfils 5 Expires: February 12, 2015 Cisco Systems 6 H. Gredler 7 Juniper Networks, Inc. 8 R. Shakir 9 British Telcom 10 W. Henderickx 11 Alcatel-Lucent 12 J. Tantsura 13 Ericsson 14 A. Lindem 15 Cisco Systems 16 August 11, 2014 18 OSPFv2 LSA Extendibility 19 draft-ietf-ospf-lsa-extend-00.txt 21 Abstract 23 OSPFv2 requires functional extension beyond what can readily be done 24 with the fixed-format Link State Advertisements (LSAs) as described 25 in RFC 2323. This document defines OSPF opaque LSAs based on Type- 26 Length-Value (TLV) tuples that can be used to associate additional 27 attributes with advertised prefixes or links. The OSPF opaque LSAs 28 are optional and fully backward 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 February 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 . . . . . . . . . . . . . . 4 79 2.1. OSPFv2 Extended Prefix TLV . . . . . . . . . . . . . . . . 6 80 3. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . . . 7 81 3.1. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . . 8 82 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 6.1. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 10 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 . . . . . . . . . 11 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 91 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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 advertised prefixes or links. The OSPF 101 opaque LSAs are optional and fully backward compatible. This is in 102 contrast to the approach taken in OSPFv3 [OSPFV3-LSA-EXTEND] where 103 the existing LSAs will be replaced TLV-based extended LSAs. 105 New requirements such as source/destination routing, route tagging, 106 and segment routing necessitate this extension. 108 The specfication defines the following OSPFv2 opaque LSAs: 110 1. OSPFv2 Extended Prefix LSA - Allows advertisement of additional 111 attributes for prefixes advertised in Router-LSAs, Network-LSAs, 112 Network-Summary-LSAs, NSSA-LSAs, and AS-External-LSAs [OSPFV2] 114 2. OSPFv2 Extended links LSA - Allows advertisement of additional 115 attributes for links advertised in Router-LSAs. 117 Additionally, the following TLVs are defined: 119 1. OSPFv2 Extended Prefix TLV - Top level TLV advertising attributes 120 for a prefix in the OSPFv2 Extended Prefix LSA. 122 2. OSPFv2 Extended Link TLV - Top level TLV advertising attributes 123 for a link in the OSPFv2 Extended link LSA. 125 1.1. Requirements notation 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC-KEYWORDS]. 131 1.2. Acknowledgments 133 We would like to thank Anton Smirnov for his contribution. 135 2. OSPFv2 Extended Prefix Opaque LSA 137 The OSPFv2 Extended Prefix Opaque LSA will be used to advertise 138 additional prefix attributes. Opaque LSAs are described in [OPAQUE]. 140 Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an 141 OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix 142 Opaque LSA depends on the scope of the advertised prefixes and is 143 under the control of the advertising router. In some cases (e.g., 144 mapping server deployment), the LSA flooding scope may be greater 145 than the scope of the corresponding prefixes. 147 The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | LS age | Options | 9, 10, or 11 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Opaque type | Instance | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Advertising Router | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | LS sequence number | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | LS checksum | length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 +- TLVs -+ 164 | ... | 166 OSPFv2 Extended Prefix LSA 168 The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. 170 The format of the TLVs within the body of the OSPFv2 Extended Prefix 171 LSA is the same as the format used by the Traffic Engineering 172 Extensions to OSPF [TE]. The variable TLV section consists of one or 173 more nested Type/Length/Value (TLV) tuples. Nested TLVs are also 174 referred to as sub-TLVs. The format of each TLV is: 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type | Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Value... | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 TLV Format 186 The Length field defines the length of the value portion in octets 187 (thus a TLV with no value portion would have a length of 0). The TLV 188 is padded to 4-octet alignment; padding is not included in the length 189 field (so a 3-octet value would have a length of 3, but the total 190 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 191 aligned. For example, a 1-byte value would have the length field set 192 to 1, and 3 octets of padding would be added to the end of the value 193 portion of the TLV. 195 2.1. OSPFv2 Extended Prefix TLV 197 The OSPF Extended Prefix TLV is used in order to advertise additional 198 attributes associated with the prefix. Multiple OSPF Extended Prefix 199 TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but 200 all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA 201 MUST have the same flooding scope. The OSPF Extended Prefix TLV has 202 the following format: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Route Type | Prefix Length | AF | Reserved | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Address Prefix (variable) | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Sub-TLVs (variable) | 214 +- -+ 215 | | 217 OSPFv2 Extended Prefix TLV 219 Type 220 The TLV type. Suggested value is 1. 222 Length 223 Variable dependent on sub-TLVs. 225 Route Type 226 Route type: type of the OSPF route. If the route type is 0 227 (unspecified), the information inside the OSPF External Prefix TLV 228 applies to the prefix regardless of prefix's route-type. This is 229 useful when prefix specific attributes are advertised by ax 230 external entity, which is not aware of the route-type associated 231 with the prefix. Supported types are: 233 0 - unspecified 235 1 - intra-area 237 3 - inter-area 239 5 - external 241 7 - NSSA external 243 Prefix Length 244 Length in of the prefix in bits. 246 AF 247 Address family for the prefix. Currently, the only supported 248 value is 0 for IPv4 unicast. 250 Address Prefix 251 The prefix itself encoded as an even multiple of 32-bit words, 252 padded with zeroed bits as necessary. This encoding consumes 253 ((PrefixLength + 31) / 32) 32-bit words. The default route is 254 represented by a prefix of length 0. 256 This document creates a registry for OSPF Extended Prefix sub-TLVs in 257 Section 6. 259 3. OSPFv2 Extended Link Opaque LSA 261 The OSPFv2 Extended Link Opaque LSA will be used to advertise 262 additional link attributes. Opaque LSAs are described in [OPAQUE]. 264 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 265 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 266 single router in an area. 268 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | LS age | Options | 10 | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Opaque type | Instance | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Advertising Router | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | LS sequence number | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | LS checksum | length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 +- TLVs -+ 285 | ... | 287 OSPFv2 Extended Link LSA 289 The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. 291 The format of the TLVs within the body of the OSPFv2 Extended Prefix 292 LSA is the same as Section 2. 294 3.1. OSPFv2 Extended Link TLV 296 OSPFv2 Extended Link TLV is used in order to advertise various 297 attributes of the link. It describes a single link and is 298 constructed of a set of Sub-TLVs. There are no ordering requirements 299 for the Sub-TLVs. Only one Extended Link TLV SHALL be advertised in 300 each Extended Link Opaque LSA, allowing for fine granularity changes 301 in the topology. 303 The Extended Link TLV has following format: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type | Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Link-Type | Reserved | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Link ID | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Link Data | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Sub-TLVs (variable) | 317 +- -+ 318 | | 320 OSPFv2 Extended Link TLV 322 Type 323 The TLV type. Suggested value is 1. 325 Length 326 Variable dependent on sub-TLVs. 328 Link-Type 329 Link-Type is defined in section A.4.2 of [OSPFV2]. 331 Link-ID 332 Link-ID is defined in section A.4.2 of [OSPFV2]. 334 Link Data 335 Link-Data is defined in section A.4.2 of [OSPFV2]. 337 This document creates a registry for OSPF Extended Link sub-TLVs in 338 Section 6. 340 4. Backward Compatibility 342 Since opaque OSPFv2 LSAs are optional and backward compatible 343 [OPAQUE], the extensions described herein is fully backward 344 compatible. However, future OSPFv2 extensions utilizing these 345 extensions must address backward compatibility of the corresponding 346 functionality. 348 5. Security Considerations 350 In general, new LSAs defined in this document are subject to the same 351 security concerns as those described in [OSPFV2]. Additionally, 352 implementations must assure that malformed TLV and Sub-TLV 353 permutations do not result in errors which cause hard OSPF failures. 355 6. IANA Considerations 357 This specification updates the Opaque Link-State Advertisements (LSA) 358 Option Types with the following values: 360 o 7 (IANA Preallocated) - OSPFv2 Extended Prefix Opaque LSA 362 o 8 (IANA preallocated) - OSPFv2 Extended Link Opaque LSA 364 This specification also creates four new registries: 366 o OSPF Extended Prefix LSA TLVs 368 o OSPF Extended Prefix TLV Sub-TLVs 370 o OSPF Extended Link LSA TLVs 372 o OSPF Extended Link TLV Sub-TLVs 374 6.1. OSPF Extended Prefix LSA TLV Registry 376 The OSPF Extend Prefix LSA TLV registry will define top-level TLVs 377 for Extended Prefix LSAs and should be placed in the existing OSPF 378 IANA registry. New values can be allocated via IETF Consensus or 379 IESG Approval. 381 The following initial values are allocated: 383 o 0 - Reserved 385 o 1 - OSPF Extended Prefix TLV 387 Types in the range 32768-33023 are for experimental use; these will 388 not be registered with IANA, and MUST NOT be mentioned by RFCs. 390 Types in the range 33023-65535 are not to be assigned at this time. 391 Before any assignments can be made in this range, there MUST be a 392 Standards Track RFC that specifies IANA Considerations that covers 393 the range being assigned. 395 6.2. OSPF Extended Prefix TLV Sub-TLV Registry 397 The OSPF Extended Link LSA sub-TLV registry will define will define 398 sub-TLVs at any level of nesting for Extended Link LSAs and should be 399 placed in the existing OSPF IANA registry. New values can be 400 allocated via IETF Consensus or IESG Approval. 402 The following initial values are allocated: 404 o 0 - Reserved 406 Types in the range 32768-33023 are for experimental use; these will 407 not be registered with IANA, and MUST NOT be mentioned by RFCs. 409 Types in the range 33023-65535 are not to be assigned at this time. 410 Before any assignments can be made in this range, there MUST be a 411 Standards Track RFC that specifies IANA Considerations that covers 412 the range being assigned. 414 6.3. OSPF Extended Link LSA TLV Registry 416 The OSPF Extend Link LSA TLV registry will define top-level TLVs for 417 Extended Link LSAs and should be placed in the existing OSPF IANA 418 registry. New values can be allocated via IETF Consensus or IESG 419 Approval. 421 Following initial values are allocated: 423 o 0 - Reserved 425 o 1 - OSPFv2 Extended Link TLV 427 Types in the range 32768-33023 are for experimental use; these will 428 not be registered with IANA, and MUST NOT be mentioned by RFCs. 430 Types in the range 33023-65535 are not to be assigned at this time. 431 Before any assignments can be made in this range, there MUST be a 432 Standards Track RFC that specifies IANA Considerations that covers 433 the range being assigned. 435 6.4. OSPF Extended Link TLV Sub-TLV Registry 437 The OSPF Extended Link sub-TLV registry will define will define sub- 438 TLVs at any level of nesting for Extended Link LSAs and should be 439 placed in the existing OSPF IANA registry. New values can be 440 allocated via IETF Consensus or IESG Approval. 442 The following initial values are allocated: 444 o 0 - Reserved 446 Types in the range 32768-33023 are for experimental use; these will 447 not be registered with IANA, and MUST NOT be mentioned by RFCs. 448 Types in the range 33023-65535 are not to be assigned at this time. 449 Before any assignments can be made in this range, there MUST be a 450 Standards Track RFC that specifies IANA Considerations that covers 451 the range being assigned. 453 7. References 455 7.1. Normative References 457 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 458 OSPF Opaque LSA Option", RFC 5250, July 2008. 460 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 462 [RFC-KEYWORDS] 463 Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", RFC 2119, March 1997. 466 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 467 Extensions to OSPF", RFC 3630, September 2003. 469 7.2. Informative References 471 [OSPFV3-LSA-EXTEND] 472 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 473 LSA Extendibility", draft-ietf-ospf-multi-instance-02.txt 474 (work in progress). 476 Authors' Addresses 478 Peter Psenak 479 Cisco Systems 480 Apollo Business Center 481 Mlynske nivy 43 482 Bratislava, 821 09 483 Slovakia 485 Email: ppsenak@cisco.com 486 Stefano Previdi 487 Cisco Systems 488 Via Del Serafico, 200 489 Rome, 00142 490 Italy 492 Email: sprevidi@cisco.com 494 Clarence Filsfils 495 Cisco Systems 496 Brussels 497 Belgium 499 Email: cfilsfils@cisco.com 501 Hannes Gredler 502 Juniper Networks, Inc. 503 1194 N. Mathilda Ave. 504 Sunnyvale, CA 94089 505 USA 507 Email: hannes@juniper.net 509 Rob Shakir 510 British Telcom 511 London 512 UK 514 Email: rob.shakir@bt.com 516 Wim Henderickx 517 Alcatel-Lucent 518 Copernicuslaan 519 Antwerp, 2018 94089 520 Belgium 522 Email: wim.henderickx@alcatel-lucent.com 523 Jeff Tantsura 524 Ericsson 525 300 Holger Way 526 San Jose, CA 95134 527 USA 529 Email: jeff.tantsura@ericsson.com 531 Acee Lindem 532 Cisco Systems 533 301 Midenhall Way 534 Cary, NC 27513 535 USA 537 Email: acee@cisco.com