RFC 7176
Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
RFC 7176: Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS 🦋
Okay bestie, this is RFC 7176 from the IETF, and it's the TRILL spec for IS-IS 🌸 It's a Standards Track document dated May 2014, with ISSN 2070-1721. D. Eastlake 3rd (Huawei) is the lead author, with T. Senevirathne (Cisco), A. Ghanwani (Dell), D. Dutt (Cumulus Networks), and A. Banerjee (Insieme Networks) helping out. It obsoletes RFC 6326 💅 The header doesn't list anything it updates.
Abstract ✨
Okay so TRILL gives you optimal pair-wise data frame forwarding with zero configuration, across multi-hop networks with any topology and any link technology 🌈 It also does multipathing for both unicast and multicast traffic, which is giving main character energy 💖 This document is where the data formats and code points for the IS-IS extensions that support TRILL are specified 🎀 Other technologies can use these formats and code points too, so it's not TRILL-exclusive 🧚 And it obsoletes RFC 6326 💀
Status of This Memo ✨
This is an Internet Standards Track document 💅
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7176 🫶
Copyright Notice ✨
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they lay 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 ....................................................3
1.1. Conventions Used in This Document ..........................4
2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................4
2.1. Group Address TLV ..........................................5
2.1.1. Group MAC Address Sub-TLV ...........................5
2.1.2. Group IPv4 Address Sub-TLV ..........................7
2.1.3. Group IPv6 Address Sub-TLV ..........................8
2.1.4. Group Labeled MAC Address Sub-TLV ...................9
2.1.5. Group Labeled IPv4 Address Sub-TLV .................10
2.1.6. Group Labeled IPv6 Address Sub-TLV .................11
2.2. Multi-Topology-Aware Port Capability Sub-TLVs .............12
2.2.1. Special VLANs and Flags Sub-TLV ....................12
2.2.2. Enabled-VLANs Sub-TLV ..............................13
2.2.3. Appointed Forwarders Sub-TLV .......................14
2.2.4. Port TRILL Version Sub-TLV .........................15
2.2.5. VLANs Appointed Sub-TLV ............................17
2.3. Sub-TLVs of the Router Capability and MT-Capability TLVs ..17
2.3.1. TRILL Version Sub-TLV ..............................18
2.3.2. Nickname Sub-TLV ...................................19
2.3.3. Trees Sub-TLV ......................................20
2.3.4. Tree Identifiers Sub-TLV ...........................20
2.3.5. Trees Used Identifiers Sub-TLV .....................21
2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...22
2.3.7. VLAN Group Sub-TLV .................................24
2.3.8. Interested Labels and Spanning Tree Roots Sub-TLV ..25
2.3.9. RBridge Channel Protocols Sub-TLV ..................27
2.3.10. Affinity Sub-TLV ..................................29
2.3.11. Label Group Sub-TLV ...............................30
2.4. MTU Sub-TLV for Extended Reachability and MT-ISN TLVs .....31
2.5. TRILL Neighbor TLV ........................................31
3. MTU PDUs .......................................................33
4. Use of Existing PDUs and TLVs ..................................35
4.1. TRILL IIH PDUs ............................................35
4.2. Area Address ..............................................35
4.3. Protocols Supported .......................................35
4.4. Link State PDUs (LSPs) ....................................35
4.5. Originating LSP Buffer Size ...............................36
5. IANA Considerations ............................................36
5.1. TLVs ......................................................36
5.2. Sub-TLVs ..................................................36
5.3. PDUs ......................................................38
5.4. Reserved and Capability Bits ..............................38
5.5. TRILL Neighbor Record Flags ...............................39
6. Security Considerations ........................................39
7. Changes from RFC 6326 ..........................................39
8. References .....................................................41
8.1. Normative References ......................................41
8.2. Informative References ....................................43
9. Acknowledgements ...............................................441. Introduction 🌸
The TRILL protocol [RFC6325] [RFC7177] is all about transparent forwarding across multi-hop networks with arbitrary topology and link technologies 💖 It uses a header with a hop count plus link-state routing. It gives you optimal pair-wise forwarding with no configuration, safe forwarding even during temporary loops, and multipathing for both unicast and multicast traffic 🦋 The systems that implement TRILL are called Routing Bridges (RBridges) or TRILL Switches 👑
This document, together with [RFC6165], specifies the data formats and code points for the IS-IS [ISO-10589] [RFC1195] extensions that support TRILL ✨ Other technologies can use these data formats and code points too 🧚
This document obsoletes [RFC6326], which matched up with the base TRILL protocol [RFC6325] 🎀 TRILL has seen a lot of development since those documents came out, so here are the main changes from [RFC6326] 🔥 A full list is in Section 7.
- Added multicast group announcements by IPv4 and IPv6 address.
- Added facilities for announcing capabilities supported.
- Added a tree affinity sub-TLV whereby ISs can request distribution tree association.
- Added multi-topology support.
- Added control-plane support for TRILL Data frame fine-grained labels. This support is independent of the data-plane representation.
- Fixed the verified erratum [Err2869] in [RFC6326].
Good news: changes to TLVs and sub-TLVs specified in [RFC6326] are backward compatible 🫶
1.1. Conventions Used in This Document 🍓
The terminology and acronyms defined in [RFC6325] mean the same thing here 💅 These extra acronyms and phrases also show up in this document:
- BVL - Bit Vector Length
- BVO - Bit Vector Offset
- IIH - IS-IS Hello
- IS - Intermediate System. For this document, all relevant intermediate systems are RBridges [RFC6325].
- MAC - Media Access Control
- MT - Multi-Topology
- NLPID - Network Layer Protocol Identifier
- SNPA - Subnetwork Point of Attachment (MAC Address)
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 [RFC2119]. These are the official BCP 14 words, so they carry real weight here 🔥
2. TLV and Sub-TLV Extensions to IS-IS for TRILL 💜
Okay so this section, together with [RFC6165], specifies the data formats and code points for the TLVs and sub-TLVs for IS-IS that support the IETF TRILL protocol ✨ If you want to know how many occurrences are allowed, whether for a TLV in a PDU or a set of PDUs, or for a sub-TLV inside a TLV, that's all summarized in Section 5 🙈
2.1. Group Address TLV 🦋
Here's the deal: the Group Address (GADDR) TLV, which is IS-IS TLV type 142, rides along in an LSP PDU 🌈 It carries sub-TLVs that advertise multicast group listeners. The listener sub-TLVs get specified below. The sub-TLVs under GADDR are a brand new series of sub-TLV types (see Section 5.2) 💖
GADDR has the following format:
+-+-+-+-+-+-+-+-+
|Type=GADDR-TLV | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...- Type: TLV type, set to GADDR-TLV 142.
- Length: variable depending on the sub-TLVs carried.
- sub-TLVs: The Group Address TLV value consists of sub-TLVs formatted as described in [RFC5305] 🎀
2.1.1. Group MAC Address Sub-TLV ✨
okay so the Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1 inside the GADDR TLV 🫶 In TRILL, it's how you advertise multicast listeners by MAC address, as specified in Section 4.5.5 of [RFC6325]. Here's the layout:
+-+-+-+-+-+-+-+-+
|Type=GMAC-ADDR | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where each group record is of the following form with k=6:
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: GADDR sub-TLV type, set to
1(GMAC-ADDR). - Length:
5 + m + k*n = 5 + m + 6*n, where m is the number of group records and n is the sum of the number of group and source addresses. - RESV: Reserved. 4-bit fields that MUST be sent as zero and ignored on receipt. 🔒
- Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
- VLAN ID: This carries the 12-bit VLAN identifier for all subsequent MAC addresses in this sub-TLV, or the value zero if no VLAN is specified.
- Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
- GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for
(*,G), that is, a listener not restricted by source. It then has a 6-byte (48-bit) multicast MAC address followed by 6-byte source MAC addresses. If the sources do not fit in a single sub-TLV, the same group address may be repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
The GMAC-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.2. Group IPv4 Address Sub-TLV ✨
the Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type 2 inside the GADDR TLV 💅 It's basically the same format as the Group MAC Address sub-TLV from Section 2.1.1, except k=4. Here are the fields:
- Type: sub-TLV type, set to
2(GIP-ADDR). - Length:
5 + m + k*n = 5 + m + 4*n, where m is the number of group records and n is the sum of the number of group and source addresses. - Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
- RESV: Must be sent as zero on transmission and is ignored on receipt.
- VLAN ID: This carries a 12-bit VLAN identifier that is valid for all subsequent addresses in this sub-TLV, or the value zero if no VLAN is specified.
- Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
- GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for
(*,G), that is, a listener not restricted by source. It then has a 4-byte (32-bit) IPv4 Group Address followed by 4-byte source IPv4 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
The GIP-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.3. Group IPv6 Address Sub-TLV ✨
the Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 3 inside the GADDR TLV 🦋 Same vibe as the Group MAC Address sub-TLV from Section 2.1.1, except this time k=16. The fields:
- Type: sub-TLV type, set to
3(GIPV6-ADDR). - Length:
5 + m + k*n = 5 + m + 16*n, where m is the number of group records and n is the sum of the number of group and source addresses. - Topology-Id: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
- RESV: Must be sent as zero on transmission and is ignored on receipt.
- VLAN ID: This carries a 12-bit VLAN identifier that is valid for all subsequent addresses in this sub-TLV, or the value zero if no VLAN is specified.
- Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
- GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for
(*,G), that is, a listener not restricted by source. It then has a 16-byte (128-bit) IPv6 Group Address followed by 16-byte source IPv6 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.4. Group Labeled MAC Address Sub-TLV ✨
okay so the GMAC-ADDR sub-TLV from Section 2.1.1 gives you a VLAN ID 🎀 The Group Labeled MAC Address sub-TLV below takes that up a notch and gives you a fine-grained label 🌸
+-+-+-+-+-+-+-+-+
|Type=GLMAC-ADDR| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fine-Grained Label | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where each group record is of the following form with k=6:
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: GADDR sub-TLV type, set to
4(GLMAC-ADDR). - Length:
6 + m + k*n = 6 + m + 6*n, where m is the number of group records and n is the sum of the number of group and source addresses. - RESV: Reserved. 4-bit field that MUST be sent as zero and ignored on receipt. 🔒
- Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
- Label: This carries the fine-grained label [RFC7172] identifier for all subsequent MAC addresses in this sub-TLV, or the value zero if no label is specified.
- Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
- GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for
(*,G), that is, a listener not restricted by source. It then has a 6-byte (48-bit) multicast address followed by 6-byte source MAC addresses. If the sources do not fit in a single sub-TLV, the same group address may be repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
The GLMAC-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.5. Group Labeled IPv4 Address Sub-TLV ✨
the Group Labeled IPv4 Address (GLIP-ADDR) sub-TLV is IS-IS sub-TLV type 5 inside the GADDR TLV 🌈 It has the same format as the Group Labeled MAC Address sub-TLV from Section 2.1.4, except k=4. The fields:
- Type: sub-TLV type, set to
5(GLIP-ADDR). - Length:
6 + m + k*n = 6 + m + 4*n, where m is the number of group records and n is the sum of the number of group and source addresses. - Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
- RESV: Must be sent as zero on transmission and is ignored on receipt.
- Label: This carries the fine-grained label [RFC7172] identifier for all subsequent IPv4 addresses in this sub-TLV, or the value zero if no label is specified.
- Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
- GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for
(*,G), that is, a listener not restricted by source. It then has a 4-byte (32-bit) IPv4 Group Address followed by 4-byte source IPv4 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
The GLIP-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.6. Group Labeled IPv6 Address Sub-TLV ✨
okay bestie, this one is the IPv6 twin of the labeled MAC one from Section 2.1.4 🦋 same format, just with k=16 this time 💅
The Group Labeled IPv6 Address (GLIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 6 inside the GADDR TLV 🌸 Here are the fields:
- Type: sub-TLV type, set to
6(GLIPV6-ADDR) 💖 - Length:
6 + m + k*n = 6 + m + 16*n, where m is the number of group records and n is the sum of the number of group and source addresses 🧮 - Topology-Id: This field carries a topology ID [RFC5120] or zero if topologies are not in use. 🗺️
- RESV: It must be sent as zero on transmission and is ignored on receipt. 🫶
- Label: This carries the fine-grained label [RFC7172] identifier for all subsequent IPv6 addresses in this sub-TLV, or the value zero if no label is specified. 🏷️
- Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV. 🔢
- GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for
(*,G), which is a listener not restricted by source. It then has a 16-byte (128-bit) IPv6 Group Address followed by 16-byte source IPv6 addresses. If the number of sources does not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV. 🌈
The GLIPV6-ADDR sub-TLV is carried only within a GADDR TLV. 👑
2.2. Multi-Topology-Aware Port Capability Sub-TLVs
TRILL makes use of the Multi-Topology-Aware Port Capability TLV (MT-Port-Cap-TLV) as specified in [RFC6165]. The following subsections specify the sub-TLVs transported by the MT-Port-Cap-TLV for TRILL. It's giving organised 🗂️✨
2.2.1. Special VLANs and Flags Sub-TLV
okay so in TRILL, a Special VLANs and Flags (VLAN-FLAGS) sub-TLV rides along in every IIH PDU 🚗💨 It looks like this:
+--+--+--+--+--+--+--+--+
| Type | (1 byte)
+--+--+--+--+--+--+--+--+
| Length | (1 byte)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Port ID | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Sender Nickname | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|AF|AC|VM|BY| Outer.VLAN | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TR|R |R |R | Designated-VLAN | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+- Type: sub-TLV type, set to MT-Port-Cap-TLV VLAN-FLAGS sub-TLV
1. 🎀 - Length:
8. 📏 - Port ID: An ID for the port on which the enclosing TRILL IIH PDU is being sent, as specified in [RFC6325], Section 4.4.2. 🚪
- Sender Nickname: If the sending IS is holding any nicknames as discussed in [RFC6325], Section 3.7, one MUST be included here. Otherwise, the field is set to zero. This field is there to support intelligent end stations that determine the egress IS (RBridge) for unicast data through a directory service or the like, and that need a nickname for their first hop to insert as the ingress nickname to correctly format a TRILL Data frame (see [RFC6325], Section 4.6.2, point 8). It is also referenced in connection with the VLANs Appointed Sub-TLV (see Section 2.2.5) and can be used as the egress on one-hop RBridge Channel messages [RFC7178], for example, those used for BFD over TRILL [RFC7175]. 🪪💅
- Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH frame containing this sub-TLV, as specified in [RFC6325], Section 4.4.5. 🏷️
- Designated-VLAN: The 12-bit ID of the Designated VLAN for the link, as specified in [RFC6325], Section 4.2.4.2. 🌷
- AF, AC, VM, BY, and TR: These flag bits have the following meanings when set to one, as specified in the listed section of [RFC6325]:
RFC 6325
Bit Section Meaning if bit is one
--------------------------------------
AF 4.4.2 Originating IS believes it is Appointed
Forwarder for the VLAN and port on which the
containing IIH PDU was sent.
AC 4.9.1 Originating port configured as an access port
(TRILL traffic disabled).
VM 4.4.5 VLAN mapping detected on this link.
BY 4.4.2 Bypass pseudonode.
TR 4.9.1 Originating port configured as a trunk port
(end-station service disabled).- R: Reserved bit. It MUST be sent as zero and ignored on receipt. 🚫
2.2.2. Enabled-VLANs Sub-TLV
The optional Enabled-VLANs sub-TLV tells everyone which VLANs are enabled at the port of the originating IS where the containing Hello was sent, as specified in [RFC6325], Section 4.4.2 🌈 Here's the layout:
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: sub-TLV type, set to MT-Port-Cap-TLV Enabled-VLANs sub-TLV
2. 🍓 - Length: Variable, minimum
3. 📐 - RESV: 4 reserved bits that MUST be sent as zero and ignored on receipt. 🫧
- Start VLAN ID: The 12-bit VLAN ID that is represented by the high-order bit of the first byte of the VLAN bit-map. 🥇
- VLAN bit-map: The highest-order bit indicates the VLAN equal to the start VLAN ID, the next highest bit indicates the VLAN equal to start VLAN ID + 1, continuing to the end of the VLAN bit-map field. 🗺️
If this sub-TLV occurs more than once in a Hello, the set of enabled VLANs is the union of the sets of VLANs indicated by each of the Enabled-VLAN sub-TLVs in the Hello. Union energy 🤝💜
2.2.3. Appointed Forwarders Sub-TLV
The Designated RBridge (DRB) on a link uses the Appointed Forwarders sub-TLV to tell the other ISs on the link that they are the designated VLAN-x forwarder for one or more ranges of VLAN IDs, as specified in [RFC6439] 👑 Here's the shape of it:
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (2) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where each appointment is of the form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: sub-TLV type, set to MT-Port-Cap-TLV AppointedFwrdrs sub-TLV
3. 🧚 - Length:
6*nbytes, where there are n appointments. 🧮 - Appointee Nickname: The nickname of the IS being appointed a forwarder. 💁♀️
- RESV: 4 bits that MUST be sent as zero and ignored on receipt. 🫶
- Start.VLAN, End.VLAN: This VLAN ID range is inclusive. Setting both Start.VLAN and VLAN.end to the same value indicates a range of one VLAN ID. If Start.VLAN is not equal to VLAN.end and Start.VLAN is 0x000, the sub-TLV is interpreted as if Start.VLAN was 0x001. If Start.VLAN is not equal to VLAN.end and VLAN.end is 0xFFF, the sub-TLV is interpreted as if VLAN.end was 0xFFE. If VLAN.end is less than Start.VLAN, the sub-TLV is ignored. If both Start.VLAN and VLAN.end are 0x000, or both are 0xFFF, the sub-TLV is ignored. The values 0x000 or 0xFFF are not valid VLAN IDs, and a port cannot be enabled for them. 🚫🌸
An IS's nickname may occur as Appointed Forwarder for multiple VLAN ranges, through occurrences of this sub-TLV within the same or different MT Port Capability TLVs within an IIH PDU. See [RFC6439]. Main character energy for every single nickname 🦋✨
2.2.4. Port TRILL Version Sub-TLV
The Port TRILL Version (PORT-TRILL-VER) sub-TLV says what the maximum version of the TRILL standard is that's supported, plus which optional hop-by-hop capabilities are supported 🌟 By implication, lower versions are also supported. If this sub-TLV is missing from an IIH, it is assumed that the originating IS only supports the base version (version zero) of the protocol [RFC6325] and supports no optional capabilities indicated by this sub-TLV. Lowkey a very important fallback 🥹
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Capabilities and Header Flags Supported | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1- Type: MT-Port-Cap-TLV sub-TLV type, set to
7(PORT-TRILL-VER). 🎯 - Length:
5. 📏 - Max-version: A one-byte unsigned integer set to the maximum version supported. 🔝
- Capabilities and Header Flags Supported: A bit vector of 32 bits numbered 0 through 31 in network order. Bits 3 through 13 indicate that the corresponding TRILL Header hop-by-hop extended flags [RFC7179] are supported. Bits 0 through 2 and 14 to 31 are reserved to indicate support of optional capabilities. A one bit indicates that the flag or capability is supported by the sending IS. Bits in this field MUST be set to zero except as permitted for a capability being advertised, or if a hop-by-hop extended header flag is supported. 🧩
This sub-TLV, if present, MUST occur in an MT-Port-Cap-TLV in a TRILL IIH. If there is more than one occurrence, the minimum of the supported versions is assumed to be correct, and a capability or header flag is assumed to be supported only if indicated by all occurrences. The flags and capabilities for which support can be indicated in this sub-TLV are disjoint from those in the TRILL-VER sub-TLV (Section 2.3.1), so they cannot conflict. The flags and capabilities indicated in this sub-TLV relate to hop-by-hop processing that can differ between the ports of an IS (RBridge), and thus must be advertised in IIHs. For example, a capability requiring cryptographic hardware assist might be supported on some ports and not others. However, the TRILL version is the same as that in the PORT-TRILL-VER sub-TLV. An IS, if it is adjacent to the sending IS of TRILL version sub-TLV(s), uses the TRILL version it received in PORT-TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub-TLV(s). 🫶💖 the way the details in this section are so precise, I'm obsessed 😭
2.2.5. VLANs Appointed Sub-TLV 🦋
okay so the optional VLANs Appointed sub-TLV is giving "here's where I'm the boss" 👑. It tells you, for the port of the originating IS where the containing Hello got sent, which VLANs that port is the Appointed Forwarder for. Here's the layout:
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 💖: this is the sub-TLV type, set to MT-Port-Cap-TLV VLANS-Appointed sub-TLV
8. - Length 🧚: it's variable, with a minimum of
3. - RESV 🌸: these are 4 reserved bits that MUST be sent as zero and ignored on receipt. Don't touch them, bestie.
- Start VLAN ID 🍓: this is the 12-bit VLAN ID represented by the high-order bit of the first byte of the VLAN bit-map.
- VLAN bit-map 💜: the highest-order bit is the VLAN equal to the Start VLAN ID, the next bit down is Start VLAN ID + 1, and so on until the end of the bit-map field. Iconic bit math 🔥.
Now the fun part. If this sub-TLV shows up more than once in a Hello, the originating IS is basically saying "I believe I'm the Appointed Forwarder on the port where this IIH was sent, for the union of all the VLANs listed in every VLANs-Appointed sub-TLV in that Hello." So you add up all the VLANs across the copies. Main character energy ✨.
2.3. Sub-TLVs of the Router Capability and MT-Capability TLVs 🌈
so the Router Capability TLV is defined in [RFC4971] and the MT-Capability TLV is defined in [RFC6329]. Every sub-section below covers a sub-TLV that can ride inside the Router Capability TLV (#242) and the MT-Capability TLV (#144), using the same sub-TLV number in both. And these TLVs only ever get carried in LSPs, so that's where they live 🫶.
2.3.1. TRILL Version Sub-TLV 🎀
The TRILL Version (TRILL-VER) sub-TLV tells everyone the highest TRILL standard version the originating IS supports, plus which optional capabilities it's down for. Lower versions are implied as supported too, so it's a whole vibe 💅. If this sub-TLV is missing, we assume the originating IS only does the base version (version zero) of the protocol [RFC6325], with no optional capabilities from this sub-TLV. Lowkey a sad little default 🥺.
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Capabilities and Header Flags Supported | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1- Type 🦋: Router Capability sub-TLV type, set to
13(TRILL-VER). - Length ⭐:
5. - Max-version 💖: a one-byte unsigned integer set to the maximum version supported.
- Capabilities and Header Flags Supported 🔥: this is a bit vector of 32 bits, numbered 0 through 31 in network order. Bits 14 through 31 say which TRILL Header extended flags [RFC7179] are supported. Bits 0 through 13 are reserved for signalling support of optional capabilities. A one bit means the originating IS supports that flag or capability. For example, support of multi-level TRILL IS-IS [MultiLevel]. Bits in this field MUST be set to zero, except for a capability being advertised or an extended header flag that's supported. No sneaky extra bits allowed 🙈.
Okay, placement rules. If this sub-TLV is in a Router Capability TLV, it MUST occur in LSP number zero for the originating IS. If it turns up in a Router Capability TLV in other fragments, it gets ignored, so don't even bother 💀. If there's more than one occurrence in LSP number zero, we take the minimum of the supported versions as the correct one, and a header flag or capability only counts as supported if every occurrence says so. The flags and capabilities this sub-TLV can advertise are disjoint from the ones in the PORT-TRILL-VER sub-TLV (Section 2.2.4), so they can't clash 🙌. The TRILL version is the same as the one in PORT-TRILL-VER, though, and an adjacent IS to the originating IS uses the version it got from the PORT-TRILL-VER sub-TLV(s) over the one from TRILL-VER sub-TLV(s). PORT-TRILL-VER wins, periodt 👑.
For multi-topology-aware TRILL Switches, the TRILL version and capabilities announced for the base topology get assumed to apply to every topology that doesn't have its own TRILL version announcement in an MT-Capability TLV. Those non-zero topology announcements don't have to show up in fragment zero 🌸.
2.3.2. Nickname Sub-TLV 🍓
The Nickname (NICKNAME) Router Capability sub-TLV carries the originating IS's nicknames, plus how strongly it wants to hold each one and how strongly it wants each nickname to be a tree root, as specified in [RFC6325], Section 3.7.3. You can have multiple instances of this one, so the more the merrier 🧚.
+-+-+-+-+-+-+-+-+
|Type = NICKNAME| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Each nickname record looks like this:
+-+-+-+-+-+-+-+-+
| Nickname.Pri | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Root Priority | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 💜: Router Capability and MT-Capability sub-TLV type, set to
6(NICKNAME). - Length 🦋:
5*n, where n is the number of nickname records present. - Nickname.Pri 🌈: an 8-bit unsigned integer priority for holding a nickname, as specified in Section 3.7.3 of [RFC6325].
- Tree Root Priority ✨: an unsigned 16-bit integer priority for being a tree root, as specified in Section 4.5 of [RFC6325].
- Nickname 💖: an unsigned 16-bit integer, as specified in Section 3.7 of [RFC6325].
2.3.3. Trees Sub-TLV 🌸
Every IS that provides TRILL service uses the TREES sub-TLV to announce three numbers used to compute distribution trees, as specified in Section 4.5 of [RFC6325]. Here's the shape:
+-+-+-+-+-+-+-+-+
|Type = TREES | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum trees able to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to use | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 🎀: Router Capability and MT-Capability sub-TLV type, set to
7(TREES). - Length 💅:
6. - Number of trees to compute 🔥: an unsigned 16-bit integer, as specified in Section 4.5 of [RFC6325].
- Maximum trees able to compute 👑: an unsigned 16-bit integer, as specified in Section 4.5 of [RFC6325].
- Number of trees to use 🫶: an unsigned 16-bit integer, as specified in Section 4.5 of [RFC6325].
2.3.4. Tree Identifiers Sub-TLV 🦋
The Tree Identifiers (TREE-RT-IDs) sub-TLV is an ordered list of nicknames 💖. When it's originated by the IS with the highest priority to be a tree root, it lists the distribution trees the other ISs are required to compute, as specified in Section 4.5 of [RFC6325]. If that info gets spread across multiple sub-TLVs, the starting tree number is what lets you stitch the ordered lists back together in the right order 🧩. The format:
+-+-+-+-+-+-+-+-+
|Type=TREE-RT-IDs| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Starting Tree Number | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K-th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K+1 - th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 🌈: Router Capability and MT-Capability sub-TLV type, set to
8(TREE-RT-IDs). - Length 🍓:
2 + 2*n, where n is the number of nicknames listed. - Starting Tree Number 🧚: this is the starting tree number for the nicknames that are trees for the domain. It's set to
1for the sub-TLV holding the first list. Other Tree-Identifiers sub-TLVs carry the number of the starting list they contain. Now, if the same tree identifier can be computed from two of these sub-TLVs and the results differ, that's assumed to be a transient glitch that'll clear up. During that transient time, such a tree SHOULD NOT be computed, unless every relevant sub-TLV present indicates that computation 🙈. - Nickname 💜: the nickname at which a distribution tree is rooted.
2.3.5. Trees Used Identifiers Sub-TLV 💖
This Router Capability sub-TLV has the same structure as the Tree Identifiers sub-TLV from Section 2.3.4. The only difference is its sub-TLV type, which is set to 9 (TREE-USE-IDs). The trees it lists are the ones the originating IS wants to use, as specified in [RFC6325], Section 4.5. Same look, different job, iconic 🔥✨.
2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ✨
okay so this sub-TLV is giving VLAN range + the tea about that range 🫖 it's basically the originating IS saying "here's my VLAN crew, and here's what's true for every single one of them." the info is flags, a variable-length list of spanning tree root bridge IDs, and an Appointed Forwarder status lost counter, and each piece is defined in the sections of [RFC6325] I'm listing with each item below 📚
the rules for the whole set of LSPs from one IS are super important, bestie 💅 the VLAN ranges across every occurrence of this sub-TLV MUST add up to exactly the VLANs where the originating IS is Appointed Forwarder on at least one port. and the VLAN ranges in multiple VLANs sub-TLVs for one IS MUST NOT overlap, unless the info about a VLAN is identical in every instance 🙈 that said, it's a transient state, so these conditions might be broken for a sec 🌈 if a VLAN isn't in any INT-VLAN sub-TLV for an IS, that IS is assumed to not care about traffic for that VLAN 🫠
now the messy part 😭 if the same VLAN shows up in more than one INT-VLAN sub-TLV for an IS and the info disagrees, here's how it shakes out:
- if the nicknames differ, it's unspecified which one wins 🤷♀️
- the largest Appointed Forwarder status lost counter wins, using serial number arithmetic [RFC1982] 🔢
- the originating IS counts as attached to a multicast IPv4 router for that VLAN if any of the INT-VLAN sub-TLVs say so, and same vibe for IPv6 multicast router attachment ✨
- the root bridge lists from all the instances of that VLAN for the originating IS get merged 🌳
to keep the chaos down, an implementation SHOULD advertise the update to an interested VLAN and Spanning Tree Roots sub-TLV in the same LSP fragment as the advertisement it replaces 🫶 if that's not possible, the two affected LSP fragments should be flooded as one atomic action. and an IS receiving an update to an existing one can chill out with a hold-down timer before processing, so it can catch all the LSP fragments for the same update first. that's the move, periodt 🎀
here's the layout:
+-+-+-+-+-+-+-+-+
|Type = INT-VLAN| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Interested VLANS | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+
| Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+now the fields, one by one 🧚
- Type: this is the Router Capability and MT-Capability sub-TLV type, set to 10 (INT-VLAN) 🔟
- Length: 10 + 6*n, where n is the number of root bridge IDs 📏
- Nickname: as specified in [RFC6325], Section 4.2.4.4, this field may be used to tie a nickname the originating IS holds to the VLAN range. if it's not used like that, it's set to zero 🍓
- Interested VLANS: the field is laid out like this:
0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+
| M4 | M6 | R | R | VLAN.start | RESV | VLAN.end |
+----+----+----+----+------------+----------+------------+- M4, M6: these bits say, respectively, that there's an IPv4 or IPv6 multicast router on a link where the originating IS is Appointed Forwarder for every VLAN in the indicated range, as specified in [RFC6325], Section 4.2.4.4, item 5.1 🪞
- R, RESV: these reserved bits MUST be sent as zero and get ignored on receipt 🙅♀️
- VLAN.start and VLAN.end: this VLAN ID range is inclusive 💜 if both are the same value, that's a range of one VLAN ID. if VLAN.start isn't equal to VLAN.end and VLAN.start is 0x000, the sub-TLV gets read as if VLAN.start was 0x001. if VLAN.start isn't equal to VLAN.end and VLAN.end is 0xFFF, it gets read as if VLAN.end was 0xFFE. if VLAN.end is less than VLAN.start, the sub-TLV is ignored 🗑️ same deal if both are 0x000 or both are 0xFFF. and just so we're clear, 0x000 and 0xFFF aren't valid VLAN IDs, so a port can't be enabled for them 🚫
- Appointed Forwarder Status Lost Counter: this counts how many times a port that was Appointed Forwarder for the VLANs in the range lost that status for some port, as discussed in Section 4.8.3 of [RFC6325] 📉 it starts at zero at an IS when the zeroth LSP sequence number gets initialized. at rollover, no special action is needed, it just wraps around 🔄
- Root Bridges: this is the list of zero or more spanning tree root bridge IDs, which is the set of root bridge IDs seen on all ports where the IS is Appointed Forwarder for the VLANs in the range, as discussed in [RFC6325], Section 4.9.3.2 🌳 obviously a port can only see one spanning tree root at a time, but multiple ports in the same VLANs can hook up to different bridged LANs with different roots 🌈
one last rule, bestie 👑 an INT-VLAN sub-TLV is basically saying the info (multicast router attachment, Appointed Forwarder status lost counter, and root bridges) is the same for every VLAN in its range. if that's not true, the range MUST be split into subranges that do meet this criteria. using a "range" of one VLAN ID is always safe, it's just maybe too verbose 🫠✨
2.3.7. VLAN Group Sub-TLV 🦋
the VLAN Group sub-TLV holds two or more VLAN IDs, as specified in [RFC6325], Section 4.8.4 🧩 its whole job is to say that shared VLAN learning is happening at the originating IS between the listed VLANs. here's the structure:
+-+-+-+-+-+-+-+-+
|Type=VLAN-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Primary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Secondary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary VLAN IDs ... (2 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the fields 🍭
- Type: this is the Router Capability and MT-Capability sub-TLV type, set to 14 (VLAN-GROUP) 💖
- Length: 4 + 2*n, where n is the number of secondary VLAN ID fields beyond the first. n MAY be zero 🫧
- RESV: a 4-bit field that MUST be sent as zero and ignored on receipt 🙈
- Primary VLAN ID: this identifies the primary VLAN ID 👑
- Secondary VLAN ID: this identifies a secondary VLAN in the VLAN Group 🎀
- more Secondary VLAN IDs: zero or more byte pairs, each with the top 4 bits as a RESV field and the low 12 bits as a VLAN ID 🌸
2.3.8. Interested Labels and Spanning Tree Roots Sub-TLV ✨
okay so an IS that can handle fine-grained labeling [RFC7172] 💅 tells everyone about its fine-grained label connectivity and related info using the Interested Labels and Spanning Tree Roots sub-TLV (INT-LABEL). it's basically a glow-up of the Interested VLANs and Spanning Tree Roots sub-TLV (INT-VLAN), and it's laid out like this 🎀
+-+-+-+-+-+-+-+-+
|Type=INT-LABEL | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Interested Labels | (7 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+- Type: Router Capability and MT-Capability sub-TLV type, set to 15 (INT-LABEL).
- Length: 11 + 6*n, where n is the number of root bridge IDs.
- Nickname: this field may be used to link a nickname held by the originating IS to the Interested Labels indicated. when it isn't used that way, it's set to zero.
- Interested Labels: the Interested Labels field is seven bytes long and looks like this 🦋
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|M4|M6|BM| R| R| R| R| R| . .
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.start - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.end or bit-map - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3- M4, M6: these bits say, respectively, that there's an IPv4 or IPv6 multicast router on a link where the originating IS is Appointed Forwarder for the VLAN matching every label in the range. 🌸
- BM: if the BM (bit-map) bit is zero, the last three bytes of the Interested Labels is a Label.end label number. if the BM bit is one, those bytes are a bit-map (more on that in a sec).
- R: these reserved bits MUST be sent as zero and are ignored on receipt. no vibes for the reserved bits 🙅♀️
- Label.start and Label.end: if the BM bit is zero, this fine-grained label [RFC7172] ID range is inclusive. these fields are treated as unsigned integers. setting them both to the same label ID value gives you a range of one label ID. if Label.end is less than Label.start, the sub-TLV is ignored.
- Label.start and bit-map: if the BM bit is one, the fine-grained labels the IS is interested in are marked by a 24-bit bit-map. the interested labels are the Label.start number plus the bit number of each one bit in the bit-map. so if bit zero of the bit-map is a one, the IS is interested in the label with value Label.start, and if bit 23 of the bit-map is a one, the IS is interested in the label with value Label.start+23. 🧚
- Appointed Forwarder Status Lost Counter: this counts how many times a port that was Appointed Forwarder for a VLAN mapping to the fine-grained label in the given range or bit-map has lost that Appointed Forwarder status, as discussed in Section 4.8.3 of [RFC6325]. it starts at zero at an IS when the zeroth LSP sequence number is initialized. no special action is needed at rollover; the counter just wraps around. 🔄
- Root Bridges: this is the list of zero or more spanning tree root bridge IDs, meaning the set of root bridge IDs seen on all ports where the IS is Appointed Forwarder for a VLAN mapping to the fine-grained label in the specified range or bit-map. (See [RFC6325], Section 4.9.3.2.) obvi a single port can only see one spanning tree root at a time, but there can be multiple relevant ports hooked up to different bridged LANs with different roots, so the list can have more than one. 👑
an INT-LABEL sub-TLV is basically promising that the info it carries (multicast router attachment, the Appointed Forwarder status lost counter, and root bridges) is the same for every label it names. if that's not true, the sub-TLV MUST be split into subranges and/or separate bit-maps that do meet that criteria. it's always safe to use sub-TLVs with a "range" of one VLAN ID, but that can get super verbose 🙈
2.3.9. RBridge Channel Protocols Sub-TLV ✨
an IS announces which RBridge Channel protocols [RFC7178] it supports using this sub-TLV. 🌈
+-+-+-+-+-+-+-+-+
|Type=RBCHANNELS| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Zero or more bit vectors (variable)
+-+-+-+-...- Type: Router Capability and MT-Capability RBridge Channel Protocols sub-TLV type, set to 16 (RBCHANNELS).
- Length: variable.
- Bit Vectors: zero or more byte-aligned bit vectors, where a one bit means the IS supports a particular RBridge Channel protocol. each byte-aligned bit vector looks like this 🍓
| 0 1 2 3 4 5 6 7| 8 9 10 11 12 13 14 15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Bit Vector Length | Bit Vector Offset |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| bits
+--+--+--...The Bit Vector Length (BVL) is a seven-bit unsigned integer field giving the number of bytes of bit vector. The Bit Vector Offset (BVO) is a nine-bit unsigned integer field.
the bits in each bit vector are numbered in network order. the high-order bit of the first byte of bits is bit 0 + 8*BVO, the low-order bit of that byte is 7 + 8*BVO, the high-order bit of the second byte is 8 + 8*BVO, and so on for BVL bytes. a bit vector of RBridge Channel protocols supported MUST NOT extend beyond the end of the value in the sub-TLV it sits in. if it does, it's ignored. if multiple byte-aligned bit vectors are in one such sub-TLV, their representations are contiguous, with the BVL field for the next one starting right after the last byte of bits for the previous one. the one or more bit vectors present MUST exactly fill the sub-TLV value. if there are one or two bytes of value left over, they're ignored; if there are more than two, an attempt is made to parse them as one or more bit vectors.
if different bit vectors overlap in the protocol number space they refer to, and they have inconsistent bit values for a channel protocol, support for that protocol is assumed if any of those bit vectors has a 1 for it. 🤝
the absence of any occurrences of this sub-TLV in an IS's LSP means that IS doesn't support the RBridge Channel facility. to avoid wasted space, trailing bit vector zero bytes SHOULD be eliminated by reducing BVL, any null bit vectors (ones with BVL equal to zero) get eliminated, and generally you want the most compact encoding possible. for example, support for channel protocols 1 and 32 could be encoded as
BVL = 5
BVO = 0
0b01000000
0b00000000
0b00000000
0b00000000
0b10000000or as
BVL = 1
BVO = 0
0b01000000
BLV = 1
BVO = 4
0b1000000the first takes 7 bytes while the second takes only 6, so the second would be preferred. 🏆
in multi-topology-aware RBridges, RBridge Channel protocols announced in the base topology are assumed to be supported in every topology that doesn't have its own separate announcement for RBridge Channel protocol support. 🗺️
2.3.10. Affinity Sub-TLV ✨
associating an IS with a multi-destination distribution tree through a specific path is done with the Affinity sub-TLV. 🦄 so if RB1 announces an Affinity sub-TLV with the nickname of RB2 as the first part of an Affinity Record in the sub-TLV value, it's basically asking all the ISs in the campus to connect RB2 as a child of RB1 when they calculate any of the trees listed in that Affinity Record. examples of use include [Affinity] and [Resilient]. main character energy for sure 👑
the structure of the Affinity sub-TLV looks like this:
+-+-+-+-+-+-+-+-+
| Type=AFFINITY | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and each AFFINITY RECORD is structured like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Affinity Flags | (1 byte)
+-+-+-+-+-+-+-+-+
|Number of trees| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 1st root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 2nd root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of Nth root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: Router Capability and MT-Capability sub-TLV type, set to 17 (AFFINITY).
- Length: size of all Affinity Records included, where an Affinity Record listing n tree roots is 4+2*n bytes long.
- Nickname: the 16-bit nickname of the IS whose associations to the multi-destination trees listed in the Affinity Record go through the originating IS. 💫
- Affinity Flags: 8 bits reserved for future needs, to provide additional info about the affinity being announced. these MUST be sent as zero and ignored on receipt. 🔒
- Number of trees: a one-byte unsigned integer giving the number of trees this Affinity Record is announcing affinity for.
- Tree-num of roots: the tree numbers of the distribution trees this Affinity Record is announcing.
there's no need for a field giving the number of Affinity Records, because you can figure that out just by processing the records themselves. 🧠
2.3.11. Label Group Sub-TLV ✨
okay bestie, the Label Group sub-TLV is made of two or more fine-grained label [RFC7172] IDs 🎀 It basically tells everyone that shared label MAC address learning is happening at the announcing IS between the listed labels. The layout is giving structure:
+-+-+-+-+-+-+-+-+
|Typ=LABEL-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary Label IDs ... (3 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: Router Capability and MT-Capability sub-TLV type, set to
18(LABEL-GROUP). 💜 - Length:
6 + 3*n, where n is the number of secondary VLAN ID fields beyond the first. n MAY be zero. 🌸 - Primary Label ID: This identifies the primary Label ID. 🦋
- Secondary Label ID: This identifies a secondary Label ID in the Label Group. ✨
- more Secondary Label IDs: zero or more byte triples, each with a Label ID. 💅
2.4. MTU Sub-TLV for Extended Reachability and MT-ISN TLVs 🌈
so the MTU sub-TLV is the optional way to announce a link's MTU, per [RFC6325], Section 4.2.4.4 🧚 It lives inside the Extended Reachability (#22) and MT-ISN (Intermediate System Neighbors) (#222) TLVs, and it looks like this:
+-+-+-+-+-+-+-+-+
| Type = MTU | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|F| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: Extended Reachability and MT-ISN sub-TLV type, set to MTU sub-TLV 28. 🍓
- Length:
3. 🎀 - F: Failed. This bit is a one if MTU testing failed on this link at the required campus-wide MTU. 💀
- RESV: 7 bits that MUST be sent as zero and ignored on receipt. 🫶
- MTU: This field is set to the largest successfully tested MTU size for this link or zero if it has not been tested, as specified in Section 4.3.2 of [RFC6325]. 👑
2.5. TRILL Neighbor TLV 🦋
the TRILL Neighbor TLV is the glow-up that shows up in TRILL broadcast link IIH PDUs (see Section 4.1 below) instead of the IS Neighbor TLV, as specified in Section 4.4.2.1 of [RFC6325] and in [RFC7177] 💖 Here's its structure:
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|S|L|R| SIZE | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+each neighbor gets its own little record, and it's shaped like this:
+-+-+-+-+-+-+-+-+
|F|O| RESV | (1 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
| SNPA (MAC Address) | (SIZE bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+- Type: TLV type, set to TRILL Neighbor TLV 145. 💜
- Length:
1 + (SIZE+3)*n, where n is the number of neighbor records, which may be zero. 🌸 - S: Smallest flag. If this bit is a one, then the list of neighbors includes the neighbor with the smallest MAC address considered as an unsigned integer. 🧚
- L: Largest flag. If this bit is a one, then the list of neighbors includes the neighbor with the largest MAC address considered as an unsigned integer. 🔥
- R, RESV: These bits are reserved and MUST be sent as zero and ignored on receipt. 🫶
- SIZE: The SNPA size as an unsigned integer in bytes except that 6 is encoded as zero. An actual size of zero is meaningless and cannot be encoded. The meaning of the value 6 in this field is reserved, and TRILL Neighbor TLVs received with a SIZE of 6 are ignored. The SIZE is inherent to the technology of a link and is fixed for all TRILL Neighbor TLVs on that link but may vary between different links in the campus if those links are different technologies, for example, 6 for EUI-48 SNPAs or 8 for EUI-64 SNPAs [RFC7042]. (The SNPA size on the various links in a TRILL campus is independent of the System ID size.) 🍓
- F: Failed. This bit is a one if MTU testing to this neighbor failed at the required campus-wide MTU (see [RFC6325], Section 4.3.1). 💀
- O: OOMF. This bit is a one if the IS sending the enclosing TRILL Neighbor TLV is willing to offer the Overload Originated Multi-destination Frame (OOMF) service [RFC7180] to the IS whose port has the SNPA in the enclosing Neighbor RECORD. 🦋
- MTU: This field is set to the largest successfully tested MTU size for this neighbor or to zero if it has not been tested. 👑
- SNPA (MAC Address): Subnetwork Point of Attachment of the neighbor. 💖
As specified in [RFC7177] and Section 4.4.2.1 of [RFC6325], all MAC addresses may fit into one TLV, in which case both the S and L flags would be set to one in that TLV. If the MAC addresses don't fit into one TLV, the highest MAC address in a TRILL Neighbor TLV with the L flag zero MUST also appear as a MAC address in some other TRILL Neighbor TLV (possibly in a different TRILL IIH PDU). Also, the lowest MAC address in a TRILL Neighbor TLV with the S flag zero MUST also appear in some other TRILL Neighbor TLV (possibly in a different TRILL IIH PDU). If an IS believes it has no neighbors, it MUST send a TRILL Neighbor TLV with an empty list of neighbor RECORDS, which will have both the S and L bits on. 🙈
⚠️ bestie, the MUST rules above are doing the heavy lifting for the MAC address lists, so don't skip them 😭
3. MTU PDUs 🌸
the IS-IS MTU-probe and MTU-ack PDUs are the tools for figuring out the MTU on a link between ISs, as specified in Section 4.3.2 of [RFC6325] and in [RFC7177] 🧚
The MTU PDUs have the IS-IS PDU common header (up through the Maximum Area Addresses byte) with PDU Type numbers as indicated in Section 5. They also have a common fixed MTU PDU header as shown below that is 8 + 2*(ID Length) bytes long, 20 bytes in the case of the usual 6-bytes System IDs. 💅
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe Source ID (ID Length bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Ack Source ID (ID Length bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+As with other IS-IS PDUs, the PDU Length gives the length of the entire IS-IS packet starting with and including the IS-IS common header. 🦋
The Probe ID field is an opaque 48-bit quantity set by the IS issuing an MTU-probe and copied by the responding IS into the corresponding MTU-ack. For example, an IS creating an MTU-probe could compose this quantity from a port identifier and probe sequence number relative to that port. ✨
The Probe Source ID is set by an IS issuing an MTU-probe to its System ID and copied by the responding IS into the corresponding MTU-ack. The Ack Source ID is set to zero in MTU-probe PDUs and ignored on receipt. An IS issuing an MTU-ack sets the Ack Source ID field to its System ID. The System ID length is usually 6 bytes but could be a different value as indicated by the ID Length field in the IS-IS PDU Header. 🍓
The TLV area follows the MTU PDU header area. This area MAY contain an Authentication TLV and MUST be padded with the Padding TLV to the exact size being tested. Since the minimum size of the Padding TLV is 2 bytes, it would be impossible to pad to exact size if the total length of the required information-bearing fixed fields and TLVs added up to 1 byte less than the desired length. However, the length of the fixed fields and substantive TLVs for MTU PDUs is expected to be quite small compared with their minimum length (minimum 1470-byte MTU on an IEEE 802.3 link, for example), so this should not be a problem. 🫶
4. Use of Existing PDUs and TLVs 💖
the sub-sections below give you the tea on how TRILL uses PDUs and TLVs that already exist 🧚
4.1. TRILL IIH PDUs 🎀
the TRILL IIH PDU is the TRILL-flavoured version of the IIH PDU 💅 Section 4.4 of the TRILL standard [RFC6325] and [RFC7177] spell out the contents of the TRILL IIH and how it differs from Layer 3 LAN IIH PDU use. The adjacency state machinery for TRILL neighbors is specified in detail in [RFC7177]. 🦋
In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header are the same as a Level 1 IIH PDU. 🌸
The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored if it appears there. Instead, TRILL LAN IIH PDUs use the TRILL Neighbor TLV (see Section 2.5). 🙈
4.2. Area Address 🌈
TRILL uses a fixed zero Area Address as specified in [RFC6325], Section 4.2.3. This is encoded in a 4-byte Area Address TLV (TLV #1) as follows: ✨
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01, Area Address Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02, Length of Value | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01, Length of Address | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00, zero Area Address | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.3. Protocols Supported 💜
NLPID (Network Layer Protocol ID) 0xC0 has been assigned to TRILL [RFC6328]. A Protocols Supported TLV (#129, [RFC1195]) including that value appears in TRILL IIH PDUs and LSP number zero PDUs. 👑
4.4. Link State PDUs (LSPs) 🔥
An LSP number zero MUST NOT be originated larger than 1470 bytes, but a larger LSP number zero successfully received MUST be processed and forwarded normally. 💀
4.5. Originating LSP Buffer Size 🍓
The originatingLSPBufferSize TLV (#14) MUST be in LSP number zero; however, if found in other LSP fragments, it is processed normally. Should there be more than one originatingLSPBufferSize TLV for an IS, the minimum size, but not less than 1470, is used. 🧚
5. IANA Considerations 🎀
this section gives IANA considerations for the TLVs, sub-TLVs, and PDUs specified herein. A number of new code points are assigned, and those that were assigned by [RFC6326] are included here for convenience. IANA has replaced all [RFC6326] references in the IANA registries with references to this document. 💖
5.1. TLVs 🎀
Okay so this doc specifies two IS-IS TLV types 💖: the Group Address TLV (GADDR-TLV; type 142) and the TRILL Neighbor TLV (type 145). The table below shows which PDUs these TLVs are allowed in for TRILL, plus the section where each one is discussed. The last "NUMBER" column is how many times the TLV can show up in its PDU (or across the set of PDUs for LSPs). For both of these it's "*", which means the TLV MAY occur 0, 1, or more times ✨
Section TLV IIH LSP SNP Purge NUMBER
======= === === === === ===== ======
GADDR-TLV 2.1 142 n y n n *
TRILL Neighbor TLV 2.5 145 y n n n *IANA registered these two code points in the IANA IS-IS TLV registry. The "Section" and "NUMBER" columns don't matter for that registry, so they get ignored there 🦋
5.2. Sub-TLVs 🌸
This doc specifies a bunch of sub-TLVs 🧚. The second table below shows which TLVs they live in and where they're discussed. Whether a sub-TLV can occur in a given TLV depends on the "X" in that column, and the first table explains what each column header means. Sometimes one column header covers two different TLVs the sub-TLV can show up in 👑
Column Head TLV RFC TLV Name
=========== ===== ======== ==============
Grp. Adr. 142 7176 Group Address
MT Port 143 6165 MT-Port-Cap-TLV
MT Cap. 242 4971 Router CAPABILITY
144 6329 MT-Capability
Ext. Reach 22 5305 Extended IS Reachability
222 5120 MT-ISNThe final "NUMBER" column in the next table says how many times a sub-TLV can appear, counted across all of its TLV occurrences in one PDU (or the set of PDUs for LSPs). Here's the breakdown 💅:
- 0-1 = MAY occur zero or one times.
- 1 = MUST occur exactly once. If it's absent, the PDU is ignored. If it occurs more than once, results are unspecified.
- * = MAY occur 0, 1, or more times.
The "Section" and "NUMBER" values don't matter to the IANA sub-registries 🙈
sub- Grp. MT MT Ext.
Name Section TLV# Adr. Port Cap. Reach NUMBER
=================================================================
GMAC-ADDR 2.1.1 1 X - - - *
GIP-ADDR 2.1.2 2 X - - - *
GIPV6-ADDR 2.1.3 3 X - - - *
GLMAC-ADDR 2.1.4 4 X - - - *
GLIP-ADDR 2.1.5 5 X - - - *
GLIPV6-ADDR 2.1.6 6 X - - - *
VLAN-FLAGS 2.2.1 1 - X - - 1
Enabled-VLANs 2.2.2 2 - X - - *
AppointedFwrdrs 2.2.3 3 - X - - *
PORT-TRILL-VER 2.2.4 7 - X - - 0-1
VLANs-Appointed 2.2.5 8 - X - - *
NICKNAME 2.3.2 6 - - X - *
TREES 2.3.3 7 - - X - 0-1
TREE-RT-IDs 2.3.4 8 - - X - *
TREE-USE-IDs 2.3.5 9 - - X - *
INT-VLAN 2.3.6 10 - - X - *
TRILL-VER 2.3.1 13 - - X - 0-1
VLAN-GROUP 2.3.7 14 - - X - *
INT-LABEL 2.3.8 15 - - X - *
RBCHANNELS 2.3.9 16 - - X - *
AFFINITY 2.3.10 17 - - X - *
LABEL-GROUP 2.3.11 18 - - X - *
MTU 2.4 28 - - - X 0-1
=================================================================
Name Section sub- Grp. MT MT Ext. NUMBER
TLV# Adr. Port Cap. ReachIANA put the newly assigned sub-TLV numbers from that table into the matching existing sub-TLV registries, based on which column has the X. The sub-TLVs from NICKNAME through VLAN-GROUP used to exist only in the sub-TLV registry under TLV 242. IANA added each of them, with the same sub-TLV number, to the existing registry under TLV 144 too 🌈
5.3. PDUs ⭐
The IS-IS PDUs registry stays as [RFC6326] set it up. The only difference is that the references to [RFC6326] now point to this document 🫶
5.4. Reserved and Capability Bits 💜
Any reserved bits (R), bits in reserved fields (RESV), or capabilities bits in the PORT-TRILL-VER and TRILL-VER sub-TLVs get allocated through IETF Review [RFC5226]. That goes for anything written in this doc as "MUST be sent as zero and ignored on receipt" or something similar 🔥
Two sub-registries were created inside the TRILL Parameters Registry 🍓
Sub-Registry Name: TRILL-VER Sub-TLV Capability Flags
Registration Procedures: IETF Review
Reference: (This document)
Bit Description Reference
===== ============= ===========
0 Affinity sub-TLV support. [Affinity]
1 FGL-safe [RFC7172]
2-13 Unassigned
14-31 Extended header flag support. [RFC7179] Sub-Registry Name: PORT-TRILL-VER Sub-TLV Capability Flags
Registration Procedures: IETF Review
Reference: (This document)
Bit Description Reference
===== ============= ===========
0 Hello reduction support. [RFC7180]
1-2 Unassigned
3-13 Hop-by-hop extended flag support. [RFC7179]
14-31 Unassigned5.5. TRILL Neighbor Record Flags 🦋
One more sub-registry got made inside the TRILL Parameters Registry 💖
Sub-Registry Name: TRILL Neighbor TLV NEIGHBOR RECORD Flags
Registration Procedures: Standards Action
Reference: (This document)
Bit Short Name Description Reference
============== ============= ===========================
0 Fail Failed MTU test [RFC6325][RFC7176][RFC7177]
1 OOMF Offering OOMF service [RFC7180]
2-7 - Unassigned6. Security Considerations 🔥
For the general TRILL protocol security stuff, check out the TRILL base protocol standard [RFC6325] 💅
This doc doesn't bring any new security issues for IS-IS 🌸 You can use IS-IS security to lock down the IS-IS messages covered here. Look at [RFC5304] and [RFC5310]. Even when IS-IS authentication is turned on, replayed Hello packets can cause denial-of-service conditions, so see [RFC6039] for the details. These issues are pretty similar in scope to the ones in Section 6.2 of [RFC6325], and the same mitigations may apply ⚠️
Replays of Hello packets are a sneaky denial-of-service threat, even with authentication on. Don't sleep on it, bestie 💀
7. Changes from RFC 6326 🧚
These are the non-editorial changes from [RFC6326], listed out for you below ✨
- Added five sub-TLVs under the Group Address (GADDR) TLV covering VLAN-labeled IPv4 and IPv6 addresses and fine-grained-labeled MAC, IPv4, and IPv6 addresses (Sections 2.1.2, 2.1.3, 2.1.4, 2.1.5, and 2.1.6).
- Added the PORT-TRILL-VER sub-TLV (Section 2.2.4).
- Added the VLANs-Appointed sub-TLV (Section 2.2.5).
- Changed the TRILL-VER sub-TLV as listed below.
- a. Added 4 bytes of TRILL Header extended flags and capabilities supported information.
- b. Required that the TRILL-VER sub-TLV appear in LSP number zero.
These TRILL-VER changes are backward compatible 🫶. The [RFC6326]-conformant TRILL implementations so far have only supported version zero and haven't supported any optional capabilities or extended flags, which is what the absence of the TRILL-VER sub-TLV indicates. So if an [RFC6326]-conformant TRILL implementation rejects this sub-TLV because of the changes in this document, the worst it can do is conclude that version zero with no extended flags or capabilities is indicated, which is the best an [RFC6326]-conformant TRILL implementation can do anyway. Likewise, a TRILL implementation that supports TRILL-VER as specified here and rejects TRILL-VER sub-TLVs in an [RFC6326]-conformant TRILL implementation, because they aren't in LSP number zero, will conclude that the implementation supports only version zero with no extended flag or capabilities support. That conclusion is correct (Section 2.3.1).
- Clarified the use of invalid VLAN IDs (0x000 and 0xFFF) in the Appointed Forwarders sub-TLV and the Interested VLANs and Spanning Tree Roots sub-TLV (Sections 2.2.3 and 2.3.6).
- Added the Interested Labels and Spanning Tree Roots sub-TLV to indicate attachment of an IS to a fine-grained label [RFC7172], analogous to the existing Interested VLANs and Spanning Tree Roots sub-TLV for VLANs (Section 2.3.8).
- Added the RBridge Channel Protocols sub-TLV so ISs can announce the RBridge Channel protocols they support (Section 2.3.9).
- Permitted specification of the length of the link SNPA field in TRILL Neighbor TLVs. This change is backward compatible because the size of 6 bytes is specially encoded as zero, the previous value of the bits in the new SIZE field (Section 2.5).
- Made the size of the MTU PDU Header Probe Source ID and Ack Source ID fields be the ID Length from the IS-IS PDU Header rather than the fixed value 6 (Section 3).
- For robustness, required that LSP number zero PDUs be originated as no larger than 1470 bytes but processed regardless of size (Section 4.4).
- Required that the originatingLSPBufferSize TLV, if present, appear in LSP number zero (Section 4.5).
- Created sub-registries for and specified the IANA Considerations policy for reserved and capability bits in the TRILL version sub-TLVs (Section 5.4).
- Added the distribution tree Affinity sub-TLV so ISs can request distribution tree attachments (Section 2.3.10).
- Added the LABEL-GROUP sub-TLV analogous to the VLAN-GROUP sub-TLV (Section 2.3.11).
- Added multi-topology to permit sub-TLVs previously only in the Router Capability TLV to also appear in the MT-Capability TLV, and to permit the MTU sub-TLV previously limited to the Extended Reachability TLV to also appear in the MT-ISN TLV.
- Added a sub-registry for Neighbor TLV Neighbor RECORD flag bits (Section 5.5).
- Explicitly stated that if the number of sources in a GADDR-TLV sub-TLV is zero, it indicates a listener for (*,G), that is, a listener not restricted by source (Section 2.1).
8. References 📚
8.1. Normative References
okay so these are the docs the spec needs you to have read, bestie 📚✨ the list is stuff like ISO-10589, RFC1195, and RFC1982, plus a whole TRILL squad (RFC6325, RFC7172, RFC7177, RFC7178, RFC7179, RFC7180) 🦋
[ISO-10589]
International Organization for Standardization,
"Intermediate System to Intermediate System intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", Second
Edition, November 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
"Intermediate System to Intermediate System (IS-IS)
Extensions for Advertising Router Information", RFC 4971,
July 2007.
[RFC5120] 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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, April 2011.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer
Protocol Identifiers", BCP 164, RFC 6328, July 2011.
[RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE
802.1aq Shortest Path Bridging", RFC 6329, April 2012.
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
Hu, "Routing Bridges (RBridges): Appointed Forwarders",
RFC 6439, November 2011.
[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, May 2014.
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, Y., and
V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, May 2014.
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
Ward, "Transparent Interconnection of Lots of Links
(TRILL): RBridge Channel Support", RFC 7178, May 2014.
[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C.
Bestler, "Transparent Interconnection of Lots of Links
(TRILL): Header Extension", RFC 7179, May 2014.
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and
A. Banerjee, "Transparent Interconnection of Lots of
Links (TRILL): Clarifications, Corrections, and Updates",
RFC 7180, May 2014.8.2. Informative References
these ones are more like bonus reading 🌸 they cover the errata, the IS-IS crypto auth stuff (RFC5304, RFC5310, RFC6039), the old TRILL-uses-IS-IS doc RFC6326 (which this one replaces, iykyk 💅), IANA stuff for IEEE 802 (RFC7042), BFD support (RFC7175), and three Work in Progress drafts (Affinity, MultiLevel, Resilient) 🧚
[Err2869] RFC Errata, Errata ID 2869, RFC 6326,
<http://www.rfc-editor.org>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010.
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
Ghanwani, "Transparent Interconnection of Lots of Links
(TRILL) Use of IS-IS", RFC 6326, July 2011.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, October 2013.
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee,
"Transparent Interconnection of Lots of Links (TRILL):
Bidirectional Forwarding Detection (BFD) Support", RFC
7175, May 2014.
[Affinity] Senevirathne, T., Pathangi, J., and J. Hudson,
"Coordinated Multicast Trees (CMT) for TRILL", Work in
Progress, April 2014.
[MultiLevel]
Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai,
"Flexible Multilevel TRILL (Transparent Interconnection of
Lots of Links)", Work in Progress, January 2014.
[Resilient]
Zhang, M. Senevirathne, T., Pathangi, J., Banerjee, A.,
and A. Ghanwani, "TRILL Resilient Distribution Trees",
Work in Progress, December 2013.9. Acknowledgements ✨
okay the shoutouts 🫶 the authors say a big thank you to Ross Callon, Spencer Dawkins, Adrian Farrel, Alexey Melnikov, Radia Perlman, Carlos Pignataro, and Joe Touch for their contributions and reviews 💖
they also thank the people who helped with [RFC6326] 🌈: Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam Hartman, Dan Romascanu, Dave Ward, and Russ White. and a special hug for Mike Shand for his detailed and helpful comments 🥹💜
Authors' Addresses 🎀
here's where to find the authors, bestie 📮
Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Tissa Senevirathne
Cisco Systems
375 East Tasman Drive,
San Jose, CA 95134
USA
Phone: +1-408-853-2291
EMail: tsenevir@cisco.com
Anoop Ghanwani
Dell
5450 Great America Parkway
Santa Clara, CA 95054
USA
EMail: anoop@alumni.duke.edu
Dinesh Dutt
Cumulus Networks
1089 West Evelyn Avenue
Sunnyvale, CA 94086
USA
EMail: ddutt.ietf@hobbesdutt.com
Ayan Banerjee
Insieme Networks
210 West Tasman Drive
San Jose, CA 95134
USA
EMail: ayabaner@gmail.com🦋 and that's a wrap on the whole RFC, bestie. you absolutely slayed the protocol reading, no cap 💅👑
📦 where this page comes from
- ietf: rfc7176 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms