idnits 2.17.1 draft-ietf-isis-te-app-12.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 (March 21, 2020) is 1468 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-06 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: September 22, 2020 S. Previdi 6 Huawei 7 W. Henderickx 8 Nokia 9 J. Drake 10 Juniper Networks 11 March 21, 2020 13 IS-IS TE Attributes per application 14 draft-ietf-isis-te-app-12 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 September 22, 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 . . 9 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 . . . . . . . . . . . . . . 10 85 5. Attribute Advertisements and Enablement . . . . . . . . . . . 11 86 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 87 6.1. Use of Legacy Advertisements . . . . . . . . . . . . . . 12 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 . . . . . . . . 14 96 6.3.4. Use of Application Specific Advertisements for RSVP- 97 TE . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 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 SR. Included among 166 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 MUST be transmitted as 0 and MUST be ignored 352 on receipt. Bits that are NOT transmitted MUST be treated as if they 353 are set to 0 on receipt. Bits that are not supported by an 354 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 When the L-flag is set in the Application Identifier Bit Mask, all of 380 the applications specified in the bit mask MUST use the legacy 381 advertisements for the corresponding link found in TLVs 22, 23, 25, 382 141, 222, and 223 or TLV 138 or TLV 139 as appropriate. Link 383 attribute sub-sub-TLVs for the corresponding link attributes MUST NOT 384 be advertised for the set of applications specified in the Standard/ 385 User Application Identifier Bit Masks and all such advertisements 386 MUST be ignored on receipt. 388 Multiple Application Specific Link Attribute sub-TLVs for the same 389 link MAY be advertised. When multiple sub-TLVs for the same link are 390 advertised, they SHOULD advertise non-conflicting application/ 391 attribute pairs. A conflict exists when the same application is 392 associated with two different values of the same link attribute for a 393 given link. In cases where conflicting values for the same 394 application/attribute/link are advertised all the conflicting values 395 MUST be ignored. 397 For a given application, the setting of the L-flag MUST be the same 398 in all sub-TLVs for a given link. In cases where this constraint is 399 violated, the L-flag MUST be considered set for this application. 401 A new registry of sub-sub-TLVs is to be created by IANA which defines 402 the link attribute sub-sub-TLV code points. This document defines a 403 sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1 404 except as noted below. The format of the sub-sub-TLVs matches the 405 format of the corresponding legacy sub-TLV and IANA is requested to 406 assign the legacy sub-TLV identifier to the corresponding sub-sub- 407 TLV. 409 4.2.1. Special Considerations for Maximum Link Bandwidth 411 Maximum link bandwidth is an application independent attribute of the 412 link. When advertised using the Application Specific Link Attributes 413 sub-TLV, multiple values for the same link MUST NOT be advertised. 414 This can be accomplished most efficiently by having a single 415 advertisement for a given link where the Application Identifier Bit 416 Mask identifies all the applications which are making use of the 417 value for that link. 419 It is also possible to advertise the same value for a given link 420 multiple times with disjoint sets of applications specified in the 421 Application Identifier Bit Mask. This is less efficient but still 422 valid. 424 If different values for Maximum Link Bandwidth for a given link are 425 advertised, all values MUST be ignored. 427 4.2.2. Special Considerations for Reservable/Unreserved Bandwidth 429 Maximum Reservable Link Bandwidth and Unreserved Bandwidth are 430 attributes specific to RSVP-TE. When advertised using the 431 Application Specific Link Attributes sub-TLV, bits other than the 432 RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit 433 Mask. If an advertisement of Maximum Reservable Link Bandwidth or 434 Unreserved Bandwidth is received with bits other than the RSVP-TE bit 435 set, the advertisement MUST be ignored. 437 4.2.3. Considerations for Extended TE Metrics 439 [RFC8570] defines a number of dynamic performance metrics associated 440 with a link. It is conceivable that such metrics could be measured 441 specific to traffic associated with a specific application. 442 Therefore this document includes support for advertising these link 443 attributes specific to a given application. However, in practice it 444 may well be more practical to have these metrics reflect the 445 performance of all traffic on the link regardless of application. In 446 such cases, advertisements for these attributes will be associated 447 with all of the applications utilizing that link. 449 4.3. Application Specific SRLG TLV 451 A new TLV is defined to advertise application specific SRLGs for a 452 given link. Although similar in functionality to TLV 138 [RFC5307] 453 and TLV 139 [RFC6119], a single TLV provides support for IPv4, IPv6, 454 and unnumbered identifiers for a link. Unlike TLVs 138/139, it 455 utilizes sub-TLVs to encode the link identifiers in order to provide 456 the flexible formatting required to support multiple link identifier 457 types. 459 Type: 238 (Temporarily assigned by IANA) 460 Length: Number of octets in the value field (1 octet) 461 Value: 462 Neighbor System-ID + pseudo-node ID (7 octets) 463 Application Identifier Bit Mask 464 (as defined in Section 4.1) 465 Length of sub-TLVs (1 octet) 466 Link Identifier sub-TLVs (variable) 467 0 or more SRLG Values (Each value is 4 octets) 469 The following Link Identifier sub-TLVs are defined. 470 The values chosen are intentionally matching the equivalent 471 sub-TLVs from [RFC5305], [RFC5307], and [RFC6119]. 473 Type Description 474 4 Link Local/Remote Identifiers [RFC5307] 475 6 IPv4 interface address [RFC5305] 476 8 IPv4 neighbor address [RFC5305] 477 12 IPv6 Interface Address [RFC6119] 478 13 IPv6 Neighbor Address [RFC6119] 480 At least one set of link identifiers (IPv4, IPv6, or Link Local/ 481 Remote) MUST be present. TLVs which do not meet this requirement 482 MUST be ignored. 484 Multiple TLVs for the same link MAY be advertised. 486 When the L-flag is set in the Application Identifier Bit Mask, SRLG 487 values MUST NOT be included in the TLV. Any SRLG values which are 488 advertised MUST be ignored. Based on the link identifiers advertised 489 the corresponding legacy TLV (see Section 3.2) can be identified and 490 the SRLG values advertised in the legacy TLV MUST be used by the set 491 of applications specified in the Application Identifier Bit Mask. 493 For a given application, the setting of the L-flag MUST be the same 494 in all TLVs for a given link. In cases where this constraint is 495 violated, the L-flag MUST be considered set for this application. 497 5. Attribute Advertisements and Enablement 499 This document defines extensions to support the advertisement of 500 application specific link attributes. 502 Whether the presence of link attribute advertisements for a given 503 application indicates that the application is enabled on that link 504 depends upon the application. Similarly, whether the absence of link 505 attribute advertisements indicates that the application is not 506 enabled depends upon the application. 508 In the case of RSVP-TE, the advertisement of application specific 509 link attributes implies that RSVP is enabled on that link. The 510 absence of RSVP-TE application specific link attributes in 511 combination with the absence of legacy advertisements implies that 512 RSVP is NOT enabled on that link. 514 In the case of SRTE, advertisement of application specific link 515 attributes does NOT indicate enablement of SRTE. The advertisements 516 are only used to support constraints which may be applied when 517 specifying an explicit path. SRTE is implicitly enabled on all links 518 which are part of the Segment Routing enabled topology independent of 519 the existence of link attribute advertisements 521 In the case of LFA, advertisement of application specific link 522 attributes does NOT indicate enablement of LFA on that link. 523 Enablement is controlled by local configuration. 525 If, in the future, additional standard applications are defined to 526 use this mechanism, the specification defining this use MUST define 527 the relationship between application specific link attribute 528 advertisements and enablement for that application. 530 This document allows the advertisement of application specific link 531 attributes with no application identifiers i.e., both the Standard 532 Application Identifier Bit Mask and the User Defined Application 533 Identifier Bit Mask are not present (See Section 4.1). This supports 534 the use of the link attribute by any application. In the presence of 535 an application where the advertisement of link attribute 536 advertisements is used to infer the enablement of an application on 537 that link (e.g., RSVP-TE), the absence of the application identifier 538 leaves ambiguous whether that application is enabled on such a link. 539 This needs to be considered when making use of the "any application" 540 encoding. 542 6. Deployment Considerations 544 This section discuss deployment considerations associated with the 545 use of application specific link attribute advertisements. 547 6.1. Use of Legacy Advertisements 549 Bit Identifiers for Standard Applications are defined in Section 4.1. 550 All of the identifiers defined in this document are associated with 551 applications which were already deployed in some networks prior to 552 the writing of this document. Therefore, such applications have been 553 deployed using the legacy advertisements. The Standard Applications 554 defined in this document may continue to use legacy advertisements 555 for a given link so long as at least one of the following conditions 556 is true: 558 o The application is RSVP-TE 560 o The application is SRTE or LFA and RSVP-TE is not deployed 561 anywhere in the network 563 o The application is SRTE or LFA, RSVP-TE is deployed in the 564 network, and both the set of links on which SRTE and/or LFA 565 advertisements are required and the attribute values used by SRTE 566 and/or LFA on all such links is fully congruent with the links and 567 attribute values used by RSVP-TE 569 Under the conditions defined above, implementations which support the 570 extensions defined in this document have the choice of using legacy 571 advertisements or application specific advertisements in support of 572 SRTE and/or LFA. This will require implementations to provide 573 controls specifying which type of advertisements are to be sent/ 574 processed on receive for these applications. Further discussion of 575 the associated issues can be found in Section 6.3. 577 New applications which future documents define to make use of the 578 advertisements defined in this document MUST NOT make use of legacy 579 advertisements. This simplifies deployment of new applications by 580 eliminating the need to support multiple ways to advertise attributes 581 for the new applications. 583 6.2. Use of Zero Length Application Identifier Bit Masks 585 If link attributes are advertised associated with zero length 586 Application Identifier Bit Masks for both standard applications and 587 user defined applications, then any Standard Application and/or any 588 User Defined Application is permitted to use that set of link 589 attributes so long as there is not another set of attributes 590 advertised on that same link which is associated with a non-zero 591 length Application Identifier Bit Mask with a matching Application 592 Identifier Bit set. If support for a new application is introduced 593 on any node in a network in the presence of such advertisements, 594 these advertisements are permitted to be used by the new application. 595 If this is not what is intended, then existing advertisements MUST be 596 readvertised with an explicit set of applications specified before a 597 new application is introduced. 599 6.3. Interoperability, Backwards Compatibility and Migration Concerns 601 Existing deployments of RSVP-TE, SRTE, and/or LFA utilize the legacy 602 advertisements listed in Section 3. Routers which do not support the 603 extensions defined in this document will only process legacy 604 advertisements and are likely to infer that RSVP-TE is enabled on the 605 links for which legacy advertisements exist. It is expected that 606 deployments using the legacy advertisements will persist for a 607 significant period of time. Therefore deployments using the 608 extensions defined in this document must be able to co-exist with use 609 of the legacy advertisements by routers which do not support the 610 extensions defined in this document. The following sub-sections 611 discuss interoperability and backwards compatibility concerns for a 612 number of deployment scenarios. 614 6.3.1. Multiple Applications: Common Attributes with RSVP-TE 616 In cases where multiple applications are utilizing a given link, one 617 of the applications is RSVP-TE, and all link attributes for a given 618 link are common to the set of applications utilizing that link, 619 interoperability is achieved by using legacy advertisements and 620 sending application specific advertisements with L-flag set and no 621 link attribute values. This avoids duplication of link attribute 622 advertisements. 624 6.3.2. Multiple Applications: All Attributes Not Shared with RSVP-TE 626 In cases where one or more applications other than RSVP-TE are 627 utilizing a given link and one or more link attribute values are NOT 628 shared with RSVP-TE, it is necessary to use application specific 629 advertisements as defined in this document. Attributes for 630 applications other than RSVP-TE MUST be advertised using application 631 specific advertisements which have the L-flag clear. In cases where 632 some link attributes are shared with RSVP-TE, this requires duplicate 633 advertisements for those attributes. 635 The discussion in this section applies to cases where RSVP-TE is NOT 636 using any advertised attributes on a link and to cases where RSVP-TE 637 is using some link attribute advertisements on the link but some link 638 attributes cannot be shared with RSVP-TE. 640 6.3.3. Interoperability with Legacy Routers 642 For the applications defined in this document, routers which do not 643 support the extensions defined in this document will send and receive 644 only legacy link attribute advertisements. So long as there is any 645 legacy router in the network which has any of the applications 646 enabled, all routers MUST continue to advertise link attributes using 647 legacy advertisements. In addition, the link attribute values 648 associated with the set of applications supported by legacy routers 649 (RSVP-TE, SRTE, and/or LFA) are always shared since legacy routers 650 have no way of advertising or processing application specific values. 651 Once all legacy routers have been upgraded, migration from legacy 652 advertisements to application specific advertisements can be achieved 653 via the following steps: 655 1)Send application specific advertisements while continuing to 656 advertise using legacy (all advertisements are then duplicated). 657 Receiving routers continue to use legacy advertisements. 659 2)Enable the use of the application specific advertisements on all 660 routers 662 3)Remove legacy advertisements 664 When the migration is complete, it then becomes possible to advertise 665 incongruent values per application on a given link. 667 Note that the use of the L-flag is of no value in the migration. 669 Documents defining new applications which make use of the application 670 specific advertisements defined in this document MUST discuss 671 interoperability and backwards compatibility issues that could occur 672 in the presence of routers which do not support the new application. 674 6.3.4. Use of Application Specific Advertisements for RSVP-TE 676 The extensions defined in this document support RSVP-TE as one of the 677 supported applications. This allows that RSVP-TE could eventually 678 utilize the application specific advertisements. This can be done in 679 the following step-wise manner: 681 1)Upgrade all routers to support the extensions in this document 683 2)Advertise all legacy link attributes using application specific 684 advertisements with L-flag clear and R-bit set. 686 3)Remove legacy advertisements 688 7. IANA Considerations 690 This section lists the protocol code point changes introduced by this 691 document and the related IANA changes required. 693 For new registries defined under IS-IS TLV Codepoints Registry with 694 registration procedure "Expert Review", guidance for designated 695 experts can be found in [RFC7370]. 697 7.1. Application Specific Link Attributes sub-TLV 699 This document defines a new sub-TLV in the Sub-TLVs for TLVs 22, 23, 700 25, 141, 222, and 223 registry. 702 Type Description 22 23 25 141 222 223 703 ---- --------------------- ---- ---- ---- ---- ---- ---- 704 16 Application Specific y y y(s) y y y 705 Link Attributes 707 7.2. Application Specific SRLG TLV 709 This document defines one new TLV in the IS-IS TLV Codepoints 710 Registry. 712 Type Description IIH LSP SNP Purge 713 ---- --------------------- --- --- --- ----- 714 238 Application Specific n y n n 715 SRLG 717 7.3. Application Specific Link Attributes sub-sub-TLV Registry 719 This document requests a new IANA registry under the IS-IS TLV 720 Codepoints Registry be created to control the assignment of sub-sub- 721 TLV codepoints for the Application Specific Link Attributes sub-TLV 722 defined in Section 7.1. The suggested name of the new registry is 723 "sub-sub-TLV code points for application specific link attributes". 724 The registration procedure is "Expert Review" as defined in 725 [RFC8126]. The following assignments are made by this document: 727 Type Description Encoding 728 Reference 729 --------------------------------------------------------- 730 0-2 Unassigned 731 3 Administrative group (color) RFC5305 732 4-8 Unassigned 733 9 Maximum link bandwidth RFC5305 734 10 Maximum reservable link bandwidth RFC5305 735 11 Unreserved bandwidth RFC5305 736 12-13 Unassigned 737 14 Extended Administrative Group RFC7308 738 15-17 Unassigned 739 18 TE Default Metric RFC5305 740 19-32 Unassigned 741 33 Unidirectional Link Delay RFC8570 742 34 Min/Max Unidirectional Link Delay RFC8570 743 35 Unidirectional Delay Variation RFC8570 744 36 Unidirectional Link Loss RFC8570 745 37 Unidirectional Residual Bandwidth RFC8570 746 38 Unidirectional Available Bandwidth RFC8570 747 39 Unidirectional Utilized Bandwidth RFC8570 748 40-255 Unassigned 750 Note to IANA: For future codepoints, in cases where the document 751 which defines the encoding is different from the document which 752 assigns the codepoint, the encoding reference MUST be to the document 753 which defines the encoding. 755 Note to designated experts: If a link attribute can be advertised 756 both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub- 757 sub-TLV of the Application Specific Link Attributes sub-TLV defined 758 in this document, then the same numerical code should be assigned to 759 the link attribute whenever possible. 761 7.4. Link Attribute Application Identifier Registry 763 This document requests a new IANA registry be created, under the 764 category of "Interior Gateway Protocol (IGP) Parameters", to control 765 the assignment of Application Identifier Bits. The suggested name of 766 the new registry is "Link Attribute Applications". The registration 767 policy for this registry is "Standards Action" [RFC8126]. Bit 768 definitions SHOULD be assigned in ascending bit order beginning with 769 Bit 0 so as to minimize the number of octets that will need to be 770 transmitted. The following assignments are made by this document: 772 Bit # Name 773 --------------------------------------------------------- 774 0 RSVP-TE (R-bit) 775 1 Segment Routing Traffic Engineering (S-bit) 776 2 Loop Free Alternate (F-bit) 777 3-63 Unassigned 779 7.5. SRLG sub-TLVs 781 This document requests a new IANA registry be created under the IS-IS 782 TLV Codepoints Registry to control the assignment of sub-TLV types 783 for the application specific SRLG TLV. The suggested name of the new 784 registry is "Sub-TLVs for TLV 238". The registration procedure is 785 "Expert Review" as defined in [RFC8126]. The following assignments 786 are made by this document: 788 Value Description Encoding 789 Reference 790 --------------------------------------------------------- 791 0-3 Unassigned 792 4 Link Local/Remote Identifiers [RFC5307] 793 5 Unassigned 794 6 IPv4 interface address [RFC5305] 795 7 Unassigned 796 8 IPv4 neighbor address [RFC5305] 797 9-11 Unassigned 798 12 IPv6 Interface Address [RFC6119] 799 13 IPv6 Neighbor Address [RFC6119] 800 14-255 Unassigned 802 Note to IANA: For future codepoints, in cases where the document 803 which defines the encoding is different from the document which 804 assigns the codepoint, the encoding reference MUST be to the document 805 which defines the encoding. 807 8. Security Considerations 809 Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], 810 and [RFC5310]. 812 This document defines a new way to advertise link attributes. 813 Tampering with the information defined in this document may have an 814 effect on applications using it, including impacting Traffic 815 Engineering. This is similar in nature to the impacts associated 816 with (for example) [RFC5305]. As the advertisements defined in this 817 document limit the scope to specific applications, the impact of 818 tampering is similarly limited in scope. 820 9. Acknowledgements 822 The authors would like to thank Eric Rosen and Acee Lindem for their 823 careful review and content suggestions. 825 10. References 827 10.1. Normative References 829 [ISO10589] 830 International Organization for Standardization, 831 "Intermediate system to Intermediate system intra-domain 832 routeing information exchange protocol for use in 833 conjunction with the protocol for providing the 834 connectionless-mode Network Service (ISO 8473)", ISO/ 835 IEC 10589:2002, Second Edition, Nov 2002. 837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 838 Requirement Levels", BCP 14, RFC 2119, 839 DOI 10.17487/RFC2119, March 1997, 840 . 842 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 843 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 844 2008, . 846 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 847 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 848 2008, . 850 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 851 in Support of Generalized Multi-Protocol Label Switching 852 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 853 . 855 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 856 and M. Fanto, "IS-IS Generic Cryptographic 857 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 858 2009, . 860 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 861 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 862 February 2011, . 864 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 865 Traffic Engineering (MPLS-TE)", RFC 7308, 866 DOI 10.17487/RFC7308, July 2014, 867 . 869 [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints 870 Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, 871 . 873 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 874 Writing an IANA Considerations Section in RFCs", BCP 26, 875 RFC 8126, DOI 10.17487/RFC8126, June 2017, 876 . 878 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 879 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 880 May 2017, . 882 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 883 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 884 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 885 2019, . 887 10.2. Informative References 889 [I-D.ietf-spring-segment-routing-policy] 890 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 891 P. Mattes, "Segment Routing Policy Architecture", draft- 892 ietf-spring-segment-routing-policy-06 (work in progress), 893 December 2019. 895 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 896 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 897 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 898 . 900 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 901 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 902 DOI 10.17487/RFC5286, September 2008, 903 . 905 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 906 Litkowski, S., Horneffer, M., and R. Shakir, "Source 907 Packet Routing in Networking (SPRING) Problem Statement 908 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 909 2016, . 911 Authors' Addresses 912 Les Ginsberg 913 Cisco Systems 914 821 Alder Drive 915 Milpitas, CA 95035 916 USA 918 Email: ginsberg@cisco.com 920 Peter Psenak 921 Cisco Systems 922 Apollo Business Center Mlynske nivy 43 923 Bratislava 821 09 924 Slovakia 926 Email: ppsenak@cisco.com 928 Stefano Previdi 929 Huawei 931 Email: stefano@previdi.net 933 Wim Henderickx 934 Nokia 935 Copernicuslaan 50 936 Antwerp 2018 94089 937 Belgium 939 Email: wim.henderickx@nokia.com 941 John Drake 942 Juniper Networks 944 Email: jdrake@juniper.net