RTGWG Z. Li Internet-Draft Z. Du Intended status: Standards Track China Mobile Expires: 1 September 2026 W. Cheng J. Wang G. Zhang Centec Networks 28 February 2026 Combined Hash Mechanism for ECMP/LAG Load Balancing draft-li-rtgwg-ecmp-hash-combination-00 Abstract This document specifies a combined hash mechanism for load balancing in Equal-Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) environments. When processing tunneled traffic, traditional hash methods that operate on either outer or inner packet fields may result in uneven traffic distribution (polarization). This specification defines a method to extend effective hash entropy by combining multiple independently computed hash values, enabling network devices to consider multi-layer packet information for path selection, thereby improving traffic distribution uniformity. This mechanism is compatible with existing hash computation architectures and does not require packet format modifications or new protocol field definitions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 September 2026. Li, et al. Expires 1 September 2026 [Page 1] Internet-Draft Combined Hash for ECMP/LAG February 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Tunnel Traffic Polarization . . . . . . . . . . . . . . . 4 4.2. Limitations of Existing Solutions . . . . . . . . . . . . 5 4.3. Motivation for Combined Hashing . . . . . . . . . . . . . 5 5. Combined Hash Mechanism Overview . . . . . . . . . . . . . . 5 5.1. Basic Principle . . . . . . . . . . . . . . . . . . . . . 5 5.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Relationship with Existing Mechanisms . . . . . . . . . . 6 6. Protocol Specification . . . . . . . . . . . . . . . . . . . 7 6.1. Base Hash Computation . . . . . . . . . . . . . . . . . . 7 6.2. Combination Operations . . . . . . . . . . . . . . . . . 7 6.3. Path Selection . . . . . . . . . . . . . . . . . . . . . 8 7. Configuration Model . . . . . . . . . . . . . . . . . . . . . 8 7.1. Configuration Parameters . . . . . . . . . . . . . . . . 8 7.2. Configuration Constraints . . . . . . . . . . . . . . . . 9 8. Operational Procedures . . . . . . . . . . . . . . . . . . . 9 8.1. Initialization . . . . . . . . . . . . . . . . . . . . . 9 8.2. Packet Processing . . . . . . . . . . . . . . . . . . . . 9 8.3. Configuration Change Handling . . . . . . . . . . . . . . 10 9. Relationship with Existing Mechanisms . . . . . . . . . . . . 10 9.1. Relationship with RFC 6438 . . . . . . . . . . . . . . . 10 9.2. Relationship with RFC 6790 . . . . . . . . . . . . . . . 11 9.3. Relationship with RFC 2992 . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10.1. Configuration Security . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Li, et al. Expires 1 September 2026 [Page 2] Internet-Draft Combined Hash for ECMP/LAG February 2026 Appendix A. Deployment Scenario Examples . . . . . . . . . . . . 13 A.1. Data Center Overlay Networks . . . . . . . . . . . . . . 13 A.2. Service Provider Core Networks . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Equal-Cost Multi-Path (ECMP) routing and Link Aggregation Groups (LAGs) are widely deployed technologies in modern networks for bandwidth scaling and redundancy. As described in [RFC2991] and [RFC2992], these technologies improve network performance and reliability by distributing traffic across multiple equal-cost paths. In ECMP/LAG environments, routers typically employ hash-based methods to select forwarding paths. As analyzed in [RFC2992], hash algorithms extract key information from packet header fields to compute hash values used for path selection. Typical hash inputs include the 5-tuple (source/destination IP addresses, source/ destination ports, protocol type) or subsets thereof. However, [RFC6438] identifies that in tunnel scenarios, when multiple distinct user flows are encapsulated within the same tunnel, hashing based solely on outer headers causes all encapsulated flows to be mapped to the same path, resulting in polarization. While RFC 6438 addresses this by setting the flow label in the outer IPv6 header, this requires tunnel endpoint cooperation and only applies to IPv6 outer encapsulation scenarios. This document defines a complementary combined hash mechanism that extends available hash entropy by combining multiple independently computed hash values within the forwarding device, thereby improving load distribution for tunneled traffic without modifying packet formats. This mechanism can be used in conjunction with [RFC6438] and [RFC6790], or deployed independently. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology This section defines terms used in this document. Some terms are inherited from [RFC2991], [RFC2992], [RFC6438], and [RFC6790]. Li, et al. Expires 1 September 2026 [Page 3] Internet-Draft Combined Hash for ECMP/LAG February 2026 Equal-Cost Multi-Path (ECMP): A routing strategy that allows packet forwarding to a single destination over multiple paths with equal routing cost. See [RFC2991]. Link Aggregation Group (LAG): A technology that bundles multiple physical links into a single logical link, providing bandwidth aggregation and link redundancy. See [IEEE802.1AX]. Hash Entropy: The amount of variability in the input to a hash function. Higher entropy typically leads to more uniform hash output distribution. Polarization: In ECMP/LAG environments, the phenomenon where traffic concentrates on a subset of paths due to insufficient variability in hash inputs. See [RFC6438]. Base Hash Value: A hash value computed by a single hash computation unit based on a specific set of packet fields. Combined Hash Value: A new hash value derived by applying a combination operation to two or more base hash values. Hash Field Set: The set of packet fields used as hash input. This document defines standard field sets including L2 (source MAC, destination MAC, VLAN tag, EtherType), L3 (source IP, destination IP, protocol), L4 (source port, destination port), OUTER (outer header fields), and INNER (inner/payload header fields). 4. Problem Statement 4.1. Tunnel Traffic Polarization As described in Section 1.1 of [RFC6438], in tunnel scenarios, when traffic from multiple sources is aggregated into a single tunnel, all encapsulated packets have the same outer source and destination addresses. If ECMP/LAG paths exist between intermediate routers, and path selection is based solely on hashing the outer 5-tuple (or its subset), all tunnel traffic will be mapped to the same path, preventing effective load sharing. _____ _____ _____ _____ | TEP |______| R1 |---------------| R2 |______| TEP | |__A__| |_____|---------------|_____| |__B__| ECMP or LAG here Figure 1: Tunnel Scenario with ECMP/LAG Li, et al. Expires 1 September 2026 [Page 4] Internet-Draft Combined Hash for ECMP/LAG February 2026 4.2. Limitations of Existing Solutions Existing solutions each have their applicable scenarios and limitations: * *IPv6 Flow Label Approach [RFC6438]:* Requires IPv6 outer encapsulation and cooperation from the ingress tunnel endpoint (TEP) to set the flow label. * *MPLS Entropy Label Approach [RFC6790]:* Only applicable to MPLS networks and requires all LSRs along the path to support entropy labels. * *Deep Packet Inspection (DPI):* While some devices support inspecting inner packet fields for hashing, this increases processing complexity and latency, and is unavailable when packets are encrypted. 4.3. Motivation for Combined Hashing In practical network devices, a common implementation approach is to configure multiple parallel hash computation units, each independently configurable with its hash field set. However, final path selection typically can only use one of these hash values. The combined hash mechanism defined in this document allows combining multiple base hash values to produce a combined hash value that considers multi-layer information for final path selection. 5. Combined Hash Mechanism Overview 5.1. Basic Principle The core idea of the combined hash mechanism is to apply combination operations to multiple independently computed base hash values, producing a new combined hash value. Through this approach: 1. Each base hash value can be independently computed from different packet field sets (e.g., outer L3, inner L3, L2 fields). 2. The combination operation merges the entropy of multiple base hash values, producing a combined hash value containing more information. 3. Final path selection can be based on the combined hash value, thus indirectly achieving comprehensive consideration of multiple field sets. Li, et al. Expires 1 September 2026 [Page 5] Internet-Draft Combined Hash for ECMP/LAG February 2026 5.2. Architecture +--------------------+ +--------+ | Hash Compute Unit 0|-----> H0 | | +-----------+ +--------------------+ | | |-->| Field Set |---->| Hash Function | | | | | A | +--------------------+ | | | +-----------+ | | | +--------------------+ | | Packet | +-----------+ | Hash Compute Unit 1|-----> H1 | |-->| Field Set |---->+--------------------+ | | | | B | | | | +-----------+ v | | +--------------------+ | | +-----------+ | Hash Compute Unit 2|-----> H2 --+ | |-->| Field Set |---->+--------------------+ | | | | C | | | | +-----------+ +--------------------+ | | | +-----------+ | Hash Compute Unit 3|-----> H3 --+ | |-->| Field Set |---->+--------------------+ | +--------+ | D | | +-----------+ v +---------------+ | Combination | | H_c = H2 ^ H3 | +---------------+ | v +---------------+ | Path Selection| | from {H0..H3, | | H_c} | +---------------+ | v Forwarding Path Figure 2: Combined Hash Mechanism Architecture 5.3. Relationship with Existing Mechanisms This mechanism complements [RFC6438] and [RFC6790]. When the outer layer uses IPv6 and TEPs support RFC 6438, the flow label approach can be preferred. When MPLS networks are deployed with RFC 6790 support, the entropy label approach can be preferred. When the above conditions are not met, the combined hash mechanism provides a purely local implementation alternative. These approaches can be used together for optimal results. Li, et al. Expires 1 September 2026 [Page 6] Internet-Draft Combined Hash for ECMP/LAG February 2026 6. Protocol Specification 6.1. Base Hash Computation Devices implementing this specification MUST support at least two independent base hash computation units. Each computation unit SHOULD support independent configuration of its hash field set. RECOMMENDED hash field set configuration options include: +==============+======================+==================+ | Field Set ID | Included Fields | Typical Use Case | +==============+======================+==================+ | L2 | Source MAC, Dest | Ethernet | | | MAC, VLAN, EtherType | switching | +--------------+----------------------+------------------+ | L3 | Source IP, Dest IP, | IP routing | | | Protocol | | +--------------+----------------------+------------------+ | L4 | Source Port, Dest | Transport layer | | | Port | differentiation | +--------------+----------------------+------------------+ | OUTER | Outer packet L2/L3/ | Tunneled traffic | | | L4 fields | | +--------------+----------------------+------------------+ | INNER | Inner packet L2/L3/ | Tunneled traffic | | | L4 fields | | +--------------+----------------------+------------------+ Table 1: Hash Field Set Options Base hash value bit-width SHOULD be at least 16 bits. Implementations MAY support larger bit-widths for better distribution characteristics. 6.2. Combination Operations Implementations MUST support XOR combination operation on two base hash values: H_combined = H_x XOR H_y where H_x and H_y are any two selected base hash values. Implementations MAY additionally support the following combination operations: *Addition combination:* Li, et al. Expires 1 September 2026 [Page 7] Internet-Draft Combined Hash for ECMP/LAG February 2026 H_combined = (H_x + H_y) mod 2^n where n is the hash value bit-width. *Concatenation hash:* H_combined = Hash(H_x || H_y) where || denotes bit-level concatenation and Hash() is the configured hash function. When using XOR operation, implementations MUST detect whether H_x and H_y might be identical (computed from the same field set). If configured to XOR identical hash values, implementations SHOULD generate a warning, as this will result in a combined value of zero. 6.3. Path Selection Implementations MUST support selecting the final hash value for path selection from any base hash value (H0, H1, H2, H3, ...) or the combined hash value (H_combined). Final hash value selection SHOULD be configurable. For ECMP path selection, the hash-threshold algorithm described in [RFC2992] or a similar deterministic algorithm SHOULD be used to ensure all packets of the same flow are forwarded to the same path. 7. Configuration Model This section defines parameters required for configuring the combined hash mechanism. Specific configuration interfaces (CLI, NETCONF/ YANG, etc.) are outside the scope of this document. 7.1. Configuration Parameters +========================+======+======================+=========+ | Parameter | Type | Range | Default | +========================+======+======================+=========+ | hash-unit-count | int | 2-8 | 4 | +------------------------+------+----------------------+---------+ | hash-unit[i].field-set | enum | L2,L3,L4,OUTER,INNER | - | +------------------------+------+----------------------+---------+ | combination.enabled | bool | true/false | false | +------------------------+------+----------------------+---------+ | combination.input-1 | int | 0 to (count-1) | - | +------------------------+------+----------------------+---------+ | combination.input-2 | int | 0 to (count-1) | - | Li, et al. Expires 1 September 2026 [Page 8] Internet-Draft Combined Hash for ECMP/LAG February 2026 +------------------------+------+----------------------+---------+ | combination.operation | enum | XOR,ADD,CONCAT-HASH | XOR | +------------------------+------+----------------------+---------+ | final-hash-select | int | 0 to count | 0 | +------------------------+------+----------------------+---------+ Table 2: Configuration Parameters 7.2. Configuration Constraints The following configuration constraints MUST be enforced: 1. combination.input-1 and combination.input-2 SHOULD NOT be configured to the same value. If configured to the same value, implementations MUST generate a warning. 2. When combination.enabled is false, the valid range for final- hash-select is 0 to (hash-unit-count - 1). 3. When combination.enabled is true, final-hash-select MAY additionally select the combined hash value. 8. Operational Procedures 8.1. Initialization Upon device startup, the following initialization procedure MUST be executed: 1. Read and validate configuration parameter validity. 2. Configure each hash computation unit with its corresponding field set. 3. If combined hashing is enabled, initialize the combination operation module. 4. Configure path selection logic to use the specified final hash value. 8.2. Packet Processing For each received packet, the processing procedure is as follows: *Step 1: Base Hash Computation* * Each hash computation unit extracts configured fields from the packet in parallel. Li, et al. Expires 1 September 2026 [Page 9] Internet-Draft Combined Hash for ECMP/LAG February 2026 * Execute hash function computation on extracted fields. * Produce base hash values H0, H1, ..., Hn. *Step 2: Combined Hash Computation (if enabled)* * Select two base hash values according to configuration. * Execute the configured combination operation. * Produce combined hash value H_combined. *Step 3: Path Selection* * Select final hash value according to final-hash-select configuration. * Execute path selection algorithm using final hash value (e.g., hash-threshold algorithm from [RFC2992]). * Determine forwarding path and forward packet. 8.3. Configuration Change Handling When configuration changes occur: * Implementations SHOULD support online configuration changes without device restart. * Configuration changes MUST take effect immediately for subsequent packets. * Implementations SHOULD log configuration change events for audit purposes. 9. Relationship with Existing Mechanisms 9.1. Relationship with RFC 6438 [RFC6438] defines a method for using the flow label in IPv6 tunnel scenarios for ECMP/LAG load balancing. That method requires the ingress tunnel endpoint to set a flow label value in the outer IPv6 header based on information computed from the inner packet. Li, et al. Expires 1 September 2026 [Page 10] Internet-Draft Combined Hash for ECMP/LAG February 2026 The combined hash mechanism defined in this document complements [RFC6438]: RFC 6438 executes at tunnel endpoints and affects all intermediate nodes along the tunnel path, while the combined hash mechanism executes locally at a single forwarding node and does not affect other nodes. When both mechanisms are used together, their effects can accumulate. 9.2. Relationship with RFC 6790 [RFC6790] defines the MPLS entropy label mechanism, allowing entropy information for load balancing to be carried in the MPLS label stack. The mechanism defined in this document complements [RFC6790]: RFC 6790 requires nodes along the path to support entropy label parsing, while the combined hash mechanism does not require support from other nodes. In MPLS networks, both mechanisms can be used simultaneously. 9.3. Relationship with RFC 2992 [RFC2992] analyzes the hash-threshold algorithm for ECMP. The final hash value produced by the combined hash mechanism defined in this document can be used as input to the RFC 2992 algorithm. This document does not modify or replace the path selection algorithm defined in [RFC2992]. 10. Security Considerations 10.1. Configuration Security The combined hash mechanism is a local device behavior and does not introduce new attack surfaces beyond those inherent in hash-based load balancing. However, operators should be aware that hash configuration details, if exposed, could allow traffic engineering attacks. Implementations MUST enforce access control for hash configuration parameters. Implementations SHOULD log configuration changes for audit purposes. 11. IANA Considerations This document does not require IANA to allocate any protocol parameters or create new registries. The combined hash mechanism is purely a local implementation optimization and does not involve protocol interactions. If future working group consensus determines that configuration parameter namespaces need to be standardized (e.g., for YANG models), IANA action may be requested at that time. Li, et al. Expires 1 September 2026 [Page 11] Internet-Draft Combined Hash for ECMP/LAG February 2026 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 28 February 2026, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 28 February 2026, . 12.2. Informative References [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, 28 February 2026, . [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, 28 February 2026, . [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, 28 February 2026, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, 28 February 2026, . [RFC7424] Krishnan, R., Yong, L., Ghanwani, A., So, N., and B. Khasnabish, "Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424, 28 February 2026, . [IEEE802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std 802.1AX-2020, 28 February 2026. Li, et al. Expires 1 September 2026 [Page 12] Internet-Draft Combined Hash for ECMP/LAG February 2026 Appendix A. Deployment Scenario Examples A.1. Data Center Overlay Networks In overlay networks such as VXLAN/NVGRE, large amounts of tenant traffic traverse shared underlay tunnels. Example configuration: * Hash unit 0: OUTER field set (outer IP addresses) * Hash unit 1: INNER field set (inner IP addresses) * Combination operation: H0 XOR H1 * Final selection: Combined hash value This configuration enables path selection to consider both outer tunnel information and inner tenant flow information. A.2. Service Provider Core Networks In MPLS backbone networks, entropy labels may not be fully deployed. Example configuration: * Hash unit 0: L3 field set (IP 5-tuple) * Hash unit 1: MPLS label stack * Combination operation: H0 XOR H1 * Final selection: Combined hash value This configuration provides improved load distribution without relying on entropy labels. Authors' Addresses Zhiqiang Li China Mobile 32 Xuanwumen West Street Beijing 100053 China Email: lizhiqiangyjy@chinamobile.com Zongpeng Du China Mobile 32 Xuanwumen West Street Li, et al. Expires 1 September 2026 [Page 13] Internet-Draft Combined Hash for ECMP/LAG February 2026 Beijing 100053 China Email: duzongpeng@chinamobile.com Wei Cheng Centec Networks Suzhou 215000 China Email: chengw@centec.com Junjie Wang Centec Networks Suzhou 215000 China Email: wangjj@centec.com Guoying Zhang Centec Networks Suzhou 215000 China Email: zhanggy@centec.com Li, et al. Expires 1 September 2026 [Page 14]