rfc-7956

Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway

W. Hao, Y. Li, A. Qu, M. Durrani, P. Sivamurugan
date2016-09 streamIETF areartg wgtrill statusPROPOSED STANDARD pages28 canonicalhttps://www.rfc-editor.org/rfc/rfc7956 doi10.17487/RFC7956
The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter-subnet traffic forwarding but has the following issues: 1. Sub-optimum forwarding paths for inter-subnet traffic. 2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per Data Label used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus. 3. A traffic bottleneck at the gateway. This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues.

Extracted elements (27)

design-rationale §3.2

A centralized L3 gateway in a TRILL campus creates three problems: sub-optimal inter-subnet forwarding paths, an unscalable number of gateway interfaces (one per tenant per Data Label), and a traffic bottleneck. The distributed gateway solution moves L3 routing to edge RBridges, eliminating detours and spreading inter-subnet load optimally.

routing, ip

design-rationale §5.3

In active-active mode, both edge RBridges independently announce the same ES's IP address. Remote ingress RBridges generate equal-cost routing entries with two next hops and perform load balancing, providing both resilience against link failure and bandwidth utilization without requiring a separate protocol.

routing, ip

design-rationale §5.2

The tenant Data Label serves a role analogous to an MPLS VPN label: it identifies the tenant VRF at the egress RBridge for incoming inter-subnet traffic. Unlike MPLS VPN labels, tenant Data Labels are independently allocated per edge RBridge with no campus-wide coordination authority required.

routing, mpls

interoperability-note §5.2

If an edge RBridge changes its tenant gateway MAC, in-flight traffic using the old MAC as Inner.MacDA may be discarded or misforwarded as L2 intra-subnet traffic at the egress RBridge. If the inter-subnet tenant Data Label is shared with an access Data Label, the misforwarded traffic bypasses filtering unless an explicit traffic-filtering policy is in place.

routing

interoperability-note §5.2

Tenant Data Labels are independently allocated on each edge RBridge per routing domain with no campus-wide constraint; an edge RBridge may reuse an access Data Label or assign a distinct Data Label as its inter-subnet tenant Label. The ingress RBridge must use the label advertised by the specific egress RBridge.

routing

normative-requirement §5.2 MUST NOT

A tenant Data Label MUST NOT be reallocated to a new tenant until a reasonable time — for example, twice the IS-IS Holding Time in use — has passed, allowing in-flight traffic using the old label to be discarded and preventing its delivery into the wrong tenant's routing instance.

routing, security

normative-requirement §5.1 SHOULD

An IP router or ES connected to an edge RBridge through an external L3 network SHOULD run an IP routing protocol with that edge RBridge so the RBridge can learn the prefixes behind it; without such a protocol, only explicitly configured prefixes are accessible.

routing, ip

normative-requirement §5.1 SHOULD

Edge RBridges establishing gateway interfaces for the same subnet SHOULD share the same gateway MAC and gateway IP address configuration; consistency can be achieved by local configuration or NETCONF/YANG models.

routing, ip

normative-requirement §5.2 MUST

If ESs in a VN are spread over multiple RBridges, those RBridges MUST advertise each locally connected ES's IP address in the VN to other RBridges. If all ESs in a VN connect to a single RBridge, advertising the subnet prefix is sufficient.

routing, ip

normative-requirement §5.3 MUST

In active-active access mode, if an ES is connected to two RBridges RB1 and RB2, both MUST be configured to act as a distributed L3 gateway for that ES so that either RBridge can serve as an egress for inter-subnet traffic destined to it.

routing

normative-requirement §7.1 MUST

Reserved bits Resv1 and Resv2 (4 bits each) in the Tenant Label and Gateway MAC APPsub-TLV MUST be sent as zero and ignored on receipt.

routing

normative-requirement §7 MUST

The APPsub-TLVs for distributed gateway operation (TENANT-GWMAC-LABEL, IPV4-PREFIX, IPV6-PREFIX) MUST be included in a TRILL GENINFO TLV in E-L1FS FS-LSPs as specified in RFC 7780.

routing, registry

normative-requirement §5 MUST

The network operator MUST configure Tenant IDs on each edge RBridge for each routing domain consistently so that the same ID always refers to the same tenant; inconsistent configuration would cause traffic to be delivered to the wrong tenant.

routing, security

normative-requirement §5.2 MUST

When a routing instance is created on an edge RBridge, the Tenant ID, tenant Data Label, and tenant gateway MAC MUST be globally advertised (via the Tenant Label and Gateway MAC APPsub-TLV) so that remote edge RBridges can generate IP routing entries for that routing domain.

routing

protocol-element §5.1

ARP/ND is used by ESs to discover the gateway MAC of their local edge RBridge. The edge RBridge responds to ARP/ND requests for the gateway IP with its gateway MAC, simultaneously learning the ES's IP-to-MAC mapping and generating local IP routing entries in the tenant VRF.

routing, ip

protocol-element §5

Each edge RBridge supporting the distributed L3 gateway maintains one VRF instance per tenant, providing IP address isolation between routing domains. A Tenant ID unique across the TRILL campus identifies each routing domain and labels all synchronized routing information.

routing, ip

protocol-element §5.4

The egress RBridge identifies inter-subnet traffic by matching Inner.MacDA to its local tenant gateway MAC. It uses the inner Data Label to look up the corresponding VRF, performs IP routing in that VRF, and locally forwards the packet to the destination ES.

routing, ip

protocol-element §5.4

The ingress edge RBridge performing inter-subnet forwarding terminates the inner Ethernet header, looks up the destination IP in the tenant VRF, rewrites the inner Ethernet header with its own gateway MAC as Inner.MacSA and the egress RBridge's gateway MAC as Inner.MacDA, sets the egress RBridge's tenant Data Label as Inner.VLAN/FGL, and TRILL-encapsulates to the egress nickname.

routing, ip

protocol-element §7.2

The SE (Inter-Subnet Egress) flag in the NickFlags APPsub-TLV allows an edge RBridge with multiple nicknames to designate one specific nickname for inter-subnet traffic egress. If no nickname is designated, the ingress RBridge may use any nickname owned by the egress RBridge.

routing

registry §10

IANA assigned bit 1 with mnemonic 'SE' (Inter-Subnet Egress) in the NickFlags Bits registry created by RFC 7780, for use in the NickFlags APPsub-TLV to designate a preferred egress nickname for inter-subnet traffic forwarding.

registry, routing

registry §10

IANA assigned three APPsub-TLV type numbers in the 'TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1' registry: Type 7 (TENANT-GWMAC-LABEL), Type 8 (IPV4-PREFIX), and Type 9 (IPV6-PREFIX), all defined by RFC 7956.

registry, routing

security-consideration §8

Correct configuration of Tenant IDs across all participating edge RBridges is critical; misconfiguration can cause traffic to be delivered to the wrong tenant, violating tenant isolation. IS-IS security (RFC 5310) can be used to protect LSP and FS-LSP advertisements from tampering.

security, routing

security-consideration §8

Reassigning a just-deleted tenant Data Label to a new tenant too quickly creates a security policy violation window: in-flight traffic from the old tenant may be forwarded into the new tenant's routing instance and delivered to the wrong destination before routing tables converge.

security, routing

security-consideration §8

Selecting tenant Labels and Tenant IDs in a pseudorandom fashion (per RFC 4086) makes it harder for an adversary to guess an in-use label or ID. Particularly sensitive data should be encrypted end-to-end between source and destination ES.

security, crypto

wire-format §7.3

The IPv4 Prefix APPsub-TLV (Type 8) encodes: 2-byte Type, 2-byte Total Length (0 means no prefix advertised), 4-byte Tenant ID, followed by N repetitions of 1-byte PrefixLength and a variable-length Prefix field padded to an octet boundary.

routing, ip

wire-format §7.4

The IPv6 Prefix APPsub-TLV (Type 9) encodes: 2-byte Type, 2-byte Total Length (0 means no prefix advertised), 4-byte Tenant ID, followed by N repetitions of 1-byte PrefixLength and a variable-length Prefix field padded to an octet boundary.

routing, ip

wire-format §7.1

The Tenant Label and Gateway MAC APPsub-TLV (Type 7) encodes: 2-byte Type, 2-byte Length (12 for VLAN, 14 for FGL), 4-byte Tenant ID, 4-bit Resv1 + 12-bit Label1 (VLAN or high 12 bits of FGL), optionally 4-bit Resv2 + 12-bit Label2 (low 12 bits of FGL), and 6-byte Tenant Gateway MAC.

routing, registry