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