Transparent Interconnection of Lots of Links (TRILL): Adjacency
obsoletes
- rfc-6327 — Routing Bridges (RBridges): Adjacency
updated by
- rfc-7780 — Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
- rfc-8139 — Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders
- rfc-8249 — Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation
- rfc-8377 — Transparent Interconnection of Lots of Links (TRILL): Multi-Topology
- rfc-8564 — Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL)
updates
- rfc-6325 — Routing Bridges (RBridges): Base Protocol Specification
Extracted elements (28)
RBridges do not implement the IS-IS externalDomain flag (or fix it to 'false') because unlike Layer 3 routers that may connect to separate routing domains, all neighbor RBridges merge into a single TRILL campus. For loop safety, TRILL Hellos must be sent and received on every non-disabled port.
TRILL cannot tolerate the Layer 3 IS-IS behavior of allowing multiple Designated Routers on a LAN. In TRILL, multiple DRBs would cause multiple RBridges to ingress and egress the same native frame simultaneously, creating forwarding loops that the TRILL hop count cannot protect against — particularly catastrophic for multi-destination frames, which could multiply on each loop iteration.
TRILL Hellos are limited to 1,470 bytes and are not padded to the link MTU (unlike Layer 3 IS-IS which pads Hellos for MTU discovery) because TRILL must assure correct adjacency and DRB election even on links that accommodate only classic Ethernet frame size. MTU discovery is handled separately via explicit MTU-probe/MTU-ack PDUs.
TRILL uses a TRILL Neighbor TLV that covers a range of MAC addresses rather than listing every neighbor individually, because on large backbone technologies (e.g., a giant Ethernet interconnecting hundreds of TRILL sites) hundreds of RBridges may appear as neighbors on a single link, making individual per-neighbor listings per Hello impractical.
A LAN Hello received on a port configured as point-to-point, or a P2P Hello received on a port not configured as point-to-point, is discarded. Hello type (LAN vs P2P) must match port configuration for a TRILL adjacency to be established.
Multiple parallel point-to-point or non-pseudonode LAN adjacencies between the same two RBridges appear as a single adjacency in LSPs. Their cost MAY be adjusted downward to reflect parallel paths; unicast TRILL Data traffic may freely multipath across them on a per-flow basis, but multi-destination traffic is restricted as specified in RFC 6325.
When the Designated VLAN on an Ethernet link changes, an RBridge must preserve connectivity by setting the non-Designated VLAN Hello holding timer to the maximum of its remaining time and the Designated VLAN timer's remaining time, then expiring the Designated VLAN timer and triggering an A5 event for each affected adjacency.
A DRB SHOULD set the bypass pseudonode bit in its TRILL LAN Hellos if it has not seen at least two simultaneous adjacencies in the Report state since it last rebooted or was reset by network management, thereby avoiding unnecessary pseudonode LSPs on effectively point-to-point links.
A received TRILL Hello MUST be discarded if: its Circuit Type is not 1; it lacks an Area Address TLV with only Area Address zero; a Protocols Supported TLV is present but does not list TRILL NLPID (0xC0); it lacks an MT Port Capabilities TLV with a VLAN-FLAGS sub-TLV; its maximumAreaAddresses field is not 1; or IS-IS authentication is in use and the PDU fails authentication.
Although MTU testing is optional, it is mandatory for an RBridge to respond to an MTU-probe PDU with an MTU-ack PDU. An adjacency that fails the MTU test at the campus MTU will not enter or will leave the Report state, preventing that adjacency from being included in least-cost route computation.
In cases where a transient nickname conflict prevents using the Any-RBridge egress nickname for a BFD session destination, initiation of the BFD session SHOULD be delayed until the nickname conflict is resolved.
In TRILL, originatingL1LSPBufferSize is limited to the range 1,470 to 65,535 bytes inclusive (unlike Layer 3 IS-IS which limits it to 512–1,492 bytes). An RBridge determines the desired campus link MTU as the minimum of its own and all other RBridges' advertised values, but not less than 1,470 bytes.
RB1's TRILL Neighbor TLV(s) MUST eventually cover every possible range of SNPA addresses so that any RBridge RB2 can definitively determine whether RB1 can hear RB2; there must be no gap in covered address ranges across all neighbor list fragments sent by RB1.
The following items MUST be the same for all TRILL Hellos issued by an RBridge on a particular Ethernet port, regardless of the VLAN in which the Hello is sent: Source MAC address, priority to be the DRB, Desired Designated VLAN, Port ID, and (if included) BFD-Enabled TLV and PORT-TRILL-VER sub-TLV.
TRILL Hello PDU headers MUST conform to Maximum Area Addresses equal to 1 and Circuit Type equal to 1. Padding TLVs SHOULD NOT be included in TRILL Hellos.
TRILL Hello PDUs MUST NOT be sent if they exceed 1,470 bytes. They SHOULD NOT be padded. A received TRILL Hello longer than 1,470 bytes is processed normally.
TRILL Neighbor TLVs sent in a LAN Hello on an Ethernet link MUST show neighbor information as sensed by the transmitting RBridge for the VLAN on which the Hello is sent; conformant implementations maintain this information only for the Designated VLAN, so they send TRILL Neighbor TLVs only in Hellos sent on the Designated VLAN.
When a BFD session is initiated while the adjacency is in the 2-Way state, the adjacency MUST NOT advance to the Report state until BFD and all other enabled connectivity tests have succeeded. If BFD is enabled while the adjacency is already in the Report state, the adjacency MUST remain in Report until BFD or another enabled test fails, to minimize unnecessary topology changes.
Each adjacency table entry (for adjacencies in Detect, 2-Way, or Report state) records: neighbor MAC/SNPA address, Port ID, and System ID; one Hello holding timer for P2P or two (Designated VLAN and non-Designated VLAN, each a 16-bit unsigned integer of seconds) for LAN; 7-bit DRB priority (LAN only); 5 bytes of PORT-TRILL-VER sub-TLV data; Desired Designated VLAN; and (if BFD is supported) a flag indicating whether the last received Hello included a BFD-Enabled TLV.
Each RBridge broadcast LAN port state record includes: enablement bit, 5-byte PORT-TRILL-VER sub-TLV data, SNPA address, Port ID, Holding Time, DRB priority, BFD support and BFD-Enabled flag, DRB state, a 16-bit unsigned Suspension Timer (seconds), Desired Designated VLAN, and a per-port adjacency table.
The DRB is elected among all RBridge ports on a broadcast link using the 7-bit priority field from each RBridge's Hellos, with MAC (SNPA) address as the primary tiebreaker, Port ID as the secondary tiebreaker, and System ID as the tertiary tiebreaker; all fields are compared as unsigned integers, with a larger value meaning higher priority.
TRILL LAN Hellos require: Area Addresses TLV (Area Address zero only), MT Port Capabilities TLV with VLAN-FLAGs sub-TLV, and zero or more TRILL Neighbor TLVs. TRILL P2P Hellos require a Three-Way Handshake TLV instead. BFD-Enabled TLV, Authentication TLV, and Protocols Supported TLV are optional in both types. Padding TLV SHOULD NOT be included. Any TLV permitted in a Layer 3 IS-IS Hello MAY also appear.
This document serves as the normative reference for the 'Fail' (Failed MTU test) value 0 in the IANA 'TRILL Neighbor TLV NEIGHBOR RECORD Flags' registry; IANA updated that reference to point to this RFC.
This document does not alter the security considerations of the TRILL base protocol (RFC 6325, Section 6). IS-IS authentication via the Authentication TLV may be used on TRILL links; a Hello that fails authentication validation is discarded. BFD security considerations are addressed in RFC 7175.
Adjacency state transitions are driven by events A1–A8: A1 (Hello confirming 2-way) advances toward 2-Way; A2 (Hello received but 2-way not confirmed) sets Detect; A3 (Hello explicitly covering receiver's address range but not listing receiver) regresses to Detect; A4 (all Hello hold timers expired) transitions to Down; A5 (Designated VLAN timer expired, non-DV timer still running) regresses to Detect; A6 (all enabled connectivity tests succeed) advances to Report; A7 (a previously passing enabled test fails) regresses to 2-Way; A8 (port operationally down) transitions to Down. The special A0 event (self-sourced Hello with higher DRB priority) discards all adjacencies on the port.
Each RBridge broadcast LAN port has a DRB election state machine with four states: Down (operationally down, no traffic), Suspended (a higher-priority port with the same MAC address exists; port only monitors Hellos to update its Suspension Timer), DRB (this port won the election and controls Designated VLAN and Appointed Forwarder decisions), and Not DRB (deferring to another port). Events D1–D5 drive transitions; D4 (receiving a Hello with the same MAC and higher DRB priority) forces the port into Suspended and discards all adjacencies.
TRILL adjacency has four states: Down (nonexistent, no table entry), Detect (neighbor seen but 2-way connectivity not confirmed or detected outside Designated VLAN), 2-Way (bidirectional confirmed on Designated VLAN but enabled tests not yet passed), and Report (all enabled tests including optional MTU and/or BFD passed; adjacency is advertised in LSPs). An RBridge participates in LSP synchronization on a port whenever it has at least one adjacency in the 2-Way or Report state.
The BFD-Enabled TLV (Type=148) in a TRILL Hello encodes topology/NLPID pairs: 1-byte Type (148), 1-byte Length (3*n), then n pairs each of a 2-byte field (4-bit RESV + 12-bit MT ID, default 0) and a 1-byte NLPID (0xC0 for TRILL).