RFC 8570

IS-IS Traffic Engineering (TE) Metric Extensions

📅 published March 2019, from ietf

Part 1 of 4: RFC 8570 💖 IS-IS TE Metric Extensions 🦋

okay bestie, let's get into it! 🎀 This one is Standards Track (so it's an actual official protocol spec, not just a vibe 💅), published March 2019 by the IETF, with ISSN 2070-1721. The authors are L. Ginsberg (editor, Cisco Systems, Inc.), S. Previdi (editor, Huawei), S. Giacalone (Microsoft), D. Ward (Cisco Systems, Inc.), J. Drake (Juniper Networks), and Q. Wu (Huawei). 👑

It obsoletes RFC 7810 🙈, so this is the new and improved version. It doesn't update anything else. Iconic glow-up energy ✨

The whole vibe is IS-IS routing 🌈, the protocol routers use to share who-connects-to-who info, and it's getting a metrics upgrade so routers can share how the links are performing too 🧚

Status of This Memo 💜

This is an Internet Standards Track document ✨. It's a product of the IETF, it reflects consensus from the IETF community, got public review, and was approved for publication by the IESG. For more on Internet Standards, check Section 2 of RFC 7841 🎀.

Updates and errata for this one live at https://www.rfc-editor.org/info/rfc8570 🌸.

Copyright (c) 2019 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 in effect on the date of publication. Please actually read these, they cover your rights and restrictions 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and come without warranty as described in that license 🫶.

1. Introduction ✨

okay so picture this 💅: in certain networks, like financial information networks (think stock market data providers 📈), network-performance info (like latency) is becoming just as critical to picking a data path as the usual metrics 😭. Those networks have SO much money riding on getting market data "real time" and making trades faster than everyone else 💸. So hop count or cost? Kinda tangentially important now 💀. What they actually want is to pick paths based on performance data (latency, etc.) in a way that's cost-effective and scalable 🔥.

This doc describes extensions (we call them "IS-IS TE Metric Extensions" 🧚) to the Extended IS Reachability TLV defined in [RFC5305]. These extensions let you distribute network-performance info, like link delay, delay variation, packet loss, residual bandwidth, and available bandwidth 🌈.

The data these extensions distribute is meant to be used as part of routing itself (like swapping cost for latency, or looking at bandwidth as well as cost 👑). It can also enhance Constrained Shortest Path First (CSPF) 🦋, or supplement the data an Application-Layer Traffic Optimization (ALTO) server uses [RFC7285] 💖. For CSPF, the data can help set up, fail over, and fail back data paths using protocols like RSVP-TE [RFC3209] 🎀.

Now, the important bit 🙈: these mechanisms only spread performance info around. How you originally gather that info (like the methods in [RFC6375]) and what you do with it once it's distributed are outside the scope of this doc 💅. For example measurement mechanisms for latency, delay variation, and loss in an MPLS network are in [RFC6374] 🧚.

Here's the spicy part 🌶️: this document doesn't say how to get the performance info, but measured delay SHOULD NOT vary much based on the offered traffic load 🌸. So queuing delays SHOULD NOT be included in the delay measurement 😭. For links like forwarding adjacencies [RFC4206], you've gotta be careful that the measured delay avoids big queuing delays 💀. You can do that a couple of ways: (1) measure with a traffic class that barely queues, or (2) add up the measured link delays of the components along the link's path ✨.

This document obsoletes [RFC7810] 🙈.

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 read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💜. Lowercase versions are just regular words, bestie 🙈.

2. TE Metric Extensions to IS-IS 🦋

Alright, so this section registers new IS-IS TE sub-TLVs in the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry 🌈. These new sub-TLVs are how you distribute network-performance info 💅. They build on IS-IS TE [RFC5305] and GMPLS [RFC4203] ✨.

The Extended IS Reachability TLV (type 22, from [RFC5305]), the Inter-AS Reachability TLV (also called "inter-AS reachability information TLV", type 141, from [RFC5316]), and the MT-ISN TLV (type 222, from [RFC5120]) all have nested sub-TLVs, so they're super easy to extend 🧚. This doc registers these sub-TLVs:

   Type    Description
   ----------------------------------------------------
    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

As you can see 👀, each sub-TLV carries a different kind of performance info 🌸. The new sub-TLVs have a bit called the Anomalous (or "A") bit 🦋. When the A bit is clear (or the sub-TLV doesn't have an A bit at all), the sub-TLV describes steady-state link performance 💖. That info could be used to build a steady-state performance topology for initial tunnel-path computation, or to check alternative failover paths 🎀.

When network performance breaks configurable link-local thresholds, a sub-TLV with the A bit set gets advertised 🚨. The receiving node could use that to decide whether to (1) fail traffic over to a backup path, or (2) calculate a whole new path 💅. From the MPLS angle, the A bit lets LSP ingress nodes figure out whether the link in the sub-TLV affects any of the label switched paths they're the ingress for 🧚. If it does, they can check whether those LSPs still meet their end-to-end performance goals 👑. If not, the node could move affected traffic onto a pre-established protection LSP, or set up a brand new LSP and put the traffic there ✨.

If link performance then improves past a configurable minimum (the reuse threshold) 🌈, that sub-TLV can be re-advertised with the A bit cleared 🫶. Then the receiving node can do whatever re-optimization (or failback) it wants, including nothing at all 💅.

Heads up 🙈: if a sub-TLV doesn't include the A bit, it can't be used for failover purposes. The A bit was left out of some sub-TLVs on purpose to help reduce oscillations 🌀. See Section 5 for more 🦋.

Consistent with the existing IS-IS TE spec [RFC5305], the bandwidth advertisements here MUST be encoded as IEEE floating-point values [IEEE754] 💖. Delay and delay-variation advertisements MUST be encoded as integer values 🎀. Delay values MUST be quantified in microseconds, packet loss MUST be quantified as a percentage of packets sent, and bandwidth MUST be sent as bytes per second 🧚. All values (except residual bandwidth) MUST be calculated as rolling averages, and the averaging period MUST be a configurable period of time 👑. See Section 5 for more ✨.

Part 2 coming up next, periodt 💅🦋

3. Interface and Neighbor Addresses ✨

okay so IS-IS TE Metric Extensions sub-TLVs aren't only for the TE crowd 💅 They can also be used for computing paths when there's no TE subsystem around. no cap 🦋

BUT, and this is a big but 🙈 just like in the TE case, the Interface Address and Neighbor Address sub-TLVs (IPv4 or IPv6) MUST be present. Their encoding is defined in [RFC5305] for IPv4 and in [RFC6119] for IPv6, so go check those if you want the exact details 🧚

4. Sub-TLV Details 🎀

this sub-TLV is all about the average link delay between two directly connected IS-IS neighbors 💖 The delay it advertises MUST be the delay from the local neighbor to the remote neighbor (aka the forward-path latency). Here's the layout:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|  RESERVED   |                   Delay                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 1

where:

  • Type: 33
  • Length: 4
  • A bit: this is the Anomalous (A) bit 🚨 It gets set when the measured value of this parameter goes over its configured maximum threshold. It gets cleared when the measured value drops back below its configured reuse threshold. When the A bit is cleared, the sub-TLV is showing steady-state link performance ✨
  • RESERVED: reserved for future use, so it's giving "don't touch" 🙅‍♀️ It MUST be set to 0 when sent and MUST be ignored when received.
  • Delay: this 24-bit field carries the average link delay over a configurable interval, in microseconds, as a plain integer 🍓 When it's set to the maximum value 16,777,215 (16.777215 seconds), the delay is at least that much and might be even bigger 😭

This sub-TLV is the min and max delay duo between two directly connected IS-IS neighbors 👯‍♀️ The delay it advertises MUST be the delay from the local neighbor to the remote neighbor (i.e., the forward-path latency). Here's the diagram:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A| RESERVED    |                   Min Delay                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   RESERVED    |                   Max Delay                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

where:

  • Type: 34
  • Length: 8
  • A bit: the Anomalous (A) bit 🚨 It gets set when one or more measured values go over a configured maximum threshold. It gets cleared when the measured value falls below its configured reuse threshold. When it's cleared, the sub-TLV represents steady-state link performance 🌈
  • RESERVED: reserved for future use 🙅‍♀️ It MUST be set to 0 when sent and MUST be ignored when received.
  • Min Delay: a 24-bit field with the minimum measured link delay (in microseconds) over a configurable interval, as an integer 🫧
  • Max Delay: a 24-bit field with the maximum measured link delay (in microseconds) over a configurable interval, as an integer 🫧

Implementations MAY also let you configure an offset value (in microseconds) to be added to the measured delay, so operators can communicate their own delay constraints 🎛️

It's totally possible for Min Delay and Max Delay to be the same value 🥰

When the delay value (Min Delay or Max Delay) is set to the maximum value 16,777,215 (16.777215 seconds), the delay is at least that much and might be larger 😭

4.3. Unidirectional Delay Variation Sub-TLV 🦋

This sub-TLV advertises the average link delay variation between two directly connected IS-IS neighbors (the jitter tea ☕). The delay variation it advertises MUST be the delay from the local neighbor to the remote neighbor (i.e., the forward-path latency). Here's the diagram:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  RESERVED     |               Delay Variation                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 3

where:

  • Type: 35
  • Length: 4
  • RESERVED: reserved for future use 🙅‍♀️ It MUST be set to 0 when sent and MUST be ignored when received.
  • Delay Variation: a 24-bit field with the average link delay variation over a configurable interval, in microseconds, as an integer 🍓 When it's set to 0, it hasn't been measured. When it's set to the maximum value 16,777,215 (16.777215 seconds), the delay is at least that much and might be larger 😭

This sub-TLV advertises the loss (as a packet percentage) between two directly connected IS-IS neighbors 📉 The link loss it advertises MUST be the packet loss from the local neighbor to the remote neighbor (i.e., the forward-path loss). Here's the diagram:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|  RESERVED   |                    Link Loss                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

where:

  • Type: 36
  • Length: 4
  • A bit: the Anomalous (A) bit 🚨 It gets set when the measured value of this parameter goes over its configured maximum threshold. It gets cleared when the measured value falls below its configured reuse threshold. When it's cleared, the sub-TLV represents steady-state link performance ✨
  • RESERVED: reserved for future use 🙅‍♀️ It MUST be set to 0 when sent and MUST be ignored when received.
  • Link Loss: a 24-bit field with the link packet loss as a percentage of the total traffic sent over a configurable interval 📊 The basic unit is 0.000003%, where (2^24 - 2) is 50.331642%. That's the highest packet-loss percentage it can express. The reasoning is that precision matters more on high-speed links than advertising loss rates above that number, and high-speed links with over 50% loss are unusable anyway 🏎️ So measured values that are larger than the field maximum SHOULD be encoded as the maximum value.

4.5. Unidirectional Residual Bandwidth Sub-TLV 💸

This sub-TLV advertises the residual bandwidth between two directly connected IS-IS neighbors 💰 The residual bandwidth it advertises MUST be the residual bandwidth from the system that originates the Link State Advertisement (LSA) to its neighbor. Here's the diagram:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Residual Bandwidth                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 5

where:

  • Type: 37
  • Length: 4
  • Residual Bandwidth: this field carries the residual bandwidth on a link, a forwarding adjacency [RFC4206], or a bundled link. It's in IEEE floating-point format, with units of bytes per second 🫧 For a link or forwarding adjacency, residual bandwidth is defined as the maximum bandwidth [RFC5305] minus the bandwidth currently allocated to RSVP-TE label switched paths. For a bundled link, it's defined as the sum of the component link residual bandwidths.

The calculation of residual bandwidth is different from that of unreserved bandwidth [RFC5305] 🤓 This calculation subtracts tunnel reservations from the maximum bandwidth (i.e., the link capacity) [RFC5305] and gives you an aggregated remainder across priorities. Unreserved bandwidth, on the other hand, is subtracted from the maximum reservable bandwidth (the bandwidth that can theoretically be reserved) and gives you per-priority remainders. Residual bandwidth and unreserved bandwidth [RFC5305] can be used at the same time, and each has its own use case 💅 For example, the former can be used for applications like Weighted ECMP, while the latter can be used for call admission control 🌟

4.6. Unidirectional Available Bandwidth Sub-TLV 🌷

This sub-TLV advertises the available bandwidth between two directly connected IS-IS neighbors 🌊 The available bandwidth it advertises MUST be the available bandwidth from the system originating this sub-TLV. Here's the diagram:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Available Bandwidth                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 6

where:

  • Type: 38
  • Length: 4
  • Available Bandwidth: this field carries the available bandwidth on a link, a forwarding adjacency, or a bundled link. It's in IEEE floating-point format, with units of bytes per second 🫧 For a link or forwarding adjacency, available bandwidth is defined as residual bandwidth (see Section 4.5) minus the measured bandwidth used for the actual forwarding of non-RSVP-TE label switched path packets. For a bundled link, it's defined as the sum of the component link available bandwidths 💖

4.7. Unidirectional Utilized Bandwidth Sub-TLV ✨

okay bestie, this sub-TLV is how two directly connected IS-IS neighbors share how much bandwidth is being used 📡💖 the utilization it advertises MUST be the bandwidth coming from the system that originates the sub-TLV, so no sneaky borrowing from anyone else 🙅‍♀️ here's the layout:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Utilized Bandwidth                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7

where:

  • Type: 39 🎀
  • Length: 4 🌸
  • Utilized Bandwidth: this field carries the bandwidth utilization on a link, forwarding adjacency, or bundled link, in IEEE floating-point format with units of bytes per second 💅 for a link or forwarding adjacency, it's the actual utilization of the link (as measured by the node doing the advertising) 👑 for a bundled link, it's defined as the sum of the component link bandwidth utilizations ✨

5. Announcement Thresholds and Filters ✨

okay so the values in all the sub-TLVs (except minimum/maximum delay and residual bandwidth) MUST represent an average over a period of time, or come from a filter that's reasonably representative of an average 📊 a rolling average is one example, and honestly it's giving very reliable energy 💖

Minimum and maximum delay MUST each be derived in one of these ways: by taking the lowest and/or highest measured value over a measurement interval, or by using a filter or some other technique to get a reasonable minimum and maximum that represent the interval, with compensation for outliers 🧚

The measurement interval, any filter coefficients, and any advertisement intervals MUST be configurable per sub-TLV 🎛️

Besides the measurement intervals that control re-advertisement, implementations SHOULD provide configurable accelerated advertisement thresholds per sub-TLV, like this:

  1. If the measured parameter falls outside a configured upper bound (or, for the minimum delay metric only, a lower bound) and the advertised sub-TLV isn't already outside that bound, or
  2. If the difference between the last advertised value and the current measured value exceeds a configured threshold, then
  3. The advertisement is made immediately 🚀
  4. For sub-TLVs that include an A bit, an additional threshold SHOULD be included for the point where the performance counts as anomalous (and sub-TLVs with the A bit are sent). The A bit gets cleared when the sub-TLV's performance has been below (or re-crosses) this threshold for one or more advertisement intervals, so failback is allowed 🦋

To prevent oscillations, only the high threshold or the low threshold (but not both) may be used to trigger any given sub-TLV that supports both 🙈 no flip-flopping, periodt 💅

Also, once a measurement is outside the bounds of the threshold, any re-advertisement of a measurement that's back within the bounds would stay governed solely by the measurement interval for that sub-TLV ⏱️

6. Announcement Suppression 🫶

When link-performance values change by small amounts that fall under the thresholds that would trigger a sub-TLV announcement, implementations SHOULD suppress sub-TLV re-advertisement and/or lengthen the period within which the sub-TLVs are refreshed 😴 quiet is the new loud

Only the accelerated advertisement threshold mechanism described in Section 5 may shorten the re-advertisement interval 🏃‍♀️ all suppression and re-advertisement interval backoff timer features SHOULD be configurable 🎀

7. Network Stability and Announcement Periodicity 🌈

Sections 5 and 6 give you configurable mechanisms to bound the number of re-advertisements 🧱 instability might happen in very large networks if the measurement intervals are set low enough to overwhelm the processing of flooded information at some of the routers in the topology 😭 so care should be taken when setting these values, no cap

Additionally, the default measurement interval for all sub-TLVs SHOULD be 30 seconds ⏲️

Announcements MUST also be able to be throttled using configurable inter-update throttle timers 🚦 the minimum announcement periodicity is one announcement per second, and the default value SHOULD be set to 120 seconds 💜

Implementations SHOULD NOT permit the inter-update timer to be lower than the measurement interval 🙅‍♀️

Furthermore, it is RECOMMENDED that any underlying performance-measurement mechanisms not include any significant buffer delay, any significant buffer-induced delay variation, or any significant loss due to buffer overflow or due to active queue management 🍓 basically keep the buffers chill

8. Enabling and Disabling Sub-TLVs 🔥

Implementations MUST make it possible to individually enable or disable each sub-TLV based on configuration 🎛️ main character control, iykyk

9. Static Metric Override 👑

Implementations SHOULD permit static configuration and/or manual override of dynamic measurements for each sub-TLV 🧚 this makes migration easier and helps in situations where dynamic measurements just aren't possible 🌸

10. Compatibility 🦋

As per [RFC5305], unrecognized sub-TLVs should be silently ignored 🙈 no drama, just vibes

11. Security Considerations 🚨

Okay, this section is serious, so read it carefully 💀

The sub-TLVs introduced in this document let an operator advertise link state information (bandwidth, delay) that could be sensitive and that the operator might not want to disclose 🔒

Section 7 describes a mechanism to ensure network stability when the new sub-TLVs defined in this document are advertised 🧱 Implementations SHOULD follow the described guidelines to mitigate the risk of instability 🫶

[RFC5304] describes an authentication method for IS-IS Link State PDUs that allows cryptographic authentication of IS-IS Link State PDUs 🔐

It is anticipated that in most deployments, the IS-IS protocol is used within an infrastructure entirely under the control of the same operator 🏠 However, it's worth considering that sending IS-IS Traffic Engineering sub-TLVs over insecure links could let a man-in-the-middle attacker delay real-time data to a given site or destination 😱 That could hurt the value of the data for that site or destination. The use of Link State PDU cryptographic authentication helps mitigate the risk of man-in-the-middle attacks 🛡️

12. IANA Considerations 📋

IANA maintains the registry for the sub-TLVs 💅 IANA has registered the following sub-TLVs in the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry:

   Type    Description
   ----------------------------------------------------
    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

13. References 📚

13.1. Normative References

13.2. Informative References

Appendix A. Changes from RFC 7810 💅

Okay so, errata ID 5293 (https://www.rfc-editor.org/errata/eid5293) caught a real mess in [RFC7810]. The length listed for these three sub-TLVs didn't match the figures, which showed a RESERVED field 🙈:

   37    Unidirectional Residual Bandwidth

   38    Unidirectional Available Bandwidth

   39    Unidirectional Utilized Bandwidth

The spec said the length was 4, but that didn't include the RESERVED field in the figures. Then it got worse. Some implementations used length 4 and left RESERVED out, while others kept RESERVED and used length 5. Bestie, those two choices are NOT interoperable 💀, so a bis version was needed to clear it up.

The fix here is to drop the unused RESERVED field from these sub-TLVs and use length 4. This lines up with the matching advertisements in the OSPF TE spec [RFC7471] and the BGP - Link State (BGP-LS) spec [RFC8571]. ✨ There were also some minor editorial fixes.

Errata ID 5486 (https://www.rfc-editor.org/errata/eid5486) pointed out a circular definition in Section 4.6 of [RFC7810]. Available bandwidth on bundled links was defined as "sum of the component link available bandwidths", which is literally the thing being defined 😭. It should have said "sum of the component link residual bandwidths". That's fixed and clarified now. 🔥

Acknowledgements 🫶

In [RFC7810], the authors gave a shoutout to Ayman Soliman, Nabil Bitar, David McDysan, Edward Crabbe, Don Fedyk, Hannes Gredler, Uma Chunduri, Alvaro Retana, Brian Weis, and Barry Leiba for their contributions and reviews of this document. Iconic squad 👑

The authors also gave credit to Curtis Villamizar for significant comments and direct content collaboration. 🎀

For this document, the authors thank Jeff Haas for spotting and reporting the incorrect encoding of the bandwidth-related sub-TLVs. He's the reason the length mess got fixed 🦋

Contributors 🌸

The following people contributed substantially to the content of this document and should be considered coauthors. They absolutely earned it 💜

   Alia Atlas
   Juniper Networks
   United States of America
   Email: akatlas@juniper.net

   Clarence Filsfils
   Cisco Systems, Inc.
   Belgium
   Email: cfilsfil@cisco.com

Authors' Addresses 🦋

Here's who wrote this thing, with contact details, so you can slide into their inbox if you have questions 🧚

   Les Ginsberg (editor)
   Cisco Systems, Inc.

   Email: ginsberg@cisco.com


   Stefano Previdi (editor)
   Huawei

   Email: stefano@previdi.net


   Spencer Giacalone
   Microsoft

   Email: spencer.giacalone@gmail.com


   Dave Ward
   Cisco Systems, Inc.

   Email: wardd@cisco.com


   John Drake
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   United States of America

   Email: jdrake@juniper.net


   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com
📦 where this page comes from