idnits 2.17.00 (12 Aug 2021) /tmp/idnits41939/draft-ietf-ospf-prefix-link-attr-05.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 (May 17, 2015) is 2561 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-bier-ospf-bier-extensions has been published as RFC 8444 == Outdated reference: draft-ietf-ospf-ospfv3-lsa-extend has been published as RFC 8362 == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665 == Outdated reference: A later version (-02) exists of draft-francois-spring-segment-routing-ti-lfa-01 Summary: 0 errors (**), 0 flaws (~~), 6 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: November 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 May 17, 2015 16 OSPFv2 Prefix/Link Attribute Advertisement 17 draft-ietf-ospf-prefix-link-attr-05.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 November 18, 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 2. OSPFv2 Extended Prefix Opaque LSA . . . . . . . . . . . . . . 3 79 2.1. OSPFv2 Extended Prefix TLV . . . . . . . . . . . . . . . 5 80 3. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . . . 7 81 3.1. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . 8 82 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 83 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 84 5.1. Implementation Survey Results . . . . . . . . . . . . . . 10 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 7.1. OSPF Extended Prefix Opaque LSA TLV Registry . . . . . . 12 88 7.2. OSPF Extended Prefix TLV Sub-TLV Registry . . . . . . . . 12 89 7.3. OSPF Extended Link Opaque LSA TLV Registry . . . . . . . 12 90 7.4. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 13 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 94 9.2. Informative References . . . . . . . . . . . . . . . . . 14 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 98 1. Introduction 100 OSPFv2 requires functional extension beyond what can readily be done 101 with the fixed-format Link State Advertisements (LSAs) as described 102 in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based 103 on Type-Length-Value (TLV) tuples that can be used to associate 104 additional attributes with prefixes or links. Dependent on the 105 application, these prefixes and links may or not be advertised in the 106 fixed-format LSAs. The OSPF opaque LSAs are optional and fully 107 backward compatible. This is in contrast to the approach taken in 108 OSPFv3 [I-D.ietf-ospf-ospfv3-lsa-extend] where the existing LSAs will 109 be replaced by TLV-based extended LSAs. 111 New requirements such as source/destination routing, route tagging, 112 and segment routing necessitate this extension. 114 This specification defines the following OSPFv2 opaque LSAs: 116 1. OSPFv2 Extended Prefix Opaque LSA - Allows advertisement of 117 additional attributes for prefixes advertised in Router-LSAs, 118 Network-LSAs, Network-Summary-LSAs, NSSA-LSAs, and AS-External- 119 LSAs [OSPFV2] 121 2. OSPFv2 Extended Link Opaque LSA - Allows advertisement of 122 additional attributes for links advertised in Router-LSAs. 124 Additionally, the following TLVs are defined: 126 1. OSPFv2 Extended Prefix TLV - Top-level TLV advertising attributes 127 for a prefix in the OSPFv2 Extended Prefix Opaque LSA. 129 2. OSPFv2 Extended Link TLV - Top-level TLV advertising attributes 130 for a link in the OSPFv2 Extended Link Opaque LSA. 132 1.1. Requirements notation 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC-KEYWORDS]. 138 2. OSPFv2 Extended Prefix Opaque LSA 140 The OSPFv2 Extended Prefix Opaque LSA will be used to advertise 141 additional prefix attributes. Opaque LSAs are described in [OPAQUE]. 143 Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an 144 OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix 145 Opaque LSA depends on the scope of the advertised prefixes and is 146 under the control of the advertising router. In some cases (e.g., 147 mapping server deployment), the LSA flooding scope may be greater 148 than the scope of the corresponding prefixes. 150 The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | LS age | Options | 9, 10, or 11 | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Opaque type | Instance | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Advertising Router | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | LS sequence number | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | LS checksum | length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | 166 +- TLVs -+ 167 | ... | 169 OSPFv2 Extended Prefix Opaque LSA 171 The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. 173 The Instance field is an arbitrary value used to maintain multiple 174 Extended Prefix Opaque LSAs. A maximum of 16777216 Extended Prefix 175 Opaque LSAs may be sourced by a single OSPF instance. 177 The format of the TLVs within the body of the OSPFv2 Extended Prefix 178 Opaque LSA is the same as the format used by the Traffic Engineering 179 Extensions to OSPF [TE]. The variable TLV section consists of one or 180 more nested Type/Length/Value (TLV) tuples. Nested TLVs are also 181 referred to as sub-TLVs. The format of each TLV is: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Value... | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 TLV Format 193 The Length field defines the length of the value portion in octets 194 (thus a TLV with no value portion would have a length of 0). The TLV 195 is padded to 4-octet alignment; padding is not included in the length 196 field (so a 3-octet value would have a length of 3, but the total 197 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 198 aligned. For example, a 1-byte value would have the length field set 199 to 1, and 3 octets of padding would be added to the end of the value 200 portion of the TLV. 202 2.1. OSPFv2 Extended Prefix TLV 204 The OSPF Extended Prefix TLV is used to advertise additional 205 attributes associated with the prefix. Multiple OSPF Extended Prefix 206 TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA. 207 However, since the opaque LSA type defines the flooding scope, the 208 LSA flooding scope MUST satisfy the application specific requirements 209 for all the prefixes included in a single OSPFv2 Extended Prefix 210 Opaque LSA. The OSPF Extended Prefix TLV has the following format: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Type | Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Route Type | Prefix Length | AF | Flags | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Address Prefix (variable) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Sub-TLVs (variable) | 222 +- -+ 223 | | 225 OSPFv2 Extended Prefix TLV 227 Type 228 The TLV type. Suggested value is 1. 230 Length 231 Variable dependent on sub-TLVs. 233 Route Type 234 Route type: type of the OSPF route. If the route type is 0 235 (Unspecified), the information inside the OSPF External Prefix TLV 236 applies to the prefix regardless of prefix's route-type. This is 237 useful when prefix specific attributes are advertised by an 238 external entity, which is not aware of the route-type associated 239 with the prefix. Supported types are: 241 0 - Unspecified 243 1 - Intra-Area 245 3 - Inter-Area 247 5 - AS External 249 7 - NSSA External 251 Prefix Length 252 Length in of the prefix in bits. 254 AF 255 Address family for the prefix. Currently, the only supported 256 value is 0 for IPv4 unicast. 258 Flags: 1 octet field. The following flags are defined: 260 0 1 2 3 4 5 6 7 261 +--+--+--+--+--+--+--+--+ 262 |A |N | | | | | | | 263 +--+--+--+--+--+--+--+--+ 265 where: 267 A-Flag: Attach flag. An ABR generating Extended Prefix TLV for 268 inter-area prefix that is locally connected or attached in 269 other connected area SHOULD set this flag. 271 N-Flag: Set when the prefix identifies the advertising router 272 i.e., the prefix is a host prefix advertising a globally 273 reachable address typically associated with a loopback address. 275 The advertising router MAY choose to NOT set this flag even 276 when the above conditions are met. If the flag is set and the 277 prefix length is NOT a host prefix then the flag MUST be 278 ignored. The flag is preserved when OSPFv2 Extended Prefix 279 Opaque LSA is propagated between areas. 281 Address Prefix 282 The prefix itself encoded as an even multiple of 32-bit words, 283 padded with zeroed bits as necessary. This encoding consumes 284 ((PrefixLength + 31) / 32) 32-bit words. The default route is 285 represented by a prefix of length 0. 287 If this TLV is advertised multiple times for the same prefix in the 288 same OSPFv2 Extended Prefix Opaque LSA, only the first instance is 289 used by receiving OSPFv2 Routers. This situation SHOULD be logged as 290 an error. 292 If this TLV is advertised multiple times for the same prefix in 293 different OSPFv2 Extended Prefix Opaque LSAs originated by the same 294 OSPF router, the OSPF advertising router is re-originating Extended 295 Prefix Opaque LSAs for multiple prefixes and is most likely repacking 296 Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case, 297 the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the 298 smallest Instance is used by receiving OSPFv2 Routers. This 299 situation MAY be logged as a warning. 301 It is RECOMMENDED that OSPF routers advertising Extended Prefix TLVs 302 in different Extended Prefix Opaque LSAs re-originate these LSAs in 303 ascending order of Instance to minimize the disruption. 305 If this TLV is advertised multiple times for the same prefix in 306 different OSPFv2 Extended Prefix Opaque LSAs originated by the 307 different OSPF routers, the application using the information is 308 required to determine which OSPFv2 Extended Prefix Opaque LSA is 309 used. For example, the application could prefer the LSA providing 310 the best path to the prefix. 312 This document creates a registry for OSPF Extended Prefix sub-TLVs in 313 Section 7. 315 3. OSPFv2 Extended Link Opaque LSA 317 The OSPFv2 Extended Link Opaque LSA will be used to advertise 318 additional link attributes. Opaque LSAs are described in [OPAQUE]. 320 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 321 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 322 single router in an area. 324 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | LS age | Options | 10 | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Opaque type | Instance | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Advertising Router | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | LS sequence number | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | LS checksum | length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 +- TLVs -+ 341 | ... | 343 OSPFv2 Extended Link Opaque LSA 345 The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. 347 The Instance field is an arbitrary value used to maintain multiple 348 Extended Link Opaque LSAs. A maximum of 16777216 Extended Link 349 Opaque LSAs may be sourced by a single OSPF instance. 351 The format of the TLVs within the body of the OSPFv2 Extended Link 352 Opaque LSA is the same as described in Section 2. 354 3.1. OSPFv2 Extended Link TLV 356 The OSPFv2 Extended Link TLV is used to advertise various attributes 357 of the link. It describes a single link and is constructed of a set 358 of Sub-TLVs. There are no ordering requirements for the Sub-TLVs. 359 Only one Extended Link TLV SHALL be advertised in each Extended Link 360 Opaque LSA, allowing for fine granularity changes in the topology. 362 The Extended Link TLV has following format: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Link-Type | Reserved | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Link ID | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Link Data | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Sub-TLVs (variable) | 376 +- -+ 377 | | 379 OSPFv2 Extended Link TLV 381 Type 382 The TLV type. Suggested value is 1. 384 Length 385 Variable dependent on sub-TLVs. 387 Link-Type 388 Link-Type is defined in section A.4.2 of [OSPFV2]. 390 Link-ID 391 Link-ID is defined in section A.4.2 of [OSPFV2]. 393 Link Data 394 Link-Data is defined in section A.4.2 of [OSPFV2]. 396 If this TLV is advertised multiple times in the same OSPFv2 Extended 397 Link Opaque LSA, only the first instance is used by receiving OSPFv2 398 Routers. This situation SHOULD be logged as an error. 400 If this TLV is advertised multiple times for the same link in 401 different OSPFv2 Extended Link Opaque LSAs originated by the same 402 OSPF router, the Extended Link TLV in the Extended Link Opaque LSA 403 with the smallest Instance is used by receiving OSPFv2 Routers. This 404 situation MAY be logged as a warning. 406 It is RECOMMENDED that OSPF routers advertising Extended Link TLVs in 407 different Extended Link Opaque LSAs re-originate these LSAs in 408 ascending order of Instance to minimize the disruption. 410 This document creates a registry for OSPF Extended Link sub-TLVs in 411 Section 7. 413 4. Backward Compatibility 415 Since opaque OSPFv2 LSAs are optional and backward compatible 416 [OPAQUE], the extensions described herein is fully backward 417 compatible. However, future OSPFv2 extensions utilizing these 418 extensions must address backward compatibility of the corresponding 419 functionality. 421 5. Implementation Status 423 This section records the status of known implementations of the 424 protocol defined by this specification at the time of posting of this 425 Internet-Draft, and is based on a proposal described in RFC 6982. 426 The description of implementations in this section is intended to 427 assist the IETF in its decision processes in progressing drafts to 428 RFCs. Please note that the listing of any individual implementation 429 here does not imply endorsement by the IETF. Furthermore, no effort 430 has been spent to verify the information presented here that was 431 supplied by IETF contributors. This is not intended as, and must not 432 be construed to be, a catalog of available implementations or their 433 features. Readers are advised to note that other implementations may 434 exist. 436 According to RFC 6982, "this will allow reviewers and working groups 437 to assign due consideration to documents that have the benefit of 438 running code, which may serve as evidence of valuable experimentation 439 and feedback that have made the implemented protocols more mature. 440 It is up to the individual working groups to use this information as 441 they see fit". 443 5.1. Implementation Survey Results 445 An implementation survey with seven questions related to the 446 implementer's support of OSPFv2 Prefix/Link Attributes was sent to 447 the OSPF WG list and several known implementers. This section 448 contains responses from four implementers who completed the survey. 449 No external means were used to verify the accuracy of the information 450 submitted by the respondents. The respondents are considered experts 451 on the products they reported on. Additionally, responses were 452 omitted from implementers who indicated that they have not 453 implemented the function yet. 455 Four vendors replied to the survey. These include Alcatel-Lucent, 456 Cisco, Huawei, Juniper. Cisco and Alcatel-Lucent also did 457 interoperability testing. The Cisco and Alcatel-Lucent 458 implementations are in released software versions. The Huawei and 459 Juniper implementation software releases are pending. For prefix 460 attributes, the recent change incorporating the A-Flag is pending 461 implementation for all four vendors. Implementation of the N-flag is 462 pending for the Huawei and Juniper implementations. Otherwise, the 463 vendors have full implementations. For all four vendors, segment 464 routing [SEGMENT-ROUTING] was an application making use of the 465 extensions. Additionally, Cisco has implemented Topology-Independent 466 Loop-Free Alternatives (TI-LFA) [TI-LFA] and Bit Indexed Egress 467 Replication (BIER) advertisement [BIER]. 469 Alcatel-Lucent's support of this specification is included in SR OS, 470 Release 13.0.R4. Cisco's support is included in IOS-XR 5.3.2. 471 Huawei and Juniper will respectively provide support in future 472 versions Versatile Routing Platform (VRP) and JUniper Network 473 Operating System (JUNOS). 475 6. Security Considerations 477 In general, new LSAs defined in this document are subject to the same 478 security concerns as those described in [OSPFV2]. Additionally, 479 implementations must assure that malformed TLV and Sub-TLV 480 permutations do not result in errors that cause hard OSPF failures. 482 7. IANA Considerations 484 This specification updates the Opaque Link-State Advertisements (LSA) 485 Option Types with the following values: 487 o 7 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Prefix 488 Opaque LSA 490 o 8 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Link Opaque 491 LSA 493 This specification also creates four new registries: 495 o OSPF Extended Prefix Opaque LSA TLVs 497 o OSPF Extended Prefix TLV Sub-TLVs 499 o OSPF Extended Link Opaque LSA TLVs 501 o OSPF Extended Link TLV Sub-TLVs 503 7.1. OSPF Extended Prefix Opaque LSA TLV Registry 505 The OSPF Extend Prefix Opaque LSA TLV registry will define top-level 506 TLVs for Extended Prefix Opaque LSA and should be placed in the 507 existing OSPF IANA registry. New values can be allocated via IETF 508 Consensus or IESG Approval. 510 The following initial values are allocated: 512 o 0 - Reserved 514 o 1 - OSPF Extended Prefix TLV 516 Types in the range 32768-33023 are for experimental use; these will 517 not be registered with IANA, and MUST NOT be mentioned by RFCs. 519 Types in the range 33024-65535 are not to be assigned at this time. 520 Before any assignments can be made in the 33024-65535 range, there 521 MUST be an IETF specification that specifies IANA Considerations that 522 covers the range being assigned. 524 7.2. OSPF Extended Prefix TLV Sub-TLV Registry 526 The OSPF Extended Prefix TLV sub-TLV registry will define sub-TLVs at 527 any level of nesting for Extended Prefix TLV and should be placed in 528 the existing OSPF IANA registry. New values can be allocated via 529 IETF Consensus or IESG Approval. 531 The following initial values are allocated: 533 o 0 - Reserved 535 Types in the range 32768-33023 are for experimental use; these will 536 not be registered with IANA, and MUST NOT be mentioned by RFCs. 538 Types in the range 33024-65535 are not to be assigned at this time. 539 Before any assignments can be made in the 33024-65535 range, there 540 MUST be an IETF specification that specifies IANA Considerations that 541 covers the range being assigned. 543 7.3. OSPF Extended Link Opaque LSA TLV Registry 545 The OSPF Extended Link Opaque LSA TLV registry will define top-level 546 TLVs for Extended Link Opaque LSAs and should be placed in the 547 existing OSPF IANA registry. New values can be allocated via IETF 548 Consensus or IESG Approval. 550 Following initial values are allocated: 552 o 0 - Reserved 554 o 1 - OSPFv2 Extended Link TLV 556 Types in the range 32768-33023 are for experimental use; these will 557 not be registered with IANA, and MUST NOT be mentioned by RFCs. 559 Types in the range 33024-65535 are not to be assigned at this time. 560 Before any assignments can be made in the 33024-65535 range, there 561 MUST be am IETF specification that specifies IANA Considerations that 562 covers the range being assigned. 564 7.4. OSPF Extended Link TLV Sub-TLV Registry 566 The OSPF Extended Link TLV sub-TLV registry will define sub-TLVs at 567 any level of nesting for Extended Link TLV and should be placed in 568 the existing OSPF IANA registry. New values can be allocated via 569 IETF Consensus or IESG Approval. 571 The following initial values are allocated: 573 o 0 - Reserved 575 Types in the range 32768-33023 are for experimental use; these will 576 not be registered with IANA, and MUST NOT be mentioned by RFCs. 577 Types in the range 33024-65535 are not to be assigned at this time. 578 Before any assignments can be made in the 33024-65535 range, there 579 MUST be an IETF specification that specifies IANA Considerations that 580 covers the range being assigned. 582 8. Acknowledgments 584 We would like to thank Anton Smirnov for his contribution. 586 Thanks to Tony Przygienda for his review and comments. 588 Thanks to Wim Henderickx, Greg Harkins, Peter Psenak, Eric Wu, and 589 Shraddha Hegde for their responses to the implementation survey. 591 9. References 593 9.1. Normative References 595 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 596 OSPF Opaque LSA Option", RFC 5250, July 2008. 598 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 600 [RFC-KEYWORDS] 601 Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", RFC 2119, March 1997. 604 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 605 Extensions to OSPF", RFC 3630, September 2003. 607 9.2. Informative References 609 [BIER] Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 610 Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions 611 for BIER", draft-ietf-bier-ospf-bier-extensions-00.txt 612 (work in progress), April 2015. 614 [I-D.ietf-ospf-ospfv3-lsa-extend] 615 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 616 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-06 617 (work in progress), February 2015. 619 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 620 Points", BCP 100, RFC 7120, January 2014. 622 [SEGMENT-ROUTING] 623 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 624 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 625 Extensions for Segment Routing", draft-ietf-ospf-segment- 626 routing-extensions-04.txt (work in progress), February 627 2015. 629 [TI-LFA] Francois, P., Filsfils, C., Bashandy, A., Decraene, B., 630 and S. Litkowski, "Topology Independent Fast Reroute using 631 Segment Routing", draft-francois-spring-segment-routing- 632 ti-lfa-01.txt (work in progress), October 2014. 634 Authors' Addresses 636 Peter Psenak 637 Cisco Systems 638 Apollo Business Center 639 Mlynske nivy 43 640 Bratislava, 821 09 641 Slovakia 643 Email: ppsenak@cisco.com 644 Hannes Gredler 645 Juniper Networks, Inc. 646 1194 N. Mathilda Ave. 647 Sunnyvale, CA 94089 648 USA 650 Email: hannes@juniper.net 652 Rob Shakir 653 British Telcom 654 London 655 UK 657 Email: rob.shakir@bt.com 659 Wim Henderickx 660 Alcatel-Lucent 661 Copernicuslaan 662 Antwerp, 2018 94089 663 Belgium 665 Email: wim.henderickx@alcatel-lucent.com 667 Jeff Tantsura 668 Ericsson 669 300 Holger Way 670 San Jose, CA 95134 671 USA 673 Email: jeff.tantsura@ericsson.com 675 Acee Lindem 676 Cisco Systems 677 301 Midenhall Way 678 Cary, NC 27513 679 USA 681 Email: acee@cisco.com