RFC 7813
IS-IS Path Control and Reservation
RFC 7813: IS-IS Path Control and Reservation 💖
okay bestie, let's get into it ✨ This one was written by a whole squad: J. Farkas (editor 👑), N. Bragg, P. Unbehagen, G. Parsons, P. Ashwood-Smith, and C. Bowers, from Ericsson, Ciena, Avaya, Huawei Technologies, and Juniper Networks. It's a Standards Track document, published in June 2016 🎀, and it's the ISSN 2070-1721 one 🦋 It doesn't obsolete or update any earlier RFCs, so it's a fresh start, no drama 💅
Here's the vibe: IEEE 802.1Qca Path Control and Reservation (PCR) lets you do explicit path control over IS-IS in Layer 2 networks, so you can go beyond the shortest-path stuff that IEEE 802.1aq Shortest Path Bridging (SPB) gives you 🧚 This document is the part that defines the sub-TLVs for IS-IS PCR. Iconic 🔥
Status of This Memo ✨
This is an Internet Standards Track document. It came out of the IETF, it represents the consensus of the IETF community, it got public review, and the IESG approved it for publication. If you want more on Internet Standards, check Section 2 of RFC 7841 🌸
Want the current status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc7813 💜
Copyright Notice ✨
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 they stood on the publication date. Read those carefully, bestie, because they spell out your rights and restrictions. Any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 💅
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
4. Explicit Trees . . . . . . . . . . . . . . . . . . . . . . . 6
5. Explicit ECT Algorithms . . . . . . . . . . . . . . . . . . . 9
6. IS-IS PCR Sub-TLVs . . . . . . . . . . . . . . . . . . . . . 11
6.1. Topology Sub-TLV . . . . . . . . . . . . . . . . . . . . 11
6.2. Hop Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Bandwidth Constraint Sub-TLV . . . . . . . . . . . . . . 19
6.4. Bandwidth Assignment Sub-TLV . . . . . . . . . . . . . . 21
6.5. Timestamp Sub-TLV . . . . . . . . . . . . . . . . . . . . 23
7. MRT-FRR Application . . . . . . . . . . . . . . . . . . . . . 24
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . 31
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 321. Introduction 🌈
okay so IEEE 802.1Qca Path Control and Reservation (PCR) [IEEE8021Qca] adds IS-IS extensions for controlling Explicit Trees (ETs) 🦋 PCR plays nicely with the Shortest Path Bridging (SPB) extensions to IS-IS from [RFC6329] and [IEEE8021aq] (which are already rolled into [IEEE8021Q]) 💜 IS-IS with PCR leans on the SPB architecture and terminology, and it reuses some of the IS-IS SPB sub-TLVs too ✨ So PCR builds on IS-IS and uses it in a similar way to SPB 🎀 One thing to note: IS-IS PCR only deals with point-to-point physical links, even though IS-IS also supports shared media LANs 👀
This document specifies five IS-IS sub-TLVs for controlling explicit trees with IS-IS PCR in a Layer 2 network, as laid out by IEEE Std 802.1Qca 💅 Besides the ones defined here, IS-IS PCR also relies on these IS-IS SPB sub-TLVs from [RFC6329]:
- SPB Link Metric sub-TLV 🍓
- SPB Base VLAN-Identifiers sub-TLV 🍓
- SPB Instance sub-TLV 🍓
- SPBV MAC address sub-TLV 🍓
- SPBM Service Identifier and Unicast Address sub-TLV 🍓
These sub-TLVs supply the link metric and the links between bridges, Media Access Control (MAC) addresses, VLAN IDs (VIDs), and I-SIDs inside an IS-IS domain 🌸 How PCR uses them is specified by IEEE Std 802.1Qca. Heads up, though: IS-IS PCR doesn't need the full IS-IS SPB protocol, it only needs support for these SPB sub-TLVs 🙈 A bridge can run IS-IS SPB and IS-IS PCR at the same time. When it does, one IS-IS entity handles both, on a per-instance basis 🧚
The sub-TLVs in this document can also be used for Fast Reroute with Maximally Redundant Trees (MRT-FRR) [RFC7812] in a Layer 2 network 🔥 Maximally Redundant Trees (MRTs) get computed as described in [RFC7811]. If the MRT computation is split so the Generalized Almost Directed Acyclic Graph (GADAG) is computed centrally, then these sub-TLVs can distribute the GADAG, which is the same for every network node across a network domain 👑
Last bit: PCR uses IS-IS, the SPB sub-TLVs above, and the new sub-TLVs defined here. IS-IS PCR has no impact on IETF protocols 💖
2. Conventions Used in This Document 💅
Okay, the key words here are the ones you'll see in capitals all over this doc: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". They're to be interpreted as described in [RFC2119] 🎀
3. Terminology and Definitions 🦋
This document uses the terminology from [RFC7812]. For the MRT terms, only the abbreviations get resolved here, so check [RFC7812] for the full definitions 🌸
ADAG: Almost Directed Acyclic Graph [RFC7812] 🧚
B-VID: Backbone VID [IEEE8021Q] 🧚
Base VID: The VID used to identify a VLAN in management operations. [IEEE8021Q] 🧚
BLCE: Bridge Local Computation Engine. This is a computation engine in a bridge that does path and routing computations. The BLCE implements e.g., SPF, CSPF, or the Maximally Redundant Trees algorithm. [IEEE8021Qca] 💜
Constrained tree: A tree that meets a certain constraint, e.g., providing minimally available bandwidth. [IEEE8021Qca] 💜
CSPF: Constrained Shortest Path First 🧚
DAG: Directed Acyclic Graph [RFC7812] 🧚
DEI: Drop Eligible Indicator [IEEE8021Q] 🧚
ECT Algorithm: Equal-Cost Tree algorithm. This is the algorithm and mechanism used to control the active topology, i.e., forwarding trees. It can be one of the shortest path algorithms specified by [IEEE8021Q]. It can also be one of the explicit path-control algorithms specified by [IEEE8021Qca]. Each ECT Algorithm has a 32-bit unique ID. 🔥
ET: Explicit Tree. This is an explicitly defined tree, specified by its Edge Bridges and the paths among those Edge Bridges. If only the Edge Bridges are specified but the paths are not, it's a loose explicit tree. If the paths are also specified, it's a strict explicit tree. [IEEE8021Qca] 👑
ETDB: Explicit Tree Database. A database storing explicit trees. [IEEE8021Qca] 🧚
FDB: Filtering Database [IEEE8021Q] 🧚
GADAG: Generalized ADAG [RFC7812] 🧚
Hop: A hop is specified by two nodes. A strict hop has no intermediate nodes, whereas a loose hop can have one or more intermediate nodes. IS-IS PCR specifies an explicit tree by an ordered list of hops starting at the root, with each successive hop defined by the next element of the list. [IEEE8021Qca] 🌈
I-SID: Backbone Service Instance Identifier. This is a 24-bit ID. [IEEE8021Q] 🧚
LSDB: Link State Database 🧚
MRT: Maximally Redundant Trees [RFC7812] 🧚
MRT-Blue: MRT-Blue is used to describe one of the two MRTs. [RFC7812] 🧚
MRT-Red: MRT-Red is used to describe one of the two MRTs. [RFC7812] 🧚
MRT Root: The common root of the two MRTs: MRT-Blue and MRT-Red. 🧚
MSRP: Multiple Stream Registration Protocol, standardized as IEEE Std 802.1Qat, already rolled into [IEEE8021Q]. 🧚
PCA: Path Control Agent. This is the agent that's part of the IS-IS domain and can therefore perform IS-IS operations on behalf of a PCE, e.g., maintain the LSDB and send LSPs. [IEEE8021Qca] 💜
PCE: Path Computation Element. An entity that can compute a path through a network based on a representation of the network's topology (obtained by undefined means external to the PCE). [RFC4655] 💜
PCP: Priority Code Point, which identifies a traffic class. [IEEE8021Q] 🧚
PTP: Precision Time Protocol, specified by [IEEE1588]. 🧚
SPB: Shortest Path Bridging 🧚
SPBM: SPB MAC. The SPB mode where a MAC or its shorthand (SPSourceID: Shortest Path Source ID) is used to identify an SPT. [IEEE8021Q] 🧚
SPBV: SPB VID. The SPB mode where a unique VID is assigned to each SPT Root bridge and is used to identify an SPT. [IEEE8021Q] 🧚
SPF: Shortest Path First 🧚
SPT: Shortest Path Tree [IEEE8021Q] 🧚
SRLG: Shared Risk Link Group. A set of links that share a resource whose failure affects each link. [RFC5307] 🧚
TAI: Temps Atomique International, International Atomic Time [IEEE1588] 🧚
TED: Traffic Engineering Database. A database storing the traffic engineering information propagated by IS-IS. [RFC5305] 🧚
VID: VLAN ID [IEEE8021Q] 🧚
VLAN: Virtual Local Area Network [IEEE8021Q] 🧚
Part 1 of 8. More parts coming, so stay tuned, bestie 💖🎀
Okay so, this part picks up right in the middle of Section 4, "Explicit Trees," and it's where things get really juicy 🦋 Let me break it down for you bestie 💅
4. Explicit Trees ✨
Okay so explicit trees can be figured out in a bunch of different ways 🌸 One example is a Path Computation Element (PCE) [RFC4655]. A PCE is basically an entity that can compute a forwarding topology from the network topology, its attributes, and any constraints it's given 🧚 If you use a PCE, it MUST explicitly specify an explicit tree like we'll see in Section 6.1 💖 Either one PCE or several PCEs can figure out explicit trees for a domain. But even when there are multiple PCEs, each explicit tree MUST only get determined by one PCE, and that one is called the owner PCE of the tree 👑 PCEs and IS-IS PCR can team up with IS-IS SPB shortest path routing 🫶 The rest of this section and the sections after it are written assuming a PCE is being used, so keep that in mind 🎀
The PCE talks to the active topology control protocol, which is IS-IS 💜 That collaboration can be handled by a Path Control Agent (PCA) acting on the PCE's behalf. Either the PCE or its PCA has to be part of the IS-IS domain 🦋 If the PCE isn't part of the IS-IS domain, then the PCE MUST be linked to a PCA that is part of it 😭 The PCE or its PCA MUST establish an IS-IS adjacency so it can receive all the LSPs sent by the bridges in the domain 🔥 The PCE can control how explicit trees get set up in that domain, either on its own or through its PCA. It does this by injecting an LSP that carries an explicit tree, which tells IS-IS to build the tree the PCE figured out 🌈 If a PCE tells it to, IS-IS MAY also record and communicate bandwidth assignments. Those MUST NOT be applied if a reservation protocol like the Multiple Stream Registration Protocol (MSRP) is being used in the domain 💀 And both MSRP and IS-IS MUST NOT be used to make bandwidth assignments in the same domain 🙈
Heads up: the operation details of the PCE aren't specified in this document or in IEEE Std 802.1Qca, so these things are left open on purpose 🍓
Now, if the PCE is part of the IS-IS domain, it uses IS-IS PDUs to talk to the domain and it keeps a live IS-IS LSDB (so the PCE is doing the PCA jobs too) ✨ A PCE can also talk to the IS-IS domain through a PCA instead, for example to pull the LSDB or ask for an explicit tree to be created 💅 Just know that how the PCE and the PCA communicate is also not specified by this document or by IEEE Std 802.1Qca 🫶
An Explicit Tree (ET) is an undirected, loop-free topology 🦋 Its use is controlled by the owner PCE, which associates VIDs and MAC addresses with it 💖 An ET MUST NOT contain cycles 😭 Because it's undirected, an ET makes no assumptions about which way flows go. It can be used in either direction, depending on the VIDs and MAC addresses attached to it 🧚 The PCE is responsible for making sure reverse-path congruency and multicast-unicast congruency hold, if that's required 👑
An explicit tree is either strict or loose 💜 A strict explicit tree spells out every bridge and every path it includes 🎀 A loose tree only lists the bridges as hops with a special role in the tree (like an Edge Bridge), and no path or path segment is given between them. That's why loose hops stay loose even when two Edge Bridges are right next to each other neighbors 🌸 The special role of a hop can be one of these: Edge Bridge, root, leaf, a bridge to be avoided, or a transit hop when the tree only has one leaf 🔥 The path for a loose hop gets worked out by the Bridge Local Computation Engine (BLCE) on the bridges. The shortest path is used for a loose hop unless the tree descriptor (Section 6.1) or the matching ECT Algorithm (Section 5) says otherwise 🍓
A loose explicit tree is constrained if its tree descriptor has one or more constraints, like the administrative group the tree's links have to belong to 💅 Then the BLCE applies the Constrained Shortest Path First (CSPF) algorithm, which is basically Shortest Path First (SPF) run only on the topology containing links that meet the constraint(s) 🦋
An explicit tree is described by a Topology sub-TLV (Section 6.1) 🌈 That sub-TLV associates one or more VIDs with the tree. It includes two or more Hop sub-TLVs (Section 6.2), and each hop is identified by an IS-IS System ID 💖 A Hop sub-TLV MAY include a delay constraint for a loose hop. A Topology sub-TLV MAY also include more sub-TLVs to constrain loose hops 🧚 The bridges involved in a tree store their Topology sub-TLVs in their Explicit Tree Database (ETDB) 💜
Explicit trees get propagated and set up by IS-IS PCR across the domain 🫶 The PCE or its PCA puts together the Topology sub-TLVs (Section 6.1) and adds them into an LSP, which gets flooded through the whole domain 🔥 The Topology sub-TLV is flooded using the same techniques as the SPB LSPs 👑 The bridges then MUST process the Topology sub-TLV when they receive it 😭 If the Topology sub-TLV specifies one or more loose trees, the BLCE on the bridges works out the path for the loose hops 🎀 After that, the bridges install the right FDB entries so frames get forwarded along the tree described by the Topology sub-TLV (or the trees computed from it) ✨ Dynamic Filtering Entries are maintained by IS-IS for the [VID, MAC address] two-tuples associated with an ET 💅
Because IS-IS LSPs age out, Topology sub-TLVs (Section 6.1) have to be refreshed just like other IS-IS TLVs, so the integrity of the LSDB is kept 🌸 The matching Dynamic Filtering Entries get refreshed in the FDB whenever a Topology sub-TLV is refreshed 🦋 Refreshing Topology sub-TLVs is the job of whichever entity is part of the IS-IS domain, meaning either the PCE or the PCA 🫶
The owner PCE can withdraw an explicit tree by sending an updated LSP that leaves out the Topology sub-TLV (Section 6.1) 💖 If a Topology sub-TLV gets removed from an LSP (or changed) so that the previous one is no longer in the LSDB (or has changed), then that previous Topology sub-TLV is implicitly withdrawn 😭 IS-IS PCR then removes the explicit tree (or updates it) 💜
There's no precedence order between explicit trees 🧚 The precedence order among bandwidth assignments recorded by IS-IS PCR is specified in Section 6.4 🔥
If an explicit tree can't be installed, for example because its constraint(s) can't be met or the Topology sub-TLV is ill-formed, then no tree gets installed, but a management report is generated 💀
The bridges MAY support the following IS-IS features when computing explicit trees 🌈 The Extended IS Reachability TLV (type 22) specified in [RFC5305] provides these link attribute IS-IS sub-TLVs:
- Administrative Group (color) (sub-TLV type 3),
- Maximum Link Bandwidth (sub-TLV type 9),
- Maximum Reservable Link Bandwidth (sub-TLV type 10),
- Unreserved Bandwidth (sub-TLV type 11),
- TE Default Metric (sub-TLV type 18).
When the Unreserved Bandwidth sub-TLV is used in a Layer 2 bridge network, the priority value it encodes gives the PCP, which identifies a traffic class (not a setup priority level) 🦋
Further attributes come from the IS-IS TE Metric Extension link attribute sub-TLVs specified in [RFC7810]:
- Unidirectional Link Delay (sub-TLV type 33),
- Min/Max Unidirectional Link Delay (sub-TLV type 34),
- Unidirectional Delay Variation (sub-TLV type 35),
- Unidirectional Link Loss (sub-TLV type 36),
- Unidirectional Residual Bandwidth (sub-TLV type 37),
- Unidirectional Available Bandwidth (sub-TLV type 38),
- Unidirectional Utilized Bandwidth (sub-TLV type 39).
The Shared Risk Link Group (SRLG) information provided by the SRLG TLV (type 138) [RFC5307] MAY also be used 🫶 To show that the interface is unnumbered in this case, the corresponding flag takes the value 0 🍓 The Link Local Identifier is an Extended Local Circuit Identifier, and the Link Remote Identifier is a Neighbor Extended Local Circuit ID 🎀
5. Explicit ECT Algorithms ✨
okay so the exact IS-IS control mode MUST be picked for a VLAN by linking its Base VID to the right ECT Algorithm in the SPB Base VLAN-Identifiers sub-TLV [RFC6329], and the Base VID also has to be given to IS-IS control 💅 there are five distinct ECT Algorithms, one for each of the five explicit path control modes. The nitty-gritty of how the explicit ECT Algorithms work and get configured lives in IEEE Std 802.1Qca, so here's the highkey overview 🧚 an ECT Algorithm value is the IEEE 802.1 OUI (Organizationally Unique Identifier) 00-80-C2 stuck together with an index [RFC6329].
The Strict Tree (ST) ECT Algorithm MUST be used for a strict explicit tree 🔒 a strict ET is static, because the only one allowed to update it is the owner PCE 👑 if the topology changes, the owner PCE is the one who has to notice (say, by watching for changes in the LSDB) and update the strict trees when needed. so the owner PCE computes the new tree, builds its descriptor (Section 6.1), and then tells IS-IS PCR to install it 🎀 the value for the ST ECT Algorithm is 00-80-C2-17 ✨
The Loose Tree (LT) ECT Algorithm MAY also be supported 🌸 it's used for a single loose explicit tree. the path for the loose hops gets figured out by the BLCE of the bridges, so the Topology sub-TLV (Section 6.1) that specifies the tree MUST indicate which hop is the root of the tree 🫶 IS-IS keeps the loose hops maintained, which means they get restored after a topology change if a loop-free path exists. if the tree the BLCE computes visits the same bridge twice (meaning a loop or hairpin got created), that loop or hairpin MUST be pruned from the tree, even if it contains a hop the Topology sub-TLV asked for 💀 if you want a bridge left out entirely, you can say so with the Exclude flag of a Hop sub-TLV (Section 6.2), which is carried by the Topology sub-TLV specifying the tree 🙈 the LT ECT Algorithm values run from 00-80-C2-21 to 00-80-C2-30.
The Loose Tree Set (LTS) ECT Algorithm MAY also be supported 🦋 it's used when the Edge Bridges named in the Topology sub-TLV (Section 6.1) need connectivity, and that connectivity comes from a set of loose trees with one tree rooted at each Edge Bridge. the BLCE of the bridges computes these loose trees, and IS-IS keeps them maintained (restored on a topology change) 🔥 one possible constraint is avoiding certain bridges in these trees, specified with the Exclude flag (item c.6. in Section 6.2). more constraints can come from the Topology sub-TLV. the LT ECT Algorithm range I mean the LTS one here runs from 00-80-C2-31 to 00-80-C2-40 💜
The LT and LTS ECT Algorithms use the shortest paths after the topology gets pruned according to whatever constraint(s) apply, if any ✨ the shortest path tie-breaking from Section 12 of [RFC6329] gets applied (see also subclauses 28.5 - 28.8 of [IEEE8021aq]), and that's exactly why these algorithms come with ranges of values 🧚 for the LT ECT Algorithm, the indexes are 0x21...0x30, and ECT-MASK{index-0x20} gets applied to pull out the ECT-MASK of Section 12 of [RFC6329]. for the LTS ECT Algorithm, the indexes are 0x31...0x40, and ECT-MASK{index-0x30} gets applied to find the ECT-MASK for shortest path tie-breaking 🎀
The MRT ECT Algorithm MAY also be supported 🌈 it's for setting up and maintaining MRTs in a distributed way. the MRT Lowpoint algorithm from [RFC7811] MUST be used to compute MRTs 💅 that algorithm computes the GADAG first, then makes two MRTs for each MRT Root: MRT-Blue and MRT-Red. if you don't need every bridge being an MRT Root to provide that level of redundancy, the MRT Roots can be listed in a Topology sub-TLV (Section 6.1) instead 🦋 both the GADAG and the MRT computation steps happen in a distributed way, meaning each bridge does them. the value for the MRT ECT Algorithm is 00-80-C2-18 🍓
The MRT GADAG (MRTG) ECT Algorithm MAY also be supported 🧠 this one splits the computation into two parts. since the GADAG is identical for every MRT in a domain, one entity, the GADAG Computer, computes it. the GADAG then gets described in a Topology sub-TLV (Section 6.1), which is flooded through the domain 🌊 the bridges then compute the MRTs for the MRT Roots based on the GADAG they received. Section 7 has more on how the GADAG gets described 📖 the value for the MRTG ECT Algorithm is 00-80-C2-19 ✨
MRTs count as loose trees, because bridges are involved in both their computation and their restoration 🫶 so both the MRT and the MRTG ECT Algorithms give you a set of loose trees, which is two MRTs for each MRT Root.
The SPB Link Metric sub-TLV [RFC6329] specifies the metric of each link for IS-IS PCR whenever the LT, the LTS, the MRT, or the MRTG ECT Algorithm is in use 💖 if the SPB Link Metric values advertised from the two ends of an adjacency don't match, the maximum value MUST be used 🙈
6. IS-IS PCR Sub-TLVs 🎀
these are the sub-TLVs specified for IS-IS PCR 🌸 the Topology sub-TLV MUST be carried in an MT-Capability TLV, and all the rest of the sub-TLVs get carried inside the Topology sub-TLV 🫶
6.1. Topology Sub-TLV ✨
okay bestie, so an explicit tree MUST be described by the variable-length Topology sub-TLV 💖 A Generalized Almost Directed Acyclic Graph (GADAG) MAY be described by a Topology sub-TLV too, and Section 7 spills all the deets on that 🦋. The Topology sub-TLV MUST be carried in an MT-Capability TLV (type 144) [RFC6329] in a Link State PDU 🌸. A Topology sub-TLV that specifies an explicit tree conveys one or more Base VIDs and two or more Hop sub-TLVs (Section 6.2) 💅. A Topology sub-TLV describing a loose tree MAY also convey further sub-TLVs to specify constraints 🧚. Figure 1 shows the format, so peek at it below 👑
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 | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Num Base VIDs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Base VID 1 (12 bits) | (2 bytes if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Base VID n (12 bits) | (2 bytes if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV 1 (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV m (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Topology Sub-TLV
ok so here's how the parameters of explicit trees get packed into the Topology sub-TLV 🍓
a. Type (8 bits): The type of the sub-TLV. Its value is 21 🌈
b. Length (8 bits): The total number of bytes contained in the Value field 📏
c. Number of Base VIDs (8 bits): The number of Base VIDs carried in the Topology sub-TLV. Its minimum value is 1 if the Topology sub-TLV specifies one or more explicit trees. Its value can be 0 if the Topology sub-TLV specifies a GADAG 🧁
d. Reserved (Res) (4 bits): The reserved bits MUST be set to 0 on transmission and the value MUST be ignored on reception 🙈
e. Base VID (12 bits): The Base VID parameter provides the Base VID of the VLAN that is associated with the explicit tree. Multiple Base VIDs can be associated with the same explicit tree. In addition to the Base VID, some of the explicit ECT Algorithms (Section 5) require further VIDs that are associated with the VLAN via the SPB Instance sub-TLV [RFC6329]. A Topology sub-TLV specifying a GADAG can have zero Base VID parameters. In this case, the given GADAG MUST be applied for each VLAN associated with the MRTG ECT Algorithm (Section 5) 💜
f. sub-TLVs: The rest conveys further sub-TLVs that specify the hops of the topology and can also specify constraints as described in the following 🦋
A topology is specified by a list of Hop sub-TLVs (Section 6.2), and a hop is specified by an IS-IS System ID. An ill-formed Topology sub-TLV (e.g., specifying an invalid or inconsistent tree) is ignored. No tree is installed, but a management report is generated 🚨
The Topology sub-TLV specifies a strict tree by decomposing the tree into branches. Each branch is a point-to-point path specified by an ordered list of hops, where the end of each branch is a leaf. Each element of a branch is the direct link between adjacent neighbor bridges whose Hop sub-TLVs sit next to each other in the Topology sub-TLV. The first hop of the Topology sub-TLV is the root, so the first branch originates from the root. The rest of the branches fork from another branch. The first hop of a branch is a bridge that is already part of a former branch, and the last hop is a leaf bridge. Therefore, the hop after a leaf hop is the beginning of a new branch, if any. A hop of a branch is created if and only if the bridge specified for that hop is directly connected to the preceding bridge of the same branch. The first branch MUST begin with the root. After that, the order of the branches does not matter within the Topology sub-TLV. Figure 2 shows an example strict tree and its description 🌸
+-----------+
| A |
+-----------+
| I |
+-----------+
| H |
[B]---[A]---[I] +-----------+
| | | G |
| | +-----------+
| | | E |
[C]---[F] [H] +-----------+
| | | A |
| | +-----------+
| | | B |
[D] [E]---[G] +-----------+
| C |
+-----------+
| D |
+-----------+
| C |
+-----------+
| F |
+-----------+Figure 2: A Strict Tree and Its Description; Root = Node A
The Topology sub-TLV of a loose tree does not provide any path or path segment other than the hops that are to participate. The root MUST be the first hop. The leaves of a single loose tree MUST also be specified. Hop sub-TLVs can be included in a Topology sub-TLV to specify bridges that have to be avoided. If the Topology sub-TLV only specifies a single leaf, then one or more transit hops can be specified by the Topology sub-TLV to direct the path along a sequence of bridges, specified by the order of hops. If bridges whose respective Hop sub-TLVs are adjacent to each other in the Topology sub-TLV are not topology neighbors, then it is a loose hop. If a Topology sub-TLV conveys one or more loose hops, then that sub-TLV defines a loose explicit tree and each hop is considered to be a loose hop. The path of a loose hop MUST be pruned from the tree if the path would create a loop or hairpin 🌀
If the Base VIDs of the Topology sub-TLV are associated with the LTS ECT Algorithm or the MRT ECT Algorithm, then the Hop sub-TLVs conveyed by the Topology sub-TLV belong to Edge Bridges or bridges to be excluded. The BLCEs compute the loose trees, e.g., MRTs, such that they span the Edge Bridges and are rooted at an Edge Bridge 🧚
The Topology sub-TLV specifies a GADAG if the Base VIDs conveyed by the Topology sub-TLV are associated with the MRTG ECT Algorithm. Section 7 provides the details on the description of a GADAG by a Topology sub-TLV 🦋
Each Edge Bridge of an explicit tree MUST always be specified in the Topology sub-TLV by the inclusion of the Hop sub-TLVs corresponding to the Edge Bridges. The Edge Bridges of a tree are identified by setting the Edge Bridge flag (item c.3. in Section 6.2) in the appropriate Hop sub-TLVs 💖
If the explicit tree is loose, then the Topology sub-TLV MAY convey further sub-TLVs to specify constraints, e.g., an Administrative Group sub-TLV [RFC5305] or a Bandwidth Constraint (Section 6.3). If it is not possible to meet the constraint(s) specified by the Topology sub-TLV, then no tree is installed but a management report is generated 🙃
IS-IS PCR MAY be used for recording bandwidth assignment. In that case, the Topology sub-TLV conveys a Bandwidth Assignment sub-TLV (Section 6.4), and it MAY also convey a Timestamp sub-TLV (Section 6.5). If assignment of the bandwidth indicated by the Bandwidth Assignment sub-TLV of the Topology sub-TLV would result in overbooking any link of the explicit tree, then bandwidth assignment MUST NOT be performed and a management report is generated. If the Topology sub-TLV specifies a new valid explicit tree, then the tree is installed without bandwidth assignment 🔥
6.2. Hop Sub-TLV ✨
okay bestie, the Hop sub-TLV is where the real magic happens 🦋 It's the piece that says which bridge is which on a path, and honestly it's giving main character energy because every other sub-TLV kind of depends on it 💅
The Hop sub-TLV MUST be used to specify a hop of a topology. Each Hop sub-TLV carries an IS-IS System ID, and that System ID is what names the hop 🌸 A Hop sub-TLV lives inside a Topology sub-TLV (Section 6.1). So a strict explicit tree gets split up into branches, and each branch is a point-to-point path described by an ordered list of Hop sub-TLVs, like we talked about in Section 6.1 🧚
Here's the lowkey tricky bit 👀 A hop on a branch only gets created if the bridge for that hop is directly connected to the bridge right before it in the path. So a point-to-point LAN is basically identified by the two bridges it connects 💜 And the LAN only counts as part of the strict tree if those two bridges' Hop sub-TLVs sit right next to each other in the Topology sub-TLV. Not me being picky, but the order really matters 🙈
A Hop sub-TLV can also carry a Circuit ID, which helps tell apart multiple links between the same adjacent neighbor bridges 🎀 It tells you the role of a bridge too, like whether it's the root or an Edge Bridge 👑 The Topology sub-TLV of a loose tree only includes Hop sub-TLVs for bridges that have a special role in that tree ✨ And the Hop sub-TLV MAY also specify a delay budget for a loose hop 🍓
By default, the Edge Bridges both transmit and receive for each VID tied to an explicit tree 🫶 The exception is an LTS (Section 5) tied to a learning VLAN, which uses a unidirectional VID per bridge 🌈 If you want something different, the Transmit (T) and Receive (R) flags in the sub-TLV let you tune it 💖 The VID and its T/R flags only show up in the Hop sub-TLV when the Edge Bridges behave differently from the default 🙌
Figure 3 shows the format of this variable length Hop sub-TLV, which MUST be carried by a Topology sub-TLV (Section 6.1) 🔥
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 | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|C|V|B|R|L|E|Res| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Local Circuit ID (4 bytes if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of VIDs | (1 byte if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R|Res| VID 1 (12 bits) | (2 bytes if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R|Res| VID n (12 bits) | (2 bytes if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Constraint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Constraint | (6 bytes if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Hop Sub-TLVHere's how the parameters of a hop are encoded 🧁
a. Type (8 bits): The type of the sub-TLV, its value is 22. 🏷️
b. Length (8 bits): The total number of bytes contained in the Value field. 📏
c. Hop Flags (8 bits): The Hop sub-TLV carries six one-bit flags 🚩 The Circuit and the VID flags change how long the Hop sub-TLV is. Two bits are reserved for later, sent as 0 and ignored when received 🤫
- Circuit (C) flag (1 bit): This one-bit flag says whether the Extended Local Circuit ID parameter is there. If it's set, an Extended Local Circuit ID is included in the Hop sub-TLV 🔌
- VID (V) flag (1 bit): This one-bit flag says whether one or more VIDs are carried by the Hop sub-TLV 🦄 If it's set, the Number of VIDs parameter is present and tells you how many VIDs are carried. If it's reset, then neither the Number of VIDs parameter nor the VIDs show up in the Hop sub-TLV 🙅♀️
- Edge Bridge (B) flag (1 bit): This one-bit flag says whether the given System is an Edge Bridge, meaning a transmitter and/or receiver 📡 If the System is an Edge Bridge, the Edge Bridge flag MUST be set. It tells you that FDB entries have to be installed for this hop, as specified by the SPBV MAC address sub-TLV or the SPBM Service Identifier and Unicast Address sub-TLV of the hop 🗂️
- Root (R) flag (1 bit): This one-bit flag says whether the given System is the root of the explicit tree specified by the Topology sub-TLV 🌳 If the System is a root of a tree, the Root flag MUST be set. If the Topology sub-TLV specifies a single tree (so the Base VIDs are tied to either the ST ECT Algorithm or the LT ECT Algorithm (Section 5)), then the Root flag is only set for one of the Systems in that Topology sub-TLV. On top of that, the first Hop sub-TLV in the Topology sub-TLV carries the System that's the root of the tree 👑
If the Topology sub-TLV specifies a Loose Tree Set (so the Base VIDs are tied to the LTS ECT Algorithm (Section 5)), then the Root flag is set for each Edge Bridge, since each one roots a tree 🌲🌲
If the Topology sub-TLV is used for MRT operations (so the Base VIDs are tied to either the MRT ECT Algorithm or the MRTG ECT algorithm (Section 5)), then the Root flag is set for each MRT Root. If a Topology sub-TLV describing a GADAG doesn't name any MRT Root, then each SPT Root is an MRT Root as well 🌿
If the Base VIDs in the Topology sub-TLV are tied to the MRTG ECT algorithm (Section 5), then the Topology sub-TLV describes a GADAG, and the very first Hop sub-TLV names the GADAG Root. There's no flag for marking the GADAG Root, so the position does the work 🎯
- Leaf (L) flag (1 bit): This one-bit flag says whether the given System is a leaf of the explicit tree specified by the Topology sub-TLV 🍂 If the System is a leaf, the Leaf flag MUST be set. The Leaf flag only marks a leaf if the Topology sub-TLV specifies a single tree. The Leaf flag MUST be used to mark the end of a topology block if the Topology sub-TLV specifies a GADAG, see Section 7 🛑
- Exclude (E) flag (1 bit): This one-bit flag says whether the given System MUST be excluded from the topology 🚫 The Exclude flag and the Root flag cannot both be set for a given hop at the same time 🙅
- Reserved (Res) (2 bits): The reserved bits MUST be set to 0 when sent, and the value MUST be ignored when received 🫧
d. System ID (48 bits): The six-byte IS-IS System Identifier of the bridge that the Hop sub-TLV refers to 🪪
e. Extended Local Circuit ID (32 bits): The Extended Local Circuit ID [RFC5303] parameter isn't necessarily there in the Hop sub-TLV. Its presence is shown by the Circuit flag 🔍 Parallel links between a pair of neighbor bridges, which belong to different IS-IS adjacencies, can be told apart using the Extended Local Circuit ID 🧵 The Extended Local Circuit ID rides in the Hop sub-TLV for the bridge nearer to the root of the tree, and it names the circuit linking that bridge to the neighbor named by the next Hop sub-TLV of the Topology sub-TLV 🛤️ The Extended Local Circuit ID can only be used in strict trees 🚫
f. Number of VIDs (8 bits): The Number of VIDs parameter isn't present if the Hop sub-TLV doesn't carry VIDs, which the VID flag tells you 🔢
g. VID and its T/R flags (14 bits): The VID and its T/R flags only show up in the Hop sub-TLV if the given bridge is an Edge Bridge and it acts differently from the default for that particular VID 💫
- T flag (1 bit): This is the Transmit allowed flag for the VID right after it 📤
- R flag (1 bit): This is the Receive allowed flag for the VID right after it 📥
- Reserved (Res) (2 bits): The reserved bits MUST be set to 0 when sent, and the value MUST be ignored when received 🫧
- VID (12 bits): A VID 🆔
h. Delay Constraint (48 bits): A Hop sub-TLV MAY specify a delay constraint ⏱️ You can tell whether a delay constraint is there by the Length of the Hop sub-TLV, because a Hop sub-TLV that carries a delay constraint is six bytes longer than it would be without one 📐 The last six bytes then give a delay constraint if they carry a Unidirectional Link Delay sub-TLV [RFC7810] 🐢 The delay constraint MAY be used in a Topology sub-TLV that specifies a single loose tree (so the Base VIDs are tied to the LT ECT Algorithm (Section 5)) 🌙 If the delay constraint is applied, then the loose hop MUST fit in the delay budget given by the Delay parameter of the Unidirectional Link Delay sub-TLV carried by the Hop sub-TLV ⏳ If the Topology sub-TLV specifies a single leaf, then the path between the preceding Hop sub-TLV and the current Hop sub-TLV MUST meet the delay budget 🎯 If the Topology sub-TLV specifies multiple leaves, then the path between the root and the current Hop sub-TLV MUST meet the delay budget 🌟 If the tree is used as a reverse congruent tree, the delay constraint applies in both directions ↔️ If the tree is used as a directed tree, the delay constraint applies in the direction of the tree ➡️ If it's not possible to meet the delay constraint specified by the Topology sub-TLV, then no tree gets installed, but a management report is generated 📋✨
6.3. Bandwidth Constraint Sub-TLV 🎀
okay bestie, this one is all about how much bandwidth a constrained tree is allowed to promise 🦋 The Bandwidth Constraint sub-TLV MAY be included in a Topology sub-TLV (Section 6.1) to say how much available bandwidth the constrained tree has to provide 💅 Every loose hop MUST meet the bandwidth constraint 😭 The bandwidth value is either a total value, or it only refers to a single PCP, as the sub-TLV says 🌸 Here's what the format looks like ✨
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 | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| PCP |D|P| Res | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Bandwidth (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Bandwidth Constraint Sub-TLVThe parameters of the bandwidth constraint are encoded like this 🫶
a. Type (8 bits): The type of the sub-TLV, its value is 23. 🍓
b. Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 5 bytes. 🧚
c. PCP (4 bits): The Priority Code Point (PCP) parameter identifies the traffic class the Available Bandwidth parameter refers to, if any. 💜
d. DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) parameter. If the DEI parameter is clear, then the bandwidth constraint refers to committed information rate. If the DEI parameter is set, then the bandwidth constraint refers to the peak information rate. 🌈
e. PCP (P) flag (1 bit): If this flag is set, then the PCP parameter is taken into account. 🔥
f. Reserved (Res) (3 bits): The reserved bits MUST be set to 0 on transmission, and the value MUST be ignored on reception. 👑
g. Available Bandwidth (32 bits): The Available Bandwidth is specific to the traffic class identified by the PCP parameter if the PCP flag is set; otherwise, it is total bandwidth. In line with the bandwidth parameters specified in [RFC5305], the Available Bandwidth is encoded as a 32-bit IEEE floating-point number [IEEE754], and the units are bytes (not bits!) per second. When the Unreserved Bandwidth sub-TLV (sub-TLV type 11 specified by [RFC5305]) is used in a Layer 2 bridge network, the priority value encoded in the Unreserved Bandwidth sub-TLV provides the PCP, i.e., identifies a traffic class (not a setup priority level). Thus, the Available Bandwidth of a traffic class is easily comparable with the Unreserved Bandwidth stored in the TED for the given traffic class. The bandwidth constraint applies for both directions in case of symmetric explicit trees. Nevertheless, a VID associated with an explicit tree can be made unidirectional by means of the T/R flags belonging to the VID in the Hop sub-TLV (item g in Section 6.2) of the Edge Bridges. If all the VIDs of the Topology sub-TLV (Section 6.1) are unidirectional and all belong to the traffic class identified by the PCP parameter of the Bandwidth Constraint sub-TLV, then it is enough to meet the bandwidth constraint in the direction applied for those VIDs. 🦋✨
6.4. Bandwidth Assignment Sub-TLV 💖
okay so IS-IS PCR MAY be used for recording bandwidth assignment for explicitly placed data traffic in a domain if MSRP is not used within the domain 🌸 If MSRP is used in a domain, then only MSRP performs reservations and IS-IS does not 😭 Both MSRP and IS-IS MUST NOT be used to make bandwidth assignments in the same domain 🙈
The Bandwidth Assignment sub-TLV can define how much bandwidth gets recorded by IS-IS PCR at each hop of the explicit tree described by the matching Topology sub-TLV (Section 6.1) 🧚 IS-IS PCR uses it to record bandwidth assignment for a traffic class identified by the PCP parameter of a VLAN tag 💅 If precedence order has to be worked out among bandwidth assignments in a domain with multiple PCEs, IS-IS PCR does it as described below ✨ If the bandwidth assignment from the Topology sub-TLV is not possible, e.g., due to overbooking, then bandwidth recording MUST NOT be performed and a management report is generated 💀 If the Topology sub-TLV specifies a new valid explicit tree, then the tree is installed without bandwidth assignment 🎀 The Bandwidth Assignment sub-TLV is conveyed by a Topology sub-TLV (Section 6.1) 🫶 Here's the format 👇
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 | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| PCP |D| Imp |R| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Bandwidth Assignment Sub-TLVThe parameters of the bandwidth assignment are encoded like this 🌈
a. Type (8 bits): The type of the sub-TLV, its value is 24. 🦋
b. Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 5 bytes. 💜
c. PCP (3 bits): The PCP parameter identifies the traffic class for which the bandwidth is to be assigned. 🍓
d. DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) parameter. If the DEI parameter is clear, then the bandwidth assignment is performed for providing the committed information rate. If the DEI parameter is set, then the bandwidth assignment is performed for providing the peak information rate. 🔥
e. Importance (Imp) (3 bits): This is the Importance parameter for determining precedence order among bandwidth assignments within a PCP as described below. A lower numerical value indicates more important bandwidth assignment within a PCP. The default value of the Importance parameter is 7. 👑
f. Reserved (R) (1 bit): The reserved bit MUST be set to 0 on transmission, and the value MUST be ignored on reception. 🙈
g. Bandwidth (32 bits): This is the amount of bandwidth to be assigned for the traffic class identified by the PCP parameter. In line with the bandwidth values specified in [RFC5305], the Bandwidth parameter is encoded as a 32-bit IEEE floating-point number [IEEE754], and the units are bytes (not bits!) per second. The bandwidth assignment applies for both directions in case of symmetric explicit trees. 🌸
The PCEs are collectively responsible for making a consistent set of bandwidth assignments when IS-IS PCR is used for recording bandwidth allocations. If, despite that, precedence ordering is required among bandwidth assignments, then ordering based on the following parameters MUST be applied: 🧚
- PCP parameter of Bandwidth Assignment sub-TLV,
- Importance parameter of Bandwidth Assignment sub-TLV,
- Timestamp sub-TLV (if present in the Topology sub-TLV).
A bandwidth assignment takes precedence if it has a higher PCP, or a higher Importance within a PCP, or an earlier timestamp in case of equal Importance within a PCP. A bandwidth assignment associated with a timestamp takes precedence over a bandwidth assignment without a timestamp when PCP and Importance of different bandwidth assignments are both equal. If resolution is not possible based on the above parameters or they are not available, e.g., each bandwidth assignment lacks a timestamp or the precedence order has to be determined for the use of a VID, then the item is granted to the PCE whose LSP has the numerically lowest LSP ID. 💅✨
6.5. Timestamp Sub-TLV 🧚
The Timestamp sub-TLV MAY be included in a Topology sub-TLV (Section 6.1) to provide precedence order among equally important bandwidth assignments within a PCP, as described in Section 6.4 💖 Here's the format 👇
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 | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Timestamp Sub-TLVThe timestamp represents a positive time with respect to the Precision Time Protocol (PTP) epoch, and it is encoded as follows: 🌈
a. Type (8 bits): The type of the sub-TLV; its value is 25. 🦋
b. Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 4 bytes. 💜
c. Time (32 bits): This is the time in units of seconds with respect to the PTP epoch. 🍓
The Timestamp sub-TLV carries the seconds portion of PTP as specified by [IEEE1588]. The epoch is 1970-01-01 00:00:00 TAI (i.e., the PTP time does not include leap seconds). 🫶✨
7. MRT-FRR Application 🦋
okay so this section is where the MRT stuff gets real, bestie 💅 it's about how [IEEE8021Qca] actually uses MRT, which is covered in detail in [MRT-IEEE8021qca], and it's giving "here's the special stuff you need to know" for the MRT Lowpoint algorithm [RFC7811]. this bit applies to BOTH the MRT ECT Algorithm and the MRTG ECT Algorithm 🎀 and it also explains the MRTG ECT Algorithm details, especially how the Topology sub-TLV is used 🧚
IS-IS PCR does NOT use the MRT Profile from [RFC7812] 🙈 it only relies on the algorithm spec in [RFC7811]. and both the MRT ECT Algorithm and the MRTG ECT Algorithm use the MRT Lowpoint algorithm from [RFC7811] 💜
the SPB Link Metric sub-TLV [RFC6329] sets the metric of each link for IS-IS PCR, MRT algorithms included 🌸 if the two ends of an adjacency advertise different SPB Link Metric values, the maximum value MUST be used ✨ and if the MRT computation finds equal cost (sub-)paths, the default tie-breaking from Section 11 of [RFC6329] MUST be used, which goes by the lower BridgeID 🔥 (the BridgeID is 8 bytes: upper 2 bytes are the node's BridgePriority, lower 6 bytes are the node's System ID, iykyk 🍓)
also if MRTs are used for source-specific multicast (see [IEEE8021Qca] for the deets), the bridges have to compute the MRTs of the OTHER bridges too, not just their own, so they can install the right FDB entries 😭 (it's kinda like needing all pairs shortest path instead of Dijkstra for source-specific shortest path multicast trees, lowkey a lot 💀)
The GADAG is identical for all the MRTs in a network domain because of the MRT Lowpoint algorithm [RFC7811] 🌈 so it's honestly smart to compute the GADAG in ONE place, by a single entity called the GADAG Computer, which is either a PCE or the GADAG Root 👑
if the MRTG ECT Algorithm is applied, the GADAG MUST be computed ONLY by the GADAG Computer, and then it MUST flood the descriptor Topology sub-TLV of the GADAG 📢 the bridges then compute their MRTs from the received GADAG ✨
the GADAG computation needs a GADAG Root 🎀 the bridge with the best BridgeID MUST be selected as the GADAG Root, where a numerically lower value means a better identifier 💅 the Bridge Priority part of the BridgeID lets you configure the GADAG Root by management action, and it's conveyed by the SPB Instance sub-TLV [RFC6329] 🦋
the GADAG Computer MUST perform the GADAG computation as specified by the MRT Lowpoint algorithm [RFC7811] 🫶 then it MUST encode the GADAG in a Topology sub-TLV (Section 6.1) and flood it through the whole domain 🌸
now here's how the GADAG gets encoded, bestie 🧚 it's done with directed ear decomposition. a directed ear is a directed point-to-point path whose end points CAN coincide, but no other element of the path is repeated in the ear 💖 each ear is an ordered list of hops, and the order follows the direction of the arcs in the GADAG ✨ a GADAG has NO leaves, so the Leaf flag (item c.5. in Section 6.2) is used to mark the END of a topology block instead 🙈 (a GADAG with multiple blocks is shown in Figure 8 💜) the ears in the Topology sub-TLV are ordered so that the end points of an ear belong to earlier ears 🔥
the GADAG Root is NOT marked by any flag, but it IS the first hop in the Topology sub-TLV, so the first ear starts and ends with the GADAG Root 👑 MRT Roots MUST be marked with the Root flag (item c.4. in Section 6.2), and every other Edge Bridge is a leaf of the given MRTs 🌈 if no MRT Root is specified, then each SPT Root is also an MRT Root 💅
Figure 7 shows an example GADAG 🦋 it also explains the GADAG itself: it shows the System ID parameter of the Hop sub-TLV (Section 6.2) and the order of hops in the Topology sub-TLV (Section 6.1) ✨
Leaf
Hop flag
+-----------+---+
| A | |
+-----------+---+
| B | |
+-----------+---+
| C | |
+-----------+---+
| F | |
[B]<---[A]<---[I] +-----------+---+
| ^ ^ | A | |
| | | +-----------+---+
V | | | C | |
[C]--->[F]--->[H] +-----------+---+
| ^ | D | |
| | +-----------+---+
V | | E | |
[D]--->[E]--->[G] +-----------+---+
| G | |
+-----------+---+
| H | |
+-----------+---+
| I | |
+-----------+---+
| A | |
+-----------+---+
| F | |
+-----------+---+
| H | X |
+-----------+---+
Figure 7: A GADAG and Its Description; GADAG Root = Node Aa topology can have multiple blocks, like the one in Figure 8(a) 🍓 this example has FOUR blocks, since each cut-link is its own block 💀 A-B-C-D-E-F is a block, D-G is another, then G-H, and H-J-K are more blocks 🎀 the GADAG for it is in Figure 8(b) 🦋 two arcs pointing opposite ways represent a cut-link in a GADAG, like the cut-link between D and G 💅 the encoding starts with the block (ADAG) that involves the GADAG Root, as shown in Figure 8 ✨ the first hop in the Topology sub-TLV is the GADAG Root (node A here) and the ADAG of the first block is described with ear decomposition, like we just went over 🧚 in this example the first block is fully traversed at the SECOND occurrence of node A in the GADAG descriptor 😭 the END of a block is marked by setting the Leaf flag on the last hop of the block, e.g. the second occurrence of node A in the example descriptor 💜 the next node in the GADAG descriptor (D here) is the localroot for the nodes in the next block 🌸 keep going and the Leaf flag is set on the third occurrence of D, the third occurrence of G, and the third occurrence of H, each one ending a block 🔥
the first hop of the first block is the GADAG Root, and the first hop in every other block is the localroot 👑 the spots where the Leaf flags are set are how you figure out the localroot, which is the next hop 🌈 in the example descriptor, A is the localroot for B, C, D, E, F (and A is the GADAG Root) 💅 D is the localroot for G 🦋 G is the localroot for H ✨ and H is the localroot for J and K 🧚 the GADAG Root gets a localroot of None 🙈
[F]--[E] +--[K] +-----------+---+
| | | | | A | |
| | | | +-----------+---+
[A] [D]--[G]--[H] | | B | |
| | | | +-----------+---+
| | | | | C | |
[B]--[C] +--[J] +-----------+---+
| D | |
(a) Topology +-----------+---+
| E | |
+-----------+---+
| F | |
+-----------+---+
| A | X |
+-----------+---+
+-+ +-+ +-+ | D | |
|F|<-|E| +--|K| +-----------+---+
+-+ +-+ | +-+ | G | |
| ^ | ^ +-----------+---+
| | V | | D | X |
V +-+ +-+ +-+ | +-----------+---+
+-+ | |->| |->| | | | G | |
|A| |D| |G| |H| | +-----------+---+
+-+ | |<-| |<-| | | | H | |
| +-+ +-+ +-+ | +-----------+---+
| ^ | | | G | X |
V | | | +-----------+---+
+-+ +-+ | +-+ | H | |
|B|->|C| +->|J| +-----------+---+
+-+ +-+ +-+ | J | |
+-----------+---+
(b) GADAG | K | |
+-----------+---+
| H | X |
+-----------+---+
(c) GADAG Descriptor
Figure 8: A GADAG with Cut-Links and Its Description; GADAG Root =
Node ABlock IDs get reconstructed while parsing a Topology sub-TLV that specifies a GADAG 🧚 the current Block ID starts at 0 and goes to the GADAG Root 💖 a node that shows up in the GADAG descriptor without a Block ID already assigned gets the current Block ID ✨ then the current Block ID goes up by 1 after the localroot of a block is processed 🌸 the localroot of a block KEEPS the Block ID of the first block it was assigned one in, so it's not a new one 🔥 in Figure 8, A has Block ID=0 👑 B, C, D, E, and F have Block ID=1 🌈 G has Block ID=2 💅 H has Block ID=3 🦋 and J and K have Block ID=4 🫶
8. Summary ✨
this document specifies IS-IS sub-TLVs for controlling explicit trees in Layer 2 networks 🧚 these sub-TLVs can ALSO be used to distribute a centrally computed GADAG or MRTs if MFT-FRR is used 💜
9. IANA Considerations 🎀
this document defines the following IS-IS sub-TLVs within the MT-Capability TLV (type 144) 💅 they're listed in the "IS-IS TLV Codepoints" registry 🌸
Type Description Length
---- ---------------------------- --------
21 Topology variable
22 Hop variable
23 Bandwidth Constraint 5
24 Bandwidth Assignment 5
25 Timestamp 410. Security Considerations 🔐
Okay bestie, this part is SO important 😭. This document adds no additional security risks to IS-IS, and it doesn't add any extra security for IS-IS either when you're using it in a configured environment or a single-operator domain like a data center 🏢. IS-IS PCR is not for zero-configuration environments 🙅♀️.
Any mechanism that chooses forwarding paths and allocates resources to those paths is potentially vulnerable to attack 💀. The security considerations section of [RFC4655] explains the risks of using a PCE for this purpose, so go read it 📖. If you want to use any other way of figuring out paths, you should only do it after thinking through similar concerns 🧠.
Because the mechanism for distributing tree information relies on IS-IS routing, the IS-IS routing security considerations (Section 6, [RFC1195]) and the mechanisms (for example, [RFC5310]) used to authenticate peer advertisements apply too 🔑✨.
11. References 📚
11.1. Normative References
[IEEE8021Qca]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Bridges and Bridged Networks - Amendment 24:
Path Control and Reservation", IEEE 802.1Qca-2015,
DOI 10.1109/IEEESTD.2016.7434544, 2016,
<https://standards.ieee.org/findstds/
standard/802.1Qca-2015.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way
Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,
DOI 10.17487/RFC5303, October 2008,
<http://www.rfc-editor.org/info/rfc5303>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<http://www.rfc-editor.org/info/rfc5307>.
[RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE
802.1aq Shortest Path Bridging", RFC 6329,
DOI 10.17487/RFC6329, April 2012,
<http://www.rfc-editor.org/info/rfc6329>.
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
RFC 7810, DOI 10.17487/RFC7810, May 2016,
<http://www.rfc-editor.org/info/rfc7810>.
[RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute
Using Maximally Redundant Trees (MRT-FRR)", RFC 7811,
DOI 10.17487/RFC7811, June 2016,
<http://www.rfc-editor.org/info/rfc7811>.11.2. Informative References
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, 2008,
<http://standards.ieee.org/findstds/
standard/1588-2008.html>.
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic",
IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935, 2008,
<http://standards.ieee.org/findstds/
standard/754-2008.html>.
[IEEE8021aq]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks -- Amendment 20: Shortest Path
Bridging", IEEE 802.1aq-2012,
DOI 10.1109/IEEESTD.2012.6231597, 2012,
<https://standards.ieee.org/findstds/
standard/802.1aq-2012.html>.
[IEEE8021Q]
IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
DOI 10.1109/IEEESTD.2014.6991462, 2014,
<https://standards.ieee.org/findstds/
standard/802.1Q-2014.html>.
[MRT-IEEE8021qca]
Bowers, C. and J. Farkas, "Applicability of Maximally
Redundant Trees to IEEE 802.1Qca Path Control and
Reservation", Work in Progress, draft-bowers-rtgwg-mrt-
applicability-to-8021qca-01, July 2015.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
<http://www.rfc-editor.org/info/rfc7812>.Acknowledgements 🫶
The authors want to thank Don Fedyk and Eric Gray for their comments and suggestions. Iconic of them 💜.
Authors' Addresses 🌸
Janos Farkas (editor)
Ericsson
Konyves Kalman krt. 11/B
Budapest 1097
Hungary
Email: janos.farkas@ericsson.com
Nigel Bragg
Ciena
43-51 Worship Street
London EC2A 2DX
United Kingdom
Email: nbragg@ciena.com
Paul Unbehagen Jr
Avaya
1300 W. 120th Avenue
Westminster, CO 80234
United States
Email: unbehagen@avaya.com
Glenn Parsons
Ericsson
349 Terry Fox Drive
Ottawa ON, K2K 2V6
Canada
Email: glenn.parsons@ericsson.com
Peter Ashwood-Smith
Huawei Technologies
303 Terry Fox Drive, Suite 400
Ottawa ON, K2K 3J1
Canada
Email: Peter.AshwoodSmith@huawei.com
Chris Bowers
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States
Email: cbowers@juniper.net📦 where this page comes from
- ietf: rfc7813 2016-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms