idnits 2.17.1 draft-ietf-ospf-prefix-link-attr-13.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 20, 2015) is 3143 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-05 == Outdated reference: A later version (-04) exists of draft-francois-rtgwg-segment-routing-ti-lfa-00 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 21, 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 20, 2015 16 OSPFv2 Prefix/Link Attribute Advertisement 17 draft-ietf-ospf-prefix-link-attr-13.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 21, 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 . . . . . . . . . . . . . . . . . . . 12 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 7.1. OSPF Extended Prefix Opaque LSA TLV Registry . . . . . . 13 88 7.2. OSPF Extended Prefix TLV Sub-TLV Registry . . . . . . . . 13 89 7.3. OSPF Extended Prefix TLV Flags Registry . . . . . . . . . 13 90 7.4. OSPF Extended Link Opaque LSA TLV Registry . . . . . . . 14 91 7.5. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 14 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 95 9.2. Informative References . . . . . . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 | LS Type | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Opaque type | Opaque ID | 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 differentiate the various type of OSPFv2 173 Opaque LSA and is described in section 3 of [OPAQUE]. The LS Type 174 may be 10 or 11 indicating that the Opaque LSA flooding scope is 175 area-local (10) or AS-wide (11) [OPAQUE]. The LSA "Length" field 176 [OSPFV2] represents the total length (in octets) of the Opaque LSA 177 including the LSA header and all TLVs (including padding). 179 The Opaque ID field is an arbitrary value used to maintain multiple 180 Extended Prefix Opaque LSAs. For OSPFv2 Extended Prefix Opaque LSAs, 181 the Opaque ID has no semantic significance other than to 182 differentiate Extended Prefix Opaque LSAs originated by the same 183 OSPFv2 router. If multiple Extended Prefix Opaque LSAs include the 184 same prefix, the attributes from the Opaque LSA with the lowest 185 Opaque ID SHOULD be used. 187 The format of the TLVs within the body of the OSPFv2 Extended Prefix 188 Opaque LSA is the same as the format used by the Traffic Engineering 189 Extensions to OSPF [TE]. The variable TLV section consists of one or 190 more nested Type/Length/Value (TLV) tuples. Nested TLVs are also 191 referred to as sub-TLVs. The format of each TLV is: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type | Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Value | 199 o 200 o 201 o 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 TLV Format 207 The Length field defines the length of the value portion in octets 208 (thus a TLV with no value portion would have a length of 0). The TLV 209 is padded to 4-octet alignment; padding is not included in the length 210 field (so a 3-octet value would have a length of 3, but the total 211 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 212 aligned. For example, a 1-byte value would have the length field set 213 to 1, and 3 octets of padding would be added to the end of the value 214 portion of the TLV. The padding is composed of zeros. 216 2.1. OSPFv2 Extended Prefix TLV 218 The OSPF Extended Prefix TLV is used to advertise additional 219 attributes associated with the prefix. Multiple OSPF Extended Prefix 220 TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA. 221 However, since the opaque LSA type defines the flooding scope, the 222 LSA flooding scope MUST satisfy the application specific requirements 223 for all the prefixes included in a single OSPFv2 Extended Prefix 224 Opaque LSA. The OSPF Extended Prefix TLV has the following format: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type | Length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Route Type | Prefix Length | AF | Flags | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Address Prefix (variable) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Sub-TLVs (variable) | 236 +- -+ 237 | | 239 OSPFv2 Extended Prefix TLV 241 Type 242 The TLV type. The value is 1 for this TLV type. 244 Length 245 Variable dependent on sub-TLVs. 247 Route Type 248 Route type: type of the OSPF route. If the route type is 0 249 (Unspecified), the information inside the OSPF External Prefix TLV 250 applies to the prefix regardless of prefix's route-type. This is 251 useful when prefix specific attributes are advertised by an 252 external entity that is not aware of the route-type associated 253 with the prefix. Supported types are: 255 0 - Unspecified 257 1 - Intra-Area 259 3 - Inter-Area 261 5 - AS External 263 7 - NSSA External 265 These route types correspond directly to the OSPFv2 LSAs types as 266 defined in http://www.iana.org/assignments/ospfv2-parameters/ 267 ospfv2-parameters.xhtml#ospfv2-parameters-5. Specification of 268 route types other than those defined will prevent correlation with 269 existing OSPFv2 LSAs and is beyond the scope this specification. 271 Prefix Length 272 Length in the prefix in bits. 274 AF 275 Address family for the prefix. Currently, the only supported 276 value is 0 for IPv4 unicast. The inclusion of address family in 277 this TLV allows for future extension. 279 Flags 280 This one octet field contains flags applicable to the prefix. 281 Supported Flags include: 283 0x80 - A-Flag (Attach flag): An Area Border Router (ABR) 284 generating an Extended Prefix TLV for inter-area prefix that is 285 locally connected or attached in other connected area SHOULD 286 set this flag. 288 0x40 - N-Flag (Node Flag): Set when the prefix identifies the 289 advertising router i.e., the prefix is a host prefix 290 advertising a globally reachable address typically associated 291 with a loopback address. The advertising router MAY choose to 292 not set this flag even when the above conditions are met. If 293 the flag is set and the prefix length is not a host prefix then 294 the flag MUST be ignored. The flag is preserved when the 295 OSPFv2 Extended Prefix Opaque LSA is propagated between areas. 297 Address Prefix 298 For the address family IPv4 unicast, the prefix itself encoded as 299 a 32-bit value. The default route is represented by a prefix of 300 length 0. Prefix encoding for other address families is beyond 301 the scope of this specification. 303 If this TLV is advertised multiple times for the same prefix in the 304 same OSPFv2 Extended Prefix Opaque LSA, only the first instance of 305 the TLV is used by receiving OSPFv2 Routers. This situation SHOULD 306 be logged as an error. 308 If this TLV is advertised multiple times for the same prefix in 309 different OSPFv2 Extended Prefix Opaque LSAs originated by the same 310 OSPF router, the OSPF advertising router is re-originating Extended 311 Prefix Opaque LSAs for multiple prefixes and is most likely repacking 312 Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case, 313 the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the 314 smallest Opaque ID is used by receiving OSPFv2 Routers. This 315 situation may be logged as a warning. 317 It is RECOMMENDED that OSPF routers advertising Extended Prefix TLVs 318 in different Extended Prefix Opaque LSAs re-originate these LSAs in 319 ascending order of Opaque ID to minimize the disruption. 321 If this TLV is advertised multiple times for the same prefix in 322 different OSPFv2 Extended Prefix Opaque LSAs originated by different 323 OSPF routers, the application using the information is required to 324 determine which OSPFv2 Extended Prefix Opaque LSA is used. For 325 example, the application could prefer the LSA providing the best path 326 to the prefix. 328 This document creates a registry for OSPF Extended Prefix sub-TLVs in 329 Section 7. 331 3. OSPFv2 Extended Link Opaque LSA 333 The OSPFv2 Extended Link Opaque LSA will be used to advertise 334 additional link attributes. Opaque LSAs are described in [OPAQUE]. 336 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 337 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 338 single router in an area. 340 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | LS age | Options | LS Type | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Opaque type | Opaque ID | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Advertising Router | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | LS sequence number | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | LS checksum | Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | | 356 +- TLVs -+ 357 | ... | 359 OSPFv2 Extended Link Opaque LSA 361 The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. The LS 362 Type is 10 indicating that the Opaque LSA flooding scope is area- 363 local [OPAQUE]. The opaque type is used to differentiate the various 364 type of OSPFv2 Opaque LSA and is described in section 3 of [OPAQUE]. 365 The LSA "Length" field [OSPFV2] represents the total length (in 366 octets) of the Opaque LSA including the LSA header and all TLVs 367 (including padding). 369 The Opaque ID field is an arbitrary value used to maintain multiple 370 Extended Prefix Opaque LSAs. For OSPFv2 Extended Link Opaque LSAs, 371 the Opaque ID has no semantic significance other than to 372 differentiate Extended Link Opaque LSAs originated by the same OSPFv2 373 router. If multiple Extended Link Opaque LSAs include the same link, 374 the attributes from the Opaque LSA with the lowest Opaque ID will be 375 used. 377 The format of the TLVs within the body of the OSPFv2 Extended Link 378 Opaque LSA is the same as described in Section 2. 380 3.1. OSPFv2 Extended Link TLV 382 The OSPFv2 Extended Link TLV is used to advertise various attributes 383 of the link. It describes a single link and is constructed of a set 384 of Sub-TLVs. There are no ordering requirements for the Sub-TLVs. 385 Only one Extended Link TLV SHALL be advertised in each Extended Link 386 Opaque LSA, allowing for fine granularity changes in the topology. 388 The Extended Link TLV has following format: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type | Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Link-Type | Reserved | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Link ID | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Link Data | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Sub-TLVs (variable) | 402 +- -+ 403 | | 405 OSPFv2 Extended Link TLV 407 Type 408 The TLV type. The value is 1 for this TLV type. 410 Length 411 Variable dependent on sub-TLVs. 413 Link-Type 414 Link-Type is defined in section A.4.2 of [OSPFV2] and 415 http://www.iana.org/assignments/ospfv2-parameters/ 416 ospfv2-parameters.xhtml#ospfv2-parameters-6. Specification of 417 link types other than those defined will prevent correlation with 418 existing OSPFv2 Router-LSA links and is beyond the scope this 419 specification. 421 Link-ID 422 Link-ID is defined in section A.4.2 of [OSPFV2]. 424 Link Data 425 Link-Data is defined in section A.4.2 of [OSPFV2]. 427 If this TLV is advertised multiple times in the same OSPFv2 Extended 428 Link Opaque LSA, only the first instance of the TLV is used by 429 receiving OSPFv2 Routers. This situation SHOULD be logged as an 430 error. 432 If this TLV is advertised multiple times for the same link in 433 different OSPFv2 Extended Link Opaque LSAs originated by the same 434 OSPF router, the Extended Link TLV in the Extended Link Opaque LSA 435 with the smallest Opaque ID is used by receiving OSPFv2 Routers. 436 This situation may be logged as a warning. 438 It is RECOMMENDED that OSPF routers advertising Extended Link TLVs in 439 different Extended Link Opaque LSAs re-originate these LSAs in 440 ascending order of Opaque ID to minimize the disruption. 442 This document creates a registry for OSPF Extended Link sub-TLVs in 443 Section 7. 445 4. Backward Compatibility 447 Since opaque OSPFv2 LSAs are optional and backward compatible 448 [OPAQUE], the extensions described herein are fully backward 449 compatible. However, future OSPFv2 applications utilizing these 450 extensions MUST address backward compatibility of the corresponding 451 functionality. 453 5. Implementation Status 455 Note to RFC Editor: this section may be removed on publication as an 456 RFC. 458 This section records the status of known implementations of the 459 protocol defined by this specification at the time of posting of this 460 Internet-Draft, and is based on a proposal described in RFC 6982. 461 The description of implementations in this section is intended to 462 assist the IETF in its decision processes in progressing drafts to 463 RFCs. Please note that the listing of any individual implementation 464 here does not imply endorsement by the IETF. Furthermore, no effort 465 has been spent to verify the information presented here that was 466 supplied by IETF contributors. This is not intended as, and must not 467 be construed to be, a catalog of available implementations or their 468 features. Readers are advised to note that other implementations may 469 exist. 471 According to RFC 6982, "this will allow reviewers and working groups 472 to assign due consideration to documents that have the benefit of 473 running code, which may serve as evidence of valuable experimentation 474 and feedback that have made the implemented protocols more mature. 475 It is up to the individual working groups to use this information as 476 they see fit". 478 5.1. Implementation Survey Results 480 An implementation survey with seven questions related to the 481 implementer's support of OSPFv2 Prefix/Link Attributes was sent to 482 the OSPF WG list and several known implementers. This section 483 contains responses from four implementers who completed the survey. 484 No external means were used to verify the accuracy of the information 485 submitted by the respondents. The respondents are considered experts 486 on the products they reported on. Additionally, responses were 487 omitted from implementers who indicated that they have not 488 implemented the function yet. 490 Four vendors and one open source entity replied to the survey. These 491 included Alcatel-Lucent, Cisco, Huawei, Juniper, and FreeRouter 492 (http://freerouter.nop.hu). Cisco and Alcatel-Lucent also did 493 interoperability testing. FreeRouter did interoperability testing 494 with Cisco. The Cisco, Alcatel-Lucent, and FreeRouter 495 implementations are in released software versions. The Huawei and 496 Juniper implementation software releases are pending. For prefix 497 attributes, the recent change incorporating the A-Flag is pending 498 implementation for all four vendors. The FreeRouter implementation 499 includes support for the A-Flag. Implementation of the N-flag is 500 pending for the Huawei and Juniper implementations. Otherwise, all 501 the survey respondents have full implementations. For all four 502 vendors and the FreeRouter implementation, segment routing 503 [SEGMENT-ROUTING] was an application making use of the extensions. 504 Additionally, Cisco has implemented Topology-Independent Loop-Free 505 Alternatives (TI-LFA) [TI-LFA] and Bit Indexed Egress Replication 506 (BIER) advertisement [BIER]. 508 Alcatel-Lucent's support of this specification is included in SR OS, 509 Release 13.0.R4. Cisco's support is included in IOS-XR 5.3.2. The 510 FreeRouter implementation is available in the FreeRouter 15.6.4 511 distribution. Huawei and Juniper will respectively provide support 512 in future versions Versatile Routing Platform (VRP) and JUniper 513 Network Operating System (JUNOS). 515 6. Security Considerations 517 In general, new LSAs defined in this document are subject to the same 518 security concerns as those described in [OSPFV2] and [OPAQUE]. 520 OSPFv2 applications utilizing these OSPFv2 extensions must define the 521 security considerations relating to those applications in the 522 specifications corresponding to those applications. 524 Additionally, implementations must assure that malformed TLV and Sub- 525 TLV permutations are detected and do not provide a vulnerability for 526 attackers to crash the OSPFv2 router or routing process. Malformed 527 LSAs MUST NOT be stored in the Link State Database (LSDB), 528 acknowledged, or reflooded. Reception of malformed LSAs SHOULD be 529 counted and/or logged for further analysis. In this context, a 530 malformed LSA is one which cannot be parsed due to a TLV or Sub-TLV 531 overrunning the end of the subsuming LSA, TLV, or sub-TLV or where 532 there is data remaining to be parsed but the length of the remaining 533 data is less than the size of a TLV header. 535 7. IANA Considerations 537 This specification updates the Opaque Link-State Advertisements (LSA) 538 Option Types with the following values: 540 o 7 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Prefix 541 Opaque LSA 543 o 8 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Link Opaque 544 LSA 546 This specification also creates five new registries: 548 o OSPF Extended Prefix Opaque LSA TLVs 550 o OSPF Extended Prefix TLV Sub-TLVs 552 o OSPF Extended Prefix TLV Flags 554 o OSPF Extended Link Opaque LSA TLVs 556 o OSPF Extended Link TLV Sub-TLVs 558 7.1. OSPF Extended Prefix Opaque LSA TLV Registry 560 The "OSPF Extend Prefix Opaque LSA TLV" registry will define top- 561 level TLVs for the Extended Prefix Opaque LSAs and should be added to 562 the "Open Shortest Path First v2 (OSPFv2) Parameters" registries 563 group. New values can be allocated via IETF Review or IESG Approval. 565 The following initial values are allocated: 567 o 0 - Reserved 569 o 1 - OSPF Extended Prefix TLV 571 Types in the range 32768-33023 are for experimental use; these will 572 not be registered with IANA, and MUST NOT be mentioned by RFCs. 574 Types in the range 33024-65535 are not to be assigned at this time. 575 Before any assignments can be made in the 33024-65535 range, there 576 MUST be an IETF specification that specifies IANA Considerations that 577 covers the range being assigned. 579 7.2. OSPF Extended Prefix TLV Sub-TLV Registry 581 The "OSPF Extended Prefix TLV sub-TLV" registry will define sub-TLVs 582 at any level of nesting for Extended Prefix TLVs and should be added 583 to the "Open Shortest Path First v2 (OSPFv2) Parameters" registries 584 group. New values can be allocated via IETF Review or IESG Approval. 586 The following initial values are allocated: 588 o 0 - Reserved 590 Types in the range 32768-33023 are for experimental use; these will 591 not be registered with IANA, and MUST NOT be mentioned by RFCs. 593 Types in the range 33024-65535 are not to be assigned at this time. 594 Before any assignments can be made in the 33024-65535 range, there 595 MUST be an IETF specification that specifies IANA Considerations that 596 covers the range being assigned. 598 7.3. OSPF Extended Prefix TLV Flags Registry 600 The "OSPF Extended Prefix TLV Flags" registry will define the bits in 601 the 8-bit Extended Prefix TLV Flags (Section 2.1). This 602 specification defines the N (0x80) and A (0x40) bits. The registry 603 should be added to the "Open Shortest Path First v2 (OSPFv2) 604 Parameters" registries group. New values can be allocated via IETF 605 Review or IESG Approval. 607 7.4. OSPF Extended Link Opaque LSA TLV Registry 609 The "OSPF Extended Link Opaque LSA TLV" registry will define top- 610 level TLVs for Extended Link Opaque LSAs and should be added to the 611 "Open Shortest Path First v2 (OSPFv2) Parameters" registries group. 612 New values can be allocated via IETF Review or IESG Approval. 614 Following initial values are allocated: 616 o 0 - Reserved 618 o 1 - OSPFv2 Extended Link TLV 620 Types in the range 32768-33023 are for experimental use; these will 621 not be registered with IANA, and MUST NOT be mentioned by RFCs. 623 Types in the range 33024-65535 are not to be assigned at this time. 624 Before any assignments can be made in the 33024-65535 range, there 625 MUST be am IETF specification that specifies IANA Considerations that 626 covers the range being assigned. 628 7.5. OSPF Extended Link TLV Sub-TLV Registry 630 The OSPF Extended Link TLV sub-TLV registry will define sub-TLVs at 631 any level of nesting for Extended Link TLVs and should be added to 632 the "Open Shortest Path First v2 (OSPFv2) Parameters" registries 633 group. New values can be allocated via IETF Review or IESG Approval. 635 The following initial values are allocated: 637 o 0 - Reserved 639 Types in the range 32768-33023 are for experimental use; these will 640 not be registered with IANA, and MUST NOT be mentioned by RFCs. 641 Types in the range 33024-65535 are not to be assigned at this time. 642 Before any assignments can be made in the 33024-65535 range, there 643 MUST be an IETF specification that specifies IANA Considerations that 644 covers the range being assigned. 646 8. Acknowledgments 648 We would like to thank Anton Smirnov for his contribution. 650 Thanks to Tony Przygienda for his review and comments. 652 Thanks to Wim Henderickx, Greg Harkins, Peter Psenak, Eric Wu, 653 Shraddha Hegde, and Csaba Mate for their responses to the 654 implementation survey. 656 Thanks to Tom Petch for review and comments. 658 Thanks to Alia Atlas and Alvaro Retana for AD review and comments. 660 Thanks to Carlos Pignataro and Ron Bonica for Operations Directorate 661 review and comments. 663 Thanks to Suresh Krishnan for Gen-ART review and comments. 665 Thanks to Ben Campbell, Kathleen Moriarty, and Barry Leiba for IESG 666 review and comments. 668 9. References 670 9.1. Normative References 672 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 673 OSPF Opaque LSA Option", RFC 5250, July 2008. 675 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 677 [RFC-KEYWORDS] 678 Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", RFC 2119, March 1997. 681 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 682 Extensions to OSPF", RFC 3630, September 2003. 684 9.2. Informative References 686 [BIER] Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 687 Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions 688 for BIER", draft-ietf-bier-ospf-bier-extensions-00.txt 689 (work in progress), April 2015. 691 [I-D.ietf-ospf-ospfv3-lsa-extend] 692 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 693 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-06 694 (work in progress), February 2015. 696 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 697 Points", BCP 100, RFC 7120, January 2014. 699 [SEGMENT-ROUTING] 700 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 701 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 702 Extensions for Segment Routing", draft-ietf-ospf-segment- 703 routing-extensions-05.txt (work in progress), June 2015. 705 [TI-LFA] Francois, P., Filsfils, C., Bashandy, A., Decraene, B., 706 and S. Litkowski, "Topology Independent Fast Reroute using 707 Segment Routing", draft-francois-rtgwg-segment-routing-ti- 708 lfa-00.txt (work in progress), August 2014. 710 Authors' Addresses 712 Peter Psenak 713 Cisco Systems 714 Apollo Business Center 715 Mlynske nivy 43 716 Bratislava, 821 09 717 Slovakia 719 Email: ppsenak@cisco.com 721 Hannes Gredler 722 Juniper Networks, Inc. 723 1194 N. Mathilda Ave. 724 Sunnyvale, CA 94089 725 USA 727 Email: hannes@juniper.net 729 Rob Shakir 730 Individual Contributor 731 London 732 UK 734 Email: rjs@rob.sh 736 Wim Henderickx 737 Alcatel-Lucent 738 Copernicuslaan 739 Antwerp, 2018 94089 740 Belgium 742 Email: wim.henderickx@alcatel-lucent.com 743 Jeff Tantsura 744 Ericsson 745 300 Holger Way 746 San Jose, CA 95134 747 USA 749 Email: jeff.tantsura@ericsson.com 751 Acee Lindem 752 Cisco Systems 753 301 Midenhall Way 754 Cary, NC 27513 755 USA 757 Email: acee@cisco.com