idnits 2.17.1 draft-ietf-isis-te-app-04.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 == Line 576 has weird spacing: '...pecific n ...' -- The document date (April 27, 2018) is 2163 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) ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-05 Summary: 1 error (**), 0 flaws (~~), 3 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: October 29, 2018 S. Previdi 6 Huawei 7 W. Henderickx 8 Nokia 9 J. Drake 10 Juniper Networks 11 April 27, 2018 13 IS-IS TE Attributes per application 14 draft-ietf-isis-te-app-04.txt 16 Abstract 18 Existing traffic engineering related link attribute advertisements 19 have been defined and are used in RSVP-TE deployments. In cases 20 where multiple applications wish to make use of these link attributes 21 the current advertisements do not support application specific values 22 for a given attribute nor do they support indication of which 23 applications are using the advertised value for a given link. 25 This draft introduces new link attribute advertisements which address 26 both of these shortcomings. It also discusses backwards 27 compatibility issues and how to minimize duplicate advertisements in 28 the presence of routers which do not support the extensions defined 29 in this document. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 35 "OPTIONAL" in this document are to be interpreted as described in BCP 36 14 [RFC2119] [RFC8174] when, and only when, they appear in all 37 capitals, as shown here. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on October 29, 2018. 56 Copyright Notice 58 Copyright (c) 2018 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3 75 3. Legacy Advertisements . . . . . . . . . . . . . . . . . . . . 4 76 3.1. Legacy sub-TLVs . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. Legacy SRLG Advertisements . . . . . . . . . . . . . . . 5 78 4. Advertising Application Specific Link Attributes . . . . . . 5 79 4.1. Application Identifier Bit Mask . . . . . . . . . . . . . 6 80 4.2. Application Specific Link Attributes sub-TLV . . . . . . 8 81 4.2.1. Special Considerations for Maximum Link Bandwidth . . 9 82 4.2.2. Special Considerations for Unreserved Bandwidth . . . 9 83 4.3. Application Specific SRLG TLV . . . . . . . . . . . . . . 9 84 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 85 6. Attribute Advertisements and Enablement . . . . . . . . . . . 11 86 7. Interoperability, Backwards Compatibility and Migration 87 Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 7.1. RSVP-TE only deployments . . . . . . . . . . . . . . . . 12 89 7.2. Multiple Applications: Common Attributes with RSVP-TE . 12 90 7.3. Multiple Applications: All Attributes Not Shared w RSVP- 91 TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7.4. Deprecating legacy advertisements . . . . . . . . . . . . 13 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 98 11.2. Informative References . . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 101 1. Introduction 103 Advertisement of link attributes by the Intermediate-System-to- 104 Intermediate-System (IS-IS) protocol in support of traffic 105 engineering (TE) was introduced by [RFC5305] and extended by 106 [RFC5307], [RFC6119], and [RFC7810]. Use of these extensions has 107 been associated with deployments supporting Traffic Engineering over 108 Multiprotocol Label Switching (MPLS) in the presence of Resource 109 Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE. 111 In recent years new applications have been introduced which have use 112 cases for many of the link attributes historically used by RSVP-TE. 113 Such applications include Segment Routing Traffic Engineering (SRTE) 114 and Loop Free Alternates (LFA). This has introduced ambiguity in 115 that if a deployment includes a mix of RSVP-TE support and SRTE 116 support (for example) it is not possible to unambiguously indicate 117 which advertisements are to be used by RSVP-TE and which 118 advertisements are to be used by SRTE. If the topologies are fully 119 congruent this may not be an issue, but any incongruence leads to 120 ambiguity. 122 An additional issue arises in cases where both applications are 123 supported on a link but the link attribute values associated with 124 each application differ. Current advertisements do not support 125 advertising application specific values for the same attribute on a 126 specific link. 128 This document defines extensions which address these issues. Also, 129 as evolution of use cases for link attributes can be expected to 130 continue in the years to come, this document defines a solution which 131 is easily extensible to the introduction of new applications and new 132 use cases. 134 2. Requirements Discussion 136 As stated previously, evolution of use cases for link attributes can 137 be expected to continue - so any discussion of existing use cases is 138 limited to requirements which are known at the time of this writing. 139 However, in order to determine the functionality required beyond what 140 already exists in IS-IS, it is only necessary to discuss use cases 141 which justify the key points identified in the introduction - which 142 are: 144 1. Support for indicating which applications are using the link 145 attribute advertisements on a link 147 2. Support for advertising application specific values for the same 148 attribute on a link 150 [RFC7855] discusses use cases/requirements for SR. Included among 151 these use cases is SRTE which is defined in 152 [I-D.filsfils-spring-segment-routing-policy]. If both RSVP-TE and 153 SRTE are deployed in a network, link attribute advertisements can be 154 used by one or both of these applications. As there is no 155 requirement for the link attributes advertised on a given link used 156 by SRTE to be identical to the link attributes advertised on that 157 same link used by RSVP-TE, there is a clear requirement to indicate 158 independently which link attribute advertisements are to be used by 159 each application. 161 As the number of applications which may wish to utilize link 162 attributes may grow in the future, an additional requirement is that 163 the extensions defined allow the association of additional 164 applications to link attributes without altering the format of the 165 advertisements or introducing new backwards compatibility issues. 167 Finally, there may still be many cases where a single attribute value 168 can be shared among multiple applications, so the solution must 169 minimize advertising duplicate link/attribute pairs whenever 170 possible. 172 3. Legacy Advertisements 174 There are existing advertisements used in support of RSVP-TE. These 175 advertisements include sub-TLVs for TLVs 22, 23, 141, 222, and 223 176 and TLVs for SRLG advertisement. 178 3.1. Legacy sub-TLVs 179 Sub-TLVs for TLVs 22, 23, 141, 222, and 223 181 Code Point/Attribute Name 182 -------------------------- 183 3 Administrative group (color) 184 9 Maximum link bandwidth 185 10 Maximum reservable link bandwidth 186 11 Unreserved bandwidth 187 14 Extended Administrative Group 188 33 Unidirectional Link Delay 189 34 Min/Max Unidirectional Link Delay 190 35 Unidirectional Delay Variation 191 36 Unidirectional Link Loss 192 37 Unidirectional Residual Bandwidth 193 38 Unidirectional Available Bandwidth 194 39 Unidirectional Utilized Bandwidth 196 3.2. Legacy SRLG Advertisements 198 TLV 138 GMPLS-SRLG 199 Supports links identified by IPv4 addresses and 200 unnumbered links 202 TLV 139 IPv6 SRLG 203 Supports links identified by IPv6 addresses 205 Note that [RFC6119] prohibits the use of TLV 139 when it is possible 206 to use TLV 138. 208 4. Advertising Application Specific Link Attributes 210 Two new code points are defined in support of Application Specific 211 Link Attribute Advertisements: 213 1) Application Specific Link Attributes sub-TLV for TLVs 22, 23, 141, 214 222, and 223 216 2)Application Specific Shared Risk Link Group (SRLG) TLV 218 In support of these new advertisements, an application bit mask is 219 defined which identifies the application(s) associated with a given 220 advertisement. 222 The following sections define the format of these new advertisements. 224 4.1. Application Identifier Bit Mask 226 Identification of the set of applications associated with link 227 attribute advertisements utilizes two bit masks. One bit mask is for 228 standard applications where the definition of each bit is defined in 229 a new IANA controlled registry. A second bit mask is for non- 230 standard User Defined Applications(UDAs). 232 The encoding defined below is used by both the Application Specific 233 Link Attributes sub-TLV and the Application Specific SRLG TLV. 235 0 1 2 3 4 5 6 7 236 +-+-+-+-+-+-+-+-+ 237 | SABML+F | 1 octet 238 +-+-+-+-+-+-+-+-+ 239 | UDABML+F | 1 octet 240 +-+-+-+-+-+-+-+-+ 241 | SABM ... 0 - 127 octets 242 +-+-+-+-+-+-+-+-+ 243 | UDABM ... 0 - 127 octets 244 +-+-+-+-+-+-+-+-+ 246 SABML+F (1 octet) 247 Standard Application Bit Mask Length/Flags 249 0 1 2 3 4 5 6 7 250 +-+-+-+-+-+-+-+-+ 251 |L| SA-Length | 252 +-+-+-+-+-+-+-+-+ 254 L-flag: Applications listed (both Standard and 255 User Defined) MUST use the legacy advertisements 256 for the corresponding link found in TLVs 22, 23, 257 141, 222, and 223 or TLV 138 or TLV 139 as appropriate. 259 SA-Length: Indicates the length in octets (0-127) of the Bit Mask 260 for Standard Applications. 262 UDABML+F (1 octet) 263 User Defined Application Bit Mask Length/Flags 265 0 1 2 3 4 5 6 7 266 +-+-+-+-+-+-+-+-+ 267 |R| UDA-Length | 268 +-+-+-+-+-+-+-+-+ 270 R: Reserved. Transmitted as 0 and ignored on receipt 271 UDA-Length: Indicates the length in octets (0-127) of the Bit Mask 272 for User Defined Applications. 274 SABM (variable length) 275 Standard Application Bit Mask 277 (SA-Length * 8) bits 279 This is omitted if SA-Length is 0. 281 0 1 2 3 4 5 6 7 ... 282 +-+-+-+-+-+-+-+-+... 283 |R|S|F|X| ... 284 +-+-+-+-+-+-+-+-+... 286 R-bit: RSVP-TE 288 S-bit: Segment Routing Traffic Engineering 290 F-bit: Loop Free Alternate 292 X-bit: Flex-Algo 294 UDABM (variable length) 295 User Defined Application Bit Mask 297 (UDA Length * 8) bits 299 0 1 2 3 4 5 6 7 ... 300 +-+-+-+-+-+-+-+-+... 301 | ... 302 +-+-+-+-+-+-+-+-+... 304 This is omitted if UDA-Length is 0. 306 NOTE: If both SA-length and UDA-Length are zero, then the 307 attributes associated with this attribute identifier bit mask 308 MAY be used by any Standard Application and any User Defined 309 Application. 311 Standard Application Bits are defined/sent starting with Bit 0. 312 Additional bit definitions that may be defined in the future SHOULD 313 be assigned in ascending bit order so as to minimize the number of 314 octets that will need to be transmitted. Undefined bits MUST be 315 transmitted as 0 and MUST be ignored on receipt. Bits that are NOT 316 transmitted MUST be treated as if they are set to 0 on receipt. 318 User Defined Application bits have no relationship to Standard 319 Application bits and are NOT managed by IANA or any other standards 320 body. It is recommended that bits are used starting with Bit 0 so as 321 to minimize the number of octets required to advertise all UDAs. 323 4.2. Application Specific Link Attributes sub-TLV 325 A new sub-TLV for TLVs 22, 23, 141, 222, and 223 is defined which 326 supports specification of the applications and application specific 327 attribute values. 329 Type: 16 (suggested value - to be assigned by IANA) 330 Length: Variable (1 octet) 331 Value: 333 Application Bit Mask (as defined in Section 3.1) 335 Link Attribute sub-sub-TLVs - format matches the 336 existing formats defined in [RFC5305] and [RFC7810] 338 When the L-flag is set in the Application Identifiers, all of the 339 applications specified in the bit mask MUST use the link attribute 340 sub-TLV advertisements listed in Section 3.1 for the corresponding 341 link. Application specific link attribute sub-sub-TLVs for the 342 corresponding link attributes MUST NOT be advertised for the set of 343 applications specified in the Standard/User Application Bit Masks and 344 all such advertisements MUST be ignored on receipt. 346 Multiple sub-TLVs for the same link MAY be advertised. When multiple 347 sub-TLVs for the same link are advertised, they SHOULD advertise non- 348 conflicting application/attribute pairs. A conflict exists when the 349 same application is associated with two different values of the same 350 link attribute for a given link. In cases where conflicting values 351 for the same application/attribute/link are advertised all the 352 conflicting values MUST be ignored. 354 For a given application, the setting of the L-flag MUST be the same 355 in all sub-TLVs for a given link. In cases where this constraint is 356 violated, the L-flag MUST be considered set for this application. 358 A new registry of sub-sub-TLVs is to be created by IANA which defines 359 the link attribute sub-sub-TLV code points. A sub-sub-TLV is defined 360 for each of the existing sub-TLVs listed in Section 3.1 except as 361 noted below. The format of the sub-sub-TLVs matches the format of 362 the corresponding legacy sub-TLV and IANA is requested to assign the 363 legacy sub-TLV identifer to the corresponding sub-sub-TLV. 365 4.2.1. Special Considerations for Maximum Link Bandwidth 367 Maximum link bandwidth is an application independent attribute of the 368 link. When advertised using the Application Specific Link Attributes 369 sub-TLV, multiple values for the same link MUST NOT be advertised. 370 This can be accomplished most efficiently by having a single 371 advertisement for a given link where the Application Bit Mask 372 identifies all the applications which are making use of the value for 373 that link. 375 It is also possible to advertise the same value for a given link 376 multiple times with disjoint sets of applications specified in the 377 Application Bit Mask. This is less efficient but still valid. 379 If different values for Maximum Link Bandwidth for a given link are 380 advertised, all values MUST be ignored. 382 4.2.2. Special Considerations for Unreserved Bandwidth 384 Unreserved bandwidth is an attribute specific to RSVP. When 385 advertised using the Application Specific Link Attributes sub-TLV, 386 bits other than the RSVP-TE(R-bit) MUST NOT be set in the Application 387 Bit Mask. If an advertisement of Unreserved Bandwidth is received 388 with bits other than the RSVP-TE bit set, the advertisement MUST be 389 ignored. 391 4.3. Application Specific SRLG TLV 393 A new TLV is defined to advertise application specific SRLGs for a 394 given link. Although similar in functionality to TLV 138 (defined by 395 [RFC5307]) and TLV 139 (defined by [RFC6119], a single TLV provides 396 support for IPv4, IPv6, and unnumbered identifiers for a link. 397 Unlike TLVs 138/139, it utilizes sub-TLVs to encode the link 398 identifiers in order to provide the flexible formatting required to 399 support multiple link identifier types. 401 Type: 238 (Suggested value - to be assigned by IANA) 402 Length: Number of octets in the value field (1 octet) 403 Value: 404 Neighbor System-ID + pseudo-node ID (7 octets) 405 Application Bit Mask (as defined in Section 3.1) 406 Length of sub-TLVs (1 octet) 407 Link Identifier sub-TLVs (variable) 408 0 or more SRLG Values (Each value is 4 octets) 410 The following Link Identifier sub-TLVs are defined. The type 411 values are suggested and will be assigned by IANA - but as 412 the formats are identical to existing sub-TLVs defined for 413 TLVs 22, 23, 141, 222, and 223 the use of the suggested sub-TLV 414 types is strongly encouraged. 416 Type Description 417 4 Link Local/Remote Identifiers (see [RFC5307]) 418 6 IPv4 interface address (see [RFC5305]) 419 8 IPv4 neighbor address (see [RFC5305]) 420 12 IPv6 Interface Address (see [RFC6119]) 421 13 IPv6 Neighbor Address (see [RFC6119]) 423 At least one set of link identifiers (IPv4, IPv6, or unnumbered) MUST 424 be present. TLVs which do not meet this requirement MUST be ignored. 426 Multiple TLVs for the same link MAY be advertised. 428 When the L-flag is set in the Application Identifiers, SRLG values 429 MUST NOT be included in the TLV. Any SRLG values which are 430 advertised MUST be ignored. Based on the link identifiers advertised 431 the corresponding legacy TLV (see Section 3.2) can be identified and 432 the SRLG values advertised in the legacy TLV MUST be used by the set 433 of applications specified in the Application Bit Mask. 435 For a given application, the setting of the L-flag MUST be the same 436 in all TLVs for a given link. In cases where this constraint is 437 violated, the L-flag MUST be considered set for this application. 439 5. Deployment Considerations 441 If link attributes are advertised associated with zero length 442 application bit masks for both standard applications and user defined 443 applications, then that set of link attributes MAY be used by any 444 application. If support for a new application is introduced on any 445 node in a network in the presence of such advertisements, these 446 advertisements MAY be used by the new application. If this is not 447 what is intended, then existing advertisements MUST be readvertised 448 with an explicit set of applications specified before a new 449 application is introduced. 451 6. Attribute Advertisements and Enablement 453 This document defines extensions to support the advertisement of 454 application specific link attributes. 456 Whether the presence of link attribute advertisements for a given 457 application indicates that the application is enabled on that link 458 depends upon the application. Similarly, whether the absence of link 459 attribute advertisements indicates that the application is not 460 enabled depends upon the application. 462 In the case of RSVP-TE, the advertisement of application specific 463 link attributes implies that RSVP is enabled on that link. 465 In the case of SRTE, advertisement of application specific link 466 attributes does NOT indicate enablement of SRTE. The advertisements 467 are only used to support constraints which may be applied when 468 specifying an explicit path. SRTE is implicitly enabled on all links 469 which are part of the Segment Routing enabled topology independent of 470 the existence of link attribute advertisements 472 In the case of LFA, advertisement of application specific link 473 attributes does NOT indicate enablement of LFA on that link. 474 Enablement is controlled by local configuration. 476 In the case of Flex-Algo, advertisement of application specific link 477 attributes does NOT indicate enablement of Flex-Algo. Rather the 478 attributes are used to determine what links are included/excluded in 479 the algorithm specific constrained SPF. This is fully specified in 480 [I-D.hegdeppsenak-isis-sr-flex-algo]. 482 If, in the future, additional standard applications are defined to 483 use this mechanism, the specification defining this use MUST define 484 the relationship between application specific link attribute 485 advertisements and enablement for that application. 487 This document allows the advertisement of application specific link 488 attributes with no application identifiers i.e., both the Standard 489 Application Bit Mask and the User Defined Application Bit Mask are 490 not present (See Section 4.1). This supports the use of the link 491 attribute by any application. In the presence of an application 492 where the advertisement of link attribute advertisements is used to 493 infer the enablement of an application on that link (e.g., RSVP-TE), 494 the absence of the application identifier leaves ambiguous whether 495 that application is enabled on such a link. This needs to be 496 considered when making use of the "any application" encoding. 498 7. Interoperability, Backwards Compatibility and Migration Concerns 500 Existing deployments of RSVP-TE utilize the legacy advertisements 501 listed in Section 3. Routers which do not support the extensions 502 defined in this document will only process legacy advertisements and 503 are likely to infer that RSVP-TE is enabled on the links for which 504 legacy advertisements exist. It is expected that deployments using 505 the legacy advertisements will persist for a significant period of 506 time - therefore deployments using the extensions defined in this 507 document must be able to co-exist with use of the legacy 508 advertisements by routers which do not support the extensions defined 509 in this document. The following sub-sections discuss 510 interoperability and backwards compatibility concerns for a number of 511 deployment scenarios. 513 Note that in all cases the defined strategy can be employed on a per 514 link basis. 516 7.1. RSVP-TE only deployments 518 In deployments where RSVP-TE is the only application utilizing link 519 attribute advertisements, use of the the legacy advertisements can 520 continue without change. 522 7.2. Multiple Applications: Common Attributes with RSVP-TE 524 In cases where multiple applications are utilizing a given link, one 525 of the applications is RSVP-TE, and all link attributes for a given 526 link are common to the set of applications utilizing that link, 527 interoperability is achieved by using legacy advertisements and 528 sending application specific advertisements with L-bit set and no 529 link attribute values. This avoids duplication of link attribute 530 advertisements. 532 7.3. Multiple Applications: All Attributes Not Shared w RSVP-TE 534 In cases where one or more applications other than RSVP-TE are 535 utilizing a given link and one or more link attribute values are NOT 536 shared with RSVP-TE, it is necessary to use application specific 537 advertisements as defined in this document. Attributes for 538 applications other than RSVP-TE MUST be advertised using application 539 specific advertisements which have the L-bit clear. In cases where 540 some link attributes are shared with RSVP-TE, this requires duplicate 541 advertisements for those attributes. 543 The discussion in this section applies to cases where RSVP-TE is NOT 544 using any advertised attributes on a link and to cases where RSVP-TE 545 is using some link attribute advertisements on the link but some link 546 attributes cannot be shared with RSVP-TE. 548 7.4. Deprecating legacy advertisements 550 The extensions defined in this document support RSVP-TE as one of the 551 supported applications - so a long term goal for deployments would be 552 to deprecate use of the legacy advertisements in support of RSVP-TE. 553 This can be done in the following step-wise manner: 555 1)Upgrade all routers to support extensions in this document 557 2)Readvertise all legacy link attributes using application specific 558 advertisements with L-bit clear and R-bit set. 560 3)Remove legacy advertisements 562 8. IANA Considerations 564 This document defines a new sub-TLV for TLVs 22, 23, 141, 222, and 565 223. 567 Type Description 22 23 25 141 222 223 568 ---- --------------------- ---- ---- ---- ---- ---- ---- 569 16 Application Specific y y y(s) y y y 570 Link Attributes 572 This document defines one new TLV: 574 Type Description IIH LSP SNP Purge 575 ---- --------------------- --- --- --- ----- 576 238 Application Specific n y n n 577 SRLG 579 This document requests a new IANA registry be created to control the 580 assignment of sub-sub-TLV codepoints for the Application Specific 581 Link Attributes sub-TLV. The suggested name of the new registry is 582 "sub-sub-TLV code points for application specific link attributes". 583 The registration procedure is "Expert Review" as defined in 584 [RFC8126]. The following assignments are made by this document: 586 Type Description 587 --------------------------------------------------------- 588 0-2 Unassigned 589 3 Administrative group (color) 590 4-8 Unassigned 591 9 Maximum link bandwidth 592 10 Maximum reservable link bandwidth 593 11 Unreserved bandwidth 594 12-13 Unassigned 595 14 Extended Administrative Group 596 15-32 Unassigned 597 33 Unidirectional Link Delay 598 34 Min/Max Unidirectional Link Delay 599 35 Unidirectional Delay Variation 600 36 Unidirectional Link Loss 601 37 Unidirectional Residual Bandwidth 602 38 Unidirectional Available Bandwidth 603 39 Unidirectional Utilized Bandwidth 604 40-255 Unassigned 606 This document requests a new IANA registry be created to control the 607 assignment of application bit identifiers. The suggested name of the 608 new registry is "Link Attribute Applications". The registration 609 procedure is "Expert Review" as defined in [RFC8126]. The following 610 assignments are made by this document: 612 Bit # Name 613 --------------------------------------------------------- 614 0 RSVP-TE (R-bit) 615 1 Segment Routing Traffic Engineering (S-bit) 616 2 Loop Free Alternate (F-bit) 617 3 Flex Algorithm (X-bit) 619 This document requests a new IANA registry be created to control the 620 assignment of sub-TLV types for the application specific SRLG TLV. 621 The suggested name of the new registry is "Sub-TLVs for TLV 238". 622 The registration procedure is "Expert Review" as defined in 623 [RFC8126]. The following assignments are made by this document: 625 Value Description 626 --------------------------------------------------------- 627 0-3 Unassigned 628 4 Link Local/Remote Identifiers (see [RFC5307]) 629 5 Unassigned 630 6 IPv4 interface address (see [RFC5305]) 631 7 Unassigned 632 8 IPv4 neighbor address (see [RFC5305]) 633 9-11 Unassigned 634 12 IPv6 Interface Address (see [RFC6119]) 635 13 IPv6 Neighbor Address (see [RFC6119]) 636 14-255 Unassigned 638 9. Security Considerations 640 Security concerns for IS-IS are addressed in [ISO10589, [RFC5304], 641 and [RFC5310]. 643 10. Acknowledgements 645 The authors would like to thank Eric Rosen and Acee Lindem for their 646 careful review and content suggestions. 648 11. References 650 11.1. Normative References 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 658 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 659 2008, . 661 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 662 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 663 2008, . 665 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 666 in Support of Generalized Multi-Protocol Label Switching 667 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 668 . 670 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 671 and M. Fanto, "IS-IS Generic Cryptographic 672 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 673 2009, . 675 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 676 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 677 February 2011, . 679 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 680 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 681 RFC 7810, DOI 10.17487/RFC7810, May 2016, 682 . 684 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 685 Writing an IANA Considerations Section in RFCs", BCP 26, 686 RFC 8126, DOI 10.17487/RFC8126, June 2017, 687 . 689 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 690 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 691 May 2017, . 693 11.2. Informative References 695 [I-D.filsfils-spring-segment-routing-policy] 696 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 697 F., Talaulikar, K., Ali, Z., Hegde, S., 698 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 699 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 700 Litkowski, S., and P. Mattes, "Segment Routing Policy for 701 Traffic Engineering", draft-filsfils-spring-segment- 702 routing-policy-05 (work in progress), February 2018. 704 [I-D.hegdeppsenak-isis-sr-flex-algo] 705 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 706 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 707 isis-sr-flex-algo-02 (work in progress), February 2018. 709 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 710 Litkowski, S., Horneffer, M., and R. Shakir, "Source 711 Packet Routing in Networking (SPRING) Problem Statement 712 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 713 2016, . 715 Authors' Addresses 717 Les Ginsberg 718 Cisco Systems 719 821 Alder Drive 720 Milpitas, CA 95035 721 USA 723 Email: ginsberg@cisco.com 725 Peter Psenak 726 Cisco Systems 727 Apollo Business Center Mlynske nivy 43 728 Bratislava 821 09 729 Slovakia 731 Email: ppsenak@cisco.com 733 Stefano Previdi 734 Huawei 736 Email: stefano@previdi.net 738 Wim Henderickx 739 Nokia 740 Copernicuslaan 50 741 Antwerp 2018 94089 742 Belgium 744 Email: wim.henderickx@nokia.com 746 John Drake 747 Juniper Networks 749 Email: jdrake@juniper.net