Load-Balancing for Mesh Softwires
updated by
- rfc-9012 — The BGP Tunnel Encapsulation Attribute
Extracted elements (16)
A smaller Load-Balancing Block value leaves more bits for per-flow identification, yielding better entropy and lower ECMP polarization, but consumes more L2TPv3 Session IDs or GRE Keys. Deployments must arbitrate this trade-off based on the number of supported services.
The mechanism places a signature (derived from the inner header) into the encapsulation header's load-balancing field to enhance per-flow entropy seen by core routers. Core routers thus make better ECMP decisions without needing to inspect the tunneled payload.
An ingress router that does not understand the Load-Balancing Block sub-TLV continues to use the single Session ID or GRE Key value advertised in the encapsulation sub-TLV, ensuring backward compatibility.
For L2TPv3-over-IP, the Session ID serves as the load-balancing field; for GRE, the GRE Key (RFC 2890) serves this role. The load-balancing block mechanism is not defined for IP-in-IP (tunnel type 7).
If the egress router does not support the Load-Balancing Block sub-TLV, the Softwire continues to operate with a single load-balancing field, and all ingress routers encapsulate using that one value.
Future tunnel types that wish to use the Load-Balancing Block sub-TLV MUST define a load-balancing field that is part of the encapsulating header. IP-in-IP (tunnel type 7) is explicitly excluded from the current definition.
If a load-balancing field is not signaled (e.g., GRE without a Key), the Load-Balancing Block sub-TLV MUST NOT be included in the advertisement.
The Load-Balancing Block sub-TLV MAY be included in any Encapsulation SAFI UPDATE message where load-balancing is desired.
The value field of the Load-Balancing Block sub-TLV MUST NOT exceed the size of the load-balancing field defined for the tunnel type.
When an egress router includes a Load-Balancing Block sub-TLV for L2TPv3-over-IP, it MUST encode the Session ID field of the encapsulation sub-TLV so that the most significant bits of the Session ID, after extracting the block, are non-zero.
Fields in the encapsulation header other than the load-balancing field (e.g., the optional L2TPv3 cookie) are shared across all per-flow load-balancing field values and are not modified by the Load-Balancing Block mechanism.
For L2TPv3-over-IP encapsulation, the ingress PE selects per-flow values by taking the block prefix (first N bits) from the Session ID advertised by the egress and filling the remaining lower-order bits with a per-flow identifier derived from, e.g., inner source/destination addresses and TCP/UDP ports.
The Load-Balancing Block sub-TLV (type 5) is a new sub-TLV for the BGP Tunnel Encapsulation Attribute (RFC 5512). Its length is 2 octets, and its value represents the size of the load-balancing block in bits, following a VLSM-like model where the block is extracted from the leading bits of the load-balancing field.
IANA assigned sub-TLV type value 5 to 'Load-Balancing Block' in the BGP Tunnel Encapsulation Attribute Sub-TLVs registry, originally created by RFC 5512.
This document introduces no additional security risks beyond those already covered in RFC 5512 for the BGP Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute. Implementors are referred to RFC 5512 for applicable security considerations.
The Load-Balancing Block sub-TLV has sub-TLV type 5, a fixed 2-octet length field, and a 2-octet value field encoding the block size in bits. The block is determined by extracting the initial 'block size' bits from the encapsulation header's load-balancing field (e.g., L2TPv3 Session ID or GRE Key).