idnits 2.17.1 draft-ietf-isis-te-app-19.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 29, 2020) is 1368 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 31, 2020 S. Previdi 6 Huawei 7 W. Henderickx 8 Nokia 9 J. Drake 10 Juniper Networks 11 June 29, 2020 13 IS-IS Application-Specific Link Attributes 14 draft-ietf-isis-te-app-19 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 31, 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 . . . . . . 7 78 4.1. Application Identifier Bit Mask . . . . . . . . . . . . . 7 79 4.2. Application-Specific Link Attributes sub-TLV . . . . . . 9 80 4.2.1. Special Considerations for Maximum Link Bandwidth . . 11 81 4.2.2. Special Considerations for Reservable/Unreserved 82 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 11 83 4.2.3. Considerations for Extended TE Metrics . . . . . . . 11 84 4.3. Application-Specific SRLG TLV . . . . . . . . . . . . . . 12 85 5. Attribute Advertisements and Enablement . . . . . . . . . . . 13 86 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 87 6.1. Use of Legacy Advertisements . . . . . . . . . . . . . . 14 88 6.2. Use of Zero Length Application Identifier Bit Masks . . . 15 89 6.3. Interoperability, Backwards Compatibility and Migration 90 Concerns . . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . 16 96 6.3.4. Use of Application-Specific Advertisements for RSVP- 97 TE . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 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 example where this ambiguity causes a problem is a network where 138 RSVP-TE is enabled only on a subset of its links. A link attribute 139 is advertised for the purpose of another application (e.g. SR 140 Policy) for a link that is not enabled for RSVP-TE. As soon as the 141 router that is an RSVP-TE head-end sees the link attribute being 142 advertised for that link, it assumes RSVP-TE is enabled on that link, 143 even though it is not. If such RSVP-TE head-end router tries to 144 setup an RSVP-TE path via that link, it will result in a path setup 145 failure. 147 An additional issue arises in cases where both applications are 148 supported on a link but the link attribute values associated with 149 each application differ. Current advertisements do not support 150 advertising application-specific values for the same attribute on a 151 specific link. 153 This document defines extensions that address these issues. Also, as 154 evolution of use cases for link attributes can be expected to 155 continue in the years to come, this document defines a solution that 156 is easily extensible to the introduction of new applications and new 157 use cases. 159 2. Requirements Discussion 161 As stated previously, evolution of use cases for link attributes can 162 be expected to continue. Therefore, any discussion of existing use 163 cases is limited to requirements that are known at the time of this 164 writing. However, in order to determine the functionality required 165 beyond what already exists in IS-IS, it is only necessary to discuss 166 use cases that justify the key points identified in the introduction, 167 which are: 169 1. Support for indicating which applications are using the link 170 attribute advertisements on a link 172 2. Support for advertising application-specific values for the same 173 attribute on a link 175 [RFC7855] discusses use cases/requirements for Segment Routing (SR). 176 Included among these use cases is SR Policy which is defined in 177 [I-D.ietf-spring-segment-routing-policy]. If both RSVP-TE and SR 178 Policy are deployed in a network, link attribute advertisements can 179 be used by one or both of these applications. As there is no 180 requirement for the link attributes advertised on a given link used 181 by SR Policy to be identical to the link attributes advertised on 182 that same link used by RSVP-TE, there is a clear requirement to 183 indicate independently which link attribute advertisements are to be 184 used by each application. 186 As the number of applications that may wish to utilize link 187 attributes may grow in the future, an additional requirement is that 188 the extensions defined allow the association of additional 189 applications to link attributes without altering the format of the 190 advertisements or introducing new backwards compatibility issues. 192 Finally, there may still be many cases where a single attribute value 193 can be shared among multiple applications, so the solution must 194 minimize advertising duplicate link/attribute pairs whenever 195 possible. 197 3. Legacy Advertisements 199 There are existing advertisements used in support of RSVP-TE. These 200 advertisements include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 201 223 and TLVs for Shared Risk Link Group (SRLG) advertisement. 203 Sub-TLV values are defined in the Sub-TLVs for TLVs 22, 23, 25, 141, 204 222, and 223 registry. 206 TLVs are defined in the TLV Codepoints Registry. 208 3.1. Legacy sub-TLVs 209 Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 211 +-------------------------------------------+ 212 | Type | Description | 213 +-------------------------------------------+ 214 | 3 | Administrative group (color) | 215 +-------------------------------------------+ 216 | 9 | Maximum link bandwidth | 217 +-------------------------------------------+ 218 | 10 | Maximum reservable link bandwidth | 219 +-------------------------------------------+ 220 | 11 | Unreserved bandwidth | 221 +-------------------------------------------+ 222 | 14 | Extended Administrative Group | 223 +-------------------------------------------+ 224 | 18 | TE Default Metric | 225 +-------------------------------------------+ 226 | 33 | Unidirectional Link Delay | 227 +-------------------------------------------+ 228 | 34 | Min/Max Unidirectional Link Delay | 229 +-------------------------------------------+ 230 | 35 | Unidirectional Delay Variation | 231 +-------------------------------------------+ 232 | 36 | Unidirectional Link Loss | 233 +-------------------------------------------+ 234 | 37 | Unidirectional Residual Bandwidth | 235 +-------------------------------------------+ 236 | 38 | Unidirectional Available Bandwidth | 237 +-------------------------------------------+ 238 | 39 | Unidirectional Utilized Bandwidth | 239 +-------------------------------------------+ 241 3.2. Legacy SRLG Advertisements 243 TLV 138 GMPLS-SRLG 244 Supports links identified by IPv4 addresses and 245 unnumbered links 247 TLV 139 IPv6 SRLG 248 Supports links identified by IPv6 addresses 250 Note that [RFC6119] prohibits the use of TLV 139 when it is possible 251 to use TLV 138. 253 4. Advertising Application-Specific Link Attributes 255 Two new code points are defined in support of Application-Specific 256 Link Attribute (ASLA) Advertisements: 258 1) ASLA sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 (defined in 259 Section 4.2 ). 261 2)Application-Specific Shared Risk Link Group (SRLG) TLV (defined in 262 Section 4.3). 264 In support of these new advertisements, an application identifier bit 265 mask is defined that identifies the application(s) associated with a 266 given advertisement (defined in Section 4.1). 268 In addition to supporting the advertisement of link attributes used 269 by standardized applications, link attributes can also be advertised 270 for use by user defined applications. Such applications are not 271 subject to standardization and are outside the scope of this 272 document. 274 The following sections define the format of these new advertisements. 276 4.1. Application Identifier Bit Mask 278 Identification of the set of applications associated with link 279 attribute advertisements utilizes two bit masks. One bit mask is for 280 standard applications where the definition of each bit is defined in 281 a new IANA controlled registry. A second bit mask is for non- 282 standard User Defined Applications (UDAs). 284 The encoding defined below is used by both the Application-Specific 285 Link Attributes sub-TLV and the Application-Specific SRLG TLV. 287 0 1 2 3 4 5 6 7 288 +--+--+--+--+--+--+--+--+ 289 | SABM Length + Flag | 1 octet 290 +--+--+--+--+--+--+--+--+ 291 | UDABM Length + Flag | 1 octet 292 +--+--+--+--+--+--+--+--+ 293 | SABM ... 0 - 8 octets 294 +--+--+--+--+--+--+--+--+ 295 | UDABM ... 0 - 8 octets 296 +--+--+--+--+--+--+--+--+ 298 SABM Length + Flag (1 octet) 299 Standard Application Identifier Bit Mask 300 Length + Flag 301 0 1 2 3 4 5 6 7 302 +-+-+-+-+-+-+-+-+ 303 |L| SABM Length | 304 +-+-+-+-+-+-+-+-+ 306 L-flag: Legacy Flag. 307 See Section 4.2 for a description of how 308 this flag is used. 310 SABM Length: Indicates the length in octets (0-8) of the 311 Standard Application Identifier Bit Mask. The length SHOULD 312 be the minimum required to send all bits that are set. 314 UDABM Length + Flag (1 octet) 315 User Defined Application Identifier Bit Mask 316 Length + Flag 318 0 1 2 3 4 5 6 7 319 +-+-+-+-+-+-+-+-+ 320 |R| UDABM Length| 321 +-+-+-+-+-+-+-+-+ 323 R: Reserved. SHOULD be transmitted as 0 and 324 MUST be ignored on receipt 326 UDABM Length: Indicates the length in octets (0-8) of the 327 User Defined Application Identifier Bit Mask. The length SHOULD 328 be the minimum required to send all bits that are set. 330 SABM (variable length) 331 Standard Application Identifier Bit Mask 333 (SABM Length * 8) bits 335 This field is omitted if SABM Length is 0. 337 0 1 2 3 4 5 6 7 ... 338 +-+-+-+-+-+-+-+-+... 339 |R|S|F| ... 340 +-+-+-+-+-+-+-+-+... 342 R-bit: Set to specify RSVP-TE 344 S-bit: Set to specify Segment Routing Policy 346 F-bit: Set to specify Loop Free Alternate (LFA) 347 (includes all LFA types) 349 UDABM (variable length) 350 User Defined Application Identifier Bit Mask 352 (UDABM Length * 8) bits 354 0 1 2 3 4 5 6 7 ... 355 +-+-+-+-+-+-+-+-+... 356 | ... 357 +-+-+-+-+-+-+-+-+... 359 This field is omitted if UDABM Length is 0. 361 NOTE: SABM/UDABM Length is arbitrarily limited to 8 octets in order 362 to insure that sufficient space is left to advertise link attributes 363 without overrunning the maximum length of a sub-TLV. 365 Standard Application Identifier Bits are defined/sent starting with 366 Bit 0. 368 User Defined Application Identifier Bits have no relationship to 369 Standard Application Identifier Bits and are not managed by IANA or 370 any other standards body. It is recommended that bits are used 371 starting with Bit 0 so as to minimize the number of octets required 372 to advertise all UDAs. 374 In the case of both SABM and UDABM, the following rules apply: 376 o Undefined bits that are transmitted MUST be transmitted as 0 and 377 MUST be ignored on receipt 379 o Bits that are not transmitted MUST be treated as if they are set 380 to 0 on receipt. 382 o Bits that are not supported by an implementation MUST be ignored 383 on receipt. 385 . 387 4.2. Application-Specific Link Attributes sub-TLV 389 A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined that 390 supports specification of the applications and application-specific 391 attribute values. 393 Type: 16 (temporarily assigned by IANA) 394 Length: Variable (1 octet) 395 Value: 397 Application Identifier Bit Mask 398 (as defined in Section 4.1) 400 Link Attribute sub-sub-TLVs - format matches the 401 existing formats defined in [RFC5305], [RFC7308], 402 and [RFC8570] 404 If the SABM or UDABM length in the Application Identifier Bit Mask is 405 greater than 8, the entire sub-TLV MUST be ignored. 407 When the L-flag is set in the Application Identifier Bit Mask, all of 408 the applications specified in the bit mask MUST use the legacy 409 advertisements for the corresponding link found in TLVs 22, 23, 25, 410 141, 222, and 223 or TLV 138 or TLV 139 as appropriate. Link 411 attribute sub-sub-TLVs for the corresponding link attributes MUST NOT 412 be advertised for the set of applications specified in the Standard/ 413 User Application Identifier Bit Masks and all such advertisements 414 MUST be ignored on receipt. 416 Multiple Application-Specific Link Attribute sub-TLVs for the same 417 link MAY be advertised. When multiple sub-TLVs for the same link are 418 advertised, they SHOULD advertise non-conflicting application/ 419 attribute pairs. A conflict exists when the same application is 420 associated with two different values for the same link attribute for 421 a given link. In cases where conflicting values for the same 422 application/attribute/link are advertised the first advertisement 423 received in the lowest numbered LSP SHOULD be used and subsequent 424 advertisements of the same attribute SHOULD be ignored. 426 For a given application, the setting of the L-flag MUST be the same 427 in all sub-TLVs for a given link. In cases where this constraint is 428 violated, the L-flag MUST be considered set for this application. 430 If link attributes are advertised associated with zero length 431 Application Identifier Bit Masks for both standard applications and 432 user defined applications, then any Standard Application and/or any 433 User Defined Application is permitted to use that set of link 434 attributes so long as there is not another set of attributes 435 advertised on that same link that is associated with a non-zero 436 length Application Identifier Bit Mask with a matching Application 437 Identifier Bit set. 439 A new registry of sub-sub-TLVs is to be created by IANA that defines 440 the link attribute sub-sub-TLV code points. This document defines a 441 sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1 442 except as noted below. The format of the sub-sub-TLVs matches the 443 format of the corresponding legacy sub-TLV and IANA is requested to 444 assign the legacy sub-TLV identifier to the corresponding sub-sub- 445 TLV. 447 4.2.1. Special Considerations for Maximum Link Bandwidth 449 Maximum link bandwidth is an application independent attribute of the 450 link. When advertised using the Application-Specific Link Attributes 451 sub-TLV, multiple values for the same link MUST NOT be advertised. 452 This can be accomplished most efficiently by having a single 453 advertisement for a given link where the Application Identifier Bit 454 Mask identifies all the applications that are making use of the value 455 for that link. 457 It is also possible to advertise the same value for a given link 458 multiple times with disjoint sets of applications specified in the 459 Application Identifier Bit Mask. This is less efficient but still 460 valid. 462 It is also possible to advertise a single advertisement with zero 463 length SABM and UDABM so long as the constraints discussed in 464 Section 4.2 and Section 6.2 are acceptable. 466 If different values for Maximum Link Bandwidth for a given link are 467 advertised, all values MUST be ignored. 469 4.2.2. Special Considerations for Reservable/Unreserved Bandwidth 471 Maximum Reservable Link Bandwidth and Unreserved Bandwidth are 472 attributes specific to RSVP-TE. When advertised using the 473 Application-Specific Link Attributes sub-TLV, bits other than the 474 RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit 475 Mask. If an advertisement of Maximum Reservable Link Bandwidth or 476 Unreserved Bandwidth is received with bits other than the RSVP-TE bit 477 set, the advertisement MUST be ignored. 479 4.2.3. Considerations for Extended TE Metrics 481 [RFC8570] defines a number of dynamic performance metrics associated 482 with a link. It is conceivable that such metrics could be measured 483 specific to traffic associated with a specific application. 484 Therefore this document includes support for advertising these link 485 attributes specific to a given application. However, in practice it 486 may well be more practical to have these metrics reflect the 487 performance of all traffic on the link regardless of application. In 488 such cases, advertisements for these attributes will be associated 489 with all of the applications utilizing that link. This can be done 490 either by explicitly specifying the applications in the Application 491 Identifier Bit Mask or by using a zero length Application Identifier 492 Bit Mask. 494 4.3. Application-Specific SRLG TLV 496 A new TLV is defined to advertise application-specific SRLGs for a 497 given link. Although similar in functionality to TLV 138 [RFC5307] 498 and TLV 139 [RFC6119], a single TLV provides support for IPv4, IPv6, 499 and unnumbered identifiers for a link. Unlike TLVs 138/139, it 500 utilizes sub-TLVs to encode the link identifiers in order to provide 501 the flexible formatting required to support multiple link identifier 502 types. 504 Type: 238 (Temporarily assigned by IANA) 505 Length: Number of octets in the value field (1 octet) 506 Value: 507 Neighbor System-ID + pseudo-node ID (7 octets) 508 Application Identifier Bit Mask 509 (as defined in Section 4.1) 510 Length of sub-TLVs (1 octet) 511 Link Identifier sub-TLVs (variable) 512 0 or more SRLG Values (Each value is 4 octets) 514 The following Link Identifier sub-TLVs are defined. 515 The values chosen are intentionally matching the equivalent 516 sub-TLVs from [RFC5305], [RFC5307], and [RFC6119]. 518 Type Description 519 4 Link Local/Remote Identifiers [RFC5307] 520 6 IPv4 interface address [RFC5305] 521 8 IPv4 neighbor address [RFC5305] 522 12 IPv6 Interface Address [RFC6119] 523 13 IPv6 Neighbor Address [RFC6119] 525 At least one set of link identifiers (IPv4, IPv6, or Link Local/ 526 Remote) MUST be present. Multiple occurrences of the same identifier 527 type MUST NOT be present. TLVs that do not meet this requirement 528 MUST be ignored. 530 Multiple TLVs for the same link MAY be advertised. 532 When the L-flag is set in the Application Identifier Bit Mask, SRLG 533 values MUST NOT be included in the TLV. Any SRLG values that are 534 advertised MUST be ignored. Based on the link identifiers advertised 535 the corresponding legacy TLV (see Section 3.2) can be identified and 536 the SRLG values advertised in the legacy TLV MUST be used by the set 537 of applications specified in the Application Identifier Bit Mask. 539 For a given application, the setting of the L-flag MUST be the same 540 in all TLVs for a given link. In cases where this constraint is 541 violated, the L-flag MUST be considered set for this application. 543 5. Attribute Advertisements and Enablement 545 This document defines extensions to support the advertisement of 546 application-specific link attributes. 548 Whether the presence of link attribute advertisements for a given 549 application indicates that the application is enabled on that link 550 depends upon the application. Similarly, whether the absence of link 551 attribute advertisements indicates that the application is not 552 enabled depends upon the application. 554 In the case of RSVP-TE, the advertisement of application-specific 555 link attributes implies that RSVP is enabled on that link. The 556 absence of RSVP-TE application-specific link attributes in 557 combination with the absence of legacy advertisements implies that 558 RSVP is not enabled on that link. 560 In the case of SR Policy, advertisement of application-specific link 561 attributes does not indicate enablement of SR Policy on that link. 562 The advertisements are only used to support constraints that may be 563 applied when specifying an explicit path. SR Policy is implicitly 564 enabled on all links that are part of the Segment Routing enabled 565 topology independent of the existence of link attribute 566 advertisements. 568 In the case of LFA, advertisement of application-specific link 569 attributes does not indicate enablement of LFA on that link. 570 Enablement is controlled by local configuration. 572 If, in the future, additional standard applications are defined to 573 use this mechanism, the specification defining this use MUST define 574 the relationship between application-specific link attribute 575 advertisements and enablement for that application. 577 This document allows the advertisement of application-specific link 578 attributes with no application identifiers i.e., both the Standard 579 Application Identifier Bit Mask and the User Defined Application 580 Identifier Bit Mask are not present (See Section 4.1). This supports 581 the use of the link attribute by any application. In the presence of 582 an application where the advertisement of link attribute 583 advertisements is used to infer the enablement of an application on 584 that link (e.g., RSVP-TE), the absence of the application identifier 585 leaves ambiguous whether that application is enabled on such a link. 586 This needs to be considered when making use of the "any application" 587 encoding. 589 6. Deployment Considerations 591 This section discuss deployment considerations associated with the 592 use of application-specific link attribute advertisements. 594 6.1. Use of Legacy Advertisements 596 Bit Identifiers for Standard Applications are defined in Section 4.1. 597 All of the identifiers defined in this document are associated with 598 applications that were already deployed in some networks prior to the 599 writing of this document. Therefore, such applications have been 600 deployed using the legacy advertisements. The Standard Applications 601 defined in this document may continue to use legacy advertisements 602 for a given link so long as at least one of the following conditions 603 is true: 605 o The application is RSVP-TE 607 o The application is SR Policy or LFA and RSVP-TE is not deployed 608 anywhere in the network 610 o The application is SR Policy or LFA, RSVP-TE is deployed in the 611 network, and both the set of links on which SR Policy and/or LFA 612 advertisements are required and the attribute values used by SR 613 Policy and/or LFA on all such links is fully congruent with the 614 links and attribute values used by RSVP-TE 616 Under the conditions defined above, implementations that support the 617 extensions defined in this document have the choice of using legacy 618 advertisements or application-specific advertisements in support of 619 SR Policy and/or LFA. This will require implementations to provide 620 controls specifying which type of advertisements are to be sent/ 621 processed on receive for these applications. Further discussion of 622 the associated issues can be found in Section 6.3. 624 New applications that future documents define to make use of the 625 advertisements defined in this document MUST NOT make use of legacy 626 advertisements. This simplifies deployment of new applications by 627 eliminating the need to support multiple ways to advertise attributes 628 for the new applications. 630 6.2. Use of Zero Length Application Identifier Bit Masks 632 Link attribute advertisements associated with zero length Application 633 Identifier Bit Masks for both standard applications and user defined 634 applications are usable by any application, subject to the 635 restrictions specified in Section 4.2. If support for a new 636 application is introduced on any node in a network in the presence of 637 such advertisements, these advertisements are permitted to be used by 638 the new application. If this is not what is intended, then existing 639 advertisements MUST be readvertised with an explicit set of 640 applications specified before a new application is introduced. 642 6.3. Interoperability, Backwards Compatibility and Migration Concerns 644 Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the 645 legacy advertisements listed in Section 3. Routers that do not 646 support the extensions defined in this document will only process 647 legacy advertisements and are likely to infer that RSVP-TE is enabled 648 on the links for which legacy advertisements exist. It is expected 649 that deployments using the legacy advertisements will persist for a 650 significant period of time. Therefore deployments using the 651 extensions defined in this document in the presence of routers that 652 do not support these extensions need to be able to interoperate with 653 the use of legacy advertisements by the legacy routers. The 654 following sub-sections discuss interoperability and backwards 655 compatibility concerns for a number of deployment scenarios. 657 6.3.1. Multiple Applications: Common Attributes with RSVP-TE 659 In cases where multiple applications are utilizing a given link, one 660 of the applications is RSVP-TE, and all link attributes for a given 661 link are common to the set of applications utilizing that link, 662 interoperability is achieved by using legacy advertisements and 663 sending application-specific advertisements with L-flag set and no 664 link attribute values. This avoids duplication of link attribute 665 advertisements. 667 6.3.2. Multiple Applications: All Attributes Not Shared with RSVP-TE 669 In cases where one or more applications other than RSVP-TE are 670 utilizing a given link and one or more link attribute values are not 671 shared with RSVP-TE, it is necessary to use application-specific 672 advertisements as defined in this document. Attributes for 673 applications other than RSVP-TE MUST be advertised using application- 674 specific advertisements that have the L-flag clear. In cases where 675 some link attributes are shared with RSVP-TE, this requires duplicate 676 advertisements for those attributes. 678 These guidelines apply to cases where RSVP-TE is not using any 679 advertised attributes on a link and to cases where RSVP-TE is using 680 some link attribute advertisements on the link but some link 681 attributes cannot be shared with RSVP-TE. 683 6.3.3. Interoperability with Legacy Routers 685 For the applications defined in this document, routers that do not 686 support the extensions defined in this document will send and receive 687 only legacy link attribute advertisements. So long as there is any 688 legacy router in the network that has any of the applications 689 enabled, all routers MUST continue to advertise link attributes using 690 legacy advertisements. In addition, the link attribute values 691 associated with the set of applications supported by legacy routers 692 (RSVP-TE, SR Policy, and/or LFA) are always shared since legacy 693 routers have no way of advertising or processing application-specific 694 values. Once all legacy routers have been upgraded, migration from 695 legacy advertisements to ASLA advertisements can be achieved via the 696 following steps: 698 1)Send ASLA advertisements while continuing to advertise using legacy 699 (all advertisements are then duplicated). Receiving routers continue 700 to use legacy advertisements. 702 2)Enable the use of the ASLA advertisements on all routers 704 3)Remove legacy advertisements 706 When the migration is complete, it then becomes possible to advertise 707 incongruent values per application on a given link. 709 Note that the use of the L-flag is of no value in the migration. 711 Documents defining new applications that make use of the application- 712 specific advertisements defined in this document MUST discuss 713 interoperability and backwards compatibility issues that could occur 714 in the presence of routers that do not support the new application. 716 6.3.4. Use of Application-Specific Advertisements for RSVP-TE 718 The extensions defined in this document support RSVP-TE as one of the 719 supported applications. This allows that RSVP-TE could eventually 720 utilize the application-specific advertisements. This can be done in 721 the following step-wise manner: 723 1)Upgrade all routers to support the extensions in this document 724 2)Advertise all legacy link attributes using ASLA advertisements with 725 L-flag clear and R-bit set. At this point both legacy and 726 application-specific advertisements are being sent. 728 3)Remove legacy advertisements 730 7. IANA Considerations 732 This section lists the protocol code point changes introduced by this 733 document and the related IANA changes required. 735 For new registries defined under IS-IS TLV Codepoints Registry with 736 registration procedure "Expert Review", guidance for designated 737 experts can be found in [RFC7370]. 739 7.1. Application-Specific Link Attributes sub-TLV 741 This document defines a new sub-TLV in the Sub-TLVs for TLVs 22, 23, 742 25, 141, 222, and 223 registry. See Section 4.2 744 Type Description 22 23 25 141 222 223 745 ---- --------------------- ---- ---- ---- ---- ---- ---- 746 16 Application-Specific y y y(s) y y y 747 Link Attributes 749 7.2. Application-Specific SRLG TLV 751 This document defines one new TLV in the IS-IS TLV Codepoints 752 Registry. See Section 4.3 754 Type Description IIH LSP SNP Purge 755 ---- --------------------- --- --- --- ----- 756 238 Application-Specific n y n n 757 SRLG 759 7.3. Application-Specific Link Attributes sub-sub-TLV Registry 761 This document requests a new IANA registry under the IS-IS TLV 762 Codepoints Registry be created to control the assignment of sub-sub- 763 TLV codepoints for the Application-Specific Link Attributes sub-TLV 764 defined in Section 7.1. The suggested name of the new registry is 765 "sub-sub-TLV code points for application-specific link attributes". 766 The registration procedure is "Expert Review" as defined in 767 [RFC8126]. The following assignments are made by this document: 769 Type Description Encoding 770 Reference 771 --------------------------------------------------------- 772 0-2 Unassigned 773 3 Administrative group (color) RFC5305 774 4-8 Unassigned 775 9 Maximum link bandwidth RFC5305 776 10 Maximum reservable link bandwidth RFC5305 777 11 Unreserved bandwidth RFC5305 778 12-13 Unassigned 779 14 Extended Administrative Group RFC7308 780 15-17 Unassigned 781 18 TE Default Metric RFC5305 782 19-32 Unassigned 783 33 Unidirectional Link Delay RFC8570 784 34 Min/Max Unidirectional Link Delay RFC8570 785 35 Unidirectional Delay Variation RFC8570 786 36 Unidirectional Link Loss RFC8570 787 37 Unidirectional Residual Bandwidth RFC8570 788 38 Unidirectional Available Bandwidth RFC8570 789 39 Unidirectional Utilized Bandwidth RFC8570 790 40-255 Unassigned 792 Note to IANA: For future codepoints, in cases where the document that 793 defines the encoding is different from the document that assigns the 794 codepoint, the encoding reference MUST be to the document that 795 defines the encoding. 797 Note to designated experts: If a link attribute can be advertised 798 both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub- 799 sub-TLV of the Application-Specific Link Attributes sub-TLV defined 800 in this document, then the same numerical code should be assigned to 801 the link attribute whenever possible. 803 7.4. Link Attribute Application Identifier Registry 805 This document requests a new IANA registry be created, under the 806 category of "Interior Gateway Protocol (IGP) Parameters", to control 807 the assignment of Application Identifier Bits. The suggested name of 808 the new registry is "Link Attribute Applications". The registration 809 policy for this registry is "Expert Review" [RFC8126]. Bit 810 definitions SHOULD be assigned such that all bits in the lowest 811 available octet are allocated before assigning bits in the next 812 octet. This minimizes the number of octets that will need to be 813 transmitted. The following assignments are made by this document: 815 Bit # Name 816 --------------------------------------------------------- 817 0 RSVP-TE (R-bit) 818 1 Segment Routing Policy (S-bit) 819 2 Loop Free Alternate (F-bit) 820 3-63 Unassigned 822 7.5. SRLG sub-TLVs 824 This document requests a new IANA registry be created under the IS-IS 825 TLV Codepoints Registry to control the assignment of sub-TLV types 826 for the application-specific SRLG TLV. The suggested name of the new 827 registry is "Sub-TLVs for TLV 238". The registration procedure is 828 "Expert Review" as defined in [RFC8126]. The following assignments 829 are made by this document: 831 Value Description Encoding 832 Reference 833 --------------------------------------------------------- 834 0-3 Unassigned 835 4 Link Local/Remote Identifiers [RFC5307] 836 5 Unassigned 837 6 IPv4 interface address [RFC5305] 838 7 Unassigned 839 8 IPv4 neighbor address [RFC5305] 840 9-11 Unassigned 841 12 IPv6 Interface Address [RFC6119] 842 13 IPv6 Neighbor Address [RFC6119] 843 14-255 Unassigned 845 Note to IANA: For future codepoints, in cases where the document that 846 defines the encoding is different from the document that assigns the 847 codepoint, the encoding reference MUST be to the document that 848 defines the encoding. 850 8. Security Considerations 852 Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], 853 and [RFC5310]. While IS-IS is deployed under a single administrative 854 domain, there can be deployments where potential attackers have 855 access to one or more networks in the IS-IS routing domain. In these 856 deployments, the stronger authentication mechanisms defined in the 857 aforementioned documents SHOULD be used. 859 This document defines a new way to advertise link attributes. 860 Tampering with the information defined in this document may have an 861 effect on applications using it, including impacting Traffic 862 Engineering as discussed in [RFC8570]. As the advertisements defined 863 in this document limit the scope to specific applications, the impact 864 of tampering is similarly limited in scope. 866 9. Acknowledgements 868 The authors would like to thank Eric Rosen and Acee Lindem for their 869 careful review and content suggestions. 871 10. References 873 10.1. Normative References 875 [ISO10589] 876 International Organization for Standardization, 877 "Intermediate system to Intermediate system intra-domain 878 routeing information exchange protocol for use in 879 conjunction with the protocol for providing the 880 connectionless-mode Network Service (ISO 8473)", ISO/ 881 IEC 10589:2002, Second Edition, Nov 2002. 883 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 884 Requirement Levels", BCP 14, RFC 2119, 885 DOI 10.17487/RFC2119, March 1997, 886 . 888 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 889 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 890 2008, . 892 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 893 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 894 2008, . 896 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 897 in Support of Generalized Multi-Protocol Label Switching 898 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 899 . 901 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 902 and M. Fanto, "IS-IS Generic Cryptographic 903 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 904 2009, . 906 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 907 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 908 February 2011, . 910 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 911 Traffic Engineering (MPLS-TE)", RFC 7308, 912 DOI 10.17487/RFC7308, July 2014, 913 . 915 [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints 916 Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, 917 . 919 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 920 Writing an IANA Considerations Section in RFCs", BCP 26, 921 RFC 8126, DOI 10.17487/RFC8126, June 2017, 922 . 924 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 925 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 926 May 2017, . 928 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 929 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 930 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 931 2019, . 933 10.2. Informative References 935 [I-D.ietf-spring-segment-routing-policy] 936 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 937 P. Mattes, "Segment Routing Policy Architecture", draft- 938 ietf-spring-segment-routing-policy-07 (work in progress), 939 May 2020. 941 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 942 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 943 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 944 . 946 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 947 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 948 DOI 10.17487/RFC5286, September 2008, 949 . 951 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 952 Litkowski, S., Horneffer, M., and R. Shakir, "Source 953 Packet Routing in Networking (SPRING) Problem Statement 954 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 955 2016, . 957 Authors' Addresses 959 Les Ginsberg 960 Cisco Systems 961 821 Alder Drive 962 Milpitas, CA 95035 963 USA 965 Email: ginsberg@cisco.com 967 Peter Psenak 968 Cisco Systems 969 Apollo Business Center Mlynske nivy 43 970 Bratislava 821 09 971 Slovakia 973 Email: ppsenak@cisco.com 975 Stefano Previdi 976 Huawei 978 Email: stefano@previdi.net 980 Wim Henderickx 981 Nokia 982 Copernicuslaan 50 983 Antwerp 2018 94089 984 Belgium 986 Email: wim.henderickx@nokia.com 988 John Drake 989 Juniper Networks 991 Email: jdrake@juniper.net