idnits 2.17.1 draft-ietf-isis-te-app-07.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 4, 2019) is 1663 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 6, 2020 S. Previdi 6 Huawei 7 W. Henderickx 8 Nokia 9 J. Drake 10 Juniper Networks 11 October 4, 2019 13 IS-IS TE Attributes per application 14 draft-ietf-isis-te-app-07 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 6, 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 6. Attribute Advertisements and Enablement . . . . . . . . . . . 11 89 7. Interoperability, Backwards Compatibility and Migration 90 Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7.1. RSVP-TE only deployments . . . . . . . . . . . . . . . . 12 92 7.2. Multiple Applications: Common Attributes with RSVP-TE . 12 93 7.3. Multiple Applications: All Attributes Not Shared w RSVP- 94 TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 7.4. Use of Application Specific Advertisements for RSVP-TE . 13 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 101 11.2. Informative References . . . . . . . . . . . . . . . . . 16 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 104 1. Introduction 106 Advertisement of link attributes by the Intermediate-System-to- 107 Intermediate-System (IS-IS) protocol in support of traffic 108 engineering (TE) was introduced by [RFC5305] and extended by 109 [RFC5307], [RFC6119], and [RFC8570]. Use of these extensions has 110 been associated with deployments supporting Traffic Engineering over 111 Multiprotocol Label Switching (MPLS) in the presence of Resource 112 Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE. 114 In recent years new applications have been introduced which have use 115 cases for many of the link attributes historically used by RSVP-TE. 116 Such applications include Segment Routing Traffic Engineering (SRTE) 117 and Loop Free Alternates (LFA). This has introduced ambiguity in 118 that if a deployment includes a mix of RSVP-TE support and SRTE 119 support (for example) it is not possible to unambiguously indicate 120 which advertisements are to be used by RSVP-TE and which 121 advertisements are to be used by SRTE. If the topologies are fully 122 congruent this may not be an issue, but any incongruence leads to 123 ambiguity. 125 An additional issue arises in cases where both applications are 126 supported on a link but the link attribute values associated with 127 each application differ. Current advertisements do not support 128 advertising application specific values for the same attribute on a 129 specific link. 131 This document defines extensions which address these issues. Also, 132 as evolution of use cases for link attributes can be expected to 133 continue in the years to come, this document defines a solution which 134 is easily extensible to the introduction of new applications and new 135 use cases. 137 2. Requirements Discussion 139 As stated previously, evolution of use cases for link attributes can 140 be expected to continue - so any discussion of existing use cases is 141 limited to requirements which are known at the time of this writing. 142 However, in order to determine the functionality required beyond what 143 already exists in IS-IS, it is only necessary to discuss use cases 144 which justify the key points identified in the introduction - which 145 are: 147 1. Support for indicating which applications are using the link 148 attribute advertisements on a link 150 2. Support for advertising application specific values for the same 151 attribute on a link 153 [RFC7855] discusses use cases/requirements for SR. Included among 154 these use cases is SRTE which is defined in 155 [I-D.ietf-spring-segment-routing-policy]. If both RSVP-TE and SRTE 156 are deployed in a network, link attribute advertisements can be used 157 by one or both of these applications. As there is no requirement for 158 the link attributes advertised on a given link used by SRTE to be 159 identical to the link attributes advertised on that same link used by 160 RSVP-TE, there is a clear requirement to indicate independently which 161 link attribute advertisements are to be used by each application. 163 As the number of applications which may wish to utilize link 164 attributes may grow in the future, an additional requirement is that 165 the extensions defined allow the association of additional 166 applications to link attributes without altering the format of the 167 advertisements or introducing new backwards compatibility issues. 169 Finally, there may still be many cases where a single attribute value 170 can be shared among multiple applications, so the solution must 171 minimize advertising duplicate link/attribute pairs whenever 172 possible. 174 3. Legacy Advertisements 176 There are existing advertisements used in support of RSVP-TE. These 177 advertisements include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 178 223 and TLVs for SRLG advertisement. 180 3.1. Legacy sub-TLVs 181 Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 183 Code Point/Attribute Name 184 -------------------------- 185 3 Administrative group (color) 186 9 Maximum link bandwidth 187 10 Maximum reservable link bandwidth 188 11 Unreserved bandwidth 189 14 Extended Administrative Group 190 18 TE Default Metric 191 33 Unidirectional Link Delay 192 34 Min/Max Unidirectional Link Delay 193 35 Unidirectional Delay Variation 194 36 Unidirectional Link Loss 195 37 Unidirectional Residual Bandwidth 196 38 Unidirectional Available Bandwidth 197 39 Unidirectional Utilized Bandwidth 199 3.2. Legacy SRLG Advertisements 201 TLV 138 GMPLS-SRLG 202 Supports links identified by IPv4 addresses and 203 unnumbered links 205 TLV 139 IPv6 SRLG 206 Supports links identified by IPv6 addresses 208 Note that [RFC6119] prohibits the use of TLV 139 when it is possible 209 to use TLV 138. 211 4. Advertising Application Specific Link Attributes 213 Two new code points are defined in support of Application Specific 214 Link Attribute Advertisements: 216 1) Application Specific Link Attributes sub-TLV for TLVs 22, 23, 25, 217 141, 222, and 223 (defined in Section 4.2 ). 219 2)Application Specific Shared Risk Link Group (SRLG) TLV (defined in 220 Section 4.3). 222 In support of these new advertisements, an application identifier bit 223 mask is defined which identifies the application(s) associated with a 224 given advertisement (defined in Section 4.1). 226 The following sections define the format of these new advertisements. 228 4.1. Application Identifier Bit Mask 230 Identification of the set of applications associated with link 231 attribute advertisements utilizes two bit masks. One bit mask is for 232 standard applications where the definition of each bit is defined in 233 a new IANA controlled registry. A second bit mask is for non- 234 standard User Defined Applications(UDAs). 236 The encoding defined below is used by both the Application Specific 237 Link Attributes sub-TLV and the Application Specific SRLG TLV. 239 0 1 2 3 4 5 6 7 240 +-+-+-+-+-+-+-+-+ 241 | SABML+F | 1 octet 242 +-+-+-+-+-+-+-+-+ 243 | UDABML+F | 1 octet 244 +-+-+-+-+-+-+-+-+ 245 | SABM ... 0 - 127 octets 246 +-+-+-+-+-+-+-+-+ 247 | UDABM ... 0 - 127 octets 248 +-+-+-+-+-+-+-+-+ 250 SABML+F (1 octet) 251 Standard Application Identifier Bit Mask 252 Length/Flags 254 0 1 2 3 4 5 6 7 255 +-+-+-+-+-+-+-+-+ 256 |L| SA-Length | 257 +-+-+-+-+-+-+-+-+ 259 L-flag: When set, applications listed (both Standard 260 and User Defined) MUST use the legacy advertisements 261 for the corresponding link found in TLVs 22, 23, 262 25, 141, 222, and 223 or TLV 138 or TLV 139 as 263 appropriate. 265 SA-Length: Indicates the length in octets (0-127) of the Bit Mask 266 for Standard Applications. 268 UDABML+F (1 octet) 269 User Defined Application Identifier Bit Mask 270 Length/Flags 272 0 1 2 3 4 5 6 7 273 +-+-+-+-+-+-+-+-+ 274 |R| UDA-Length | 275 +-+-+-+-+-+-+-+-+ 277 R: Reserved. SHOULD be transmitted as 0 and 278 MUST be ignored on receipt 280 UDA-Length: Indicates the length in octets (0-127) of the Bit Mask 281 for User Defined Applications. 283 SABM (variable length) 284 Standard Application Identifier Bit Mask 286 (SA-Length * 8) bits 288 This is omitted if SA-Length is 0. 290 0 1 2 3 4 5 6 7 ... 291 +-+-+-+-+-+-+-+-+... 292 |R|S|F| ... 293 +-+-+-+-+-+-+-+-+... 295 R-bit: Set to specify RSVP-TE 297 S-bit: Set to specify Segment Routing 298 Traffic Engineering 300 F-bit: Set to specify Loop Free Alternate 301 (includes all LFA types) 303 UDABM (variable length) 304 User Defined Application Identifier Bit Mask 306 (UDA-Length * 8) bits 308 0 1 2 3 4 5 6 7 ... 309 +-+-+-+-+-+-+-+-+... 310 | ... 311 +-+-+-+-+-+-+-+-+... 313 This is omitted if UDA-Length is 0. 315 NOTE: If both SA-length and UDA-Length are zero, then the 316 attributes associated with this Attribute Identifier Bit Mask 317 MAY be used by any Standard Application and any User Defined 318 Application. 320 Standard Application Identifier Bits are defined/sent starting with 321 Bit 0. Additional bit definitions that may be defined in the future 322 SHOULD be assigned in ascending bit order so as to minimize the 323 number of octets that will need to be transmitted. Undefined bits 324 MUST be transmitted as 0 and MUST be ignored on receipt. Bits that 325 are NOT transmitted MUST be treated as if they are set to 0 on 326 receipt. 328 User Defined Application Identifier Bits have no relationship to 329 Standard Application Identifier Bits and are NOT managed by IANA or 330 any other standards body. It is recommended that bits are used 331 starting with Bit 0 so as to minimize the number of octets required 332 to advertise all UDAs. 334 4.2. Application Specific Link Attributes sub-TLV 336 A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined which 337 supports specification of the applications and application specific 338 attribute values. 340 Type: 16 (temporarily assigned by IANA) 341 Length: Variable (1 octet) 342 Value: 344 Application Identifier Bit Mask 345 (as defined in Section 4.1) 347 Link Attribute sub-sub-TLVs - format matches the 348 existing formats defined in [RFC5305] and [RFC8570] 350 When the L-flag is set in the Application Identifier Bit Mask, all of 351 the applications specified in the bit mask MUST use the link 352 attribute sub-TLV advertisements listed in Section 3.1 for the 353 corresponding link. Link attribute sub-sub-TLVs for the 354 corresponding link attributes MUST NOT be advertised for the set of 355 applications specified in the Standard/User Application Identifier 356 Bit Masks and all such advertisements MUST be ignored on receipt. 358 Multiple Application Specific Link Attribute sub-TLVs for the same 359 link MAY be advertised. When multiple sub-TLVs for the same link are 360 advertised, they SHOULD advertise non-conflicting application/ 361 attribute pairs. A conflict exists when the same application is 362 associated with two different values of the same link attribute for a 363 given link. In cases where conflicting values for the same 364 application/attribute/link are advertised all the conflicting values 365 MUST be ignored. 367 For a given application, the setting of the L-flag MUST be the same 368 in all sub-TLVs for a given link. In cases where this constraint is 369 violated, the L-flag MUST be considered set for this application. 371 A new registry of sub-sub-TLVs is to be created by IANA which defines 372 the link attribute sub-sub-TLV code points. This document defines a 373 sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1 374 except as noted below. The format of the sub-sub-TLVs matches the 375 format of the corresponding legacy sub-TLV and IANA is requested to 376 assign the legacy sub-TLV identifer to the corresponding sub-sub-TLV. 378 4.2.1. Special Considerations for Maximum Link Bandwidth 380 Maximum link bandwidth is an application independent attribute of the 381 link. When advertised using the Application Specific Link Attributes 382 sub-TLV, multiple values for the same link MUST NOT be advertised. 383 This can be accomplished most efficiently by having a single 384 advertisement for a given link where the Application Identifier Bit 385 Mask identifies all the applications which are making use of the 386 value for that link. 388 It is also possible to advertise the same value for a given link 389 multiple times with disjoint sets of applications specified in the 390 Application Identifier Bit Mask. This is less efficient but still 391 valid. 393 If different values for Maximum Link Bandwidth for a given link are 394 advertised, all values MUST be ignored. 396 4.2.2. Special Considerations for Unreserved Bandwidth 398 Unreserved bandwidth is an attribute specific to RSVP. When 399 advertised using the Application Specific Link Attributes sub-TLV, 400 bits other than the RSVP-TE(R-bit) MUST NOT be set in the Application 401 Identifier Bit Mask. If an advertisement of Unreserved Bandwidth is 402 received with bits other than the RSVP-TE bit set, the advertisement 403 MUST be ignored. 405 4.3. Application Specific SRLG TLV 407 A new TLV is defined to advertise application specific SRLGs for a 408 given link. Although similar in functionality to TLV 138 (defined by 409 [RFC5307]) and TLV 139 (defined by [RFC6119], a single TLV provides 410 support for IPv4, IPv6, and unnumbered identifiers for a link. 411 Unlike TLVs 138/139, it utilizes sub-TLVs to encode the link 412 identifiers in order to provide the flexible formatting required to 413 support multiple link identifier types. 415 Type: 238 (Temporarily assigned by IANA) 416 Length: Number of octets in the value field (1 octet) 417 Value: 418 Neighbor System-ID + pseudo-node ID (7 octets) 419 Application Identifier Bit Mask 420 (as defined in Section 4.1) 421 Length of sub-TLVs (1 octet) 422 Link Identifier sub-TLVs (variable) 423 0 or more SRLG Values (Each value is 4 octets) 425 The following Link Identifier sub-TLVs are defined. The type 426 values are suggested and will be assigned by IANA - but as 427 the formats are identical to existing sub-TLVs defined for 428 TLVs 22, 23, 25, 141, 222, and 223 the use of the suggested 429 sub-TLV types is strongly encouraged. 431 Type Description 432 4 Link Local/Remote Identifiers (see [RFC5307]) 433 6 IPv4 interface address (see [RFC5305]) 434 8 IPv4 neighbor address (see [RFC5305]) 435 12 IPv6 Interface Address (see [RFC6119]) 436 13 IPv6 Neighbor Address (see [RFC6119]) 438 At least one set of link identifiers (IPv4, IPv6, or unnumbered) MUST 439 be present. TLVs which do not meet this requirement MUST be ignored. 441 Multiple TLVs for the same link MAY be advertised. 443 When the L-flag is set in the Application Identifier Bit Mask, SRLG 444 values MUST NOT be included in the TLV. Any SRLG values which are 445 advertised MUST be ignored. Based on the link identifiers advertised 446 the corresponding legacy TLV (see Section 3.2) can be identified and 447 the SRLG values advertised in the legacy TLV MUST be used by the set 448 of applications specified in the Application Identifier Bit Mask. 450 For a given application, the setting of the L-flag MUST be the same 451 in all TLVs for a given link. In cases where this constraint is 452 violated, the L-flag MUST be considered set for this application. 454 5. Deployment Considerations 456 If link attributes are advertised associated with zero length 457 Application Identifier Bit Masks for both standard applications and 458 user defined applications, then that set of link attributes MAY be 459 used by any application. If support for a new application is 460 introduced on any node in a network in the presence of such 461 advertisements, these advertisements MAY be used by the new 462 application. If this is not what is intended, then existing 463 advertisements MUST be readvertised with an explicit set of 464 applications specified before a new application is introduced. 466 6. Attribute Advertisements and Enablement 468 This document defines extensions to support the advertisement of 469 application specific link attributes. 471 Whether the presence of link attribute advertisements for a given 472 application indicates that the application is enabled on that link 473 depends upon the application. Similarly, whether the absence of link 474 attribute advertisements indicates that the application is not 475 enabled depends upon the application. 477 In the case of RSVP-TE, the advertisement of application specific 478 link attributes implies that RSVP is enabled on that link. 480 In the case of SRTE, advertisement of application specific link 481 attributes does NOT indicate enablement of SRTE. The advertisements 482 are only used to support constraints which may be applied when 483 specifying an explicit path. SRTE is implicitly enabled on all links 484 which are part of the Segment Routing enabled topology independent of 485 the existence of link attribute advertisements 487 In the case of LFA, advertisement of application specific link 488 attributes does NOT indicate enablement of LFA on that link. 489 Enablement is controlled by local configuration. 491 If, in the future, additional standard applications are defined to 492 use this mechanism, the specification defining this use MUST define 493 the relationship between application specific link attribute 494 advertisements and enablement for that application. 496 This document allows the advertisement of application specific link 497 attributes with no application identifiers i.e., both the Standard 498 Application Identifier Bit Mask and the User Defined Application 499 Identifier Bit Mask are not present (See Section 4.1). This supports 500 the use of the link attribute by any application. In the presence of 501 an application where the advertisement of link attribute 502 advertisements is used to infer the enablement of an application on 503 that link (e.g., RSVP-TE), the absence of the application identifier 504 leaves ambiguous whether that application is enabled on such a link. 505 This needs to be considered when making use of the "any application" 506 encoding. 508 7. Interoperability, Backwards Compatibility and Migration Concerns 510 Existing deployments of RSVP-TE utilize the legacy advertisements 511 listed in Section 3. Routers which do not support the extensions 512 defined in this document will only process legacy advertisements and 513 are likely to infer that RSVP-TE is enabled on the links for which 514 legacy advertisements exist. It is expected that deployments using 515 the legacy advertisements will persist for a significant period of 516 time - therefore deployments using the extensions defined in this 517 document must be able to co-exist with use of the legacy 518 advertisements by routers which do not support the extensions defined 519 in this document. The following sub-sections discuss 520 interoperability and backwards compatibility concerns for a number of 521 deployment scenarios. 523 Note that in all cases the defined strategy can be employed on a per 524 link basis. 526 7.1. RSVP-TE only deployments 528 In deployments where RSVP-TE is the only application utilizing link 529 attribute advertisements, use of the the legacy advertisements can 530 continue without change. 532 7.2. Multiple Applications: Common Attributes with RSVP-TE 534 In cases where multiple applications are utilizing a given link, one 535 of the applications is RSVP-TE, and all link attributes for a given 536 link are common to the set of applications utilizing that link, 537 interoperability is achieved by using legacy advertisements and 538 sending application specific advertisements with L-bit set and no 539 link attribute values. This avoids duplication of link attribute 540 advertisements. 542 7.3. Multiple Applications: All Attributes Not Shared w RSVP-TE 544 In cases where one or more applications other than RSVP-TE are 545 utilizing a given link and one or more link attribute values are NOT 546 shared with RSVP-TE, it is necessary to use application specific 547 advertisements as defined in this document. Attributes for 548 applications other than RSVP-TE MUST be advertised using application 549 specific advertisements which have the L-bit clear. In cases where 550 some link attributes are shared with RSVP-TE, this requires duplicate 551 advertisements for those attributes. 553 The discussion in this section applies to cases where RSVP-TE is NOT 554 using any advertised attributes on a link and to cases where RSVP-TE 555 is using some link attribute advertisements on the link but some link 556 attributes cannot be shared with RSVP-TE. 558 7.4. Use of Application Specific Advertisements for RSVP-TE 560 The extensions defined in this document support RSVP-TE as one of the 561 supported applications. This allows that RSVP-TE could eventually 562 utilize the application specific advertisements. This can be done in 563 the following step-wise manner: 565 1)Upgrade all routers to support extensions in this document 567 2)Readvertise all legacy link attributes using application specific 568 advertisements with L-bit clear and R-bit set. 570 3)Remove legacy advertisements 572 Migrating RSVP-TE away from legacy advertisements could result in 573 some implementation simplification as it allows the removal of code 574 which encodes/decodes the legacy advertisements. Whether this is 575 seen as desirable is something for the marketplace to determine. 577 8. IANA Considerations 579 This document defines a new sub-TLV for TLVs 22, 23, 25, 141, 222, 580 and 223. 582 Type Description 22 23 25 141 222 223 583 ---- --------------------- ---- ---- ---- ---- ---- ---- 584 16 Application Specific y y y(s) y y y 585 Link Attributes 587 This document defines one new TLV: 589 Type Description IIH LSP SNP Purge 590 ---- --------------------- --- --- --- ----- 591 238 Application Specific n y n n 592 SRLG 594 This document requests a new IANA registry be created to control the 595 assignment of sub-sub-TLV codepoints for the Application Specific 596 Link Attributes sub-TLV. The suggested name of the new registry is 597 "sub-sub-TLV code points for application specific link attributes". 598 The registration procedure is "Expert Review" as defined in 599 [RFC8126]. The following assignments are made by this document: 601 Type Description 602 --------------------------------------------------------- 603 0-2 Unassigned 604 3 Administrative group (color) 605 4-8 Unassigned 606 9 Maximum link bandwidth 607 10 Maximum reservable link bandwidth 608 11 Unreserved bandwidth 609 12-13 Unassigned 610 14 Extended Administrative Group 611 15-17 Unassigned 612 18 TE Default Metric 613 19-32 Unassigned 614 33 Unidirectional Link Delay 615 34 Min/Max Unidirectional Link Delay 616 35 Unidirectional Delay Variation 617 36 Unidirectional Link Loss 618 37 Unidirectional Residual Bandwidth 619 38 Unidirectional Available Bandwidth 620 39 Unidirectional Utilized Bandwidth 621 40-255 Unassigned 623 This document requests a new IANA registry be created, under the 624 category of "Interior Gateway Protocol (IGP) Parameters", to control 625 the assignment of Application Identifier Bits. The suggested name of 626 the new registry is "Link Attribute Applications". The registration 627 policy for this registry is "Standards Action" ([RFC8126] and 628 [RFC7120]). The following assignments are made by this document: 630 Bit # Name 631 --------------------------------------------------------- 632 0 RSVP-TE (R-bit) 633 1 Segment Routing Traffic Engineering (S-bit) 634 2 Loop Free Alternate (F-bit) 636 This document requests a new IANA registry be created to control the 637 assignment of sub-TLV types for the application specific SRLG TLV. 638 The suggested name of the new registry is "Sub-TLVs for TLV 238". 639 The registration procedure is "Expert Review" as defined in 640 [RFC8126]. The following assignments are made by this document: 642 Value Description 643 --------------------------------------------------------- 644 0-3 Unassigned 645 4 Link Local/Remote Identifiers (see [RFC5307]) 646 5 Unassigned 647 6 IPv4 interface address (see [RFC5305]) 648 7 Unassigned 649 8 IPv4 neighbor address (see [RFC5305]) 650 9-11 Unassigned 651 12 IPv6 Interface Address (see [RFC6119]) 652 13 IPv6 Neighbor Address (see [RFC6119]) 653 14-255 Unassigned 655 9. Security Considerations 657 Security concerns for IS-IS are addressed in [ISO10589, [RFC5304], 658 and [RFC5310]. 660 10. Acknowledgements 662 The authors would like to thank Eric Rosen and Acee Lindem for their 663 careful review and content suggestions. 665 11. References 667 11.1. Normative References 669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 670 Requirement Levels", BCP 14, RFC 2119, 671 DOI 10.17487/RFC2119, March 1997, 672 . 674 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 675 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 676 2008, . 678 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 679 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 680 2008, . 682 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 683 in Support of Generalized Multi-Protocol Label Switching 684 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 685 . 687 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 688 and M. Fanto, "IS-IS Generic Cryptographic 689 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 690 2009, . 692 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 693 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 694 February 2011, . 696 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 697 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 698 2014, . 700 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 701 Writing an IANA Considerations Section in RFCs", BCP 26, 702 RFC 8126, DOI 10.17487/RFC8126, June 2017, 703 . 705 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 706 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 707 May 2017, . 709 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 710 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 711 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 712 2019, . 714 11.2. Informative References 716 [I-D.ietf-spring-segment-routing-policy] 717 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 718 bogdanov@google.com, b., and P. Mattes, "Segment Routing 719 Policy Architecture", draft-ietf-spring-segment-routing- 720 policy-03 (work in progress), May 2019. 722 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 723 Litkowski, S., Horneffer, M., and R. Shakir, "Source 724 Packet Routing in Networking (SPRING) Problem Statement 725 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 726 2016, . 728 Authors' Addresses 729 Les Ginsberg 730 Cisco Systems 731 821 Alder Drive 732 Milpitas, CA 95035 733 USA 735 Email: ginsberg@cisco.com 737 Peter Psenak 738 Cisco Systems 739 Apollo Business Center Mlynske nivy 43 740 Bratislava 821 09 741 Slovakia 743 Email: ppsenak@cisco.com 745 Stefano Previdi 746 Huawei 748 Email: stefano@previdi.net 750 Wim Henderickx 751 Nokia 752 Copernicuslaan 50 753 Antwerp 2018 94089 754 Belgium 756 Email: wim.henderickx@nokia.com 758 John Drake 759 Juniper Networks 761 Email: jdrake@juniper.net