RFC 7780
Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
Internet Engineering Task Force (IETF) 💖
Okay so bestie, this is part 1 of 11 of RFC 7780, and it's a whole glow-up for TRILL 🦋✨
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7780 M. Zhang
Obsoletes: 7180 Huawei
Updates: 6325, 7177, 7179 R. Perlman
Category: Standards Track EMC
ISSN: 2070-1721 A. Banerjee
Cisco
A. Ghanwani
Dell
S. Gupta
IP Infusion
February 2016Title block tea ☕: this is RFC 7780, titled "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates". It's a Standards Track doc from February 2016, written by D. Eastlake 3rd, M. Zhang (Huawei), R. Perlman (EMC), A. Banerjee (Cisco), A. Ghanwani (Dell), and S. Gupta (IP Infusion). It obsoletes RFC 7180 and updates RFCs 6325, 7177, and 7179. The ISSN is 2070-1721. Iconic 💅
Abstract ✨
Okay so, ever since the TRILL base protocol came out in 2011, people have actually been building and deploying it, and that's how the errata in RFC 6325 got found 🙈 RFC 7177, RFC 7357, and an intended replacement of RFC 6439 cover clarifications and updates for adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively. This document is where all the other known clarifications, corrections, and updates live 🌸 It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC) and it updates RFCs 6325, 7177, and 7179 🫶
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 info on Internet Standards is in Section 2 of RFC 5741 📚
Info about the current status of this doc, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc7780 🦋
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 are provided without warranty as described in the Simplified BSD License 🔥
Table of Contents 🧚
1. Introduction (Changed) ..........................................5
1.1. Precedence (Changed) .......................................5
1.2. Changes That Are Not Backward Compatible (Unchanged) .......6
1.3. Terminology and Acronyms (Changed) .........................6
2. Overloaded and/or Unreachable RBridges (Unchanged) ..............7
2.1. Reachability ...............................................8
2.2. Distribution Trees .........................................8
2.3. Overloaded Receipt of TRILL Data Packets ...................9
2.3.1. Known Unicast Receipt ...............................9
2.3.2. Multi-Destination Receipt ...........................9
2.4. Overloaded Origination of TRILL Data Packets ...............9
2.4.1. Known Unicast Origination ..........................10
2.4.2. Multi-Destination Origination ......................10
2.4.2.1. An Example Network ........................10
2.4.2.2. Indicating OOMF Support ...................11
2.4.2.3. Using OOMF Service ........................11
3. Distribution Trees and RPF Check (Changed) .....................12
3.1. Number of Distribution Trees (Unchanged) ..................12
3.2. Distribution Tree Update Clarification (Unchanged) ........12
3.3. Multicast Pruning Based on IP Address (Unchanged) .........13
3.4. Numbering of Distribution Trees (Unchanged) ...............13
3.5. Link Cost Directionality (Unchanged) ......................13
3.6. Alternative RPF Check (New) ...............................14
3.6.1. Example of the Potential Problem ...................14
3.6.2. Solution and Discussion ............................15
4. Nickname Selection (Unchanged) .................................17
5. MTU (Maximum Transmission Unit) (Unchanged) ....................18
5.1. MTU-Related Errata in RFC 6325 ............................19
5.1.1. MTU PDU Addressing .................................19
5.1.2. MTU PDU Processing .................................20
5.1.3. MTU Testing ........................................20
5.2. Ethernet MTU Values .......................................20
6. TRILL Port Modes (Unchanged) ...................................21
7. The CFI/DEI Bit (Unchanged) ....................................22
8. Other IS-IS Considerations (Changed) ...........................23
8.1. E-L1FS Support (New) ......................................24
8.1.1. Backward Compatibility .............................24
8.1.2. E-L1FS Use for Existing (Sub-)TLVs .................25
8.2. Control Packet Priorities (New) ...........................26
8.3. Unknown PDUs (New) ........................................27
8.4. Nickname Flags APPsub-TLV (New) ...........................27
8.5. Graceful Restart (Unchanged) ..............................29
8.6. Purge Originator Identification (New) .....................29
9. Updates to RFC 7177 (Adjacency) (Changed) ......................30
10. TRILL Header Update (New) .....................................31
10.1. Color Bit ................................................32
10.2. Flags Word Changes (Update to RFC 7179) ..................32
10.2.1. Extended Hop Count ................................32
10.2.1.1. Advertising Support ......................33
10.2.1.2. Ingress Behavior .........................33
10.2.1.3. Transit Behavior .........................33
10.2.1.4. Egress Behavior ..........................34
10.2.2. Extended Color Field ..............................34
10.3. Updated Flags Word Summary ...............................35
11. Appointed Forwarder Status Lost Counter (New) .................35
12. IANA Considerations (Changed) .................................37
12.1. Previously Completed IANA Actions (Unchanged) ............37
12.2. New IANA Actions (New) ...................................37
12.2.1. Reference Updated .................................37
12.2.2. The "E" Capability Bit ............................37
12.2.3. NickFlags APPsub-TLV Number and Registry ..........38
12.2.4. Updated TRILL Extended Header Flags ...............38
12.2.5. TRILL-VER Sub-TLV Capability Flags ................39
12.2.6. Example Nicknames .................................39
13. Security Considerations (Changed) .............................39
14. References ....................................................40
14.1. Normative References .....................................40
14.2. Informative References ...................................42
Appendix A. Life Cycle of a TRILL Switch Port (New) ...............45
Appendix B. Example TRILL PDUs (New) ..............................48
B.1. LAN Hello over Ethernet ...................................48
B.2. LSP over PPP ..............................................50
B.3. TRILL Data over Ethernet ..................................51
B.4. TRILL Data over PPP .......................................52
Appendix C. Changes to Previous RFCs (New) ........................53
C.1. Changes to Obsoleted RFC 7180 .............................53
C.1.1. Changes ..............................................53
C.1.2. Additions ............................................53
C.1.3. Deletions ............................................54
C.2. Changes to RFC 6325 .......................................55
C.3. Changes to RFC 7177 .......................................55
C.4. Changes to RFC 7179 .......................................55
Acknowledgments ...................................................56
Authors' Addresses ................................................56Those page numbers are the map to the whole doc, babe 🗺️ Just know that the sections and subsections go by their exact numbers, so when something says "see Section 4.2.1" you can find it instantly 💅
1. Introduction (Changed) 🌸
Since the TRILL base protocol [RFC6325] came out in 2011, active development and deployment of TRILL have revealed errors in the specification [RFC6325] and several areas that could use clarifications or updates 🔍
[RFC7177], [RFC7357], and [RFC6439bis] provide clarifications and updates for adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively 🦋 This document provides other known clarifications, corrections, and updates to [RFC6325], [RFC7177], and [RFC7179]. This document obsoletes [RFC7180] (the previous TRILL "clarifications, corrections, and updates" document), updates [RFC6325], updates [RFC7177] as described in Section 9, and updates [RFC7179] as described in Sections 10.2 and 10.3. The changes to these RFCs are summarized in Appendix C 💜
Sections of this document are tagged as whether they're "New" technical material, material that has been technically "Changed", or material that is technically "Unchanged". You can tell by one of those three words in parentheses at the end of the section header 🎀 A section with only editorial changes is tagged "(Unchanged)". If there's no tag, the first tag you hit going up to the higher-level section headers (the ones with shorter section numbers) applies. Appendix C describes the changes, summarizes the material added, and lists the material deleted 📝
1.1. Precedence (Changed) 👑
In the event of any conflicts between this document and [RFC6325], [RFC7177], or [RFC7179], this document takes precedence 🫶
In addition, Section 1.2 of [RFC6325] ("Normative Content and Precedence") is updated to provide a more complete precedence ordering of the sections of [RFC6325], as shown below. Sections to the left take precedence over sections to their right. There are no known conflicts between these sections. However, Sections 1 and 2 are less detailed and don't mention every corner case, while the later sections of [RFC6325] are more detailed. This precedence is specified as a fallback in case some conflict is found in the future 🌈
4 > 3 > 7 > 5 > 2 > 6 > 1To be continued in part 2 of 11, bestie 🧚💖
1.2. Changes That Are Not Backward Compatible (Unchanged) 💅
okay so the change made in Section 3.4 below (same as Section 3.4 of [RFC7180], unchanged) is not backward compatible with [RFC6325] 💀 but it got adopted anyway because it cuts down on distribution tree changes when the topology shifts 🦋
several other changes in here are fixes for errata on [RFC6325] (we're talking [Err3002], [Err3003], [Err3004], [Err3052], [Err3053], and [Err3508]) and they might not be backward compatible with older implementations that followed the errors in the spec 😭 not their fault, the spec was just wrong lol
1.3. Terminology and Acronyms (Changed) 🎀
this doc uses the acronyms from [RFC6325], and some of them get repeated below for convenience, plus a few extra acronyms and terms, so here's the whole vibe check:
- BFD - Bidirectional Forwarding Detection.
- Campus - A TRILL network consisting of TRILL switches, links, and possibly bridges bounded by end stations and IP routers. For TRILL, there is no "academic" implication in the name "campus".
- CFI - Canonical Format Indicator [802].
- CSNP - Complete Sequence Number PDU.
- DEI - Drop Eligibility Indicator [802.1Q-2014].
- FGL - Fine-Grained Labeling [RFC7172].
- FS-LSP - Flooding Scope LSP.
- OOMF - Overload Originated Multi-destination Frame.
- P2P - Point-to-point.
- PDU - Protocol Data Unit.
- PSNP - Partial Sequence Number PDU.
- RBridge - Routing Bridge, an alternative name for a TRILL switch.
- RPFC - Reverse Path Forwarding Check.
- SNPA - Subnetwork Point of Attachment (for example, Media Access Control (MAC) address).
- ToS - Type of Service.
- TRILL - Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer.
- TRILL switch - A device implementing the TRILL protocol. An alternative name for an RBridge.
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
in this doc, a "packet" usually means a TRILL Data packet or TRILL IS-IS packet that's received from or sent to a TRILL switch, while a "frame" usually means a native frame being received from or sent to an end station. (The word "frame" also shows up in other contexts, like the "Frame Check Sequence" at the end of Ethernet transmissions, so don't get confused 🙈)
2. Overloaded and/or Unreachable RBridges (Unchanged) 🌸
in this section, "neighbor" only refers to actual RBridges and ignores pseudonodes, so no pseudonodes allowed in the friend group 💖
RBridges can be in overload, which is shown by the [IS-IS] overload flag in their LSPs (Link State PDUs). That means either (1) they can't hold the entire link-state database and so they don't have a view of the entire topology, or (2) they've been configured to have the overload bit set. networks should be engineered to avoid actual link-state overload, but it might still happen in different situations, like if a very large campus has one or more low-end TRILL switches 🫠
it's a super common operational move to set the overload bit in an [IS-IS] router (like a TRILL switch) while doing maintenance on it that might mess with its ability to forward packets correctly. this usually leaves the router reachable for maintenance traffic, but transit traffic won't get routed through it 🧚 (also, in some cases, TRILL lets you set the overload bit in the pseudonode of a link to stop TRILL Data traffic on an access link (see Section 4.9.1 of [RFC6325]).)
[IS-IS] and TRILL make a reasonable effort to do what they can, even if some TRILL switches/routers are in overload. they can do pretty well if a few scattered nodes are in overload. however, actual least-cost paths are no longer assured if any TRILL switches are in overload ⚠️
for the effect of overload on the appointment of forwarders, see [RFC6439bis] ✨
2.1. Reachability 🦋
packets are not least-cost routed through an overloaded TRILL switch, although they may originate or terminate at one. also, packets will not be least-cost routed over links with cost 2**24 - 1 [RFC5305]. those links are reserved for traffic-engineered packets, and how those get handled is beyond the scope of this document 🙃
so a portion of the campus can end up unreachable for least-cost routed TRILL Data, because all paths to it go either through a link with cost 224 - 1 or through an overloaded RBridge. for example, an RBridge (TRILL switch) RB1 is not reachable by TRILL Data if all of its neighbors are connected to RB1 by links with cost 224 - 1. these RBridges are called "data unreachable" 💀
the link-state database at an RBridge (like RB1) can also contain info about TRILL switches that are unreachable by IS-IS link-state flooding because of link or RBridge failures. when those failures split the campus, the TRILL switches next to the failure, and on the same side as RB1, will update their LSPs to show the lack of connectivity, and RB1 will get those updates. so RB1 knows about the partition 👀 nodes on the far side of the partition are both IS-IS unreachable and data unreachable from RB1. BUT the LSPs RB1 holds for TRILL switches on the far side won't get updated, and they may stick around until they time out, which could be tens of minutes or longer. (the default in [IS-IS] is twenty minutes.) 😩
2.2. Distribution Trees 🌈
an RBridge in overload can't be trusted to correctly calculate distribution trees or correctly perform the RPFC (Reverse Path Forwarding Check). so it can't be trusted to forward multi-destination TRILL Data packets either. it can only show up as a leaf node in a TRILL multi-destination distribution tree. and if all the immediate neighbors of an RBridge are overloaded, then it gets left out of all trees in the campus and is unreachable by multi-destination packets 🥲
when an RBridge figures out which nicknames to use as the roots of the distribution trees it calculates, it MUST ignore all nicknames held by TRILL switches that are in overload or are data unreachable. when calculating RPFCs for multi-destination packets, an RBridge such as RB1 MAY, to avoid calculating unnecessary RPFC state information, ignore any trees that cannot reach RB1, even if other RBridges list those trees as trees that other TRILL switches might use. (However, see Section 3.)
2.3. Overloaded Receipt of TRILL Data Packets 📬
the receipt of TRILL Data packets by overloaded RBridge RB2 is covered in the subsections below. in every case, the normal Hop Count decrement is done, and the TRILL Data packets get discarded if the result is less than one or if the Egress Nickname is illegal 🗑️
2.3.1. Known Unicast Receipt 💌
RB2 won't usually receive unicast TRILL Data packets unless it's the egress, and then it egresses and delivers the data normally. if RB2 gets a unicast TRILL Data packet for which it is not the egress (maybe because a neighbor doesn't know yet that it's in overload), RB2 MUST NOT discard the packet just because the egress is an unknown nickname, since it might not know about all nicknames due to its overloaded condition. if any neighbor other than the one the packet came from is not overloaded, it MUST attempt to forward the packet to one of those neighbors, selected at random [RFC4086]. if there's no such neighbor, the packet is discarded 🎲
2.3.2. Multi-Destination Receipt 📣
if RB2 in overload receives a multi-destination TRILL Data packet, RB2 MUST NOT apply an RPFC, because due to overload it might not do that correctly. RB2 egresses and delivers the frame locally where it is Appointed Forwarder for the frame's VLAN (or, if the packet is FGL, for the VLAN that FGL maps to at the port), subject to any multicast pruning. but because, as said above, RB2 can only be the leaf of a distribution tree, it MUST NOT forward a multi-destination TRILL Data packet (except as an egressed native frame where RB2 is Appointed Forwarder) 🫶
2.4. Overloaded Origination of TRILL Data Packets 🚀
overloaded origination of unicast TRILL Data packets with a known egress, and of multi-destination packets, is covered in the subsections below.
2.4.1. Known Unicast Origination 🍓
when RB2, an overloaded RBridge, ingresses or creates a known destination unicast data packet, it delivers it locally if the destination is local. otherwise, RB2 unicasts it to any neighbor TRILL switch that is not overloaded. it MAY use whatever routing information it has to help select the neighbor 🧭
2.4.2. Multi-Destination Origination 🎭
overloaded RBridge RB2 ingressing or creating a multi-destination data packet is a more complex scenario than the known unicast case, as discussed below 😵💫
2.4.2.1. An Example Network 🗺️
for example, check out the network diagram below. for simplicity, end stations and any bridges are not shown. there is one distribution tree, with RB4 as its root, shown with double lines. only RBridge RB2 is overloaded 👑
+-----+ +-----+ +-----+ +-----+
| RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 |
+-----+ +--+--+ +-++--+ +--+--+
| || |
+---+---+ || |
+------+RB2(ov)|======++ |
| +-------+ || |
| || |
+--+--+ +-----+ ++==++=++ +--+--+
| RB8 +====+ RB6 +===++ RB4 ++=====+ RB9 |
+-----+ +-----+ ++=====++ +-----+since RB2 is overloaded, it doesn't know what the distribution tree or trees are for the network. so there's no way it can give normal TRILL Data service for multi-destination native frames. so RB2 tunnels the frame in a TRILL Data packet to a neighbor that is not overloaded, if it has one that has signaled it's willing to offer this service. RBridges indicate this in their Hellos, as described below. this service is called the OOMF (Overload Originated Multi-destination Frame) service 🌷
- The multi-destination frame MUST NOT be locally distributed in native form at RB2, because this would cause the frame to be delivered twice. Instead, it is tunneled to a neighbor as described in this section. for example, if RB2 locally distributed a multicast native frame and then tunneled it to RB5, RB2 would get a copy of the frame when RB3 transmitted it as a TRILL Data packet on the multi-access RB2-RB3-RB4 link. since RB2 would, in general, not be able to tell that this was a frame it had tunneled for distribution, RB2 would decapsulate it and locally distribute it a second time 🙈
- on the other hand, if there is no neighbor of RB2 offering RB2 the OOMF service, RB2 cannot tunnel the frame to a neighbor. in this case, RB2 MUST locally distribute the frame where it is Appointed Forwarder for the frame's VLAN, and optionally subject to multicast pruning 🫠
2.4.2.2. Indicating OOMF Support ✨
okay so RB3 tells RB2 it's down to offer the OOMF service by setting a bit in the TRILL Neighbor TLV inside its TRILL Hellos 🫶. That bit is tied to the SNPA (Subnetwork Point of Attachment, also known as MAC address) of RB2 on the link (see the IANA Considerations section). Overloaded RBridge RB2 can only send multi-destination TRILL Data packets out to the campus if a neighbor of RB2 that is not in overload offers RB2 the OOMF service. If RB2 doesn't have OOMF service available, it can still receive multi-destination packets from non-overloaded neighbors. And if RB2 originates or ingresses a frame like that, it just distributes it locally in native form 💅.
2.4.2.3. Using OOMF Service 🦋
so if RB2 sees this OOMF (Overload Originated Multi-destination Frame) service advertised for it by any of its neighbors on any link it connects to, it picks one of them. How it picks is beyond the scope of this document, so no spoilers 🙈. Say RB2 picks RB3 to handle the multi-destination packets it originates. Then RB2 MUST advertise in its LSP that it might use any of the distribution trees RB3 advertises, so that the RPFC works in the rest of the campus. Basically, even though RB2 is overloaded, it MUST keep this info from RB3's LSPs, because it's directly connected to RB3 and will receive them 🌸.
RB2 then wraps these frames up as TRILL Data packets to RB3 like this: "M" bit = 0; Hop Count = 2; Ingress Nickname = a nickname held by RB2; and, since RB2 can't tell which distribution tree RB3 will use, Egress Nickname = a special nickname that means "this is an OOMF packet" (see the IANA Considerations section). Then RB2 unicasts this TRILL Data packet to RB3. (Implementation of Item 4 in Section 4 below gives reasonable assurance that, even while overloaded, the ingress nickname RB2 uses will be unique within at least the portion of the campus that is IS-IS reachable from RB2 🧚.)
When RB3 gets one of these packets, it does the following:
- changes the
Egress Nicknamefield to designate a distribution tree that RB3 normally uses, - sets the
"M"bit to one, - changes the
Hop Countto the value it would normally use if it were the ingress, and - forwards the TRILL Data packet on that tree.
RB3 MAY rate-limit how many packets it provides this service for, by discarding some of them from RB2. Giving OOMFs even a little bandwidth at RB3, maybe via the slow path, can be really important for getting services going at RB2 or at end stations connected to RB2, like DHCP and ARP/ND (Address Resolution Protocol / Neighbor Discovery) 💜. (Everyone sometimes needs a little OOMF (pronounced "oomph") to get off the ground 😭.)
3. Distribution Trees and RPF Check (Changed) 🌈
Two corrections, a clarification, and two updates related to distribution trees show up in the subsections below, along with an alternative, stronger RPF (Reverse Path Forwarding) check 👑. See also Section 2.2.
3.1. Number of Distribution Trees (Unchanged) 🎀
In [RFC6325], Section 4.5.2, page 56, point 2, fourth paragraph, the parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052]. It should read "(up to k if j is zero or the minimum of (j, k) if j is non-zero)".
3.2. Distribution Tree Update Clarification (Unchanged) 🍓
When a link-state database change causes a change in the distribution tree(s), several possible types of change can happen. If a tree root stays a tree root but the tree changes, then local forwarding and RPFC entries for that tree should be updated as soon as practical. Similarly, if a new nickname becomes a tree root, forwarding and RPFC entries for the new tree should be installed as soon as practical. However, if a nickname stops being a tree root and there's enough room in local tables, the forwarding and RPFC entries for the former tree MAY be kept, so that any multi-destination TRILL Data packets already in flight on that tree have a higher chance of being delivered 🚀.
3.3. Multicast Pruning Based on IP Address (Unchanged) 🌸
The TRILL base protocol specification [RFC6325] provides for, and recommends, pruning multi-destination packet distribution trees based on where IP multicast routers and listeners are. However, multicast listening is identified by derived MAC addresses, as communicated in the Group MAC Address sub-TLV [RFC7176] 🙃.
TRILL switches MAY communicate multicast listeners and prune distribution trees based on the actual IPv4 or IPv6 multicast addresses involved. Additional Group Address sub-TLVs are provided in [RFC7176] to carry this info. A TRILL switch that can only prune based on derived MAC addresses SHOULD calculate and use those derived MAC addresses from the multicast listener IPv4 or IPv6 address information it receives 🫶.
3.4. Numbering of Distribution Trees (Unchanged) 🔢
Section 4.5.1 of [RFC6325] says that when building distribution tree number j, node (RBridge) N that has multiple possible parents in the tree gets attached to possible parent number j mod p. Trees are numbered starting with 1, but possible parents are numbered starting with 0. So if there are two trees and two possible parents, then in tree 1 parent 1 gets selected, and in tree 2 parent 0 gets selected 🤯.
This is changed so that the selected parent MUST be (j-1) mod p. So in the case above, tree 1 selects parent 0, and tree 2 selects parent 1 ✨. This change is not backward compatible with [RFC6325]. If all RBridges in a campus don't determine distribution trees in the same way, then for most topologies, the RPFC will drop lots of multi-destination packets before they've been properly delivered 😭.
3.5. Link Cost Directionality (Unchanged) 🧭
Distribution tree construction, like other least-cost parts of TRILL, works even when link costs are asymmetric. So the cost of the hop from RB1 to RB2 can be different from the cost of the hop from RB2 to RB1. But it's essential that all RBridges calculate the same distribution trees, so they all have to use either the cost away from the tree root or the cost towards the tree root 💅. The text in Section 4.5.1 of [RFC6325] is incorrect, as documented in [Err3508]. The text says:
In other words, the set of potential parents for N, for the tree
rooted at R, consists of those that give equally minimal cost
paths from N to R and ...but the text should say "from R to N":
In other words, the set of potential parents for N, for the tree
rooted at R, consists of those that give equally minimal cost
paths from R to N and ...3.6. Alternative RPF Check (New) 🦋
[RFC6325] mandates a Reverse Path Forwarding (RPF) check on multi-destination TRILL Data packets, to avoid possible multiplication and/or looping of multi-destination traffic during TRILL campus topology transients 🌀. This check is logically performed at each TRILL switch input port. It decides whether a packet is arriving on the expected port, based on where the packet started (the ingress nickname) and the tree it's being distributed on. If not, the packet is silently discarded. This check is fine for point-to-point links. However, there are rare situations involving multi-access ("broadcast") links where a packet can get duplicated even with this RPF check and the other checks TRILL does 😱.
Section 3.6.1 gives an example of the potential problem, and Section 3.6.2 specifies a solution. The solution is an alternative, stronger RPF check that TRILL switches can implement in place of the RPF check discussed in [RFC6325] 👑.
3.6.1. Example of the Potential Problem 🕵️♀️
Consider this network:
F--A--B--C--o--D
|
EAll the links except the one between C, D, and E are point-to-point links. C, D, and E are connected over a broadcast link, represented by the pseudonode "o". For example, they could be connected by a bridged LAN. (Bridged LANs are transparent to TRILL.)
Although the choice of root doesn't matter here, assume D or F is chosen as the root of a distribution tree, so it's obvious that the tree looks just like the diagram above 🌳.
Now assume a link comes up from A to the same bridged LAN. The network then looks like this:
+--------+
| |
F--A--B--C--o--D
|
ELet's say the resulting tree in steady state includes all links except the B-C link. After the network has converged, a packet that starts from F goes F->A. Then A sends one copy on the A-B link, and another copy into the bridged LAN, from which it gets received by C and D 💫.
Now think about a transition stage where A and D have acted on the new LSPs and programmed their forwarding plane, while B and C haven't done so yet. This means B and C both consider the link between them to still be part of the tree. In this case, a packet that starts out from F and reaches A gets copied by A onto the A-B link and into the bridged LAN. D's RPF check says to accept packets on this tree coming from F over its port on the bridged LAN, so it gets accepted. D is also adjacent to A on the tree, so the tree adjacency check, a separate check mandated by [RFC6325], also passes ✅.
However, the packet that reaches B gets sent out by B to C. C's RPF check still has the old state, so it thinks the packet is OK. C sends the packet along the old tree, which sends it into the bridged LAN. D receives one more packet, but the tree adjacency check passes at D because C is adjacent to D in the new tree as well. The RPF check also passes at D, because D's port on the bridged LAN is OK for receiving packets from F 🙃.
So during this transient state, D gets duplicates of every multi-destination packet ingressed at F (unless the packet gets pruned) until B and C act on the new LSPs and program their forwarding tables. 😭💀
3.6.2. Solution and Discussion 🦋
okay so the problem here comes from the RPF check in [RFC6325] only looking at the port a TRILL Data packet arrives on, the ingress nickname, and the tree being used. so the receiving switch checks whether {ingress nickname, tree, input port} is a valid combo based on its view of the campus topology. 💅 a multi-access link is actually multiple adjacencies stacked on one physical link, so to dodge the problem in Section 3.6.1, we need a stronger check that also includes the Layer 2 source address of the arriving TRILL Data packet. 🫶 (TRILL is a Layer 3 protocol, and TRILL switches are true routers. they basically strip the Layer 2 header off any arriving TRILL Data packet and slap a fresh one on for the next hop, so the Layer 2 source address tells you which previous TRILL switch forwarded it. iykyk 🌸)
what we actually need, instead of checking {ingress nickname, tree, input port}, is to check that {ingress nickname, source SNPA, tree, input port} is valid. ✨ (where "source SNPA" (Subnetwork Point of Attachment) is the Outer.MacSA for an Ethernet link.) it's true that [RFC6325] also requires a check that a multi-destination TRILL Data packet comes from a TRILL switch that is adjacent in the distribution tree being used, but that check is separate from the RPF check. so these two independent checks are not as powerful as the single unified check for a valid quadruplet. 👑
_______
/ \
RB1 ------ o ----- RB2
\_______/ngl this stronger RPF check comes with a cost though. 💀 in the simple case of a multi-access link where each TRILL switch has only one port on the link, it just makes the validity entries bigger by adding the source SNPA (Outer.MacSA). but say some TRILL switch RB1 has multiple ports attached to a multi-access link. in the figure above, RB1 has three ports on the multi-access link. RB1 is allowed to load split multi-destination traffic it's sending onto the link across those ports (Section 4.4.4 of [RFC6325]). now assume RB2 is another TRILL switch on the link, and RB2 is adjacent to RB1 in the distribution tree. the number of validity quadruplets at RB2 for ingress nicknames whose multi-destination traffic would arrive through RB1 gets multiplied by the number of ports RB1 has on the access link, because RB2 has to accept that traffic from any of those ports. 😭 such instances seem to be super rare in practice, but an RBridge could in principle have tens or even a hundred or more ports on a link, which would hugely blow up the RPF check state at RB2 when this stronger check is used. 🙈
another potential cost of the stronger RPF check is more transient loss of multi-destination TRILL Data packets during a topology change. 🌈 for TRILL switch D, the new stronger RPF check is (tree->A, Outer.MacSA=A, ingress=A, arrival port=if1), while the old one was (tree->A, Outer.MacSA=C, ingress=A, arrival port=if1).
say both A and B have switched to the new tree for multicast forwarding but D hasn't updated its RPF check yet. the multicast packet then gets dropped at D's input port, because D still expects a packet from "Outer.MacSA=C". 😱 but we don't have this packet loss issue if the weaker triplet check (tree->A, ingress=A, arrival port=if1) is used. so yeah, the stronger check can increase RPF check discards of multi-destination packets during topology transients. 🥺
because of these potential costs, implementing this stronger RPF check is optional. ✨ the TRILL base protocol is updated so that TRILL switches MUST, for multi-destination packets, either implement the RPF and other checks as described in [RFC6325] or implement this stronger RPF check as a substitute for the [RFC6325] RPF and tree adjacency checks. 🎀 and there's no problem with a campus having a mix of TRILL switches, some doing one of these RPF checks and some doing the other. 🫶
4. Nickname Selection (Unchanged) 🎀
nickname selection is covered by Section 3.7.3 of [RFC6325]. however, a few things should be noted:
- the second sentence in the second bullet item in Section 3.7.3 of [RFC6325] on page 25 is erroneous [Err3002] and gets corrected as follows:
o the occurrence of "IS-IS ID (LAN ID)" is replaced with "priority".
o the occurrence of "IS-IS System ID" is replaced with "7-byte IS-IS ID (LAN ID)".
the corrected sentence in [RFC6325] reads like this:
If RB1 chooses nickname x, and RB1 discovers, through receipt
of an LSP for RB2 at any later time, that RB2 has also chosen
x, then the RBridge or pseudonode with the numerically higher
priority keeps the nickname, or if there is a tie in priority,
the RBridge with the numerically higher 7-byte IS-IS ID
(LAN ID) keeps the nickname, and the other RBridge MUST select
a new nickname.- when examining the link-state database for nickname conflicts, nicknames held by IS-IS unreachable TRILL switches MUST be ignored, but nicknames held by IS-IS reachable TRILL switches MUST NOT be ignored even if they are data unreachable. 🔍
- an RBridge may need to select a new nickname, either initially because it has none or because of a conflict. when it does, the RBridge MUST consider as available all nicknames that don't appear in its link-state database or that appear to be held by IS-IS unreachable TRILL switches. however, it SHOULD give preference to new nicknames that don't appear to be held by any TRILL switch in the campus, reachable or unreachable, so as to minimize conflicts if IS-IS unreachable TRILL switches later become reachable. 🧚
- an RBridge, even after it has acquired a nickname that appears to have no conflicting claimant, MUST continue to monitor for conflicts with the nickname or nicknames it holds. it does this by monitoring any received LSPs that should update its link-state database for any occurrence of any of its nicknames held with higher priority by some other TRILL switch that is IS-IS reachable from it. if it finds such a conflict, it MUST select a new nickname, even when in overloaded state. (it's possible to receive an LSP that should update the link-state database but doesn't do so due to overload.) 💜
- in the very unlikely case that an RBridge can't obtain a nickname because all valid RBridge nicknames (0x0001 through 0xFFBF inclusive) are in use with higher priority by IS-IS reachable TRILL switches, it won't be able to act as an ingress, egress, or tree root, but it will still be able to function as a transit TRILL switch. 🌸 although it can't be a tree root, such an RBridge is included in distribution trees computed for the campus unless all its neighbors are overloaded. it would not be possible to send a unicast RBridge Channel message specifically to such a TRILL switch [RFC7178]; however, it will receive unicast RBridge Channel messages sent by a neighbor to the Any-RBridge egress nickname, and it will receive appropriate multi-destination RBridge Channel messages. 🦋
5. MTU (Maximum Transmission Unit) (Unchanged) 📏
MTU values in TRILL are derived from the originatingL1LSPBufferSize value communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS]. the campus-wide value Sz, as described in Section 4.3.1 of [RFC6325], is the minimum value of originatingL1LSPBufferSize for the RBridges in a campus, but not less than 1470. the MTU testing mechanism and limiting LSPs to Sz make sure the LSPs can be flooded by IS-IS, so IS-IS can operate properly. ✨
if an RBridge knows nothing about the MTU of the links or the originatingL1LSPBufferSize of other RBridges in a campus, its originatingL1LSPBufferSize should default to the minimum of the LSP size its TRILL IS-IS software can handle and the minimum MTU of the ports it might use to receive or transmit LSPs. 🍓 if an RBridge does know link MTUs or other RBridges' originatingL1LSPBufferSize, then, to avoid having to regenerate the local LSPs at a different maximum size, the RBridge's originatingL1LSPBufferSize SHOULD be configured to the minimum of (1) the smallest value that other RBridges are, or will be, announcing as their originatingL1LSPBufferSize and (2) a value small enough that the campus won't partition due to a significant number of links with limited MTUs. however, as specified in [RFC6325], originatingL1LSPBufferSize can in no case be less than 1470. 🙈 in a well-configured campus, to minimize any LSP regeneration due to resizing, all RBridges will be configured with the same originatingL1LSPBufferSize. 💖
Section 5.1 below corrects errata in [RFC6325], and Section 5.2 clarifies the meaning of various MTU limits for TRILL Ethernet links. 🌈
5.1. MTU-Related Errata in RFC 6325 🛠️
three MTU-related errata in [RFC6325] get corrected in the subsections below. 💅
5.1.1. MTU PDU Addressing
Section 4.3.2 of [RFC6325] incorrectly states that multi-destination MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links with the All-RBridges multicast address as the Outer.MacDA [Err3004]. as TRILL IS-IS PDUs, when multicast on an Ethernet link, these multi-destination MTU-probe and MTU-ack PDUs MUST be sent to the All-IS-IS-RBridges multicast address. 🫶
5.1.2. MTU PDU Processing
as discussed in [RFC6325] and (in more detail) [RFC7177], MTU-probe and MTU-ack PDUs MAY be unicast; however, Section 4.6 of [RFC6325] erroneously doesn't allow for this possibility [Err3003]. it gets corrected by replacing Item 1 in Section 4.6.2 of [RFC6325] with the following text, which TRILL switches MUST conform to:
1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either
All-IS-IS-RBridges or the unicast MAC address of the receiving
RBridge port, the frame is handled as described in
Section 4.6.2.1.the reference to "Section 4.6.2.1" in the above text is to that section in [RFC6325]. 🎀
5.1.3. MTU Testing
the last two sentences of Section 4.3.2 of [RFC6325] contain errors [Err3053]. they currently read like this:
If X is not greater than Sz, then RB1 sets the "failed minimum MTU
test" flag for RB2 in RB1's Hello. If size X succeeds, and X >
Sz, then RB1 advertises the largest tested X for each adjacency in
the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X
as an attribute of the link to RB2 in RB1's LSP.they should read like this:
If X is not greater than or equal to Sz, then RB1 sets the "failed
minimum MTU test" flag for RB2 in RB1's Hello. If size X
succeeds, and X >= Sz, then RB1 advertises the largest tested X
for each adjacency in the TRILL Hellos RB1 sends on that link,
and RB1 MAY advertise X as an attribute of the link to RB2 in
RB1's LSP.5.2. Ethernet MTU Values
Okay so, originatingL1LSPBufferSize is the maximum size an LSP is allowed to be, and it counts everything starting with and including the IS-IS 0x83 "Intradomain Routeing Protocol Discriminator" byte 🦋. In Layer 3 IS-IS it defaults to 1492 bytes, and the reason is iconic. Back in its previous life as DECnet Phase V, IS-IS was encoded using the SNAP SAP (Subnetwork Access Protocol Service Access Point) [RFC7042] format, which takes 8 bytes of overhead. So 1492 + 8 = 1500, the classic Ethernet maximum 💅. When it was standardized by ISO/IEC [IS-IS] to use Logical Link Control (LLC) encoding, the default could have gone up by a few bytes, but it didn't 😭.
In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes. That leaves 27 bytes of headroom, or safety margin, so legacy devices with the classic Ethernet maximum MTU can still cope, even with headers like an Outer.VLAN 🌸.
Assuming the campus-wide minimum link MTU is Sz, RBridges on Ethernet links MUST limit most TRILL IS-IS PDUs so that PDUz (the length of the PDU starting just after the L2-IS-IS Ethertype and ending just before the Ethernet Frame Check Sequence (FCS)) does not exceed Sz. The exceptions are TRILL Hello PDUs, which MUST NOT exceed 1470 bytes, and MTU-probe and MTU-ack PDUs. Those get padded by an amount that depends on the size being tested, so they may exceed Sz 🙈.
Sz does not limit TRILL Data packets. They're only limited by the MTU of the devices and links they actually pass through. Still, links that can handle IS-IS PDUs up to Sz would handle TRILL Data packet payloads of (Sz - 24) bytes, starting after the Inner.VLAN and ending just before the FCS, with a generous safety margin ✨.
Most modern Ethernet equipment has plenty of headroom for frames with lots of headers, and it's sometimes engineered to handle 9 KB jumbo frames 🧚.
6. TRILL Port Modes (Unchanged)
Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports, but it may not be completely clear on what all the combinations of bits actually do to allowed frame types 🎀.
So this table spells out the effect of every possible combination of the TRILL port mode bits. "*" in one of the first four columns means that bit can be either zero or one. The remaining columns show the allowed frame types. The "disable bit" normally disables all frames. As an implementation choice, though, some or all low-level Layer 2 control messages can still be sent or received. Examples of Layer 2 control messages are the control frames for Ethernet identified in Section 1.4 of [RFC6325] and PPP link negotiation messages [RFC6361] 💜.
+-+-+-+-+--------+-------+-------+-------+-------+
|D| | | | | | | | |
|i| |A| | | | TRILL | | |
|s| |c|T| |Native | Data | | |
|a| |c|r| |Ingress| | | |
|b|P|e|u| | | LSP | | |
|l|2|s|n|Layer 2 |Native | SNP | TRILL | P2P |
|e|P|s|k|Control |Egress | MTU | Hello | Hello |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|0|0| Yes | Yes | Yes | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|0|1| Yes | No | Yes | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|1|0| Yes | Yes | No | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|0|1|1| Yes | No | No | Yes | No |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|1|0|*| Yes | No | Yes | No | Yes |
+-+-+-+-+--------+-------+-------+-------+-------+
|0|1|1|*| Yes | No | No | No | Yes |
+-+-+-+-+--------+-------+-------+-------+-------+
|1|*|*|*|Optional| No | No | No | No |
+-+-+-+-+--------+-------+-------+-------+-------+The formal name of the "access bit" above is the "TRILL traffic disable bit". The formal name of the "trunk bit" is the "end-station service disable bit" [RFC6325] 🌈.
7. The CFI/DEI Bit (Unchanged)
In May 2011, the IEEE promulgated IEEE Std 802.1Q-2011, which changed the meaning of the bit between the priority and VLAN ID bits in the payload of C-VLAN tags. Before that, this bit was called the CFI (Canonical Format Indicator) bit [802] and had a special meaning for IEEE 802.5 (Token Ring) frames. After 802.1Q-2011, and in later versions of 802.1Q (the most current of which is [802.1Q-2014]), it's now the DEI (Drop Eligibility Indicator) bit. The corresponding bit in S-VLAN/B-VLAN tags has always been a DEI bit 🍓.
The TRILL base protocol specification [RFC6325] basically assumed that the link connecting end stations to TRILL switches, and the restricted virtual link provided by the TRILL Data packet, are IEEE 802.3 Ethernet links where the CFI bit is always zero. If an end station were attached by some other type of link, like a Token Ring link, [RFC6325] implicitly assumed those frames would be canonicalized to 802.3 frames before ingress. Similarly, on egress, they'd be converted from 802.3 to the appropriate frame type for the link. So [RFC6325] required that the CFI bit in the Inner.VLAN, shown as the "C" bit in Section 4.1.1 of [RFC6325], always be zero 🙅♀️.
However, for TRILL switches with ports that conform to the change in the IEEE 802.1Q-2011 standard, the bit in the Inner.VLAN (now a DEI bit) MUST be set to the DEI value the port interface provides when ingressing a native frame. Similarly, this bit MUST be provided to the port when transiting or egressing a TRILL Data packet. Just like the 3-bit Priority field, the DEI bit used to forward a transit packet MUST be taken from the Inner.VLAN. The exact effect on the Outer.VLAN DEI and priority bits, and on whether an Outer.VLAN appears at all on the wire for output frames, may depend on output port configuration 🔥.
TRILL campuses with a mix of ports, some compliant with versions of 802.1Q from IEEE Std 802.1Q-2011 onward and some compliant with pre-802.1Q-2011 standards, may operate incorrectly and may corrupt data, especially if they have actual Token Ring links. A bridged LAN with that same mix of ports and links would have the same problem 💀.
8. Other IS-IS Considerations (Changed)
This section covers Extended Level 1 Flooding Scope (E-L1FS) support, control packet priorities, unknown PDUs, the Nickname Flags APPsub-TLV, graceful restart, and the Purge Originator Identification TLV 👑.
8.1. E-L1FS Support (New)
TRILL switches MUST support E-L1FS PDUs [RFC7356] and MUST include a Scope Flooding Support TLV [RFC7356] in all TRILL Hellos they send. That TLV indicates support for this scope and any other FS-LSP scopes they support. This support increases the number of fragments available for link-state information by over two orders of magnitude 🚀. (See Section 9 for further information on support of the Scope Flooding Support TLV.)
Also, TRILL switches MUST advertise their support of E-L1FS flooding in a TRILL-VER sub-TLV Capability Flag (see [RFC7176] and Section 12.2). A TRILL switch, say RB1, uses this flag to figure out whether some remote RBx supports E-L1FS. Just looking for an E-L1FS FS-LSP originated by RBx doesn't work, for two reasons. First, RBx might support E-L1FS flooding but not be originating any E-L1FS FS-LSPs. Second, even if RBx is originating E-L1FS FS-LSPs, there might be no path between RBx and RB1 through TRILL switches that support E-L1FS flooding, because of legacy TRILL switches in the campus. If that's the case, no E-L1FS FS-LSP originated by RBx could ever reach RB1 😵💫.
E-L1FS will commonly be used to flood TRILL GENINFO TLVs and enclosed TRILL APPsub-TLVs [RFC7357]. For robustness, E-L1FS fragment zero MUST NOT exceed 1470 bytes in length. If a bigger fragment does show up, though, it's processed normally. It's anticipated that some particularly important TRILL APPsub-TLVs will be specified as flooded in E-L1FS fragment zero in the future 🔮. TRILL GENINFO TLVs MUST NOT be sent in LSPs. If one does arrive in an LSP, it's processed normally.
8.1.1. Backward Compatibility
A TRILL campus might contain TRILL switches that support E-L1FS flooding, plus legacy TRILL switches that don't support E-L1FS, or maybe don't support any [RFC7356] scopes at all 🧩.
A TRILL switch conformant to this document can always tell which adjacent TRILL switches support E-L1FS flooding, by looking at the adjacency table entries on its ports (see Section 9). It can also tell which remote TRILL switches in a campus support E-L1FS, by checking for a TRILL version sub-TLV in that switch's LSP with the E-L1FS support bit set in the Capabilities field. That capability bit gets ignored for adjacent TRILL switches where only the adjacency table entry is consulted to determine E-L1FS support 🦋.
TRILL specifications that make use of E-L1FS MUST specify how situations involving a mixed TRILL campus of TRILL switches will be handled 📝.
8.1.2. E-L1FS Use for Existing (Sub-)TLVs
In a campus where all TRILL switches support E-L1FS, all TRILL sub-TLVs listed in Section 2.3 of [RFC7176], except the TRILL version sub-TLV, MAY be advertised by inclusion in Router Capability or MT-Capability TLVs in E-L1FS FS-LSPs [RFC7356]. (The TRILL version sub-TLV still MUST appear in an LSP fragment zero 🫶.)
In a mixed campus, where some TRILL switches support E-L1FS and some don't, only the following four sub-TLVs from those listed in Section 2.3 of [RFC7176] can appear in E-L1FS, and only under the conditions discussed below. In the list below, each sub-TLV has an abbreviated acronym that's only used in this section of this document:
IV: Interested VLANs and Spanning Tree Roots sub-TLV
VG: VLAN Group sub-TLV
IL: Interested Labels and Spanning Tree Roots sub-TLV
LG: Label Group sub-TLVAn IV or VG sub-TLV MUST NOT be advertised by TRILL switch RB1 in an E-L1FS FS-LSP (it should instead be advertised in an LSP) unless the following conditions are met:
- E-L1FS is supported by all of the TRILL switches that are data reachable from RB1 and are interested in the VLANs mentioned in the IV or VG sub-TLV, and
- there is E-L1FS connectivity between all such TRILL switches in the campus interested in the VLANs mentioned in the IV or VG sub-TLV (connectivity involving only intermediate TRILL switches that also support E-L1FS).
Any IV and VG sub-TLVs MAY still be advertised via core TRILL IS-IS LSPs by any TRILL switch that has enough room in its LSPs 💖.
The conditions for using E-L1FS for the IL and LG sub-TLVs are the same as for IV and VG, but with Fine-Grained Labels [RFC7172] substituted for VLANs 🌷.
Note, for example, that the above would permit a contiguous subset of the campus that supported Fine-Grained Labels and E-L1FS to use E-L1FS to advertise IL and LG sub-TLVs, even if the remainder of the campus did not support Fine-Grained Labels or E-L1FS. ✨
8.2. Control Packet Priorities (New) ✨
okay so when a switch is deciding which packet goes out a port 🎀, control packets used to establish and maintain adjacency between TRILL switches SHOULD be treated as the highest-priority category 👑. That includes TRILL IS-IS Hello and MTU PDUs, and possibly other adjacency [RFC7177] or link-technology-specific packets. Other control and data packets SHOULD be given lower priority so that a flood of them can't cause loss of adjacency or stop adjacency from forming 💀. Losing adjacency causes a topology transient, and that can mean reduced throughput, reordering, a higher chance of losing data, and in the worst case a network partition if the adjacency is a cut point 😭.
other important control packets should be given second-highest priority, and lower priorities should go to data or less important control packets 🫶.
based on all that, control packets can be sorted into priority categories, based on how critical each type of message is 🌈. the most critical ones are about core routing between TRILL switches, and the less critical ones are closer to "application" info. (there may be additional control packets that aren't listed in any category below, and they SHOULD be handled as being in the most nearly analogous category 🧚.) few implementations will actually treat these four categories with different priority, but an implementation MAY choose to prioritize more critical messages over less critical ones. however, an implementation SHOULD NOT send control packets in a lower-priority category with a priority above those in a higher-priority category, because under sufficiently congested conditions this could block control packets in a higher-priority category and cause network disruption 🚨.
Priority
Category Description
-------- --------------
4. Hello, MTU-probe, MTU-ack, and other packets critical
to establishing and maintaining adjacency. (Normally
sent with highest priority, which is priority 7.)
3. LSPs, CSNPs/PSNPs, and other important control packets.
2. Circuit scoped FS-LSPs, FS-CSNPs, and FS-PSNPs.
1. Non-circuit scoped FS-LSPs, FS-CSNPs, and FS-PSNPs.8.3. Unknown PDUs (New) 🙈
TRILL switches MUST silently discard [IS-IS] PDUs they receive with PDU numbers they don't understand 🤫, same as how they ignore TLVs and sub-TLVs with unknown Types and sub-Types. they SHOULD still keep a counter of how many of those PDUs they've received, tracked per PDU number 📊. (this isn't a big deal, since the PDU number is only a 5-bit field 💅.)
Note: The set of valid [IS-IS] PDUs was stable for so long that some IS-IS implementations may treat PDUs with unknown PDU numbers as a serious error. For example, they might decide that other valid PDUs from the sender can't be trusted, or that they should drop adjacency to the sender if they were adjacent. But the MTU-probe and MTU-ack PDUs were added by [RFC7176], and now [RFC7356] has added three more new PDUs. The authors of this document aren't aware of any Internet-Drafts asking for more PDUs, but the eventual addition of more new PDUs shouldn't be surprising 😭.
8.4. Nickname Flags APPsub-TLV (New) 🦋
there's an optional Nickname Flags APPsub-TLV inside the TRILL GENINFO TLV [RFC7357], and it looks like this 🍓:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = NickFlags (6) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 4*K | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKFLAG RECORD 1 (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKFLAG RECORD K (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+each NICKFLAG RECORD has this format:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+the fields, bestie 💜:
- Type: NickFlags TRILL APPsub-TLV, set to 6 (NICKFLAGS).
- Length: 4 times the number of NICKFLAG RECORDS present.
- Nickname: A 16-bit TRILL nickname held by the advertising TRILL switch ([RFC6325] and Section 4).
- IN: Ingress. If this flag is one, the advertising TRILL switch may use the nickname in the NICKFLAG RECORD as the Ingress Nickname of TRILL Headers it creates. If the flag is zero, that nickname won't be used for that purpose 🌸.
- RESV: Reserved for additional flags to be specified in the future. MUST be sent as zero and ignored on receipt 🧊.
the whole NickFlags APPsub-TLV gets ignored if the Length isn't a multiple of 4 🙅♀️. a NICKFLAG RECORD gets ignored if the nickname it lists isn't owned by the TRILL switch that advertised the enclosing NickFlags APPsub-TLV.
if a TRILL switch wants to use a nickname in the Ingress Nickname field of the TRILL Headers it builds, it can advertise that through E-L1FS FS-LSPs (see Section 8.1) with a NickFlags APPsub-TLV entry that has the IN flag set ✨. if it only owns one nickname, there's no reason to bother, since a TRILL switch that advertises no NickFlags APPsub-TLVs with the IN flag set for the nicknames it owns is assumed to possibly use any or all of them as the Ingress Nickname in the TRILL Headers it builds. but if a TRILL switch advertises any NickFlags APPsub-TLV entries with the IN flag set, then it MUST NOT use any other nickname(s) it owns as the Ingress Nickname in the TRILL Headers it builds 🚫.
every reasonable effort should be made to keep Nickname sub-TLVs [RFC7176] and NickFlags APPsub-TLVs in sync 🔄. if every TRILL switch in a campus supports E-L1FS, so Nickname sub-TLVs can be advertised in E-L1FS FS-LSPs, then the Nickname sub-TLV and any NickFlags APPsub-TLVs for a particular nickname SHOULD be advertised in the same fragment 🧩. if they aren't in the same fragment, then, as far as is practical, all fragments involving those sub-TLVs for the same nickname should be propagated as an atomic action. if a TRILL switch sees multiple NickFlags APPsub-TLV entries for the same nickname, it assumes that nickname might be used as the ingress in a TRILL Header if any of those entries have the IN bit set.
a NickFlags APPsub-TLV might not get propagated throughout the TRILL campus, because legacy TRILL switches don't support E-L1FS 🥺. in that case, Nickname sub-TLVs MUST be advertised in LSPs, and TRILL switches that don't receive NickFlags APPsub-TLVs with entries that have the IN flag set will simply assume the source TRILL switch might use any of its nicknames as the ingress when constructing TRILL Headers. so this optional APPsub-TLV is backward compatible with legacy switches that lack E-L1FS support 🫶.
(additional flags are assigned from those labeled RESV above and specified in [TRILL-L3-GW] and [Centralized-Replication] 🌈.)
8.5. Graceful Restart (Unchanged) 🔁
TRILL switches SHOULD support the features specified in [RFC5306]. that doc describes a mechanism that lets a restarting IS-IS router tell its neighbors it's restarting, so they can re-establish adjacencies without going through the down state, while still correctly starting link-state database synchronization 🙌. if this feature isn't supported, it may increase the number of topology transients caused by a TRILL switch rebooting because of errors or maintenance 😬.
8.6. Purge Originator Identification (New) 🔍
to make purge-related problems easier to debug, TRILL switches SHOULD include the Purge Originator Identification TLV [RFC6232] in all purge PDUs in TRILL IS-IS 🕵️♀️. that includes Flooding Scope LSPs [RFC7356] and ESADI LSPs [RFC7357].
9. Updates to RFC 7177 (Adjacency) (Changed) 💖
to support the E-L1FS flooding scope [RFC7356] required by Section 8.1, and to stay backward compatible with legacy RBridges that don't support E-L1FS flooding, this document updates [RFC7177] like so 🎀:
- The list in the second paragraph of Section 3.1 of [RFC7177] gets another item added:
- The Scope Flooding Support TLV.
The sentence right after that list is also updated by this document to read:
Of course, (a) the priority, (b) the Desired Designated VLAN, (c) the Scope Flooding Support TLV, and whether or not the (d) PORT-TRILL-VER sub-TLV and/or (e) BFD-Enabled TLV are included, and their value if included, could change on occasion. However, if these change, the new value(s) must similarly be used in all TRILL Hellos on the LAN port, regardless of VLAN.
- This document adds another bullet item to the end of Section 3.2 of [RFC7177], like this:
- The value from the Scope Flooding Support TLV, or a null string if none was included.
- Near the bottom of Section 3.3 of [RFC7177], this document adds this bullet item:
- The variable-length value part of the Scope Flooding Support TLV in the Hello, or a null string if that TLV doesn't occur in the Hello.
- At the beginning of Section 4 of [RFC7177], this document adds a bullet item to the list:
- The variable-length value part of the Scope Flooding Support TLV used in TRILL Hellos sent on the port.
- This document adds a line to Table 4 ("TRILL Hello Contents") in Section 8.1 of [RFC7177]:
LAN P2P Number Content Item
--- --- ------ ---------------------------
M M 1 Scope Flooding Support TLV10. TRILL Header Update (New) ✨
Okay bestie, the TRILL Header got a major glow-up! 💖 It started out in [RFC6325], then [RFC7455] and [RFC7179] gave it updates, and this document adds even more. Here's the new look. The references under it cover every field, and any field that only points at [RFC6325] is unchanged from that RFC 🫶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional Flags Word :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay, so when a TRILL switch is picking a path for a TRILL Data packet using equal-cost multipath, it MUST ignore the value of the "A" and "C" bits. No exceptions, periodt 💅
Heads up, in [RFC6325] and [RFC7179] there's a TRILL Header Extension Length field called "Op-Length". It's getting a makeover too: it's now made up of the RESV field and the "F" bit shown above 🦋
- V (Version): 2-bit unsigned integer. See Section 3.2 of [RFC6325].
- A (Alert): 1 bit. See [RFC7455].
- C (Color): 1 bit. See Section 10.1.
- M (Multi-destination): 1 bit. See Section 3.4 of [RFC6325].
- RESV: 4 bits. These bits are reserved and MUST be sent as zero. Due to the previous use of these bits as specified in [RFC6325], most TRILL "fast path" hardware implementations trap and do not forward TRILL Data packets with these bits non-zero. A TRILL switch receiving a TRILL Data packet with any of these bits non-zero MUST discard the packet unless the non-zero bit or bits have some future use specified that the TRILL switch understands. 😭
- F: 1 bit. If this field is non-zero, then the optional flags word described in Section 10.2 is present. If it is zero, the flags word is not present.
- Hop Count: 6 bits. See Section 3.6 of [RFC6325] and Section 10.2.1 below.
- Egress Nickname: See Section 3.7.1 of [RFC6325].
- Ingress Nickname: See Section 3.7.2 of [RFC6325].
- Optional Flags Word: See [RFC7179] and Section 10.2.
10.1. Color Bit 🎀
The Color bit is an optional way for ingress TRILL switches to MAY mark TRILL Data packets for implementation-specific purposes. Transit TRILL switches MUST NOT change this bit. Transit and egress TRILL switches MAY use the Color bit for implementation-dependent traffic labeling, or for statistical analysis or other types of traffic study or analysis. 🌈
10.2. Flags Word Changes (Update to RFC 7179) 🍓
When the "F" bit in the TRILL Header is non-zero, the first 32 bits after the Ingress Nickname field provide additional flags. These bits are as specified in [RFC7179], except as changed by the subsections below, in which the Extended Hop Count and Extended Color fields are described. See Section 10.3 for a diagram and summary of these fields. ✨
10.2.1. Extended Hop Count 🚀
The TRILL base protocol [RFC6325] specifies the Hop Count field in the header, so packets don't persist in the network due to looping or the like. But the Hop Count field is only 6 bits, which limits a TRILL Data packet to 64 hops max. Optionally, TRILL switches can use a field made of bits 14 through 16 in the flags word, as specified below, to stretch this field to 9 bits. That bumps the maximum Hop Count up to 512. Except in rare circumstances, reliable use of Hop Counts over 64 requires support of this optional capability at all TRILL switches along the path of a TRILL Data packet. Main character energy 👑
10.2.1.1. Advertising Support 📣
It may be that not all the TRILL switches support the Extended Hop Count mechanism in a TRILL campus, and in that campus more than 64 hops are required either for the distribution tree calculated path or for the unicast calculated path plus a reasonable allowance for alternate pathing. As such, it is required that TRILL switches advertise their support by setting bit 14 in the TRILL Version Sub-TLV Capabilities and Header Flags Supported field [RFC7176]. Bits 15 and 16 of that field are now specified as Unassigned (see Section 12.2.5). 🧚
10.2.1.2. Ingress Behavior 🌸
If an ingress TRILL switch determines that it should set the Hop Count for a TRILL Data packet to 63 or less, then behavior is as specified in the TRILL base protocol [RFC6325]. If the optional TRILL Header flags word is present, bits 14, 15, and 16 and the critical reserved bit of the critical summary bits are zero.
If the Hop Count for a TRILL Data packet should be set to some value greater than 63 but less than 512, and all TRILL switches that the packet is reasonably likely to encounter support Extended Hop Count, then the resulting TRILL Header has the flags word extension present. The high-order 3 bits of the desired Hop Count go in the Extended Hop Count field in the flags word, the low-order 5 bits go in the Hop Count field in the first word of the TRILL Header, and bit two (the critical reserved bit of the critical summary bits) in the flags word is set to one. 💅
For known unicast traffic (TRILL Header "M" bit zero), an ingress TRILL switch discards the frame if it determines that the least-cost path to the egress is (1) more than 64 hops and not all TRILL switches on that path support the Extended Hop Count feature, or (2) more than 512 hops. 💀
For multi-destination traffic, when a TRILL switch determines that one or more tree paths from the ingress are more than 64 hops and not all TRILL switches in the campus support the Extended Hop Count feature, the encapsulation uses a total Hop Count of 63 to get at least partial distribution of the traffic. 🫶
10.2.1.3. Transit Behavior 🦋
A transit TRILL switch supporting Extended Hop Count behaves like a base protocol [RFC6325] TRILL switch when decrementing the Hop Count, except that it treats the Hop Count as a 9-bit field where the Extended Hop Count field makes up the high-order 3 bits.
To be more precise, a TRILL switch supporting Extended Hop Count takes the first of the following actions that is applicable:
- If both the Hop Count and Extended Hop Count fields are zero, the packet is discarded.
- If the Hop Count is non-zero, it is decremented. As long as the Extended Hop Count is non-zero, no special action is taken. If the result of this decrement is zero, the packet is processed normally.
- If the Hop Count is zero, it is set to the maximum value of 63, and the Extended Hop Count is decremented. If this results in the Extended Hop Count being zero, the critical reserved bit in the critical summary bits is set to zero.
10.2.1.4. Egress Behavior 🌷
No special behavior is required when egressing a TRILL Data packet that uses the Extended Hop Count. The flags word, if present, is removed along with the rest of the TRILL Header during decapsulation.
10.2.2. Extended Color Field 🌈
Flags word bits 27 and 28 are specified to be a 2-bit Extended Color field (see Section 10.3). These bits are in the non-critical ingress-to-egress region of the flags word.
The Extended Color field is an optional way for ingress TRILL switches to MAY mark TRILL Data packets for implementation-specific purposes. Transit TRILL switches MUST NOT change these bits. Transit and egress TRILL switches MAY use the Extended Color bits for implementation-dependent traffic labeling, or for statistical analysis or other types of traffic study or analysis. 🎀
Per Section 2.3.1 of [RFC7176], support for these bits is indicated by the same bits (27 and 28) in the Capabilities and Header Flags Supported field of the TRILL version sub-TLV. If these bits are zero in those capabilities, Extended Color is not supported. A TRILL switch that does not support Extended Color will ignore the corresponding bits in any TRILL Header flags word it receives as part of a TRILL Data packet, and will set those bits to zero in any TRILL Header flags word it creates. A TRILL switch that sets or senses the Extended Color field on transmitting or receiving TRILL Data packets MUST set the corresponding 2-bit field in the TRILL version sub-TLV to a non-zero value. Any difference in the meaning of the three possible non-zero values of this 2-bit capability field (0b01, 0b10, or 0b11) is implementation dependent. 🧚
10.3. Updated Flags Word Summary 📋
With the changes above, the 32-bit flags word extension to the TRILL Header [RFC7179], which is detailed in the "TRILL Extended Header Flags" registry on the "Transparent Interconnection of Lots of Links (TRILL) Parameters" IANA web page, now looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE |
|.....|.........|...........|.....|.......|...........|.........|
|C|C|C| |C|N| | Ext | | |Ext| |
|R|R|R| |R|C| | Hop | | |Clr| |
|H|I|R| |C|C| | Cnt | | | | |
|b|t|s| |A|A| | | | | | |
|H|E|v| |F|F| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Bits 0, 1, and 2 are the critical summary bits, as specified in [RFC7179], consisting of the critical hop-by-hop, critical ingress-to-egress, and critical reserved bits, respectively. The next two fields are the specific critical and non-critical hop-by-hop bits, CHbH and NCHbH, which contain the Critical and Non-critical Channel Alert flags as specified in [RFC7179]. The next field is the critical reserved bits (CRSV), which are specified herein to be the Extended Hop Count. The non-critical reserved bits (NCRSV) and the critical ingress-to-egress bits (CItE), as specified in [RFC7179], follow. Finally, there's the non-critical ingress-to-egress field, including bits 27 and 28, which are specified herein as the Extended Color field. Slay, that's the whole flags word glow-up 💜
11. Appointed Forwarder Status Lost Counter (New) 🦋
okay so bestie, this one is a whole plot twist 🎀 Strict obedience to Section 4.8.3 of [RFC6325] about the Appointed Forwarder Status Lost Counter can actually make Interested VLANs and Spanning Tree Roots sub-TLVs [RFC7176] split apart 💔 (or the matching Interested Labels and Spanning Tree Roots sub-TLVs, when a VLAN gets mapped to an FGL) just because the counter values differ between neighbouring VLAN IDs (or 24-bit FGLs). This counter is basically a trick for speeding up data-plane learning by shortening the expiry timer on learned addresses, per VLAN or FGL, in certain situations ✨
So this document changes the rule that says a TRILL switch MUST... wait, sorry, let me say it properly: the requirement to bump this counter by one every time a TRILL switch loses Appointed Forwarder status on a port is now replaced by the enumerated rules below, instead of the mandatory stuff in [RFC6325] 💅 If this makes the counter go up when [RFC6325] says it shouldn't, remote TRILL switches will have their data-plane address learning timeouts reduced. If it makes the counter stay the same when [RFC6325] says it should go up, then the timeout reduction that would have happened just... doesn't 🥲
(1) If any of the following apply, then either data-plane address learning isn't in use or Appointed Forwarder status doesn't matter at all 🙈 In these cases, the Appointed Forwarder Status Lost Counter MAY be left at zero, or set to any convenient value, such as the value of the Appointed Forwarder Status Lost Counter for an adjacent VLAN ID or FGL 🧚
- (1a) The TRILL switch port has been configured with the "end-station service disable" bit (also known as the trunk bit) on. 🌸
- (1b) The TRILL switch port has been configured in IS-IS as an IS-IS point-to-point link. 🌸
- (1c) The TRILL switch is relying on ESADI [RFC7357] or Directory Assist [RFC7067] and not using data-plane learning. 🌸
(2) For any cases other than the ones listed in point 1 above, the Appointed Forwarder Status Lost Counter SHOULD be incremented as described in [RFC6325] 💖 That incrementing is great because it helps optimize data-plane learning. Alternatively, the counter can be set to something other than that value, for example to match the value for an adjacent VLAN ID (or FGL), which allows more aggregation of Interested VLANs and Spanning Tree Roots sub-TLVs 🫶
12. IANA Considerations (Changed) 🌈
This section is the IANA paperwork bit: it lists the IANA actions that were already done and the new ones 📋
12.1. Previously Completed IANA Actions (Unchanged) 🍓
These IANA actions were completed as part of [RFC7180], and they're listed again here for completeness, since this document obsoletes [RFC7180] ✨
- The nickname 0xFFC1, which was reserved by [RFC6325], is allocated for use in the TRILL Header Egress Nickname field to indicate an OOMF (Overload Originated Multi-destination Frame).
- Bit 1 from the seven previously reserved (RESV) bits in the per-neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176] is allocated to indicate that the RBridge sending the TRILL Hello volunteers to provide the OOMF forwarding service described in Section 2.4.2 to such frames originated by the TRILL switch whose SNPA (MAC address) appears in that Neighbor RECORD. The description of this bit is "Offering OOMF service". 🦋
- Bit 0 is allocated from the capability bits in the PORT-TRILL-VER sub-TLV [RFC7176] to indicate support of the VLANs Appointed sub-TLV [RFC7176] and the VLAN inhibition setting mechanisms specified in [RFC6439bis]. The description of this bit is "Hello reduction support". 💜
12.2. New IANA Actions (New) 🎀
The following are the new IANA actions for this document 💅
12.2.1. Reference Updated 🌸
All references to [RFC7180] in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry have been replaced with references to this document, except that the Reference for bit 0 in the PORT-TRILL-VER Sub-TLV Capability Flags has been changed to [RFC6439bis] 🔥
12.2.2. The "E" Capability Bit 🌟
There's an existing TRILL version sub-TLV, sub-TLV #13, under both TLV #242 and TLV #144 [RFC7176]. It has a capability bits field, and those assignments are documented in the "TRILL-VER Sub-TLV Capability Flags" registry on the TRILL Parameters IANA web page. IANA has allocated 4 from the previously reserved bits in this registry to indicate support of the E-L1FS flooding scope as specified in Section 8.1. This capability bit is called the "E" bit 💖 Here's the addition to the "TRILL-VER Sub-TLV Capability Flags" registry:
Bit Description References
---- --------------------- ---------------
4 E-L1FS FS-LSP support [RFC7356], RFC 778012.2.3. NickFlags APPsub-TLV Number and Registry 🧚
IANA has assigned an APPsub-TLV number under the TRILL GENINFO TLV, from the range less than 255, like this:
Type Name References
---- --------- -----------
6 NICKFLAGS RFC 7780IANA also created a registry on its TRILL Parameters web page for NickFlags bit assignments:
Name: NickFlags Bits
Registration Procedure: IETF Review [RFC5226]
Reference: RFC 7780
Bit Mnemonic Description Reference
----- -------- ----------- ---------
0 IN Used as ingress RFC 7780
1-15 - Unassigned RFC 778012.2.4. Updated TRILL Extended Header Flags 🌈
The "TRILL Extended Header Flags" registry has been updated like so:
Bits Purpose Reference
----- ---------------------------------------- ------------
14-16 Extended Hop Count RFC 7780
27-28 Extended Color RFC 7780
29-31 Available non-critical ingress-to-egress [RFC7179], RFC 7780
flags12.2.5. TRILL-VER Sub-TLV Capability Flags ⭐
The "TRILL-VER Sub-TLV Capability Flags" registry has also been updated:
Bit Description Reference
----- -------------------------- ----------------
14 Extended Hop Count support RFC 7780
15-16 Unassigned RFC 7780
27-28 Extended Color support RFC 7780
29-31 Extended header flag support [RFC7179], RFC 778012.2.6. Example Nicknames 🍓
IANA has assigned a block of eight nicknames for use as examples in documentation, as the table below shows 🧁 Appendix B shows a use of some of these nicknames. The "TRILL Nicknames" registry has been updated by changing the previous "0xFFC2-0xFFFE Unassigned" line to the following:
Name Description Reference
------------- -------------- -----------
0xFFC2-0xFFD7 Unassigned
0xFFD8-0xFFDF For use in documentation examples RFC 7780
0xFFE0-0xFFFE Unassigned13. Security Considerations (Changed) 🔐
Serious moment incoming 🚨 For general TRILL security considerations, see [RFC6325]. This 🫶 memo improves the documentation of the TRILL protocol, corrects six errata in [RFC6325], updates [RFC6325], [RFC7177], and [RFC7179], and obsoletes [RFC7180]. It does not change the security considerations of those RFCs, except as follows:
- E-L1FS FS-LSPs can be authenticated with IS-IS security [RFC5310], that is, through the inclusion of an IS-IS Authentication TLV in E-L1FS PDUs. 🔒
- As discussed in Section 3.6, when using an allowed weaker RPF check under very rare topologies and transient conditions, multi-destination TRILL Data packets can be duplicated. This could have security consequences for some protocols. 😭 Be careful out there, bestie 💀
14. References 📚
14.1. Normative References 💖
okay so these are the must-reads, bestie 📚 you genuinely need these to build the thing 🔥
[802.1Q-2014]IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", DOI 10.1109/IEEESTD.2014.6991462, IEEE Std 802.1Q-2014.[IS-IS]International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- 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)", ISO/IEC 10589:2002, Second Edition, November 2002.[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>.[RFC5305]Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008,<http://www.rfc-editor.org/info/rfc5305>.[RFC5306]Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, DOI 10.17487/RFC5306, October 2008,<http://www.rfc-editor.org/info/rfc5306>.[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>.[RFC6232]Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, May 2011,<http://www.rfc-editor.org/info/rfc6232>.[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>.[RFC6361]Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011,<http://www.rfc-editor.org/info/rfc6361>.[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>.[RFC7177]Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014,<http://www.rfc-editor.org/info/rfc7177>.[RFC7179]Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 2014,<http://www.rfc-editor.org/info/rfc7179>.[RFC7356]Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014,<http://www.rfc-editor.org/info/rfc7356>.[RFC7455]Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015,<http://www.rfc-editor.org/info/rfc7455>.
14.2. Informative References 🦋
these are the extra-credit reads 🧚 super helpful for the backstory and the deep dives, but you don't need them to get the core picture ✨
[802]IEEE 802, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802-2014.[Centralized-Replication]Hao, W., Li, Y., Durrani, M., Gupta, S., Qu, A., and T. Han, "Centralized Replication for BUM traffic in active-active edge connection", Work in Progress, draft-ietf-trill-centralized-replication-03, November 2015.[Err3002]RFC Errata, Erratum ID 3002, RFC 6325.[Err3003]RFC Errata, Erratum ID 3003, RFC 6325.[Err3004]RFC Errata, Erratum ID 3004, RFC 6325.[Err3052]RFC Errata, Erratum ID 3052, RFC 6325.[Err3053]RFC Errata, Erratum ID 3053, RFC 6325.[Err3508]RFC Errata, Erratum ID 3508, RFC 6325.[RFC792]Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981,<http://www.rfc-editor.org/info/rfc792>.[RFC826]Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982,<http://www.rfc-editor.org/info/rfc826>.[RFC4086]Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,<http://www.rfc-editor.org/info/rfc4086>.[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008,<http://www.rfc-editor.org/info/rfc5226>.[RFC6327]Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, DOI 10.17487/RFC6327, July 2011,<http://www.rfc-editor.org/info/rfc6327>.[RFC6439]Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011,<http://www.rfc-editor.org/info/rfc6439>.[RFC6439bis]Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and H. Fangwei, "TRILL: Appointed Forwarders", Work in Progress, draft-ietf-trill-rfc6439bis-01, January 2016.[RFC7042]Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013,<http://www.rfc-editor.org/info/rfc7042>.[RFC7067]Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013,<http://www.rfc-editor.org/info/rfc7067>.[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, DOI 10.17487/RFC7175, May 2014,<http://www.rfc-editor.org/info/rfc7175>.[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, DOI 10.17487/RFC7178, May 2014,<http://www.rfc-editor.org/info/rfc7178>.[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, DOI 10.17487/RFC7180, May 2014,<http://www.rfc-editor.org/info/rfc7180>.[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>.[TRILL-L3-GW]Hao, W., Li, Y., Qu, A., Durrani, M., Sivamurugan, P., and L. Xia, "TRILL Distributed Layer 3 Gateway", Work in Progress, draft-ietf-trill-irb-10, January 2016.
Appendix A. Life Cycle of a TRILL Switch Port (New) 🦋
Okay bestie, this informational appendix is a paraphrase of a mailing list thread from http://www.ietf.org/mail-archive/web/trill/current/msg06355.html, and it's giving "what actually happens first??" energy 🌸
Question: Say we're building a TRILL implementation that has to run on different machines. What happens first? Is LSP flooding or ESADI started first? -> Link-state database creation -> Designated RBridge election (How do you set priority? Is there a fixed process that depends on user settings?) -> etc.
Answer: The very first thing on a port or link is whatever link setup it needs 🔥 For example, on a PPP link [RFC6361], you have to negotiate that you'll be using TRILL. But if you've got Ethernet links [RFC6325], which are probably the most common kind, there's no link setup needed at all ✨
Once the port is set up, it can ingress or egress native frames, as long as end-station service is being offered on that port. Offering end-station service is the default 💅 But if the port trunk bit (end-station service disable) is set, or the port is configured as an IS-IS point-to-point link port, then end-station service is not offered. That means native frames that come in get ignored, and native frames don't get egressed. Rude! 🙈
TRILL IS-IS Hellos then get sent out the port so they can be exchanged with any other TRILL switches on the link [RFC7177]. Only the Hellos are required. Optionally, you could also swap MTU-probe/ack PDUs [RFC7177], BFD PDUs [RFC7175], or other link test packets 🧚
TRILL doesn't send any TRILL Data or TRILL IS-IS packets out the port onto the link, except for Hellos, until the link gets to the 2-Way or Report state [RFC7177]. Patience, babe 💖
If a link is configured as a point-to-point link, there's no Designated RBridge (DRB) election. By default, an Ethernet link is considered a LAN link, and the DRB election happens when the link is in any state other than Down. You don't have to configure priorities on each TRILL switch (RBridge) to make it the DRB. Things will work fine with all the RBridges on a link using the default priority 👑 But if the network manager wants to control this, there should be a way for them to configure the priority to become the DRB of the TRILL switch ports on the link.
(To keep things simple, this appendix generally describes the life cycle for a link that only has two TRILL switches on it. But TRILL works fine, as it's currently specified, on a broadcast link with multiple TRILL switches on it. Actually, it's multiple TRILL switch ports, since a TRILL switch can have multiple ports connected to the same link. The most likely way to get a multi-access link like that with current technology and the existing TRILL standards is to have more than two TRILL switch Ethernet ports connected to a bridged LAN. TRILL operates above all bridging. In general, the bridged LAN looks like a transparent broadcast link to TRILL 🌈)
When a link gets to the 2-Way or Report state, LSPs, CSNPs, and PSNPs start flowing on the link. FS-LSPs, FS-CSNPs, and FS-PSNPs for E-L1FS flow too (see Section 8.1) 🍓
When a link gets to the Report state, there is an adjacency. The existence of that adjacency gets flooded (reported) to the campus in LSPs. Then TRILL Data packets can start flowing on the link, as TRILL switches recalculate the least-cost paths and distribution trees to take the new adjacency into account 🦋 Until the link gets to the Report state, there's no adjacency, and no TRILL Data packets can flow over that link. There's one minor corner case exception: an RBridge Channel message can, for its first hop only, be sent on a port where there's no adjacency (Section 2.4 of [RFC7178]). Also, even though that paragraph seems to be talking about link state, it's actually about port state. Different TRILL switch ports on the same link can temporarily be in different states, because the adjacency state machinery runs independently on each port 💜
ESADI [RFC7357] is built on top of the regular TRILL Data routing. Since ESADI PDUs look like regular TRILL Data packets to transit TRILL switches, no ESADI PDUs can flow until adjacencies are established and TRILL Data is flowing. And of course, ESADI is optional and isn't used unless it's configured 🙌
Question: Does it require TRILL Full Headers at the time TRILL LSPs start being broadcast on a link? Because at that point, egress and ingress nicknames aren't defined yet.
Answer: TRILL Headers are only for TRILL Data packets. TRILL IS-IS packets, such as TRILL LSPs, get sent in a different way that doesn't use a TRILL Header and doesn't depend on nicknames 💅
Probably, in most implementations, a TRILL switch will start up using the same nickname it had when it shut down or last got disconnected from a campus. If you want, you can implement TRILL to come up initially without reporting any nickname (by not including a Nickname sub-TLV in its LSPs). Then, once you've got the link-state database, or most of it, you can choose a nickname that no other TRILL switch in the campus is using ✨ Of course, if a TRILL switch doesn't have a nickname, then it cannot ingress data, cannot egress known unicast data, and cannot be a tree root. No nickname, no vibes 🥲
TRILL IS-IS PDUs such as LSPs, and the link-state database, all work based on the 7-byte IS-IS System ID (sometimes called the LAN ID [IS-IS]). Since topology determination uses System IDs, which are always unique across the campus, it isn't affected by the nickname assignment state. The nickname system is built on top of that, so it's like a little layer cake 🎀
Appendix B. Example TRILL PDUs (New) 🧚
Here are some example TRILL IS-IS PDUs. The main reason for these examples is to clear up any confusion about bit ordering 💖
The examples in this appendix focus on the format of the packet header and trailer. There are often unspecified optional items or data in the packet that would affect header or trailer fields, like the packet length or checksum. So an "Xed out" placeholder is used for those fields, where each X stands for one hex nibble 🌸
B.1. LAN Hello over Ethernet
This is a TRILL Hello sent from a TRILL switch (RBridge) with 7-byte System ID 0x30033003300300 holding nickname 0xFFDE. It goes out over Ethernet from a port with MAC address 0x00005E0053DE on VLAN 1 at priority 7 🍓 There's one neighbor, and that neighbor is the DRB. The neighbor's port MAC is 0x00005E0053E3, and the neighbor's System ID is 0x44444444444400 👑
Ethernet Header
Outer.MacDA, Outer.MacSA
0x0180C2000041 All-IS-IS-RBridges Destination MAC Address
0x00005E0053DE Source MAC Address
Outer VLAN Tag (optional)
0x8100 C-VLAN Ethertype [802.1Q-2014]
0xE001 Priority 7, Outer.VLAN
IS-IS
0x22F4 L2-IS-IS Ethertype
IS-IS Payload
Common Header
0x83 Intradomain Routeing Protocol Discriminator
0x08 Header Length
0x01 IS-IS Version Number
0x06 ID Length of 6 Bytes
0x0F PDU Type (Level 1 LAN Hello)
0x01 Version
0x00 Reserved
0x01 Maximum Area Addresses
Hello PDU Specific Fields
0x01 Circuit Type (Level 1)
0x30033003300300 Source System ID
0x0009 Holding Time
0xXXXX PDU Length
0x40 Priority to be DRB
0x44444444444400 LAN ID
TLVs (the following order of TLVs or of sub-TLVs in a TLV
is not significant)
Area Addresses TLV
0x01 Area Addresses Type
0x02 Length of Value
0x01 Length of Address
0x00 The fixed TRILL Area Address
MT Port Capabilities TLV
0x8F MT Port Capabilities Type
0x0011 Length of Value
0x0000 Topology
Special VLANs and Flags Sub-TLV
0x01 Sub-TLV Type
0x08 Length
0x0123 Port ID
0xFFDE Sender Nickname
0x0001 Outer.VLAN
0x0001 Designated VLAN
Enabled VLANs Sub-TLV (optional)
0x02 Sub-TLV Type
0x03 Length
0x0001 Start VLAN 1
0x80 VLAN 1
TRILL Neighbor TLV
0x91 Neighbor Type
0x0A Length of Value
0xC0 S Flag = 1, L Flag = 1, SIZE field 0
NEIGHBOR RECORD
0x00 Flags
0x2328 MTU = 9 KB
0x00005E0053E3 Neighbor MAC Address
Scope Flooding Support TLV
0xF3 Scope Flooding Support Type
0x01 Length of Value
0x40 E-L1FS Flooding Scope
More TLVs (optional)
...
Ethernet Trailer
0xXXXXXXXX Ethernet Frame Check Sequence (FCS)B.2. LSP over PPP
Here's an example of a TRILL LSP sent over a PPP link by the same source TRILL switch as in Appendix B.1 🦋
PPP Header
0x405D PPP TRILL Link State Protocol
IS-IS Payload
Common Header
0x83 Intradomain Routeing Protocol Discriminator
0x08 Header Length
0x01 IS-IS Version Number
0x06 ID Length of 6 Bytes
0x12 PDU Type (Level 1 LSP)
0x01 Version
0x00 Reserved
0x01 Maximum Area Addresses
LSP Specific Fields
0xXXXX PDU Length
0x0123 Remaining Lifetime
0x3003300330030009 LSP ID (fragment 9)
0x00001234 Sequence Number
0xXXXX Checksum
0x01 Flags = Level 1
TLVs (the following order of TLVs or of sub-TLVs in a TLV
is not significant)
Router Capability TLV
0xF2 Router Capability Type
0x0F Length of Value
0x00 Flags
Nickname Sub-TLV
0x06 Sub-TLV Type
0x05 Length of Value
NICKNAME RECORD
0x33 Nickname Priority
0x1234 Tree Root Priority
0xFFDE Nickname
TRILL Version Sub-TLV
0x0D Sub-TLV Type
0x05
0x00 Max Version
0x40000000 Flags = FGL Support
More TLVs (optional
...
PPP Trailer
0xXXXXXX PPP Frame Check Sequence (FCS)B.3. TRILL Data over Ethernet ✨
okay bestie, this one is an IPv4 ICMP Echo [RFC792] tucked inside a TRILL Data packet 🎀. It's sent from the same TRILL switch that sent the Hello in Appendix B.1, over to its neighbor TRILL switch on that same link. It's giving layered-cake energy 🍰
Ethernet Header
Outer.MacDA, Outer.MacSA
0x00005E0053E3 Destination MAC Address
0x00005E0053DE Source MAC Address
Outer VLAN Tag (optional)
0x8100 C-VLAN Ethertype [802.1Q-2014]
0x0001 Priority 0, Outer.VLAN 1
TRILL
0x22F3 TRILL Ethertype
TRILL Header
0X000E Flags, Hop Count 14
0xFFDF Egress Nickname
0xFFDC Ingress Nickname
Inner Ethernet Header
Inner.MacDA, Inner.MacSA
0x00005E005322 Destination MAC Address
0x00005E005344 Source MAC Address
Inner VLAN Tag
0x8100 C-VLAN Ethertype
0x0022 Priority 0, Inner.VLAN 34
Ethertype
0x0800 IPv4 Ethertype
IP Header
0x4500 Version 4, Header Length 5, ToS 0
0xXXXX Total Length
0x3579 Identification
0x0000 Flags, Fragment Offset
0x1101 TTL 17, ICMP = Protocol 1
0xXXXX Header Checksum
0xC0000207 Source IP 192.0.2.7
0xC000020D Destination IP 192.0.2.13
0x00000000 Options, Padding
ICMP
0x0800 ICMP Echo
0xXXXX Checksum
0x87654321 Identifier, Sequence Number
... Echo Data
Ethernet Trailer
0xXXXXXXXX Ethernet Frame Check Sequence (FCS)B.4. TRILL Data over PPP 🧚
this one's an ARP Request [RFC826] that gets wrapped in a TRILL Data packet 📦. It comes from the same TRILL switch that sent the Hello in Appendix B.1, but this time it travels over a PPP link 🫧
PPP Header
0x005D PPP TRILL Network Protocol
TRILL Header
0X080D Flags (M = 1), Hop Count 13
0xFFDD Distribution Tree Root Nickname
0xFFDC Ingress Nickname
Inner Ethernet Header
Inner.MacDA, Inner.MacSA
0xFFFFFFFFFFFF Destination MAC Address
0x00005E005344 Source MAC Address
Inner VLAN Tag
0x8100 C-VLAN Ethertype
0x0022 Priority 0, Inner.VLAN 34
Ethertype
0x0806 ARP Ethertype
ARP
0x0001 Hardware Address Space = Ethernet
0x0001 Protocol Address Space = IPv4
0x06 Size of Hardware Address
0x04 Size of Protocol Address
0x0001 OpCode = Request
0x00005E005344 Sender Hardware Address
0xC0000207 Sender Protocol Address 192.0.2.7
0x000000000000 Target Hardware Address
0xC000020D Target Protocol Address 192.0.2.13
PPP Trailer
0xXXXXXX PPP Frame Check Sequence (FCS)Appendix C. Changes to Previous RFCs (New) 💅
C.1. Changes to Obsoleted RFC 7180
okay so this section sums up all the changes, augmentations, and excisions this document makes to [RFC7180]. It officially obsoletes and replaces it, so this is the glow-up tracker 📈✨
C.1.1. Changes
for every section header in this document that ends with "(Changed)", this part gives you the tea on what changed 🍵
Section 1 ("Introduction"): numerous changes to reflect the overall changes in contents.
Section 1.1 ("Precedence"): changed to add mention of [RFC7179].
Section 1.3 ("Terminology and Acronyms"): numerous terms added.
Section 3 ("Distribution Trees and RPF Check"): changed by the addition of the new material in Section 3.6. See Appendix C.1.2, Item 1.
Section 8 ("Other IS-IS Considerations"): changed by the addition of Sections 8.1, 8.2, 8.3, and 8.4. See Appendix C.1.2 -- Items 2, 3, 4, and 5, respectively.
Section 9 ("Updates to RFC 7177 (Adjacency): changes and additions to [RFC7177] to support E-L1FS. See Appendix C.1.2, Item 2.
Section 12 ("IANA Considerations"): changed by the addition of material in Section 12.2. See Appendix C.1.2, Item 7.
Section 13 ("Security Considerations"): minor changes in the RFCs listed.
C.1.2. Additions
this document has the following new stuff that isn't in [RFC7180] 🎉
- Support for an alternative Reverse Path Forwarding Check (RPFC), along with considerations for deciding between the original [RFC6325] RPFC and this alternative RPFC. This alternative RPFC was originally discussed on the TRILL WG mailing list in
http://www.ietf.org/mail-archive/web/trill/current/msg01852.htmland subsequent messages (Section 3.6). - Mandatory E-L1FS [RFC7356] support (Sections 8.1 and 9).
- Recommendations concerning control packet priorities (Section 8.2).
- Implementation requirements concerning unknown IS-IS PDU types (Section 8.3).
- Specification of an optional Nickname Flags APPsub-TLV and an ingress flag within that APPsub-TLV (Section 8.4).
- Update to the TRILL Header to allocate a Color bit (Section 10.1), and update to the optional TRILL Header Extension flags word to allocate a 2-bit Extended Color field (Section 10.2).
- Some new IANA Considerations in Section 12.2, including reservation of nicknames for use as examples in documentation.
- A new "Appointed Forwarder Status Lost Counter" section (Section 11 of this document) that loosens the mandatory update requirements specified in [RFC6325].
- Informative Appendix A on the life cycle of a TRILL port.
- A new Appendix B containing example TRILL PDUs.
- Recommendation to use the Purge Originator Identification TLV (Section 8.6).
C.1.3. Deletions
this document drops the following stuff that was in [RFC7180] 🗑️
- All updates to [RFC6327] that occurred in [RFC7180]. These have been rolled into [RFC7177], which obsoletes [RFC6327]. However, new updates to [RFC7177] are included (see Appendix C.3).
- All updates to [RFC6439]. These have been rolled into [RFC6439bis], which is intended to obsolete [RFC6439].
C.2. Changes to RFC 6325
this document has a bunch of normative updates to [RFC6325]. Some of them were also in [RFC7180], which this document replaces. The changes are:
- Changing nickname allocation to ignore conflicts with RBridges that are IS-IS unreachable.
- Fixing errors: [Err3002], [Err3003], [Err3004], [Err3052], [Err3053], and [Err3508].
- Changing the requirement to use the RPF check described in [RFC6325] for multi-destination TRILL Data packets by providing an alternative stronger RPF check.
- Adoption of the change of the CFI bit, which was required to be zero in the inner frame, to the DEI bit, which is obtained from inner frame ingress or creation.
- Requiring that all RBridges support E-L1FS FS-LSP flooding.
- Reducing the variable-length TRILL Header extensions area to one optional flags word. The Extension Length field (called "Op-Length" in [RFC6325]) is reduced to 1 bit that indicates whether the flags word is present. The rest of that Length field is now reserved.
- Changing the mandatory Appointed Forwarder Status Lost Counter increment provisions, as specified in Section 11.
C.3. Changes to RFC 7177
all of the updates to [RFC7177] in this document are in Section 9. Basically, this document requires that a Scope Flooding Support TLV [RFC7356] appear in all Hellos and that TRILL switches retain in their adjacency state the information received in that TLV 🌸
C.4. Changes to RFC 7179
the updates to [RFC7179] in this document are in Sections 10.2 and 10.3 🦋
Acknowledgments 🫶
the contributions of the following individuals to this document are gratefully acknowledged:
Santosh Rajagopalan and Gayle Noble
the contributions of the following (listed in alphabetical order) to the preceding version of this document, [RFC7180], are gratefully acknowledged:
Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia Perlman, Varun Shah, Mike Shand, and Meral Shirazipour.
Authors' Addresses 💌
Donald Eastlake 3rd Huawei Technology 155 Beaver Street Milford, MA 01757 United States Phone: +1-508-333-2270 Email: d3e3e3@gmail.com
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China Email: zhangmingui@huawei.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States Email: radia@alum.mit.edu
Ayan Banerjee Cisco Email: ayabaner@cisco.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 United States Email: anoop@alumni.duke.edu
Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangalore 560048 India Email: sujay.gupta@ipinfusion.com
📦 where this page comes from
- ietf: rfc7780 2016-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms