diff options
Diffstat (limited to 'doc/rfc/rfc9479.txt')
| -rw-r--r-- | doc/rfc/rfc9479.txt | 1108 |
1 files changed, 1108 insertions, 0 deletions
diff --git a/doc/rfc/rfc9479.txt b/doc/rfc/rfc9479.txt new file mode 100644 index 0000000..b98da0f --- /dev/null +++ b/doc/rfc/rfc9479.txt @@ -0,0 +1,1108 @@ + + + + +Internet Engineering Task Force (IETF) L. Ginsberg +Request for Comments: 9479 P. Psenak +Obsoletes: 8919 Cisco Systems +Category: Standards Track S. Previdi +ISSN: 2070-1721 Huawei Technologies + W. Henderickx + Nokia + J. Drake + Juniper Networks + October 2023 + + + IS-IS Application-Specific Link Attributes + +Abstract + + Existing traffic-engineering-related link attribute advertisements + have been defined and are used in RSVP-TE deployments. Since the + original RSVP-TE use case was defined, additional applications (e.g., + Segment Routing Policy and Loop-Free Alternates) that also make use + of the link attribute advertisements have been defined. In cases + where multiple applications wish to make use of these link + attributes, the current advertisements do not support application- + specific values for a given attribute, nor do they support an + indication of which applications are using the advertised value for a + given link. This document introduces link attribute advertisements + that address both of these shortcomings. + + This document obsoletes RFC 8919. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9479. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. Requirements Language + 2. Requirements Discussion + 3. Legacy Advertisements + 3.1. Legacy Sub-TLVs + 3.2. Legacy SRLG Advertisements + 4. Advertising Application-Specific Link Attributes + 4.1. Application Identifier Bit Mask + 4.2. Application-Specific Link Attributes Sub-TLV + 4.2.1. Special Considerations for Maximum Link Bandwidth + 4.2.2. Special Considerations for Reservable/Unreserved + Bandwidth + 4.2.3. Considerations for Extended TE Metrics + 4.3. Application-Specific SRLG TLV + 5. Attribute Advertisements and Enablement + 6. Deployment Considerations + 6.1. Use of Legacy Advertisements + 6.2. Use of Zero-Length Application Identifier Bit Masks + 6.3. Interoperability, Backwards Compatibility, and Migration + Concerns + 6.3.1. Multiple Applications: Common Attributes with RSVP-TE + 6.3.2. Multiple Applications: All Attributes Not Shared with + RSVP-TE + 6.3.3. Interoperability with Legacy Routers + 6.3.4. Use of Application-Specific Advertisements for RSVP-TE + 7. IANA Considerations + 7.1. Application-Specific Link Attributes Sub-TLV + 7.2. Application-Specific SRLG TLV + 7.3. IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link + Attributes Registry + 7.4. Link Attribute Application Identifiers Registry + 7.5. IS-IS Sub-TLVs for Application-Specific SRLG TLV + 8. Security Considerations + 9. Changes to RFC 8919 + 10. References + 10.1. Normative References + 10.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + Advertisement of link attributes by the Intermediate System to + Intermediate System (IS-IS) protocol in support of Traffic + Engineering (TE) was introduced by [RFC5305] and extended by + [RFC5307], [RFC6119], [RFC7308], and [RFC8570]. The use of these + extensions has been associated with deployments supporting TE over + Multiprotocol Label Switching (MPLS) in the presence of the Resource + Reservation Protocol (RSVP), more succinctly referred to as RSVP-TE + [RFC3209]. + + For the purposes of this document, an application is a technology + that makes use of link attribute advertisements, examples of which + are listed in Section 3. + + In recent years, new applications that have use cases for many of the + link attributes historically used by RSVP-TE have been introduced. + Such applications include Segment Routing (SR) Policy [RFC9256] and + Loop-Free Alternates (LFAs) [RFC5286]. This has introduced ambiguity + in that if a deployment includes a mix of RSVP-TE support and SR + Policy support, for example, it is not possible to unambiguously + indicate which advertisements are to be used by RSVP-TE and which + advertisements are to be used by SR Policy. If the topologies are + fully congruent, this may not be an issue, but any incongruence leads + to ambiguity. + + An example of where this ambiguity causes a problem is a network + where RSVP-TE is enabled only on a subset of its links. A link + attribute is advertised for the purpose of another application (e.g., + SR Policy) for a link that is not enabled for RSVP-TE. As soon as + the router that is an RSVP-TE head end sees the link attribute being + advertised for that link, it assumes that RSVP-TE is enabled on that + link, even though it is not. If such an RSVP-TE head-end router + tries to set up an RSVP-TE path via that link, it will result in a + setup failure for the path. + + An additional issue arises in cases where both applications are + supported on a link but the link attribute values associated with + each application differ. Current advertisements do not support + advertising application-specific values for the same attribute on a + specific link. + + This document defines extensions that address these issues. Also, as + evolution of use cases for link attributes can be expected to + continue in the years to come, this document defines a solution that + is easily extensible to the introduction of new applications and new + use cases. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Requirements Discussion + + As stated previously, evolution of use cases for link attributes can + be expected to continue. Therefore, any discussion of existing use + cases is limited to requirements that are known at the time of this + writing. However, in order to determine the functionality required + beyond what already exists in IS-IS, it is only necessary to discuss + use cases that justify the key points identified in the Introduction, + which are: + + 1. Support for indicating which applications are using the link + attribute advertisements on a link. + + 2. Support for advertising application-specific values for the same + attribute on a link. + + [RFC7855] discusses use cases and requirements for SR. Included + among these use cases is SR Policy, which is defined in [RFC9256]. + If both RSVP-TE and SR Policy are deployed in a network, link + attribute advertisements can be used by one or both of these + applications. There is no requirement for the link attributes + advertised on a given link used by SR Policy to be identical to the + link attributes advertised on that same link used by RSVP-TE; thus, + there is a clear requirement to indicate independently which link + attribute advertisements are to be used by each application. + + As the number of applications that may wish to utilize link + attributes may grow in the future, an additional requirement is that + the extensions defined allow the association of additional + applications to link attributes without altering the format of the + advertisements or introducing backwards-compatibility issues. + + Finally, there may still be many cases where a single attribute value + can be shared among multiple applications, so the solution must + minimize advertising duplicate link/attribute pairs whenever + possible. + +3. Legacy Advertisements + + Existing advertisements used in support of RSVP-TE include sub-TLVs + for TLVs Advertising Neighbor Information and TLVs for Shared Risk + Link Group (SRLG) advertisements. + + Sub-TLV values are defined in the "IS-IS Sub-TLVs for TLVs + Advertising Neighbor Information" registry. + + TLVs are defined in the "IS-IS TLV Codepoints" registry. + +3.1. Legacy Sub-TLVs + + +======+====================================+ + | Type | Description | + +======+====================================+ + | 3 | Administrative group (color) | + +------+------------------------------------+ + | 9 | Maximum link bandwidth | + +------+------------------------------------+ + | 10 | Maximum reservable link bandwidth | + +------+------------------------------------+ + | 11 | Unreserved bandwidth | + +------+------------------------------------+ + | 14 | Extended Administrative Group | + +------+------------------------------------+ + | 18 | TE Default metric | + +------+------------------------------------+ + | 33 | Unidirectional Link Delay | + +------+------------------------------------+ + | 34 | Min/Max Unidirectional Link Delay | + +------+------------------------------------+ + | 35 | Unidirectional Delay Variation | + +------+------------------------------------+ + | 36 | Unidirectional Link Loss | + +------+------------------------------------+ + | 37 | Unidirectional Residual Bandwidth | + +------+------------------------------------+ + | 38 | Unidirectional Available Bandwidth | + +------+------------------------------------+ + | 39 | Unidirectional Utilized Bandwidth | + +------+------------------------------------+ + + Table 1 + +3.2. Legacy SRLG Advertisements + + TLV 138 (GMPLS-SRLG): + Supports links identified by IPv4 addresses and unnumbered links. + + TLV 139 (IPv6 SRLG): + Supports links identified by IPv6 addresses. + + Note that [RFC6119] prohibits the use of TLV 139 when it is possible + to use TLV 138. + +4. Advertising Application-Specific Link Attributes + + Two codepoints are defined to support Application-Specific Link + Attribute (ASLA) advertisements: + + 1. Application-Specific Link Attributes sub-TLV for TLVs Advertising + Neighbor Information (defined in Section 4.2). + + 2. Application-Specific SRLG TLV (defined in Section 4.3). + + To support these advertisements, an application identifier bit mask + is defined to identify the application(s) associated with a given + advertisement (defined in Section 4.1). + + In addition to supporting the advertisement of link attributes used + by standardized applications, link attributes can also be advertised + for use by User-Defined Applications (UDAs). Such applications are + not subject to standardization and are outside the scope of this + document. + + The following sections define the format of these advertisements. + +4.1. Application Identifier Bit Mask + + Identification of the set of applications associated with link + attribute advertisements utilizes two bit masks. One bit mask is for + standard applications where the definition of each bit is defined in + an IANA-controlled registry (see Section 7.4). A second bit mask is + for non-standard UDAs. + + The encoding defined below is used by both the Application-Specific + Link Attributes sub-TLV and the Application-Specific SRLG TLV. + + 0 1 2 3 4 5 6 7 + +--+--+--+--+--+--+--+--+ + | SABM Length + Flag | 1 octet + +--+--+--+--+--+--+--+--+ + | UDABM Length + Flag | 1 octet + +--+--+--+--+--+--+--+--+ + | SABM ... 0-8 octets + +--+--+--+--+--+--+--+--+ + | UDABM ... 0-8 octets + +--+--+--+--+--+--+--+--+ + + SABM Length + Flag (1 octet): + Standard Application Identifier Bit Mask Length + Flag + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |L| SABM Length | + +-+-+-+-+-+-+-+-+ + + L-flag: + Legacy Flag. See Section 4.2 for a description of how this + flag is used. + + SABM Length: + This field indicates the length in octets (0-8) of the Standard + Application Identifier Bit Mask. The length SHOULD be the + minimum required to send all bits that are set. + + UDABM Length + Flag (1 octet): + User-Defined Application Identifier Bit Mask Length + Flag + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |R| UDABM Length| + +-+-+-+-+-+-+-+-+ + + R: + Reserved. SHOULD be transmitted as 0 and MUST be ignored on + receipt. + + UDABM Length: + Indicates the length in octets (0-8) of the User-Defined + Application Identifier Bit Mask. The length SHOULD be the + minimum required to send all bits that are set. + + SABM (variable length): + Standard Application Identifier Bit Mask + + (SABM Length * 8) bits + + This field is omitted if SABM Length is 0. + + 0 1 2 3 4 5 6 7 ... + +-+-+-+-+-+-+-+-+... + |R|S|F| ... + +-+-+-+-+-+-+-+-+... + + R-bit: + Set to specify RSVP-TE. + + S-bit: + Set to specify SR Policy (this is data plane independent). + + F-bit: + Set to specify an LFA (includes all LFA types). + + UDABM (variable length): + User-Defined Application Identifier Bit Mask + + (UDABM Length * 8) bits + + 0 1 2 3 4 5 6 7 ... + +-+-+-+-+-+-+-+-+... + | ... + +-+-+-+-+-+-+-+-+... + + This field is omitted if UDABM Length is 0. + + | Note: SABM/UDABM Length is arbitrarily limited to 8 octets in + | order to ensure that sufficient space is left to advertise link + | attributes without overrunning the maximum length of a sub-TLV. + + Standard Application Identifier Bits are defined and sent starting + with bit 0. + + User-Defined Application Identifier Bits have no relationship to + Standard Application Identifier Bits and are not managed by IANA or + any other standards body. It is recommended that bits be used + starting with bit 0 so as to minimize the number of octets required + to advertise all UDAs. + + For both the SABM and UDABM, the following rules apply: + + * Undefined bits that are transmitted MUST be transmitted as 0 and + MUST be ignored on receipt. + + * Bits that are not transmitted MUST be treated as if they are set + to 0 on receipt. + + * Bits that are not supported by an implementation MUST be ignored + on receipt. + +4.2. Application-Specific Link Attributes Sub-TLV + + A sub-TLV for TLVs Advertising Neighbor Information is defined that + supports specification of the applications and application-specific + attribute values. + + Type: + 16 + + Length: + Variable (1 octet) + + Value: + Application Identifier Bit Mask (as defined in Section 4.1) + + Link Attribute sub-sub-TLVs -- format matches the existing formats + defined in [RFC5305], [RFC7308], and [RFC8570] + + If the SABM Length or UDABM Length in the Application Identifier Bit + Mask is greater than 8, the entire sub-TLV MUST be ignored. + + When the SABM Length or UDABM Length is non-zero and the L-flag is + NOT set, all applications specified in the bit mask MUST use the link + attribute advertisements in the sub-TLV. + + When the L-flag is set in the Application Identifier Bit Mask, all of + the applications specified in the bit mask MUST use the legacy + advertisements for the corresponding link found in TLVs Advertising + Neighbor Information. Link attribute sub-sub-TLVs for the + corresponding link attributes MUST NOT be advertised for the set of + applications specified in the Standard Application Identifier Bit + Mask or the User-Defined Application Identifier Bit Mask, and all + such sub-sub-TLVs MUST be ignored on receipt. + + Multiple Application-Specific Link Attributes sub-TLVs for the same + link MAY be advertised. When multiple sub-TLVs for the same link are + advertised, they SHOULD advertise non-conflicting application/ + attribute pairs. A conflict exists when the same application is + associated with two different values for the same link attribute for + a given link. In cases where conflicting values for the same + application/attribute/link are advertised, the first advertisement + received in the lowest-numbered Link State Protocol Data Unit (LSP) + MUST be used, and subsequent advertisements of the same attribute + MUST be ignored. + + For a given application, the setting of the L-flag MUST be the same + in all sub-TLVs for a given link. In cases where this constraint is + violated, the L-flag MUST be considered set for this application. + + The end result of the set of rules defined above is that for a given + application either the attribute values advertised in ASLA sub-sub- + TLVs are used or the attribute values advertised in legacy sub-TLVs + are used, but not both. + + Link attributes MAY be advertised associated with zero-length + Application Identifier Bit Masks for both standard applications and + UDAs. Such link attribute advertisements MUST be used by standard + applications and/or UDAs when no link attribute advertisements with a + non-zero-length Application Identifier Bit Mask and a matching + Application Identifier Bit set are present for a given link. + Otherwise, such link attribute advertisements MUST NOT be used. + + IANA has created a registry of sub-sub-TLVs to define the link + attribute sub-sub-TLV codepoints (see Section 7.3). This document + defines a sub-sub-TLV for each of the existing sub-TLVs listed in + Section 3.1, except as noted below. The format of the sub-sub-TLVs + matches the format of the corresponding legacy sub-TLV, and IANA has + assigned the legacy sub-TLV identifier to the corresponding sub-sub- + TLV. + +4.2.1. Special Considerations for Maximum Link Bandwidth + + Maximum link bandwidth is an application-independent attribute of the + link. When advertised using the Application-Specific Link Attributes + sub-TLV, multiple values for the same link MUST NOT be advertised. + This can be accomplished most efficiently by having a single + advertisement for a given link where the Application Identifier Bit + Mask identifies all the applications that are making use of the value + for that link. + + It is also possible to advertise the same value for a given link + multiple times with disjoint sets of applications specified in the + Application Identifier Bit Mask. This is less efficient but still + valid. + + It is also possible to advertise a single advertisement with a zero- + length SABM and UDABM so long as the constraints discussed in + Sections 4.2 and 6.2 are satisfied. + + If different values for maximum link bandwidth for a given link are + advertised, all values MUST be ignored. + +4.2.2. Special Considerations for Reservable/Unreserved Bandwidth + + Maximum reservable link bandwidth and unreserved bandwidth are + attributes specific to RSVP-TE. When advertised using the + Application-Specific Link Attributes sub-TLV, bits other than the + RSVP-TE bit (R-bit) MUST NOT be set in the Application Identifier Bit + Mask. If an advertisement of maximum reservable link bandwidth or + unreserved bandwidth is received with bits other than the R-bit set, + the advertisement MUST be ignored. + +4.2.3. Considerations for Extended TE Metrics + + [RFC8570] defines a number of dynamic performance metrics associated + with a link. It is conceivable that such metrics could be measured + specific to traffic associated with a specific application. + Therefore, this document includes support for advertising these link + attributes specific to a given application. However, in practice, it + may well be more practical to have these metrics reflect the + performance of all traffic on the link regardless of application. In + such cases, advertisements for these attributes will be associated + with all of the applications utilizing that link. This can be done + by either explicitly specifying the applications in the Application + Identifier Bit Mask or using a zero-length Application Identifier Bit + Mask. The use of zero-length Application Identifier Bit Masks is + further discussed in Section 6.2. + +4.3. Application-Specific SRLG TLV + + A TLV is defined to advertise application-specific SRLGs for a given + link. Although similar in functionality to TLV 138 [RFC5307] and TLV + 139 [RFC6119], this single TLV provides support for IPv4, IPv6, and + unnumbered identifiers for a link. Unlike TLVs 138 and 139, it + utilizes sub-TLVs to encode the link identifiers in order to provide + the flexible formatting required to support multiple link identifier + types. + + Type: + 238 + + Length: + Number of octets in the value field (1 octet) + + Value: + Neighbor System-ID + pseudonode ID (7 octets) + + Application Identifier Bit Mask (as defined in Section 4.1) + + Length of sub-TLVs (1 octet) + + Link Identifier sub-TLVs (variable) + + 0 or more SRLG values (each value is 4 octets) + + If the SABM Length or UDABM Length in the Application Identifier Bit + Mask is greater than 8, the entire sub-TLV MUST be ignored. + + When the SABM Length or UDABM Length is non-zero and the L-flag is + NOT set, all applications specified in the bit mask MUST use SRLG + advertisements in the Application-Specific SRLG TLV. + + The following Link Identifier sub-TLVs are defined. The values + chosen intentionally match the equivalent sub-TLVs from [RFC5305], + [RFC5307], and [RFC6119]. + + +======+=========================================+ + | Type | Description | + +======+=========================================+ + | 4 | Link Local/Remote Identifiers [RFC5307] | + +------+-----------------------------------------+ + | 6 | IPv4 interface address [RFC5305] | + +------+-----------------------------------------+ + | 8 | IPv4 neighbor address [RFC5305] | + +------+-----------------------------------------+ + | 12 | IPv6 Interface Address [RFC6119] | + +------+-----------------------------------------+ + | 13 | IPv6 Neighbor Address [RFC6119] | + +------+-----------------------------------------+ + + Table 2 + + At least one set of link identifiers (IPv4, IPv6, or Link Local/ + Remote) MUST be present. Multiple occurrences of the same identifier + type MUST NOT be present. TLVs that do not meet this requirement + MUST be ignored. + + Multiple TLVs for the same link MAY be advertised. + + When the L-flag is set in the Application Identifier Bit Mask, SRLG + values MUST NOT be included in the TLV. Any SRLG values that are + advertised MUST be ignored. Based on the link identifiers + advertised, the corresponding legacy TLV (see Section 3.2) can be + identified, and the SRLG values advertised in the legacy TLV MUST be + used by the set of applications specified in the Application + Identifier Bit Mask. + + For a given application, the setting of the L-flag MUST be the same + in all TLVs for a given link. In cases where this constraint is + violated, the L-flag MUST be considered set for this application. + +5. Attribute Advertisements and Enablement + + This document defines extensions to support the advertisement of + ASLAs. + + Whether the presence of link attribute advertisements for a given + application indicates that the application is enabled on that link + depends upon the application. Similarly, whether the absence of link + attribute advertisements indicates that the application is not + enabled depends upon the application. + + In the case of RSVP-TE, the advertisement of ASLAs implies that RSVP + is enabled on that link. The absence of RSVP-TE ASLAs in combination + with the absence of legacy advertisements implies that RSVP is not + enabled on that link. + + In the case of SR Policy, the advertisement of ASLAs does not + indicate enablement of SR Policy on that link. The advertisements + are only used to support constraints that may be applied when + specifying an explicit path. SR Policy is implicitly enabled on all + links that are part of the SR-enabled topology independent of the + existence of link attribute advertisements. + + In the case of LFA, the advertisement of ASLAs does not indicate + enablement of LFA on that link. Enablement is controlled by local + configuration. + + In the future, if additional standard applications are defined to use + this mechanism, the specification defining this use MUST define the + relationship between ASLA advertisements and enablement for those + applications. + + This document allows the advertisement of ASLAs with no application + identifiers, i.e., neither the Standard Application Identifier Bit + Mask nor the User-Defined Application Identifier Bit Mask is present + (see Section 4.1). This supports the use of the link attribute by + any application. In the presence of an application where the + advertisement of link attributes is used to infer the enablement of + an application on that link (e.g., RSVP-TE), the absence of the + application identifier leaves ambiguous whether that application is + enabled on such a link. This needs to be considered when making use + of the "any application" encoding. + +6. Deployment Considerations + + This section discusses deployment considerations associated with the + use of ASLA advertisements. + +6.1. Use of Legacy Advertisements + + Bit identifiers for standard applications are defined in Section 4.1. + All of the identifiers defined in this document are associated with + applications that were already deployed in some networks prior to the + writing of this document. Therefore, such applications have been + deployed using the legacy advertisements. The standard applications + defined in this document may continue to use legacy advertisements + for a given link so long as at least one of the following conditions + is true: + + * The application is RSVP-TE. + + * The application is SR Policy or LFA, and RSVP-TE is not deployed + anywhere in the network. + + * The application is SR Policy or LFA, RSVP-TE is deployed in the + network, and both the set of links on which SR Policy and/or LFA + advertisements are required and the attribute values used by SR + Policy and/or LFA on all such links are fully congruent with the + links and attribute values used by RSVP-TE. + + Under the conditions defined above, implementations that support the + extensions defined in this document have the choice of using legacy + advertisements or application-specific advertisements in support of + SR Policy and/or LFA. This will require implementations to provide + controls specifying which types of advertisements are to be sent and + processed on receipt for these applications. Further discussion of + the associated issues can be found in Section 6.3. + + New applications that future documents define to make use of the + advertisements defined in this document MUST NOT make use of legacy + advertisements. This simplifies deployment of new applications by + eliminating the need to support multiple ways to advertise attributes + for the new applications. + +6.2. Use of Zero-Length Application Identifier Bit Masks + + Link attribute advertisements associated with zero-length Application + Identifier Bit Masks for both standard applications and UDAs are + usable by any application, subject to the restrictions specified in + Section 4.2. If support for a new application is introduced on any + node in a network in the presence of such advertisements, the new + application will use these advertisements, when the aforementioned + restrictions are met. If this is not what is intended, then existing + link attribute advertisements MUST be readvertised with an explicit + set of applications specified before a new application is introduced. + +6.3. Interoperability, Backwards Compatibility, and Migration Concerns + + Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the + legacy advertisements listed in Section 3. Routers that do not + support the extensions defined in this document will only process + legacy advertisements and are likely to infer that RSVP-TE is enabled + on the links for which legacy advertisements exist. It is expected + that deployments using the legacy advertisements will persist for a + significant period of time. Therefore, deployments using the + extensions defined in this document in the presence of routers that + do not support these extensions need to be able to interoperate with + the use of legacy advertisements by the legacy routers. The + following subsections discuss interoperability and backwards- + compatibility concerns for a number of deployment scenarios. + +6.3.1. Multiple Applications: Common Attributes with RSVP-TE + + In cases where multiple applications are utilizing a given link, one + of the applications is RSVP-TE, and all link attributes for a given + link are common to the set of applications utilizing that link, + interoperability is achieved by using legacy advertisements and + sending application-specific advertisements with the L-flag set and + no link attribute values. This avoids duplication of link attribute + advertisements. + +6.3.2. Multiple Applications: All Attributes Not Shared with RSVP-TE + + In cases where one or more applications other than RSVP-TE are + utilizing a given link and one or more link attribute values are not + shared with RSVP-TE, it is necessary to use application-specific + advertisements as defined in this document. Attributes for + applications other than RSVP-TE MUST be advertised using application- + specific advertisements that have the L-flag clear. In cases where + some link attributes are shared with RSVP-TE, this requires duplicate + advertisements for those attributes. + + These guidelines apply to cases where RSVP-TE is not using any + advertised attributes on a link and to cases where RSVP-TE is using + some link attribute advertisements on the link but some link + attributes cannot be shared with RSVP-TE. + +6.3.3. Interoperability with Legacy Routers + + For the standard applications defined in this document, routers that + do not support the extensions defined in this document will send and + receive only legacy link attribute advertisements. In addition, the + link attribute values associated with these applications are always + shared, since legacy routers have no way of advertising or processing + application-specific values. So long as there is any legacy router + in the network that has any of the standard applications defined in + this document enabled, all routers MUST continue to advertise link + attributes for these applications using only legacy advertisements. + ASLA advertisements for these applications MUST NOT be sent. Once + all legacy routers have been upgraded, migration from legacy + advertisements to ASLA advertisements can be achieved via the + following steps: + + 1. Send ASLA advertisements while continuing to advertise legacy + advertisements (all advertisements are then duplicated). + Receiving routers continue to use legacy advertisements. + + 2. Enable the use of the ASLA advertisements on all routers. + + 3. Remove legacy advertisements. + + When the migration is complete, it then becomes possible to advertise + incongruent values per application on a given link. + + Note that the use of the L-flag is of no value in the migration. + + Documents defining new applications that make use of the application- + specific advertisements defined in this document MUST discuss + interoperability and backwards-compatibility issues that could occur + in the presence of routers that do not support the new application. + +6.3.4. Use of Application-Specific Advertisements for RSVP-TE + + The extensions defined in this document include RSVP-TE as one of the + applications. It is therefore possible, in the future, for + implementations to migrate to the use of application-specific + advertisements in support of RSVP-TE. This could be done in the + following stepwise manner: + + 1. Upgrade all routers to support the extensions in this document. + + 2. Advertise all legacy link attributes using ASLA advertisements + with the L-flag clear and the R-bit set. At this point, both + legacy and application-specific advertisements are being sent. + + 3. Remove legacy advertisements. + +7. IANA Considerations + + This section lists the protocol codepoint changes introduced by this + document and the related IANA updates. + + For the registries defined under the "IS-IS TLV Codepoints" group of + registries with a registration procedure of "Expert Review" (see + Sections 7.3 and 7.5), guidance for designated experts can be found + in [RFC7370]. + + Note that in all cases where the registry reference was to RFC 8919, + the registry has been updated to refer to this document. + +7.1. Application-Specific Link Attributes Sub-TLV + + IANA has registered the sub-TLV defined in Section 4.2 in the "IS-IS + Sub-TLVs for TLVs Advertising Neighbor Information" registry. + + +======+======================+====+====+======+=====+=====+=====+ + | Type | Description | 22 | 23 | 25 | 141 | 222 | 223 | + +======+======================+====+====+======+=====+=====+=====+ + | 16 | Application-Specific | y | y | y(s) | y | y | y | + | | Link Attributes | | | | | | | + +------+----------------------+----+----+------+-----+-----+-----+ + + Table 3 + +7.2. Application-Specific SRLG TLV + + IANA has registered the TLV defined in Section 4.3 in the "IS-IS Top- + Level TLV Codepoints" registry. + + +=======+===========================+=====+=====+=====+=======+ + | Value | Description | IIH | LSP | SNP | Purge | + +=======+===========================+=====+=====+=====+=======+ + | 238 | Application-Specific SRLG | n | y | n | n | + +-------+---------------------------+-----+-----+-----+-------+ + + Table 4 + +7.3. IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link + Attributes Registry + + IANA has created a registry titled "IS-IS Sub-Sub-TLV Codepoints for + Application-Specific Link Attributes" under the "IS-IS TLV + Codepoints" registry to control the assignment of sub-sub-TLV + codepoints for the Application-Specific Link Attributes sub-TLV + defined in Section 7.1. The registration procedure is "Expert + Review" as defined in [RFC8126]. The initial contents of this + registry are as follows: + + +========+====================================+===========+ + | Type | Description | Reference | + +========+====================================+===========+ + | 0-2 | Unassigned | | + +--------+------------------------------------+-----------+ + | 3 | Administrative group (color) | [RFC5305] | + +--------+------------------------------------+-----------+ + | 4-8 | Unassigned | | + +--------+------------------------------------+-----------+ + | 9 | Maximum link bandwidth | [RFC5305] | + +--------+------------------------------------+-----------+ + | 10 | Maximum reservable link bandwidth | [RFC5305] | + +--------+------------------------------------+-----------+ + | 11 | Unreserved bandwidth | [RFC5305] | + +--------+------------------------------------+-----------+ + | 12-13 | Unassigned | | + +--------+------------------------------------+-----------+ + | 14 | Extended Administrative Group | [RFC7308] | + +--------+------------------------------------+-----------+ + | 15-17 | Unassigned | | + +--------+------------------------------------+-----------+ + | 18 | TE Default metric | [RFC5305] | + +--------+------------------------------------+-----------+ + | 19-32 | Unassigned | | + +--------+------------------------------------+-----------+ + | 33 | Unidirectional Link Delay | [RFC8570] | + +--------+------------------------------------+-----------+ + | 34 | Min/Max Unidirectional Link Delay | [RFC8570] | + +--------+------------------------------------+-----------+ + | 35 | Unidirectional Delay Variation | [RFC8570] | + +--------+------------------------------------+-----------+ + | 36 | Unidirectional Link Loss | [RFC8570] | + +--------+------------------------------------+-----------+ + | 37 | Unidirectional Residual Bandwidth | [RFC8570] | + +--------+------------------------------------+-----------+ + | 38 | Unidirectional Available Bandwidth | [RFC8570] | + +--------+------------------------------------+-----------+ + | 39 | Unidirectional Utilized Bandwidth | [RFC8570] | + +--------+------------------------------------+-----------+ + | 40-255 | Unassigned | | + +--------+------------------------------------+-----------+ + + Table 5 + + IANA has also added the following notes to this registry: + + Note: For future codepoints, in cases where the document that + defines the encoding is different from the document that assigns + the codepoint, the encoding reference MUST be to the document that + defines the encoding. + + Note: If a link attribute can be advertised both as a sub-TLV of + TLVs advertising neighbor information and as a sub-sub-TLV of the + Application-Specific Link Attributes sub-TLV defined in RFC 9479, + then the same numerical code should be assigned to the link + attribute whenever possible. + +7.4. Link Attribute Application Identifiers Registry + + IANA has created a registry titled "Link Attribute Application + Identifiers" within the "Interior Gateway Protocol (IGP) Parameters" + group of registries to control the assignment of Application + Identifier Bits. The registration policy for this registry is + "Expert Review" as defined in [RFC8126]. Bit definitions SHOULD be + assigned such that all bits in the lowest available octet are + allocated before assigning bits in the next octet. This minimizes + the number of octets that will need to be transmitted. The initial + contents of this registry are as follows: + + +======+================================+ + | Bit | Name | + +======+================================+ + | 0 | RSVP-TE (R-bit) | + +------+--------------------------------+ + | 1 | Segment Routing Policy (S-bit) | + +------+--------------------------------+ + | 2 | Loop-Free Alternate (F-bit) | + +------+--------------------------------+ + | 3-63 | Unassigned | + +------+--------------------------------+ + + Table 6 + +7.5. IS-IS Sub-TLVs for Application-Specific SRLG TLV + + IANA has created a registry titled "IS-IS Sub-TLVs for Application- + Specific SRLG TLV" under the "IS-IS TLV Codepoints" registry to + control the assignment of sub-TLV types for the Application-Specific + SRLG TLV (TLV 238). The registration procedure is "Expert Review" as + defined in [RFC8126]. The initial contents of this registry are as + follows: + + +========+===============================+===========+ + | Value | Description | Reference | + +========+===============================+===========+ + | 0-3 | Unassigned | | + +--------+-------------------------------+-----------+ + | 4 | Link Local/Remote Identifiers | [RFC5307] | + +--------+-------------------------------+-----------+ + | 5 | Unassigned | | + +--------+-------------------------------+-----------+ + | 6 | IPv4 interface address | [RFC5305] | + +--------+-------------------------------+-----------+ + | 7 | Unassigned | | + +--------+-------------------------------+-----------+ + | 8 | IPv4 neighbor address | [RFC5305] | + +--------+-------------------------------+-----------+ + | 9-11 | Unassigned | | + +--------+-------------------------------+-----------+ + | 12 | IPv6 Interface Address | [RFC6119] | + +--------+-------------------------------+-----------+ + | 13 | IPv6 Neighbor Address | [RFC6119] | + +--------+-------------------------------+-----------+ + | 14-255 | Unassigned | | + +--------+-------------------------------+-----------+ + + Table 7 + + IANA has also added the following note to this registry: + + Note: For future codepoints, in cases where the document that + defines the encoding is different from the document that assigns + the codepoint, the encoding reference MUST be to the document that + defines the encoding. + +8. Security Considerations + + Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], + and [RFC5310]. While IS-IS is deployed under a single administrative + domain, there can be deployments where potential attackers have + access to one or more networks in the IS-IS routing domain. In these + deployments, the stronger authentication mechanisms defined in the + aforementioned documents SHOULD be used. + + This document defines an improved way to advertise link attributes. + Tampering with the information defined in this document may have an + effect on applications using it, including impacting TE as discussed + in [RFC8570]. As the advertisements defined in this document limit + the scope to specific applications, the impact of tampering is + similarly limited in scope. + +9. Changes to RFC 8919 + + Discussion within the LSR WG indicated that there was confusion + regarding the use of ASLA advertisements that had a zero-length SABM/ + UDABM. The discussion can be seen by searching the LSR WG mailing + list archives for the thread "Proposed Errata for RFCs 8919/8920" + starting on 15 June 2021. + + Changes to Sections 4.2, 4.3, and 6.2 have been introduced to clarify + normative behavior in the presence of such advertisements. In + particular, the text in [RFC8919] used the word "permitted", + suggesting that the use of such advertisements is "optional". Such + an interpretation could lead to interoperability issues and is not + what was intended. + + The replacement text makes explicit the specific conditions when such + advertisements MUST be used and the specific conditions under which + they MUST NOT be used. + +10. References + +10.1. Normative References + + [ISO10589] ISO, "Information technology - Telecommunications and + information exchange between systems - Intermediate System + to Intermediate System intra-domain routing information + exchange protocol for use in conjunction with the protocol + for providing the connectionless-mode network service (ISO + 8473)", Second Edition, ISO/IEC 10589:2002, November 2002, + <https://www.iso.org/standard/30932.html>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, DOI 10.17487/RFC5304, October + 2008, <https://www.rfc-editor.org/info/rfc5304>. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, October + 2008, <https://www.rfc-editor.org/info/rfc5305>. + + [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, + <https://www.rfc-editor.org/info/rfc5307>. + + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, DOI 10.17487/RFC5310, February + 2009, <https://www.rfc-editor.org/info/rfc5310>. + + [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic + Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, + February 2011, <https://www.rfc-editor.org/info/rfc6119>. + + [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS + Traffic Engineering (MPLS-TE)", RFC 7308, + DOI 10.17487/RFC7308, July 2014, + <https://www.rfc-editor.org/info/rfc7308>. + + [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints + Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, + <https://www.rfc-editor.org/info/rfc7370>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, + D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) + Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March + 2019, <https://www.rfc-editor.org/info/rfc8570>. + +10.2. Informative References + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + <https://www.rfc-editor.org/info/rfc3209>. + + [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for + IP Fast Reroute: Loop-Free Alternates", RFC 5286, + DOI 10.17487/RFC5286, September 2008, + <https://www.rfc-editor.org/info/rfc5286>. + + [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., + Litkowski, S., Horneffer, M., and R. Shakir, "Source + Packet Routing in Networking (SPRING) Problem Statement + and Requirements", RFC 7855, DOI 10.17487/RFC7855, May + 2016, <https://www.rfc-editor.org/info/rfc7855>. + + [RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and + J. Drake, "IS-IS Application-Specific Link Attributes", + RFC 8919, DOI 10.17487/RFC8919, October 2020, + <https://www.rfc-editor.org/info/rfc8919>. + + [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, + A., and P. Mattes, "Segment Routing Policy Architecture", + RFC 9256, DOI 10.17487/RFC9256, July 2022, + <https://www.rfc-editor.org/info/rfc9256>. + +Acknowledgements + + RFC 8919 included the following acknowledgements: + + | Eric Rosen and Acee Lindem for their careful review and content + | suggestions. + + For the new version (this document), the authors would like to thank + Bruno Decraene. + +Authors' Addresses + + Les Ginsberg + Cisco Systems + United States of America + Email: ginsberg@cisco.com + + + Peter Psenak + Cisco Systems + Slovakia + Email: ppsenak@cisco.com + + + Stefano Previdi + Huawei Technologies + Email: stefano@previdi.net + + + Wim Henderickx + Nokia + Copernicuslaan 50 + 2018 94089 Antwerp + Belgium + Email: wim.henderickx@nokia.com + + + John Drake + Juniper Networks + Email: jdrake@juniper.net |