Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments
Extracted elements (29)
Option B stores multiple MAC attachments in ESADI link-state databases (software), while the hardware MAC table retains only one entry per MAC address. This design avoids requiring new hardware fast-path support, enabling incremental deployment across existing TRILL infrastructure.
The MAC-Reachability TLVs in the AA-LAALP-GROUP-MAC APPsub-TLV are organized so that each TLV contains MAC addresses from a single LAALP only. This grouping lets remote RBridges correlate MAC addresses with specific LAALP identifiers, which is necessary for correct split-horizon filtering and AAE group identification.
The split horizon filtering list is populated by listening to AA-LAALP-GROUP-RBRIDGES APPsub-TLVs, which identify all other RBridges sharing the same LAALP. The Sender Nickname from each such APPsub-TLV is added to the local port's filtering list, enabling each AAE member to block echoes from peer AAE members without needing out-of-band coordination.
Using each member RBridge's own nickname (rather than a shared pseudo-nickname) as the ingress nickname avoids the MAC flip-flopping problem by requiring remote RBridges to maintain all multiple MAC attachments simultaneously. This approach allows coexistence with other AAE solutions (e.g., RFC 7781) in the same campus.
A remote RBridge supporting Option A (H-bit set) is compatible with an AAE group operating under Option B (E-bit set), so the two options can coexist. This document and RFC 7781 (pseudo-nickname approach) can also be simultaneously deployed for different AAE groups in the same campus.
The Extended TLVs defined in this document are carried in E-L1FS (Extended Level 1 Flooding Scope) PDUs. RBridges that do not support E-L1FS will not receive the EXTENDED-RBRIDGE-CAP APPsub-TLV, and therefore MAC multi-attach active-active is not supported on such RBridges.
An AAE member RBridge MUST use the AA-LAALP-GROUP-MAC APPsub-TLV to advertise in ESADI any MAC addresses learned from plain local (non-LAALP) links whose Data Labels are covered by the Data Labels of any attached LAALP, because remote RBridges will have disabled data-plane learning for those Data Labels.
An RBridge in an AAE group MUST participate in ESADI in Data Labels enabled for its attached LAALPs, advertising those Data Labels as belonging to LAALP (not plain LAN) connections by setting the AA flag bits.
For multicast egress, when the LAALP selection function designates the receiving RBridge as the single exit point for a multi-destination packet in a given Data Label, that RBridge MUST egress the packet; otherwise it MUST NOT egress the packet for that AAE group.
If an AAE group member observes that a remote RBridge is interested in one or more of the AAE group's Data Labels but advertises support for neither Option A nor Option B, the AAE group MUST fall back to active-standby mode.
It is RECOMMENDED that a receiving edge RBridge disable data-plane MAC learning from TRILL Data packet decapsulation within Data Labels advertised by AAE RBridges, unless the receiving RBridge also supports Option A. Alternative implementations that prevent MAC flip-flopping (e.g., confidence-level mechanisms) are acceptable.
The AA-LAALP-GROUP-MAC APPsub-TLV MUST be included in a TRILL GENINFO TLV in the ESADI-LSP. There may be more than one occurrence of such APPsub-TLVs in one ESADI-LSP fragment.
To prevent echo/forwarding loops, AAE member RBridges MUST set up per-port filtering lists of <ingress nickname, VLAN> tuples. Packets matching any entry in the filtering list MUST NOT be egressed out of the corresponding LAALP port (split horizon). All enabled VLANs MUST be consistent on all ports connected to an LAALP.
Whenever MAC addresses from an LAALP are learned through ingress or configuration, the originating AAE member RBridge MUST advertise those MAC addresses using the MAC-Reachability TLV via the ESADI protocol, enclosed in the AA-LAALP-GROUP-MAC APPsub-TLV.
With Option B, receiving edge RBridges MUST avoid flip-flop errors for MAC addresses learned from TRILL Data packet decapsulation for originating RBridges within the advertised Data Labels.
In a TRILL Active-Active Edge (AAE) group, each member RBridge encapsulates frames from attached end systems using its own nickname as the ingress nickname, regardless of whether the frame is unicast or multicast. This causes remote RBridges to observe multiple attachment points (ingress RBridges) for the same host MAC address.
Option A requires new fast-path hardware capable of data-plane learning of multiple attachments for a single end node MAC address. It can only be used safely if all edge RBridges interested in the relevant Data Labels announce the Option A capability; otherwise the AAE group must fall back to active-standby or isolate non-supporting RBridges.
Option B uses the TRILL ESADI protocol to distribute multiple MAC attachments to remote RBridges, disabling data-plane MAC learning for those addresses. It is incrementally deployable on existing TRILL hardware without fast-path changes.
Remote RBridges that learn MAC addresses from the AA-LAALP-GROUP-MAC APPsub-TLV via ESADI SHOULD treat those MAC addresses as if the corresponding end nodes are locally attached, enabling intra-AAE group MAC learning and proper forwarding decisions.
To handle black-hole and triangular forwarding on sub-link failure, the AAE member RBridge attached to the failed sub-link uses the ESADI protocol to flush affected MAC addresses (per RFC 7357 Section 5.2), causing remote RBridges to stop forwarding to the failed port without requiring intra-AAE traffic redirection.
When a remote RBridge has learned multiple AAE attachments for a MAC address and there are multiple equal least-cost member RBridges, the ingress RBridge MUST select one using a pseudorandom method (as specified in RFC 7357 Section 5.3) to achieve load balancing toward the AAE.
IANA allocated three TRILL APPsub-TLV types under IS-IS TLV 251 Application Identifier 1: type 252 (AA-LAALP-GROUP-RBRIDGES), type 253 (AA-LAALP-GROUP-MAC), and type 254 (EXTENDED-RBRIDGE-CAP), all referencing RFC 7782.
IANA allocated two Active-Active (AA) flag bits: Bit 16 from the Interested VLANs Flag Bits (VLANs for Active-Active) and Bit 4 from the Interested Labels Flag Bits (FGLs for Active-Active), both in RFC 7176 sub-TLVs and referencing RFC 7782.
IANA created the 'Extended RBridge Capabilities' registry under TRILL Parameters with Expert Review procedure. Initial entries: Bit 0 (E) = Option B Support, Bit 1 (H) = Option A Support, Bits 2–63 Unassigned.
Because currently deployed LAALPs are proprietary, security over AAE group membership and internal management is proprietary. In environments without IS-IS authentication (RFC 5304/RFC 5310), a rogue RBridge that joins an AAE group can control approximately 1/N of outgoing traffic and a similar share of incoming unicast traffic, disrupting end-station service.
For extensions transported by TRILL ESADI, security follows RFC 7357. For extensions not transported by ESADI, RBridges MAY be configured to include IS-IS Authentication TLV (10) in IS-IS PDUs to authenticate using IS-IS security mechanisms (RFC 5304, RFC 5310).
The AA-LAALP-GROUP-MAC APPsub-TLV (type 253) encodes: 2-byte Type, 2-byte Length (= k+8+6*n), 1-byte LAALP ID Size (k), k-byte LAALP ID, and a MAC-Reachability sub-TLV (7+6*n bytes, where n is the number of MAC addresses). Type and Length of the inner TLV are unsigned 16-bit integers per RFC 7356.
The AA-LAALP-GROUP-RBRIDGES APPsub-TLV (type 252) encodes: 2-byte Type, 2-byte Length (= 3+k), 2-byte Sender Nickname (the ingress nickname), 1-byte LAALP ID Size (k), and k-byte LAALP ID. For MC-LAG or DRNI, the LAALP ID is the 8-byte ID from IEEE 802.1AX Clause 6.3.2.
The EXTENDED-RBRIDGE-CAP APPsub-TLV (type 254) has Length=10 and contains a 2-byte Topology field followed by 8 bytes of capability flags. Bit 0 (E) signals Option B support; Bit 1 (H) signals Option A support; bits 2–63 are Reserved and MUST be sent as zero and ignored on receipt.