idnits 2.17.1 draft-ietf-isis-te-app-08.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 (October 17, 2019) is 1653 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) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: April 19, 2020 S. Previdi 6 Huawei 7 W. Henderickx 8 Nokia 9 J. Drake 10 Juniper Networks 11 October 17, 2019 13 IS-IS TE Attributes per application 14 draft-ietf-isis-te-app-08 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 SRTE, LFA) have been defined which also make use of the link 22 attribute advertisements. In cases where multiple applications wish 23 to make use of these link attributes the current advertisements do 24 not support application specific values for a given attribute nor do 25 they support indication of which applications are using the 26 advertised value for a given link. 28 This draft introduces new link attribute advertisements which address 29 both of these shortcomings. It also discusses backwards 30 compatibility issues and how to minimize duplicate advertisements in 31 the presence of routers which do not support the extensions defined 32 in this document. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 38 "OPTIONAL" in this document are to be interpreted as described in BCP 39 14 [RFC2119] [RFC8174] when, and only when, they appear in all 40 capitals, as shown here. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on April 19, 2020. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3 78 3. Legacy Advertisements . . . . . . . . . . . . . . . . . . . . 4 79 3.1. Legacy sub-TLVs . . . . . . . . . . . . . . . . . . . . . 4 80 3.2. Legacy SRLG Advertisements . . . . . . . . . . . . . . . 5 81 4. Advertising Application Specific Link Attributes . . . . . . 5 82 4.1. Application Identifier Bit Mask . . . . . . . . . . . . . 6 83 4.2. Application Specific Link Attributes sub-TLV . . . . . . 8 84 4.2.1. Special Considerations for Maximum Link Bandwidth . . 9 85 4.2.2. Special Considerations for Unreserved Bandwidth . . . 9 86 4.3. Application Specific SRLG TLV . . . . . . . . . . . . . . 9 87 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 88 5.1. Use of Legacy Advertisements . . . . . . . . . . . . . . 11 89 5.2. Use of Zero Length Application Identifier Bit Masks . . . 11 90 6. Attribute Advertisements and Enablement . . . . . . . . . . . 12 91 7. Interoperability, Backwards Compatibility and Migration 92 Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 7.1. Multiple Applications: Common Attributes with RSVP-TE . 13 94 7.2. Multiple Applications: All Attributes Not Shared w RSVP- 95 TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 7.3. Use of Application Specific Advertisements for RSVP-TE . 14 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 103 11.2. Informative References . . . . . . . . . . . . . . . . . 17 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 106 1. Introduction 108 Advertisement of link attributes by the Intermediate-System-to- 109 Intermediate-System (IS-IS) protocol in support of traffic 110 engineering (TE) was introduced by [RFC5305] and extended by 111 [RFC5307], [RFC6119], and [RFC8570]. Use of these extensions has 112 been associated with deployments supporting Traffic Engineering over 113 Multiprotocol Label Switching (MPLS) in the presence of Resource 114 Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE. 116 In recent years new applications have been introduced which have use 117 cases for many of the link attributes historically used by RSVP-TE. 118 Such applications include Segment Routing Traffic Engineering (SRTE) 119 and Loop Free Alternates (LFA). This has introduced ambiguity in 120 that if a deployment includes a mix of RSVP-TE support and SRTE 121 support (for example) it is not possible to unambiguously indicate 122 which advertisements are to be used by RSVP-TE and which 123 advertisements are to be used by SRTE. If the topologies are fully 124 congruent this may not be an issue, but any incongruence leads to 125 ambiguity. 127 An additional issue arises in cases where both applications are 128 supported on a link but the link attribute values associated with 129 each application differ. Current advertisements do not support 130 advertising application specific values for the same attribute on a 131 specific link. 133 This document defines extensions which address these issues. Also, 134 as evolution of use cases for link attributes can be expected to 135 continue in the years to come, this document defines a solution which 136 is easily extensible to the introduction of new applications and new 137 use cases. 139 2. Requirements Discussion 141 As stated previously, evolution of use cases for link attributes can 142 be expected to continue - so any discussion of existing use cases is 143 limited to requirements which are known at the time of this writing. 144 However, in order to determine the functionality required beyond what 145 already exists in IS-IS, it is only necessary to discuss use cases 146 which justify the key points identified in the introduction - which 147 are: 149 1. Support for indicating which applications are using the link 150 attribute advertisements on a link 152 2. Support for advertising application specific values for the same 153 attribute on a link 155 [RFC7855] discusses use cases/requirements for SR. Included among 156 these use cases is SRTE which is defined in 157 [I-D.ietf-spring-segment-routing-policy]. If both RSVP-TE and SRTE 158 are deployed in a network, link attribute advertisements can be used 159 by one or both of these applications. As there is no requirement for 160 the link attributes advertised on a given link used by SRTE to be 161 identical to the link attributes advertised on that same link used by 162 RSVP-TE, there is a clear requirement to indicate independently which 163 link attribute advertisements are to be used by each application. 165 As the number of applications which may wish to utilize link 166 attributes may grow in the future, an additional requirement is that 167 the extensions defined allow the association of additional 168 applications to link attributes without altering the format of the 169 advertisements or introducing new backwards compatibility issues. 171 Finally, there may still be many cases where a single attribute value 172 can be shared among multiple applications, so the solution must 173 minimize advertising duplicate link/attribute pairs whenever 174 possible. 176 3. Legacy Advertisements 178 There are existing advertisements used in support of RSVP-TE. These 179 advertisements include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 180 223 and TLVs for SRLG advertisement. 182 3.1. Legacy sub-TLVs 183 Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 185 Code Point/Attribute Name 186 -------------------------- 187 3 Administrative group (color) 188 9 Maximum link bandwidth 189 10 Maximum reservable link bandwidth 190 11 Unreserved bandwidth 191 14 Extended Administrative Group 192 18 TE Default Metric 193 33 Unidirectional Link Delay 194 34 Min/Max Unidirectional Link Delay 195 35 Unidirectional Delay Variation 196 36 Unidirectional Link Loss 197 37 Unidirectional Residual Bandwidth 198 38 Unidirectional Available Bandwidth 199 39 Unidirectional Utilized Bandwidth 201 3.2. Legacy SRLG Advertisements 203 TLV 138 GMPLS-SRLG 204 Supports links identified by IPv4 addresses and 205 unnumbered links 207 TLV 139 IPv6 SRLG 208 Supports links identified by IPv6 addresses 210 Note that [RFC6119] prohibits the use of TLV 139 when it is possible 211 to use TLV 138. 213 4. Advertising Application Specific Link Attributes 215 Two new code points are defined in support of Application Specific 216 Link Attribute Advertisements: 218 1) Application Specific Link Attributes sub-TLV for TLVs 22, 23, 25, 219 141, 222, and 223 (defined in Section 4.2 ). 221 2)Application Specific Shared Risk Link Group (SRLG) TLV (defined in 222 Section 4.3). 224 In support of these new advertisements, an application identifier bit 225 mask is defined which identifies the application(s) associated with a 226 given advertisement (defined in Section 4.1). 228 The following sections define the format of these new advertisements. 230 4.1. Application Identifier Bit Mask 232 Identification of the set of applications associated with link 233 attribute advertisements utilizes two bit masks. One bit mask is for 234 standard applications where the definition of each bit is defined in 235 a new IANA controlled registry. A second bit mask is for non- 236 standard User Defined Applications(UDAs). 238 The encoding defined below is used by both the Application Specific 239 Link Attributes sub-TLV and the Application Specific SRLG TLV. 241 0 1 2 3 4 5 6 7 242 +--+--+--+--+--+--+--+--+ 243 | SABM Length + Flag | 1 octet 244 +--+--+--+--+--+--+--+--+ 245 | UDABM Length + Flag | 1 octet 246 +--+--+--+--+--+--+--+--+ 247 | SABM ... 0 - 127 octets 248 +--+--+--+--+--+--+--+--+ 249 | UDABM ... 0 - 127 octets 250 +--+--+--+--+--+--+--+--+ 252 SABM Length + Flag (1 octet) 253 Standard Application Identifier Bit Mask 254 Length + Flag 256 0 1 2 3 4 5 6 7 257 +-+-+-+-+-+-+-+-+ 258 |L| SABM Length | 259 +-+-+-+-+-+-+-+-+ 261 L-flag: When set, applications listed (both Standard 262 and User Defined) MUST use the legacy advertisements 263 for the corresponding link found in TLVs 22, 23, 264 25, 141, 222, and 223 or TLV 138 or TLV 139 as 265 appropriate. 267 SABM Length: Indicates the length in octets (0-127) of the 268 Bit Mask for Standard Applications. 270 UDABM Length + Flag (1 octet) 271 User Defined Application Identifier Bit Mask 272 Length + Flag 274 0 1 2 3 4 5 6 7 275 +-+-+-+-+-+-+-+-+ 276 |R| UDABM Length| 277 +-+-+-+-+-+-+-+-+ 279 R: Reserved. SHOULD be transmitted as 0 and 280 MUST be ignored on receipt 282 UDABM Length: Indicates the length in octets (0-127) of the 283 Bit Mask for User Defined Applications. 285 SABM (variable length) 286 Standard Application Identifier Bit Mask 288 (SABM Length * 8) bits 290 This is omitted if SABM Length is 0. 292 0 1 2 3 4 5 6 7 ... 293 +-+-+-+-+-+-+-+-+... 294 |R|S|F| ... 295 +-+-+-+-+-+-+-+-+... 297 R-bit: Set to specify RSVP-TE 299 S-bit: Set to specify Segment Routing 300 Traffic Engineering (SRTE) 302 F-bit: Set to specify Loop Free Alternate (LFA) 303 (includes all LFA types) 305 UDABM (variable length) 306 User Defined Application Identifier Bit Mask 308 (UDABM Length * 8) bits 310 0 1 2 3 4 5 6 7 ... 311 +-+-+-+-+-+-+-+-+... 312 | ... 313 +-+-+-+-+-+-+-+-+... 315 This is omitted if UDABM Length is 0. 317 NOTE: If both SABM Length and UDABM Length are zero, then the 318 attributes associated with this Attribute Identifier Bit Mask 319 MAY be used by any Standard Application and any User Defined 320 Application. 322 Standard Application Identifier Bits are defined/sent starting with 323 Bit 0. Additional bit definitions that may be defined in the future 324 SHOULD be assigned in ascending bit order so as to minimize the 325 number of octets that will need to be transmitted. Undefined bits 326 MUST be transmitted as 0 and MUST be ignored on receipt. Bits that 327 are NOT transmitted MUST be treated as if they are set to 0 on 328 receipt. 330 User Defined Application Identifier Bits have no relationship to 331 Standard Application Identifier Bits and are NOT managed by IANA or 332 any other standards body. It is recommended that bits are used 333 starting with Bit 0 so as to minimize the number of octets required 334 to advertise all UDAs. 336 4.2. Application Specific Link Attributes sub-TLV 338 A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined which 339 supports specification of the applications and application specific 340 attribute values. 342 Type: 16 (temporarily assigned by IANA) 343 Length: Variable (1 octet) 344 Value: 346 Application Identifier Bit Mask 347 (as defined in Section 4.1) 349 Link Attribute sub-sub-TLVs - format matches the 350 existing formats defined in [RFC5305] and [RFC8570] 352 When the L-flag is set in the Application Identifier Bit Mask, all of 353 the applications specified in the bit mask MUST use the link 354 attribute sub-TLV advertisements listed in Section 3.1 for the 355 corresponding link. Link attribute sub-sub-TLVs for the 356 corresponding link attributes MUST NOT be advertised for the set of 357 applications specified in the Standard/User Application Identifier 358 Bit Masks and all such advertisements MUST be ignored on receipt. 360 Multiple Application Specific Link Attribute sub-TLVs for the same 361 link MAY be advertised. When multiple sub-TLVs for the same link are 362 advertised, they SHOULD advertise non-conflicting application/ 363 attribute pairs. A conflict exists when the same application is 364 associated with two different values of the same link attribute for a 365 given link. In cases where conflicting values for the same 366 application/attribute/link are advertised all the conflicting values 367 MUST be ignored. 369 For a given application, the setting of the L-flag MUST be the same 370 in all sub-TLVs for a given link. In cases where this constraint is 371 violated, the L-flag MUST be considered set for this application. 373 A new registry of sub-sub-TLVs is to be created by IANA which defines 374 the link attribute sub-sub-TLV code points. This document defines a 375 sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1 376 except as noted below. The format of the sub-sub-TLVs matches the 377 format of the corresponding legacy sub-TLV and IANA is requested to 378 assign the legacy sub-TLV identifer to the corresponding sub-sub-TLV. 380 4.2.1. Special Considerations for Maximum Link Bandwidth 382 Maximum link bandwidth is an application independent attribute of the 383 link. When advertised using the Application Specific Link Attributes 384 sub-TLV, multiple values for the same link MUST NOT be advertised. 385 This can be accomplished most efficiently by having a single 386 advertisement for a given link where the Application Identifier Bit 387 Mask identifies all the applications which are making use of the 388 value for that link. 390 It is also possible to advertise the same value for a given link 391 multiple times with disjoint sets of applications specified in the 392 Application Identifier Bit Mask. This is less efficient but still 393 valid. 395 If different values for Maximum Link Bandwidth for a given link are 396 advertised, all values MUST be ignored. 398 4.2.2. Special Considerations for Unreserved Bandwidth 400 Unreserved bandwidth is an attribute specific to RSVP. When 401 advertised using the Application Specific Link Attributes sub-TLV, 402 bits other than the RSVP-TE(R-bit) MUST NOT be set in the Application 403 Identifier Bit Mask. If an advertisement of Unreserved Bandwidth is 404 received with bits other than the RSVP-TE bit set, the advertisement 405 MUST be ignored. 407 4.3. Application Specific SRLG TLV 409 A new TLV is defined to advertise application specific SRLGs for a 410 given link. Although similar in functionality to TLV 138 (defined by 411 [RFC5307]) and TLV 139 (defined by [RFC6119], a single TLV provides 412 support for IPv4, IPv6, and unnumbered identifiers for a link. 413 Unlike TLVs 138/139, it utilizes sub-TLVs to encode the link 414 identifiers in order to provide the flexible formatting required to 415 support multiple link identifier types. 417 Type: 238 (Temporarily assigned by IANA) 418 Length: Number of octets in the value field (1 octet) 419 Value: 420 Neighbor System-ID + pseudo-node ID (7 octets) 421 Application Identifier Bit Mask 422 (as defined in Section 4.1) 423 Length of sub-TLVs (1 octet) 424 Link Identifier sub-TLVs (variable) 425 0 or more SRLG Values (Each value is 4 octets) 427 The following Link Identifier sub-TLVs are defined. The type 428 values are suggested and will be assigned by IANA - but as 429 the formats are identical to existing sub-TLVs defined for 430 TLVs 22, 23, 25, 141, 222, and 223 the use of the suggested 431 sub-TLV types is strongly encouraged. 433 Type Description 434 4 Link Local/Remote Identifiers (see [RFC5307]) 435 6 IPv4 interface address (see [RFC5305]) 436 8 IPv4 neighbor address (see [RFC5305]) 437 12 IPv6 Interface Address (see [RFC6119]) 438 13 IPv6 Neighbor Address (see [RFC6119]) 440 At least one set of link identifiers (IPv4, IPv6, or unnumbered) MUST 441 be present. TLVs which do not meet this requirement MUST be ignored. 443 Multiple TLVs for the same link MAY be advertised. 445 When the L-flag is set in the Application Identifier Bit Mask, SRLG 446 values MUST NOT be included in the TLV. Any SRLG values which are 447 advertised MUST be ignored. Based on the link identifiers advertised 448 the corresponding legacy TLV (see Section 3.2) can be identified and 449 the SRLG values advertised in the legacy TLV MUST be used by the set 450 of applications specified in the Application Identifier Bit Mask. 452 For a given application, the setting of the L-flag MUST be the same 453 in all TLVs for a given link. In cases where this constraint is 454 violated, the L-flag MUST be considered set for this application. 456 5. Deployment Considerations 458 This section discuss deployment considerations associated with the 459 use of application specific link attribute advertisements. 461 5.1. Use of Legacy Advertisements 463 Bit Identifers for Standard Applications are defined in Section 4.1. 464 All of the identifiers defined in this document are associated with 465 applications which were already deployed in some networks prior to 466 the writing of this document. Therefore, such applications have been 467 deployed using the legacy advertisements. The Standard Applications 468 defined in this document MAY continue to use legacy advertisements 469 for a given link so long as at least one of the following conditions 470 is true: 472 o The application is RSVP-TE 474 o The application is SRTE or LFA and RSVP-TE is not deployed 475 anywhere in the network 477 o The application is SRTE or LFA, RSVP-TE is deployed in the 478 network, and both the set of links on which SRTE and/or LFA 479 advertisements are required and the attribute values used by SRTE 480 and/or LFA on all such links is fully congruent with the links and 481 attribute values used by RSVP-TE 483 Under the conditions defined above, implementations which support the 484 extensions defined in this document have the choice of using legacy 485 advertisements or application specific advertisements in support of 486 SRTE and/or LFA. This will require implementations to provide 487 controls specifying which type of advertisements are to be sent/ 488 processed on receive for these applications. Further discussion of 489 the associated issues can be found in Section 7. 491 New applications which future documents define to make use of the 492 advertisements defined in this document MUST NOT make use of legacy 493 advertisements. 495 5.2. Use of Zero Length Application Identifier Bit Masks 497 If link attributes are advertised associated with zero length 498 Application Identifier Bit Masks for both standard applications and 499 user defined applications, then that set of link attributes MAY be 500 used by any application. If support for a new application is 501 introduced on any node in a network in the presence of such 502 advertisements, these advertisements MAY be used by the new 503 application. If this is not what is intended, then existing 504 advertisements MUST be readvertised with an explicit set of 505 applications specified before a new application is introduced. 507 6. Attribute Advertisements and Enablement 509 This document defines extensions to support the advertisement of 510 application specific link attributes. 512 Whether the presence of link attribute advertisements for a given 513 application indicates that the application is enabled on that link 514 depends upon the application. Similarly, whether the absence of link 515 attribute advertisements indicates that the application is not 516 enabled depends upon the application. 518 In the case of RSVP-TE, the advertisement of application specific 519 link attributes implies that RSVP is enabled on that link. The 520 absence of RSVP-TE application specific link attributes in 521 combination with the absence of legacy advertisements implies that 522 RSVP is NOT enabled on that link. 524 In the case of SRTE, advertisement of application specific link 525 attributes does NOT indicate enablement of SRTE. The advertisements 526 are only used to support constraints which may be applied when 527 specifying an explicit path. SRTE is implicitly enabled on all links 528 which are part of the Segment Routing enabled topology independent of 529 the existence of link attribute advertisements 531 In the case of LFA, advertisement of application specific link 532 attributes does NOT indicate enablement of LFA on that link. 533 Enablement is controlled by local configuration. 535 If, in the future, additional standard applications are defined to 536 use this mechanism, the specification defining this use MUST define 537 the relationship between application specific link attribute 538 advertisements and enablement for that application. 540 This document allows the advertisement of application specific link 541 attributes with no application identifiers i.e., both the Standard 542 Application Identifier Bit Mask and the User Defined Application 543 Identifier Bit Mask are not present (See Section 4.1). This supports 544 the use of the link attribute by any application. In the presence of 545 an application where the advertisement of link attribute 546 advertisements is used to infer the enablement of an application on 547 that link (e.g., RSVP-TE), the absence of the application identifier 548 leaves ambiguous whether that application is enabled on such a link. 549 This needs to be considered when making use of the "any application" 550 encoding. 552 7. Interoperability, Backwards Compatibility and Migration Concerns 554 Existing deployments of RSVP-TE, SRTE, and/or LFA utilize the legacy 555 advertisements listed in Section 3. Routers which do not support the 556 extensions defined in this document will only process legacy 557 advertisements and are likely to infer that RSVP-TE is enabled on the 558 links for which legacy advertisements exist. It is expected that 559 deployments using the legacy advertisements will persist for a 560 significant period of time - therefore deployments using the 561 extensions defined in this document must be able to co-exist with use 562 of the legacy advertisements by routers which do not support the 563 extensions defined in this document. The following sub-sections 564 discuss interoperability and backwards compatibility concerns for a 565 number of deployment scenarios. 567 Note that in all cases the defined strategy can be employed on a per 568 link basis. 570 7.1. Multiple Applications: Common Attributes with RSVP-TE 572 In cases where multiple applications are utilizing a given link, one 573 of the applications is RSVP-TE, and all link attributes for a given 574 link are common to the set of applications utilizing that link, 575 interoperability is achieved by using legacy advertisements and 576 sending application specific advertisements with L-bit set and no 577 link attribute values. This avoids duplication of link attribute 578 advertisements. 580 7.2. Multiple Applications: All Attributes Not Shared w RSVP-TE 582 In cases where one or more applications other than RSVP-TE are 583 utilizing a given link and one or more link attribute values are NOT 584 shared with RSVP-TE, it is necessary to use application specific 585 advertisements as defined in this document. Attributes for 586 applications other than RSVP-TE MUST be advertised using application 587 specific advertisements which have the L-bit clear. In cases where 588 some link attributes are shared with RSVP-TE, this requires duplicate 589 advertisements for those attributes. 591 The discussion in this section applies to cases where RSVP-TE is NOT 592 using any advertised attributes on a link and to cases where RSVP-TE 593 is using some link attribute advertisements on the link but some link 594 attributes cannot be shared with RSVP-TE. 596 7.3. Use of Application Specific Advertisements for RSVP-TE 598 The extensions defined in this document support RSVP-TE as one of the 599 supported applications. This allows that RSVP-TE could eventually 600 utilize the application specific advertisements. This can be done in 601 the following step-wise manner: 603 1)Upgrade all routers to support extensions in this document 605 2)Readvertise all legacy link attributes using application specific 606 advertisements with L-bit clear and R-bit set. 608 3)Remove legacy advertisements 610 Migrating RSVP-TE away from legacy advertisements could result in 611 some implementation simplification as it allows the removal of code 612 which encodes/decodes the legacy advertisements. Whether this is 613 seen as desirable is something for the marketplace to determine. 615 8. IANA Considerations 617 This document defines a new sub-TLV for TLVs 22, 23, 25, 141, 222, 618 and 223. 620 Type Description 22 23 25 141 222 223 621 ---- --------------------- ---- ---- ---- ---- ---- ---- 622 16 Application Specific y y y(s) y y y 623 Link Attributes 625 This document defines one new TLV: 627 Type Description IIH LSP SNP Purge 628 ---- --------------------- --- --- --- ----- 629 238 Application Specific n y n n 630 SRLG 632 This document requests a new IANA registry be created to control the 633 assignment of sub-sub-TLV codepoints for the Application Specific 634 Link Attributes sub-TLV. The suggested name of the new registry is 635 "sub-sub-TLV code points for application specific link attributes". 636 The registration procedure is "Expert Review" as defined in 637 [RFC8126]. The following assignments are made by this document: 639 Type Description 640 --------------------------------------------------------- 641 0-2 Unassigned 642 3 Administrative group (color) 643 4-8 Unassigned 644 9 Maximum link bandwidth 645 10 Maximum reservable link bandwidth 646 11 Unreserved bandwidth 647 12-13 Unassigned 648 14 Extended Administrative Group 649 15-17 Unassigned 650 18 TE Default Metric 651 19-32 Unassigned 652 33 Unidirectional Link Delay 653 34 Min/Max Unidirectional Link Delay 654 35 Unidirectional Delay Variation 655 36 Unidirectional Link Loss 656 37 Unidirectional Residual Bandwidth 657 38 Unidirectional Available Bandwidth 658 39 Unidirectional Utilized Bandwidth 659 40-255 Unassigned 661 This document requests a new IANA registry be created, under the 662 category of "Interior Gateway Protocol (IGP) Parameters", to control 663 the assignment of Application Identifier Bits. The suggested name of 664 the new registry is "Link Attribute Applications". The registration 665 policy for this registry is "Standards Action" ([RFC8126] and 666 [RFC7120]). The following assignments are made by this document: 668 Bit # Name 669 --------------------------------------------------------- 670 0 RSVP-TE (R-bit) 671 1 Segment Routing Traffic Engineering (S-bit) 672 2 Loop Free Alternate (F-bit) 674 This document requests a new IANA registry be created to control the 675 assignment of sub-TLV types for the application specific SRLG TLV. 676 The suggested name of the new registry is "Sub-TLVs for TLV 238". 677 The registration procedure is "Expert Review" as defined in 678 [RFC8126]. The following assignments are made by this document: 680 Value Description 681 --------------------------------------------------------- 682 0-3 Unassigned 683 4 Link Local/Remote Identifiers (see [RFC5307]) 684 5 Unassigned 685 6 IPv4 interface address (see [RFC5305]) 686 7 Unassigned 687 8 IPv4 neighbor address (see [RFC5305]) 688 9-11 Unassigned 689 12 IPv6 Interface Address (see [RFC6119]) 690 13 IPv6 Neighbor Address (see [RFC6119]) 691 14-255 Unassigned 693 9. Security Considerations 695 Security concerns for IS-IS are addressed in [ISO10589, [RFC5304], 696 and [RFC5310]. 698 10. Acknowledgements 700 The authors would like to thank Eric Rosen and Acee Lindem for their 701 careful review and content suggestions. 703 11. References 705 11.1. Normative References 707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 708 Requirement Levels", BCP 14, RFC 2119, 709 DOI 10.17487/RFC2119, March 1997, 710 . 712 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 713 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 714 2008, . 716 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 717 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 718 2008, . 720 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 721 in Support of Generalized Multi-Protocol Label Switching 722 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 723 . 725 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 726 and M. Fanto, "IS-IS Generic Cryptographic 727 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 728 2009, . 730 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 731 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 732 February 2011, . 734 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 735 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 736 2014, . 738 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 739 Writing an IANA Considerations Section in RFCs", BCP 26, 740 RFC 8126, DOI 10.17487/RFC8126, June 2017, 741 . 743 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 744 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 745 May 2017, . 747 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 748 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 749 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 750 2019, . 752 11.2. Informative References 754 [I-D.ietf-spring-segment-routing-policy] 755 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 756 bogdanov@google.com, b., and P. Mattes, "Segment Routing 757 Policy Architecture", draft-ietf-spring-segment-routing- 758 policy-03 (work in progress), May 2019. 760 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 761 Litkowski, S., Horneffer, M., and R. Shakir, "Source 762 Packet Routing in Networking (SPRING) Problem Statement 763 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 764 2016, . 766 Authors' Addresses 767 Les Ginsberg 768 Cisco Systems 769 821 Alder Drive 770 Milpitas, CA 95035 771 USA 773 Email: ginsberg@cisco.com 775 Peter Psenak 776 Cisco Systems 777 Apollo Business Center Mlynske nivy 43 778 Bratislava 821 09 779 Slovakia 781 Email: ppsenak@cisco.com 783 Stefano Previdi 784 Huawei 786 Email: stefano@previdi.net 788 Wim Henderickx 789 Nokia 790 Copernicuslaan 50 791 Antwerp 2018 94089 792 Belgium 794 Email: wim.henderickx@nokia.com 796 John Drake 797 Juniper Networks 799 Email: jdrake@juniper.net