RFC 8919

IS-IS Application-Specific Link Attributes

📅 published October 2020, from ietf
  • Who wrote it: L. Ginsberg (Cisco Systems), P. Psenak (Cisco Systems), S. Previdi (Huawei Technologies), W. Henderickx (Nokia), and J. Drake (Juniper Networks) 🫶
  • Publisher: the Internet Engineering Task Force (IETF), as RFC number 8919
  • Category: Standards Track, so it's an actual Internet standard 💅
  • ISSN: 2070-1721
  • Date: October 2020 📅
  • Obsoletes and updates: the header doesn't list anything it obsoletes or updates 🧚

Abstract

okay so the IS-IS protocol already has link attribute advertisements for traffic engineering, and they're used by RSVP-TE deployments 🌸 Then more applications showed up that want those same attributes too, like Segment Routing Policy and Loop-Free Alternates. The problem is that the current advertisements can't carry an application-specific value for one attribute, and they can't say which applications are using the value advertised for a link. This document introduces new link attribute advertisements that fix both of those things. It's giving clean and it's so needed ✨

Status of This Memo

This is an Internet Standards Track document 🎀

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 💖

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8919 🦋

Copyright (c) 2020 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) as they stand on the date this document was published. Please read these carefully, because they explain your rights and restrictions for this document 📜 Code Components taken from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified 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.  Sub-sub-TLV Codepoints for Application-Specific Link
        Attributes Registry
  7.4.  Link Attribute Application Identifiers Registry
  7.5.  Sub-TLVs for TLV 238 Registry
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

Okay so the IS-IS protocol started advertising link attributes for traffic engineering (TE) with [RFC5305], and then [RFC5307], [RFC6119], [RFC7308], and [RFC8570] extended that. These extensions have mostly been used for Traffic Engineering over Multiprotocol Label Switching (MPLS) with the Resource Reservation Protocol (RSVP), which people shorten to RSVP-TE [RFC3209] 🫶

For this document, an application is a technology that uses link attribute advertisements. Section 3 lists some examples 🧚

In recent years, new applications have shown up that want a lot of the same link attributes RSVP-TE uses. These include Segment Routing (SR) Policy [SEGMENT-ROUTING] and Loop-Free Alternates (LFAs) [RFC5286] 💅 Here's the messy part: if a network runs both RSVP-TE and SR Policy, you can't clearly say which advertisements belong to RSVP-TE and which belong to SR Policy. If the two topologies are fully congruent, it might be fine, but any incongruence causes confusion 🙈

Here's an example of how that goes wrong. Say RSVP-TE is only turned on for some of a network's links. Then a link attribute gets advertised for some other application, like SR Policy, on a link where RSVP-TE is off. The RSVP-TE head-end router sees that attribute on the link and assumes RSVP-TE is enabled there, even though it isn't 😭 If that head-end then tries to set up an RSVP-TE path over that link, the path setup fails 💀

It gets worse when both applications run on the same link but want different values for the same attribute. The current advertisements can't carry application-specific values for one attribute on one link 🔥

This document defines extensions that fix these problems. Also, since new use cases for link attributes will probably keep showing up, this document defines a solution that's easy to extend to 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 💖

Like we said, link attribute use cases will keep evolving. So any talk about existing use cases is limited to the requirements we know about as of this writing. To figure out what IS-IS needs beyond what it already has, we only have 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] covers use cases and requirements for Segment Routing (SR). One of those use cases is SR Policy, which is defined in [SEGMENT-ROUTING]. If a network runs both RSVP-TE and SR Policy, link attribute advertisements can be used by one or both of them. The link attributes advertised on a link for SR Policy don't have to match the ones advertised on that same link for RSVP-TE. So there's a clear requirement to indicate separately which link attribute advertisements each application uses 🦋

More applications may want link attributes later, so there's another requirement: the extensions have to let new applications be associated with link attributes without changing the advertisement format or creating new backwards-compatibility problems 🧚

Finally, lots of cases can share one attribute value across several applications, so the solution must minimize advertising duplicate link/attribute pairs whenever possible 🫶

3. Legacy Advertisements 🍓

Advertisements that already support RSVP-TE include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223, plus TLVs for Shared Risk Link Group (SRLG) advertisement ✨

Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223" registry 📜

TLVs are defined in the "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: Sub-TLVs for TLVs 22, 23, 25,
              141, 222, and 223

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 this section is where the magic happens, bestie 🧚 we're introducing two brand-new codepoints so links can carry attributes for specific applications:

  • 1) the Application-Specific Link Attributes sub-TLV, which works inside TLVs 22, 23, 25, 141, 222, and 223 (see Section 4.2) 💖
  • 2) the Application-Specific Shared Risk Link Group (SRLG) TLV (see Section 4.3) 🎀

to make all that work, we also need an application identifier bit mask so we can say which applications an advertisement is for (see Section 4.1) 🦋

also, lowkey important: link attributes can be advertised for user-defined applications too 💅 those aren't standardized and they're outside the scope of this document, so we're not going there 🙈

the sections below define the exact format of these new advertisements. let's go 🌈

4.1. Application Identifier Bit Mask 🫶

okay so identifying which applications a link attribute advertisement belongs to uses two bit masks ✨ one is for standard applications, where each bit is defined in a brand-new IANA-controlled registry (see Section 7.4) 📋 the other is for non-standard user-defined applications (UDAs) 🌸

both the Application-Specific Link Attributes sub-TLV and the Application-Specific SRLG TLV use this same encoding 💜

 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
+--+--+--+--+--+--+--+--+

the first octet is the SABM Length + Flag (Standard Application Identifier Bit Mask Length + Flag) 💅

            0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+
           |L| SABM Length |
           +-+-+-+-+-+-+-+-+
  • L-flag: the Legacy Flag 🕰️ see Section 4.2 for how this one gets used
  • SABM Length: how many octets (0-8) the Standard Application Identifier Bit Mask is. it SHOULD be the minimum needed to send all the bits that are set ✨

the next octet is the UDABM Length + Flag (User-Defined Application Identifier Bit Mask Length + Flag) 🎀

            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: how many octets (0-8) the User-Defined Application Identifier Bit Mask is. same rule as above: it SHOULD be the minimum needed to send all the set bits 💖

the SABM field is variable length, and it's (SABM Length * 8) bits long 🧮 if SABM Length is 0, this field is omitted entirely 🙈

            0 1 2 3 4 5 6 7 ...
           +-+-+-+-+-+-+-+-+...
           |R|S|F|          ...
           +-+-+-+-+-+-+-+-+...
  • R-bit: set to specify RSVP-TE 🚀
  • S-bit: set to specify Segment Routing Policy 🧚
  • F-bit: set to specify Loop-Free Alternate (LFA), which includes all LFA types 🌈

the UDABM field is also variable length, (UDABM Length * 8) bits long, and it's omitted if UDABM Length is 0 🫧

            0 1 2 3 4 5 6 7 ...
           +-+-+-+-+-+-+-+-+...
           |                ...
           +-+-+-+-+-+-+-+-+...
📝 Note: SABM/UDABM Length is arbitrarily limited to 8 octets so there's still enough room to advertise link attributes without going over 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 the standard ones, and they're not managed by IANA or any other standards body 🦋 it is recommended that UDA bits start at bit 0 so you need the fewest octets to advertise all your UDAs 💜

for both SABM and UDABM, these rules apply, no cap 💀

  • undefined bits that get transmitted MUST be transmitted as 0 and MUST be ignored on receipt 🫶
  • bits that aren't transmitted MUST be treated as if they're set to 0 on receipt 🌸
  • bits an implementation doesn't support MUST be ignored on receipt 🌷

this is the new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 that lets you specify the applications and their 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 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 L-flag is set in the Application Identifier Bit Mask, all the applications in that bit mask MUST use the legacy advertisements for the corresponding link. those live in TLVs 22, 23, 25, 141, 222, and 223, or in TLV 138, or in TLV 139, whichever fits 🕰️ and link attribute sub-sub-TLVs for those attributes MUST NOT be advertised for the applications in the Standard or User-Defined Application Identifier Bit Masks, and any such advertisements MUST be ignored on receipt 🙅‍♀️

you MAY advertise multiple Application-Specific Link Attributes sub-TLVs for the same link 🫧 and when you do, they SHOULD advertise non-conflicting application/attribute pairs ✨ a conflict is when the same application is tied to two different values for the same link attribute on a given link 😭 when conflicting values show up anyway, the first advertisement received in the lowest-numbered LSP SHOULD be used, and later advertisements of that same attribute SHOULD be ignored 🧾

for a given application, the L-flag MUST be the same in all sub-TLVs for a given link. if that rule gets broken, the L-flag MUST be considered set for that application 🚨

if link attributes are advertised with zero-length Application Identifier Bit Masks for both standard and user-defined applications, then any standard application and/or any UDA is allowed to use that set of link attributes 🌈 as long as there isn't another set of attributes on that same link tied to a non-zero-length bit mask with a matching Application Identifier bit set 💖

IANA created a new registry of sub-sub-TLVs for 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 each sub-sub-TLV matches its legacy sub-TLV, and IANA assigned the legacy sub-TLV identifier to the matching sub-sub-TLV 🫶

maximum link bandwidth is an application-independent attribute of the link 🌍 when it's advertised using the Application-Specific Link Attributes sub-TLV, multiple values for the same link MUST NOT be advertised 🙅‍♀️ the most efficient way to do this is one advertisement per link, with an Application Identifier Bit Mask that covers every application using that value 💅

you can advertise the same value for a link multiple times with disjoint sets of applications in the mask. it's less efficient, but it's still valid 🫧

it's also possible to send a single advertisement with zero-length SABM and UDABM, as long as the constraints discussed in Sections 4.2 and 6.2 are acceptable 🌸

if different values for maximum link bandwidth are advertised for a given link, 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 they're advertised using the Application-Specific Link Attributes sub-TLV, bits other than the RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit Mask 🙅‍♀️ if an advertisement of either one arrives with bits other than the RSVP-TE 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 those could be measured specifically for traffic belonging to one application, so this document supports advertising these link attributes per application 🧠 in practice though, it may be more practical for the metrics to reflect the performance of all traffic on the link, no matter the application 🌈 in that case, the advertisements get associated with every application using that link 💜 you can do that by explicitly listing the applications in the Application Identifier Bit Mask, or by using a zero-length Application Identifier Bit Mask ✨

4.3. Application-Specific SRLG TLV ✨

okay bestie, so this is the new TLV for advertising application-specific SRLGs on a link 🦋. It's similar to TLV 138 [RFC5307] and TLV 139 [RFC6119], but this one is giving everything: a single TLV handles IPv4, IPv6, and unnumbered identifiers for a link. Instead of hardcoding one identifier format, it uses sub-TLVs to encode the link identifiers, so the formatting can flex for all the different 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)

Here 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], so everything lines up nicely.

+======+=========================================+
| 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

Now the rules, and these ones are non-negotiable 🫶. 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 🌸.

Now the L-flag, which is where it gets a little spicy 🌶️. 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. It's like the legacy TLV is the source of truth here 👑

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. Consistency is everything, periodt 💅

5. Attribute Advertisements and Enablement ✨

okay so this section is all about whether advertising link attributes actually means an application is turned on 🦋. This document defines extensions to support the advertisement of application-specific link attributes, and whether the presence of those 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. Every app has its own vibe 🌈

For RSVP-TE, advertising application-specific link attributes implies that RSVP is enabled on that link 🎀. The absence of RSVP-TE application-specific link attributes in combination with the absence of legacy advertisements implies that RSVP is not enabled on that link.

For SR Policy, it's a different story 🧚. Advertising application-specific link attributes 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.

For LFA, the same energy applies 🍓. Advertising application-specific link attributes does not indicate enablement of LFA on that link. Enablement is controlled by local configuration.

Looking ahead ✨: in the future, if additional standard applications are defined to use this mechanism, the specification defining this use MUST define the relationship between application-specific link attribute advertisements and enablement for that application. Future authors, you have been warned 🫡

This document also allows the advertisement of application-specific link attributes with no application identifiers. That means both the Standard Application Identifier Bit Mask and the User-Defined Application Identifier Bit Mask are not present (see Section 4.1). This supports the use of the link attribute by any application 🌟. Now, if an app uses link attribute advertisements to infer that it's enabled on a link (like RSVP-TE does), the missing application identifier leaves it ambiguous whether that application is enabled on such a link. This needs to be considered when making use of the "any application" encoding. Think before you use it, bestie 🙈

6. Deployment Considerations ✨

this section talks about deployment considerations for using application-specific link attribute advertisements 🚀.

6.1. Use of Legacy Advertisements

okay, so the bit identifiers for standard applications live in Section 4.1 🦋. Every identifier defined in this document belongs to an application that was already deployed in some networks before this document was written. So those apps have been deploying with the legacy advertisements. The standard applications defined here 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 those conditions, implementations that support the extensions in this document get to choose between legacy advertisements or application-specific advertisements for 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. More on the associated issues in Section 6.3 🌸.

Now for new applications 🔥: new applications that future documents define to make use of the advertisements 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 them. One way, no drama 👑

6.2. Use of Zero-Length Application Identifier Bit Masks

okay so link attribute advertisements with zero-length Application Identifier Bit Masks, for both standard and user-defined applications, can be used by any application 🦋. That's 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 exist, the new application is allowed to use them 😭. If that's not what you want, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced. Get your explicit lists in order first, bestie ✨

6.3. Interoperability, Backwards Compatibility, and Migration Concerns

so 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 where legacy advertisements exist. Deployments using legacy advertisements are expected to stick around for a significant period of time. So deployments using these extensions alongside routers that don't support them need to be able to interoperate with the legacy advertisements used by those legacy routers 🫶. The following subsections cover interoperability and backwards-compatibility concerns for a few 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 on that link are shared by every application using it, you're good 🎀. Interoperability is achieved by using legacy advertisements and sending application-specific advertisements with the L-flag set and no link attribute values. No duplicated attributes, no extra noise 🌈

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

now if one or more applications other than RSVP-TE use a given link, and one or more link attribute values are not 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 that have the L-flag clear. When some link attributes are shared with RSVP-TE, this means duplicate advertisements for those attributes. Little bit of duplication, big bit of clarity 💜

These guidelines apply both when RSVP-TE is not using any advertised attributes on a link and when 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

okay this one's important, so for the applications in this document, routers that don't support these extensions will only send and receive legacy link attribute advertisements 💀. As long as any legacy router in the network has any of these applications enabled, all routers MUST continue to advertise link attributes using legacy advertisements. Also, the link attribute values for the set of applications supported by legacy routers (RSVP-TE, SR Policy, and/or LFA) are always shared, because legacy routers have no way of advertising or processing application-specific values 🫠.

Once every legacy router has been upgraded, you can migrate from legacy advertisements to ASLA advertisements in three steps 🚀:

  1. Send ASLA advertisements while continuing to advertise using legacy (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 🌸. Also, note that the use of the L-flag is of no value in the migration, so don't stress about it there ✨.

Last but not least 🔥: documents defining new applications that make use of the application-specific advertisements 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. Future authors, we're counting on you, periodt 👑

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

okay so this doc adds RSVP-TE as one of the applications 💅 which means that down the road, implementations can totally migrate to using application-specific advertisements for RSVP-TE ✨ the stepwise way to do it looks like this:

  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 R-bit set. At this point, both legacy and application-specific advertisements are being sent. 👀
  3. Remove legacy advertisements. 🧹

7. IANA Considerations 🎀

this section is the big list of protocol codepoint changes from this doc and the related updates IANA made 📋

for the new registries defined under the "IS-IS TLV Codepoints" registry with the "Expert Review" registration procedure (see Sections 7.3 and 7.5), guidance for designated experts can be found in [RFC7370]. 🧑‍🏫

IANA registered the new sub-TLV from Section 4.2 in the "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223" registry, so it's official now 🔥

    +======+======================+====+====+======+=====+=====+=====+
    | 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 registered the new TLV from Section 4.3 in the IS-IS "TLV Codepoints Registry" ✨

      +=======+===========================+=====+=====+=====+=======+
      | Value | Description               | IIH | LSP | SNP | Purge |
      +=======+===========================+=====+=====+=====+=======+
      | 238   | Application-Specific SRLG | n   | y   | n   | n     |
      +-------+---------------------------+-----+-----+-----+-------+

Table 4

IANA created a brand new registry called "Sub-sub-TLV Codepoints for Application-Specific Link Attributes" under the "IS-IS TLV Codepoints" registry. It controls who gets which sub-sub-TLV codepoint for the Application-Specific Link Attributes sub-TLV from Section 7.1 🫶 The registration procedure is "Expert Review" as defined in [RFC8126]. Here's the starting lineup:

        +========+====================================+===========+
        | 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 also added these notes to this registry, and they're important 👑

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 22, 23, 25, 141, 222, and 223 and as a sub-sub-TLV of the Application-Specific Link Attributes sub-TLV defined in RFC 8919, then the same numerical code should be assigned to the link attribute whenever possible. 💖

IANA created a new registry called "Link Attribute Application Identifiers" under the "Interior Gateway Protocol (IGP) Parameters" registry. It controls the assignment of Application Identifier Bits. The registration policy is "Expert Review" as defined in [RFC8126]. Bit definitions SHOULD be assigned so that all bits in the lowest available octet are allocated before any bits in the next octet are assigned. This keeps the number of octets that need to be transmitted as small as possible 🍓 The initial contents look like this:

                +=======+================================+
                | 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. Sub-TLVs for TLV 238 Registry 🍒

IANA created a new registry called "Sub-TLVs for TLV 238" under the "IS-IS TLV Codepoints" registry. It controls the assignment of sub-TLV types for the Application-Specific SRLG TLV. The registration procedure is "Expert Review" as defined in [RFC8126]. The initial contents are:

          +========+===============================+===========+
          | 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 also added this note to the 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, this part is serious bestie, so read it carefully 🙈 security concerns for IS-IS are covered in [ISO10589], [RFC5304], and [RFC5310]. IS-IS is deployed under a single administrative domain, but there can be deployments where potential attackers have access to one or more networks in the IS-IS routing domain. In those deployments, the stronger authentication mechanisms defined in the aforementioned documents SHOULD be used. 🔒

this document defines a new way to advertise link attributes 🦋 Tampering with the information defined here may affect applications that use it, including impacting traffic engineering as discussed in [RFC8570]. Because the advertisements in this document limit their scope to specific applications, the impact of tampering is limited in scope the same way 🫶

9. References 📚

9.1. Normative References 📚✨

okay bestie, this is the reading list the spec needs you to have read 🧾💅

9.2. Informative References 🦋

these ones are the extra reading that gives you the bigger picture 🌸

Acknowledgements 🫶

the authors wanna give a big shoutout to Eric Rosen and Acee Lindem 💜 they gave this thing a careful review and super helpful content suggestions, so iconic of them 🙌

Authors' Addresses 🎀

meet the squad who wrote this 👑

Les Ginsberg
Cisco Systems
821 Alder Drive
Milpitas, CA 95035
United States of America

Email: ginsberg@cisco.com
Peter Psenak
Cisco Systems
Apollo Business Center
Mlynske nivy 43
821 09 Bratislava
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

that's the whole thing, bestie! 🌈💖 the RFC is complete and we are not okay about how good it is 😭✨

📦 where this page comes from