idnits 2.17.00 (12 Aug 2021) /tmp/idnits54686/draft-ietf-ospf-te-link-attr-reuse-08.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 date (August 19, 2019) is 1006 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-isis-te-app has been published as RFC 8919 == Outdated reference: A later version (-20) exists of draft-ietf-lsr-flex-algo-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group P. Psenak, Ed. 3 Internet-Draft L. Ginsberg 4 Intended status: Standards Track Cisco Systems 5 Expires: February 20, 2020 W. Henderickx 6 Nokia 7 J. Tantsura 8 Apstra 9 J. Drake 10 Juniper Networks 11 August 19, 2019 13 OSPF Link Traffic Engineering (TE) Attribute Reuse 14 draft-ietf-ospf-te-link-attr-reuse-08.txt 16 Abstract 18 Various link attributes have been defined in OSPF in the context of 19 the MPLS Traffic Engineering (TE) and GMPLS. Many of these link 20 attributes can be used for applications other than MPLS Traffic 21 Engineering or GMPLS. This document defines how to distribute such 22 attributes in OSPFv2 and OSPFv3 for applications other than MPLS 23 Traffic Engineering or GMPLS. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 20, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 61 2. Advertisement of Link Attributes . . . . . . . . . . . . . . 3 62 2.1. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA . 3 63 3. Advertisement of Application Specific Values . . . . . . . . 4 64 4. Reused TE link attributes . . . . . . . . . . . . . . . . . . 7 65 4.1. Shared Risk Link Group (SRLG) . . . . . . . . . . . . . . 7 66 4.2. Extended Metrics . . . . . . . . . . . . . . . . . . . . 8 67 4.3. Administrative Group . . . . . . . . . . . . . . . . . . 9 68 4.4. Traffic Engineering Metric . . . . . . . . . . . . . . . 9 69 5. Maximum Link Bandwidth . . . . . . . . . . . . . . . . . . . 9 70 6. Local Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 10 71 7. Remote Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 10 72 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 73 9. Attribute Advertisements and Enablement . . . . . . . . . . . 11 74 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 12.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 12.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 80 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 81 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 15.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 15.2. Informative References . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 Various link attributes have been defined in OSPFv2 [RFC2328] and 89 OSPFv3 [RFC5340] in the context of the MPLS traffic engineering and 90 GMPLS. All these attributes are distributed by OSPFv2 as sub-TLVs of 91 the Link-TLV advertised in the OSPFv2 TE Opaque LSA [RFC3630]. In 92 OSPFv3, they are distributed as sub-TLVs of the Link-TLV advertised 93 in the OSPFv3 Intra-Area-TE-LSA as defined in [RFC5329]. 95 Many of these link attributes are useful outside of traditional MPLS 96 Traffic Engineering or GMPLS. This brings its own set of problems, 97 in particular how to distribute these link attributes in OSPFv2 and 98 OSPFv3 when MPLS TE and GMPLS are not deployed or are deployed in 99 parallel with other applications that use these link attributes. 101 [RFC7855] discusses use cases/requirements for Segment Routing. 102 Included among these use cases is SRTE. If both RSVP-TE and SRTE are 103 deployed in a network, link attribute advertisements can be used by 104 one or both of these applications. As there is no requirement for 105 the link attributes advertised on a given link used by SRTE to be 106 identical to the link attributes advertised on that same link used by 107 RSVP-TE, there is a clear requirement to indicate independently which 108 link attribute advertisements are to be used by each application. 110 As the number of applications which may wish to utilize link 111 attributes may grow in the future, an additional requirement is that 112 the extensions defined allow the association of additional 113 applications to link attributes without altering the format of the 114 advertisements or introducing new backwards compatibility issues. 116 Finally, there may still be many cases where a single attribute value 117 can be shared among multiple applications, so the solution should 118 minimize advertising duplicate link/attribute when possible. 120 1.1. Requirements notation 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. Advertisement of Link Attributes 128 This section outlines the solution for advertising link attributes 129 originally defined for MPLS Traffic Engineering or GMPLS when they 130 are used for other applications. 132 2.1. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA 134 Extended Link Opaque LSAs as defined in [RFC7684] for OSPFv2 and 135 Extended Router-LSAs [RFC8362] for OSPFv3 are used to advertise link 136 attributes that are used by applications other then MPLS traffic 137 engineering or GMPLS. These LSAs were defined as a generic 138 containers for distribution of the extended link attributes. There 139 are several advantages in using them: 141 1. Advertisement of the link attributes does not make the link part 142 of the TE topology. It avoids any conflicts and is fully 143 compatible with [RFC3630] and [RFC5329]. 145 2. The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA remains 146 truly opaque to OSPFv2 and OSPFv3 as originally defined in 147 [RFC3630] and [RFC5329] respectively. Their contents are not 148 inspected by OSPF, that acts as a pure transport. 150 3. There is clear distinction between link attributes used by TE and 151 link attributes used by other OSPFv2 or OSPFv3 applications. 153 4. All link attributes that are used by other applications are 154 advertised in a single LSA, the Extended Link Opaque LSA in 155 OSPFv2 or the OSPFv3 E-Router-LSA [RFC8362] in OSPFv3. 157 The disadvantage of this approach is that in rare cases, the same 158 link attribute is advertised in both the TE Opaque and Extended Link 159 Attribute LSAs in OSPFv2 or the Intra-Area-TE-LSA and E-Router-LSA in 160 OSPFv3. Additionally, there will be additional standardization 161 effort. However, this could also be viewed as an advantage as the 162 non-TE use cases for the TE link attributes are documented and 163 validated by the LSR working group. 165 It is RECOMMENDED to use the Extended Link Opaque LSA [RFC7684] and 166 E-Router-LSA [RFC8362] to advertise any link attributes used for non- 167 TE applications in OSPFv2 or OSPFv3 respectively, including those 168 that have been originally defined for TE applications. 170 It is also RECOMMENDED that TE link attributes used for RSVP-TE/GMPLS 171 continue to use OSPFv2 TE Opaque LSA [RFC3630] and OSPFv3 Intra-Area- 172 TE-LSA [RFC5329]. 174 The format of the link attribute TLVs that have been defined for TE 175 applications will be kept unchanged even when they are used for non- 176 TE applications. Unique code points will be allocated for these TE 177 link attribute TLVs from the OSPFv2 Extended Link TLV Sub-TLV 178 Registry [RFC7684] and from the OSPFv3 Extended LSA Sub-TLV Registry 179 [RFC8362]. For each reused TLV, the code point will be defined in an 180 IETF document along with the expected use-case(s). 182 3. Advertisement of Application Specific Values 184 To allow advertisement of the application specific values of the link 185 attribute, a new Application Specific Link Attributes (ASLA) sub-TLV 186 is defined. The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended 187 Link TLV [RFC7471] and OSPFv3 Router-Link TLV [RFC8362]. 189 The ASLA sub-TLV is an optional sub-TLV and can appear multiple times 190 in the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. It has 191 the following format: 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 | SABML | UDABML | Reserved | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Standard Application Bit-Mask | 201 +- -+ 202 | ... | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | User Defined Application Bit-Mask | 205 +- -+ 206 | ... | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Link Attribute sub-sub-TLVs | 209 +- -+ 210 | ... | 212 where: 214 Type: 10 (OSPFv2), TBD1 (OSPFv3) 216 Length: variable 218 SABML: Standard Application Bit-Mask Length. It MUST be a 219 multiple of 4 bytes. If the Standard Application Bit-Mask is not 220 present, the Standard Application Bit-Mask Length MUST be set to 221 0. 223 UDABML: User Defined Application Bit-Mask Length. It MUST be a 224 multiple of 4 bytes. If the User Defined Application Bit-Mask is 225 not present, the User Defined Application Bit-Mask Length MUST be 226 set to 0. 228 Standard Application Bit-Mask: Optional set of bits, where each 229 bit represents a single standard application. Bits are defined in 230 [I-D.ietf-isis-te-app], which also request a new IANA "Link 231 Attribute Applications" registry under "Interior Gateway Protocol 232 (IGP) Parameters" for them. The bits are repeated here for 233 informational purpose: 235 Bit-0: RSVP Traffic Engineering 237 Bit-1: Segment Routing Traffic Engineering 239 Bit-2: Loop Free Alternate (LFA). Includes all LFA types 240 Bit-3: Flexible Algorithm 242 User Defined Application Bit-Mask: Optional set of bits, where 243 each bit represents a single user defined application. 245 Standard Application Bits are defined/sent starting with Bit 0. 246 Additional bit definitions that are defined in the future SHOULD be 247 assigned in ascending bit order so as to minimize the number of 248 octets that will need to be transmitted. 250 User Defined Application bits have no relationship to Standard 251 Application bits and are NOT managed by IANA or any other standards 252 body. It is recommended that bits are used starting with Bit 0 so as 253 to minimize the number of octets required to advertise all of them. 255 Undefined bits in both Bit-Masks MUST be transmitted as 0 and MUST be 256 ignored on receipt. Bits that are NOT transmitted MUST be treated as 257 if they are set to 0 on receipt. 259 If the link attribute advertisement is limited to be used by a 260 specific set of applications, corresponding Bit-Masks MUST be present 261 and application specific bit(s) MUST be set for all applications that 262 use the link attributes advertised in the ASLA sub-TLV. 264 Application Bit-Masks apply to all link attributes that support 265 application specific values and are advertised in the ASLA sub-TLV. 267 The advantage of not making the Application Bit-Masks part of the 268 attribute advertisement itself is that we can keep the format of the 269 link attributes that have been defined previously and reuse the same 270 format when advertising them in the ASLA sub-TLV. 272 When neither the Standard Application Bits nor the User Defined 273 Application bits are set (i.e., both SABML and UDABML are 0) in the 274 ASLA sub-TLV, then the link attributes included in it MUST be 275 considered as being applicable to all applications. 277 If, however, another advertisement of the same link attribute 278 includes any Application Bit-Mask in the ASLA sub-TLV, applications 279 that are listed in the Application Bit-Masks of such ASLA sub-TLV 280 SHOULD use the attribute advertisement which has the application 281 specific bit set in the Application Bit-Masks. 283 If the same application is listed in the Application Bit-Masks of 284 more then one ASLA sub-TLV, the application SHOULD use the first 285 advertisement and ignore any subsequent advertisements of the same 286 attribute. This situation SHOULD be logged as an error. 288 This document defines the initial set of link attributes that MUST 289 use ASLA sub-TLV if advertised in the OSPFv2 Extended Link TLV or in 290 the OSPFv3 Router-Link TLV. If the ASLA sub-TLV includes any link 291 attribute(s) NOT listed below, they MUST be ignored. Documents which 292 define new link attributes MUST state whether the new attributes 293 support application specific values and as such MUST be advertised in 294 an ASLA sub-TLV. The link attributes that MUST be advertised in ASLA 295 sub-TLVs are: 297 - Shared Risk Link Group 299 - Unidirectional Link Delay 301 - Min/Max Unidirectional Link Delay 303 - Unidirectional Delay Variation 305 - Unidirectional Link Loss 307 - Unidirectional Residual Bandwidth 309 - Unidirectional Available Bandwidth 311 - Unidirectional Utilized Bandwidth 313 - Administrative Group 315 - Extended Administrative Group 317 - Traffic Engineering Metric 319 4. Reused TE link attributes 321 This section defines the use case and code points from the OSPFv2 322 Extended Link TLV Sub-TLV Registry and OSPFv3 Extended LSA Sub-TLV 323 Registry for some of the link attributes that have been originally 324 defined for TE or GMPLS. 326 4.1. Shared Risk Link Group (SRLG) 328 The SRLG of a link can be used in OSPF calculated IPFRR [RFC5714] to 329 compute a backup path that does not share any SRLG group with the 330 protected link. 332 To advertise the SRLG of the link in the OSPFv2 Extended Link TLV, 333 the same format for the sub-TLV defined in section 1.3 of [RFC4203] 334 is used and TLV type 11 is used. Similarly, for OSPFv3 to advertise 335 the SRLG in the OSPFv3 Router-Link TLV, TLV type TBD2 is used. 337 4.2. Extended Metrics 339 [RFC3630] defines several link bandwidth types. [RFC7471] defines 340 extended link metrics that are based on link bandwidth, delay and 341 loss characteristics. All these can be used to compute primary and 342 backup paths within an OSPF area to satisfy requirements for 343 bandwidth, delay (nominal or worst case) or loss. 345 To advertise extended link metrics in the OSPFv2 Extended Link TLV, 346 the same format for the sub-TLVs defined in [RFC7471] is used with 347 the following TLV types: 349 12 - Unidirectional Link Delay 351 13 - Min/Max Unidirectional Link Delay 353 14 - Unidirectional Delay Variation 355 15 - Unidirectional Link Loss 357 16 - Unidirectional Residual Bandwidth 359 17 - Unidirectional Available Bandwidth 361 18 - Unidirectional Utilized Bandwidth 363 To advertise extended link metrics in the OSPFv3 Extended LSA Router- 364 Link TLV, the same format for the sub-TLVs defined in [RFC7471] is 365 used with the following TLV types: 367 TBD3 - Unidirectional Link Delay 369 TBD4 - Min/Max Unidirectional Link Delay 371 TBD5 - Unidirectional Delay Variation 373 TBD6 - Unidirectional Link Loss 375 TBD7 - Unidirectional Residual Bandwidth 377 TBD8 - Unidirectional Available Bandwidth 379 TBD9 - Unidirectional Utilized Bandwidth 381 4.3. Administrative Group 383 [RFC3630] and [RFC7308] define the Administrative Group and Extended 384 Administrative Group sub-TLVs respectively. 386 One use case where advertisement of the Extended Administrative 387 Group(s) for a link is required is described in 388 [I-D.ietf-lsr-flex-algo]. 390 To advertise the Administrative Group and Extended Administrative 391 Group in the OSPFv2 Extended Link TLV, the same format for the sub- 392 TLVs defined in [RFC3630] and [RFC7308] is used with the following 393 TLV types: 395 19 - Administrative Group 397 20 - Extended Administrative Group 399 To advertise Administrative Group and Extended Administrative Group 400 in the OSPFv3 Router-Link TLV, the same format for the sub-TLVs 401 defined in [RFC3630] and [RFC7308] is used with the following TLV 402 types: 404 TBD10 - Administrative Group 406 TBD11 - Extended Administrative Group 408 4.4. Traffic Engineering Metric 410 [RFC3630] defines Traffic Engineering Metric. 412 To advertise the Traffic Engineering Metric in the OSPFv2 Extended 413 Link TLV, the same format for the sub-TLV defined in section 2.5.5 of 414 [RFC3630] is used and TLV type TBD12 is used. Similarly, for OSPFv3 415 to advertise the Traffic Engineering Metric in the OSPFv3 Router-Link 416 TLV, TLV type TBD13 is used. 418 5. Maximum Link Bandwidth 420 Maximum link bandwidth is an application independent attribute of the 421 link that is defined in [RFC3630]. Because it is an application 422 independent attribute, it MUST NOT be advertised in ASLA sub-TLV. 423 Instead, it MAY be advertised as a sub-TLV of the Extended Link 424 Opaque LSA Extended Link TLV in OSPFv2 [RFC7684] or sub-TLV of OSPFv3 425 E-Router-LSA Router-Link TLV in OSPFv3 [RFC8362]. 427 To advertise the Maximum link bandwidth in the OSPFv2 Extended Link 428 TLV, the same format for sub-TLV defined in [RFC3630] is used with 429 TLV type TBD14. 431 To advertise the Maximum link bandwidth in the OSPFv3 Router-Link 432 TLV, the same format for sub-TLV defined in [RFC3630] is used with 433 TLV type TBD15. 435 6. Local Interface IPv6 Address Sub-TLV 437 The Local Interface IPv6 Address Sub-TLV is an application 438 independent attribute of the link that is defined in [RFC5329]. 439 Because it is an application independent attribute, it MUST NOT be 440 advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a 441 sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV [RFC8362]. 443 To advertise the Local Interface IPv6 Address Sub-TLV in the OSPFv3 444 Router-Link TLV, the same format for sub-TLV defined in [RFC5329] is 445 used with TLV type TBD16. 447 7. Remote Interface IPv6 Address Sub-TLV 449 The Remote Interface IPv6 Address Sub-TLV is an application 450 independent attribute of the link that is defined in [RFC5329]. 451 Because it is an application independent attribute, it MUST NOT be 452 advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a 453 sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV [RFC8362]. 455 To advertise the Remote Interface IPv6 Address Sub-TLV in the OSPFv3 456 Router-Link TLV, the same format for sub-TLV defined in [RFC5329] is 457 used with TLV type TBD17. 459 8. Deployment Considerations 461 If link attributes are advertised associated with zero length 462 application bit masks for both standard applications and user defined 463 applications, then that set of link attributes MAY be used by any 464 application. If support for a new application is introduced on any 465 node in a network in the presence of such advertisements, these 466 advertisements MAY be used by the new application. If this is not 467 what is intended, then existing advertisements MUST be readvertised 468 with an explicit set of applications specified before a new 469 application is introduced. 471 9. Attribute Advertisements and Enablement 473 This document defines extensions to support the advertisement of 474 application specific link attributes. 476 Whether the presence of link attribute advertisements for a given 477 application indicates that the application is enabled on that link 478 depends upon the application. Similarly, whether the absence of link 479 attribute advertisements indicates that the application is not 480 enabled depends upon the application. 482 In the case of RSVP-TE, the advertisement of application specific 483 link attributes implies that RSVP is enabled on that link. 485 In the case of SRTE, advertisement of application specific link 486 attributes does NOT indicate enablement of SRTE. The advertisements 487 are only used to support constraints which may be applied when 488 specifying an explicit path. SRTE is implicitly enabled on all links 489 which are part of the Segment Routing enabled topology independent of 490 the existence of link attribute advertisements. 492 In the case of LFA, advertisement of application specific link 493 attributes does NOT indicate enablement of LFA on that link. 494 Enablement is controlled by local configuration. 496 In the case of Flexible Algorithm, advertisement of application 497 specific link attributes does NOT indicate enablement of Flexible 498 Algorithm on that link. Rather the attributes are used to determine 499 what links are included/excluded in the algorithm specific 500 constrained SPF. This is fully specified in 501 [I-D.ietf-lsr-flex-algo]. 503 If, in the future, additional standard applications are defined to 504 use this mechanism, the specification defining this use MUST define 505 the relationship between application specific link attribute 506 advertisements and enablement for that application. 508 This document allows the advertisement of application specific link 509 attributes with no application identifiers i.e., both the Standard 510 Application Bit Mask and the User Defined Application Bit Mask are 511 not present (See Section 3). This supports the use of the link 512 attribute by any application. In the presence of an application 513 where the advertisement of link attribute advertisements is used to 514 infer the enablement of an application on that link (e.g., RSVP-TE), 515 the absence of the application identifier leaves ambiguous whether 516 that application is enabled on such a link. This needs to be 517 considered when making use of the "any application" encoding. 519 10. Backward Compatibility 521 Link attributes may be concurrently advertised in both the TE Opaque 522 LSA and the Extended Link Opaque LSA in OSPFv2 and the OSPFv3 Intra- 523 Area-TE-LSA and OSPFv3 Extended LSA Router-Link TLV in OSPFv3. 525 In fact, there is at least one OSPF implementation that utilizes the 526 link attributes advertised in TE Opaque LSAs [RFC3630] for Non-RSVP 527 TE applications. For example, this implementation of LFA and remote 528 LFA utilizes links attributes such as Shared Risk Link Groups (SRLG) 529 [RFC4203] and Admin Group [[RFC3630] advertised in TE Opaque LSAs. 530 These applications are described in [RFC5286], [RFC7490], [RFC7916] 531 and [RFC8102]. 533 When an OSPF routing domain includes routers using link attributes 534 from the OSPFv2 TE Opaque LSAs or the OSPFv3 Intra-Area-TE-LSA for 535 Non-RSVP TE applications such as LFA, OSPF routers in that domain 536 SHOULD continue to advertise such OSPFv2 TE Opaque LSAs or the OSPFv3 537 Intra-Area-TE-LSA. If there are also OSPF routers using the link 538 attributes described herein for any other application, OSPF routers 539 in the routing domain will also need to advertise these attributes in 540 OSPFv2 Extended Link Attributes LSAs or OSPFv3 E-Router-LSA. In such 541 a deployment, the advertised attributes SHOULD be the same and Non- 542 RSVP application access to link attributes is a matter of local 543 policy. 545 11. Security Considerations 547 Existing security extensions as described in [RFC2328], [RFC5340] and 548 [RFC8362] apply to extensions defined in this document. While OSPF 549 is under a single administrative domain, there can be deployments 550 where potential attackers have access to one or more networks in the 551 OSPF routing domain. In these deployments, stronger authentication 552 mechanisms such as those specified in [RFC5709], [RFC7474], [RFC4552] 553 or [RFC7166] SHOULD be used. 555 Implementations MUST assure that malformed TLV and Sub-TLV defined in 556 this document are detected and do not provide a vulnerability for 557 attackers to crash the OSPF router or routing process. Reception of 558 a malformed TLV or Sub-TLV SHOULD be counted and/or logged for 559 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be 560 rate-limited to prevent a Denial of Service (DoS) attack (distributed 561 or otherwise) from overloading the OSPF control plane. 563 12. IANA Considerations 565 12.1. OSPFv2 567 OSPFv2 Extended Link TLV Sub-TLVs registry [RFC7684] defines sub-TLVs 568 at any level of nesting for OSPFv2 Extended Link TLVs. This 569 specification updates OSPFv2 Extended Link TLV sub-TLVs registry with 570 the following TLV types: 572 10 - Application Specific Link Attributes 574 11 - Shared Risk Link Group 576 12 - Unidirectional Link Delay 578 13 - Min/Max Unidirectional Link Delay 580 14 - Unidirectional Delay Variation 582 15 - Unidirectional Link Loss 584 16 - Unidirectional Residual Bandwidth 586 17 - Unidirectional Available Bandwidth 588 18 - Unidirectional Utilized Bandwidth 590 19 - Administrative Group 592 20 - Extended Administrative Group 594 TBD12 (22 Recommended) - Traffic Engineering Metric 596 TBD14 (21 Recommended) - Maximum Link Bandwidth 598 12.2. OSPFv3 600 OSPFv3 Extended LSA Sub-TLV Registry [RFC8362] defines sub-TLVs at 601 any level of nesting for OSPFv3 Extended LSAs. This specification 602 updates OSPFv3 Extended LSA Sub-TLV Registry with the following TLV 603 types: 605 TBD1 (10 Recommended) - Application Specific Link Attributes 607 TBD2 (11 Recommended) - Shared Risk Link Group 609 TBD3 (12 Recommended) - Unidirectional Link Delay 610 TBD4 (13 Recommended) - Min/Max Unidirectional Link Delay 612 TBD5 (14 Recommended) - Unidirectional Delay Variation 614 TBD6 (15 Recommended) - Unidirectional Link Loss 616 TBD7 (16 Recommended) - Unidirectional Residual Bandwidth 618 TBD8 (17 Recommended) - Unidirectional Available Bandwidth 620 TBD9 (18 Recommended) - Unidirectional Utilized Bandwidth 622 TBD10 (19 Recommended) - Administrative Group 624 TBD11 (20 Recommended) - Extended Administrative Group 626 TBD13 (21 Recommended) - Traffic Engineering Metric 628 TBD15 (22 Recommended) - Maximum Link Bandwidth 630 TBD16 (23 Recommended) - Local Interface IPv6 Address Sub-TLV 632 TBD17 (24 Recommended) - Local Interface IPv6 Address Sub-TLV 634 13. Contributors 636 The following people contributed to the content of this document and 637 should be considered as co-authors: 639 Acee Lindem 640 Cisco Systems 641 301 Midenhall Way 642 Cary, NC 27513 643 USA 645 Email: acee@cisco.com 647 Ketan Talaulikar 648 Cisco Systems, Inc. 649 India 651 Email: ketant@cisco.com 653 Hannes Gredler 654 RtBrick Inc. 655 Austria 657 Email: hannes@rtbrick.com 659 14. Acknowledgments 661 Thanks to Chris Bowers for his review and comments. 663 15. References 665 15.1. Normative References 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, 669 DOI 10.17487/RFC2119, March 1997, 670 . 672 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 673 (TE) Extensions to OSPF Version 2", RFC 3630, 674 DOI 10.17487/RFC3630, September 2003, 675 . 677 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 678 "Traffic Engineering Extensions to OSPF Version 3", 679 RFC 5329, DOI 10.17487/RFC5329, September 2008, 680 . 682 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 683 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 684 . 686 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 687 Traffic Engineering (MPLS-TE)", RFC 7308, 688 DOI 10.17487/RFC7308, July 2014, 689 . 691 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 692 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 693 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 694 2015, . 696 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 697 F. Baker, "OSPFv3 Link State Advertisement (LSA) 698 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 699 2018, . 701 15.2. Informative References 703 [I-D.ietf-isis-te-app] 704 Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 705 J. Drake, "IS-IS TE Attributes per application", draft- 706 ietf-isis-te-app-06 (work in progress), April 2019. 708 [I-D.ietf-lsr-flex-algo] 709 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 710 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 711 algo-03 (work in progress), July 2019. 713 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 714 DOI 10.17487/RFC2328, April 1998, 715 . 717 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 718 Support of Generalized Multi-Protocol Label Switching 719 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 720 . 722 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 723 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 724 . 726 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 727 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 728 DOI 10.17487/RFC5286, September 2008, 729 . 731 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 732 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 733 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 734 2009, . 736 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 737 RFC 5714, DOI 10.17487/RFC5714, January 2010, 738 . 740 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 741 Authentication Trailer for OSPFv3", RFC 7166, 742 DOI 10.17487/RFC7166, March 2014, 743 . 745 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 746 Previdi, "OSPF Traffic Engineering (TE) Metric 747 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 748 . 750 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 751 "Security Extension for OSPFv2 When Using Manual Key 752 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 753 . 755 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 756 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 757 RFC 7490, DOI 10.17487/RFC7490, April 2015, 758 . 760 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 761 Litkowski, S., Horneffer, M., and R. Shakir, "Source 762 Packet Routing in Networking (SPRING) Problem Statement 763 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 764 2016, . 766 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 767 Horneffer, M., and P. Sarkar, "Operational Management of 768 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 769 July 2016, . 771 [RFC8102] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and 772 S. Litkowski, "Remote-LFA Node Protection and 773 Manageability", RFC 8102, DOI 10.17487/RFC8102, March 774 2017, . 776 Authors' Addresses 778 Peter Psenak (editor) 779 Cisco Systems 780 Eurovea Centre, Central 3 781 Pribinova Street 10 782 Bratislava 81109 783 Slovakia 785 Email: ppsenak@cisco.com 787 Les Ginsberg 788 Cisco Systems 789 821 Alder Drive 790 MILPITAS, CA 95035 791 USA 793 Email: ginsberg@cisco.com 795 Wim Henderickx 796 Nokia 797 Copernicuslaan 50 798 Antwerp, 2018 94089 799 Belgium 801 Email: wim.henderickx@nokia.com 803 Jeff Tantsura 804 Apstra 805 US 807 Email: jefftant.ietf@gmail.com 809 John Drake 810 Juniper Networks 811 1194 N. Mathilda Ave 812 Sunnyvale, California 94089 813 USA 815 Email: jdrake@juniper.net