RFC 7810

IS-IS Traffic Engineering (TE) Metric Extensions

📅 published May 2016, from ietf

Abstract 📖

Okay bestie, the abstract is giving "this matters a LOT in finance" 💰. In certain networks, like financial information networks (think stock market data providers 📈), network-performance criteria such as latency are becoming just as critical to picking a data path as every other metric 🔥.

This doc extends IS-IS Traffic Engineering Extensions ([RFC5305]) so network-performance info can be spread around and collected in a scalable way ✨. That info can then be used to make path-selection choices based on performance 🦋.

Also, this doc ONLY covers how the performance info gets distributed 💅. How you measure performance, or what you do with the info once it's shared, is outside the scope here 🙈.

Status of This Memo 🎀

This is an Internet Standards Track document 👑.

This is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶. More info on Internet Standards is in Section 2 of RFC 5741 🌸.

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7810 🔗.

Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) as in effect on the date of publication. Read these carefully, because they spell out your rights and restrictions for this doc 📜. Code Components extracted 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Conventions Used in This Document . . . . . . . . . . . .   4
2.  TE Metric Extensions to IS-IS . . . . . . . . . . . . . . . .   4
3.  Interface and Neighbor Addresses  . . . . . . . . . . . . . .   5
4.  Sub-TLV Details . . . . . . . . . . . . . . . . . . . . . . .   6
  4.1.  Unidirectional Link Delay Sub-TLV . . . . . . . . . . . .   6
  4.2.  Min/Max Unidirectional Link Delay Sub-TLV . . . . . . . .   7
  4.3.  Unidirectional Delay Variation Sub-TLV  . . . . . . . . .   8
  4.4.  Unidirectional Link Loss Sub-TLV  . . . . . . . . . . . .   9
  4.5.  Unidirectional Residual Bandwidth Sub-TLV . . . . . . . .  10
  4.6.  Unidirectional Available Bandwidth Sub-TLV  . . . . . . .  11
  4.7.  Unidirectional Utilized Bandwidth Sub-TLV . . . . . . . .  12
5.  Announcement Thresholds and Filters . . . . . . . . . . . . .  12
6.  Announcement Suppression  . . . . . . . . . . . . . . . . . .  13
7.  Network Stability and Announcement Periodicity  . . . . . . .  14
8.  Enabling and Disabling Sub-TLVs . . . . . . . . . . . . . . .  14
9.  Static Metric Override  . . . . . . . . . . . . . . . . . . .  14
10. Compatibility . . . . . . . . . . . . . . . . . . . . . . . .  14
11. Security Considerations . . . . . . . . . . . . . . . . . . .  15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
  13.1.  Normative References . . . . . . . . . . . . . . . . . .  16
  13.2.  Informative References . . . . . . . . . . . . . . . . .  16
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1. Introduction ✨

Okay so, in certain networks (financial information networks like stock market data providers, for example 💸), network-performance info like latency is becoming just as critical to choosing a data path as the other metrics 🏃‍♀️.

In these networks, huge amounts of money depend on getting market data in "real time" and making trades predictably faster than everyone else 🤑. So using stuff like hop count or cost as routing metrics is becoming only tangentially important 🙄. It'd be way more beneficial to pick paths based on performance data, like latency, in a cost-effective and scalable way 💖.

This doc describes extensions (we're calling them "IS-IS TE Metric Extensions") to the IS-IS Extended Reachability TLV defined in [RFC5305] 🦋. They can be used to 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 protocol operation (for example, swapping cost for latency, or considering bandwidth as well as cost) 🔄. It can also enhance Constrained-SPF (CSPF), or supplement the data used by an ALTO server [RFC7285] 🌈. For CSPF specifically, the distributed data can help set up, fail over, and fail back data paths using protocols like RSVP-TE [RFC3209] 🛤️.

Heads up 🚨: these mechanisms only spread performance info around. Gathering that info in the first place (as described in [RFC6375]) or acting on it once it's distributed is outside the scope of this doc 🙈. Example mechanisms for measuring latency, delay variation, and loss in an MPLS network are in [RFC6374] 🧪.

This doc doesn't specify how the performance info should be obtained, BUT the measurement of delay SHOULD NOT vary significantly based on the offered traffic load 📉. So queuing delays SHOULD NOT be included in the delay measurement 🚫. For links like Forwarding Adjacencies, you've gotta be careful that measuring the associated delay avoids significant queuing delay 👀. You can do that a few ways: measure with a traffic class that sees minimal queuing, or sum the measured link delays of the components of the link's path 💅.

1.1. Conventions Used in This Document 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🎀.

In this doc, these words only carry that meaning when they appear in ALL CAPS 🔠. Lowercase uses of these words do NOT carry the significance described in RFC 2119 💀.

2. TE Metric Extensions to IS-IS 🌸

This doc registers new IS-IS TE sub-TLVs that can be announced in the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry, so network-performance info can be distributed 📬. These extensions build on the ones in IS-IS TE [RFC5305] and GMPLS [RFC4203] 🧱.

IS-IS Extended Reachability TLV 22 (defined in [RFC5305]), Inter-AS Reachability Information TLV 141 (defined in [RFC5316]), and MT-ISIS TLV 222 (defined in [RFC5120]) have nested sub-TLVs, which makes them easy to extend 🪆. This doc registers several 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, the sub-TLVs here carry different types of network-performance info 📊. The new sub-TLVs include a bit called the Anomalous (or "A") bit 🚩. When the A bit is clear (or when the sub-TLV doesn't have an A bit at all), the sub-TLV describes steady-state link performance 😌. That info could conceivably be used to build a steady-state performance topology for initial tunnel-path computation, or to verify alternative failover paths 🗺️.

When network performance violates configurable link-local thresholds, a sub-TLV with the A bit set gets advertised 🚨. The receiving node could use these to decide whether to fail traffic over to a backup path, or whether to calculate an entirely new path 🔀. From an MPLS perspective, the point of the A bit is to let label switched path ingress nodes check whether the link in the sub-TLV affects any of the label switched paths they're ingress for 🔍. If they're affected, they can see whether those paths still meet end-to-end performance objectives 🎯. If not, the node could conceivably move the affected traffic to a pre-established protection label switched path, or set up a new label switched path and put the traffic on it 🦸‍♀️.

If link performance then improves past a configurable minimum value (the reuse threshold), that sub-TLV can be re-advertised with the A bit cleared 📈. In that case, a receiving node can conceivably do whatever re-optimization (or failback) it wants, including nothing 🤷‍♀️.

Note that when a sub-TLV does NOT include the A bit, that sub-TLV can't be used for failover purposes 🙅‍♀️. The A bit was intentionally left out of some sub-TLVs to help mitigate oscillations 🌊. Check out Section 5 for more info 👀.

Consistent with the existing IS-IS TE specification [RFC5305], the bandwidth advertisements in this document MUST be encoded as IEEE floating-point values 🔢. The delay and delay-variation advertisements MUST be encoded as integer values 🔟. Delay values MUST be quantified in units of 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 info 💜.

3. Interface and Neighbor Addresses 🦋

okay so, IS-IS TE Metric Extensions sub-TLVs are not just for the TE crowd 💅 you can totally use the ones defined in this doc to compute paths even if there's no TE subsystem around. no cap, that's a super useful flex 🌸

BUT (and this is a big but 😭) when it's the TE case, the Interface Address and Neighbor Address sub-TLVs (IPv4 or IPv6) MUST be present 🫶 the encoding for IPv4 lives in [RFC5305] and the encoding for IPv6 lives in [RFC6119]. no skipping these, bestie!

4. Sub-TLV Details ✨

okay this is the juicy part 🍓 every sub-TLV below gets its own little diagram, and the field-by-field breakdown is right under it.

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

here's what each piece means:

  • Type: 33
  • Length: 4
  • A bit: this is the Anomalous (A) bit 🚨 it gets set when the measured value goes over its configured maximum threshold, and it gets cleared once the measured value drops below its configured reuse threshold. when the A bit is clear, the sub-TLV is showing steady-state link performance 🧚
  • RESERVED: reserved for future use 🎀 it MUST be set to 0 when sent, and it MUST be ignored when received.
  • Delay: a 24-bit field with the average link delay over a configurable interval, in microseconds, as an integer 💜 if it hits the max value of 16,777,215 (that's 16.777215 sec), the delay is at least that much and could be even bigger 😭

this one tells you the minimum and maximum delay values between two directly connected IS-IS neighbors ⚡ same rule as before: the delay it advertises MUST be the delay from the local neighbor to the remote one (the forward-path latency) 🌸

    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

the breakdown:

  • Type: 34
  • Length: 8
  • A bit: the Anomalous (A) bit 🚨 it's set when one or more measured values go over a configured maximum threshold, and cleared when the measured value falls below its configured reuse threshold. A clear A bit means steady-state link performance 💖
  • RESERVED: reserved for future use 🎀 it MUST be set to 0 when sent, and it 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 💜

extra bonus 🎁 implementations MAY also let you configure an offset value (in microseconds) that gets added to the measured delay, so you can communicate operator-specific delay constraints 🧁

also, the Min and Max can totally be the same value ✨ and if either one (Min or Max) hits the max value of 16,777,215 (16.777215 sec), 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 delay variation it advertises MUST be the delay from the local neighbor to the remote one (the forward-path latency) 🫶

    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

the details:

  • Type: 35
  • Length: 4
  • RESERVED: reserved for future use 🎀 it MUST be set to 0 when sent, and it 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 💜 a value of 0 means it hasn't been measured 👀 and if it hits the max value of 16,777,215 (16.777215 sec), the delay is at least that much and could 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 one (the forward-path loss) 🫶

    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

the breakdown:

  • Type: 36
  • Length: 4
  • A bit: the Anomalous (A) bit 🚨 set when the measured value goes over its configured maximum threshold, cleared when it drops below its configured reuse threshold. A clear A bit means steady-state link performance 💖
  • RESERVED: reserved for future use 🎀 it MUST be set to 0 when sent, and it MUST be ignored when received.
  • Link Loss: a 24-bit field with link packet loss as a percentage of the total traffic sent over a configurable interval 🌊 the basic unit is 0.000003%, and (2^24 - 2) is 50.331642%. That's the highest packet-loss percentage this field can express. The thinking here is that precision matters more on high-speed links than being able to advertise loss rates above that number, and high-speed links with over 50% loss are basically unusable 🙈 So measured values bigger 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.

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

the breakdown:

  • Type: 37
  • Length: 4
  • RESERVED: reserved for future use 🎀 it MUST be set to 0 when sent, and it MUST be ignored when received.
  • Residual Bandwidth: this carries the residual bandwidth on a link, a forwarding adjacency [RFC4206], or a bundled link, 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 vibe check on residual vs. unreserved bandwidth 🧠 these two are NOT the same thing, bestie!! Residual bandwidth subtracts tunnel reservations from the maximum bandwidth (aka the link capacity) [RFC5305] and gives you one aggregated remainder across priorities 🌈 Unreserved bandwidth is subtracted from the maximum reservable bandwidth (the amount that could theoretically be reserved) and gives you per-priority remainders instead 🎯 Residual bandwidth and unreserved bandwidth [RFC5305] can be used at the same time, and each one has its own use case. For example, residual bandwidth can power things like Weighted ECMP, while unreserved bandwidth is great 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 that originates this sub-TLV 💖 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    |  RESERVED     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Available Bandwidth                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5

the details:

  • Type: 38
  • Length: 4
  • RESERVED: reserved for future use 🎀 it MUST be set to 0 when sent, and it MUST be ignored when received.
  • Available Bandwidth: this carries the available bandwidth on a link, a forwarding adjacency, or a bundled link, 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 actually forwarding non-RSVP-TE label switched path packets. For a bundled link, it's defined as the sum of the component link available bandwidths minus that same measured bandwidth used for forwarding non-RSVP-TE label switched path packets. Then, for a bundled link, the definition gets restated as just the sum of the component link available bandwidths 🧁

4.7. Unidirectional Utilized Bandwidth Sub-TLV ✨

okay so this one is the bandwidth utilization sub-TLV 🦋 it tells your bestie how much bandwidth is actually being used between two directly connected IS-IS neighbors. and the number you advertise MUST be the bandwidth coming from the system that's originating this sub-TLV 💅 no cap, that detail is the whole point!!

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    |  RESERVED     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Utilized Bandwidth                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 6

and here's what each field is doing 🧚

  • Type: it's 39 🎀
  • Length: it's 4 🌸
  • RESERVED: this one's saved for future use 🫶 when you send it you MUST set it to 0, and when you receive it you MUST ignore it. no drama, just zeros!
  • Utilized Bandwidth: this is the juicy part 🔥 it carries the bandwidth utilization on a link, a forwarding adjacency, or a bundled link, in IEEE floating-point format, with units of bytes per second. for a link or a forwarding adjacency, it's the actual utilization of the link, measured by the node doing the advertising. for a bundled link, it's defined as the sum of the component link bandwidth utilizations. it's giving math bestie energy 🧮💜

5. Announcement Thresholds and Filters 🌈

okay bestie, let's talk about when you're allowed to shout your numbers 📣 the values in all the sub-TLVs (except min/max delay and residual bandwidth) MUST represent an average over a period, or be obtained by a filter that's reasonably representative of an average. a rolling average is one example of that filter 🦋 so no raw spiky numbers allowed, periodt 💅

min and max delay have their own rules 🎀 each one MUST 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 that gives a reasonable min and max representing the interval, with compensation for outliers. the outliers get filtered out so they don't make your whole vibe look chaotic 🙈

the measurement interval, any filter coefficients, and any advertisement intervals MUST be configurable per sub-TLV ⭐ every sub-TLV gets its own settings, no one-size-fits-all energy here.

in addition to the measurement intervals that govern re-advertisement, implementations SHOULD provide configurable accelerated advertisement thresholds per sub-TLV 🔥 here's how it's supposed to go:

  1. if the measured parameter falls outside a configured upper bound for all but the minimum delay metric (or outside a lower bound, for the minimum delay metric only), 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. ⚡ no waiting, bestie!
  4. for sub-TLVs that include an A bit, an additional threshold SHOULD be included corresponding to the threshold for which the performance is considered 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 an advertisement interval(s), so things can fail back 🌸 it's the glow-up arc.

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. pick a lane, bestie!

and finally, once you're outside the bounds of the threshold, any re-advertisement of a measurement that's back within the bounds would remain governed solely by the measurement interval for that sub-TLV 🧚 so the interval is the boss again.

6. Announcement Suppression 🙈

okay so sometimes the link numbers wiggle by tiny amounts that don't even cross the thresholds 🫠 when that happens, implementations SHOULD suppress the sub-TLV re-advertisement and/or lengthen the period between refreshes. quiet is the new loud 🤫🌸

only the accelerated advertisement threshold mechanism from Section 5 is allowed to shorten the re-advertisement interval 💅 that's the one exception to the chill rule. and all of the suppression and re-advertisement interval backoff timer features SHOULD be configurable ⭐ so you get to tune the drama level yourself.

7. Network Stability and Announcement Periodicity 🦋

okay this section is the "don't break the internet" section 😭 sections 5 and 6 give you configurable mechanisms to bound how many re-advertisements happen. but instability could show up 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 you set these values, bestie 🫶

also, 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 1 announcement per second, and the default value SHOULD be set to 120 seconds. so you don't spam everyone every single second, obviously 😭

implementations SHOULD NOT permit the inter-update timer to be lower than the measurement interval 🙅‍♀️ keep that timer respectable!

and 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. the goal is measurements that aren't secretly lying to you because of a clogged queue 🧚

8. Enabling and Disabling Sub-TLVs 🔥

implementations MUST make it possible to individually enable or disable each sub-TLV based on configuration 🎛️ you're in charge of your own menu, bestie. no forced sub-TLV buffet 🍓

9. Static Metric Override ✨

implementations SHOULD permit static configuration and/or manual override of dynamic measurements for each sub-TLV 👑 the reason is to simplify migration and to cover scenarios where dynamic measurements just aren't possible. it's the emergency mode that saves the day 🦸‍♀️

10. Compatibility 🌸

as per [RFC5305], unrecognized sub-TLVs should be silently ignored 🤫 so if you don't recognize something, just let it slide, no drama, no crashing the vibe.

11. Security Considerations 💀

okay this section is serious business, so I'm going to keep my energy in check (mostly) 😭🫶

the sub-TLVs introduced in this document let an operator advertise state information about links, like bandwidth and delay. that info could be sensitive, and an operator may not want to disclose it, so keep that in mind 🔒

section 7 describes a mechanism to keep the network stable when the new sub-TLVs defined in this document are advertised. implementations SHOULD follow the described guidelines to reduce the instability risk 💖

[RFC5304] describes an authentication method for IS-IS Link State PDUs. it lets you do cryptographic authentication of those PDUs, which is a whole glow-up for security 🔐

now, here's the tea ☕ in most deployments, the IS-IS protocol runs entirely inside an infrastructure controlled by the same operator. but it's still worth thinking about this: sending IS-IS Traffic Engineering sub-TLVs over insecure links could let a man-in-the-middle attacker delay real-time data headed to a given site or destination. that could hurt how valuable the data is for that site or destination 😱 yikes, bestie.

the good news is that using Link State PDU cryptographic authentication helps mitigate the risk of a man-in-the-middle attack 🛡️ main character defense energy!!

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 🦋

Acknowledgements 💜

the authors would like to recognize Ayman Soliman, Nabil Bitar, David McDysan, Les Ginsberg, Edward Crabbe, Don Fedyk, Hannes Gredler, Uma Chunduri, Alvaro Retana, Brian Weis, and Barry Leiba for their contribution and review of this document 🫶

the authors also recognize Curtis Villamizar for significant comments and direct content collaboration 🌟

Contributors 🌈

the following people contributed substantially to the content of this document and should be considered co-authors ✨

Alia Atlas
Juniper Networks
United States

Email: akatlas@juniper.net
Clarence Filsfils
Cisco Systems Inc.
Belgium

Email: cfilsfil@cisco.com

Authors' Addresses 🦋

Stefano Previdi (editor)
Cisco Systems, Inc.
Via Del Serafico 200
Rome  00191
Italy

Email: sprevidi@cisco.com
Spencer Giacalone
Microsoft

Email: spencer.giacalone@gmail.com
Dave Ward
Cisco Systems, Inc.
3700 Cisco Way
San Jose, CA  95134
United States

Email: wardd@cisco.com
John Drake
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
United States

Email: jdrake@juniper.net
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu  210012
China

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