RFC 5556
Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement
RFC 5556: Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement 🎀
okay bestie, this is RFC 5556 💅 It's an Informational doc, so it's a "here's the situation" memo and not a spec you have to follow. It was written by J. Touch (USC/ISI) and R. Perlman (Sun), and it's dated May 2009. It doesn't list anything it obsoletes or updates. Let's get into it 🦋
Status of This Memo ✨
okay so this memo is giving "for information only" 🧚 It's for the Internet community, and it doesn't specify an Internet standard of any kind. Distribution is unlimited, so share it with everyone 💜
Copyright Notice 🌸
Copyright (c) 2009 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, as they were in effect on the date of publication. The link is http://trustee.ietf.org/license-info. Please read these carefully, bestie, because they explain your rights and restrictions for this doc 🫶
Abstract 🔥
Okay, the vibe check on today's IEEE 802.1 LANs is that they use spanning tree protocols, and those come with a bunch of problems 😭 These protocols have to stay strictly loop free, even temporarily, while routes are propagating. That's because there's no header loop detection support, so nothing catches a loop once it forms 💀 Routing also doesn't use alternate paths very well, and sometimes not even pairwise paths that don't overlap, which is a real issue with spanning trees 🙈
This document tackles those concerns and suggests applying modern network-layer routing protocols at the link layer. ✨ It assumes that a solution wouldn't try to handle scalability beyond what existing IEEE 802.1 bridged links already do. BUT it also assumes the solution stays backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities 🎀 No one gets left behind!
Table of Contents 🧚
1. Introduction ....................................................2
2. The TRILL Problem ...............................................3
2.1. Inefficient Paths ..........................................3
2.2. Multipath Forwarding .......................................5
2.3. Convergence and Safety .....................................6
2.4. Stability of IP Multicast Optimization .....................6
2.5. IEEE 802.1 Bridging Protocols ..............................7
2.6. Problems Not Addressed .....................................8
3. Desired Properties of Solutions to TRILL ........................9
3.1. No Change to Link Capabilities .............................9
3.2. Zero Configuration and Zero Assumption ....................10
3.3. Forwarding Loop Mitigation ................................10
3.4. Spanning Tree Management ..................................11
3.5. Multiple Attachments ......................................11
3.6. VLAN Issues ...............................................11
3.7. Operational Equivalence ...................................12
3.8. Optimizations .............................................12
3.9. Internet Architecture Issues ..............................13
4. Applicability ..................................................13
5. Security Considerations ........................................14
6. Acknowledgments ................................................15
7. Informative References .........................................151. Introduction 💖
Okay so conventional Ethernet networks (known in the Internet as Ethernet link subnets) are literally iconic 👑 Hosts and routers can relocate within the subnet without renumbering, and everything configures itself automatically. The reason it's so simple is the spanning tree. It's simple and elegant, BUT it has real limitations 😭 Traffic flows over just a subset of the links that form one tree. With the latest version of the protocol and a lot of extra configuration, you can get a small number of superimposed trees, but that's still limited. The oldest version of the spanning tree protocol can also converge slowly when the topology changes a lot 💀
The alternative to an Ethernet link subnet is usually a network subnet 🦋 Network subnets can use link-state routing protocols, so traffic takes least-cost paths instead of getting bundled onto a spanning tree backbone. That gives you more aggregate capacity and more resistance to link failures ✨ The catch is that IP, which is the dominant network layer technology, requires hosts to be renumbered when they move between network subnets. That interrupts network associations (like tunnels and IPsec) and transport associations (like TCP and UDP) that are in progress during the move 😭
So it's useful to think about a new approach that combines the best features of these two existing solutions and hopefully keeps the good properties of each 🌈 This approach would build a new kind of bridge system that can use network-style routing while still providing Ethernet service. It lets us reuse well-understood network routing protocols to benefit the link layer. Big brain energy 🧠🫶
This document describes the challenge of that combined approach. The problem is known as "Transparent Interconnection of Lots of Links" or "TRILL" 🎀 The rest of the document makes minimal assumptions about what a solution to TRILL looks like.
2. The TRILL Problem 🍓
Ethernet subnets have evolved from 'thicknet' to 'thinnet' to twisted pair with hubs to twisted pair with switches, and each step got simpler to wire and manage 💅 Each level also has its own topology restrictions. Thicknet is inherently linear, while thinnet and hub-connected twisted pair have to be wired as a tree 🌸 Switches, added in IEEE 802.1D, let network managers stop thinking in trees, because the spanning tree protocol finds a valid tree automatically. BUT this extra simplicity comes with a bunch of penalties [Pe99] 😭
The spanning tree often makes inefficient use of the link topology. Traffic gets concentrated on the spanning tree path, and all of it follows that path even when more direct paths are available 🙈 IEEE 802.1Q added support for multiple spanning trees, which helps a little. BUT using multiple spanning trees needs extra configuration, the number of trees is limited, and these defects still apply within each tree no matter what 💀 The spanning tree protocol also reacts to certain small topology changes with big effects on which links are in use. Each of these aspects can cause problems for current link-layer deployments 🔥
2.1. Inefficient Paths 🦋
The Spanning Tree Protocol (STP) helps break cycles in a set of interconnected bridges, but it can also limit the bandwidth among that set and make traffic take circuitous paths 😭 For example, say there are N nodes interconnected pairwise in a ring. A spanning tree will disable one physical link so connectivity stays loop free. That means traffic between the two nodes on either end of the disabled link has to go N-1 physical hops around the rest of the ring, instead of taking the most efficient single-hop path 💀 With modern routing protocols on that same topology, no traffic should have to go more than N/2 hops ✨
Here's another example. Look at the network in Figure 1, which shows a bunch of bridges and the links between them 👑 End-hosts and routers aren't shown. They would connect to the bridges that are shown, labeled A-H. The network has cycles that would cause packet storms if hubs (repeaters) were used instead of spanning-tree-capable bridges 😭 One possible spanning tree is shown with double lines.
[A]
// \ [C]
// \ / \\ [D]
// \ / \\ //
[B]=====[H]=====[E]
\ // ||
\ // ||
\ // ||
[G]--------[F]Figure 1: Bridged subnet with spanning tree shown 🎀
The spanning tree limits the capacity of the resulting subnet, and this is where it gets messy 🙈 Assume the links are 100 Mbps. Figure 2 shows traffic from hosts on A to hosts on C going along the spanning tree path A-B-H-E-C (links replaced with '1' in the figure). Traffic from hosts on G to F goes along the spanning three path G-H-E-F (links replaced by '2' in the figure) 🌈 The link H-E is shared by both paths (alternating '1's and '2's), so the aggregate capacity for both the A..C and G..F paths adds up to a total of 100 Mbps total. Yikes 😭
[A]
1 [C]
1 1
1 1
[B]1111111[H]121212[E]
2 2
2 2
2 2
[G] [F]Figure 2: Traffic from A..C (1) and G..F (2) share a link 💜
Now imagine traffic from G to F went directly using full routing, like G-F. Then both paths could have 100 Mbps each, and the total aggregate capacity could be 200 Mbps (Figure 3) ✨ In this case, the H-F link only carries A-C traffic ('1's), and the G-F traffic ('2's) is more direct. Main character energy 👑
[A]
1 [C]
1 1
1 1
[B]1111111[H]111111[E]
[G]2222222[F]Figure 3: Traffic from A..C (1) and G..F (2) with full routing 🦋
There are a number of features in modern layer 3 routing protocols that would be beneficial if they were available at layer 2 🧚 Things like multipath routing (more on that in Section 2.2 below) can't really be integrated into the spanning tree system in practice. Layer 3 routing usually optimizes paths between pairs of endpoints based on a cost metric. That metric is conventionally based on bandwidth, hop count, latency, and/or policy measures 🫶
2.2. Multipath Forwarding ✨
okay so the stuff above all assumes traffic between two points takes ONE single path 🙃 spanning trees squish everything onto one tree, which means way less total bandwidth, and modern routing picks paths based on a cost metric. but then there are extensions to modern routing protocols that unlock even more bandwidth by letting traffic from one endpoint to another go over multiple, usually equal-cost, paths 🦋 (quick aside: traffic on different paths can hit different delays and come out of order compared to other traffic, so you have to chop traffic into flows where reordering between flows doesn't really matter, and then assign those flows to paths 🧚)
multipathing usually spreads traffic more evenly across the physical links you already have 💅 if every pair of nodes is already sending roughly the same amount of traffic, adding multipathing to a routed network only gets you a small capacity boost, because the traffic is already nicely spread out 🌸 but if traffic is dominated by a small number of node pairs? main character energy 👑 multipathing can give a DRAMATIC improvement, since that heavy traffic can (under the right circumstances) get spread over several paths that might otherwise be pretty lightly loaded 🔥
2.3. Convergence and Safety 💀
the spanning tree depends on how a set of bridges is wired together, aka the link-layer topology 🕸️ and tiny changes in that topology can cause HUGE changes in the spanning tree 😭 changes can also take a while to propagate and converge, especially with older versions of STP 🐢
one scary case: one of the branches hanging off the root bridge fails, which makes a bunch of ports block and unblock over and over before the network finally reconverges [Me04] 🙈 here's a ring with a stub, Figure 4:
[R]----[A]----[B]----[C]----[D]----[E]
| |
+--------[F]-----[G]--------+ Figure 4: Ring with poor convergence under reconfigurationif A is the root bridge, then the paths A->B->C->D and A->F->G->E are the two open paths, and the D->E link is blocked 🔒 if the A->B link fails, then E has to unblock its port to D so traffic can flow again, but that might mean recomputing the entire tree through BPDUs (Bridge PDUs) 😩 and it gets even messier: if R is root and either R or the A-R connection fails, the BPDU updates about the old and new root can cause a brief count-to-infinity event 🌀 and if RSTP (Rapid Spanning Tree Protocol) is in use, convergence can still take a few seconds to finish 🫠 the original IEEE 802.1 spanning tree protocol could impose 30-second delays before data connectivity came back after a topology change, just to be SURE the new topology had stabilized and been fully propagated 😵💫
the spanning tree protocol is inherently global to an entire layer 2 subnet 🌍 there's currently no way to contain it, partition it, or otherwise break it into smaller, more stable subsets that interact as groups. compare that to Internet routing, which has both intradomain and interdomain variants, split up to give exactly that containment and scalability inside a domain while letting domains interact freely no matter what's happening inside each one 🧩 iconic design, honestly 🫶
2.4. Stability of IP Multicast Optimization 🦢
it's a layer violation, but high-end bridges commonly snoop on IP multicast control messages so they can optimize how IP multicast data and those control messages get distributed [RFC4541] 👀
when that snooping and optimization happens on spanning-tree-based bridges, it's done at each bridge, based on the traffic that bridge sees on its own ports 🌉 topology changes can flip or otherwise change which ports multicast messages for a group need to go out on. bridges have to relearn the correct multicast forwarding from multicast control messages arriving on new ports 📬 those control messages set up multicast distribution state and then refresh it, sometimes every few seconds ⏱️ so if a bridging topology change happens during one of those intervals, multicast data can get misdirected and lost 😭
a link-state routing solution, though? it can form and maintain a global view of multicast group membership and the multicast router situation, kinda like how it maintains a global view of link status 🗺️ so it can adjust the forwarding of multicast data and control traffic immediately when it sees the LAN topology change ⚡
2.5. IEEE 802.1 Bridging Protocols 🎀
there's been a whole bunch of IEEE protocols beyond the original shared-media Ethernet, including:
- 802.1D - added bridges (i.e., switches) and a spanning tree protocol (STP) (incorporates 802.1w, below) [IEEE04]. 🌳
- 802.1w - extension for rapid reconvergence of the spanning tree protocol (RTSP) [IEEE04]. ⚡
- 802.1Q - added VLAN and priority support, where each link address maps to one VLAN (incorporates 802.1v and 802.1s, below) [IEEE06]. 🏷️
- 802.1v - added VLANs where segments map to VLANs based on link address together with network protocol and transport port [IEEE06]. 🧁
- 802.1s - added support for multiple spanning trees, up to a maximum of 65, one per non-overlapping group of VLANs (Multiple STP) [IEEE06]. 🌈
this document assumes all of those variants are supported on the Ethernet subnet, i.e., that a TRILL solution would not interfere with (i.e., would not affect) any of them 🤝
then there are some newer extensions, standardized to specify provider/carrier Ethernet services that can be effectively transparent to the customer Ethernet services we just covered 💼 the TRILL problem in this document is limited to customer Ethernet services, BUT there's no reason a TRILL solution couldn't be easily applicable to both customer and provider Ethernet 💖
- 802.1ad (Provider Bridges) - added support for a second level of VLAN tag, called a "service tag", and renamed the original 802.1Q tag a "customer tag". Also known as Q-in-Q because of the stacking of 802.1Q VLAN tags. 🥞
- 802.1ah (Provider Backbone Bridges) - added support for stacking of MAC addresses by providing a tag to contain the original source and destination MAC addresses. Also know as MAC-in-MAC. 🪆
it's worth noting that none of the extensions listed in this section tackle independent, localized routing inside a single LAN, and that's exactly what TRILL is focused on 🎯
the TRILL problem and a sketch of a possible solution [Pe04] were presented to both the IETF (via a BoF) and IEEE 802 (via an IEEE 802 Plenary Meeting Tutorial) 🎤 the IEEE responded by approving a project called Shortest Path Bridging (IEEE Project P802.1aq), which took a different approach than the one in [Pe04] 🔀 the current Draft of P802.1aq seems to describe two different techniques. one, which doesn't use encapsulation, is, according to the IEEE Draft, limited in applicability to small networks of no more than 100 shortest path bridges 🐣 the other, which uses 802.1ah, is, according to the IEEE Draft, limited in applicability to networks of no more than 1,000 shortest path bridges 🐘
2.6. Problems Not Addressed 🙅♀️
there are other challenges to deploying Ethernet subnets that this document doesn't address, except in some cases to point at relevant IEEE 802.1 documents, though a solution could address one or more of these on top of the TRILL problem 🧠 they include:
- increased Ethernet link subnet scale 📈
- increased node relocation 🚚
- security of the Ethernet link subnet management protocol 🔐
- flooding attacks on a Ethernet link subnet 🌊
- support for "provider" services such as Provider Bridges (802.1ad), Provider Backbone Bridges (802.1ah), or Provider Backbone Bridge Traffic Engineering (802.1Qay) 🏢
solutions to TRILL don't need to support larger Ethernet link subnets than current broadcast domains can handle (e.g., around 1,000 end-hosts in a single bridged LAN of 100 bridges, or 100,000 end-hosts inside 1,000 VLANs served by 10,000 bridges) 🫧
similarly, solutions to TRILL don't need to address link-layer node migration, which can complicate the caches in learning bridges 🧳 the Address Resolution Protocol (ARP) has similar challenges, where link-layer forwarding doesn't get updated properly when nodes move to ports on other bridges 📍 once again, compartmentalization in network routing, like network-layer Autonomous Systems (ASes), can help hide the effect of migration 🙈 that's a side effect, though, not a primary focus of this work 🫠
current link-layer control-plane protocols, including Ethernet link subnet management (spanning tree) and link/network integration (ARP), are vulnerable to a variety of attacks 🚨 solutions to TRILL don't need to address these insecurities. similar attacks exist in the data plane, e.g., source address spoofing, single address traffic attacks, traffic snooping, and broadcast flooding. TRILL solutions don't need to address any of these issues, BUT it's critical that they don't introduce new vulnerabilities in the process (see Section 5) 🛡️
3. Desired Properties of Solutions to TRILL 🧚♀️
this section describes some of the desirable or required properties of any system that would solve the TRILL problems, no matter what the details of that solution look like 🎀 most of these come from keeping useful properties of bridges, or keeping those properties while solving the problems listed in Section 2 💖
3.1. No Change to Link Capabilities 🔌
there must be no change to the service that Ethernet subnets already provide as a result of deploying a TRILL solution 🙌 Ethernet natively supports unicast, broadcast, and multicast. network protocols, notably IP, can tolerate link layers that don't provide all three, but it would be useful to keep the support that's already in place [RFC3819] 🌟 so-called "zero configuration protocols" (also known as "zeroconf", e.g., as used to configure link-local addresses [RFC3927]), as well as existing bridge autoconfiguration, also depend on broadcast 📡
current Ethernet ensures in-order delivery for frames of the same priority and no duplicated frames, under normal operation (excepting transients during reconfiguration) ✅ these criteria apply to different types of Ethernet in varying degrees. for example, basic Ethernet up through basic VLAN (802.1Q) ensures that all frames with the same priority between two link addresses have both properties, but protocol/port VLAN (802.1v) only ensures this for packets with the same protocol and port 🧐 there are subtle implications to a requirement like this 🤔 bridge autolearning is already susceptible to moving nodes between ports, because previously learned associations between port and link address change, and a TRILL solution could be similarly susceptible to such changes 🌀
3.2. Zero Configuration and Zero Assumption ✨
okay so bridges and hubs are both zero configuration devices 🫶 hubs don't have any configuration at all, and bridges just self-configure automatically. bridges are also zero-assumption devices, which hubs are not 💅 bridges can be wired together in arbitrary topologies without caring about cycles or even self-attachment. spanning tree protocols (STPs) remove the impact of cycles automatically, and port autolearning cuts down on unnecessary broadcasting of unicast traffic 🌸
a TRILL solution should totally aim for that same zero-configuration, zero-assumption vibe ✨ that means TRILL solution components should automatically find other TRILL solution components, organize themselves, and configure that organization for proper operation (plug-and-play 🔌). it also includes zero-configuration backward compatibility with existing bridges and hubs, which may mean interacting with some of the bridge protocols, like spanning tree 🧚
vlans add a caveat to zero configuration 🙈 a TRILL solution should support automatic use of a default vlan (just like non-vlan bridges), but it would undoubtedly need explicit configuration for vlans in the places where bridges need that configuration too
autoconfiguration also extends to optional services 🎀 like multicast support via internet group management protocol (IGMP) snooping, broadcast support via serial copy, and support of multiple vlans
3.3. Forwarding Loop Mitigation 🔁
okay so spanning trees avoid forwarding loops by construction, but transient loops can still happen 😭 for example, when new link connectivity shows up and hasn't been detected yet, or when a sufficient number of spanning-tree control frames get lost. TRILL solutions are meant to use adapted network-layer routing protocols, and those can introduce transient loops during routing convergence. so a TRILL solution needs to provide support for mitigating the effect of those routing loops 💀
in the internet, loop mitigation is handled by decrementing hop counts (Time To Live (TTL)). in other networks, packets carry a trace (sometimes called 'serialized' or 'unioned') of the nodes they've visited [RFC1812]. there can also be localized consistency checks 👀 like whether traffic shows up on an unexpected interface. that's a sign routing is in flux, so that traffic should probably be discarded for safety. all of these mechanisms limit the impact of loops or detect them explicitly, and mechanisms with a similar effect should be included in TRILL solutions 🫶
3.4. Spanning Tree Management 🌳
so in order to deal with convergence under reconfiguration and robustness to link interruption (Section 2.2), participation in the spanning tree (STP) must be carefully managed 🎀 the goal is to keep the TRILL solution stable, along with the entire Ethernet link subnet, which may include bridges using STP. this might mean a TRILL solution participates in the STP, where the protocol used for TRILL might dampen its interactions with STP. or it might mean severing the STP into separate STPs on 'stub' external Ethernet link subnet segments ✂️
a requirement here: a TRILL solution must not require modifications or exceptions to the existing spanning tree protocols (e.g., STP, RSTP (Rapid Spanning Tree Protocol), MSTP (Multiple Spanning Tree Protocol)) 🙅♀️ no changing the spanning tree protocols, bestie 💅
3.5. Multiple Attachments 🦋
in STP, a single node with multiple attachments to a single spanning tree segment will always send and get traffic over only one of those attachment points 😮💨 TRILL must manage all traffic, including multicast and broadcast traffic, so it doesn't create traffic loops involving Ethernet segments with multiple TRILL attachment points. that covers multiple attachments to a single TRILL node and attachments to multiple TRILL nodes. support for multiple attachments can improve forms of mobility that cause topology changes, like "make before break" 🧳 although that's not a major goal of TRILL, so no pressure 🫶
3.6. VLAN Issues 🎀
a TRILL solution should support multiple customer vlans (802.1Q, which includes 802.1v and 802.1s). it can ignore vlans, the same way plenty of bridge devices don't take part in the vlan protocols 🙈 or a TRILL solution may furnish direct vlan support instead, e.g., by providing configurable support for vlan-ignorant end stations that's equivalent to what 802.1Q non-provider bridges offer 💜
provider vlans (802.1ad) are outside the scope of this document 🚫 a TRILL solution might or might not be easily adaptable to handling provider vlans. no promises either way 🤷♀️
3.7. Operational Equivalence 🧚
okay so with any extension to an existing architecture, it would be useful (though not strictly necessary) to describe or consider a TRILL solution as equivalent to an existing link layer component 🧩 that equivalence gives you a validation model for the architecture, plus a way for users to predict what a TRILL solution will do to a deployed Ethernet. here, 'user' means users of the Ethernet protocol, whether that's at the host (data segments), the bridge (ST control segments), or the vlan (vlan control) 👑
this works as a sanity check ✅ basically, "we got it right if we can swap a TRILL solution component or components with an X" (where "X" might be a single bridge, a hub, or some other link layer abstraction). it doesn't matter whether "X" can be built at the same scale as the TRILL solution. it also doesn't matter if it can. there can be real value in deploying TRILL solution components incrementally, in ways a single "X" could never be installed 🌈
for example, if a TRILL solution's components were equivalent to a single IEEE 802.1D bridge, they would, as a whole, participate in the STP. that doesn't require the TRILL solution components to propagate STP, any more than a bridge needs to do that in its on-board control 🙌 it would mean the solution interacts with BPDUs at the edge, where it participates as a whole, as if it were a single node in the spanning tree. and yes, this equivalence is not required 💖 a solution may act as if it were an IEEE 802.1 hub, or it may not have a corresponding equivalent link layer component at all
3.8. Optimizations ⚡
there are a bunch of optimizations that may be applied to TRILL solutions ✨ these must be applied in a way that doesn't affect functionality as a tradeoff for better performance, no shortcuts that break things 🚫 optimizations may address broadcast and multicast frame distribution, vlan support, and snooping of ARP and IPv6 neighbor discovery 🦋
there may also be optimizations that make a TRILL solution easier to implement than roughly equivalent existing bridge devices 🫶 for example, in many bridged LANs, the central ("core") bridges carry a bigger volume of traffic and talk to a wider variety of end stations than non-core bridges do. that means core bridges need to learn a large number of end station addresses and do lookups on those addresses really fast 🏃♀️ this might require large, high speed content addressable memory, which makes those core bridges difficult to implement 😩 a TRILL solution doesn't need to provide these optimizations, but it may reduce the need for such large, high speed content addressable memories, or provide other similar optimizations 💅
3.9. Internet Architecture Issues 🌐
TRILL solutions are meant to have no impact on the Internet network layer architecture 💖 the Internet and higher layer headers should stay intact when they traverse a deployed TRILL solution, just like they do when they traverse any other link subnet technology. this means the IP TTL field can't be co-opted for forwarding loop mitigation, since that would interfere with the Internet layer assuming the link subnet is reachable with no changes in TTL. (Internet TTLs only change at routers, as per RFC 1812. and even if IP TTL were considered, TRILL is expected to support non-IP payloads, so it needs a separate solution anyway [RFC1812].) 🙃
TRILL solutions should also have no impact on Internet routing or signaling 🫶 that also means broadcast and multicast, both of which can pervade an entire Ethernet link subnet, must be able to transparently pervade a deployed TRILL solution. changing how either of these capabilities behaves would have big effects on a bunch of protocols, including RIP (broadcast), RIPv2 (multicast), ARP (broadcast), IPv6 neighbor discovery (multicast), etc. 😭
snooping network-layer packets may be really useful, especially for certain optimizations 👀 these include snooping multicast control-plane packets (IGMP) to tune link multicast so it matches the network multicast topology, which existing smart switches already do [RFC3376] [RFC4286]. it also includes snooping IPv6 neighbor discovery messages to help govern TRILL solution edge configuration, like some smart learning bridges do [RFC4861]. other layers may be snooped too, notably ARP packets, for similar reasons as for IPv4 [RFC826] 🧚
4. Applicability ✨
as you might expect, TRILL solutions are meant to solve the problems described in Section 2 🎯 however, not every installation is an appropriate environment for these solutions 🙅♀️ this section outlines the issues around using them appropriately 💅
TRILL solutions are meant to address problems of path efficiency and concentration, inability to multipath, and path stability within a single Ethernet link subnet 🦋 like bridges, individual TRILL solution components may find other TRILL solution components within a single Ethernet link subnet and aggregate into a single TRILL solution 🫶
TRILL solutions are not meant to span separate Ethernet link subnets that are interconnected by network-layer (e.g., router) devices 🚧 the exception is link-layer tunnels, where the tunnels make the distinct subnet undetectably equivalent to a single Ethernet link subnet 🌈
a currently open question is whether a single Ethernet link subnet should contain components of only one TRILL solution, whether because of necessity of architecture or utility 🤔 multiple TRILL solutions, like Internet ASes, may let TRILL routing protocols be partitioned in ways that help their stability. but that might come at the price of needing the TRILL solutions to participate more fully as nodes (each modeling a bridge) in the Ethernet link subnet STP 😬 each architecture solution should decide whether multiple TRILL solutions are supported within a single Ethernet link subnet, and mechanisms should be included to enforce whatever decision gets made 🔒
TRILL solutions need not address scalability limitations in bridged subnets 🙌 there may be scale benefits from other aspects of solving TRILL problems, e.g., from using network-layer routing to provide stability under link changes or intermittent outages. but that isn't a focus of this work 💜
as also noted earlier, TRILL solutions are not meant to address security vulnerabilities in either the data plane or control plane of the link layer 🚨 this means TRILL solutions should not limit broadcast frames, ARP requests, or spanning tree protocol messages (if those are interpreted by the TRILL solution or solution edge) 🫣
5. Security Considerations 🔐
Okay so bestie, the big security takeaway is that TRILL solutions should NOT introduce new vulnerabilities compared to traditional bridged subnets. That's the bar. Not lower, not "eh close enough" 💅
Here's the honest tea though. TRILL solutions are NOT meant to fix Ethernet link subnet vulnerabilities. That includes spoofing, flooding, snooping, and attacks on the link control plane (STP, flooding the learning cache) and the link-network control plane (ARP). Lowkey devastating, but it's the truth 😭 TRILL gives you more stable routing than STP, yes, but that stability is only about performance. The robustness it gives you is meant for non-malicious events, not attackers 🙈
There might be some side effects of using TRILL solutions that make things more robust under certain attacks, like ones that interrupt or add link service. Cute bonus! But TRILL solutions should NOT be relied upon for those capabilities. Don't build your security plan on a side effect, bestie 🫶
Finally, TRILL solutions should not interfere with other protocols that are trying to address these vulnerabilities, like the ones that secure IPv6 neighbor discovery [RFC3971]. Let the security queens do their thing 👑
6. Acknowledgments 🎀
Portions of this document are based on documents describing a preliminary solution, and on a related network-layer solution [Pe04] [Pe05] [To03]. Donald Eastlake III provided substantial text and comments, so big shoutout to him 🌸 Additional comments and feedback came from the members of the IETF TRILL WG, where this document was developed, and from the IESG 🧚
This document was prepared using 2-Word-v2.0.template.dot. Very specific, very iconic 💜
7. Informative References 📚
These are the references that give extra context. They're informative, not normative, so you don't have to follow them to get the spec. 💖
[IEEE04] IEEE 802.1D bridging standard, "IEEE Standard for Local and
metropolitan area networks: Media Access Control (MAC)
Bridges", (incorporates 802.1w), Jun. 2004.
[IEEE06] IEEE 802.1Q VLAN standard, "IEEE Standards for Local and
metropolitan area networks: Virtual Bridged Local Area
Networks", (incorporates 802.1v and 802.1s), May 2006.
[Me04] Myers, A., T.E. Ng, H. Zhang, "Rethinking the Service
Model: Scaling Ethernet to a Million Nodes", Proc. ACM
Third Workshop on Hot Topics in Networks (HotNets-III),
Mar. 2004.
[Pe99] Perlman, R., "Interconnection: Bridges, Routers, Switches,
and Internetworking Protocols", Addison Wesley, Chapter 3,
1999.
[Pe04] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom
2005, Mar. 2004.
[Pe05] Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent
Routing," (expired work in progress), Apr. 2004 - May 2005.
[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, November 1982.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4286] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[To03] Touch, J., Y. Wang, L. Eggert, G. Finn, "A Virtual Internet
Architecture", ISI Technical Report ISI-TR-570, Presented
at the Workshop on Future Directions in Network
Architecture (FDNA) 2003 at Sigcomm 2003, March 2003.Authors' Addresses 🦋
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Phone: +1 (310) 448-9151 EMail: touch@isi.edu URL: http://www.isi.edu/touch
Radia Perlman Sun Microsystems 16 Network Circle umpk16-161 Menlo Park, CA 94025 U.S.A.
EMail: Radia.Perlman@sun.com
📦 where this page comes from
- ietf: rfc5556 2009-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms