rfc-7172

Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling

D. Eastlake 3rd, M. Zhang, P. Agarwal, R. Perlman, D. Dutt
date2014-05 streamIETF areartg wgtrill statusPROPOSED STANDARD pages27 canonicalhttps://www.rfc-editor.org/rfc/rfc7172 doi10.17487/RFC7172
The IETF has standardized Transparent Interconnection of Lots of Links (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.

updates

Extracted elements (29)

design-rationale §2.1

FGL was designed to reuse existing fast-path silicon features as much as possible. The Inner.Label High Part priority field is in the same position as in the VL Inner.VLAN label, allowing transit processing to use the same code path for both packet types.

routing

design-rationale §A

Serial TRILL unicast is specified as an alternative to distribution trees for multi-destination FGL packets. Unicast SHOULD be used when only one egress FGL switch is relevant, as it follows least-cost paths with ECMP traffic spreading, whereas distribution trees are constrained to a single path per tree.

routing

design-rationale §3

The FGL label space is flat and separate from the VL (C-VLAN) space. C-VLAN IDs on native frames are stripped at ingress and mapped to FGL per-port, allowing the same FGL to correspond to different C-VLANs on different ports or links, enabling flexible multi-tenant isolation.

routing

design-rationale §2.4

VL and FGL coexistence is retained for three reasons: (1) VL switches can exchange VL packets through an FGL core using specified precautions; (2) a maintenance VLAN/FGL in which all switches participate is simpler if VL is used when any VL switches remain; (3) incremental campus upgrades from VL to FGL require long-term VL support.

routing

interoperability-note §3

FGL TRILL switch ports can be configured for FGL or VL, with VL as the default. An unconfigured FGL TRILL switch port reports untagged frames as VLAN 1, matching base protocol behavior. Outer.VLAN on Ethernet links can only be a C-VLAN tag regardless of FGL configuration.

routing

interoperability-note §5.1

VL TRILL switches conformant to RFC 6325 should discard frames with 0x893B after the inner MAC addresses, but non-conformant implementations could mishandle FGL packets by egressing them into the wrong VLAN, incorrectly pruning multicast distribution, or persistently misordering packets due to ECMP flow miscomputation.

routing, security

normative-requirement §4.2.1 MUST

All transit TRILL switches MUST take the priority and DEI used to forward a packet from the Inner.VLAN label or the FGL Inner.Label High Part, which are in the same place in the packet. An FGL TRILL switch MUST properly distinguish flows if it provides ECMP for unicast FGL TRILL Data packets.

routing

normative-requirement §9 MUST

All TRILL switches MUST check the Ethertype immediately after the Inner.MacSA and, if it is a value they do not know how to handle, either discard the frame or make no decisions based on any data after that Ethertype.

routing, security

normative-requirement §4.1.1 SHOULD

An FGL ingress TRILL switch SHOULD unicast a multi-destination TRILL Data packet if there is only one relevant egress FGL TRILL switch. The relevant egress set starts with switches advertising interest in the frame's (X.Y) label and SHOULD be further filtered by multicast listener announcements.

routing

normative-requirement §2.3 MUST

An FGL TRILL Data packet MUST contain exactly two occurrences of Ethertype 0x893B as shown in the packet structure. If a TRILL switch processing an FGL packet notices that the second occurrence is any other value, it MUST discard the packet.

routing, security

normative-requirement §4.3 MUST NOT

An FGL TRILL switch MUST NOT egress an FGL packet with label (X.Y) to any port not configured with that FGL, even if the port is configured to egress VL packets in VLAN X.

routing, security

normative-requirement §4.3 MUST

FGL TRILL switches MUST accept multi-destination TRILL Data packets sent to them as TRILL unicast packets (M bit = 0). They locally egress such packets if appropriate, but MUST NOT forward them to other TRILL switches.

routing

normative-requirement §5.1 MUST

For mixed-campus safety, all FGL-safe switches MUST do Step (A) or (B) for any port with a VL RBridge neighbor, and MUST do Step (C) — use only distribution trees rooted at FGL TRILL switch nicknames for FGL traffic. If using Step (A) with low-speed links (~100 Mbps or less), link costs MUST be adjusted so no adjacency between FGL-safe switches exceeds cost 200,000.

routing

normative-requirement §4.5 MUST

If distribution tree roots are configured, there MUST be at least one tree rooted at a nickname held by an FGL TRILL switch or an FGL link pseudonode. If misconfigured such that no such tree exists, the highest-priority FGL nickname is used to construct an additional tree regardless of configuration.

routing

normative-requirement §5.2 MUST

On a link with mixed FGL and VL ports where an FGL switch is DRB, it MUST appoint only other FGL TRILL switch ports as Appointed Forwarder for any VLANs that are to be mapped to FGL. If Step (B) is in effect, an FGL DRB MUST only appoint FGL Appointed Forwarders.

routing

normative-requirement §5.1 MUST

Once any TRILL switch advertises an FGL-edge, any FGL-safe TRILL switch (RB1) that observes a VL RBridge on one of its ports MUST take Step (A) — discard FGL output to that port and report increased adjacency cost (2^23 higher) — or Step (B) — report adjacency cost as 2^24−1 to block the adjacency from least-cost calculations.

routing, security

normative-requirement §4.1 MUST

The FGL ingress process MUST copy the priority and DEI of an ingressed native frame to the upper 4 bits of the Inner.Label Low Order part. It SHOULD also associate a possibly different mapped priority and DEI in the Inner.Label High Part; if mapping is not supported, the original priority and DEI MUST be placed in the High Part.

routing

normative-requirement §4.1.1 MUST NOT

When a native frame with a broadcast, multicast, or unknown MAC destination is FGL-ingressed as a multi-destination TRILL packet, it MUST NOT be sent on a distribution tree rooted at a nickname held by a VL TRILL switch or a VL link pseudonode.

routing

protocol-element §4.7

ESADI is extended to support FGL: the FGL to which an ESADI packet applies is indicated only by the Inner.Label of the packet, and no indication of the FGL is allowed within the ESADI payload, mirroring the VL approach.

routing

protocol-element §4.6

FGL address learning on FGL-configured ports uses the fine-grained label rather than the native frame VLAN. Local addresses are represented as {MAC address, FGL, port, confidence, timer}; remote addresses as {MAC address, FGL, remote TRILL switch nickname, confidence, timer}.

routing

protocol-element §2.3

Fine-Grained Labeling (FGL) extends TRILL data labels to 24 bits, denoted (X.Y), where X is the 12-bit high-order part and Y is the 12-bit low-order part. This provides up to 2^24 labels, vastly exceeding the 4094 VLANs supported by the base protocol.

routing

protocol-element §6

IS-IS extensions required for FGL include: (1) a method for a TRILL switch to announce itself as FGL-safe in its LSP, (2) the Interested Labels and Spanning Tree Roots (INT-LABEL) sub-TLV analogous to the Interested VLANs sub-TLV, and (3) GLMAC-ADDR, GLIP-ADDR, and GLIPV6-ADDR sub-TLVs specifying FGL-based group addresses.

routing

registry §8.2

IANA has allocated capability flag bit 1 in the TRILL-VER sub-TLV capability flags (defined in RFC 7176) to indicate that a TRILL switch is FGL-safe. FGL-safe TRILL switches MUST advertise this flag in their IS-IS LSPs.

registry, routing

registry §8.1

The IEEE Registration Authority has assigned Ethertype 0x893B for TRILL Fine-Grained Labeling (FGL). This value is used twice in each FGL TRILL Data packet, immediately preceding the Inner.Label High Part and Inner.Label Low Part respectively.

registry, routing

security-consideration §9

A VL TRILL switch that fails to discard packets with non-0x8100 Ethertype after the Inner.MacSA could egress an FGL packet (X.Y) into VLAN X, violating the security policy requiring configurable separation of differently labeled data. For multi-destination packets, it could also incorrectly prune based on VLAN X, preventing delivery to intended recipients.

routing, security

security-consideration §9

An FGL TRILL switch that receives a malformed TRILL Data packet and does not check the Ethertype after the Inner.MacSA could improperly egress the packet in VLAN X, violating security policy. End-to-end encryption and authentication should be considered for sensitive data traversing the TRILL campus.

routing, security

wire-format §2.3

Each 2-byte FGL label part (following 0x893B) has a 3-bit priority field in bits 0–2, a 1-bit Drop Eligibility Indicator (DEI) in bit 3, and 12 bits of label information in bits 4–15. The High Part carries the campus transit priority; the Low Part carries the preserved original user priority.

routing

wire-format §2.3

FGL TRILL Data packets use Ethertype 0x893B (2 bytes) followed by Inner.Label High Part (2 bytes), then a second 0x893B (2 bytes) followed by Inner.Label Low Part (2 bytes), all appearing after the inner MAC addresses inside the TRILL Header.

routing

wire-format §2.2

VL TRILL Data packets carry Inner.MacDA (6 bytes), Inner.MacSA (6 bytes), Ethertype 0x8100 (2 bytes), and Inner.VLAN Label (2 bytes) inside the TRILL Header, followed by the native payload.

routing