Summary

  • A TRILL RBridge nickname is a dynamic 16-bit abbreviation for an IS-IS identity and can also select a distribution tree; its meaning depends on the claimant, advertisement, packet role and topology scope.
  • Collision rules can force even a configured holder to choose again. A defensible record preserves both claims, priority, LSP provenance, the corrected tie-break, forwarding installation and observed delivery instead of treating the number as an asset ID.

At 09:14, a monitoring system associates nickname 0x2A10 with one chassis. At 09:15, a network boundary changes and a second reachable RBridge advertises the same value. One has the higher nickname priority. The other loses and selects a replacement. For several seconds, different observers may possess different link-state views.

An asset database built around the nickname now reports an impossible event: one device became two, or one box teleported between sites. The protocol has done nothing paradoxical. A compact forwarding reference collided inside a distributed system and was adjudicated. The database supplied the false premise by promoting a temporary binding into identity.

Donald E. Eastlake 3rd appears repeatedly in the standards lineage that makes this distinction inspectable. The five-author base specification, RFC 6325, includes him among its contributors. He then led RFC 7176, which specifies TRILL's IS-IS encodings, and RFC 7780, which corrected and clarified nickname selection. He later co-authored RFC 8397 on unique nicknames in multilevel TRILL. These are collective IETF documents, not personal decrees. The IETF Datatracker profile establishes the person and publication record; it does not make Eastlake the operator of any campus.

The useful human story is not that one engineer named every switch. It is that successive documents narrowed what a short number can prove.

Sixteen bits are an abbreviation

RFC 6325 defines RBridge nicknames as dynamically assigned 16-bit quantities. They abbreviate IS-IS IDs so the TRILL header can remain compact. A nickname is not the underlying System ID; it is a smaller value associated with a claimant through the link-state protocol.

Even the noun “nickname” warns against permanence. One RBridge normally has one, but it can request several. A successfully acquired value should be attempted again after reboot, yet an attempt at reuse is neither a reservation nor proof that the returning process represents the same physical asset. Another reachable claimant may now hold the value with better priority.

The number is also overloaded by packet context. With the M bit clear in known-unicast TRILL Data, the egress nickname identifies the RBridge expected to decapsulate and forward the native frame. With the M bit set for multi-destination traffic, the egress field identifies a selected distribution tree. The same 16 bits can therefore refer to a forwarding endpoint in one packet and a tree choice in another.

An observation that stores only 0x2A10 has thrown away the grammar. It needs the M bit, ingress or egress role, packet class, claimant and observation time before the value can be interpreted.

The advertisement is part of the name

RFC 7176 gives the nickname claim a concrete wire format. Its Nickname Sub-TLV carries repeated records with three separate fields: Nickname.Pri, Tree Root Priority and Nickname. The originating IS and LSP provide the missing subject and provenance.

Those priorities do different work. Nickname priority helps decide which claimant may keep a colliding value. Tree-root priority helps select roots for distribution trees. Collapsing them into one “priority” column makes later reconstruction unreliable.

The high bit of Nickname.Pri records whether the value was configured; the lower seven bits carry the priority. A configured choice beats a non-configured one, but configuration is not ownership. RFC 6325 expressly allows a configured RBridge to lose a collision and select a replacement. A local setting expresses preference inside a protocol contest. It does not reserve the number forever.

The full receipt therefore begins with an advertisement, not an inventory label: originating IS-IS ID, LSP identity and sequence, nickname record, receipt time, database version and reachability state. Without those fields, the system cannot say who made the claim or under which distributed view it was accepted.

The corrected collision rule matters

The original base text contained a faulty sentence in its tie-break description. RFC 7780 preserves the mechanism but corrects that sentence: the numerically higher priority keeps the nickname; if priority is tied, the numerically higher seven-byte IS-IS ID, or LAN ID for a pseudonode, wins. The other RBridge must choose again.

That correction is an operational warning. Copying a rule from a famous base RFC without its later update can cause two implementations, runbooks or forensic tools to name different winners from the same evidence. The RFC number and section version belong in the decision record.

Conflict detection also has a denominator. Claims by IS-IS-unreachable switches must be ignored for adjudication, while claims by IS-IS-reachable switches must not be ignored merely because they are data-unreachable. Control-plane reachability and data-plane reachability are not interchangeable.

Nor does apparent peace end the obligation. RFC 7780 requires a holder to continue monitoring received LSPs for a higher-priority reachable claimant. A later advertisement can reopen the question, even while the local RBridge is overloaded. “Nickname acquired” is a state at a time, not final title.

A campus merge exposes the hidden clock

RFC 6325 anticipates the cleanest counterexample to permanent identity: two RBridge campuses can merge with duplicate nicknames. Once their LSPs cross the former boundary, losers select new values that appear free. Some may have to reselect more than once before the campus becomes collision-free.

Each decision is rational against one link-state database. The views need not update simultaneously. During the transient, a packet capture, an operator console and an asset collector may each be accurate about a different instant and still disagree.

The repair is not to select one screen as reality. Preserve the sequence: pre-merge scope, boundary event, both LSPs, their reachability, priority comparison, winning and losing claim, replacement selection, new advertisements, forwarding update and convergence seen by independent observers.

An RBridge that cannot acquire any valid nickname offers another useful boundary. RFC 7780 says it cannot act as ingress, egress or tree root, yet it can still function as a transit switch. No usable nickname does not mean no device. Conversely, a nickname present in link state does not prove that a packet was installed into the right forwarding path or reached an end station.

“Unique” still has a topology

RFC 8397 extends TRILL across levels using a unique-nickname approach. Nicknames are kept unique across that multilevel campus, and border RBridges propagate individual claims or blocks so other areas can route toward them. The document contrasts this with an aggregated-area approach in which values can be reused across areas and border devices rewrite the relevant fields.

The word “unique” therefore has a declared scope and mechanism. It means non-collision within the chosen campus-wide allocation regime. It does not mean universally assigned, globally registered, legally owned or permanently bound to hardware.

Multilevel advertisements add another subtlety. A border RBridge can announce reachability for nicknames inside or outside its area, and multiple border RBridges can appear to own the same advertised scope for routing purposes. The advertisement may be a projection on behalf of a region of topology. Treating every advertised nickname as a physical asset directly attached to the originator converts reachability into possession.

Build a binding history, not a nickname inventory

The durable record should use the underlying IS-IS identity and a locally governed asset identifier as separate anchors. Around them, store nickname bindings with explicit validity intervals. Each interval should name the campus, level or area; the claimant; configured flag and numeric priority; tree-root priority; source LSP and link-state version; and the event that opened or closed the binding.

Collision records need both sides. Save the claims before normalization, the corrected comparison result, reachability evidence, losing value, replacement value and every intermediate reselection. Reboot records should state whether reuse was attempted and whether it was actually reacquired, rather than stamping “same device” because the number returned.

Finally, join control-plane state to downstream receipts. Did the chosen claim enter the forwarding information base? Was the nickname interpreted as an endpoint or a tree? Did reverse-path checking accept the traffic? Which RBridge decapsulated the frame? Did the intended station observe delivery? A winning nickname claim proves only the protocol contest represented by its evidence.

Sources