idnits 2.17.1 draft-ietf-isis-te-app-14.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 3, 2020) is 1422 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 5, 2020 S. Previdi 6 Huawei 7 W. Henderickx 8 Nokia 9 J. Drake 10 Juniper Networks 11 June 3, 2020 13 IS-IS TE Attributes per application 14 draft-ietf-isis-te-app-14 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 Traffic Engineering, Loop Free Alternate) have been 22 defined which also make use of the link attribute advertisements. In 23 cases where multiple applications wish to make use of these link 24 attributes the current advertisements do not support application 25 specific values for a given attribute nor do they support indication 26 of which applications are using the advertised value for a given 27 link. This document introduces new link attribute advertisements 28 which address 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 5, 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 . . . . . . . . . . . . . . . . . . . . 4 75 3.1. Legacy sub-TLVs . . . . . . . . . . . . . . . . . . . . . 5 76 3.2. Legacy SRLG Advertisements . . . . . . . . . . . . . . . 5 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 . . . . . . 8 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 . . . . . . . 10 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 . . . 13 89 6.3. Interoperability, Backwards Compatibility and Migration 90 Concerns . . . . . . . . . . . . . . . . . . . . . . . . 14 91 6.3.1. Multiple Applications: Common Attributes with RSVP- 92 TE . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 6.3.2. Multiple Applications: All Attributes Not Shared with 94 RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 14 95 6.3.3. Interoperability with Legacy Routers . . . . . . . . 15 96 6.3.4. Use of Application Specific Advertisements for RSVP- 97 TE . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 99 7.1. Application Specific Link Attributes sub-TLV . . . . . . 16 100 7.2. Application Specific SRLG TLV . . . . . . . . . . . . . . 16 101 7.3. Application Specific Link Attributes sub-sub-TLV Registry 16 102 7.4. Link Attribute Application Identifier Registry . . . . . 17 103 7.5. SRLG sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 18 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 108 10.2. Informative References . . . . . . . . . . . . . . . . . 20 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 123 which makes use of link attribute advertisements - examples of which 124 are listed in Section 3. 126 In recent years new applications have been introduced which have use 127 cases for many of the link attributes historically used by RSVP-TE. 128 Such applications include Segment Routing Traffic Engineering (SRTE) 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 SRTE support (for 132 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 SRTE. If the topologies are fully congruent this may 135 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 which address these issues. Also, 144 as evolution of use cases for link attributes can be expected to 145 continue in the years to come, this document defines a solution which 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 - so any discussion of existing use cases is 153 limited to requirements which are known at the time of this writing. 154 However, in order to determine the functionality required beyond what 155 already exists in IS-IS, it is only necessary to discuss use cases 156 which justify the key points identified in the introduction - which 157 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 SRTE which is defined in 167 [I-D.ietf-spring-segment-routing-policy]. If both RSVP-TE and SRTE 168 are deployed in a network, link attribute advertisements can be used 169 by one or both of these applications. As there is no requirement for 170 the link attributes advertised on a given link used by SRTE to be 171 identical to the link attributes advertised on that same link used by 172 RSVP-TE, there is a clear requirement to indicate independently which 173 link attribute advertisements are to be used by each application. 175 As the number of applications which may wish to utilize link 176 attributes may grow in the future, an additional requirement is that 177 the extensions defined allow the association of additional 178 applications to link attributes without altering the format of the 179 advertisements or introducing new backwards compatibility issues. 181 Finally, there may still be many cases where a single attribute value 182 can be shared among multiple applications, so the solution must 183 minimize advertising duplicate link/attribute pairs whenever 184 possible. 186 3. Legacy Advertisements 188 There are existing advertisements used in support of RSVP-TE. These 189 advertisements include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 190 223 and TLVs for Shared Risk Link Group (SRLG) advertisement. 192 Sub-TLV values are defined in https://www.iana.org/assignments/isis- 193 tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints- 194 22-23-25-141-222-223 and https://www.iana.org/assignments/isis-tlv- 195 codepoints/isis-tlv-codepoints.xhtml . 197 3.1. Legacy sub-TLVs 199 Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 201 +-------------------------------------------+ 202 | Type | Description | 203 +-------------------------------------------+ 204 | 3 | Administrative group (color) | 205 +-------------------------------------------+ 206 | 9 | Maximum link bandwidth | 207 +-------------------------------------------+ 208 | 10 | Maximum reservable link bandwidth | 209 +-------------------------------------------+ 210 | 11 | Unreserved bandwidth | 211 +-------------------------------------------+ 212 | 14 | Extended Administrative Group | 213 +-------------------------------------------+ 214 | 18 | TE Default Metric | 215 +-------------------------------------------+ 216 | 33 | Unidirectional Link Delay | 217 +-------------------------------------------+ 218 | 34 | Min/Max Unidirectional Link Delay | 219 +-------------------------------------------+ 220 | 35 | Unidirectional Delay Variation | 221 +-------------------------------------------+ 222 | 36 | Unidirectional Link Loss | 223 +-------------------------------------------+ 224 | 37 | Unidirectional Residual Bandwidth | 225 +-------------------------------------------+ 226 | 38 | Unidirectional Available Bandwidth | 227 +-------------------------------------------+ 228 | 39 | Unidirectional Utilized Bandwidth | 229 +-------------------------------------------+ 231 3.2. Legacy SRLG Advertisements 232 TLV 138 GMPLS-SRLG 233 Supports links identified by IPv4 addresses and 234 unnumbered links 236 TLV 139 IPv6 SRLG 237 Supports links identified by IPv6 addresses 239 Note that [RFC6119] prohibits the use of TLV 139 when it is possible 240 to use TLV 138. 242 4. Advertising Application Specific Link Attributes 244 Two new code points are defined in support of Application Specific 245 Link Attribute Advertisements: 247 1) Application Specific Link Attributes sub-TLV for TLVs 22, 23, 25, 248 141, 222, and 223 (defined in Section 4.2 ). 250 2)Application Specific Shared Risk Link Group (SRLG) TLV (defined in 251 Section 4.3). 253 In support of these new advertisements, an application identifier bit 254 mask is defined which identifies the application(s) associated with a 255 given advertisement (defined in Section 4.1). 257 The following sections define the format of these new advertisements. 259 4.1. Application Identifier Bit Mask 261 Identification of the set of applications associated with link 262 attribute advertisements utilizes two bit masks. One bit mask is for 263 standard applications where the definition of each bit is defined in 264 a new IANA controlled registry. A second bit mask is for non- 265 standard User Defined Applications (UDAs). 267 The encoding defined below is used by both the Application Specific 268 Link Attributes sub-TLV and the Application Specific SRLG TLV. 270 0 1 2 3 4 5 6 7 271 +--+--+--+--+--+--+--+--+ 272 | SABM Length + Flag | 1 octet 273 +--+--+--+--+--+--+--+--+ 274 | UDABM Length + Flag | 1 octet 275 +--+--+--+--+--+--+--+--+ 276 | SABM ... 0 - 8 octets 277 +--+--+--+--+--+--+--+--+ 278 | UDABM ... 0 - 8 octets 279 +--+--+--+--+--+--+--+--+ 281 SABM Length + Flag (1 octet) 282 Standard Application Identifier Bit Mask 283 Length + Flag 285 0 1 2 3 4 5 6 7 286 +-+-+-+-+-+-+-+-+ 287 |L| SABM Length | 288 +-+-+-+-+-+-+-+-+ 290 L-flag: Legacy Flag. 291 See the following section for a description of how 292 this flag is used. 294 SABM Length: Indicates the length in octets (0-8) of the 295 Standard Application Identifier Bit Mask. The length SHOULD 296 be the minimum required to send all bits which are set. 298 UDABM Length + Flag (1 octet) 299 User Defined Application Identifier Bit Mask 300 Length + Flag 302 0 1 2 3 4 5 6 7 303 +-+-+-+-+-+-+-+-+ 304 |R| UDABM Length| 305 +-+-+-+-+-+-+-+-+ 307 R: Reserved. SHOULD be transmitted as 0 and 308 MUST be ignored on receipt 310 UDABM Length: Indicates the length in octets (0-8) of the 311 User Defined Application Identifier Bit Mask. The length SHOULD 312 be the minimum required to send all bits which are set. 314 SABM (variable length) 315 Standard Application Identifier Bit Mask 317 (SABM Length * 8) bits 319 This field is omitted if SABM Length is 0. 321 0 1 2 3 4 5 6 7 ... 322 +-+-+-+-+-+-+-+-+... 323 |R|S|F| ... 324 +-+-+-+-+-+-+-+-+... 326 R-bit: Set to specify RSVP-TE 328 S-bit: Set to specify Segment Routing 329 Traffic Engineering (SRTE) 331 F-bit: Set to specify Loop Free Alternate (LFA) 332 (includes all LFA types) 334 UDABM (variable length) 335 User Defined Application Identifier Bit Mask 337 (UDABM Length * 8) bits 339 0 1 2 3 4 5 6 7 ... 340 +-+-+-+-+-+-+-+-+... 341 | ... 342 +-+-+-+-+-+-+-+-+... 344 This field is omitted if UDABM Length is 0. 346 NOTE: SABM/UDABM Length is arbitrarily limited to 8 octets in order 347 to insure that sufficient space is left to advertise link attributes 348 without overrunning the maximum length of a sub-TLV. 350 Standard Application Identifier Bits are defined/sent starting with 351 Bit 0. Undefined bits which are transmitted MUST be transmitted as 0 352 and MUST be ignored on receipt. Bits that are not transmitted MUST 353 be treated as if they are set to 0 on receipt. Bits that are not 354 supported by an implementation MUST be ignored on receipt. 356 User Defined Application Identifier Bits have no relationship to 357 Standard Application Identifier Bits and are not managed by IANA or 358 any other standards body. It is recommended that bits are used 359 starting with Bit 0 so as to minimize the number of octets required 360 to advertise all UDAs. 362 4.2. Application Specific Link Attributes sub-TLV 364 A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined which 365 supports specification of the applications and application specific 366 attribute values. 368 Type: 16 (temporarily assigned by IANA) 369 Length: Variable (1 octet) 370 Value: 372 Application Identifier Bit Mask 373 (as defined in Section 4.1) 375 Link Attribute sub-sub-TLVs - format matches the 376 existing formats defined in [RFC5305], [RFC7308], 377 and [RFC8570] 379 If the SABM or UDABM length in the Application Identifer Bit Mask is 380 greater than 8, the entire sub-TLV MUST be ignored. 382 When the L-flag is set in the Application Identifier Bit Mask, all of 383 the applications specified in the bit mask MUST use the legacy 384 advertisements for the corresponding link found in TLVs 22, 23, 25, 385 141, 222, and 223 or TLV 138 or TLV 139 as appropriate. Link 386 attribute sub-sub-TLVs for the corresponding link attributes MUST NOT 387 be advertised for the set of applications specified in the Standard/ 388 User Application Identifier Bit Masks and all such advertisements 389 MUST be ignored on receipt. 391 Multiple Application Specific Link Attribute sub-TLVs for the same 392 link MAY be advertised. When multiple sub-TLVs for the same link are 393 advertised, they SHOULD advertise non-conflicting application/ 394 attribute pairs. A conflict exists when the same application is 395 associated with two different values of the same link attribute for a 396 given link. In cases where conflicting values for the same 397 application/attribute/link are advertised all the conflicting values 398 MUST be ignored by the specified application. 400 For a given application, the setting of the L-flag MUST be the same 401 in all sub-TLVs for a given link. In cases where this constraint is 402 violated, the L-flag MUST be considered set for this application. 404 If link attributes are advertised associated with zero length 405 Application Identifier Bit Masks for both standard applications and 406 user defined applications, then any Standard Application and/or any 407 User Defined Application is permitted to use that set of link 408 attributes so long as there is not another set of attributes 409 advertised on that same link which is associated with a non-zero 410 length Application Identifier Bit Mask with a matching Application 411 Identifier Bit set. 413 A new registry of sub-sub-TLVs is to be created by IANA which defines 414 the link attribute sub-sub-TLV code points. This document defines a 415 sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1 416 except as noted below. The format of the sub-sub-TLVs matches the 417 format of the corresponding legacy sub-TLV and IANA is requested to 418 assign the legacy sub-TLV identifier to the corresponding sub-sub- 419 TLV. 421 4.2.1. Special Considerations for Maximum Link Bandwidth 423 Maximum link bandwidth is an application independent attribute of the 424 link. When advertised using the Application Specific Link Attributes 425 sub-TLV, multiple values for the same link MUST NOT be advertised. 426 This can be accomplished most efficiently by having a single 427 advertisement for a given link where the Application Identifier Bit 428 Mask identifies all the applications which are making use of the 429 value for that link. 431 It is also possible to advertise the same value for a given link 432 multiple times with disjoint sets of applications specified in the 433 Application Identifier Bit Mask. This is less efficient but still 434 valid. 436 If different values for Maximum Link Bandwidth for a given link are 437 advertised, all values MUST be ignored. 439 4.2.2. Special Considerations for Reservable/Unreserved Bandwidth 441 Maximum Reservable Link Bandwidth and Unreserved Bandwidth are 442 attributes specific to RSVP-TE. When advertised using the 443 Application Specific Link Attributes sub-TLV, bits other than the 444 RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit 445 Mask. If an advertisement of Maximum Reservable Link Bandwidth or 446 Unreserved Bandwidth is received with bits other than the RSVP-TE bit 447 set, the advertisement MUST be ignored. 449 4.2.3. Considerations for Extended TE Metrics 451 [RFC8570] defines a number of dynamic performance metrics associated 452 with a link. It is conceivable that such metrics could be measured 453 specific to traffic associated with a specific application. 454 Therefore this document includes support for advertising these link 455 attributes specific to a given application. However, in practice it 456 may well be more practical to have these metrics reflect the 457 performance of all traffic on the link regardless of application. In 458 such cases, advertisements for these attributes will be associated 459 with all of the applications utilizing that link. This can be done 460 either by explicitly specifying the applications in the Application 461 Identifier Bit Mask or by using a zero length Application Identifier 462 Bit Mask. 464 4.3. Application Specific SRLG TLV 466 A new TLV is defined to advertise application specific SRLGs for a 467 given link. Although similar in functionality to TLV 138 [RFC5307] 468 and TLV 139 [RFC6119], a single TLV provides support for IPv4, IPv6, 469 and unnumbered identifiers for a link. Unlike TLVs 138/139, it 470 utilizes sub-TLVs to encode the link identifiers in order to provide 471 the flexible formatting required to support multiple link identifier 472 types. 474 Type: 238 (Temporarily assigned by IANA) 475 Length: Number of octets in the value field (1 octet) 476 Value: 477 Neighbor System-ID + pseudo-node ID (7 octets) 478 Application Identifier Bit Mask 479 (as defined in Section 4.1) 480 Length of sub-TLVs (1 octet) 481 Link Identifier sub-TLVs (variable) 482 0 or more SRLG Values (Each value is 4 octets) 484 The following Link Identifier sub-TLVs are defined. 485 The values chosen are intentionally matching the equivalent 486 sub-TLVs from [RFC5305], [RFC5307], and [RFC6119]. 488 Type Description 489 4 Link Local/Remote Identifiers [RFC5307] 490 6 IPv4 interface address [RFC5305] 491 8 IPv4 neighbor address [RFC5305] 492 12 IPv6 Interface Address [RFC6119] 493 13 IPv6 Neighbor Address [RFC6119] 495 At least one set of link identifiers (IPv4, IPv6, or Link Local/ 496 Remote) MUST be present. TLVs which do not meet this requirement 497 MUST be ignored. 499 Multiple TLVs for the same link MAY be advertised. 501 When the L-flag is set in the Application Identifier Bit Mask, SRLG 502 values MUST NOT be included in the TLV. Any SRLG values which are 503 advertised MUST be ignored. Based on the link identifiers advertised 504 the corresponding legacy TLV (see Section 3.2) can be identified and 505 the SRLG values advertised in the legacy TLV MUST be used by the set 506 of applications specified in the Application Identifier Bit Mask. 508 For a given application, the setting of the L-flag MUST be the same 509 in all TLVs for a given link. In cases where this constraint is 510 violated, the L-flag MUST be considered set for this application. 512 5. Attribute Advertisements and Enablement 514 This document defines extensions to support the advertisement of 515 application specific link attributes. 517 Whether the presence of link attribute advertisements for a given 518 application indicates that the application is enabled on that link 519 depends upon the application. Similarly, whether the absence of link 520 attribute advertisements indicates that the application is not 521 enabled depends upon the application. 523 In the case of RSVP-TE, the advertisement of application specific 524 link attributes implies that RSVP is enabled on that link. The 525 absence of RSVP-TE application specific link attributes in 526 combination with the absence of legacy advertisements implies that 527 RSVP is not enabled on that link. 529 In the case of SRTE, advertisement of application specific link 530 attributes does not indicate enablement of SRTE on that link. The 531 advertisements are only used to support constraints which may be 532 applied when specifying an explicit path. SRTE is implicitly enabled 533 on all links which are part of the Segment Routing enabled topology 534 independent of the existence of link attribute advertisements 536 In the case of LFA, advertisement of application specific link 537 attributes does not indicate enablement of LFA on that link. 538 Enablement is controlled by local configuration. 540 If, in the future, additional standard applications are defined to 541 use this mechanism, the specification defining this use MUST define 542 the relationship between application specific link attribute 543 advertisements and enablement for that application. 545 This document allows the advertisement of application specific link 546 attributes with no application identifiers i.e., both the Standard 547 Application Identifier Bit Mask and the User Defined Application 548 Identifier Bit Mask are not present (See Section 4.1). This supports 549 the use of the link attribute by any application. In the presence of 550 an application where the advertisement of link attribute 551 advertisements is used to infer the enablement of an application on 552 that link (e.g., RSVP-TE), the absence of the application identifier 553 leaves ambiguous whether that application is enabled on such a link. 554 This needs to be considered when making use of the "any application" 555 encoding. 557 6. Deployment Considerations 559 This section discuss deployment considerations associated with the 560 use of application specific link attribute advertisements. 562 6.1. Use of Legacy Advertisements 564 Bit Identifiers for Standard Applications are defined in Section 4.1. 565 All of the identifiers defined in this document are associated with 566 applications which were already deployed in some networks prior to 567 the writing of this document. Therefore, such applications have been 568 deployed using the legacy advertisements. The Standard Applications 569 defined in this document may continue to use legacy advertisements 570 for a given link so long as at least one of the following conditions 571 is true: 573 o The application is RSVP-TE 575 o The application is SRTE or LFA and RSVP-TE is not deployed 576 anywhere in the network 578 o The application is SRTE or LFA, RSVP-TE is deployed in the 579 network, and both the set of links on which SRTE and/or LFA 580 advertisements are required and the attribute values used by SRTE 581 and/or LFA on all such links is fully congruent with the links and 582 attribute values used by RSVP-TE 584 Under the conditions defined above, implementations which support the 585 extensions defined in this document have the choice of using legacy 586 advertisements or application specific advertisements in support of 587 SRTE and/or LFA. This will require implementations to provide 588 controls specifying which type of advertisements are to be sent/ 589 processed on receive for these applications. Further discussion of 590 the associated issues can be found in Section 6.3. 592 New applications which future documents define to make use of the 593 advertisements defined in this document MUST NOT make use of legacy 594 advertisements. This simplifies deployment of new applications by 595 eliminating the need to support multiple ways to advertise attributes 596 for the new applications. 598 6.2. Use of Zero Length Application Identifier Bit Masks 600 Link attribute advertisements associated with zero length Application 601 Identifier Bit Masks for both standard applications and user defined 602 applications are usable by any application, subject to the 603 restrictions specified in Section 4.2. If support for a new 604 application is introduced on any node in a network in the presence of 605 such advertisements, these advertisements are permitted to be used by 606 the new application. If this is not what is intended, then existing 607 advertisements MUST be readvertised with an explicit set of 608 applications specified before a new application is introduced. 610 6.3. Interoperability, Backwards Compatibility and Migration Concerns 612 Existing deployments of RSVP-TE, SRTE, and/or LFA utilize the legacy 613 advertisements listed in Section 3. Routers which do not support the 614 extensions defined in this document will only process legacy 615 advertisements and are likely to infer that RSVP-TE is enabled on the 616 links for which legacy advertisements exist. It is expected that 617 deployments using the legacy advertisements will persist for a 618 significant period of time. Therefore deployments using the 619 extensions defined in this document in the presence of routers which 620 do not support these extensions need to be able to interoperate with 621 the use of legacy advertisements by the legacy routers. The 622 following sub-sections discuss interoperability and backwards 623 compatibility concerns for a number of deployment scenarios. 625 6.3.1. Multiple Applications: Common Attributes with RSVP-TE 627 In cases where multiple applications are utilizing a given link, one 628 of the applications is RSVP-TE, and all link attributes for a given 629 link are common to the set of applications utilizing that link, 630 interoperability is achieved by using legacy advertisements and 631 sending application specific advertisements with L-flag set and no 632 link attribute values. This avoids duplication of link attribute 633 advertisements. 635 6.3.2. Multiple Applications: All Attributes Not Shared with RSVP-TE 637 In cases where one or more applications other than RSVP-TE are 638 utilizing a given link and one or more link attribute values are not 639 shared with RSVP-TE, it is necessary to use application specific 640 advertisements as defined in this document. Attributes for 641 applications other than RSVP-TE MUST be advertised using application 642 specific advertisements which have the L-flag clear. In cases where 643 some link attributes are shared with RSVP-TE, this requires duplicate 644 advertisements for those attributes. 646 The discussion in this section applies to cases where RSVP-TE is not 647 using any advertised attributes on a link and to cases where RSVP-TE 648 is using some link attribute advertisements on the link but some link 649 attributes cannot be shared with RSVP-TE. 651 6.3.3. Interoperability with Legacy Routers 653 For the applications defined in this document, routers which do not 654 support the extensions defined in this document will send and receive 655 only legacy link attribute advertisements. So long as there is any 656 legacy router in the network which has any of the applications 657 enabled, all routers MUST continue to advertise link attributes using 658 legacy advertisements. In addition, the link attribute values 659 associated with the set of applications supported by legacy routers 660 (RSVP-TE, SRTE, and/or LFA) are always shared since legacy routers 661 have no way of advertising or processing application specific values. 662 Once all legacy routers have been upgraded, migration from legacy 663 advertisements to application specific advertisements can be achieved 664 via the following steps: 666 1)Send application specific advertisements while continuing to 667 advertise using legacy (all advertisements are then duplicated). 668 Receiving routers continue to use legacy advertisements. 670 2)Enable the use of the application specific advertisements on all 671 routers 673 3)Remove legacy advertisements 675 When the migration is complete, it then becomes possible to advertise 676 incongruent values per application on a given link. 678 Note that the use of the L-flag is of no value in the migration. 680 Documents defining new applications which make use of the application 681 specific advertisements defined in this document MUST discuss 682 interoperability and backwards compatibility issues that could occur 683 in the presence of routers which do not support the new application. 685 6.3.4. Use of Application Specific Advertisements for RSVP-TE 687 The extensions defined in this document support RSVP-TE as one of the 688 supported applications. This allows that RSVP-TE could eventually 689 utilize the application specific advertisements. This can be done in 690 the following step-wise manner: 692 1)Upgrade all routers to support the extensions in this document 694 2)Advertise all legacy link attributes using application specific 695 advertisements with L-flag clear and R-bit set. 697 3)Remove legacy advertisements 699 7. IANA Considerations 701 This section lists the protocol code point changes introduced by this 702 document and the related IANA changes required. 704 For new registries defined under IS-IS TLV Codepoints Registry with 705 registration procedure "Expert Review", guidance for designated 706 experts can be found in [RFC7370]. 708 7.1. Application Specific Link Attributes sub-TLV 710 This document defines a new sub-TLV in the Sub-TLVs for TLVs 22, 23, 711 25, 141, 222, and 223 registry. 713 Type Description 22 23 25 141 222 223 714 ---- --------------------- ---- ---- ---- ---- ---- ---- 715 16 Application Specific y y y(s) y y y 716 Link Attributes 718 7.2. Application Specific SRLG TLV 720 This document defines one new TLV in the IS-IS TLV Codepoints 721 Registry. 723 Type Description IIH LSP SNP Purge 724 ---- --------------------- --- --- --- ----- 725 238 Application Specific n y n n 726 SRLG 728 7.3. Application Specific Link Attributes sub-sub-TLV Registry 730 This document requests a new IANA registry under the IS-IS TLV 731 Codepoints Registry be created to control the assignment of sub-sub- 732 TLV codepoints for the Application Specific Link Attributes sub-TLV 733 defined in Section 7.1. The suggested name of the new registry is 734 "sub-sub-TLV code points for application specific link attributes". 735 The registration procedure is "Expert Review" as defined in 736 [RFC8126]. The following assignments are made by this document: 738 Type Description Encoding 739 Reference 740 --------------------------------------------------------- 741 0-2 Unassigned 742 3 Administrative group (color) RFC5305 743 4-8 Unassigned 744 9 Maximum link bandwidth RFC5305 745 10 Maximum reservable link bandwidth RFC5305 746 11 Unreserved bandwidth RFC5305 747 12-13 Unassigned 748 14 Extended Administrative Group RFC7308 749 15-17 Unassigned 750 18 TE Default Metric RFC5305 751 19-32 Unassigned 752 33 Unidirectional Link Delay RFC8570 753 34 Min/Max Unidirectional Link Delay RFC8570 754 35 Unidirectional Delay Variation RFC8570 755 36 Unidirectional Link Loss RFC8570 756 37 Unidirectional Residual Bandwidth RFC8570 757 38 Unidirectional Available Bandwidth RFC8570 758 39 Unidirectional Utilized Bandwidth RFC8570 759 40-255 Unassigned 761 Note to IANA: For future codepoints, in cases where the document 762 which defines the encoding is different from the document which 763 assigns the codepoint, the encoding reference MUST be to the document 764 which defines the encoding. 766 Note to designated experts: If a link attribute can be advertised 767 both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub- 768 sub-TLV of the Application Specific Link Attributes sub-TLV defined 769 in this document, then the same numerical code should be assigned to 770 the link attribute whenever possible. 772 7.4. Link Attribute Application Identifier Registry 774 This document requests a new IANA registry be created, under the 775 category of "Interior Gateway Protocol (IGP) Parameters", to control 776 the assignment of Application Identifier Bits. The suggested name of 777 the new registry is "Link Attribute Applications". The registration 778 policy for this registry is "Standards Action" [RFC8126]. Bit 779 definitions SHOULD be assigned in ascending bit order beginning with 780 Bit 0 so as to minimize the number of octets that will need to be 781 transmitted. The following assignments are made by this document: 783 Bit # Name 784 --------------------------------------------------------- 785 0 RSVP-TE (R-bit) 786 1 Segment Routing Traffic Engineering (S-bit) 787 2 Loop Free Alternate (F-bit) 788 3-63 Unassigned 790 7.5. SRLG sub-TLVs 792 This document requests a new IANA registry be created under the IS-IS 793 TLV Codepoints Registry to control the assignment of sub-TLV types 794 for the application specific SRLG TLV. The suggested name of the new 795 registry is "Sub-TLVs for TLV 238". The registration procedure is 796 "Expert Review" as defined in [RFC8126]. The following assignments 797 are made by this document: 799 Value Description Encoding 800 Reference 801 --------------------------------------------------------- 802 0-3 Unassigned 803 4 Link Local/Remote Identifiers [RFC5307] 804 5 Unassigned 805 6 IPv4 interface address [RFC5305] 806 7 Unassigned 807 8 IPv4 neighbor address [RFC5305] 808 9-11 Unassigned 809 12 IPv6 Interface Address [RFC6119] 810 13 IPv6 Neighbor Address [RFC6119] 811 14-255 Unassigned 813 Note to IANA: For future codepoints, in cases where the document 814 which defines the encoding is different from the document which 815 assigns the codepoint, the encoding reference MUST be to the document 816 which defines the encoding. 818 8. Security Considerations 820 Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], 821 and [RFC5310]. 823 This document defines a new way to advertise link attributes. 824 Tampering with the information defined in this document may have an 825 effect on applications using it, including impacting Traffic 826 Engineering. This is similar in nature to the impacts associated 827 with (for example) [RFC5305]. As the advertisements defined in this 828 document limit the scope to specific applications, the impact of 829 tampering is similarly limited in scope. 831 9. Acknowledgements 833 The authors would like to thank Eric Rosen and Acee Lindem for their 834 careful review and content suggestions. 836 10. References 838 10.1. Normative References 840 [ISO10589] 841 International Organization for Standardization, 842 "Intermediate system to Intermediate system intra-domain 843 routeing information exchange protocol for use in 844 conjunction with the protocol for providing the 845 connectionless-mode Network Service (ISO 8473)", ISO/ 846 IEC 10589:2002, Second Edition, Nov 2002. 848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels", BCP 14, RFC 2119, 850 DOI 10.17487/RFC2119, March 1997, 851 . 853 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 854 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 855 2008, . 857 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 858 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 859 2008, . 861 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 862 in Support of Generalized Multi-Protocol Label Switching 863 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 864 . 866 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 867 and M. Fanto, "IS-IS Generic Cryptographic 868 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 869 2009, . 871 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 872 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 873 February 2011, . 875 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 876 Traffic Engineering (MPLS-TE)", RFC 7308, 877 DOI 10.17487/RFC7308, July 2014, 878 . 880 [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints 881 Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, 882 . 884 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 885 Writing an IANA Considerations Section in RFCs", BCP 26, 886 RFC 8126, DOI 10.17487/RFC8126, June 2017, 887 . 889 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 890 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 891 May 2017, . 893 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 894 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 895 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 896 2019, . 898 10.2. Informative References 900 [I-D.ietf-spring-segment-routing-policy] 901 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 902 P. Mattes, "Segment Routing Policy Architecture", draft- 903 ietf-spring-segment-routing-policy-07 (work in progress), 904 May 2020. 906 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 907 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 908 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 909 . 911 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 912 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 913 DOI 10.17487/RFC5286, September 2008, 914 . 916 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 917 Litkowski, S., Horneffer, M., and R. Shakir, "Source 918 Packet Routing in Networking (SPRING) Problem Statement 919 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 920 2016, . 922 Authors' Addresses 923 Les Ginsberg 924 Cisco Systems 925 821 Alder Drive 926 Milpitas, CA 95035 927 USA 929 Email: ginsberg@cisco.com 931 Peter Psenak 932 Cisco Systems 933 Apollo Business Center Mlynske nivy 43 934 Bratislava 821 09 935 Slovakia 937 Email: ppsenak@cisco.com 939 Stefano Previdi 940 Huawei 942 Email: stefano@previdi.net 944 Wim Henderickx 945 Nokia 946 Copernicuslaan 50 947 Antwerp 2018 94089 948 Belgium 950 Email: wim.henderickx@nokia.com 952 John Drake 953 Juniper Networks 955 Email: jdrake@juniper.net