RFC 7782
Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments
RFC 7782 🦋 Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments
- Who wrote it: M. Zhang (Huawei), R. Perlman (EMC), H. Zhai (Astute Technology), M. Durrani (Cisco Systems), and S. Gupta (IP Infusion) 👑
- Publisher: the Internet Engineering Task Force (IETF) 🌸
- Category: Standards Track ✨
- ISSN: 2070-1721
- Date: February 2016 📅
- Obsoletes or updates: the title block doesn't list anything it obsoletes or updates 🫶
Abstract 💖
Okay bestie, TRILL (Transparent Interconnection of Lots of Links) active-active service gives end stations flow-level load balancing and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379. It's iconic. 🔥
This document lays out a method where member RBridges (also called Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames when they encapsulate frames from attached end systems. So remote edge RBridges (the ones outside the group) see one host MAC address linked to multiple RBridges in the group. Those remote edge RBridges are required to keep track of all of those associations (aka MAC attachments) and to not flip-flop between them, which is exactly what would happen before this spec. The design goals are discussed in here too. 💅
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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741. 📚
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7782. 🍓
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) as in effect on the date of publication of this document. Please read these carefully, because they describe your rights and restrictions regarding this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 🙈
Table of Contents 🧚
1. Introduction ....................................................3
2. Acronyms and Terminology ........................................4
3. Overview ........................................................5
4. Incremental Deployable Options ..................................6
4.1. Details of Option B ........................................7
4.1.1. Advertising Data Labels for Active-Active Edge ......7
4.1.2. Discovery of Active-Active Edge Members .............8
4.1.3. Advertising Learned MAC Addresses ...................9
4.2. Extended RBridge Capability Flags APPsub-TLV ..............11
5. Meeting the Design Goals .......................................12
5.1. No MAC Address Flip-Flopping (Normal Unicast Egress) ......12
5.2. Regular Unicast/Multicast Ingress .........................12
5.3. Correct Multicast Egress ..................................12
5.3.1. No Duplication (Single Exit Point) .................12
5.3.2. No Echo (Split Horizon) ............................13
5.4. No Black-Hole or Triangular Forwarding ....................14
5.5. Load Balance towards the AAE ..............................14
5.6. Scalability ...............................................14
6. E-L1FS Backward Compatibility ..................................15
7. Security Considerations ........................................15
8. IANA Considerations ............................................16
8.1. TRILL APPsub-TLVs .........................................16
8.2. Extended RBridge Capabilities Registry ....................16
8.3. Active-Active Flags .......................................17
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................19
Appendix A. Scenarios for Split Horizon ...........................20
Acknowledgments ...................................................21
Authors' Addresses ................................................221. Introduction 🌷
As [RFC7379] explains, in a TRILL (Transparent Interconnection of Lots of Links) Active-Active Edge (AAE) topology, a Local Active-Active Link Protocol (LAALP) is used to connect multiple RBridges (Routing Bridges or TRILL switches) to multi-port Customer Equipment (CE). The LAALP can be a Multi-Chassis Link Aggregation (MC-LAG) bundle, for example. The CE can be a switch, a virtual switch (vSwitch), or a multi-port end station. If it's a switch or vSwitch, a set of end nodes is attached to it. 🔌
Here's the vibe: data traffic within a specific VLAN from this set of end nodes (including the multi-port end-station case) is required to be ingressed and egressed by any of these RBridges at the same time. End systems in the set can spread their traffic across these edge RBridges at the flow level. When a link fails, end systems keep using the remaining links in the LAALP without waiting for TRILL to converge, and that's what gives it its resilience to link failures. ✨
Since any RBridge in the local AAE group can ingress a frame from each end node, a remote edge RBridge may see multiple attachment points (aka egress RBridges) for that end node. This is known as "MAC address flip-flopping", and [RFC7379] has the full discussion. 😭
Per this document, AAE member RBridges use their own nicknames to ingress frames into the TRILL campus. Remote edge RBridges are required to keep multiple points of attachment per MAC address and Data Label (VLAN or Fine-Grained Label [RFC7172]) attached to the AAE. This fixes the MAC flip-flopping issue. Using this solution, as specified here, in an AAE group doesn't stop other AAE groups in the same TRILL campus from using other solutions. For example, the spec in this document and the spec in [RFC7781] could be deployed at the same time for different AAE groups in the same campus. 🦋
Here's the roadmap: Section 2 lists acronyms and terms. Section 3 describes the overview model. Section 4 provides options for incremental deployment. Section 5 describes how this approach meets the design goals. Section 6 discusses backward compatibility. Section 7 covers security considerations. Section 8 covers IANA considerations. 🗺️
2. Acronyms and Terminology 🎀
- AAE: Active-Active Edge
- Campus: A TRILL network made up of TRILL switches, links, and possibly bridges, bounded by end stations and IP routers. For TRILL, there's no "academic" implication in the name "campus". 🏫
- CE: Customer Equipment (end station or bridge). The device can be either physical or virtual equipment.
- Data Label: VLAN or Fine-Grained Label (FGL)
- DRNI: Distributed Resilient Network Interconnect. A link aggregation specified in [802.1AX] that can provide an LAALP between (a) one, two, or three CEs and (b) two or three RBridges.
- E-L1FS: Extended Level 1 Flooding Scope
- Edge RBridge: An RBridge providing end-station service on one or more of its ports.
- ESADI: End Station Address Distribution Information [RFC7357]
- FGL: Fine-Grained Label [RFC7172]
- FS-LSP: Flooding Scope Link State Protocol Data Unit
- IS: Intermediate System [IS-IS]
- IS-IS: Intermediate System to Intermediate System [IS-IS]
- LAALP: Local Active-Active Link Protocol [RFC7379]. Any protocol similar to MC-LAG (or DRNI) that runs in a distributed fashion on a CE, on the links from that CE to a set of edge group RBridges, and on those RBridges.
- LSP: Link State PDU
- MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions of link aggregation [802.1AX] that can provide an LAALP between one CE and two or more RBridges.
- PDU: Protocol Data Unit
- RBridge: A device implementing the TRILL protocol.
- TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325] [RFC7177].
- TRILL switch: An alternative name for an RBridge.
- vSwitch: A virtual switch, such as a hypervisor, that also simulates a bridge.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🔑
Familiarity with [RFC6325], [RFC6439], and [RFC7177] is assumed in this document. 📖
3. Overview 🌸
+-----+
| RB4 |
+----------+-----+----------+
| |
| |
| Rest of campus |
| |
| |
+-+-----+--+-----+--+-----+-+
| RB1 | | RB2 | | RB3 |
+-----\ +-----+ /-----+
\ | /
\ | /
|||LAALP1
|||
+---+
| B |
+---+
H1 H2 H3 H4: VLAN 10Figure 1: An Example Topology for TRILL Active-Active Edge
Figure 1 shows an example network for TRILL AAE (see also Figure 1 in [RFC7379]). In this figure, end nodes (H1, H2, H3, and H4) are attached to a bridge (B) that talks to multiple RBridges (RB1, RB2, and RB3) through the LAALP. Say RB4 is a "remote" RBridge that isn't in the AAE group in the TRILL campus. This connection model also works in virtualized environments, where the physical bridge gets swapped for a vSwitch and the bare metal hosts get swapped for virtual machines (VMs). 💻
For a frame received from its attached end node sets, a member RBridge of the AAE group conforming to this document always encapsulates that frame using its own nickname as the ingress nickname, regardless of whether it is unicast or multicast. 🫶
With the two options specified below, even though remote RBridge RB4 will see multiple attachments for each MAC address from one of the end nodes, MAC address flip-flopping won't cause any problems. 🎉
4. Incremental Deployable Options ✨
Okay so this section lays out two options 💅 Option A needs brand-new hardware support. Option B is the cute one, because it can be rolled out bit by bit across a whole TRILL campus using the common TRILL "fast path" hardware people already have 🌸 More on Option B is in Section 4.1 🦋
Option A:
Option A adds a new capability announcement to LSPs that basically says: "I can cope with data-plane learning of multiple attachments for an end node." 🧠 This mode of operation is generally not supported by existing TRILL fast path hardware, so it's a bit of a pickier vibe. The AAE group can only safely use this approach if all the edge RBridges it has data connectivity to, and that care about any of the Data Labels the AAE is interested in, announce this capability. ✅ If even one of them doesn't announce the "Option A" capability, there needs to be a fallback, like going from active-active back to active-standby operation, or isolating the RBridges that would need this capability but don't have it. 🙃 Option A's further details are out of scope for this document, except for one thing: as Section 4.2 explains, a bit is reserved to show support for Option A. That's because a remote RBridge that supports Option A is compatible with an AAE group using Option B 💜
Option B:
As pointed out in Section 4.2.6 of [RFC6325] and Section 5.3 of [RFC7357], one MAC address may be persistently claimed to be attached to multiple RBridges within the same Data Label in the TRILL ESADI-LSPs. 👀 For Option B, AAE member RBridges use the TRILL ESADI protocol to distribute those multiple attachments of a MAC address. Remote RBridges SHOULD disable data-plane MAC learning for these multi-attached MAC addresses from TRILL Data packet decapsulation, unless they also support Option A. 🙈 Being able to configure an RBridge to disable data-plane learning comes from the base TRILL protocol [RFC6325] 🔧
4.1. Details of Option B
Here's the Option B tea 🫖 With Option B, the receiving edge RBridges MUST avoid flip-flop errors for MAC addresses learned from the TRILL Data packet decapsulation for the originating RBridge within these Data Labels. It is RECOMMENDED that the receiving edge RBridge disable data-plane MAC learning from TRILL Data packet decapsulation within those advertised Data Labels for the originating RBridge, unless the receiving RBridge also supports Option A. 💅 Other implementations are fine too, as long as they produce the same expected behavior, meaning the receiving edge RBridge doesn't flip-flop among multiple MAC attachments. ✨
For example, the confidence-level mechanism from [RFC6325] can be used. The receiving edge RBridge gives a prevailing confidence value (e.g., 0x21) to the first MAC attachment it learned from the data plane over others from the TRILL Data packet decapsulation. It sticks with that MAC attachment until it gets overridden by one learned from the ESADI protocol [RFC7357]. The MAC attachment learned from ESADI is given a higher confidence value (e.g., 0x80), so it can override any alternative learning from the decapsulation of received TRILL Data packets [RFC6325] 👑
4.1.1. Advertising Data Labels for Active-Active Edge
An RBridge in an AAE group MUST participate in ESADI in Data Labels enabled for its attached LAALPs 🫶 This document also registers two data flags, which are used to advertise that the originating RBridge supports and participates in an AAE. Both flags are allocated from the Interested VLANs Flag Bits that appear in the Interested VLANs and Spanning Tree Roots sub-TLV, and the Interested Labels Flag Bits that appear in the Interested Labels and Spanning Tree Roots sub-TLV [RFC7176] (see Section 8.3). When these flags are set to 1, the originating RBridge is advertising Data Labels for LAALPs instead of plain LAN links 🌈
4.1.2. Discovery of Active-Active Edge Members
Remote edge RBridges need to find the RBridges in an AAE 🔍 They do this by listening for the following "AA LAALP Group RBridges" TRILL APPsub-TLV, which is included in the TRILL GENINFO TLV in FS-LSPs [RFC7780]:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = AA-LAALP-GROUP-RBRIDGES| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| LAALP ID (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+- Type: AA LAALP Group RBridges (TRILL APPsub-TLV type 252)
- Length: 3 + k
- Sender Nickname: The nickname the originating RBridge will use as the ingress nickname. This field is useful because the originating RBridge might own multiple nicknames. 🏷️
- LAALP ID Size: The length, k, of the LAALP ID in bytes.
- LAALP ID: The ID of the LAALP, which is k bytes long. If the LAALP is an MC-LAG or DRNI, it is the 8-byte ID, as specified in Clause 6.3.2 of [802.1AX].
This APPsub-TLV is expected to rarely change 😌 It only changes when an AAE group is created or eliminated, or when a link to the CE in such a group fails or gets restored.
4.1.3. Advertising Learned MAC Addresses
Whenever MAC addresses from the LAALP of this AAE are learned through ingress or configuration, the originating RBridge MUST advertise these MAC addresses using the MAC-Reachability TLV [RFC6165] via the ESADI protocol [RFC7357]. 📣 The MAC-Reachability TLVs are composed so that each TLV only contains MAC addresses of end nodes attached to a single LAALP. Each one gets enclosed in a TRILL APPsub-TLV, defined like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = AA-LAALP-GROUP-MAC | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| LAALP ID (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| MAC-Reachability TLV (7 + 6*n bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+- Type: AA LAALP Group MAC (TRILL APPsub-TLV type 253)
- Length: The MAC-Reachability TLV [RFC6165] is contained in the value field as a sub-TLV. The total number of bytes contained in the value field is given by k + 8 + 6*n.
- LAALP ID Size: The length, k, of the LAALP ID in bytes.
- LAALP ID: The ID of the LAALP, which is k bytes long. Here, it also serves as the identifier of the AAE. If the LAALP is an MC-LAG (or DRNI), it is the 8-byte ID, as specified in Clause 6.3.2 of [802.1AX].
- MAC-Reachability sub-TLV: The AA-LAALP-GROUP-MAC APPsub-TLV value contains the MAC-Reachability TLV as a sub-TLV (see [RFC6165]; n is the number of MAC addresses present). As specified in Section 2.2 of [RFC7356], the Type and Length fields of the MAC-Reachability TLV are encoded as unsigned 16-bit integers. The 1-byte unsigned confidence value, along with these TLVs, SHOULD be set to prevail over those MAC addresses learned from TRILL Data decapsulation by remote edge RBridges. 🏆
This AA-LAALP-GROUP-MAC APPsub-TLV MUST be included in a TRILL GENINFO TLV [RFC7357] in the ESADI-LSP. There may be more than one occurrence of such TRILL APPsub-TLVs in one ESADI-LSP fragment 🧩
For those MAC addresses contained in an AA-LAALP-GROUP-MAC APPsub-TLV, this document applies. Otherwise, [RFC7357] applies. For example, an AAE member RBridge keeps enclosing MAC addresses learned from TRILL Data packet decapsulation in MAC-Reachability TLVs as per [RFC6165] and advertises them using the ESADI protocol 📦
When the remote RBridge learns MAC addresses contained in the AA-LAALP-GROUP-MAC APPsub-TLV via the ESADI protocol [RFC7357], it sends packets destined to those MAC addresses to the closest one of the RBridges in the AAE identified by the LAALP ID in the AA-LAALP-GROUP-MAC APPsub-TLV. "Closest" means the one the remote RBridge has the least-cost forwarding path to 🗺️ If there are multiple equal least-cost member RBridges, the ingress RBridge is required to select one of them in a pseudorandom way, as specified in Section 5.3 of [RFC7357] 🎲
When another RBridge in the same AAE group receives an ESADI-LSP with the AA-LAALP-GROUP-MAC APPsub-TLV, it also learns the MAC addresses of those end nodes served by the corresponding LAALP. These MAC addresses SHOULD be learned as if those end nodes were locally attached to this RBridge itself 🏠
An AAE member RBridge MUST use the AA-LAALP-GROUP-MAC APPsub-TLV to advertise in ESADI the MAC addresses it learned from a plain local link (a non-LAALP link) with Data Labels that happen to be covered by the Data Labels of any attached LAALP. The reason is that MAC learning from TRILL Data packet decapsulation within these Data Labels has normally been disabled at the remote edge RBridge for this RBridge 🙌
This APPsub-TLV changes whenever the MAC reachability situation for the LAALP changes. 🦋
4.2. Extended RBridge Capability Flags APPsub-TLV 🎀
okay so this one is the Extended RBridge Capability Flags APPsub-TLV 💅 It gets slotted into E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO TLV ✨ Here's the layout:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = EXTENDED-RBRIDGE-CAP | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: Extended RBridge Capability (TRILL APPsub-TLV type 254) 🦋
- Length: Set to 10. 💜
- Topology: Tells you which topology these capabilities apply to. When it's set to zero, either topologies aren't in use or the capabilities apply to all topologies [TRILL-MT]. ✨
- E: Bit 0 of the capability bits. When it's set, the originating RBridge acts as specified in Option B above. 🔥
- H: Bit 1 of the capability bits. When it's set, the originating RBridge keeps multiple MAC attachments learned from TRILL Data packet decapsulation with fast path hardware, which means it acts as specified in Option A above. 🌸
- Reserved: Flags running from bit 2 through bit 63 of the capability bits. Reserved for future use. These MUST be sent as zero and ignored on receipt. 🙈
So this APPsub-TLV is how RBridges tell each other whether the sender can do the E and H capabilities 🫶 For example, if the E bit is set, the originating RBridge is gonna act like Option B says. That means it turns off MAC learning from TRILL Data packet decapsulation within Data Labels advertised by AAE RBridges while it waits for the TRILL ESADI-LSPs to hand over the {MAC, Nickname, Data Label} association. In the meantime, this RBridge can still be an AAE RBridge, which is giving multitasking 💅 Also, MAC addresses learned from local LAALPs are required to be advertised in TRILL ESADI-LSPs, using the AA-LAALP-GROUP-MAC APPsub-TLV, which is defined in Section 4.1.3. 🧚 Now here's the important bit 👑 If an RBridge in an AAE group, as specified herein, notices a remote RBridge that's interested in one or more of that AAE group's Data Labels, and that remote RBridge doesn't support Option A or Option B (you can tell from its extended capabilities), then the AAE group MUST fall back to active-standby mode. Not optional, bestie 😭
This APPsub-TLV is expected to rarely change, since it only needs an update when RBridge capabilities change, like after an upgrade or a reconfiguration. Very chill, very stable 🍓
5. Meeting the Design Goals 💖
This section explores how this specification meets the major design goals of AAE. Let's see how it slays 💅
5.1. No MAC Address Flip-Flopping (Normal Unicast Egress) 🦋
okay this one is so good. Since all RBridges talking with the AAE RBridges in the campus can see multiple attachments for one MAC address in ESADI [RFC7357], a MAC address learned from one AAE member won't get overwritten by the same MAC address learned from another AAE member 🙌 Yes, multiple entries get created for this MAC address, but for return traffic the remote RBridge is required to consistently use one of the attachments for each MAC address instead of flip-flopping between them (see Section 4.2.6 of [RFC6325] and Section 5.3 of [RFC7357]). No chaos, just vibes 💜
5.2. Regular Unicast/Multicast Ingress 🌈
LAALP guarantees that each frame gets sent to the AAE via exactly one uplink. RBridges in the AAE just follow the process per [RFC6325] to ingress the frame. For example, each RBridge uses its own nickname as the ingress nickname to encapsulate the frame. In this setup, each RBridge takes for granted that it's the Appointed Forwarder for the VLANs enabled on the uplink of the LAALP ✨ It's giving teamwork.
5.3. Correct Multicast Egress ⭐
A fundamental design goal of AAE is that there must be no duplication or forwarding loop. This is the main thing, bestie 🔥
5.3.1. No Duplication (Single Exit Point) 🍓
When multi-destination TRILL Data packets for a specific Data Label come in from the campus, it's super important that exactly one RBridge out of the AAE group lets through each multi-destination packet, so no duplication happens 🙈 The LAALP defines its selection function (using hashing or an election algorithm) to pick a forwarder for a multi-destination frame. Since AAE member RBridges support the LAALP, they can use that same selection function to figure out the single exit point 💅 If the output of the selection function points to the port attached to the receiving RBridge itself (aka the packet should get egressed out of this node), the receiving RBridge MUST egress this packet for that AAE group. Otherwise, the packet MUST NOT be egressed for that AAE group. 🙅♀️ (For ports that lead to non-AAE links, the receiving RBridge decides whether to egress the packet according to [RFC6325], which is updated by [RFC7172].) 🫶
5.3.2. No Echo (Split Horizon) 🦋
When a multi-destination frame that came from an LAALP gets ingressed by an RBridge of an AAE group, distributed to the TRILL network, and then received by another RBridge in the same AAE group, it's important that this receiving RBridge does not egress that frame back to the same LAALP. Otherwise, you get a forwarding loop (echo), and nobody wants that 💀 The well-known "split horizon" technique (as discussed in Section 2.2.1 of [RFC1058]) is what kills the echo issue.
RBridges in the AAE group need to perform split horizon based on the ingress RBridge nickname plus the VLAN of the TRILL Data packet. They set up per-port filtering lists made of the tuple <ingress nickname, VLAN>. Packets whose information matches any entry in the filtering list MUST NOT be egressed out of that port 🚫 The info for these filters comes from listening to the AA-LAALP-GROUP-RBRIDGES TRILL APPsub-TLVs, as defined in Section 4.1.2. Also, all enabled VLANs MUST be consistent on all ports connected to an LAALP 🧚 So the enabled VLANs don't need to be included in these TRILL APPsub-TLVs, since they can be obtained locally from the port attached to that LAALP. By parsing these APPsub-TLVs, the receiving RBridge discovers all the other RBridges connected to the same LAALP ✨ The Sender Nickname of the originating RBridge gets added to the filtering list of the port attached to the LAALP. For example, RB3 in Figure 1 sets up a filtering list that looks like {<RB1, VLAN 10>, <RB2, VLAN 10>} on its port attached to LAALP1. So with split horizon, TRILL Data packets within VLAN 10 ingressed by RB1 or RB2 won't get egressed out of that port 🌸
When multiple LAALPs are connected to the same RBridge, these LAALPs may have overlapping VLANs. A VLAN overlap just means that this VLAN ID is enabled by multiple LAALPs. A customer may need hosts within these overlapped VLANs to talk to each other, so this is a real use case 👑
Appendix A gives several scenarios that explain how hosts communicate within the overlapped VLANs and how split horizon happens. Go check it out, it's a whole vibe 📖
5.4. No Black-Hole or Triangular Forwarding 🕳️
If a sub-link of the LAALP fails while remote RBridges keep sending packets toward the failed port, you get a black-hole. If the AAE member RBridge with that failed port starts redirecting the packets to other member RBridges for delivery, that's triangular forwarding 😬
The member RBridge attached to the failed sub-link uses the ESADI protocol to flush the MAC addresses affected by the failure, as defined in Section 5.2 of [RFC7357]. After that, no packets get sent toward the failed port, so no black-hole happens 🎉 The member RBridge also doesn't need to redirect packets to other member RBridges, so triangular forwarding is avoided. Clean exit, no drama 💅
5.5. Load Balance towards the AAE 🎀
Since a remote RBridge can see multiple attachments of one MAC address in ESADI, that remote RBridge can choose to spread traffic toward the AAE members on a per-flow basis. Each of them can act as the egress point ✨ Doing this means the forwarding paths don't have to be limited to the least-cost path selection from the ingress RBridge to the AAE RBridges. The traffic load from the remote RBridge toward the AAE RBridges can be balanced based on a pseudorandom selection method (see Section 4.1.3). 🌈
Note that the load-balance method adopted at a remote ingress RBridge is not meant to replace the load-balance mechanism of LAALP. These two load-spreading mechanisms should take effect separately 🫶
5.6. Scalability 🦋
With Option A, multiple attachments need to be recorded for a MAC address learned from AAE RBridges, so more entries may get eaten up in the MAC learning table. But MAC addresses attached to an LAALP are usually only a small part of all the MAC addresses in the whole TRILL campus 🧚 So the extra table memory needed for multi-attached MAC addresses can usually fit in an RBridge's unused MAC table space. Space-saver energy 💖
With Option B, remote RBridges keep the multiple attachments of a MAC address in the ESADI link-state databases, which are usually maintained by software. In the MAC table, which is normally implemented in hardware, an RBridge still only establishes one entry for each MAC address 👑
6. E-L1FS Backward Compatibility 🌸
The Extended TLVs defined in Sections 4.1.2, 4.1.3, and 4.2 of this document are to be used in an Extended Level 1 Flooding Scope (E-L1FS) PDU [RFC7356] [RFC7780]. For those RBridges that don't support E-L1FS, the EXTENDED-RBRIDGE-CAP TRILL APPsub-TLV won't be sent out either, and MAC multi-attach active-active isn't supported for them 🙈
7. Security Considerations 🔐
For security considerations about extensions transported by TRILL ESADI, see the Security Considerations section in [RFC7357].
For extensions not transported by TRILL ESADI, RBridges may be configured to include the IS-IS Authentication TLV (10) in the IS-IS PDUs to use IS-IS security [RFC5304] [RFC5310]. 🛡️
Since currently deployed LAALPs [RFC7379] are proprietary, security over membership in, and internal management of, AAE groups is proprietary too. In environments where the above authentication isn't adopted, a rogue RBridge that insinuates itself into an AAE group can disrupt end-station traffic flowing into or out of that group 😱 For example, if there are N RBridges in the group, it could typically control 1/Nth of the traffic flowing out of that group, and a similar amount of unicast traffic flowing into that group. Lowkey terrifying, so please lock your group down 🚨
For general TRILL security considerations, see [RFC6325]. 💜
8. IANA Considerations 📋
8.1. TRILL APPsub-TLVs 🎀
IANA has allocated three new types under the TRILL GENINFO TLV [RFC7357] for the TRILL APPsub-TLVs defined in Sections 4.1.2, 4.1.3, and 4.2 of this document. The following entries have been added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry on the TRILL Parameters IANA web page ✨
Type Name Reference
---- ---- ---------
252 AA-LAALP-GROUP-RBRIDGES RFC 7782
253 AA-LAALP-GROUP-MAC RFC 7782
254 EXTENDED-RBRIDGE-CAP RFC 77828.2. Extended RBridge Capabilities Registry ✨
okay so IANA made a brand new registry inside the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry 🎀 here are the deets:
- Name: Extended RBridge Capabilities
- Registration Procedure: Expert Review
- Reference: RFC 7782
Bit Mnemonic Description Reference
---- -------- ----------- ---------
0 E Option B Support RFC 7782
1 H Option A Support RFC 7782
2-63 - Unassigned8.3. Active-Active Flags 💜
bestie, IANA gave out two flag bits with the mnemonic "AA" 🦋 one comes from the Interested VLANs Flag Bits, and the other comes from the Interested Labels Flag Bits. no cap, they're both super iconic.
One flag bit is allocated from the Interested VLANs Flag Bits.
Bit Mnemonic Description Reference
--- -------- ----------- ---------
16 AA VLANs for Active-Active RFC 7782One flag bit is allocated from the Interested Labels Flag Bits.
Bit Mnemonic Description Reference
--- -------- ----------- ---------
4 AA FGLs for Active-Active RFC 77829. References 📚
9.1. Normative References 🌸
these are the sources you NEED to know to get this whole spec, so bookmark them, bestie 🫶
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area
networks - Link Aggregation", IEEE Std 802.1AX-2014,
DOI 10.1109/IEEESTD.2014.7055197, December 2014.
[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>.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011,
<http://www.rfc-editor.org/info/rfc6165>.
[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>.
[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>.
[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>.
[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>.
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
Stokes, "Transparent Interconnection of Lots of Links
(TRILL): End Station Address Distribution Information
(ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>.9.2. Informative References 🧚
these ones are extra context. nice to have, not a must-read 💅
[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.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
DOI 10.17487/RFC1058, June 1988,
<http://www.rfc-editor.org/info/rfc1058>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304,
October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[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>.
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai,
"Problem Statement and Goals for Active-Active Connection
at the Transparent Interconnection of Lots of Links
(TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379,
October 2014, <http://www.rfc-editor.org/info/rfc7379>.
[RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y.
Li, "Transparent Interconnection of Lots of Links (TRILL):
Pseudo-Nickname for Active-Active Access", RFC 7781,
DOI 10.17487/RFC7781, February 2016,
<http://www.rfc-editor.org/info/rfc7781>.
[TRILL-MT] Eastlake 3rd, D., Zhang, M., Banerjee, A., and V. Manral,
"TRILL: Multi-Topology", Work in Progress,
draft-ietf-trill-multi-topology-00, September 2015.Appendix A. Scenarios for Split Horizon 🦄
picture this: three RBridges (RB1, RB2, RB3) all in one active-active group, hooked up to LAALP1 and LAALP2. LAALP1 and LAALP2 connect to B1 and B2 on their other ends. all three RBridges use port L1 for LAALP1 and port L2 for LAALP2. the L1 ports enable VLANs 10-20 and the L2 ports enable VLANs 15-25, so VLANs 15-20 overlap ✨ here's the layout:
+------------------+ +------------------+ +------------------+
| RB1 | | RB2 | | RB3 |
+------------------+ +------------------+ +------------------+
L1 L2 L3 L1 L2 L3 L1 L2 L3
VL10-20 VL15-25 VL15 VL10-20 VL15-25 VL15 VL10-20 VL15-25 VL15
LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN
B1 B2 B10 B1 B2 B20 B1 B2 B30
Figure 2: An Example Topology to Explain Split Horizonso the customer wants hosts in those overlapping VLANs to be able to talk to each other. hosts on B1 in VLANs 15-20 need to reach hosts on B2 in VLANs 15-20 🫶 and the remote plain RBridge RB4 also has hosts in VLANs 15-20 that need to talk to the ones on B1 and B2.
there are two big requirements here:
- Frames ingressed from RB1-L1-VLANs 15-20 MUST NOT be egressed out of ports RB2-L1 and RB3-L1.
- At the same time, frames coming from B1-VLANs 15-20 should reach B2-VLANs 15-20.
RB3 stores the split horizon info on its L1 and L2 ports, like this:
On L1: {<ingress_nickname_RB1, VLANs 10-20>,
<ingress_nickname_RB2, VLANs 10-20>}.
On L2: {<ingress_nickname_RB1, VLANs 15-25>,
<ingress_nickname_RB2, VLANs 15-25>}.Five clarification scenarios follow, and they're honestly my favourite part 💖
a. okay so say RB2 or RB3 gets a TRILL multi-destination data packet with VLAN 15 and ingress_nickname_RB1. RB3 is the single exit point (picked by the hashing function of LAALP) for this packet. on ports L1 and L2, RB3 has covered <ingress_nickname_RB1, VLAN 15>, so it won't egress this packet out of either L1 or L2. this is "split horizon" happening, periodt 🙈
beforehand, RB1 grabs a native frame on port L1 from B1 in VLAN 15. RB1 figures out that it should be forwarded as a multi-destination packet across the TRILL campus. RB1 also replicates this frame without TRILL encapsulation and sends it out of port L2, so B2 gets the frame too 🌈
b. now say RB2 or RB3 gets a TRILL multi-destination data packet with VLAN 15 and ingress_nickname_RB4. RB3 is the single exit point. on ports L1 and L2, since RB3 hasn't stored any tuple with ingress_nickname_RB4, it decapsulates the packet and egresses it out of both ports L1 and L2. so both B1 and B2 receive the frame 🍓
c. suppose there's a plain LAN link port L3 on RB1, RB2, and RB3, connecting to B10, B20, and B30 respectively. these L3 ports happen to be configured with VLAN 15. on port L3, RB2 and RB3 store no split horizon info for AAE, since this port hasn't been configured to be in any LAALP. they'll egress the packet that was ingressed from RB1-L1 in VLAN 15 💜
d. if a packet is ingressed from RB1-L1 or RB1-L2 with VLAN 15, port RB1-L3 won't egress packets with ingress_nickname_RB1. RB1 needs to replicate this frame without encapsulation and send it out of port L3. this kind of "bounce" behavior for multi-destination frames is just as specified in paragraph 3 of Section 4.6.1.2 of [RFC6325]. ✨
e. last one! if a packet is ingressed from RB1-L3, then since RB1-L1 and RB1-L2 can't egress packets with VLAN 15 and ingress_nickname_RB1, RB1 needs to replicate this frame without encapsulation and send it out of ports L1 and L2. (also see paragraph 3 of Section 4.6.1.2 of [RFC6325].) 🎀
Acknowledgments 🫶
the authors want to give a huge thank you to these legends for their comments and suggestions: Andrew Qu, Donald Eastlake, Erik Nordmark, Fangwei Hu, Liang Xia, Weiguo Hao, Yizhou Li, and Mukhtiar Shaikh. you're all iconic 👑
Authors' Addresses 🧚♀️
meet the authors! 💅
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
Hongjun Zhai
Nanjing Astute Software Technology Co. Ltd
57 Andemen Avenue, Yuhuatai District
Nanjing, Jiangsu 210016
China
Email: honjun.zhai@tom.com
Muhammad Durrani
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134
United States
Email: mdurrani@cisco.com
Sujay Gupta
IP Infusion
RMZ Centennial
Mahadevapura Post
Bangalore 560048
India
Email: sujay.gupta@ipinfusion.com📦 where this page comes from
- ietf: rfc7782 2016-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms