RFC 6329
IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging
RFC 6329 📜 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging
okay bestie, this is RFC 6329, and it's a Standards Track doc from the IETF, published in April 2012 🗓️ It's ISSN 2070-1721 and it's about how IS-IS gets extended so it can run IEEE 802.1aq Shortest Path Bridging (SPB) 🌸
The author crew is giving main character energy 💅 D. Fedyk, Ed. (Alcatel-Lucent) and P. Ashwood-Smith, Ed. (Huawei) are the editors, and they're joined by D. Allan (Ericsson), N. Bragg (Ciena Limited), and P. Unbehagen (Avaya). 🫶
The header doesn't list anything this RFC obsoletes or updates, so it's standing on its own 🦋
Abstract ✨
okay so 802.1aq Shortest Path Bridging (SPB) is the IEEE's next step after the older spanning tree and registration protocols 🌈 It does true shortest path forwarding in a mesh Ethernet network and uses multiple equal cost paths to do it 🔥 That means it can handle way bigger Layer 2 topologies, converge faster, and actually use the mesh properly instead of wasting it 😭 It also gives you single point provisioning for logical connectivity membership, covering point-to-point, point-to-multipoint, and multipoint-to-multipoint setups 💜 This memo covers the IS-IS changes you need to support this IEEE protocol, plus some context and examples 🎀
Status of This Memo 🧚
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 📚
Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6329 🔗
Copyright Notice 🌸
Copyright (c) 2012 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. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 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 they come without warranty as described in the Simplified BSD License 💅
Table of Contents 💖
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Conventions Used in This Document ...............................5
4. 802.1aq Overview ................................................6
4.1. Multi-Topology Support .....................................8
4.2. Data Path SPBM - Unicast ...................................8
4.3. Data Path SPBM - Multicast (Head-End Replication) ..........9
4.4. Data Path SPBM - Multicast (Tandem Replication) ............9
4.5. Data Path SPBV Broadcast ..................................11
4.6. Data Path SPBV Unicast ....................................11
4.7. Data Path SPBV Multicast ..................................12
5. SPBM Example ...................................................12
6. SPBV Example ...................................................14
7. SPB Supported Adjacency types ..................................16
8. SPB IS-IS Adjacency Addressing .................................16
9. IS-IS Area Address and SYSID ...................................17
10. Level 1/2 Adjacency ...........................................17
11. Shortest Path Default Tie-Breaking ............................17
12. Shortest Path ECT .............................................18
13. Hello (IIH) Protocol Extensions ...............................19
13.1. SPB-MCID Sub-TLV .........................................20
13.2. SPB-Digest Sub-TLV .......................................21
13.3. SPB Base VLAN Identifiers (SPB-B-VID) Sub-TLV ............23
14. Node Information Extensions ...................................24
14.1. SPB Instance (SPB-Inst) Sub-TLV ..........................24
14.1.1. SPB Instance Opaque ECT-ALGORITHM
(SPB-I-OALG) Sub-TLV ..............................28
15. Adjacency Information Extensions ..............................29
15.1. SPB Link Metric (SPB-Metric) Sub-TLV .....................29
15.1.1. SPB Adjacency Opaque ECT-ALGORITHM
(SPB-A-OALG) Sub-TLV ..............................30
16. Service Information Extensions ................................30
16.1. SPBM Service Identifier and Unicast Address
(SPBM-SI) Sub-TLV ........................................30
16.2. SPBV MAC Address (SPBV-ADDR) Sub-TLV .....................32
17. Security Considerations .......................................34
18. IANA Considerations ...........................................34
19. References ....................................................35
19.1. Normative References .....................................35
19.2. Informative References ...................................36
20. Acknowledgments ...............................................361. Introduction ✨
okay so 802.1aq Shortest Path Bridging (SPB) [802.1aq] is the IEEE's next step after the older spanning tree and registration protocols 🌈 It does true shortest path forwarding in an Ethernet mesh network and uses multiple equal cost paths to get there 🔥 That lets SPB handle much bigger Layer 2 topologies, converge faster, and actually make good use of the mesh instead of wasting it 😭 You also get single point provisioning for logical connectivity membership, which covers point-to-point (E-LINE), point-to-multipoint (E-TREE), and multipoint-to-multipoint (E-LAN) setups 💜
The control protocol for 802.1aq is IS-IS [IS-IS] with a small number of TLVs and sub-TLVs added on top 🎀 It supports two Ethernet encapsulating data paths: 802.1ad (Provider Bridges) [PB] and 802.1ah (Provider Backbone Bridges) [PBB]. This memo documents those TLVs and gives a bit of overview along the way 🦋
Here's the key bit 🔑 802.1aq doesn't need any state machine or other big changes to [IS-IS]. It just needs a new Network Layer Protocol Identifier (NLPID) and a set of TLVs. If this document and [IS-IS] ever seem to disagree, [IS-IS] wins 👑
2. Terminology 🍓
Besides the well-understood IS-IS terms, this memo uses terminology from IEEE 802.1 and introduces a few of its own terms, listed below 💅
802.1ad Provider Bridges (PBs) - Q-in-Q encapsulation
802.1ah Provider Backbone Bridges (PBBs), MAC-IN-MAC
encapsulation
802.1aq Shortest Path Bridging (SPB)
Base VID VID used to identify a VLAN in management operations
B-DA Backbone Destination Address 802.1ah PBB
B-MAC Backbone MAC Address
B-SA Backbone Source Address in 802.1ah PBB header
B-VID Backbone VLAN ID in 802.1ah PBB header
B-VLAN Backbone Virtual LAN
BPDU Bridge PDU
BridgeID 64-bit quantity = (Bridge Priority:16)<<48 | SYSID:48
BridgePriority 16-bit relative priority of a node for tie-breaking
C-MAC Customer MAC. Inner MAC in 802.1ah PBB header
C-VID Customer VLAN ID
ECT-ALGORITHM 32-bit unique ID of an SPF tie-breaking set of rules
ECT-MASK 64-bit mask XORed with BridgeID during tie-breaking
E-LAN Bidirectional Logical Connectivity between >2 UNIs
E-LINE Bidirectional Logical Connectivity between two UNIs
E-TREE Asymmetric Logical Connectivity between UNIs
FDB Filtering Database: {DA/VID}->{next hops}
I-SID Ethernet Services Instance Identifier used for
Logical Grouping for E-LAN/LINE/TREE UNIs
LAN Local Area Network
LSDB Link State Database
LSP Link State PDU
MAC Media Access Control
MAC-IN-MAC Ethernet in Ethernet framing as per 802.1ah [PBB]
MDT Multicast Distribution Tree
MMRP Multiple MAC Registration Protocol 802.1ak [MMRP]
MT Multi-Topology. As used in [MT]
MT ID Multi-Topology Identifier (12 bits). As used in [MT]
NLPID Network Layer Protocol Identifier: IEEE 802.1aq= 0xC1
NNI Network-Network Interface
Q-in-Q Additional S-VID after a C-VID (802.1ad) [PB]
PBB Provider Backbone Bridge - forwards using PBB
Ingress Check Source Forwarding Check - drops misdirected frames
(S,G) Source & Group - identity of a source-specific tree
(*,G) Any Source & Group - identity of a shared tree
S-VID Service VLAN ID
SA Source Address
SPB Shortest Path Bridging - generally all of 802.1aq
SPB Shortest Path Bridge - device implementing 802.1aq
SPB-instance Logical SPB instance correlated by MT ID
SPBM Device implementing SPB MAC mode
SPBV Device implementing SPB VID mode
SPSourceID 20-bit identifier of the source of multicast frames
SPT Shortest Path Tree computed by one ECT-ALGORITHM
SPT Region A set of SPBs with identical VID usage on their NNIs
SPVID Shortest Path VLAN ID: a C-VID or S-VID that
identifies the source
STP Spanning Tree Protocol
UNI User-Network Interface: customer-to-SPB attach point
VID VLAN ID: 12-bit logical identifier after MAC header
VLAN Virtual LAN: a logical network in the control plane3. Conventions Used in This Document 📐
Here's where the requirement words live 🎀 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 💜
The lowercase forms with an initial capital, "Must", "Must Not", "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional", also get read in the sense defined in [RFC2119]. The difference is that they're only used where the normative behavior is defined in documents published by SDOs other than the IETF 🌸
4. 802.1aq Overview 🦋
okay so this section gives you a quick overview of how [802.1aq] behaves, but it's not the normative text 🙈 For the definitive behavior, go read [802.1aq] itself. Still, I used the lowercase forms with initial capitalization of the RFC 2119 conventions here, so you can get a feel for the intended normative behaviors. 💅
802.1aq is built on 802.1Q-based Ethernet bridging 🌸 The filtering database (FDB) gets filled in as a result of the topology computed from the IS-IS database. If you're new to IEEE terminology, Ethernet behavior is almost entirely described in terms of "filtering" (of broadcast traffic) instead of "forwarding" (the explicit direction of unicast traffic). This document uses the generic term "forwarding," and these two terms are really just different ways of saying the same behaviors ✨
802.1aq supports multiple modes of operation, depending on the type of data plane and the behavior you want 💜 For the first two modes, SPBV and SPBM, routes are shortest path, forward- and reverse-path symmetric for any source/destination pair within the SPB domain, and congruent for unicast and multicast. So the shortest path tree (SPT) to a given node is congruent with the multicast distribution tree (MDT) from a given node. The MDT for a given VLAN is a pruned subset of the complete MDT for a given node, and it's identical to that node's SPT. Symmetry and congruency preserve packet ordering and proper fate sharing of Operations, Administration, and Maintenance (OAM) flows by the forwarding path, which is honestly so important 😭 Those modes are fully supported by the existing [802.1ag] and [Y.1731] OAM mechanisms.
VLANs give you a natural delineation of service instances 🎀 802.1aq supports two modes, SPB VID (SPBV) and SPB MAC (SPBM). In SPBV, multiple VLANs can be used to spread load across different shortest path trees (each computed by a different tie-breaking rule) on a service basis. In SPBM, service instances are delineated by I-SIDs, but VLANs can again be used to spread load across different shortest path trees.
There are two encapsulation methods supported 🧚 SPBM can be used in a PBB network that implements PBB (802.1ah [PBB]) encapsulation. SPBV can be used in PB networks that implement VLANs, PB (802.1aq [PB]), or PBB encapsulation. The two modes can coexist in the same SPB network.
The practical design goals for the current 802.1aq specification are networks of 100 nodes for SPBV and 1000 nodes for SPBM. BUT (and this is the plot twist) since SPBV can be used sparsely in an SPB region, it can simply span a large SPB region using a small number of SPVIDs 👑
In SPBM and SPBV, each bridge has at least one unique "known" MAC address, which is advertised by IS-IS in the SYSID 🍓
In the forwarding plane, SPBM uses the combination of one or more B-VIDs and "known" Backbone-MAC (B-MAC) addresses that have been advertised in IS-IS. The word Backbone just implies an encapsulation that's often used in backbone networks, but the encapsulation is useful in other kinds of networks too, anywhere hiding C-MACs is useful 🌈
The SPBM filtering database (FDB) is computed and installed for unicast and multicast MAC addresses. The SPBV filtering database, on the other hand, is computed and installed for unidirectional VIDs (referred to as SPVIDs), and after that, MAC reachability is learned (exactly as in bridged Ethernet) for unicast MACs 💖
Both SPBV and SPBM use source-specific multicast trees 🦋 If they share the same ECT-ALGORITHM (a 32-bit worldwide unique definition of the computation), the tree is the same SPT. For SPBV, (S,G) is encoded by a source-specific VID (the SPVID) and a standard Group MAC address. For SPBM, (S,G) is encoded in the destination B-MAC address as the concatenation of a 20-bit SPB wide unique nodal nickname (referred to as the SPSourceID) and the 24-bit I-SID, together with the B-VID that corresponds to the ECT-ALGORITHM network-wide.
802.1aq supports membership attributes that are advertised with the I-SID (SPBM) or Group Address (SPBV) that defines the group 🫶 Individual members can be transmitters (T) and/or receivers (R) within the group, and the multicast state is sized to match those requests. Multicast group membership is possible even without transmit membership, by doing head-end replication to the receivers, which eliminates transit multicast state entirely 🔥
Some highly connected mesh networks offer path diversity by providing multiple equal cost alternatives between nodes. Since congruency and symmetry Must be honored, a single tree may leave some links under-utilized 🥺 By using different deterministic tie-breakers, up to 16 shortest paths of arbitrary diversity are possible between any pair of nodes, and that spreads the traffic on a VLAN basis. Main character energy 👑
SPBV and SPBM May share a single SPT with a single ECT-ALGORITHM, or use any combination of the 16 ECT-ALGORITHMs. There's also an extensible framework that lets additional or alternative algorithms with other properties and parameters (e.g., ECMP, (*,G)) be supported too, without any changes in this document or the IEEE documents 🧚♀️
4.1. Multi-Topology Support
SPB incorporates the multi-topology features of [MT], which allows multiple logical SPB instances within a single IS-IS instance 🌸
To make this work, all SPB-related information is either explicitly or implicitly associated with a Multi-Topology Identifier (MT ID). All the SPB information related to a given MT ID forms a single logical SPB instance 💅
SPB has its own adjacency metrics, and those metrics are also associated with an MT ID. That means you can have different adjacency metrics (or infinite metrics) for SPB adjacencies that are not only distinct from IP or other NLPIDs riding in this IS-IS instance, but also distinct from the ones used by other SPB instances in the same IS-IS instance. The way that's organized is so clean 😭
Data plane traffic for a given MT ID is intrinsically isolated by the VLANs assigned to that SPB instance. So VLANs (represented by VIDs in TLVs and in the data plane) Must Not overlap between SPB instances, no matter how the control planes are isolated 🚫
The [MT] mechanism, when applied to SPB, lets you use different routing metrics and topology subsets for different classes of service 💜
Using [MT] for anything other than the default MT ID #0 is completely OPTIONAL 🎀
Using [MT] to separate SPB from other NLPIDs is also OPTIONAL 🌈
4.2. Data Path SPBM - Unicast
Unicast frames in SPBM are encapsulated as per 802.1ah [PBB]. A Backbone Source Address (B-SA), Backbone Destination Address (B-DA), Backbone VLAN ID (B-VID), and an I-Component Service Instance ID (I-TAG) are used to encapsulate the Ethernet frame. The B-SA is a B-MAC associated with the ingress 802.1aq bridge, usually the "known" B-MAC of that entire bridge. The B-DA is one of the "known" B-MACs associated with the egress 802.1aq bridge. The B-VID and I-TAG are mapped based on the physical or logical UNI port being bridged (untagged, or tagged either by S-TAG or C-TAG). Normal learning and broadcast to unknown C-MACs is applied as per [PBB], at the ingress/egress SPBs only 🦋
Unlike [PBB] on a (*,G) tree, B-DA forwarding on tandem nodes (NNI to NNI) is performed without learning ✨ Instead, the output of the 802.1aq computations, based on the TLVs specified in this document, is used to populate the filtering databases (FDBs). The FDB entries map {B-DA, B-VID} to an outgoing interface, and they're only populated from the IS-IS database and computations 🧠
The B-SA/B-VID is checked on tandem nodes against the ingress port. If the B-SA/B-VID (as a destination) entry in the FDB does not point to the port the packet arrived on, the packet is discarded. This is called an ingress check, and it's a very powerful loop mitigation mechanism 🔁💀
4.3. Data Path SPBM - Multicast (Head-End Replication)
Head-end replication is supported for instances where there's a sparse community of interest or a low likelihood of multicast traffic 🌸 It requires no multicast state in the core. A UNI port that wants to use head-end replication Must Not advertise its I-SID membership with the Transmit (T) bit set. Instead, it Must locally and dynamically construct the appropriate unicast serial replication to all the other receivers (Receive (R) bit set) of the same I-SID 🫶
When an unknown customer unicast or a multicast frame arrives at an SPBM User-Network Interface (UNI) port that's been configured to replicate only at the head end, the packet is replicated once for each receiver, encapsulated, and sent as a unicast frame 📦 The set of receivers is determined by looking through the IS-IS database for other SPBs that have registered interest in the same I-SID with the R bit set. That R bit / I-SID pair is found in the SPBM Service Identifier and Unicast Address (SPBM-SI) sub-TLV. The packets are encapsulated as per the SPBM unicast forwarding above 💖
4.4. Data Path SPBM - Multicast (Tandem Replication) 🌸
okay so tandem replication is giving "only replicate where it's actually needed" 💅 It uses the shortest path tree to copy frames only at the points where the tree forks, and only if there's at least one receiver on each branch. It's super bandwidth efficient, but core bridges have to keep multicast FDB entries (state) for it, which might be wasteful if there's barely any multicast traffic going on. Head-end replication is the better pick when an I-SID has little or no true multicast traffic. Tandem replication kicks in on transit nodes whenever the I-SID is advertised with the T bit set. ✨
Broadcast, unknown unicast, or multicast frames that arrive at an SPBM UNI port get encapsulated with a B-DA multicast address. That address uniquely identifies the encapsulating node (the root of the Multicast Distribution Tree) and the I-SID that scopes this multicast. 🎀
This B-DA address is a well-formed multicast group address (per 802.1Q and 802.1ah). It concatenates the SPSourceID A' with the I-SID M, written as DA=<A',M>, and that combo uniquely identifies the (S,G) tree. Here's the exact format in Figure 1:
M L TYP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|0|SPSrcMS| SPSrc [8:15] | SPSrc [0:7] | I-SID [16:23] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID [8:15] | I-SID [0:7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SPBM Multicast Address Format
(SPSrcMS represents SPSrc [16:19])Note: In Figure 1, the index numbering goes from the less significant bit to the more significant bit within a byte or a field within a byte. That gives the wire order of the bits in the address, which matches the IETF format used everywhere else in this document. (The IEEE convention for number representation reverses the bits within an octet compared with IETF practice.)
- M is the multicast bit, always set to 1 for a multicast DA. (It's the lowest bit in the most significant byte.) 💜
- L is the local bit, always set to 1 for an SPBM-constructed multicast DA.
- TYP is the SPSourceID type. 00 is the only type supported at this time.
- SPSrc (SPSourceID) is a 20-bit quantity that uniquely identifies an SPBM node for all B-VIDs allocated to SPBM operation. It's just the SPSourceID advertised in the SPB Instance (SPB-Inst) sub-TLV. The value SPSourceID = 0 has special significance: it's advertised by an SPBM node that's been configured to assign its SPSourceID dynamically. That needs LSDB synchronization, but the SPSourceID assignment hasn't finished yet. 🦋
- I-SID is the 24-bit I-Component Service ID advertised in the SPBM Service Identifier TLV. It occupies the lower 24 bits of the SPBM multicast DA. The I-SID value 0xfff is reserved for SPBM control traffic (refer to the default I-SID in [802.1aq]).
This multicast address format is used as the DA on frames when they're first encapsulated at ingress to the SPBM network. The DA also gets installed into the FDBs on all SPBM nodes that sit on the corresponding SPT between the source and the other nodes that have registered receiver interest in the same I-SID. 🧚
Just like with unicast forwarding, the B-SA/B-VID May be used to perform an ingress check. But the SPSourceID encoded in the DA and the "drop-on-unknown" functionality of the FDB in [PBB] achieve the same effect. 🙈
The I-Component at the egress SPBM device has completely standard [PBB] behavior, so it will:
- learn the remote C-SA to B-SA relationship and
- bridge the original customer frame to the set of local UNI ports that are associated with the I-SID.
4.5. Data Path SPBV Broadcast 🍓
When a packet for an unknown DA arrives at an SPBV UNI port, VID translation (or VID encapsulation for untagged Frames) happens with the corresponding SPVID for this VLAN and ingress SPB. ✨
SPVID forwarding is basically an SPT that follows normal VLAN forwarding behavior, with one twist: the SPVID is unidirectional. Because of that, shared VLAN learning (SVL) is used between the forward- and reverse-path SPVIDs associated with the same Base VID. That's what lets SPBV unicast forwarding work in the normal reverse learning fashion. 💅
The ingress check is just verifying that the bridge the SPVID is assigned to really is "shortest path" reachable over the link where the packet tagged with that SPVID arrived. This is computed from the IS-IS database, and it's implied when the SPVID is associated with a specific incoming port. 🔥
4.6. Data Path SPBV Unicast 🦋
When a packet for a known DA arrives at an SPBV UNI port, VID translation (or VID encapsulation for untagged Frames) happens with the corresponding SPVID for this VLAN and ingress bridge. 🫶
Since the SPVID has been configured to follow a source-specific SPT and the DA is known, the packet follows the source-specific path toward the destination C-MAC. 👑
The ingress check is the same as in the previous SPBV section. 💜
4.7. Data Path SPBV Multicast 🌈
C-DA multicast addresses May be advertised from SPBV UNI ports. They can be configured or learned through the Multiple MAC Registration Protocol (MMRP). MMRP is terminated at the edge of the SPBV network, and IS-IS carries the multicast addresses. Tandem SPBV devices check whether they're on the SPF tree between SPBV UNI ports advertising the same C-DA multicast address. If they are, they install multicast state to follow the SPBV SPF trees. 🧚♀️
The ingress check is the same as in the previous two SPBV sections. 🎀
5. SPBM Example ✨
Consider the small example network in Figure 2. Nodes are drawn in boxes, and the last nibble of their B-MAC address is :1..:7. The rest of the B-MAC address nibbles are 4455-6677-00xx. Links are drawn as "--" and "/", the interface indexes are drawn as numbers next to the links, and UNI ports are shown as "<==>" with the desired I-SID shown at the end of the UNI ports as "i1". 🍓
+----+ +----+
| :4 | 2 ------1 | :5 | <==> i1
+----+ +----+
1 3 3 2
/ \ / \
1 4 3 2
+----+ +----+ +----+
i1 <==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> i1
+----+ +----+ +----+
3 6 5 3
\ / \ /
3 2 1 2
+----+ +----+
| :6 | 1-------3 | :7 | <==> i1
+----+ +----+
Figure 2: SPBM Example 7-Node NetworkUsing the default ECT-ALGORITHM (00-80-C2-01), which picks the equal cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned to B-VID 100. When all links have the same cost, the 1-hop shortest paths are all direct, and the 2-hop shortest paths (which are of course symmetric) are these:
{ 1-2-3, 1-2-5, 1-2-7, 6-2-5,
4-2-7, 4-1-6, 5-2-7, 6-2-3, 4-2-3 }So node :1's unicast forwarding table routes toward B-MACs :7, :3, and :5 via interface/2, and its single-hop paths are all direct, as you can see from its FDB in Figure 3. 💖
Node :1 originates multicast since it's at the head of the MDT to nodes :3, :5, and :7, and it's a transmitter of I-SID 1, which nodes :3, :5, and :7 all want to receive. So node :1 produces a multicast forwarding entry whose DA contains its SPSourceID (which is the last 20 bits of the B-MAC in this example) and I-SID 1. After that, node :1 sends packets matching this entry out to interface if/2 with B-VID=100. Node :1's full unicast (U) and multicast (M) table is in Figure 3. 🌸
Note that the IN/IF (incoming interface) field isn't specified for unicast traffic. For multicast traffic, it has to point back to the root of the tree, unless the node is the head of the tree, in which case we use the convention if/00. Since node :1 isn't transit for any multicast, it only has a single entry for the root of its tree for I-SID=1. 🙈
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
U| if/** | 4455-6677-0002 | 0100 | {if/2 }
U| if/** | 4455-6677-0003 | 0100 | {if/2 }
U| if/** | 4455-6677-0004 | 0100 | {if/1 }
U| if/** | 4455-6677-0005 | 0100 | {if/2 }
U| if/** | 4455-6677-0006 | 0100 | {if/3 }
U| if/** | 4455-6677-0007 | 0100 | {if/2 }
M| if/00 | 7300-0100-0001 | 0100 | {if/2 }
Figure 3: SPBM Node :1 FDB - Unicast (U) and Multicast (M)Node :2 sits at the center of the network and has direct 1-hop paths to all other nodes. So its unicast FDB just sends packets with the given B-MAC/B-VID=100 out the interface directly to the addressed node. You can see this in the unicast entries (the first 6) in Figure 4. 🦋
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
U| if/** | 4455-6677-0001 | 0100 | {if/1 }
U| if/** | 4455-6677-0003 | 0100 | {if/2 }
U| if/** | 4455-6677-0004 | 0100 | {if/4 }
U| if/** | 4455-6677-0005 | 0100 | {if/3 }
U| if/** | 4455-6677-0006 | 0100 | {if/6 }
U| if/** | 4455-6677-0007 | 0100 | {if/5 }
M| if/01 | 7300-0100-0001 | 0100 | {if/2,if/3,if/5 }
M| if/02 | 7300-0300-0001 | 0100 | {if/1 }
M| if/03 | 7300-0500-0001 | 0100 | {if/1,if/5 }
M| if/05 | 7300-0700-0001 | 0100 | {if/1,if/3 }
Figure 4: SPBM Node :2 FDB Unicast (U) and Multicast (M)Node :2's multicast is a bit more complicated, since it's a transit node for the 4 members of I-SID=1. That means it needs 4 multicast FDB entries, depending on which member it's forwarding or replicating on behalf of. For example, node :2 is on the shortest path between each of nodes {:3, :5, :7} and :1. So it has to replicate from node :1's I-SID 1 out on interfaces { if/2, if/3 and if/5 } (to reach nodes :3, :5, and :7). It therefore creates a multicast DA with the SPSourceID of node :1 together with I-SID=1, which it expects to receive over interface/1 and will replicate out interfaces { if/2, if/3 and if/5 }. You can see this in the first multicast entry in Figure 4. 💜
Note that node :2 is not on the shortest path between nodes :3 and :5, nor between nodes :3 and :7. It still has to forward packets to node :1 from node :3 for this I-SID, though, and that's what produces the second multicast forwarding entry in Figure 4. Likewise, for packets originating at nodes :5 or :7, node :2 only has to replicate twice, which gives the last two multicast forwarding entries in Figure 4. 🧚
6. SPBV Example 💅
okay so we're using the same network as Figure 2 🦋 and now we look at the FDBs for SPBV mode forwarding. nodes :1, :5, :3, and :7 all want to transmit and receive the same multicast MAC traffic at multicast address 0300-0000-000f, and at the same time they need congruent and symmetric unicast forwarding. ngl that's so main character ✨ in SPBV mode the only encapsulation is the C-TAG or S-TAG, and the SA and DA MAC addresses are reverse-path learned, same as traditional bridging 🌸
+----+ +----+
| :4 | 2 ------1 | :5 | <==> MMAC ..:f
+----+ +----+
1 3 3 2
/ \ / \
1 4 3 2
+----+ +----+ +----+
MMAC<==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> MMAC ..:f
..:f +----+ +----+ +----+
3 6 5 3
\ / \ /
3 2 1 2
+----+ +----+
| :6 | 1-------3 | :7 | <==> MMAC ..:f
+----+ +----+
Figure 5: SPBV Example 7-Node NetworkAssuming the same ECT-ALGORITHM (00-80-C2-01), which picks the equal cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned to Base VID 100, and for each node the SPVID = Base VID + Node ID (i.e., 101, 102..107). when all links have the same cost, the 1-hop shortest paths are all direct, and the 2-hop shortest paths (which are of course symmetric) are the same as previously given for Figure 2 💖
Node :1's SPT for this ECT-ALGORITHM is therefore (described as a sequence of unidirectional paths):
{ 1->4, 1->6, 1->2->3, 1->2->5, 1->2->7 }The FDBs therefore must have entries for the SPVID reserved for packets originating from node :1, which in this case is VID=101 🎀
Node :2 therefore has an FDB that looks like Figure 6 🧚 in particular, it takes packets from VID 101 on interface/01 and sends them to nodes :3, :5, and :7 via if/2, if/3, and if/5. it does NOT replicate anywhere else, because the other nodes (:4 and :6) are reached by the SPT directly from node :1. the rest of the FDB unicast entries follow a similar pattern. recall that the shortest path between :4 and :6 is via node :1, which explains the replication onto only two interfaces from if/4 and if/6 🍓 also the destination addresses are wild cards, and SVL exists between these SPVIDs because they're all associated with Base VID = 100, which defines the VLAN being bridged 🫶
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | VID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
U| if/01 | ************** | 0101 | {if/2,if/3,if/5 }
U| if/02 | ************** | 0103 | {if/1,if/4,if/6 }
U| if/04 | ************** | 0104 | {if/2,if/5 }
U| if/03 | ************** | 0105 | {if/1,if/5,if/6 }
U| if/06 | ************** | 0106 | {if/2,if/3 }
U| if/05 | ************** | 0107 | {if/1,if/3,if/4 }
Figure 6: SPBV Node :2 FDB UnicastNow, since nodes :5, :3, :7 and :1 are advertising membership in the same multicast group address :f, Node 2 needs additional entries to replicate just to these specific nodes for the given multicast group address 🔥 these extra multicast entries are in Figure 7 below 👑
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | VID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
M| if/01 | 0300-0000-000f | 0101 | {if/2,if/3,if/5 }
M| if/02 | 0300-0000-000f | 0103 | {if/1 }
M| if/03 | 0300-0000-000f | 0105 | {if/1,if/5 }
M| if/05 | 0300-0000-000f | 0107 | {if/1,if/3 }
Figure 7: SPBV Node :2 FDB Multicast (M)7. SPB Supported Adjacency types 🌈
okay so IS-IS for SPB only supports peer-to-peer adjacencies for now 🦋 other link types are for future study. which means pseudonodes and links to/from pseudonodes are NOT part of the IS-IS SPF computations, and they'll get avoided if they're present in the physical topology 💀 other NLPIDs MAY of course use them as per normal ✨
IS-IS for SPB Must use the IS-IS three-way handshake for IS-IS point-to-point adjacencies described in RFC 5303 💅
8. SPB IS-IS Adjacency Addressing 🎀
so the default behavior of 802.1aq is to use the normal IS-IS Ethernet multicast addresses for IS-IS 🌸
there are however additional Ethernet multicast addresses that have been assigned for 802.1aq for special use cases 🧚 these don't change the state machinery or packet formats of IS-IS in any way. they just recommend and reserve different multicast addresses. iykyk, go to [802.1aq] for the extra details 🫶
9. IS-IS Area Address and SYSID 🦋
a stand-alone implementation (supporting ONLY the single NLPID=0xC1) of SPB Must use an IS-IS area address value of 0, and the SYSID Must be the well-known MAC address of the SPB device 💖
non-stand-alone implementations (supporting other NLPIDs) MUST use the normal IS-IS rules for establishing a level 1 domain. that means multiple area addresses are allowed ONLY where immediate adjacencies share a common area address 👑 level 2 operations of course place no such restriction on adjacent area addresses ✨
10. Level 1/2 Adjacency 🍓
SPBV and SPBM will operate within either an IS-IS level 1 or level 2 🌈 as a result, the TLVs specified here MAY propagate in either level 1 or level 2 LSPs. IS-IS SPB implementations Must support level 1, and May support level 2 operations. hierarchical SPB is for further study, so these TLVs Should Not be leaked between level 1 and level 2 🙈
11. Shortest Path Default Tie-Breaking 💜
the default algorithm is ECT-Algorithm = 00-80-c2-01 ✨
two mechanisms are used to make sure things are symmetric and deterministic in the shortest path calculations 🔥
the first mechanism deals with the problem where different ends (nodes) of an adjacency advertise different values for the SPB-LINK-METRIC. to fix this, SPB shortest path calculations Must use the maximum value of the two nodes' advertised SPB-LINK-METRICs when accumulating and minimizing the (sub)path costs 💅
the second mechanism deals with the problem where two equal sums of link metrics (sub)paths are found. to fix this, the (sub)path with the fewest hops between the fork/join points Must win the tie. however, if both (sub)paths have the same number of hops between the fork and join points, then the default tie-breaking Must pick the path traversing the intermediate node with the lower BridgeID. the BridgeID is an 8-byte quantity whose upper 2 bytes are the node's BridgePriority and whose lower 6 bytes are the node's SYSID 🦋
for example, consider the network in Figure 2 when a shortest path computation is being done from node :1. upon reaching node :7, two competing sub-paths fork at node :1 and join at node :7: the first goes via :2 and the second goes via :6. assuming all the nodes advertise a Bridge Priority of 0, the default tie-breaking rule means the path traversing node :2 gets selected, since it has a lower BridgeID {0...:2} than node :6 {0...:6}. note that the operator may make the tie-breaking logic pick the alternate path by raising the Bridge Priority of node :2 above that of node :6 🧚
the above algorithm guarantees symmetric and deterministic results, plus it has the critical property of transitivity (a shortest path is made up of sub-shortest paths) 🎀
12. Shortest Path ECT 🌸
standard ECT Algorithms were initially proposed, ranging from 00-80-c2-01 to 00-80-c2-10 ✨
to create diversity in routing, SPB defines 16 variations on the above default tie-breaking algorithm 💖 these have worldwide unique designations 00-80-C2-01 through 00-80-C2-10. these designations are made of the IEEE 802.1 OUI (Organizationally Unique Identifier) value 00-80-C2 concatenated with indexes 0X01..0X10. these individual algorithms are implemented by selecting the (sub)path with the lowest value of:
XOR BYTE BY BYTE(ECT-MASK{ECT-ALGORITHM.index},BridgeID)where:
ECT-MASK{17} = { 0x00, 0x00, 0xFF, 0x88,
0x77, 0x44, 0x33, 0xCC,
0xBB, 0x22, 0x11, 0x66,
0x55, 0xAA, 0x99, 0xDD,
0xEE };XOR BYTE BY BYTE means XORing the BridgeID bytes with the ECT-MASK 🫶
ECT-MASK{1}, since it XORs with all zeros, yields the default algorithm described above (00-80-C2-01). ECT-MASK{2}, since it XORs with a mask of all ones, inverts the BridgeID, which essentially picks the path traversing the largest Bridge ID 😭 the other ECT-MASKs produce diverse alternatives. in every case, the BridgePriority is the most significant part of the BridgeID, so it permits overriding the SYSID as the selection criteria and gives the operator a degree of control over the chosen ECT paths 👑
to support many other tie-breaking mechanisms in the future, two opaque ECT TLVs are defined, which may be used to provide parameters to ECT-ALGORITHMs outside of the currently defined space 🌈
ECT-ALGORITHMs are mapped to VIDs, and then services can be assigned to those VIDs. this permits a degree of traffic engineering, since service assignment to a VID is consistent end to end through the network 💅
13. Hello (IIH) Protocol Extensions 🦋
IEEE 802.1aq can run in parallel with other network layer protocols such as IPv4 and IPv6. therefore, failure of two SPB nodes to establish an adjacency MUST NOT cause rejection of an adjacency for the purposes of other network layer protocols 🍓
IEEE 802.1aq has been assigned the NLPID value 0xC1 [RFC6328], which MUST be used by Shortest Path Bridges (SPBs) to indicate their ability to run 802.1aq. this is done by including this NLPID value in the IS-IS IIH PDU Protocols Supported TLV (type 129). 802.1aq frames MUST only flow on adjacencies that advertise this NLPID in both directions of the IIH PDUs. 802.1aq computations MUST consider an adjacency that has NOT advertised the 0xC1 NLPID in both directions as non-existent (infinite link metric), and they MUST ignore any IIH SPB TLVs they receive over such adjacencies 🙈
IEEE 802.1aq augments the normal IIH PDU with three new TLVs. like all other SPB TLVs, they travel within Multi-Topology [MT] TLVs, which allows multiple logical instances of SPB within a single IS-IS protocol instance 🌸
since SPB can use many VIDs and Must agree on which VIDs are used for which purposes, the IIH PDUs carry a digest of all the used VIDs (on the NNIs), referred to as the SPB-MCID TLV. it uses a common and compact encoding reused from 802.1Q ✨
SPB neighbors May support a mechanism to verify that the contents of their topology databases are synchronized (for loop prevention purposes). this is done by exchanging a digest of SPB topology information (computed over all MT IDs) and taking specific actions on forwarding entries when the digests indicate a topology mismatch. this digest is carried in the Optional SPB-Digest sub-TLV 💖
finally, SPB needs to know which SPT Sets (defined by ECT-ALGORITHMs) are being used by which VIDs, and this is carried in the Base VLAN Identifiers (SPB-B-VID) sub-TLV 🧚
13.1. SPB-MCID Sub-TLV 🎀
okay so this sub-TLV gets added to an IIH PDU to show the digest for the multiple spanning tree configuration, a.k.a. the MCID 💅 It's a digest of your local config, meaning which VIDs are running which protocols. (It's not down to a specific algorithm for SPB, so it's coarser than that 🙈) This info MUST be the same on all bridges in the SPT Region controlled by an IS-IS instance. The MCID gets built from config, and it's basically a digest of the VIDs allocated to different protocols. You get two MCIDs so you can switch between configs without disruption when the changes are non-critical ✨
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=SPB-MCID | = 4
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCID (51 Bytes) |
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aux MCID (51 Bytes) |
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: sub-TLV type 4 🌸
- Length: The size of the value defined below (102) 🌸
- MCID (51 bytes): This is the complete MCID defined in IEEE 802.1Q, and it identifies an SPT Region based on matching assignments of VIDs to control regimes (xSTP, SPBV, SPBM, etc.). Quick breakdown: the MCID is a 1-byte format selector, a 32-byte configuration name, a 2-byte revision level, and then a 16-byte signature of type HMAC-MD5 over an array of 4096 elements that hold identifiers for how each corresponding VID is used. For the exact format and procedure, see Section 13.8 of [802.1aq]. Also, the use of the VID doesn't specify a particular SPB ECT-ALGORITHM. It's coarser grain, bestie 🫶
- Aux MCID (51 bytes): This is the complete MCID defined in IEEE 802.1Q, and it identifies an SPT Region. The aux MCID is the glow-up that lets SPT Regions migrate by allocating new VLAN to FDB Mappings without interrupting existing traffic 🦋
The SPB-MCID sub-TLV is carried within the MT-Port-Cap TLV [RFC6165] with the MT ID value of 0, and that TLV rides inside an IIH PDU 💜
13.2. SPB-Digest Sub-TLV 🔥
this sub-TLV is optionally added to an IIH PDU to show the current SPB topology digest value. It's always carried in an MT-Port-Cap TLV [RFC6165] with an MT ID value of 0. This info should settle to be the same on all bridges in an unchanging topology. Matching digests mean (with extremely high probability) that the topology view between two SPBs is synced, and that match (or lack of one) is what controls updating forwarding info. The SPB Agreement Digest is computed from contributions based on the current topologies of all SPB MT instances, and it's designed to change when significant topology changes happen within any SPB instance 😭
During LSP propagation, the Agreement Digest can vary between neighbors until the key topology info in the LSPs is common. So the digest is a summarised way of checking agreement between nodes on database commonality, and therefore of inferring agreement on the distance to all multicast roots. When it's present, it's used for loop prevention like this: for each shortest path tree where the distance to the root has changed, "unsafe" multicast forwarding is blocked until the exchanged Agreement Digests match. Meanwhile "safe" multicast forwarding keeps going even if the digests (and so the topology views) disagree. Section 28.2 of [802.1aq] spells out exactly what counts as "safe" vs. "unsafe" 👑
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=SPB-Digest| = 5
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-----+-+---+---+
| Res |V| A | D | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agreement Digest (Length - 1) |
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: sub-TLV type 5 🌸
- Length: The size of the value. 🌸
- V bit: Agreed digest valid bit. See Section 28.2 of [802.1aq]. ✨
- A (2 bits): The Agreement Number 0-3, which lines up with the BPDU's Agreement Number concept [802.1aq]. When this node's Agreement Digest changes, this number goes up. The node then checks for an Agreement Digest match (more on that below). The new local Agreement Number and the updated local Discarded Agreement Number then get sent along with the new Agreement Digest to the node's neighbors in the Hello PDU. Once an Agreement Number has been sent, it's considered outstanding until a matching or more recent Discarded Agreement Number comes back from the neighbor 💅
- D (2 bits): The Discarded Agreement Number 0-3, which also lines up with the BPDU's Agreement Number concept. When an Agreement Digest comes in from a neighbor, this number gets set to the received Agreement Number, which signals that this node has received the new agreement and discarded any previous ones. The node then checks whether the local and received Agreement Digests match. If they do, this node sets:
the local Discarded Agreement Number = received Agreement Number + 1If the Agreement Digests match, AND received Discarded Agreement Number ==
local Agreement Number + N (N = 0 || 1)then the node has a topology matched to its neighbor 🦋
Whenever the local Discarded Agreement Number for a neighbor changes, the local Agreement Digest, Agreement Number, and Discarded Agreement Number all get transmitted 🫶
- Agreement Digest: This digest is used to figure out when SPB is synced between neighbors for all SPB instances. It's a hash computed over the set of all SPB adjacencies in all SPB instances. In other words, the digest includes all VIDs and all adjacencies for all MT instances of SPB (but not other network layer protocols). This reflects the fact that all SPB nodes in a region MUST have identical VID allocations (see Section 13.1), so all SPB instances will contain the same set of nodes. The exact procedure for computing the Agreement Digest and its size are defined in Section 28.2 of [802.1aq] 🌈
The SPB-Digest sub-TLV is carried within the MT-Port-Cap TLV [RFC6165] (with the MT ID value 0), which rides inside an IIH PDU 💜
When it's supported, this sub-TLV MUST be carried on every IIH between SPB neighbors, not just when a Digest changes. ⭐
When one peer supports this TLV and the other doesn't, loop prevention by Agreement Digest MUST NOT be done by either side. 🙈
13.3. SPB Base VLAN Identifiers (SPB-B-VID) Sub-TLV 🧚
this sub-TLV gets added to an IIH PDU to show the mappings between ECT algorithms and Base VIDs that are in use. (The VID(s) used on the forwarding path for each SPT Set for a VLAN identified by a Base VID are implied by this.) Under stable operational conditions, this info should be the same on all bridges in the topology identified by the MT-Port-Cap TLV [RFC6165] it's carried within 🍓
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= SPB-B-VID| = 68
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-----------------------------------------------+
| ECT-VID Tuple (1) (6 bytes) |
+---------------------------------+-----------------------------+
| ... | ECT-VID Tuple(2) (6 bytes) |
+---------------------------------+-----------------------------+
| ..... |
+---------------------------------------------------------------+
| ..... |
| ..... |
+---------------------------------------------------------------+- Type: sub-TLV type 6 🌸
- Length: The size of the value is ECT-VID Tuples*6 bytes. Each 6-byte part of the ECT-VID tuple is formatted as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT-ALGORITHM (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base VID (12 bits) |U|M|RES|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ECT-ALGORITHM (4 bytes): The ECT-ALGORITHM is advertised when the bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given Base VID. There are 17 predefined IEEE algorithms for SPB with index values 0X00..0X10 occupying the low 8 bits, and the IEEE OUI=00-80-C2 occupies the top 24 bits of the ECT-ALGORITHM 🦋
- Base VID (12 bits): The Base VID that's associated with the SPT Set. 💖
- Use-Flag (1 bit): The Use-Flag is set if this bridge, or any bridge in the LSDB, is currently using this ECT-ALGORITHM and Base VID. Remote usage gets discovered by inspecting the U bit in the SPB-Inst sub-TLV of other SPB bridges (see Section 14.1) 👀
- M bit (1 bit): The M bit shows whether this Base VID operates in SPBM (M = 1) or SPBV (M = 0) mode. 🍓
The SPB-B-VID sub-TLV is carried within the MT-Port-Cap TLV [RFC6165], which rides inside an IIH PDU 💜
14. Node Information Extensions ✨
All SPB nodal information extensions travel within a new multi-topology capability TLV, MT-Capability (type 144). 👑
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 = MT-CAP | = 144
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O R R R| MT ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(sub-TLVs ... )The format of this TLV is identical in its first 2 bytes to all current MT TLVs, and it carries the MT ID as defined in [MT]. 🫶
The O (overload) bit, sitting in bit 16, has the same semantics as specified in [MT], but only in the context of SPB adjacencies. 🌸
There can be multiple MT-Capability TLVs present, depending on how much information needs to be carried. 🧚
14.1. SPB Instance (SPB-Inst) Sub-TLV 💖
Okay so the SPB-Inst sub-TLV is how a node shares its SPSourceID for a given node/topology instance ✨. That's the 20-bit value used to build the multicast DAs for frames starting out at this node/instance 🦋. The SPSourceID lives in the upper 20 bits of the multicast DA, with 4 other bits riding along (check the SPBM 802.1ah multicast DA address format section for the full picture 💅). This sub-TLV MUST be carried within the MT-Capability TLV in the fragment ZERO LSP. If there's an additional SPB instance, it MUST be declared under its own separate MT-Capability TLV, and that one also gets carried in the fragment ZERO LSP 🎀.
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 = SPB-Inst| = 1
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST Root Identifier (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST Root Identifier (cont) (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST External Root Path Cost (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bridge Priority | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R R R R R R R R|V| SPSourceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Trees | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID (1) Tuples (8 bytes) |
| ........................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...........................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID (N) Tuples (8 bytes) |
| ........................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Where the VLAN-ID tuples look like this 🧁:
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
+-+-+-+-+-+-+-+-+
|U|M|A| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT-ALGORITHM (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base VID (12 bits) | SPVID (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field rundown 📋:
- Type: sub-TLV type 1.
- Length: the total number of bytes contained in the value field.
- CIST Root Identifier (64 bits): this one's for SPB interworking with Rapid STP (RSTP) and Multiple STP (MSTP) at SPT Region boundaries. It's an imported value from a spanning tree 🌳.
- CIST External Root Path Cost (32 bits): the cost to root, derived from the spanning tree algorithm.
- Bridge Priority (16 bits): the 16 bits that, together with the 6 bytes of the System ID, form the Bridge Identifier. This lets SPB build a compatible spanning tree using link state by combining the Bridge Priority and the System ID into the 8-byte Bridge Identifier. That 8-byte Bridge Identifier is also the input to the 16 predefined ECT tie-breaker algorithms 🔥.
- V bit (1 bit): the V bit (SPBM) shows this SPSourceID is auto-allocated (Section 27.11 of [802.1aq]). If the V bit is clear, the SPSourceID has been configured and Must be unique. SPSourceID allocation is defined in IEEE [802.1aq]. Bridges running SPBM will allocate an SPSourceID if they aren't configured with an explicit one. The V bit lets neighbour bridges tell whether auto-allocation was turned on. In the rare event of an SPsourceID allocation collision, the bridge with the highest priority Bridge Identifier wins the conflict. The lower priority bridge gets re-allocated or, if it's configured, it isn't allowed to join the SPT Region 🙈.
- SPSourceID: a 20-bit value used to construct multicast DAs, as described below, for multicast frames originating from the origin (SPB node) of the Link State Packet (LSP) that contains this TLV. More details are in IEEE [802.1aq].
- Number of Trees (8 bits): the Number of Trees is set to the number of {ECT-ALGORITHM, Base VID plus flags} tuples that follow. Each ECT-ALGORITHM has a Base VID, an SPVID, and flags, described below. This Must contain at least the one ECT-ALGORITHM (
00-80-C2-01) 🌈.
Each VID Tuple consists of:
- U bit (1 bit): the U bit is set if this bridge is currently using this ECT-ALGORITHM for I-SIDs it sources or sinks. This is a strictly local indication. Its semantics differ from the Use-Flag found in the Hello, which gets set if it sees other nodal U bits are set OR it sources or sinks itself 💜.
- M bit (1 bit): the M bit tells you whether this is SPBM or SPBV mode. When cleared, the mode is SPBV. When set, the mode is SPBM.
- A bit (1 bit): the A bit (SPB), when set, declares this is an SPVID with auto-allocation. The VID allocation logic details are in IEEE [802.1aq]. SPVIDs are allocated from a small pool of 12-bit resources, so collisions are very likely 😭. To cut down on collisions during auto-allocation, LSPs are first advertised with the originating bridge setting the SPVID to 0. Only after it has learned the other bridges' SPVID allocations does this bridge re-advertise this sub-TLV with a non-zero SPVID. That minimises the chance of a clash but doesn't eliminate it. If a clash happens, the highest Bridge Identifier picks the winner, and the loser(s) with lower Bridge Identifier(s) Must withdraw their SPVID allocation(s) and pick an alternative candidate for another trial. SPVID May also be configured. When the A bit is set to not specify auto-allocation and the SPVID is set to 0, this SPBV bridge is used for transit only within the SPB region. If a port is configured with the Base VID as a neighbour using RSTP or MSTP, the bridge acts as an ingress filter for that VID 🍓.
- ECT-ALGORITHM (4 bytes): ECT-ALGORITHM is advertised when the bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given VID. This declaration Must match the declaration in the Hello PDU originating from the same bridge. The ECT-ALGORITHM and Base VID Must match what's generated in the IIHs of the same node. The ECT-ALGORITHM, Base VID tuples can come in any order, though. There are currently 17 worldwide unique 802.1aq defined ECT-ALGORITHMs, given by values
00-80-C2-00through00-80-C2-10👑. - Base VID (12 bits): the Base VID that associated the SPT Set via the ECT-ALGORITHM.
- SPVID (12 bits): the SPVID is the Shortest Path VID assigned for the Base VID to this node when using SPBV mode. It isn't defined for SPBM mode and Must be 0 for SPBM mode B-VIDs.
14.1.1. SPB Instance Opaque ECT-ALGORITHM (SPB-I-OALG) Sub-TLV 🧚
Okay, so SPB has multiple ECT algorithms defined, but down the road more could show up, like ECMP- or hash-based behaviours and (*,G) multicast trees ✨. These algorithms will use this Optional TLV to define new algorithm parametric data. For tie-breaking parameters there are two broad classes of algorithm: one uses nodal data to break ties, and the other uses link data. This sub-TLV is used to attach opaque tie-breaking data to a node. When it's present, this sub-TLV MUST be carried within the MT-Capability TLV (along with a valid SPB-Inst sub-TLV). Multiple copies of this sub-TLV MAY be carried for different ECT-ALGORITHMs relating to this node 🦋.
There are of course lots of other uses for this opaque data that haven't been defined yet 🌸.
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=SPB-I-OALG| = 2
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT-ALGORITHM (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Information (variable) |
| ....................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: sub-TLV type 2.
- Length: the total number of bytes contained in the value field.
- ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given VID.
- ECT Information: ECT-ALGORITHM Information of variable length, which SHOULD be in sub-TLV format with an IANA numbering space where appropriate 🎀.
15. Adjacency Information Extensions 🌷
15.1. SPB Link Metric (SPB-Metric) Sub-TLV 🍭
The SPB-Metric sub-TLV (type 29) lives within the Multi-Topology Intermediate System Neighbor (MT-ISN) TLV (type 222) or within the Extended IS Reachability TLV (type 22). If this sub-TLV isn't present for an IS-IS adjacency, then that adjacency Must Not carry SPB traffic for the given topology instance 🙅♀️.
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=SPB-Metric| = 29
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPB-LINK-METRIC | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Ports | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Identifier | ( 2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: sub-TLV type 29.
- Length: the total number of bytes contained in the value field.
- SPB-LINK-METRIC: the administrative cost or weight of using this link, as a 24-bit unsigned number. This metric only applies to using this link for SPB traffic. Smaller numbers mean lower weights, so the link is more likely to carry SPB traffic. Only one metric is allowed per SPB instance per link. If you need multiple metrics, you must use multiple SPB instances, either within IS-IS or within several independent IS-IS instances. If this metric is different at each end of a link, the maximum of the two values Must be used in all SPB calculations for the weight of this link. The maximum SPB-LINK-METRIC value
2^24 - 1has special significance: it means that although the IS-IS adjacency has formed, incompatible values have been detected in parameters configured within SPB itself (for example, different regions), so the link Must Not be used for carrying SPB traffic. Full details are in [802.1aq] ⚠️. - Num of Ports: the number of ports associated with this link.
- Port Identifier: the standard IEEE port identifier used to build a spanning tree associated with this link.
15.1.1. SPB Adjacency Opaque ECT-ALGORITHM (SPB-A-OALG) Sub-TLV ✨
okay so there are multiple ECT algorithms defined for SPB right now 🦋, but more can be defined later, so this sub-TLV is built to handle that 💅. The SPB-A-OALG sub-TLV lives inside either the Multi-Topology Intermediate System TLV (type 222) or the Extended IS Reachability TLV (type 22). You can carry multiple copies of it, one per ECT-ALGORITHM related to the same adjacency, and that is totally allowed 🫶 (so we can say it's a MAY 💜).
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=SPB-A-OALG| = 30
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Algorithm (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Information (variable) |
| ......................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: sub-TLV type 30.
- Length: the total number of bytes in the value field.
- ECT-ALGORITHM: this gets advertised when the bridge supports a given ECT-ALGORITHM (identified by OUI/Index) on a given VID. 🌸
- ECT Information: the ECT-ALGORITHM Information, which is variable length and uses sub-TLV format with new IANA type values as needed. 🧚
16. Service Information Extensions 💖
16.1. SPBM Service Identifier and Unicast Address (SPBM-SI) Sub-TLV 🎀
the SPBM-SI sub-TLV (type 3) does two jobs 👑: it introduces service group membership on the node that originates it, and/or it advertises an extra B-MAC unicast address that's on the node or reachable through it.
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 = SPBM-SI | = 3
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-MAC ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-MAC ADDRESS (6 bytes) | Res. | Base VID (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | I-SID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | I-SID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | I-SID #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: sub-TLV type 3.
- Length: the total number of bytes in the value field.
- B-MAC ADDRESS: a unicast address of this node. It can be the single nodal address, or it can point at a port or any other level of granularity relative to the node. If the node only has one B-MAC address, this SHOULD be the same as the SYSID of the node. To add multiple B-MACs, this TLV MUST be repeated for each extra B-MAC. 🫶
- Base VID (12 bits): the Base VID tied to the B-BMAC is what links it to the ECT-ALGORITHM and SPT Set defined in the SPB-Inst sub-TLV. 🔥
- I-SID #1 .. #n: 24-bit service group membership identifiers. If two nodes share an I-SID, the intermediate nodes on the unique shortest path between them will create forwarding state for the related B-MAC addresses. They'll also build multicast forwarding state using the I-SID and the node's SPSourceID to construct a multicast DA, as described in IEEE 802.1aq LSB. Each I-SID has a Transmit (T) bit and a Receive (R) bit that show whether the membership is as a transmitter, a receiver, or both (both bits set). When both the T and R bits are zero, the I-SID instance gets ignored for distributed multicast computation, BUT the unicast B-MAC address MUST still be processed and installed at nodes providing transit to that address. 💅 If more I-SIDs are tied to one B-MAC than fit in a single sub-TLV, you repeat the sub-TLV with the same B-MAC and different I-SID values.
- Note: when the T bit is not set, an SPB MAY still multicast to all the other receiving members of this I-SID (the ones advertising with their R bits set). It does this by configuring edge replication and doing serial unicast to each member locally. 🦋
The SPBM-SI sub-TLV, when present, MUST be carried within the MT-Capability TLV, and it can show up multiple times in any LSP fragment. 🌈
16.2. SPBV MAC Address (SPBV-ADDR) Sub-TLV 🍓
the SPBV-ADDR sub-TLV is IS-IS sub-TLV type 4. It SHOULD be used to advertise Group MAC addresses in SPBV mode. Unicast MAC addresses usually get distributed by reverse-path learning, but putting them in this TLV isn't ruled out. 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=SPBV-ADDR| = 4 (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R| SR| SPVID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | MAC 1 Address | (1+6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | MAC N Address | (1+6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+- Type: sub-TLV type 4.
- Length: the total number of bytes in the value field. The number of MAC addresses tied to the SPVID is worked out as (Length - 2)/7. 🎀
- SR bits (2 bits): the SR bits are the service requirement parameter from MMRP. The MMRP service requirement parameters have the value 0 (Forward all Groups) and 1 (Forward All Unregistered Groups) defined. The attribute MAY also be missing, though, so the SR bits are defined as: 0 not declared, 1 Forward all Groups, and 2 Forward All Unregistered Groups. The two 'R' reserved bits right before these SR bits SHALL be set to zero when this sub-TLV is originated, and SHALL be ignored on receipt. 💜
- SPVID (12 bits): the SPVID, and by extension the Base VID, the ECT-ALGORITHM, and the SPT Set that the MAC addresses below will use. If the SPVID isn't allocated, the SPVID value is 0. Also, if the ECT-ALGORITHM in use is the spanning tree algorithm, this value MUST be populated with the Base VID, and the MAC MUST be populated too. 👑
- T bit (1 bit): this is the Transmit allowed bit for a following Group MAC address. It tells you that the Group MAC address, in the context of the SPVID of the advertising bridge, MUST be installed in the FDB of transit bridges. That happens when the bridge computing the trees is on the matching ECT-ALGORITHM shortest path between the advertising bridge (with the T bit set) and any receiver of this Group MAC address. A bridge that does NOT advertise this bit set for a MAC address MUST NOT cause multicast forwarding state to be installed on other transit bridges in the network for traffic coming from that bridge. 🚫
- R bit (1 bit): this is the Receive allowed bit for the following MAC address. It indicates that MAC addresses acting as receivers MUST be populated and installed when the bridge computing the trees sits on the matching shortest path for this ECT-ALGORITHM, between this receiver and any transmitter to this MAC address. An entry without this bit set for a Group MAC address is blocked from receiving on that Group MAC address, because transit bridges MUST NOT install multicast forwarding state towards it in their FDBs. 🛑
- MAC Address (48 bits): the MAC address declares this bridge as part of the multicast interest for this destination MAC address. Multicast trees can be built efficiently for a destination by populating FDB entries for the subset of the shortest path tree that connects the bridges supporting the MAC address. This replaces the function of MMRP for SPTs. ✨ The T and R bits above mean what's specified above.
The SPBV-ADDR sub-TLV, when present, MUST be carried within the MT-Capability TLV, and it can occur multiple times in any LSP fragment. 🌸
17. Security Considerations 🔐
This document adds no additional security risks to IS-IS, and it doesn't add any extra security to IS-IS either when it's used in a configured environment or a single-operator domain, like a data center. 🏢
BUT this protocol can be used in a zero-configuration environment 🚨. Zero configuration might apply to the automatic detection and forming of an IS-IS adjacency (which creates an NNI port). It might also apply to automatic detection of VLAN-tagged traffic and forming a UNI port, with the resulting I-SID advertisements.
If zero configuration methods get used to autoconfigure NNIs or UNIs, there are intrinsic security concerns that should be mitigated with authentication procedures for the cases above. Those procedures are beyond the scope of this document and haven't been defined yet. 😬
Also, this protocol can create a LOT of multicast state when an I-SID is advertised with the T bit set. Extra care should be taken to make sure this can't be used in a denial-of-service attack [RFC4732] in a zero-configuration environment. 💀🔥
18. IANA Considerations ✨
okay so first things first, bestie 🎀 the NLPID value 0xC1 [RFC6328] that shows up in the IIH PDUs is already taken care of! IANA assigned it for 802.1aq ages ago, so there is literally no further action is required for that code point 💅
Now, 802.1aq lives inside the IS-IS Multi-Topology framework 🌈 so every sub-TLV MUST occur in the context of the proper MT TLV. The one exception is the SPB-Metric sub-TLV, which MAY travel in TLV 22, where its MT ID isn't specified but is implied to be 0 🦋 IANA handed out sub-TLVs for three Multi-Topology TLVs for 802.1aq: MT-Port-Cap [RFC6165] (used in the IIH), the brand-new MT-Capability TLV (used in the LSP), and MT-ISN [MT] (used to hold adjacency info in the LSP) ✨
This document creates the TLVs and sub-TLVs for the IIH and LSP PDU MT TLVs shown below. The '*' marks new IANA assignments from this document, and everything else is just there for context 🧚
The MT-Capability TLV is the only one that needed a brand-new sub-registry 👑 It got Type value 144, starts its sub-TLV values at 1, and is managed by Expert Review 💜
+-----+----+-----------------+--------+------+-------------+
| PDU |TLV | SUB-TLV | TYPE | TYPE | #OCCURRENCE |
+-----+----+-----------------+--------+------+-------------+
IIH
MT-Port-Cap 143
* SPB-MCID 4 1
* SPB-Digest 5 >=0
* SPB-B-VID 6 1
LSP
* MT-Capability 144 >=1
* SPB-Inst 1 1
* SPB-I-OALG 2 >=0
* SPBM-SI 3 >=0
* SPBV-ADDR 4 >=0
MT-ISN 222
or Extended IS Reachability 22
* SPB-Metric 29 1
* SPB-A-OALG 30 >=019. References 📚
19.1. Normative References 💖
- [802.1aq] "Standard for Local and Metropolitan Area Networks: Virtual Bridges and Virtual Bridged Local Area Networks - Amendment 9: Shortest Path Bridging", IEEE P802.1aq, Draft 4.6, 2012.
- [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002.
- [MT] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
- [RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer Protocol Identifiers", BCP 164, RFC 6328, July 2011.
19.2. Informative References 🌸
- [802.1ag] "Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Amendment 5: Connectivity Fault Management", IEEE STD 802.1ag, 2007.
- [MMRP] "Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks - Amendment 07: Multiple Registration Protocol", IEEE STD 802.1ak, 2007.
- [PB] "Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Amendment 4: Provider Bridges", IEEE STD 802.1ad, 2005.
- [PBB] "Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Amendment 7: Provider Backbone Bridges", IEEE STD 802.1ah, 2008.
- [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
- [Y.1731] ITU-T, "OAM Functions and Mechanisms for Ethernet based networks", ITU-T Y.1731, 2006.
20. Acknowledgments 🫶
huge thank-you energy going out to Ayan Banerjee, Mick Seaman, Janos Farkas, Les Ginsberg, Stewart Bryant , Donald Eastlake, Matthew Bocci and Mike Shand 💜 they all contributed and/or gave detailed review, and that's iconic behaviour 👑
Authors' Addresses 💌
Don Fedyk (editor)
Alcatel-Lucent
Groton, MA 01450
USA
EMail: Donald.Fedyk@alcatel-lucent.com
Peter Ashwood-Smith (editor)
Huawei Technologies Canada Ltd.
303 Terry Fox Drive, Suite 400
Kanata, Ontario, K2K 3J1
CANADA
EMail: Peter.AshwoodSmith@huawei.com
Dave Allan
Ericsson
300 Holger Way
San Jose, CA 95134
USA
EMail: david.i.allan@ericsson.com
Nigel Bragg
Ciena Limited
Ciena House
43-51 Worship Street
London EC2A 2DX
UK
EMail: nbragg@ciena.com
Paul Unbehagen
Avaya
8742 Lucent Boulevard
Highlands Ranch, CO 80129
USA
EMail: unbehagen@avaya.com📦 where this page comes from
- ietf: rfc6329 2012-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms