Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames
Extracted elements (29)
The NickBlockFlags APPsub-TLV was introduced because using the individual Nickname Sub-TLV (RFC 7176) to announce a mass of internal/external nicknames is uneconomic. The block-range format allows border RBridges to efficiently advertise large contiguous nickname ranges.
The unique nickname approach assigns globally unique nicknames to all TRILL switches across the multilevel campus, so border RBridges do not rewrite nickname fields when packets transition between Level 1 and Level 2, unlike the aggregated nickname approach. This simplifies border RBridge logic and testing/maintenance operations that cross areas, but at the cost of scalability for very large campuses.
In mixed deployments combining unique nickname areas and aggregated nickname areas, global distribution trees span unique nickname areas and Level 2 but never reach the inside of aggregated areas; each border RBridge of an aggregated area appears as a single node on the global tree.
The Nickname Sub-TLV (RFC 7176 Section 2.3.2) is still allowed to be used alongside the NickBlockFlags APPsub-TLV. Border RBridges must fall back to individual Nickname Sub-TLV announcements for areas that contain legacy RBridges not understanding the NickBlockFlags APPsub-TLV.
A border RBridge MUST announce in its Level 1 area the ownership of all external nicknames reachable from that border RBridge (nicknames in other unique nickname areas and Level 2). It MUST also announce in Level 2 the ownership of all nicknames within its own area.
A multi-destination packet with an egress nickname of the root RBridge of a local tree MUST NOT be leaked into Level 2 at the border RBridge, ensuring local distribution trees remain area-confined.
All border RBridges MUST understand the NickBlockFlags APPsub-TLV. If an RBridge within an area understands it, it MUST indicate this capability by announcing it in its TRILL-VER Sub-TLV.
Blocks of 64 nicknames aligned on boundaries of multiples of 64 are RECOMMENDED for the nickname blocks that border RBridges contend for in Level 2 on behalf of their Level 1 area.
Border RBridges of aggregated areas MUST announce nicknames heard from Level 2 into their area just like a unique nickname border RBridge, but they do not announce nicknames of their area into Level 2.
Border RBridges SHOULD use the NickBlockFlags APPsub-TLV to advertise into the Level 1 area the inclusive range of nicknames that are or are not available for self-allocation. The traditional Nickname Sub-TLV remains allowed alongside it.
Global trees MUST be pruned at border TRILL switches based on Data Labels when legacy TRILL switches use global trees to flood multi-destination packets with a scope of only the local area.
If a border RBridge has been assigned as both a global tree root and a local tree root, it MUST acquire both global tree root nickname(s) and local tree root nickname(s).
If there are legacy TRILL switches that do not understand the APPsub-TLVs for tree selection, configuration MUST guarantee that Data Labels being used globally in Level 2 are disabled on these legacy TRILL switches.
If there are RBridges in an area that do not understand the NickBlockFlags APPsub-TLV, border RBridges of the area MUST also use the traditional Nickname Sub-TLV (RFC 7176) to announce those nicknames covered by NickBlockFlags blocks with OK=0.
The border RBridge with the highest tree root priority MUST advertise both the set of global distribution tree root nicknames and a separate set of local distribution tree root nicknames. Since global and local tree root nicknames indicate different flooding scopes, these two sets MUST NOT overlap.
The RESV field in the NickBlockFlags APPsub-TLV MUST be sent as zero and ignored on receipt.
TRILL Data packets with egress nicknames that are neither in the announced unavailable ranges nor announced by any RBridge in the area MUST be discarded.
Usage of nickname space MUST be planned so that nicknames used in any one unique nickname area and Level 2 are never used in any other areas, including both unique nickname areas and aggregated nickname areas; nickname reuse is only allowed among aggregated nickname areas.
A minimum acceptable link size Sz2 for Level 2 is calculated by Level 2 RBridges using the originatingLSPBufferSize distributed in Level 2 LSPs, analogous to how the area-local Sz is computed in Level 1.
Border RBridges establish Level 1 adjacency with Level 1 RBridges per RFC 7177 and RFC 6325, and Level 2 adjacency using Level 2 Hello PDUs (LAN) or configured level flags (point-to-point). Level 1 and Level 2 adjacency state machines are independent.
Each RBridge in a unique nickname area calculates two types of distribution trees: local distribution trees (for area-confined multi-destination traffic) and global distribution trees (for multi-destination traffic spanning areas). The tree scope is determined by the tree root nickname being a Level 1 or Level 2 nickname.
Level 2 RBridges use the nickname range 0xF000 through 0xFFBF. The highest-priority border router for a Level 1 area contends in Level 2 for blocks of nicknames in the range 0x0001 to 0xEFFF, with blocks of 64 aligned on multiples of 64 being recommended.
The NickBlockFlags APPsub-TLV (Type 24) is used by border RBridges to advertise inclusive ranges of nicknames that are or are not available for self-allocation by Level 1 RBridges. It contains an OK flag bit, a RESV field, and one or more Nickname Blocks each specifying a starting and ending nickname.
IANA assigned Type 24 (named 'NickBlockFlags') in the 'TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1' registry for the NickBlockFlags APPsub-TLV defined in RFC 8397.
IANA registered a new flag bit (Bit 5) in the 'TRILL-VER Sub-TLV Capability Flags' registry indicating the ability to handle the NickBlockFlags APPsub-TLV, as defined in RFC 8397.
Because unique nickname areas share a common nickname space, border RBridges must leak nickname information between levels, meaning nickname-related events or attacks in one area can affect other areas—unlike pure IS-IS multilevel where link-state flooding is automatically confined.
If border RBridges do not prune multi-destination distribution tree traffic in Data Labels configured as area-local, traffic that should be contained within an area may be delivered to end stations in other areas, violating security constraints that restrict Data Label traffic to a single area.
Malicious devices may forge NickBlockFlags APPsub-TLVs to announce large nickname ranges, thereby attracting TRILL data packets destined for other RBridges. RBridges SHOULD be configured to use IS-IS Authentication TLV (10) in IS-IS PDUs containing the NickBlockFlags APPsub-TLV so that forged PDUs can be detected and discarded per RFC 5310.
The NickBlockFlags APPsub-TLV has a 16-bit Type field (value 24), a 16-bit Length field (value 2 + 4*K where K is the number of nickname blocks), a 1-bit OK flag, 15 reserved bits (RESV), followed by K Nickname Blocks each consisting of a 16-bit starting nickname and a 16-bit ending nickname.