idnits 2.17.1 draft-ietf-isis-te-app-17.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 (June 17, 2020) is 1399 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg 3 Internet-Draft P. Psenak 4 Intended status: Standards Track Cisco Systems 5 Expires: December 19, 2020 S. Previdi 6 Huawei 7 W. Henderickx 8 Nokia 9 J. Drake 10 Juniper Networks 11 June 17, 2020 13 IS-IS TE Attributes per application 14 draft-ietf-isis-te-app-17 16 Abstract 18 Existing traffic engineering related link attribute advertisements 19 have been defined and are used in RSVP-TE deployments. Since the 20 original RSVP-TE use case was defined, additional applications (e.g., 21 Segment Routing Policy, Loop Free Alternate) that also make use of 22 the link attribute advertisements have been defined . In cases where 23 multiple applications wish to make use of these link attributes, the 24 current advertisements do not support application specific values for 25 a given attribute, nor do they support indication of which 26 applications are using the advertised value for a given link. This 27 document introduces new link attribute advertisements that address 28 both of these shortcomings. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 19, 2020. 55 Copyright Notice 57 Copyright (c) 2020 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Requirements Discussion . . . . . . . . . . . . . . . . . . . 4 74 3. Legacy Advertisements . . . . . . . . . . . . . . . . . . . . 5 75 3.1. Legacy sub-TLVs . . . . . . . . . . . . . . . . . . . . . 5 76 3.2. Legacy SRLG Advertisements . . . . . . . . . . . . . . . 6 77 4. Advertising Application Specific Link Attributes . . . . . . 6 78 4.1. Application Identifier Bit Mask . . . . . . . . . . . . . 6 79 4.2. Application Specific Link Attributes sub-TLV . . . . . . 9 80 4.2.1. Special Considerations for Maximum Link Bandwidth . . 10 81 4.2.2. Special Considerations for Reservable/Unreserved 82 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 10 83 4.2.3. Considerations for Extended TE Metrics . . . . . . . 11 84 4.3. Application Specific SRLG TLV . . . . . . . . . . . . . . 11 85 5. Attribute Advertisements and Enablement . . . . . . . . . . . 12 86 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 87 6.1. Use of Legacy Advertisements . . . . . . . . . . . . . . 13 88 6.2. Use of Zero Length Application Identifier Bit Masks . . . 14 89 6.3. Interoperability, Backwards Compatibility and Migration 90 Concerns . . . . . . . . . . . . . . . . . . . . . . . . 14 91 6.3.1. Multiple Applications: Common Attributes with RSVP- 92 TE . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 6.3.2. Multiple Applications: All Attributes Not Shared with 94 RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 15 95 6.3.3. Interoperability with Legacy Routers . . . . . . . . 15 96 6.3.4. Use of Application Specific Advertisements for RSVP- 97 TE . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 99 7.1. Application Specific Link Attributes sub-TLV . . . . . . 17 100 7.2. Application Specific SRLG TLV . . . . . . . . . . . . . . 17 101 7.3. Application Specific Link Attributes sub-sub-TLV Registry 17 102 7.4. Link Attribute Application Identifier Registry . . . . . 18 103 7.5. SRLG sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 19 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 108 10.2. Informative References . . . . . . . . . . . . . . . . . 21 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 111 1. Introduction 113 Advertisement of link attributes by the Intermediate-System-to- 114 Intermediate-System (IS-IS) protocol in support of traffic 115 engineering (TE) was introduced by [RFC5305] and extended by 116 [RFC5307], [RFC6119], [RFC7308], and [RFC8570]. Use of these 117 extensions has been associated with deployments supporting Traffic 118 Engineering over Multiprotocol Label Switching (MPLS) in the presence 119 of the Resource Reservation Protocol (RSVP) - more succinctly 120 referred to as RSVP-TE [RFC3209]. 122 For the purposes of this document an application is a technology that 123 makes use of link attribute advertisements - examples of which are 124 listed in Section 3. 126 In recent years new applications that have use cases for many of the 127 link attributes historically used by RSVP-TE have been introduced. 128 Such applications include Segment Routing Policy (SR Policy) 129 [I-D.ietf-spring-segment-routing-policy] and Loop Free Alternates 130 (LFA) [RFC5286]. This has introduced ambiguity in that if a 131 deployment includes a mix of RSVP-TE support and SR Policy support 132 (for example) it is not possible to unambiguously indicate which 133 advertisements are to be used by RSVP-TE and which advertisements are 134 to be used by SR Policy. If the topologies are fully congruent this 135 may not be an issue, but any incongruence leads to ambiguity. 137 An additional issue arises in cases where both applications are 138 supported on a link but the link attribute values associated with 139 each application differ. Current advertisements do not support 140 advertising application specific values for the same attribute on a 141 specific link. 143 This document defines extensions that address these issues. Also, as 144 evolution of use cases for link attributes can be expected to 145 continue in the years to come, this document defines a solution that 146 is easily extensible to the introduction of new applications and new 147 use cases. 149 2. Requirements Discussion 151 As stated previously, evolution of use cases for link attributes can 152 be expected to continue. Therefore, any discussion of existing use 153 cases is limited to requirements that are known at the time of this 154 writing. However, in order to determine the functionality required 155 beyond what already exists in IS-IS, it is only necessary to discuss 156 use cases that justify the key points identified in the introduction, 157 which are: 159 1. Support for indicating which applications are using the link 160 attribute advertisements on a link 162 2. Support for advertising application specific values for the same 163 attribute on a link 165 [RFC7855] discusses use cases/requirements for Segment Routing (SR). 166 Included among these use cases is SR Policy which is defined in 167 [I-D.ietf-spring-segment-routing-policy]. If both RSVP-TE and SR 168 Policy are deployed in a network, link attribute advertisements can 169 be used by one or both of these applications. As there is no 170 requirement for the link attributes advertised on a given link used 171 by SR Policy to be identical to the link attributes advertised on 172 that same link used by RSVP-TE, there is a clear requirement to 173 indicate independently which link attribute advertisements are to be 174 used by each application. 176 As the number of applications that may wish to utilize link 177 attributes may grow in the future, an additional requirement is that 178 the extensions defined allow the association of additional 179 applications to link attributes without altering the format of the 180 advertisements or introducing new backwards compatibility issues. 182 Finally, there may still be many cases where a single attribute value 183 can be shared among multiple applications, so the solution must 184 minimize advertising duplicate link/attribute pairs whenever 185 possible. 187 3. Legacy Advertisements 189 There are existing advertisements used in support of RSVP-TE. These 190 advertisements include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 191 223 and TLVs for Shared Risk Link Group (SRLG) advertisement. 193 Sub-TLV values are defined in the Sub-TLVs for TLVs 22, 23, 25, 141, 194 222, and 223 registry. 196 TLVs are defined in the TLV Codepoints Registry. 198 3.1. Legacy sub-TLVs 200 Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 202 +-------------------------------------------+ 203 | Type | Description | 204 +-------------------------------------------+ 205 | 3 | Administrative group (color) | 206 +-------------------------------------------+ 207 | 9 | Maximum link bandwidth | 208 +-------------------------------------------+ 209 | 10 | Maximum reservable link bandwidth | 210 +-------------------------------------------+ 211 | 11 | Unreserved bandwidth | 212 +-------------------------------------------+ 213 | 14 | Extended Administrative Group | 214 +-------------------------------------------+ 215 | 18 | TE Default Metric | 216 +-------------------------------------------+ 217 | 33 | Unidirectional Link Delay | 218 +-------------------------------------------+ 219 | 34 | Min/Max Unidirectional Link Delay | 220 +-------------------------------------------+ 221 | 35 | Unidirectional Delay Variation | 222 +-------------------------------------------+ 223 | 36 | Unidirectional Link Loss | 224 +-------------------------------------------+ 225 | 37 | Unidirectional Residual Bandwidth | 226 +-------------------------------------------+ 227 | 38 | Unidirectional Available Bandwidth | 228 +-------------------------------------------+ 229 | 39 | Unidirectional Utilized Bandwidth | 230 +-------------------------------------------+ 232 3.2. Legacy SRLG Advertisements 234 TLV 138 GMPLS-SRLG 235 Supports links identified by IPv4 addresses and 236 unnumbered links 238 TLV 139 IPv6 SRLG 239 Supports links identified by IPv6 addresses 241 Note that [RFC6119] prohibits the use of TLV 139 when it is possible 242 to use TLV 138. 244 4. Advertising Application Specific Link Attributes 246 Two new code points are defined in support of Application Specific 247 Link Attribute Advertisements: 249 1) Application Specific Link Attributes sub-TLV for TLVs 22, 23, 25, 250 141, 222, and 223 (defined in Section 4.2 ). 252 2)Application Specific Shared Risk Link Group (SRLG) TLV (defined in 253 Section 4.3). 255 In support of these new advertisements, an application identifier bit 256 mask is defined that identifies the application(s) associated with a 257 given advertisement (defined in Section 4.1). 259 In addition to supporting the advertisement of link attributes used 260 by standardized applications, link attributes can also be advertised 261 for use by user defined applications. Such applications are not 262 subject to standardization and are outside the scope of this 263 document. 265 The following sections define the format of these new advertisements. 267 4.1. Application Identifier Bit Mask 269 Identification of the set of applications associated with link 270 attribute advertisements utilizes two bit masks. One bit mask is for 271 standard applications where the definition of each bit is defined in 272 a new IANA controlled registry. A second bit mask is for non- 273 standard User Defined Applications (UDAs). 275 The encoding defined below is used by both the Application Specific 276 Link Attributes sub-TLV and the Application Specific SRLG TLV. 278 0 1 2 3 4 5 6 7 280 +--+--+--+--+--+--+--+--+ 281 | SABM Length + Flag | 1 octet 282 +--+--+--+--+--+--+--+--+ 283 | UDABM Length + Flag | 1 octet 284 +--+--+--+--+--+--+--+--+ 285 | SABM ... 0 - 8 octets 286 +--+--+--+--+--+--+--+--+ 287 | UDABM ... 0 - 8 octets 288 +--+--+--+--+--+--+--+--+ 290 SABM Length + Flag (1 octet) 291 Standard Application Identifier Bit Mask 292 Length + Flag 294 0 1 2 3 4 5 6 7 295 +-+-+-+-+-+-+-+-+ 296 |L| SABM Length | 297 +-+-+-+-+-+-+-+-+ 299 L-flag: Legacy Flag. 300 See Section 4.2 for a description of how 301 this flag is used. 303 SABM Length: Indicates the length in octets (0-8) of the 304 Standard Application Identifier Bit Mask. The length SHOULD 305 be the minimum required to send all bits that are set. 307 UDABM Length + Flag (1 octet) 308 User Defined Application Identifier Bit Mask 309 Length + Flag 311 0 1 2 3 4 5 6 7 312 +-+-+-+-+-+-+-+-+ 313 |R| UDABM Length| 314 +-+-+-+-+-+-+-+-+ 316 R: Reserved. SHOULD be transmitted as 0 and 317 MUST be ignored on receipt 319 UDABM Length: Indicates the length in octets (0-8) of the 320 User Defined Application Identifier Bit Mask. The length SHOULD 321 be the minimum required to send all bits that are set. 323 SABM (variable length) 324 Standard Application Identifier Bit Mask 326 (SABM Length * 8) bits 327 This field is omitted if SABM Length is 0. 329 0 1 2 3 4 5 6 7 ... 330 +-+-+-+-+-+-+-+-+... 331 |R|S|F| ... 332 +-+-+-+-+-+-+-+-+... 334 R-bit: Set to specify RSVP-TE 336 S-bit: Set to specify Segment Routing Policy 338 F-bit: Set to specify Loop Free Alternate (LFA) 339 (includes all LFA types) 341 UDABM (variable length) 342 User Defined Application Identifier Bit Mask 344 (UDABM Length * 8) bits 346 0 1 2 3 4 5 6 7 ... 347 +-+-+-+-+-+-+-+-+... 348 | ... 349 +-+-+-+-+-+-+-+-+... 351 This field is omitted if UDABM Length is 0. 353 NOTE: SABM/UDABM Length is arbitrarily limited to 8 octets in order 354 to insure that sufficient space is left to advertise link attributes 355 without overrunning the maximum length of a sub-TLV. 357 Standard Application Identifier Bits are defined/sent starting with 358 Bit 0. 360 User Defined Application Identifier Bits have no relationship to 361 Standard Application Identifier Bits and are not managed by IANA or 362 any other standards body. It is recommended that bits are used 363 starting with Bit 0 so as to minimize the number of octets required 364 to advertise all UDAs. 366 In the case of both SABM and UDABM, the following rules apply: 368 o Undefined bits that are transmitted MUST be transmitted as 0 and 369 MUST be ignored on receipt 371 o Bits that are not transmitted MUST be treated as if they are set 372 to 0 on receipt. 374 o Bits that are not supported by an implementation MUST be ignored 375 on receipt. 377 . 379 4.2. Application Specific Link Attributes sub-TLV 381 A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined that 382 supports specification of the applications and application specific 383 attribute values. 385 Type: 16 (temporarily assigned by IANA) 386 Length: Variable (1 octet) 387 Value: 389 Application Identifier Bit Mask 390 (as defined in Section 4.1) 392 Link Attribute sub-sub-TLVs - format matches the 393 existing formats defined in [RFC5305], [RFC7308], 394 and [RFC8570] 396 If the SABM or UDABM length in the Application Identifier Bit Mask is 397 greater than 8, the entire sub-TLV MUST be ignored. 399 When the L-flag is set in the Application Identifier Bit Mask, all of 400 the applications specified in the bit mask MUST use the legacy 401 advertisements for the corresponding link found in TLVs 22, 23, 25, 402 141, 222, and 223 or TLV 138 or TLV 139 as appropriate. Link 403 attribute sub-sub-TLVs for the corresponding link attributes MUST NOT 404 be advertised for the set of applications specified in the Standard/ 405 User Application Identifier Bit Masks and all such advertisements 406 MUST be ignored on receipt. 408 Multiple Application Specific Link Attribute sub-TLVs for the same 409 link MAY be advertised. When multiple sub-TLVs for the same link are 410 advertised, they SHOULD advertise non-conflicting application/ 411 attribute pairs. A conflict exists when the same application is 412 associated with two different values of the same link attribute for a 413 given link. In cases where conflicting values for the same 414 application/attribute/link are advertised all the conflicting values 415 MUST be ignored by the specified application. 417 For a given application, the setting of the L-flag MUST be the same 418 in all sub-TLVs for a given link. In cases where this constraint is 419 violated, the L-flag MUST be considered set for this application. 421 If link attributes are advertised associated with zero length 422 Application Identifier Bit Masks for both standard applications and 423 user defined applications, then any Standard Application and/or any 424 User Defined Application is permitted to use that set of link 425 attributes so long as there is not another set of attributes 426 advertised on that same link that is associated with a non-zero 427 length Application Identifier Bit Mask with a matching Application 428 Identifier Bit set. 430 A new registry of sub-sub-TLVs is to be created by IANA that defines 431 the link attribute sub-sub-TLV code points. This document defines a 432 sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1 433 except as noted below. The format of the sub-sub-TLVs matches the 434 format of the corresponding legacy sub-TLV and IANA is requested to 435 assign the legacy sub-TLV identifier to the corresponding sub-sub- 436 TLV. 438 4.2.1. Special Considerations for Maximum Link Bandwidth 440 Maximum link bandwidth is an application independent attribute of the 441 link. When advertised using the Application Specific Link Attributes 442 sub-TLV, multiple values for the same link MUST NOT be advertised. 443 This can be accomplished most efficiently by having a single 444 advertisement for a given link where the Application Identifier Bit 445 Mask identifies all the applications that are making use of the value 446 for that link. 448 It is also possible to advertise the same value for a given link 449 multiple times with disjoint sets of applications specified in the 450 Application Identifier Bit Mask. This is less efficient but still 451 valid. 453 It is also possible to advertise a single advertisement with zero 454 length SABM and UDABM so long as the constraints discussed in 455 Section 4.2 and Section 6.2 are acceptable. 457 If different values for Maximum Link Bandwidth for a given link are 458 advertised, all values MUST be ignored. 460 4.2.2. Special Considerations for Reservable/Unreserved Bandwidth 462 Maximum Reservable Link Bandwidth and Unreserved Bandwidth are 463 attributes specific to RSVP-TE. When advertised using the 464 Application Specific Link Attributes sub-TLV, bits other than the 465 RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit 466 Mask. If an advertisement of Maximum Reservable Link Bandwidth or 467 Unreserved Bandwidth is received with bits other than the RSVP-TE bit 468 set, the advertisement MUST be ignored. 470 4.2.3. Considerations for Extended TE Metrics 472 [RFC8570] defines a number of dynamic performance metrics associated 473 with a link. It is conceivable that such metrics could be measured 474 specific to traffic associated with a specific application. 475 Therefore this document includes support for advertising these link 476 attributes specific to a given application. However, in practice it 477 may well be more practical to have these metrics reflect the 478 performance of all traffic on the link regardless of application. In 479 such cases, advertisements for these attributes will be associated 480 with all of the applications utilizing that link. This can be done 481 either by explicitly specifying the applications in the Application 482 Identifier Bit Mask or by using a zero length Application Identifier 483 Bit Mask. 485 4.3. Application Specific SRLG TLV 487 A new TLV is defined to advertise application specific SRLGs for a 488 given link. Although similar in functionality to TLV 138 [RFC5307] 489 and TLV 139 [RFC6119], a single TLV provides support for IPv4, IPv6, 490 and unnumbered identifiers for a link. Unlike TLVs 138/139, it 491 utilizes sub-TLVs to encode the link identifiers in order to provide 492 the flexible formatting required to support multiple link identifier 493 types. 495 Type: 238 (Temporarily assigned by IANA) 496 Length: Number of octets in the value field (1 octet) 497 Value: 498 Neighbor System-ID + pseudo-node ID (7 octets) 499 Application Identifier Bit Mask 500 (as defined in Section 4.1) 501 Length of sub-TLVs (1 octet) 502 Link Identifier sub-TLVs (variable) 503 0 or more SRLG Values (Each value is 4 octets) 505 The following Link Identifier sub-TLVs are defined. 506 The values chosen are intentionally matching the equivalent 507 sub-TLVs from [RFC5305], [RFC5307], and [RFC6119]. 509 Type Description 510 4 Link Local/Remote Identifiers [RFC5307] 511 6 IPv4 interface address [RFC5305] 512 8 IPv4 neighbor address [RFC5305] 513 12 IPv6 Interface Address [RFC6119] 514 13 IPv6 Neighbor Address [RFC6119] 516 At least one set of link identifiers (IPv4, IPv6, or Link Local/ 517 Remote) MUST be present. Multiple occurrences of the same identifier 518 type MUST NOT be present. TLVs that do not meet this requirement 519 MUST be ignored. 521 Multiple TLVs for the same link MAY be advertised. 523 When the L-flag is set in the Application Identifier Bit Mask, SRLG 524 values MUST NOT be included in the TLV. Any SRLG values that are 525 advertised MUST be ignored. Based on the link identifiers advertised 526 the corresponding legacy TLV (see Section 3.2) can be identified and 527 the SRLG values advertised in the legacy TLV MUST be used by the set 528 of applications specified in the Application Identifier Bit Mask. 530 For a given application, the setting of the L-flag MUST be the same 531 in all TLVs for a given link. In cases where this constraint is 532 violated, the L-flag MUST be considered set for this application. 534 5. Attribute Advertisements and Enablement 536 This document defines extensions to support the advertisement of 537 application specific link attributes. 539 Whether the presence of link attribute advertisements for a given 540 application indicates that the application is enabled on that link 541 depends upon the application. Similarly, whether the absence of link 542 attribute advertisements indicates that the application is not 543 enabled depends upon the application. 545 In the case of RSVP-TE, the advertisement of application specific 546 link attributes implies that RSVP is enabled on that link. The 547 absence of RSVP-TE application specific link attributes in 548 combination with the absence of legacy advertisements implies that 549 RSVP is not enabled on that link. 551 In the case of SR Policy, advertisement of application specific link 552 attributes does not indicate enablement of SR Policy on that link. 553 The advertisements are only used to support constraints that may be 554 applied when specifying an explicit path. SR Policy is implicitly 555 enabled on all links that are part of the Segment Routing enabled 556 topology independent of the existence of link attribute 557 advertisements. 559 In the case of LFA, advertisement of application specific link 560 attributes does not indicate enablement of LFA on that link. 561 Enablement is controlled by local configuration. 563 If, in the future, additional standard applications are defined to 564 use this mechanism, the specification defining this use MUST define 565 the relationship between application specific link attribute 566 advertisements and enablement for that application. 568 This document allows the advertisement of application specific link 569 attributes with no application identifiers i.e., both the Standard 570 Application Identifier Bit Mask and the User Defined Application 571 Identifier Bit Mask are not present (See Section 4.1). This supports 572 the use of the link attribute by any application. In the presence of 573 an application where the advertisement of link attribute 574 advertisements is used to infer the enablement of an application on 575 that link (e.g., RSVP-TE), the absence of the application identifier 576 leaves ambiguous whether that application is enabled on such a link. 577 This needs to be considered when making use of the "any application" 578 encoding. 580 6. Deployment Considerations 582 This section discuss deployment considerations associated with the 583 use of application specific link attribute advertisements. 585 6.1. Use of Legacy Advertisements 587 Bit Identifiers for Standard Applications are defined in Section 4.1. 588 All of the identifiers defined in this document are associated with 589 applications that were already deployed in some networks prior to the 590 writing of this document. Therefore, such applications have been 591 deployed using the legacy advertisements. The Standard Applications 592 defined in this document may continue to use legacy advertisements 593 for a given link so long as at least one of the following conditions 594 is true: 596 o The application is RSVP-TE 598 o The application is SR Policy or LFA and RSVP-TE is not deployed 599 anywhere in the network 601 o The application is SR Policy or LFA, RSVP-TE is deployed in the 602 network, and both the set of links on which SR Policy and/or LFA 603 advertisements are required and the attribute values used by SR 604 Policy and/or LFA on all such links is fully congruent with the 605 links and attribute values used by RSVP-TE 607 Under the conditions defined above, implementations that support the 608 extensions defined in this document have the choice of using legacy 609 advertisements or application specific advertisements in support of 610 SR Policy and/or LFA. This will require implementations to provide 611 controls specifying which type of advertisements are to be sent/ 612 processed on receive for these applications. Further discussion of 613 the associated issues can be found in Section 6.3. 615 New applications that future documents define to make use of the 616 advertisements defined in this document MUST NOT make use of legacy 617 advertisements. This simplifies deployment of new applications by 618 eliminating the need to support multiple ways to advertise attributes 619 for the new applications. 621 6.2. Use of Zero Length Application Identifier Bit Masks 623 Link attribute advertisements associated with zero length Application 624 Identifier Bit Masks for both standard applications and user defined 625 applications are usable by any application, subject to the 626 restrictions specified in Section 4.2. If support for a new 627 application is introduced on any node in a network in the presence of 628 such advertisements, these advertisements are permitted to be used by 629 the new application. If this is not what is intended, then existing 630 advertisements MUST be readvertised with an explicit set of 631 applications specified before a new application is introduced. 633 6.3. Interoperability, Backwards Compatibility and Migration Concerns 635 Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the 636 legacy advertisements listed in Section 3. Routers that do not 637 support the extensions defined in this document will only process 638 legacy advertisements and are likely to infer that RSVP-TE is enabled 639 on the links for which legacy advertisements exist. It is expected 640 that deployments using the legacy advertisements will persist for a 641 significant period of time. Therefore deployments using the 642 extensions defined in this document in the presence of routers that 643 do not support these extensions need to be able to interoperate with 644 the use of legacy advertisements by the legacy routers. The 645 following sub-sections discuss interoperability and backwards 646 compatibility concerns for a number of deployment scenarios. 648 6.3.1. Multiple Applications: Common Attributes with RSVP-TE 650 In cases where multiple applications are utilizing a given link, one 651 of the applications is RSVP-TE, and all link attributes for a given 652 link are common to the set of applications utilizing that link, 653 interoperability is achieved by using legacy advertisements and 654 sending application specific advertisements with L-flag set and no 655 link attribute values. This avoids duplication of link attribute 656 advertisements. 658 6.3.2. Multiple Applications: All Attributes Not Shared with RSVP-TE 660 In cases where one or more applications other than RSVP-TE are 661 utilizing a given link and one or more link attribute values are not 662 shared with RSVP-TE, it is necessary to use application specific 663 advertisements as defined in this document. Attributes for 664 applications other than RSVP-TE MUST be advertised using application 665 specific advertisements that have the L-flag clear. In cases where 666 some link attributes are shared with RSVP-TE, this requires duplicate 667 advertisements for those attributes. 669 These guidelines apply to cases where RSVP-TE is not using any 670 advertised attributes on a link and to cases where RSVP-TE is using 671 some link attribute advertisements on the link but some link 672 attributes cannot be shared with RSVP-TE. 674 6.3.3. Interoperability with Legacy Routers 676 For the applications defined in this document, routers that do not 677 support the extensions defined in this document will send and receive 678 only legacy link attribute advertisements. So long as there is any 679 legacy router in the network that has any of the applications 680 enabled, all routers MUST continue to advertise link attributes using 681 legacy advertisements. In addition, the link attribute values 682 associated with the set of applications supported by legacy routers 683 (RSVP-TE, SR Policy, and/or LFA) are always shared since legacy 684 routers have no way of advertising or processing application specific 685 values. Once all legacy routers have been upgraded, migration from 686 legacy advertisements to application specific advertisements can be 687 achieved via the following steps: 689 1)Send application specific advertisements while continuing to 690 advertise using legacy (all advertisements are then duplicated). 691 Receiving routers continue to use legacy advertisements. 693 2)Enable the use of the application specific advertisements on all 694 routers 696 3)Remove legacy advertisements 698 When the migration is complete, it then becomes possible to advertise 699 incongruent values per application on a given link. 701 Note that the use of the L-flag is of no value in the migration. 703 Documents defining new applications that make use of the application 704 specific advertisements defined in this document MUST discuss 705 interoperability and backwards compatibility issues that could occur 706 in the presence of routers that do not support the new application. 708 6.3.4. Use of Application Specific Advertisements for RSVP-TE 710 The extensions defined in this document support RSVP-TE as one of the 711 supported applications. This allows that RSVP-TE could eventually 712 utilize the application specific advertisements. This can be done in 713 the following step-wise manner: 715 1)Upgrade all routers to support the extensions in this document 717 2)Advertise all legacy link attributes using application specific 718 advertisements with L-flag clear and R-bit set. At this point both 719 legacy and application specific advertisements are being sent. 721 3)Remove legacy advertisements 723 7. IANA Considerations 725 This section lists the protocol code point changes introduced by this 726 document and the related IANA changes required. 728 For new registries defined under IS-IS TLV Codepoints Registry with 729 registration procedure "Expert Review", guidance for designated 730 experts can be found in [RFC7370]. 732 7.1. Application Specific Link Attributes sub-TLV 734 This document defines a new sub-TLV in the Sub-TLVs for TLVs 22, 23, 735 25, 141, 222, and 223 registry. See Section 4.2 737 Type Description 22 23 25 141 222 223 738 ---- --------------------- ---- ---- ---- ---- ---- ---- 739 16 Application Specific y y y(s) y y y 740 Link Attributes 742 7.2. Application Specific SRLG TLV 744 This document defines one new TLV in the IS-IS TLV Codepoints 745 Registry. See Section 4.3 747 Type Description IIH LSP SNP Purge 748 ---- --------------------- --- --- --- ----- 749 238 Application Specific n y n n 750 SRLG 752 7.3. Application Specific Link Attributes sub-sub-TLV Registry 754 This document requests a new IANA registry under the IS-IS TLV 755 Codepoints Registry be created to control the assignment of sub-sub- 756 TLV codepoints for the Application Specific Link Attributes sub-TLV 757 defined in Section 7.1. The suggested name of the new registry is 758 "sub-sub-TLV code points for application specific link attributes". 759 The registration procedure is "Expert Review" as defined in 760 [RFC8126]. The following assignments are made by this document: 762 Type Description Encoding 763 Reference 764 --------------------------------------------------------- 765 0-2 Unassigned 766 3 Administrative group (color) RFC5305 767 4-8 Unassigned 768 9 Maximum link bandwidth RFC5305 769 10 Maximum reservable link bandwidth RFC5305 770 11 Unreserved bandwidth RFC5305 771 12-13 Unassigned 772 14 Extended Administrative Group RFC7308 773 15-17 Unassigned 774 18 TE Default Metric RFC5305 775 19-32 Unassigned 776 33 Unidirectional Link Delay RFC8570 777 34 Min/Max Unidirectional Link Delay RFC8570 778 35 Unidirectional Delay Variation RFC8570 779 36 Unidirectional Link Loss RFC8570 780 37 Unidirectional Residual Bandwidth RFC8570 781 38 Unidirectional Available Bandwidth RFC8570 782 39 Unidirectional Utilized Bandwidth RFC8570 783 40-255 Unassigned 785 Note to IANA: For future codepoints, in cases where the document that 786 defines the encoding is different from the document that assigns the 787 codepoint, the encoding reference MUST be to the document that 788 defines the encoding. 790 Note to designated experts: If a link attribute can be advertised 791 both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub- 792 sub-TLV of the Application Specific Link Attributes sub-TLV defined 793 in this document, then the same numerical code should be assigned to 794 the link attribute whenever possible. 796 7.4. Link Attribute Application Identifier Registry 798 This document requests a new IANA registry be created, under the 799 category of "Interior Gateway Protocol (IGP) Parameters", to control 800 the assignment of Application Identifier Bits. The suggested name of 801 the new registry is "Link Attribute Applications". The registration 802 policy for this registry is "Expert Review" [RFC8126]. Bit 803 definitions SHOULD be assigned such that all bits in the lowest 804 available octet are allocated before assigning bits in the next 805 octet. This minimizes the number of octets that will need to be 806 transmitted. The following assignments are made by this document: 808 Bit # Name 809 --------------------------------------------------------- 810 0 RSVP-TE (R-bit) 811 1 Segment Routing Policy (S-bit) 812 2 Loop Free Alternate (F-bit) 813 3-63 Unassigned 815 7.5. SRLG sub-TLVs 817 This document requests a new IANA registry be created under the IS-IS 818 TLV Codepoints Registry to control the assignment of sub-TLV types 819 for the application specific SRLG TLV. The suggested name of the new 820 registry is "Sub-TLVs for TLV 238". The registration procedure is 821 "Expert Review" as defined in [RFC8126]. The following assignments 822 are made by this document: 824 Value Description Encoding 825 Reference 826 --------------------------------------------------------- 827 0-3 Unassigned 828 4 Link Local/Remote Identifiers [RFC5307] 829 5 Unassigned 830 6 IPv4 interface address [RFC5305] 831 7 Unassigned 832 8 IPv4 neighbor address [RFC5305] 833 9-11 Unassigned 834 12 IPv6 Interface Address [RFC6119] 835 13 IPv6 Neighbor Address [RFC6119] 836 14-255 Unassigned 838 Note to IANA: For future codepoints, in cases where the document that 839 defines the encoding is different from the document that assigns the 840 codepoint, the encoding reference MUST be to the document that 841 defines the encoding. 843 8. Security Considerations 845 Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], 846 and [RFC5310]. While IS-IS is deployed under a single administrative 847 domain, there can be deployments where potential attackers have 848 access to one or more networks in the IS-IS routing domain. In these 849 deployments, the stronger authentication mechanisms defined in the 850 aforementioned documents SHOULD be used. 852 This document defines a new way to advertise link attributes. 853 Tampering with the information defined in this document may have an 854 effect on applications using it, including impacting Traffic 855 Engineering as discussed in [RFC8570]. As the advertisements defined 856 in this document limit the scope to specific applications, the impact 857 of tampering is similarly limited in scope. 859 9. Acknowledgements 861 The authors would like to thank Eric Rosen and Acee Lindem for their 862 careful review and content suggestions. 864 10. References 866 10.1. Normative References 868 [ISO10589] 869 International Organization for Standardization, 870 "Intermediate system to Intermediate system intra-domain 871 routeing information exchange protocol for use in 872 conjunction with the protocol for providing the 873 connectionless-mode Network Service (ISO 8473)", ISO/ 874 IEC 10589:2002, Second Edition, Nov 2002. 876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", BCP 14, RFC 2119, 878 DOI 10.17487/RFC2119, March 1997, 879 . 881 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 882 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 883 2008, . 885 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 886 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 887 2008, . 889 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 890 in Support of Generalized Multi-Protocol Label Switching 891 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 892 . 894 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 895 and M. Fanto, "IS-IS Generic Cryptographic 896 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 897 2009, . 899 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 900 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 901 February 2011, . 903 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 904 Traffic Engineering (MPLS-TE)", RFC 7308, 905 DOI 10.17487/RFC7308, July 2014, 906 . 908 [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints 909 Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, 910 . 912 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 913 Writing an IANA Considerations Section in RFCs", BCP 26, 914 RFC 8126, DOI 10.17487/RFC8126, June 2017, 915 . 917 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 918 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 919 May 2017, . 921 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 922 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 923 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 924 2019, . 926 10.2. Informative References 928 [I-D.ietf-spring-segment-routing-policy] 929 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 930 P. Mattes, "Segment Routing Policy Architecture", draft- 931 ietf-spring-segment-routing-policy-07 (work in progress), 932 May 2020. 934 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 935 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 936 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 937 . 939 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 940 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 941 DOI 10.17487/RFC5286, September 2008, 942 . 944 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 945 Litkowski, S., Horneffer, M., and R. Shakir, "Source 946 Packet Routing in Networking (SPRING) Problem Statement 947 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 948 2016, . 950 Authors' Addresses 952 Les Ginsberg 953 Cisco Systems 954 821 Alder Drive 955 Milpitas, CA 95035 956 USA 958 Email: ginsberg@cisco.com 960 Peter Psenak 961 Cisco Systems 962 Apollo Business Center Mlynske nivy 43 963 Bratislava 821 09 964 Slovakia 966 Email: ppsenak@cisco.com 968 Stefano Previdi 969 Huawei 971 Email: stefano@previdi.net 973 Wim Henderickx 974 Nokia 975 Copernicuslaan 50 976 Antwerp 2018 94089 977 Belgium 979 Email: wim.henderickx@nokia.com 981 John Drake 982 Juniper Networks 984 Email: jdrake@juniper.net