RFC 9479

IS-IS Application-Specific Link Attributes

📅 published October 2023, from ietf

okay bestie, this one is RFC 9479, from the Internet Engineering Task Force (IETF) 💅. It's written by L. Ginsberg and P. Psenak (both at Cisco Systems), S. Previdi (Huawei Technologies), W. Henderickx (Nokia), and J. Drake (Juniper Networks). It's a Standards Track doc, published October 2023 with ISSN 2070-1721. It obsoletes RFC 8919, so 8919 is officially retired and this one is the new main character 👑.

Abstract ✨

Okay so the link attribute ads that IS-IS already sends for traffic engineering were built for RSVP-TE 🌸. Then other apps like Segment Routing Policy and Loop-Free Alternates showed up and wanted those same attributes too 👀. When more than one app wants them, the current ads can't give each app its own value for an attribute, and they can't say which apps are actually using a link's value. This doc adds new link attribute ads that fix both of those problems 🫶.

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 (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 ✨

Okay so the Intermediate System to Intermediate System (IS-IS) protocol has been sending link attribute ads for Traffic Engineering (TE) since [RFC5305] introduced them. [RFC5307], [RFC6119], [RFC7308], and [RFC8570] extended them. These extensions have mostly been used in deployments doing TE over Multiprotocol Label Switching (MPLS) with the Resource Reservation Protocol (RSVP), which people usually just call 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.

Recently, new apps that want a lot of the same link attributes RSVP-TE uses have shown up. Examples are Segment Routing (SR) Policy [RFC9256] and Loop-Free Alternates (LFAs) [RFC5286]. This creates a mess 😭. If a network runs both RSVP-TE and SR Policy, for example, there's no clean way to say which ads are for RSVP-TE and which are for SR Policy. If the topologies match up perfectly, it might not be a big deal, but any difference between them causes confusion.

Here's a scenario where it goes wrong. Say RSVP-TE is only turned on for some of the links in a network. Another app, like SR Policy, advertises a link attribute for a link where RSVP-TE is off. The RSVP-TE head-end router sees that attribute and assumes RSVP-TE is on for that link, even though it isn't 🙈. If that head-end then tries to set up an RSVP-TE path over the link, the path setup fails 💀.

Things get messier when both apps run on the same link but need different values for the same attribute. The current ads can't carry application-specific values for one attribute on one link 🍓.

This document defines extensions that fix these problems. Also, since link attribute use cases will keep growing, this document uses a solution that's easy to extend for 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 we already said, link attribute use cases will keep evolving 🔥. So any discussion of current use cases is limited to the requirements known at the time of writing. To figure out what IS-IS needs beyond what it already does, we only need to look at the use cases that back up the two key points from the Introduction:

  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] talks about use cases and requirements for SR. One of those use cases is SR Policy, defined in [RFC9256]. If RSVP-TE and SR Policy are both deployed in a network, link attribute advertisements can be used by one or both of them. The link attributes that SR Policy uses on a link don't have to match the ones RSVP-TE uses on that same link. So there's a clear requirement to indicate independently which link attribute advertisements each application should use 💖.

Lots of apps may want link attributes in the future, so another requirement is that the extensions let new applications be linked to link attributes without changing the format of the advertisements or causing backwards-compatibility problems ✨.

There are also plenty of cases where one attribute value can be shared by multiple applications. So the solution has to minimize advertising duplicate link/attribute pairs whenever possible 🫶.

3. Legacy Advertisements

Existing ads used for 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 🌸.

okay so bestie, this section is where the ASLA magic happens 🦋 two codepoints get defined so we can advertise ASLA stuff:

  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 make these adverts work, there's an application identifier bit mask (defined in Section 4.1) that tells you which app(s) an advert is for 💅

and it's not just standardized apps! link attributes can also be advertised for User-Defined Applications (UDAs) 🌈 those aren't standardized and they're outside the scope of this document, so no spoilers there 🙈

the following sections define the format of all this, so let's go 💜

4.1. Application Identifier Bit Mask 🎀

okay this part is giving bit-level realness 😭 identifying the set of apps for a link attribute advert uses two bit masks. one is for standard apps, where what each bit means lives in an IANA-controlled registry (see Section 7.4) 🍓 the other is for non-standard UDAs.

this encoding is used by BOTH the ASLA sub-TLV and the ASLA SRLG TLV, so it's a whole vibe ✨

          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) 🧚

this is the Standard Application Identifier Bit Mask Length + Flag byte:

          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |L| SABM Length |
         +-+-+-+-+-+-+-+-+
  • L-flag: the Legacy Flag 🕰️ see Section 4.2 for how it's used.
  • SABM Length: 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) 🌸

this is the User-Defined Application Identifier Bit Mask Length + Flag byte:

          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |R| UDABM Length|
         +-+-+-+-+-+-+-+-+
  • R: Reserved. it SHOULD be transmitted as 0 and MUST be ignored on receipt 🫶
  • UDABM Length: 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, which is (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, which is (UDABM Length * 8) bits. this field is omitted if UDABM Length is 0 🙈

          0 1 2 3 4 5 6 7 ...
         +-+-+-+-+-+-+-+-+...
         |                ...
         +-+-+-+-+-+-+-+-+...
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 🍼

UDA bits have no relationship to Standard Application Identifier Bits, and they're 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, these 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. 🔒

this sub-TLV is for TLVs Advertising Neighbor Information, and it lets you specify the apps and their app-specific attribute values 🍒

  • Type: 16 👑
  • Length: Variable (1 octet) 📏
  • Value: Application Identifier Bit Mask (as defined in Section 4.1), plus Link Attribute sub-sub-TLVs. the sub-sub-TLV 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 the applications in the bit mask MUST use the link attribute advertisements in the sub-TLV 🎯

when the L-flag IS set, all of the apps 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 those attributes MUST NOT be advertised for the apps in the SABM or UDABM, and all such sub-sub-TLVs MUST be ignored on receipt 🛑

multiple ASLA sub-TLVs for the same link MAY be advertised. when they do show up, they SHOULD advertise non-conflicting application/attribute pairs 🤝 a conflict is when the same app is tied to two different values for the same link attribute on a given link. when conflicting values for the same app/attribute/link are advertised, the first advertisement received in the lowest-numbered Link State Protocol Data Unit (LSP) MUST be used, and later advertisements of that same attribute MUST be ignored 🥇

for a given app, the L-flag MUST be the same in all sub-TLVs for a given link. if that constraint gets violated, the L-flag MUST be considered set for that app 🚨

the big takeaway: for a given app, EITHER the attribute values in ASLA sub-sub-TLVs are used OR the values in legacy sub-TLVs are used, but NOT both 💜

link attributes MAY be advertised with zero-length Application Identifier Bit Masks for both standard apps and UDAs. those advertisements MUST be used by standard apps 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, they 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 sub-sub-TLV format matches the corresponding legacy sub-TLV, and IANA has assigned the legacy sub-TLV identifier to the corresponding sub-sub-TLV 🎀

maximum link bandwidth is an application-independent attribute of the link 🌍 when advertised using the ASLA sub-TLV, multiple values for the same link MUST NOT be advertised. this is most efficient with a single advertisement for a given link, where the Application Identifier Bit Mask identifies ALL the apps using that link's value 🧠

it's also possible to advertise the same value for a given link multiple times with disjoint sets of apps in the mask. less efficient, but still valid 🤷‍♀️

it's 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 ASLA 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 bunch of dynamic performance metrics for a link 🌡️ it's conceivable that those could be measured for traffic specific to a particular app, so this document supports advertising these link attributes per app 💅

in practice though, it may well be more practical to have these metrics reflect the performance of ALL traffic on the link, regardless of app 🫠 in that case, the advertisements get associated with all the apps using that link. you can do this by either explicitly listing the apps in the Application Identifier Bit Mask, or by using a zero-length Application Identifier Bit Mask. the zero-length approach is further discussed in Section 6.2 🔁

4.3. Application-Specific SRLG TLV 🎀

Okay so there's a TLV whose whole job is advertising application-specific SRLGs for a given link 🦋. It's giving TLV 138 [RFC5307] and TLV 139 [RFC6119] vibes, but the glow-up is that this one single TLV works for IPv4, IPv6, AND unnumbered identifiers on a link 💅. Instead of locking in one identifier format, it uses sub-TLVs to hold the link identifiers, which gives the flexible formatting needed to support multiple link identifier types ✨.

The layout goes like this 🧚:

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 💀. No exceptions, bestie.

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 🔥.

These are the Link Identifier sub-TLVs that are defined. The values were chosen on purpose to 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 don't 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, you can figure out the corresponding legacy TLV (see Section 3.2), and the SRLG values advertised in that 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. If that constraint gets violated, the L-flag MUST be considered set for this application 😭.

5. Attribute Advertisements and Enablement ✨

This document defines extensions to support advertising ASLAs 🦋.

Whether the presence of link attribute advertisements for a given application means the application is enabled on that link depends on the application. Same goes for the absence: whether no link attribute advertisements means the application is NOT enabled depends on the application too 🙃.

For RSVP-TE, advertising ASLAs implies RSVP is enabled on that link. If there are no RSVP-TE ASLAs AND no legacy advertisements, then RSVP is not enabled on that link 💅.

For SR Policy, advertising ASLAs does NOT indicate that SR Policy is enabled 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, whether or not there are link attribute advertisements 🧚.

For LFA, advertising ASLAs does NOT indicate that LFA is enabled on that link. Enablement is controlled by local configuration ⭐.

If more standard applications get defined to use this mechanism in the future, the specification defining that use MUST define the relationship between ASLA advertisements and enablement for those applications 🔥.

This document allows ASLAs to be advertised with no application identifiers, meaning 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 🌈. But if an application uses link attribute advertisements to infer whether it's enabled on a link (RSVP-TE is an example), the missing application identifier leaves it ambiguous whether that application is enabled on such a link. You have to think about this when you use the "any application" encoding 🙈.

6. Deployment Considerations 🌸

This section talks about deployment considerations for using ASLA advertisements 🫶.

6.1. Use of Legacy Advertisements 💜

Bit identifiers for standard applications are defined in Section 4.1. Every identifier defined in this document is tied to an application that was already deployed in some networks before this document was written, so those applications were deployed with legacy advertisements 🍓. The standard applications defined here may keep using legacy advertisements for a given link as long as at least one of these 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 where SR Policy and/or LFA advertisements are required and the attribute values SR Policy and/or LFA use on all those links are fully congruent with the links and attribute values used by RSVP-TE.

Under the conditions above, implementations that support the extensions in this document get to choose between legacy advertisements or application-specific advertisements for SR Policy and/or LFA 👑. That means implementations need controls for which types of advertisements get sent and processed on receipt for these applications. More on the related issues in Section 6.3 💅.

New applications that future documents define to use the advertisements in this document MUST NOT make use of legacy advertisements. This keeps deployment simple, since new applications don't need to support multiple ways of advertising attributes 🦋.

6.2. Use of Zero-Length Application Identifier Bit Masks 🧚

Link attribute advertisements with zero-length Application Identifier Bit Masks, for both standard applications and UDAs, can be used by any application, subject to the restrictions in Section 4.2 ✨. If support for a new application shows up on any node in a network while these advertisements are around, the new application will use them once the restrictions above are met 😭. If that's not what you want, existing link attribute advertisements MUST be readvertised with an explicit set of applications specified before the new application is introduced 🔥.

6.3. Interoperability, Backwards Compatibility, and Migration Concerns 🫶

Existing deployments of RSVP-TE, SR Policy, and/or LFA use the legacy advertisements listed in Section 3 🍓. Routers that don't support the extensions in this document will only process legacy advertisements, and they're likely to infer that RSVP-TE is enabled on links that have legacy advertisements 🙈. Deployments using legacy advertisements are expected to stick around for a significant amount of time. So deployments using the extensions in this document, when there are routers around that don't support them, need to be able to interoperate with the legacy routers' use of legacy advertisements 💜. The subsections below cover the interoperability and backwards-compatibility concerns for a bunch of deployment scenarios 🌈.

6.3.1. Multiple Applications: Common Attributes with RSVP-TE 💖

When multiple applications use a given link, one of them is RSVP-TE, and all link attributes for that link are common to every application using it, interoperability is achieved by using legacy advertisements and sending application-specific advertisements with the L-flag set and no link attribute values. That way you avoid duplicating link attribute advertisements 👑.

6.3.2. Multiple Applications: All Attributes Not Shared with RSVP-TE 🔥

When one or more applications other than RSVP-TE use a given link, and one or more link attribute values aren't shared with RSVP-TE, you need application-specific advertisements as defined in this document 💅. Attributes for applications other than RSVP-TE MUST be advertised using application-specific advertisements with the L-flag clear. If some link attributes are shared with RSVP-TE, this means duplicate advertisements for those attributes 🙃.

These guidelines apply both when RSVP-TE isn't using any advertised attributes on a link, and when RSVP-TE is using some link attribute advertisements on the link but some link attributes can't be shared with RSVP-TE ✨.

6.3.3. Interoperability with Legacy Routers 🌸

For the standard applications defined in this document, routers that don't support the extensions in this document will only send and receive legacy link attribute advertisements. The link attribute values for these applications are always shared, since legacy routers have no way to advertise or process application-specific values 🦋. As long as there's any legacy router in the network with any of the standard applications from 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 every legacy router has been upgraded, you can migrate from legacy advertisements to ASLA advertisements with these steps:

  1. Send ASLA advertisements while continuing to advertise legacy advertisements (so everything is duplicated). Receiving routers keep using the legacy advertisements.
  2. Enable the use of the ASLA advertisements on all routers.
  3. Remove legacy advertisements.

Once the migration is done, it becomes possible to advertise incongruent values per application on a given link 🎀.

Note that the L-flag is of no value in the migration 🙈.

Documents that define new applications using the application-specific advertisements in this document MUST discuss the interoperability and backwards-compatibility issues that could come up in the presence of routers that don't support the new application 🫶💜

6.3.4. Use of Application-Specific Advertisements for RSVP-TE 🎀

okay so bestie, here's the glow-up path for RSVP-TE 💅 The extensions in this document count RSVP-TE as one of the applications, which means that in the future, implementations can migrate over to application-specific advertisements to support RSVP-TE ✨ It can be done in this 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, so get ready for the registry tea ☕

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. 💜

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

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.

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 🚨

Okay, security time, and I'm being so serious about this one 😭🔐 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

okay so these are the ones you need to read before you can even pretend you understand the protocol 📚 the normative ones are load-bearing, no cap 💅

10.2. Informative References

these ones are the helpful background reads 🦋 not strictly required, but so good for context

Acknowledgements 🫶

the squad gets a shoutout 🎀 RFC 8919 thanked these legends:

|  Eric Rosen and Acee Lindem for their careful review and content
|  suggestions.

and for this new version, the authors would like to thank Bruno Decraene 💖 he's giving main character energy in the credits, fr fr 👑

Authors' Addresses 💌

the people who wrote this whole thing, with their contact info 🧚

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
📦 where this page comes from