Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
obsoleted by
- rfc-7780 — Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
updates
Extracted elements (30)
The distribution tree parent numbering was changed from 'j mod p' to '(j-1) mod p' to reduce distribution tree changes resulting from topology changes. This non-backward-compatible change was deliberately adopted despite the compatibility cost.
TRILL's originatingL1LSPBufferSize defaults to 1470 bytes (not IS-IS's 1492) to provide a 27-byte safety margin accommodating legacy devices with the classic Ethernet maximum MTU despite headers such as an Outer.VLAN tag.
RFC 6325 Section 3.7.3 nickname conflict resolution incorrectly references 'IS-IS ID (LAN ID)' for priority comparison; the corrected text specifies that the RBridge with numerically higher priority keeps the nickname, or on a tie, the one with the numerically higher seven-byte IS-IS ID (LAN ID) keeps it (Errata ID 3002).
RFC 6325 Section 4.3.2 incorrectly states that multi-destination MTU-probe and MTU-ack TRILL IS-IS PDUs are sent to the All-RBridges multicast address. As TRILL IS-IS PDUs, they MUST be sent to the All-IS-IS-RBridges multicast address (Errata ID 3004).
RFC 6325 Section 4.3.2 MTU test thresholds used '>' instead of '>=': the failed minimum MTU test flag is set when X is not >= Sz, and the largest tested X is advertised when X >= Sz (previously X > Sz) (Errata ID 3053).
RFC 6325 Section 4.5.1 incorrectly states that distribution tree cost paths are calculated 'from N to R'; this should read 'from R to N'. All RBridges must use cost in the direction from the root toward each node to ensure consistent tree calculation (Errata ID 3508).
RFC 6325 Section 4.6 erroneously does not allow MTU-probe and MTU-ack PDUs to be unicast. The corrected text requires RBridges to accept these PDUs when the Outer.MacDA is either All-IS-IS-RBridges or the unicast MAC address of the receiving RBridge port (Errata ID 3003).
TRILL campuses with a mixture of IEEE 802.1Q-2011-compliant ports and pre-802.1Q-2011 ports, especially with actual Token Ring links, may operate incorrectly and corrupt data due to different interpretations of the CFI/DEI bit — just as a bridged LAN with such mixed ports would.
All TRILL LAN Hellos issued by an RBridge on a particular port MUST have the same PORT-TRILL-VER sub-TLV (if included) in addition to the same source MAC address, priority, desired Designated VLAN, and Port ID, regardless of the VLAN in which the Hello is sent.
An overloaded RBridge can only appear as a leaf node in a TRILL multi-destination distribution tree; it MUST NOT forward multi-destination TRILL Data frames (except as an egressed native frame where it is Appointed Forwarder). If all immediate neighbors of an RBridge are overloaded, it is omitted from all trees.
An overloaded RBridge RB2 that receives a unicast TRILL Data frame for which it is not the egress MUST NOT discard the frame solely because the egress nickname is unknown (overload may cause incomplete nickname tables). If any non-overloaded neighbor exists (other than the source), RB2 MUST attempt to forward to one of those neighbors.
An overloaded RBridge receiving a multi-destination TRILL Data frame MUST NOT apply the RPFC (Reverse-Path Forwarding Check), since due to overload it might not perform it correctly. It MUST NOT forward such frames except as egressed native frames where it is Appointed Forwarder.
An RBridge MUST continue monitoring for nickname conflicts even after acquiring a nickname with no apparent conflicting claimant, by checking received LSPs for any of its nicknames held with higher priority by an IS-IS reachable TRILL Switch. If found, it MUST select a new nickname, even when in overloaded state.
Distribution tree parent selection is changed from 'j mod p' to '(j-1) mod p' when building tree number j for a node with p possible parents. This change is not backward compatible with RFC 6325; if RBridges disagree, the RPFC will drop most multi-destination frames.
For TRILL Switches with ports conforming to IEEE 802.1Q-2011, the DEI bit in the Inner.VLAN MUST be set to the DEI value provided by the EISS interface on ingressing a native frame, and MUST be provided to the EISS when transiting or egressing a TRILL Data frame. The DEI bit for a transit frame MUST be taken from the Inner.VLAN.
RBridges on Ethernet links MUST limit most TRILL IS-IS PDUs so that the PDU length does not exceed Sz (the campus-wide minimum originatingL1LSPBufferSize). TRILL Hello PDUs MUST NOT exceed 1470 bytes. Sz does not limit TRILL Data frames.
The DRB SHOULD NOT appoint an overloaded RBridge as an Appointed Forwarder unless there is no alternative. If an Appointed Forwarder becomes overloaded, the DRB SHOULD reassign its VLANs to a non-overloaded RBridge on the link if one is available. DRB election is not affected by overload.
TRILL Switches SHOULD support the IS-IS graceful restart features specified in RFC 5306, allowing a restarting IS-IS router to signal neighbors and reestablish adjacencies without cycling through the down state while correctly initiating link-state database synchronization.
When an overloaded RBridge RB2 needs to originate a multi-destination frame and has a neighbor offering OOMF service, the frame MUST NOT be locally distributed in native form at RB2 before tunneling, to prevent duplicate delivery. If no OOMF neighbor exists, RB2 MUST locally distribute the frame where it is Appointed Forwarder for the frame's VLAN.
When determining distribution tree roots, an RBridge MUST ignore all nicknames held by TRILL Switches that are in overload or are data unreachable. This prevents overloaded nodes from being selected as tree roots.
When examining the link-state database for nickname conflicts, nicknames held by IS-IS unreachable TRILL Switches MUST be ignored, but nicknames held by IS-IS reachable TRILL Switches MUST NOT be ignored even if they are data unreachable.
When using the optional TRILL Hello reduction mechanism, an RBridge MUST always attempt to send Hellos in the Designated VLAN. It may be unsafe to send Hellos on fewer VLANs unless all adjacencies on the link support the Hello reduction capability mechanisms.
An RBridge signals willingness to offer OOMF service by setting a bit (Bit 1 of the RESV field) associated with a neighbor's SNPA in the TRILL Neighbor TLV within its TRILL Hellos. An overloaded RBridge RB2 MUST advertise in its LSP the distribution trees used by any neighbor providing it OOMF service, so that RPFC works campus-wide.
OOMF (Overload Originated Multi-destination Frame) service: an overloaded RBridge RB2 encapsulates multi-destination frames as TRILL Data unicast to a neighbor RB3 with M bit=0, Hop Count=2, ingress nickname=RB2's nickname, and egress nickname=0xFFC1 (special OOMF indicator). RB3 then substitutes a real distribution tree root, sets M=1, updates Hop Count, and forwards normally.
The TRILL port mode bits (Disable, P2P, Access/trunk, Trunk) define which frame types are permitted: Layer 2 control, native ingress/egress, LSP/SNP/MTU, TRILL Hello, and P2P Hello. The Disable bit disables all frames except optionally low-level Layer 2 control frames.
Two mechanisms extend RFC 6439 VLAN inhibition timer setting for Hello reduction: (1) an RBridge may include a self-appointment Appointed Forwarders sub-TLV in any TRILL Hello to update peer inhibition timers for listed VLAN ranges; (2) an RBridge may use the new VLANs Appointed sub-TLV to list VLANs for which it is Appointed Forwarder, causing receivers to update inhibition timers. Support is indicated by Bit 0 of PORT-TRILL-VER.
Bit 0 of the Capability bits in the PORT-TRILL-VER sub-TLV is allocated with description 'Hello reduction support', indicating support of the VLANs Appointed sub-TLV and the VLAN inhibition timer setting mechanisms for optional TRILL Hello reduction.
Bit 1 from the RESV bits in the per-neighbor Neighbor RECORD of the TRILL Neighbor TLV is allocated with description 'Offering OOMF service', indicating that the sending RBridge volunteers to provide OOMF forwarding service to the TRILL Switch whose SNPA appears in that Neighbor RECORD.
Nickname 0xFFC1 (previously reserved by RFC 6325) is allocated for use in the TRILL Header Egress Nickname field to indicate an OOMF (Overload Originated Multi-destination Frame), enabling overloaded RBridges to tunnel multi-destination frames to a non-overloaded neighbor.
RFC 7180 corrects five errata in RFC 6325 and updates RFCs 6325, 6327, and 6439 but does not change the security considerations of those RFCs. The corrections and clarifications do not introduce new security properties or vulnerabilities.