idnits 2.17.1 draft-ietf-ospf-prefix-link-attr-09.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 5, 2015) is 3179 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 (-18) exists of draft-ietf-bier-ospf-bier-extensions-00 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-06 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-04 == 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: February 6, 2016 Juniper Networks, Inc. 6 R. Shakir 7 Individual Contributor 8 W. Henderickx 9 Alcatel-Lucent 10 J. Tantsura 11 Ericsson 12 A. Lindem 13 Cisco Systems 14 August 5, 2015 16 OSPFv2 Prefix/Link Attribute Advertisement 17 draft-ietf-ospf-prefix-link-attr-09.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 February 6, 2016. 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 . . . . . . . . . . . . . . . 8 81 3.1. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . 9 82 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 83 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 84 5.1. Implementation Survey Results . . . . . . . . . . . . . . 11 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . 13 90 7.4. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 13 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 9.2. Informative References . . . . . . . . . . . . . . . . . 14 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 [SEGMENT-ROUTING]), the LSA flooding scope 148 may be greater 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. The 172 opaque type is used to differential the various type of OSPFv2 Opaque 173 LSA and is described in section 3 of [OPAQUE]. 175 The Instance field is an arbitrary value used to maintain multiple 176 Extended Prefix Opaque LSAs. For OSPFv2 Extended Prefix Opaque LSAs, 177 the Instance has no semantic significance other than to differentiate 178 Extended Prefix Opaque LSAs originated by the same OSPFv2 router. If 179 multiple Extended Prefix Opaque LSAs include the same prefix, the 180 attributes from the Opaque LSA with the lowest Instance will be used. 182 The format of the TLVs within the body of the OSPFv2 Extended Prefix 183 Opaque LSA is the same as the format used by the Traffic Engineering 184 Extensions to OSPF [TE]. The variable TLV section consists of one or 185 more nested Type/Length/Value (TLV) tuples. Nested TLVs are also 186 referred to as sub-TLVs. The format of each TLV is: 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type | Length | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Value... | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 TLV Format 198 The Length field defines the length of the value portion in octets 199 (thus a TLV with no value portion would have a length of 0). The TLV 200 is padded to 4-octet alignment; padding is not included in the length 201 field (so a 3-octet value would have a length of 3, but the total 202 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 203 aligned. For example, a 1-byte value would have the length field set 204 to 1, and 3 octets of padding would be added to the end of the value 205 portion of the TLV. 207 2.1. OSPFv2 Extended Prefix TLV 209 The OSPF Extended Prefix TLV is used to advertise additional 210 attributes associated with the prefix. Multiple OSPF Extended Prefix 211 TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA. 212 However, since the opaque LSA type defines the flooding scope, the 213 LSA flooding scope MUST satisfy the application specific requirements 214 for all the prefixes included in a single OSPFv2 Extended Prefix 215 Opaque LSA. The OSPF Extended Prefix TLV has the following format: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Type | Length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Route Type | Prefix Length | AF | Flags | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Address Prefix (variable) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Sub-TLVs (variable) | 227 +- -+ 228 | | 230 OSPFv2 Extended Prefix TLV 232 Type 233 The TLV type. The value is 1 for this TLV type. 235 Length 236 Variable dependent on sub-TLVs. 238 Route Type 239 Route type: type of the OSPF route. If the route type is 0 240 (Unspecified), the information inside the OSPF External Prefix TLV 241 applies to the prefix regardless of prefix's route-type. This is 242 useful when prefix specific attributes are advertised by an 243 external entity that is not aware of the route-type associated 244 with the prefix. Supported types are: 246 0 - Unspecified 248 1 - Intra-Area 250 3 - Inter-Area 252 5 - AS External 254 7 - NSSA External 256 These route types correspond directly to the OSPFv2 LSAs types as 257 defined in http://www.iana.org/assignments/ospfv2-parameters/ 258 ospfv2-parameters.xhtml#ospfv2-parameters-5. 260 Prefix Length 261 Length in of the prefix in bits. 263 AF 264 Address family for the prefix. Currently, the only supported 265 value is 0 for IPv4 unicast. OSPFv3 [OSPFV3] is used for OSPF 266 advertisement of IPv6 prefixes so this address family is not 267 applicable. The inclusion of address family in this TLV allows 268 for future extension. 270 Flags: 1 octet field. The following flags are defined: 272 0 1 2 3 4 5 6 7 273 +--+--+--+--+--+--+--+--+ 274 |A |N | | | | | | | 275 +--+--+--+--+--+--+--+--+ 277 where: 279 A-Flag: Attach flag. An Area Border Router (ABR) generating an 280 Extended Prefix TLV for inter-area prefix that is locally 281 connected or attached in other connected area SHOULD set this 282 flag. 284 N-Flag: Set when the prefix identifies the advertising router 285 i.e., the prefix is a host prefix advertising a globally 286 reachable address typically associated with a loopback address. 287 The advertising router MAY choose to NOT set this flag even 288 when the above conditions are met. If the flag is set and the 289 prefix length is NOT a host prefix then the flag MUST be 290 ignored. The flag is preserved when the OSPFv2 Extended Prefix 291 Opaque LSA is propagated between areas. 293 Address Prefix 294 The prefix itself encoded as an even multiple of 32-bit words, 295 padded with zeroed bits as necessary. This encoding consumes 296 ((PrefixLength + 31) / 32) 32-bit words. The default route is 297 represented by a prefix of length 0. 299 If this TLV is advertised multiple times for the same prefix in the 300 same OSPFv2 Extended Prefix Opaque LSA, only the first instance is 301 used by receiving OSPFv2 Routers. This situation SHOULD be logged as 302 an error. 304 If this TLV is advertised multiple times for the same prefix in 305 different OSPFv2 Extended Prefix Opaque LSAs originated by the same 306 OSPF router, the OSPF advertising router is re-originating Extended 307 Prefix Opaque LSAs for multiple prefixes and is most likely repacking 308 Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case, 309 the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the 310 smallest Instance is used by receiving OSPFv2 Routers. This 311 situation MAY be logged as a warning. 313 It is RECOMMENDED that OSPF routers advertising Extended Prefix TLVs 314 in different Extended Prefix Opaque LSAs re-originate these LSAs in 315 ascending order of Instance to minimize the disruption. 317 If this TLV is advertised multiple times for the same prefix in 318 different OSPFv2 Extended Prefix Opaque LSAs originated by the 319 different OSPF routers, the application using the information is 320 required to determine which OSPFv2 Extended Prefix Opaque LSA is 321 used. For example, the application could prefer the LSA providing 322 the best path to the prefix. 324 This document creates a registry for OSPF Extended Prefix sub-TLVs in 325 Section 7. 327 3. OSPFv2 Extended Link Opaque LSA 329 The OSPFv2 Extended Link Opaque LSA will be used to advertise 330 additional link attributes. Opaque LSAs are described in [OPAQUE]. 332 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 333 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 334 single router in an area. 336 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | LS age | Options | 10 | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Opaque type | Instance | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Advertising Router | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | LS sequence number | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | LS checksum | length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 +- TLVs -+ 353 | ... | 355 OSPFv2 Extended Link Opaque LSA 357 The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. The 358 opaque type is used to differential the various type of OSPFv2 Opaque 359 LSA and is described in section 3 of [OPAQUE]. 361 The Instance field is an arbitrary value used to maintain multiple 362 Extended Prefix Opaque LSAs. For OSPFv2 Extended Link Opaque LSAs, 363 the Instance has no semantic significance other than to differentiate 364 Extended Link Opaque LSAs originated by the same OSPFv2 router. If 365 multiple Extended Link Opaque LSAs include the same link, the 366 attributes from the Opaque LSA with the lowest Instance will be used. 368 The format of the TLVs within the body of the OSPFv2 Extended Link 369 Opaque LSA is the same as described in Section 2. 371 3.1. OSPFv2 Extended Link TLV 373 The OSPFv2 Extended Link TLV is used to advertise various attributes 374 of the link. It describes a single link and is constructed of a set 375 of Sub-TLVs. There are no ordering requirements for the Sub-TLVs. 376 Only one Extended Link TLV SHALL be advertised in each Extended Link 377 Opaque LSA, allowing for fine granularity changes in the topology. 379 The Extended Link TLV has following format: 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type | Length | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Link-Type | Reserved | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Link ID | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Link Data | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Sub-TLVs (variable) | 393 +- -+ 394 | | 396 OSPFv2 Extended Link TLV 398 Type 399 The TLV type. The value is 1 for this TLV type. 401 Length 402 Variable dependent on sub-TLVs. 404 Link-Type 405 Link-Type is defined in section A.4.2 of [OSPFV2] and 406 http://www.iana.org/assignments/ospfv2-parameters/ 407 ospfv2-parameters.xhtml#ospfv2-parameters-6. 409 Link-ID 410 Link-ID is defined in section A.4.2 of [OSPFV2]. 412 Link Data 413 Link-Data is defined in section A.4.2 of [OSPFV2]. 415 If this TLV is advertised multiple times in the same OSPFv2 Extended 416 Link Opaque LSA, only the first instance is used by receiving OSPFv2 417 Routers. This situation SHOULD be logged as an error. 419 If this TLV is advertised multiple times for the same link in 420 different OSPFv2 Extended Link Opaque LSAs originated by the same 421 OSPF router, the Extended Link TLV in the Extended Link Opaque LSA 422 with the smallest Instance is used by receiving OSPFv2 Routers. This 423 situation MAY be logged as a warning. 425 It is RECOMMENDED that OSPF routers advertising Extended Link TLVs in 426 different Extended Link Opaque LSAs re-originate these LSAs in 427 ascending order of Instance to minimize the disruption. 429 This document creates a registry for OSPF Extended Link sub-TLVs in 430 Section 7. 432 4. Backward Compatibility 434 Since opaque OSPFv2 LSAs are optional and backward compatible 435 [OPAQUE], the extensions described herein are fully backward 436 compatible. However, future OSPFv2 extensions utilizing these 437 extensions must address backward compatibility of the corresponding 438 functionality. 440 5. Implementation Status 442 Note to RFC Editor: this section may be removed on publication as an 443 RFC. 445 This section records the status of known implementations of the 446 protocol defined by this specification at the time of posting of this 447 Internet-Draft, and is based on a proposal described in RFC 6982. 448 The description of implementations in this section is intended to 449 assist the IETF in its decision processes in progressing drafts to 450 RFCs. Please note that the listing of any individual implementation 451 here does not imply endorsement by the IETF. Furthermore, no effort 452 has been spent to verify the information presented here that was 453 supplied by IETF contributors. This is not intended as, and must not 454 be construed to be, a catalog of available implementations or their 455 features. Readers are advised to note that other implementations may 456 exist. 458 According to RFC 6982, "this will allow reviewers and working groups 459 to assign due consideration to documents that have the benefit of 460 running code, which may serve as evidence of valuable experimentation 461 and feedback that have made the implemented protocols more mature. 463 It is up to the individual working groups to use this information as 464 they see fit". 466 5.1. Implementation Survey Results 468 An implementation survey with seven questions related to the 469 implementer's support of OSPFv2 Prefix/Link Attributes was sent to 470 the OSPF WG list and several known implementers. This section 471 contains responses from four implementers who completed the survey. 472 No external means were used to verify the accuracy of the information 473 submitted by the respondents. The respondents are considered experts 474 on the products they reported on. Additionally, responses were 475 omitted from implementers who indicated that they have not 476 implemented the function yet. 478 Four vendors and one open source entity replied to the survey. These 479 included Alcatel-Lucent, Cisco, Huawei, Juniper, and FreeRouter 480 (http://freerouter.nop.hu). Cisco and Alcatel-Lucent also did 481 interoperability testing. FreeRouter did interoperability testing 482 with Cisco. The Cisco, Alcatel-Lucent, and FreeRouter 483 implementations are in released software versions. The Huawei and 484 Juniper implementation software releases are pending. For prefix 485 attributes, the recent change incorporating the A-Flag is pending 486 implementation for all four vendors. The FreeRouter implementation 487 includes support for the A-Flag. Implementation of the N-flag is 488 pending for the Huawei and Juniper implementations. Otherwise, all 489 the survey respondents have full implementations. For all four 490 vendors and the FreeRouter implementation, segment routing 491 [SEGMENT-ROUTING] was an application making use of the extensions. 492 Additionally, Cisco has implemented Topology-Independent Loop-Free 493 Alternatives (TI-LFA) [TI-LFA] and Bit Indexed Egress Replication 494 (BIER) advertisement [BIER]. 496 Alcatel-Lucent's support of this specification is included in SR OS, 497 Release 13.0.R4. Cisco's support is included in IOS-XR 5.3.2. The 498 FreeRouter implementation is available in the FreeRouter 15.6.4 499 distribution. Huawei and Juniper will respectively provide support 500 in future versions Versatile Routing Platform (VRP) and JUniper 501 Network Operating System (JUNOS). 503 6. Security Considerations 505 In general, new LSAs defined in this document are subject to the same 506 security concerns as those described in [OSPFV2]. Additionally, 507 implementations must assure that malformed TLV and Sub-TLV 508 permutations do not result in errors that cause hard OSPF failures. 510 7. IANA Considerations 512 This specification updates the Opaque Link-State Advertisements (LSA) 513 Option Types with the following values: 515 o 7 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Prefix 516 Opaque LSA 518 o 8 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Link Opaque 519 LSA 521 This specification also creates four new registries: 523 o OSPF Extended Prefix Opaque LSA TLVs 525 o OSPF Extended Prefix TLV Sub-TLVs 527 o OSPF Extended Link Opaque LSA TLVs 529 o OSPF Extended Link TLV Sub-TLVs 531 7.1. OSPF Extended Prefix Opaque LSA TLV Registry 533 The "OSPF Extend Prefix Opaque LSA TLV" registry will define top- 534 level TLVs for the Extended Prefix Opaque LSAs and should be added to 535 the "Open Shortest Path First v2 (OSPFv2) Parameters" registries 536 group. New values can be allocated via IETF Review or IESG Approval. 538 The following initial values are allocated: 540 o 0 - Reserved 542 o 1 - OSPF Extended Prefix TLV 544 Types in the range 32768-33023 are for experimental use; these will 545 not be registered with IANA, and MUST NOT be mentioned by RFCs. 547 Types in the range 33024-65535 are not to be assigned at this time. 548 Before any assignments can be made in the 33024-65535 range, there 549 MUST be an IETF specification that specifies IANA Considerations that 550 covers the range being assigned. 552 7.2. OSPF Extended Prefix TLV Sub-TLV Registry 554 The "OSPF Extended Prefix TLV sub-TLV" registry will define sub-TLVs 555 at any level of nesting for Extended Prefix TLVs and should be added 556 to the "Open Shortest Path First v2 (OSPFv2) Parameters" registries 557 group. New values can be allocated via IETF Review or IESG Approval. 559 The following initial values are allocated: 561 o 0 - Reserved 563 Types in the range 32768-33023 are for experimental use; these will 564 not be registered with IANA, and MUST NOT be mentioned by RFCs. 566 Types in the range 33024-65535 are not to be assigned at this time. 567 Before any assignments can be made in the 33024-65535 range, there 568 MUST be an IETF specification that specifies IANA Considerations that 569 covers the range being assigned. 571 7.3. OSPF Extended Link Opaque LSA TLV Registry 573 The "OSPF Extended Link Opaque LSA TLV" registry will define top- 574 level TLVs for Extended Link Opaque LSAs and should be added to the 575 "Open Shortest Path First v2 (OSPFv2) Parameters" registries group. 576 New values can be allocated via IETF Review or IESG Approval. 578 Following initial values are allocated: 580 o 0 - Reserved 582 o 1 - OSPFv2 Extended Link TLV 584 Types in the range 32768-33023 are for experimental use; these will 585 not be registered with IANA, and MUST NOT be mentioned by RFCs. 587 Types in the range 33024-65535 are not to be assigned at this time. 588 Before any assignments can be made in the 33024-65535 range, there 589 MUST be am IETF specification that specifies IANA Considerations that 590 covers the range being assigned. 592 7.4. OSPF Extended Link TLV Sub-TLV Registry 594 The OSPF Extended Link TLV sub-TLV registry will define sub-TLVs at 595 any level of nesting for Extended Link TLVs and should be added to 596 the "Open Shortest Path First v2 (OSPFv2) Parameters" registries 597 group. New values can be allocated via IETF Review or IESG Approval. 599 The following initial values are allocated: 601 o 0 - Reserved 603 Types in the range 32768-33023 are for experimental use; these will 604 not be registered with IANA, and MUST NOT be mentioned by RFCs. 605 Types in the range 33024-65535 are not to be assigned at this time. 606 Before any assignments can be made in the 33024-65535 range, there 607 MUST be an IETF specification that specifies IANA Considerations that 608 covers the range being assigned. 610 8. Acknowledgments 612 We would like to thank Anton Smirnov for his contribution. 614 Thanks to Tony Przygienda for his review and comments. 616 Thanks to Wim Henderickx, Greg Harkins, Peter Psenak, Eric Wu, 617 Shraddha Hegde, and Csaba Mate for their responses to the 618 implementation survey. 620 Thanks to Alia Atlas for AD review and comments. 622 Thanks to Tom Petch for review and comments. 624 9. References 626 9.1. Normative References 628 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 629 OSPF Opaque LSA Option", RFC 5250, July 2008. 631 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 633 [RFC-KEYWORDS] 634 Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", RFC 2119, March 1997. 637 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 638 Extensions to OSPF", RFC 3630, September 2003. 640 9.2. Informative References 642 [BIER] Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 643 Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions 644 for BIER", draft-ietf-bier-ospf-bier-extensions-00.txt 645 (work in progress), April 2015. 647 [I-D.ietf-ospf-ospfv3-lsa-extend] 648 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 649 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-06 650 (work in progress), February 2015. 652 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 653 for IPv6", RFC 5340, July 2008. 655 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 656 Points", BCP 100, RFC 7120, January 2014. 658 [SEGMENT-ROUTING] 659 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 660 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 661 Extensions for Segment Routing", draft-ietf-ospf-segment- 662 routing-extensions-04.txt (work in progress), February 663 2015. 665 [TI-LFA] Francois, P., Filsfils, C., Bashandy, A., Decraene, B., 666 and S. Litkowski, "Topology Independent Fast Reroute using 667 Segment Routing", draft-francois-spring-segment-routing- 668 ti-lfa-01.txt (work in progress), October 2014. 670 Authors' Addresses 672 Peter Psenak 673 Cisco Systems 674 Apollo Business Center 675 Mlynske nivy 43 676 Bratislava, 821 09 677 Slovakia 679 Email: ppsenak@cisco.com 681 Hannes Gredler 682 Juniper Networks, Inc. 683 1194 N. Mathilda Ave. 684 Sunnyvale, CA 94089 685 USA 687 Email: hannes@juniper.net 689 Rob Shakir 690 Individual Contributor 691 London 692 UK 694 Email: rjs@rob.sh 695 Wim Henderickx 696 Alcatel-Lucent 697 Copernicuslaan 698 Antwerp, 2018 94089 699 Belgium 701 Email: wim.henderickx@alcatel-lucent.com 703 Jeff Tantsura 704 Ericsson 705 300 Holger Way 706 San Jose, CA 95134 707 USA 709 Email: jeff.tantsura@ericsson.com 711 Acee Lindem 712 Cisco Systems 713 301 Midenhall Way 714 Cary, NC 27513 715 USA 717 Email: acee@cisco.com