Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic
updates
- rfc-6325 — Routing Bridges (RBridges): Base Protocol Specification
Extracted elements (21)
BUM traffic in the centralized replication solution is initially ingressed as a unicast TRILL data packet (not a multi-destination packet as required by RFC 6325), representing a deliberate update to RFC 6325 behavior. This allows all edge RBridges to direct BUM traffic to the centralized node without triggering the distributed RPF check against the actual ingress RBridge.
The ingress nickname in the multi-destination TRILL header forwarded by the centralized node is kept identical to the one in the received unicast packet (the pseudo-nickname). This ensures that MAC address learning by all egress RBridges is bound to the pseudo-nickname, preserving the MAC flip-flop avoidance property of RFC 7781.
When a pseudo-nickname is used as the ingress nickname for BUM traffic, RBridges between the ingress RBridge and the distribution tree root may receive traffic from different ports for the same virtual RBridge, causing RPF check failures and incorrect packet drops. Centralized replication resolves this by sending all BUM traffic to a single centralized node via unicast TRILL encapsulation, then having that node distribute it on a tree for which it is root.
Centralized nodes and active-active edge RBridges typically require hardware and software upgrades, while transit nodes between the ingress RBridge and centralized node typically need only a software upgrade to support the modified RPF port calculation algorithm.
If a unicast TRILL packet is sent to an R-nickname that is not a tree root, the packet either will not be forwarded at all or, if re-encapsulated and forwarded, will be subject to incorrect pruning and will not reach all intended recipients.
The centralized replication solution and the CMT solution (RFC 7783) can coexist in a single TRILL campus, with each active-active edge group independently choosing which mechanism to use. The C-nickname flag distinguishes the two solutions for transit RBridges.
An edge group using CMT (RFC 7783) MUST NOT set the C flag on its pseudo-nickname. A pseudo-nickname MUST NOT be shared between a centralized replication edge group and a CMT-based edge group, as incorrect early pruning would prevent BUM traffic from reaching intended recipients.
Edge group RBridges using centralized replication MUST announce the local pseudo-nickname using the Nickname Flags APPsub-TLV with the C flag set.
If an APPsub-TLV is advertised by an RBridge that does not hold the nickname appearing in that TLV, the R and C flag bits MUST be treated as zero.
In the case of inconsistent Nickname Flags APPsub-TLVs for the same nickname (e.g., due to transient LSP inconsistency during convergence), it is RECOMMENDED that the nickname be treated as if the R/C flag were set if any APPsub-TLV for that nickname has the flag set.
RPF checks on each RBridge MUST be calculated as if the centralized node were the ingress RBridge for trees rooted at that node, rather than using the actual ingress virtual RBridge. This allows traffic to arrive correctly on the centralized-node-facing port.
The centralized replication node MUST be a distribution tree root. An R-nickname advertised by an RBridge that is not a distribution tree root MUST NOT be treated as an R-nickname but rather as an ordinary nickname.
The centralized replication node MUST use a distribution tree whose root is the centralized RBridge itself when forwarding replicated BUM traffic. It forwards the packet as if locally ingressed, but preserves the original ingress nickname (pseudo-nickname) to ensure MAC address learning on egress RBridges is bound to the pseudo-nickname.
BUM traffic load-balancing across multiple centralized nodes uses a VLAN-based (or FGL-based) algorithm: all R-nicknames are ordered numerically 0 to k-1; for data label ID m, the egress R-nickname index is (m mod k). A node holding more R-nicknames receives a proportionally larger share of BUM traffic.
Local forwarding behavior A applies when the ingress RBridge is not the centralized node: (1) replicate to active-active group ports with the same pseudo-nickname as the incoming port; (2) do not replicate to active-active group ports with other pseudo-nicknames; (3) do not replicate to non-edge-group ports.
Local forwarding behavior B applies when the ingress RBridge is itself the centralized replication node (BUM traffic won't loop back): replicate to ports with the same pseudo-nickname, replicate to group DF ports with different pseudo-nicknames (not non-DF ports), and replicate to non-edge-group ports.
The C-nickname is a pseudo-nickname with the C flag set in the Nickname Flags APPsub-TLV, assigned to an edge group using centralized replication. Transit RBridges receiving TRILL data packets with a C-nickname as the ingress nickname apply the centralized replication-specific RPF check algorithm instead of the standard one.
The R-nickname is a special nickname held by a centralized replication node used as the egress nickname in the unicast TRILL header for BUM traffic. It differentiates centralized replication unicast TRILL encapsulation from normal unicast TRILL encapsulation. A centralized node may hold multiple R-nicknames to support load-balancing.
IANA assigned two new bits in the NickFlags Bits subregistry of the TRILL Parameters registry: bit 2 (mnemonic R) for Replication Nickname and bit 3 (mnemonic C) for Special RPF Check, both referencing RFC 8361.
A rogue RBridge that is a distribution tree root can attract BUM traffic by advertising an R-nickname, but this does not substantially increase risk beyond existing threats such as advertising low-cost adjacencies or claiming highest-priority tree root status. Protection against untrusted RBridges is provided by IS-IS authentication (RFC 5310) and administrative controls on authentication key distribution.
The NICKFLAG RECORD in the Nickname Flags APPsub-TLV is a 32-bit structure: bits 0-15 carry the Nickname, bit 16 is IN, bit 17 is SE, bit 18 is R (Replication Nickname), bit 19 is C (Special RPF Check), and bits 20-31 are RESV.