Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)
Extracted elements (24)
A border RBridge connecting multiple L1 areas SHOULD use a single area nickname for all those areas to minimize nickname consumption and reduce the number of nicknames advertised in L2. However, it may need to hold multiple nicknames if it is the root of multiple L1 or L2 distribution trees.
In this single-nickname approach, each area border RBridge uses its own nickname in both L1 and L2 — no separate nicknames are assigned to represent L1 areas. An L1 area is instead identified by the set of all border RBridge nicknames attached to it, which scales better than unique-nickname solutions while remaining simpler than full aggregated-nickname approaches.
An RBridge supporting single nickname MUST be able to simultaneously support single nickname for some of its L1 areas and unique nickname for others, since overlapping sets of RBridges can serve as border RBridges for different L1 areas with different capability mixes.
RBridges that do not support E-L1FS or E-L2FS cannot serve as area border RBridges but may appear within an L1 area as non-area-border RBridges. The extended TLVs defined in Section 5 must be used only in E-L1FS/E-L2FS PDUs.
A border RBridge receiving a multi-destination packet whose ingress nickname is a border RBridge nickname of its own area MUST NOT transition that packet back into its own area, preventing forwarding loops.
All area border RBridges for an L1 area MUST agree on the same pseudorandom algorithm for ingress nickname selection. The destination MAC address SHOULD be excluded from algorithm input to prevent source MAC flip-flopping at the egress RBridge.
All Level 2 RBridges MUST support E-L2FS (RFC 7356, RFC 7780). Area border RBridges MUST support both E-L1FS and E-L2FS. RBridges supporting only single-level TRILL (RFC 6325) do not support L2 adjacencies.
For an unknown-unicast multi-destination packet, if the DBRB has learned the destination MAC address, it SHOULD convert the packet to unicast (setting M bit to 0) before forwarding into the next level.
For multi-destination packets, non-DBRB border RBridges MUST drop received copies. All border RBridges of an area MUST agree on the mechanism used to determine the DBRB.
Nicknames in the L2 area MUST be unique, but nicknames inside an L1 area can be reused in other L1 areas that also use the single-nickname approach.
RBridges supporting and configured for single-nickname multilevel MUST also support unique-nickname multilevel (RFC 8397). If any border RBridge for an L1 area supports only unique-nickname multilevel, all single-nickname-configured border RBridges for that area MUST fall back to unique-nickname behavior. Operators SHOULD be notified when this fallback occurs.
The L1-BORDER-RB-GROUP TLV generated by an area border RBridge MUST include all L1 Border RBridge Nicknames of the area. It is RECOMMENDED that the k nicknames be ordered in ascending order as unsigned integers.
When an area border RBridge (RB2) learns a source MAC-to-nickname binding during L1-to-L2 transition, it SHOULD synchronize this attachment information with peer border RBridges in the same area using the ESADI protocol (RFC 7357).
When border RBridges detect a change in the set of border RBridge nicknames for a splitting or merging area, they MUST flush the reachability information associated with any RBridge nickname from that changing set.
For multi-destination packets, only one border RBridge per area acts as the Designated Border RBridge (DBRB) to perform the level transition; by default, the border RBridge with the smallest nickname (treated as an unsigned integer) is elected DBRB.
L1-to-L2 egress nickname replacement: a border RBridge MAY replace the egress nickname with any area nickname of the egress area, defaulting to the least-cost-route border RBridge or using the pseudorandom algorithm among equal-cost alternatives for load spreading.
L2-to-L1 ingress nickname replacement: when a TRILL Data packet from another L1 area arrives, the border RBridge MAY select one area nickname of the ingress area using a pseudorandom algorithm (per RFC 7357 Section 5.3) to enable per-flow load balancing of return unicast traffic.
When a border RBridge is DBRB for multiple connected areas and receives a packet that was originally flooded on the L2 tree (i.e., a replication originated from one of its own areas), the replication arriving from L2 MUST be dropped, identified by the ingress nickname matching a border RBridge nickname of a connected L1 area.
When a TRILL Data packet transitions from L1 to L2, the area border RBridge replaces the ingress TRILL switch nickname with its own nickname. When transitioning from L2 to L1, the egress nickname is replaced with the actual destination RBridge's nickname based on a MAC lookup.
IANA allocated two new APPsub-TLV types under 'TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1': type 256 (L1-BORDER-RBRIDGE) and type 257 (L1-BORDER-RB-GROUP), both allocated from the Standards Action range.
The newly defined TRILL APPsub-TLVs are transported in IS-IS PDUs. RBridges SHOULD be configured to use the IS-IS Authentication TLV (10) so that IS-IS security (RFC 5310) can authenticate PDUs and discard forged ones. Malicious devices may fake APPsub-TLVs to attract TRILL Data packets, interfere with multilevel operation, or induce excessive state.
The possible duplication of nicknames between areas increases the risk of a TRILL Data packet being delivered to the wrong egress RBridge if areas are unexpectedly merged. In most cases such misdelivered data would be discarded at the egress as it would not match a known end-station Data Label/MAC address.
L1-BORDER-RB-GROUP APPsub-TLV (type 257): Type 2 bytes, Length 2 bytes (= 2*k), followed by k L1 Border RBridge Nicknames each 2 bytes. Carried in E-L2FS FS-LSP fragment zero. If Length is not a multiple of 2, the APPsub-TLV is corrupt and MUST be ignored.
L1-BORDER-RBRIDGE APPsub-TLV (type 256): Type field 2 bytes, Length field 2 bytes (fixed value 2), Sender Nickname 2 bytes indicating which nickname the originating IS uses as its L1 Border RBridge Nickname. Carried in E-L1FS FS-LSP fragment zero as an APPsub-TLV of the TRILL GENINFO-TLV.