idnits 2.17.1 draft-ietf-ospf-prefix-link-attr-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 12, 2014) is 3546 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-02 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: February 13, 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 August 12, 2014 16 OSPFv2 Prefix/Link Attribute Advertisement 17 draft-ietf-ospf-prefix-link-attr-00.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 advertised prefixes or links. The OSPF opaque LSAs 26 are optional and fully backward compatible. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 13, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 76 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 77 2. OSPFv2 Extended Prefix Opaque LSA . . . . . . . . . . . . . . 4 78 2.1. OSPFv2 Extended Prefix TLV . . . . . . . . . . . . . . . . 6 79 3. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . . . 7 80 3.1. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . . 8 81 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 6.1. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 10 85 6.2. OSPF Extended Prefix TLV Sub-TLV Registry . . . . . . . . 11 86 6.3. OSPF Extended Link LSA TLV Registry . . . . . . . . . . . 11 87 6.4. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 11 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 90 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 OSPFv2 requires functional extension beyond what can readily be done 96 with the fixed-format Link State Advertisements (LSAs) as described 97 in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based 98 on Type-Length-Value (TLV) tuples that can be used to associate 99 additional attributes with advertised prefixes or links. The OSPF 100 opaque LSAs are optional and fully backward compatible. This is in 101 contrast to the approach taken in OSPFv3 [OSPFV3-LSA-EXTEND] where 102 the existing LSAs will be replaced TLV-based extended LSAs. 104 New requirements such as source/destination routing, route tagging, 105 and segment routing necessitate this extension. 107 The specfication defines the following OSPFv2 opaque LSAs: 109 1. OSPFv2 Extended Prefix LSA - Allows advertisement of additional 110 attributes for prefixes advertised in Router-LSAs, Network-LSAs, 111 Network-Summary-LSAs, NSSA-LSAs, and AS-External-LSAs [OSPFV2] 113 2. OSPFv2 Extended links LSA - Allows advertisement of additional 114 attributes for links advertised in Router-LSAs. 116 Additionally, the following TLVs are defined: 118 1. OSPFv2 Extended Prefix TLV - Top level TLV advertising attributes 119 for a prefix in the OSPFv2 Extended Prefix LSA. 121 2. OSPFv2 Extended Link TLV - Top level TLV advertising attributes 122 for a link in the OSPFv2 Extended link LSA. 124 1.1. Requirements notation 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC-KEYWORDS]. 130 1.2. Acknowledgments 132 We would like to thank Anton Smirnov for his contribution. 134 2. OSPFv2 Extended Prefix Opaque LSA 136 The OSPFv2 Extended Prefix Opaque LSA will be used to advertise 137 additional prefix attributes. Opaque LSAs are described in [OPAQUE]. 139 Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an 140 OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix 141 Opaque LSA depends on the scope of the advertised prefixes and is 142 under the control of the advertising router. In some cases (e.g., 143 mapping server deployment), the LSA flooding scope may be greater 144 than the scope of the corresponding prefixes. 146 The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | LS age | Options | 9, 10, or 11 | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Opaque type | Instance | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Advertising Router | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | LS sequence number | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | LS checksum | length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | | 162 +- TLVs -+ 163 | ... | 165 OSPFv2 Extended Prefix LSA 167 The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. 169 The format of the TLVs within the body of the OSPFv2 Extended Prefix 170 LSA is the same as the format used by the Traffic Engineering 171 Extensions to OSPF [TE]. The variable TLV section consists of one or 172 more nested Type/Length/Value (TLV) tuples. Nested TLVs are also 173 referred to as sub-TLVs. The format of each TLV is: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type | Length | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Value... | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 TLV Format 185 The Length field defines the length of the value portion in octets 186 (thus a TLV with no value portion would have a length of 0). The TLV 187 is padded to 4-octet alignment; padding is not included in the length 188 field (so a 3-octet value would have a length of 3, but the total 189 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 190 aligned. For example, a 1-byte value would have the length field set 191 to 1, and 3 octets of padding would be added to the end of the value 192 portion of the TLV. 194 2.1. OSPFv2 Extended Prefix TLV 196 The OSPF Extended Prefix TLV is used in order to advertise additional 197 attributes associated with the prefix. Multiple OSPF Extended Prefix 198 TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but 199 all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA 200 MUST have the same flooding scope. The OSPF Extended Prefix TLV has 201 the following format: 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Route Type | Prefix Length | AF | Reserved | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Address Prefix (variable) | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Sub-TLVs (variable) | 213 +- -+ 214 | | 216 OSPFv2 Extended Prefix TLV 218 Type 219 The TLV type. Suggested value is 1. 221 Length 222 Variable dependent on sub-TLVs. 224 Route Type 225 Route type: type of the OSPF route. If the route type is 0 226 (unspecified), the information inside the OSPF External Prefix TLV 227 applies to the prefix regardless of prefix's route-type. This is 228 useful when prefix specific attributes are advertised by an 229 external entity, which is not aware of the route-type associated 230 with the prefix. Supported types are: 232 0 - unspecified 234 1 - intra-area 236 3 - inter-area 238 5 - external 240 7 - NSSA external 242 Prefix Length 243 Length in of the prefix in bits. 245 AF 246 Address family for the prefix. Currently, the only supported 247 value is 0 for IPv4 unicast. 249 Address Prefix 250 The prefix itself encoded as an even multiple of 32-bit words, 251 padded with zeroed bits as necessary. This encoding consumes 252 ((PrefixLength + 31) / 32) 32-bit words. The default route is 253 represented by a prefix of length 0. 255 This document creates a registry for OSPF Extended Prefix sub-TLVs in 256 Section 6. 258 3. OSPFv2 Extended Link Opaque LSA 260 The OSPFv2 Extended Link Opaque LSA will be used to advertise 261 additional link attributes. Opaque LSAs are described in [OPAQUE]. 263 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 264 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 265 single router in an area. 267 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | LS age | Options | 10 | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Opaque type | Instance | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Advertising Router | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | LS sequence number | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | LS checksum | length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 +- TLVs -+ 284 | ... | 286 OSPFv2 Extended Link LSA 288 The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. 290 The format of the TLVs within the body of the OSPFv2 Extended Prefix 291 LSA is the same as Section 2. 293 3.1. OSPFv2 Extended Link TLV 295 OSPFv2 Extended Link TLV is used in order to advertise various 296 attributes of the link. It describes a single link and is 297 constructed of a set of Sub-TLVs. There are no ordering requirements 298 for the Sub-TLVs. Only one Extended Link TLV SHALL be advertised in 299 each Extended Link Opaque LSA, allowing for fine granularity changes 300 in the topology. 302 The Extended Link TLV has following format: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Link-Type | Reserved | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Link ID | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Link Data | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Sub-TLVs (variable) | 316 +- -+ 317 | | 319 OSPFv2 Extended Link TLV 321 Type 322 The TLV type. Suggested value is 1. 324 Length 325 Variable dependent on sub-TLVs. 327 Link-Type 328 Link-Type is defined in section A.4.2 of [OSPFV2]. 330 Link-ID 331 Link-ID is defined in section A.4.2 of [OSPFV2]. 333 Link Data 334 Link-Data is defined in section A.4.2 of [OSPFV2]. 336 This document creates a registry for OSPF Extended Link sub-TLVs in 337 Section 6. 339 4. Backward Compatibility 341 Since opaque OSPFv2 LSAs are optional and backward compatible 342 [OPAQUE], the extensions described herein is fully backward 343 compatible. However, future OSPFv2 extensions utilizing these 344 extensions must address backward compatibility of the corresponding 345 functionality. 347 5. Security Considerations 349 In general, new LSAs defined in this document are subject to the same 350 security concerns as those described in [OSPFV2]. Additionally, 351 implementations must assure that malformed TLV and Sub-TLV 352 permutations do not result in errors which cause hard OSPF failures. 354 6. IANA Considerations 356 This specification updates the Opaque Link-State Advertisements (LSA) 357 Option Types with the following values: 359 o 7 (IANA Preallocated) - OSPFv2 Extended Prefix Opaque LSA 361 o 8 (IANA preallocated) - OSPFv2 Extended Link Opaque LSA 363 This specification also creates four new registries: 365 o OSPF Extended Prefix LSA TLVs 367 o OSPF Extended Prefix TLV Sub-TLVs 369 o OSPF Extended Link LSA TLVs 371 o OSPF Extended Link TLV Sub-TLVs 373 6.1. OSPF Extended Prefix LSA TLV Registry 375 The OSPF Extend Prefix LSA TLV registry will define top-level TLVs 376 for Extended Prefix LSAs and should be placed in the existing OSPF 377 IANA registry. New values can be allocated via IETF Consensus or 378 IESG Approval. 380 The following initial values are allocated: 382 o 0 - Reserved 384 o 1 - OSPF Extended Prefix TLV 386 Types in the range 32768-33023 are for experimental use; these will 387 not be registered with IANA, and MUST NOT be mentioned by RFCs. 389 Types in the range 33024-65535 are not to be assigned at this time. 390 Before any assignments can be made in the 33024-65535 range, there 391 MUST be an IETF specification that specifies IANA Considerations that 392 covers the range being assigned. 394 6.2. OSPF Extended Prefix TLV Sub-TLV Registry 396 The OSPF Extended Link LSA sub-TLV registry will define will define 397 sub-TLVs at any level of nesting for Extended Link LSAs and should be 398 placed in the existing OSPF IANA registry. New values can be 399 allocated via IETF Consensus or IESG Approval. 401 The following initial values are allocated: 403 o 0 - Reserved 405 Types in the range 32768-33023 are for experimental use; these will 406 not be registered with IANA, and MUST NOT be mentioned by RFCs. 408 Types in the range 33024-65535 are not to be assigned at this time. 409 Before any assignments can be made in the 33024-65535 range, there 410 MUST be an IETF specificatin that specifies IANA Considerations that 411 covers the range being assigned. 413 6.3. OSPF Extended Link LSA TLV Registry 415 The OSPF Extend Link LSA TLV registry will define top-level TLVs for 416 Extended Link LSAs and should be placed in the existing OSPF IANA 417 registry. New values can be allocated via IETF Consensus or IESG 418 Approval. 420 Following initial values are allocated: 422 o 0 - Reserved 424 o 1 - OSPFv2 Extended Link TLV 426 Types in the range 32768-33023 are for experimental use; these will 427 not be registered with IANA, and MUST NOT be mentioned by RFCs. 429 Types in the range 33024-65535 are not to be assigned at this time. 430 Before any assignments can be made in the 33024-65535 range, there 431 MUST be am IETF specification that specifies IANA Considerations that 432 covers the range being assigned. 434 6.4. OSPF Extended Link TLV Sub-TLV Registry 436 The OSPF Extended Link sub-TLV registry will define will define sub- 437 TLVs at any level of nesting for Extended Link LSAs and should be 438 placed in the existing OSPF IANA registry. New values can be 439 allocated via IETF Consensus or IESG Approval. 441 The following initial values are allocated: 443 o 0 - Reserved 445 Types in the range 32768-33023 are for experimental use; these will 446 not be registered with IANA, and MUST NOT be mentioned by RFCs. 447 Types in the range 33024-65535 are not to be assigned at this time. 448 Before any assignments can be made in the 33024-65535 range, there 449 MUST be an IETF specification that specifies IANA Considerations that 450 covers the range being assigned. 452 7. References 454 7.1. Normative References 456 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 457 OSPF Opaque LSA Option", RFC 5250, July 2008. 459 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 461 [RFC-KEYWORDS] 462 Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", RFC 2119, March 1997. 465 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 466 Extensions to OSPF", RFC 3630, September 2003. 468 7.2. Informative References 470 [OSPFV3-LSA-EXTEND] 471 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 472 LSA Extendibility", 473 draft-ietf-ospf-ospfv3-lsa-extend-02.txt (work in 474 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 Hannes Gredler 487 Juniper Networks, Inc. 488 1194 N. Mathilda Ave. 489 Sunnyvale, CA 94089 490 USA 492 Email: hannes@juniper.net 494 Rob Shakir 495 British Telcom 496 London 497 UK 499 Email: rob.shakir@bt.com 501 Wim Henderickx 502 Alcatel-Lucent 503 Copernicuslaan 504 Antwerp, 2018 94089 505 Belgium 507 Email: wim.henderickx@alcatel-lucent.com 509 Jeff Tantsura 510 Ericsson 511 300 Holger Way 512 San Jose, CA 95134 513 USA 515 Email: jeff.tantsura@ericsson.com 517 Acee Lindem 518 Cisco Systems 519 301 Midenhall Way 520 Cary, NC 27513 521 USA 523 Email: acee@cisco.com