RFC 7968
Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data
RFC 7968 📖💖
RFC 7968: Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data 🦋
- Authors: Y. Li, D. Eastlake 3rd, W. Hao, H. Chen (Huawei Technologies), and S. Chatterjee (Cisco) 👑
- Category: Standards Track ✨
- Date: August 2016 🎀
- ISSN: 2070-1721 🌸
- Obsoletes / Updates: this title block doesn't list any, so nothing is obsoleted or updated here 🙈
Abstract ✨
okay so TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames 🌈 and multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow 💅. different ingress RBridges may pick different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group, which is so iconic 👑
now, to avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address 🧚. but here's the tea 🫖: if any VLAN, FGL, or multicast group can be sent on any tree, then for typical fast-path hardware the amount of pruning information gets multiplied by the number of trees, and there's only limited hardware capacity for that pruning information 😭
so this document specifies an optional facility to restrict the TRILL Data packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups 🦋. that means way less total pruning information, so it can actually fit into fast-path hardware. main character energy 💖
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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. 🎀
Info about the current status of this document, any errata, and how to send feedback on it can be found at http://www.rfc-editor.org/info/rfc7968. 🌸
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) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 🫶
Table of Contents 🧾
1. Introduction ....................................................3
1.1. Background Description .....................................3
1.2. Terminology Used in This Document ..........................4
2. Motivations .....................................................5
3. Tree Selection Based on Data Labels .............................9
3.1. Overview of the Mechanism ..................................9
3.2. APPsub-TLVs Supporting Tree Selection .....................10
3.2.1. The Tree and VLANs APPsub-TLV ......................11
3.2.2. The Tree and VLANs Used APPsub-TLV .................12
3.2.3. The Tree and FGLs APPsub-TLV .......................12
3.2.4. The Tree and FGLs Used APPsub-TLV ..................13
3.2.5. The Tree and Groups APPsub-TLV .....................13
3.2.6. The Tree and Groups Used APPsub-TLV ................14
3.3. Detailed Processing .......................................14
3.4. Failure Handling ..........................................15
4. Backward Compatibility .........................................17
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................20
Acknowledgments ...................................................21
Authors' Addresses ................................................211. Introduction ✨
1.1. Background Description 🌷
so one or more distribution trees, identified by their root nicknames, are used to distribute multi-destination data in a (Transparent Interconnection of Lots of Links) (TRILL) campus [RFC6325] 🦋. the Routing Bridge (RBridge) with the highest tree root priority announces the total number of trees that should be computed for the campus 👑. it can also list the trees that RBridges need to compute, using the Tree Identifiers (TREE-RT-IDs) sub-TLV [RFC7176] 🧚.
every RBridge can say which trees it will use for multi-destination TRILL Data packets it originates, using the Trees Used Identifiers (TREE-USE-IDs) sub-TLV [RFC7176] 💅. the VLANs or Fine-Grained Labels (FGLs) [RFC7172] it cares about get specified in the Interested VLANs and/or Interested Labels sub-TLVs [RFC7176] 🎀.
by default, it's suggested that the ingress RBridge uses the distribution tree whose root is the closest [RFC6325] 🌸. the TREE-USE-IDs sub-TLV builds the RPF (Reverse Path Forwarding) check table, which is what RPF checking uses 🔥. the Interested VLANs and Interested Labels sub-TLVs are used for distribution tree pruning, and the multi-destination forwarding table with pruning information gets built from that RPF check table 🫶.
to reduce unnecessary link loads, each distribution tree should be pruned per VLAN/FGL, which cuts off branches with no potential receivers downstream, as specified in [RFC6325] ✨. pruning based on Layer 2 or Layer 3 multicast addresses is also possible 🌈.
⚠️ Defaults are provided, but how many trees get calculated, where the tree roots are located, and which tree or trees an ingress RBridge uses are all implementation dependent. Just so you know 🙈
so with TRILL getting more and more popular in data center networks 💖, there are some features we can explore for multi-destination frames in the data center use case 🍓. to get non-blocking data forwarding, a fat tree structure is often used 🦋. Figure 1 shows a typical data center network built on a fat tree structure 🧚. RB1 and RB2 are aggregation switches, and RB11 through RB14 are access switches 👑. it's a common practice to put the tree roots on the aggregation switches for efficient traffic transportation 💅. then all the ingress RBridges that are access switches end up equally distant from all the tree roots 🎀.
+-----+ +-----+
| RB1 | | RB2 |
+-----+ +-----+
/ | \\ / /|\
/ | \ \ / / | \
/ | \ \ / | \-----+
/ | \/ \ | |
/ | /\/ \| |
/ /---+---/ /\ |\ |
/ / | / \ | \ |
/ / | / \ | \ |
/ / | / \ | \ |
+-----+ +-----+ +-----+ +-----+
| RB11| | RB12| | RB13| | RB14|
+-----+ +-----+ +-----+ +-----+
Figure 1: TRILL Network Based on Fat Tree Structure1.2. Terminology Used in This Document 📚
this document uses the terminology from [RFC6325] and [RFC7172] 🎀. some of it gets repeated below for convenience, and there are a few extra terms too 💅:
- Campus: the name for a network using the TRILL protocol, in the same sense that a "bridged LAN" is the name for a network using bridging. in TRILL, the word "campus" has no academic implication 🏫 (no cap, it's not a school thing)
- Data Label: VLAN or FGL 🏷️
- ECMP: Equal-Cost Multipath [RFC6325] 🌊
- FGL: Fine-Grained Label [RFC7172] 🧵
- Interested Labels sub-TLV: short for "Interested Labels and Spanning Tree Roots sub-TLV" [RFC7176] 🌷
- Interested VLANs sub-TLV: short for "Interested VLANs and Spanning Tree Roots sub-TLV" [RFC7176] 🌸
- IPTV: "Television" (video) over IP 📺
- RBridge: an alternative name for a TRILL switch 🦋
- RPF: Reverse Path Forwarding 🔁
- TRILL: Transparent Interconnection of Lots of Links (or Tunneled Routing in the Link Layer) 🌈
- TRILL switch: a device implementing the TRILL protocol. sometimes called an RBridge 🧚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶. these are the words that make the rules rules, so keep an eye out for them 👀✨
2. Motivations 🌸
Okay so, bestie, picture the Figure 1 layout with the tree roots at RB1 and RB2. Now the ingress RBridge (say, RB11) finds more than one equal-cost closest tree root, RB1 and RB2 both. 😳 It has two ways to pick a root for multi-destination frames. It can choose one and only one as the distribution tree root, or it can use an ECMP-like algorithm to spread traffic across all the trees whose roots are the same distance away. Both have drama. 💅
- For the first option (one distribution tree root), using a single tree from each ingress RBridge can lead to uneven or inefficient link usage. If RB11 picks the tree rooted at RB1, the link between RB11 and RB2 never gets used for multi-destination frames that RB11 ingresses. Lowkey wasteful 💀
- For the second option (ECMP-like), ECMP-based tree selection makes the multicast forwarding table size grow linearly with the number of trees, as the next paragraph explains. 📈
A multicast forwarding table at an RBridge normally maps the key of (distribution tree nickname + VLAN) to an index into a list of ports used for multicast packet replication. When the RBridge does not prune the tree, the key is simply the tree nickname. 🦋
The key can also be the distribution tree nickname augmented by the FGL and/or Layer 2 or 3 multicast address, when the RBridge supports FGL and/or Layer 2 or 3 pruning information. ✨
For any RBridge RBn and each VLAN x: if RBn is in a distribution tree t that carries traffic in VLAN x, there will be an entry of (t, x, port list) in the multicast forwarding table on RBn. Typically each entry has a distinct combination of (tree nickname, VLAN) as its lookup key. If there are n such trees and m such VLANs, the multicast forwarding table size on RBn is n*m entries. If an FGL is used [RFC7172] and/or finer pruning is used (for example, VLAN + multicast group address is used for pruning), the value of m goes up. In a larger-scale data center, more trees are needed for better load-balancing, which pushes n up too. Either way, the number of table entries (i.e., n*m) climbs dramatically. 📊🔥
Figure 2's left-hand table shows an example of the multicast forwarding table on RB11 in the Figure 1 topology. It has two distribution trees in a campus using typical fast-path hardware. 👀
Before VLAN-Based After VLAN-Based
Tree Selection Tree Selection
+--------------+-----+---------+ +--------------+-----+---------+
|tree nickname |VLAN |port list| |tree nickname |VLAN |port list|
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 1 | | | tree 1 | 1 | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 2 | | | tree 1 | 2 | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | ... | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | 1999| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | 2000| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 4093| | | tree 2 | 2001| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 4094| | | tree 2 | 2002| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | 1 | | | tree 2 | ... | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | 2 | | | tree 2 | 4093| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | ... | | | tree 2 | 4094| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | 4093| |
+--------------+-----+---------+
| tree 2 | 4094| |
+--------------+-----+---------+
Figure 2: Multicast Forwarding Table
before and after Using VLAN-Based Tree SelectionThe number of entries is approximately 2*4K in this case. If four distribution trees are used in a TRILL campus and RBn has 4K VLANs with downstream receivers, it eats up 16K table entries. 😱 The size of fast-path TRILL multicast forwarding tables is typically limited by hardware, so table entries are a precious resource. 💎
In some implementations, the table is shared with Layer 3 IP multicast, for a total of 16K or 8K table entries. So we want to reduce the table size consumed by TRILL distribution trees as much as possible, while still keeping load-balancing across the trees. It's a balancing act, bestie 🤹♀️
In cases where blocks of consecutive VLANs or FGLs can be assigned to a tree, the multicast forwarding table could be greatly compressed if entries could have a Data Label value and mask, with the fast-path hardware doing longest prefix matching. But few, if any, fast-path implementations provide that logic. Rude 🙄
A straightforward way to ease the limited table entries problem is to not prune the distribution tree. However, this only works in restricted scenarios, for the following reasons:
- Not pruning wastes bandwidth for multi-destination packets. There is normally broadcast traffic, like ARP and unknown unicast, that can be pruned on a VLAN (or FGL) so it doesn't get sent down branches of a distribution tree where it isn't needed. Plus, if there's a lot of Layer 3 multicast traffic, no pruning could lead to a worst-case scenario where that user data gets unnecessarily flooded all over the campus. The volume of flooded data could be huge if apps like IPTV are supported. More precise pruning, such as pruning based on multicast groups, may be desirable here. 🌊
- Not pruning is only useful at pure transit nodes. Edge nodes always need to maintain the multicast forwarding table with the key of (tree nickname + VLAN (or FGL)), since the edge node needs to decide whether and how to replicate the frame to local access ports. Edge nodes are likely relatively low-end switches with a smaller shared table size, say 4K, available. 🥲
- Due to security concerns, VLAN-based (or FGL-based) traffic isolation is a basic requirement in some scenarios. No pruning may increase the risk of traffic leakage, and misbehaving RBridges may take advantage of that leakage. 🚨
Security check: no pruning can make traffic isolation leak, and a misbehaving RBridge can exploit that leak. Don't skip this one, bestie. 🔐
On top of the table size concern, some silicon doesn't currently support hashing-based tree nickname selection at the ingress RBridge. It commonly uses VLAN-based tree selection instead. If the control plane of the ingress RBridge maps the incoming VLAN x to a tree nickname t, the data plane will always use tree t for VLAN x multi-destination frames. An ingress RBridge like that may choose multiple trees for load-sharing, but it can use one and only one tree for each VLAN. If we make sure all ingress RBridges campus-wide only send VLAN x multi-destination packets on tree t, then no RBridge needs to store a multicast table entry with the key of (tree-other-than-t, x). Less storage, same vibes ✨
This document describes TRILL control-plane support for distribution tree selection based on a VLAN, FGL, and/or multicast address, all to reduce the multicast forwarding table size. It's compatible with the silicon implementations mentioned in the previous paragraph. Main character energy 👑
3. Tree Selection Based on Data Labels 🎀
Data Label tree selection (VLAN-based or FGL-based) can be used as a distribution tree selection mechanism, especially when the multicast forwarding table size is a concern. This section specifies that mechanism and how to extend it so tree selection can be based on multicast groups. 🧚
3.1. Overview of the Mechanism 💜
Okay, so here's how it works. The RBridge with the highest priority to be a tree root announces the tree nicknames and the Data Labels allowed on each tree. These announcements of the tree-to-Data-Label correspondence can be based on static configuration or on some predefined algorithm that's beyond the scope of this document. An ingress RBridge picks the tree-VLAN correspondence it wants to use from the list announced by the highest-priority tree root. It SHOULD NOT transmit VLAN x frames on tree y if the highest-priority tree root does not say that VLAN x is allowed on tree y. 🚫
If we make sure a particular VLAN is allowed on one and only one tree, we can keep the number of multicast forwarding table entries on any RBridge fixed at 4K maximum (or up to 16M in the case of an FGL). 🤯 Take Figure 1 as an example, where two trees are rooted at RB1 and RB2, respectively. The highest-priority tree root appoints tree 1 to carry VLAN 1-2000 and tree 2 to carry VLAN 2001-4094. With that announcement, every RBridge that understands it will not send VLAN 2001-4094 traffic on tree 1, and will not send VLAN 1-2000 traffic on tree 2. So no RBridge needs to store entries for tree 1 / VLAN 2001-4094 or tree 2 / VLAN 1-2000. 🙌 Figure 2 shows the multicast forwarding table on an RBridge before and after we use VLAN-based tree selection. The number of entries is reduced by a factor f, where f is the number of trees used in the campus. In this example, it drops from 2*4094 to 4094. This affects both transit nodes and edge nodes. The data-plane encoding does not change. 🦋✨
3.2. APPsub-TLVs Supporting Tree Selection ✨
okay so this is where it gets really fun 🎀 Six brand-new APPsub-TLVs live inside the TRILL GENINFO TLV [RFC7357], and they only show up in Extended Level 1 Flooding Scope (E-L1FS) FS-LSPs [RFC7780] 💅 The first four are basically finer-grained versions of the TREE-RT-IDs and TREE-USE-IDs sub-TLVs [RFC7176], so if you already know those, you're halfway there 🧚 The VLAN ones are in Sections 3.2.1 and 3.2.2. The highest-priority tree root uses them to announce which VLANs are allowed on each tree across the campus, and then an ingress RBridge uses them to say which tree-VLAN pairing it picked from that list 🫶 The FGL ones are in Sections 3.2.3 and 3.2.4 and do the exact same job, just with FGLs instead 🌸 And Sections 3.2.5 and 3.2.6 go even more specific, picking trees based on multicast groups instead of Data Labels 💜
Here's the whole cast at a glance:
New APPsub-TLVs Description
======================= =============
Tree and VLANs announcement by the highest-priority
tree root of the VLANs allowed per tree
Tree and VLANs Used tree-VLAN correspondence that an
ingress RBridge selects
Tree and FGLs announcement by the highest-priority
tree root of the FGLs allowed per tree
Tree and FGLs Used tree-FGL correspondence that an
ingress RBridge selects
Tree and Groups announcement by the highest-priority
tree root of the multicast groups
allowed on each tree
Tree and Groups Used tree and multicast group correspondence
that an ingress RBridge selects3.2.1. The Tree and VLANs APPsub-TLV
the RBridge that is the highest-priority tree root uses this one to announce the VLANs allowed on each tree 🌈 It's called the Tree and VLANs (TREE-VLANs) APPsub-TLV, and you can carry more than one of them. The same tree nickname can show up in several Tree-VLAN RECORDs, either inside one APPsub-TLV or spread across a bunch of them 💅 Here's the layout:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-VLAN RECORD (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-VLAN RECORD (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+and each Tree-VLAN RECORD looks like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's the breakdown, bestie 🎀
Type: TRILL GENINFO APPsub-TLV type, set to11(TREE-VLANs).Length:6*n bytes, where there are n Tree-VLAN RECORDs. So you can figure out n straight from the Length value 🧮 If Length isn't a multiple of 6, the APPsub-TLV is corrupt and MUST be ignored 🙈Nickname: the nickname that identifies the distribution tree by its root 🌸RESV: 4 bits that MUST be sent as zero and ignored on receipt 🫧Start.VLAN,End.VLAN: the VLAN IDs for the allowed VLAN range on the tree, and the range is inclusive 🦋 If you only want one VLAN, you put its ID in both fields. IfEnd.VLANis less thanStart.VLAN, the Tree-VLAN RECORD MUST be ignored 💀
3.2.2. The Tree and VLANs Used APPsub-TLV
this one is basically the twin of the TREE-VLANs APPsub-TLV from Section 3.2.1, same structure, no notes 💅 The only differences are the type, which is 12 (TREE-VLAN-USE), and what the records mean. The tree-VLAN pairings listed here are the ones the originating RBridge actually wants to use for multi-destination packets 🌈 An ingress RBridge sends this to share the tree-VLAN pairing it picked off the list the highest-priority tree root announced. Main character energy, honestly ✨
3.2.3. The Tree and FGLs APPsub-TLV
the highest-priority tree root can use the Tree and FGLs (TREE-FGLs) APPsub-TLV to announce which FGLs are allowed on each tree 🦋 You can carry several of these, and the same tree nickname can appear across multiple Tree-FGL RECORDs, either in one APPsub-TLV or across a few of them. Here's how it's laid out:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-FGL RECORD (1) | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-FGL RECORD (N) | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+and each Tree-FGL RECORD is shaped like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Start.FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| End.FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+the details 🎀
Type: TRILL GENINFO APPsub-TLV type, set to13(TREE-FGLs).Length:8*n bytes, where there are n Tree-FGL RECORDs. The Length value tells you n. If Length isn't a multiple of 8, the APPsub-TLV is corrupt and MUST be ignored 🙈Nickname: the nickname that identifies the distribution tree by its root 🌸RESV: 4 bits that MUST be sent as zero and ignored on receipt 🫧Start.FGL,End.FGL: the FGL IDs for the allowed FGL range on the tree, inclusive 🧚 For a single FGL, its ID goes in both fields. IfEnd.FGLis less thanStart.FGL, the Tree-FGL RECORD MUST be ignored 💀
3.2.4. The Tree and FGLs Used APPsub-TLV
same structure as the TREE-FGLs APPsub-TLV from Section 3.2.3, so it's giving déjà vu 🌈 The type is 14 (TREE-FGL-USE), and the Tree-FGL pairings in the records are the ones the originating RBridge wants for multi-destination packets 💜 An ingress RBridge uses it to pass along the tree-FGL pairing it chose from the list the highest-priority tree root announced. iykyk 😭
3.2.5. The Tree and Groups APPsub-TLV
okay this is the one that's lowkey so clever ✨ Picking trees by Data Label is easy to stretch into picking trees by Data Label plus a Layer 2 or Layer 3 multicast group. Say multicast group 1 in VLAN 10 goes on tree 1, and multicast group 2 in VLAN 10 goes on tree 2. Boom, better load-sharing 🦋
The highest-priority tree root can announce which multicast groups are allowed on each tree for each Data Label, using the Tree and Groups (TREE-GROUPs) APPsub-TLV. You can carry more than one, and here's what it looks like:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 15 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Sub-Sub-TLVs (variable)
+-+-+-+-+-+-+-+-+-+....the breakdown 🍓
Type: TRILL GENINFO APPsub-TLV type, set to15(TREE-GROUPs).Length: 2 + the length of the Group Sub-Sub TLVs that are included 🧮Nickname: the nickname that identifies the distribution tree by its root 🌸Group Sub-Sub-TLVs: zero or more of the TLV structures that are allowed as sub-TLVs of the Group Address (GADDR) TLV [RFC7176]. Each one specifies a multicast group and either a VLAN or an FGL. These are sub-TLVs when they sit inside a GADDR TLV, but when they sit inside a TREE-GROUPs APPsub-TLV, which is inside a TRILL GENINFO TLV [RFC7357], they're technically sub-sub-TLVs 🤓
3.2.6. The Tree and Groups Used APPsub-TLV
the Tree and Groups Used (TREE-GROUPs-USE) APPsub-TLV has the same structure as the TREE-GROUPs one from Section 3.2.5 💅 The differences: its type is 16 (TREE-GROUPs-USE), and the Tree Nickname and Group sub-sub-TLVs in it are the ones the originating RBridge wants for multi-destination packets 👑 An ingress RBridge sends it to distribute the tree-group pairing it picked from the list the highest-priority tree root announced. Slay 🔥
3.3. Detailed Processing 🎀
okay so the highest-priority tree root RBridge MUST include all the necessary tree-related sub-TLVs defined in [RFC7176] as usual in its E-L1FS FS-LSP 💅 and it MAY include the TREE-VLANs APPsub-TLV and/or the TREE-FGLs APPsub-TLV in its E-L1FS FS-LSP [RFC7780]. this way it MAY indicate that each VLAN and/or FGL is only allowed on one or some other number of trees, which is less than the number of trees being calculated in the campus. the point is to save table space in the fast-path forwarding hardware 🧚✨
an ingress RBridge that understands the TREE-VLANs APPsub-TLV SHOULD select the tree-VLAN correspondences it wants to use and put them in TREE-VLAN-USE APPsub-TLVs. if there are multiple tree nicknames announced in a TREE-VLANs APPsub-TLV for VLAN x, the ingress RBridge chooses one of them as long as it supports this feature 👀. for example, the ingress RBridge may choose the closest (minimum-cost) root among them. how to make that choice is out of scope for this document. it may be desirable to have some fixed algorithm so that all ingress RBridges choose the same tree for VLAN x in this case, which is very cute ngl 🫶. any single Data Label that the ingress RBridge is interested in should be related to only one tree ID in a TREE-VLAN-USE APPsub-TLV to keep the multicast forwarding table size small on other RBridges. but as long as the Data Label is related to less than all the trees being calculated, it still reduces the burden on the forwarding table size 💜
when an ingress RBridge encapsulates a multi-destination frame for Data Label x, it SHOULD use a tree nickname it selected earlier in a TREE-VLAN-USE or TREE-FGL-USE APPsub-TLV for Data Label x. however, that may not be possible, because either (1) the RBridge may not have advertised any such TREE-VLAN-USE or TREE-FGL-USE APPsub-TLVs, in which case it can use any tree that the highest-priority tree root has advertised as permitted for the Data Label, or (2) the tree or trees it advertised might be unavailable due to failures 😭
if RBridge RBn does not perform pruning, it builds the multicast forwarding table as specified in [RFC6325]. 🌸
if RBn prunes the distribution tree based on VLANs, RBn uses the information received in TREE-VLAN-USE APPsub-TLVs to mark the set of VLANs reachable downstream for each adjacency and for each related tree. if RBn prunes the distribution tree based on FGLs, RBn uses the information received in TRILL-FGL-USE APPsub-TLVs to mark the set of FGLs reachable downstream for each adjacency and for each related tree 🦋
logically, an ingress RBridge that does not support VLAN-based or FGL-based tree selection is equivalent to one that supports it but uses it in such a way that it gains no advantage. for example, it announces the use of all trees for all VLANs and FGLs. it's the main character of "no effort" 💅
3.4. Failure Handling 🌈
this section talks about failure scenarios for a distribution tree root, both for the case where that tree root is not the highest-priority root and the case where it is the highest-priority root. it also covers some other transient error conditions, so let's go 🧚
- Failure of a tree root that is not the highest-priority tree root: it is the responsibility of the highest-priority tree root to inform other RBridges of any change in the allowed tree-VLAN correspondence. when the highest-priority tree root learns that the root of tree t has failed, it should reassign the VLANs allowed on tree t to other trees or to a tree replacing the failed one 🔁
- Failure of the highest-priority tree root: it is suggested that the tree root of second-highest priority be pre-configured with the proper knowledge of the tree-VLAN correspondence that is allowed when the highest-priority tree root fails. the information announced by the RBridge with the second-highest priority to be a tree root would be in the link state of all RBridges, but it would not take effect unless the RBridge noticed the failure of the highest-priority tree root. when the highest-priority tree root fails, the tree root that formerly had second-highest priority will become the highest-priority tree root of the campus. when an RBridge notices the failure of the original highest-priority tree root, it can immediately use the stored information announced by the tree root that originally had second-highest priority. it is suggested that the tree-VLAN correspondence information be pre-configured on the tree root of second-highest priority to be the same as on the highest-priority tree root, for the trees other than the highest-priority tree itself. this can minimize the change to multicast forwarding tables in the case of highest-priority tree root failure. for a large campus, it may make sense to pre-configure this information in a similar way on the third-priority, fourth-priority, or even lower-priority tree root RBridges 👑
in some transient conditions, or in the case of a misbehaving highest-priority tree root, an ingress RBridge may run into the following scenarios 🙈:
- No tree has been announced for which VLAN x frames are allowed.
- An ingress RBridge is supposed to transmit VLAN x frames on tree t, but the root of tree t is no longer reachable.
for the second case, an ingress RBridge may choose another reachable tree root that allows VLAN x frames according to the highest-priority tree root announcement. if there is no such tree available, then it is the same as the first case above. the ingress RBridge should then be "downgraded" to a conventional RBridge with behavior as specified in [RFC6325]. a timer should be set to allow the temporary transient stage to complete before the change of the responsive tree or the downgrade takes effect. the value of the timer should be set to at least the LSP flooding time of the campus ⏳💀
4. Backward Compatibility 🍓
RBridges MUST include the TREE-USE-IDs and INT-VLAN sub-TLVs in their LSPs when required by [RFC6325], whether or not they support the new TREE-VLAN-USE or TREE-FGL-USE APPsub-TLVs specified by this document. non-negotiable, bestie 🫶
RBridges that understand the new TREE-VLAN-USE APPsub-TLV sent from another RBridge RBn should use it to build the multicast forwarding table, and ignore the TREE-USE-IDs and INT-VLAN sub-TLVs sent from that same RBridge. TREE-USE-IDs and INT-VLAN sub-TLVs are still useful for some purposes other than building the multicast forwarding table, like building an RPF table or spanning tree root notification ✨. if the RBridge does not receive TREE-VLAN-USE APPsub-TLVs from RBn, it uses the conventional way described in [RFC6325] to build the multicast forwarding table.
here's the example, it's giving very organized 📋. there are two distribution trees, tree 1 and tree 2, in the campus. RB1 and RB2 are RBridges that use the new APPsub-TLVs described in this document. RB3 is an old RBridge that is compatible with [RFC6325]. assume that RB2 is interested in VLANs 10 and 11, and RB3 is interested in VLANs 100 and 101. so RB1 receives ((tree 1, VLAN 10), (tree 2, VLAN 11)) as a TREE-VLAN-USE APPsub-TLV and (tree 1, tree 2) as a TREE-USE-IDs sub-TLV from RB2 on port x. also, RB1 receives (tree 1) as a TREE-USE-IDs sub-TLV and no TREE-VLAN-USE APPsub-TLV from RB3 on port y. RB2 and RB3 announce their interested VLANs in an INT-VLAN sub-TLV as usual. RB1 will then build the entries (tree 1, VLAN 10, port x) and (tree 2, VLAN 11, port x) based on RB2's LSP and the mechanism specified in this document. RB1 also builds the entries (tree 1, VLAN 100, port y), (tree 1, VLAN 101, port y), (tree 2, VLAN 100, port y), and (tree 2, VLAN 101, port y) based on RB3's LSP in the conventional way 🧩
the multicast forwarding table on RB1 with a merged entry would look like the following:
+--------------+-----+---------+
|tree nickname |VLAN |port list|
+--------------+-----+---------+
| tree 1 | 10 | x |
+--------------+-----+---------+
| tree 1 | 100 | y |
+--------------+-----+---------+
| tree 1 | 101 | y |
+--------------+-----+---------+
| tree 2 | 11 | x |
+--------------+-----+---------+
| tree 2 | 100 | y |
+--------------+-----+---------+
| tree 2 | 101 | y |
+--------------+-----+---------+as expected, that table is not as small as the one where every RBridge supports the new TREE-VLAN-USE APPsub-TLVs. in a hybrid campus, the worst case is where the number of entries equals the number of entries required by the current practice that does not support VLAN-based tree selection. that extreme case happens when the set of interested VLANs from the new RBridges is a subset of the set of interested VLANs from the old RBridges 🥲
tree selection based on the Data Label and multicast group is compatible with the current practice. its effectiveness increases with more RBridges supporting this feature in the TRILL campus. the more the merrier, periodt 🌟
5. Security Considerations 🔐
this document does not change the general RBridge security considerations of the TRILL base protocol. the APPsub-TLVs specified can be secured using the IS-IS authentication feature [RFC5310]. see Section 6 of [RFC6325] for general TRILL security considerations. stay safe out there, no cap 😤
6. IANA Considerations 🦋
IANA has assigned six new TRILL APPsub-TLV types from the range less than 255, as specified in Section 3, and updated the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry on <http://www.iana.org/assignments/trill-parameters/>, as shown below 📝
Type Name of APPsub-TLV Reference
---- ----------------------- -------------------------
11 Tree and VLANs Section 3.2.1 of RFC 7968
12 Tree and VLANs Used Section 3.2.2 of RFC 7968
13 Tree and FGLs Section 3.2.3 of RFC 7968
14 Tree and FGLs Used Section 3.2.4 of RFC 7968
15 Tree and Groups Section 3.2.5 of RFC 7968
16 Tree and Groups Used Section 3.2.6 of RFC 79687. References ✨
7.1. Normative References ✨
okay so these are the docs you NEED to have read before you touch any of this 📚🫶 the normative ones, lowkey the foundation of the whole vibe:
[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>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
<http://www.rfc-editor.org/info/rfc6325>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172,
DOI 10.17487/RFC7172, May 2014,
<http://www.rfc-editor.org/info/rfc7172>.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
D., and A. Banerjee, "Transparent Interconnection of Lots
of Links (TRILL) Use of IS-IS", RFC 7176,
DOI 10.17487/RFC7176, May 2014,
<http://www.rfc-editor.org/info/rfc7176>.
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
Stokes, "Transparent Interconnection of Lots of Links
(TRILL): End Station Address Distribution Information
(ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>.7.2. Informative References 🌸
these ones are the extra-credit reading, bestie 🧚 good to know about but not required to get the core picture:
[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>.Acknowledgments 💖
okay the authors had to give a shoutout to the people who helped them get this across the finish line, and I'm obsessed with that energy 🫶 huge thanks to David M. Bond, Liangliang Ma, Naveen Nimmu, Radia Perlman, Rakesh Kumar, Robert Sparks, Daniele Ceccarelli, and Sunny Rajagopalan for their valuable comments and contributions. literally the real MVPs 👑✨
Authors' Addresses 🦋
and here are the people who wrote it, with their contact info, so you can slide into their inbox if you have questions 💌 (be respectful tho 🙈)
Yizhou Li is at Huawei Technologies:
Yizhou Li
Huawei Technologies
101 Software Avenue
Nanjing 210012
China
Phone: +86-25-56624629
Email: liyizhou@huawei.comDonald Eastlake 3rd is also at Huawei Technologies, but in the US office:
Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.comWeiguo Hao is back in Nanjing with Huawei:
Weiguo Hao
Huawei Technologies
101 Software Avenue
Nanjing 210012
China
Phone: +86-25-56623144
Email: haoweiguo@huawei.comHao Chen is in Nanjing too, same building energy 🏢💅:
Hao Chen
Huawei Technologies
101 Software Avenue
Nanjing 210012
China
Email: philips.chenhao@huawei.comAnd last but definitely not least, Somnath Chatterjee is at Cisco Systems in Bangalore 🌈⭐:
Somnath Chatterjee
Cisco Systems
SEZ Unit, Cessna Business Park
Outer Ring Road
Bangalore 560087
India
Email: somnath.chatterjee01@gmail.com📦 where this page comes from
- ietf: rfc7968 2016-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms