Network Working Group L. Gong Internet Draft China Mobile Intended status: Standards Track C. Lin Expires: January 07, 2027 New H3C Technologies July 06, 2026 Metric Normalize for IGP Flex-algo draft-gl-lsr-metric-normalize-01 Abstract When multiple links in a network have the same metric, they can serve as ECMP equivalent links for load balancing during forwarding. However, slight fluctuations in metric values can prevent the formation of ECMP equivalent links, leading to the idle state of suboptimal links and thus wasting bandwidth resources. This document proposes a metric normalization method by advertising metric normalization parameters corresponding to a specific Metric- Type for Flexible Algorithm. During route calculation, slight fluctuations across multiple links are adjusted according to these normalization parameters, making the computed metric values more consistent. This approach enables the formation of ECMP equivalent links and promotes load sharing in the forwarding process. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 07, 2027. Gong & Lin, et al. Expires January 07, 2027 [Page 1] Internet-Draft Metric Normalize for IGP Flex-algo July 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 2. Terminology....................................................3 3. Problem........................................................3 4. Solution.......................................................4 5. Usecase........................................................4 6. Extensions.....................................................5 6.1. Flex-Algo Extensions......................................5 6.1.1. ISIS Flex-Algo Metric Normalize Sub-TLV ..............6 6.1.2. OSPF Flexible Algorithm Metric Normalize Sub-TLV.....7 7. Security Considerations........................................8 8. IANA Considerations............................................8 8.1. ISIS Flex-Algo Metric Normalize...........................8 8.2. OSPF Flex-Algo Metric Normalize...........................9 9. Security Considerations........................................9 10. References....................................................9 10.1. Normative References.....................................9 10.2. Informational References.................................9 Authors' Addresses...............................................10 1. Introduction When there are slight differences in metrics among multiple paths in a network, these paths cannot be computed as ECMP routes, resulting in suboptimal paths being unused for traffic forwarding and leading to inefficient bandwidth utilization. To eliminate these slight metric differences, this document proposes a method for normalizing metric calculations. Gong & Lin, et al. Expires January 07, 2027 [Page 2] Internet-Draft Metric Normalize for IGP Flex-algo July 2026 This document proposes a metric normalization method by advertising metric normalization parameters corresponding to a specific Flexible Algorithm. During route calculation, slight fluctuations across multiple links are adjusted according to these normalization parameters, making the computed metric values more consistent. This approach enables the formation of ECMP equivalent links and promotes load sharing in the forwarding process. 1.1. 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. 2. Terminology TBD. 3. Problem [RFC9350] defines types of link metrics, including IGP-Metric, Link Delay, Link Loss, and Bandwidth. Different normalization parameters must be set for each metric type. For example, parameters such as metric-step and metric-offset need to be configured separately for link delay and link loss. Metrics are advertised per metric type, and basic topology computation and Flex-Algorithm computation, or different FA computations, may involve distinct metric normalization constraint conditions, meaning each FA may require its own normalization strategy. Currently, the normalization parameters configured independently on each device can only affect the advertisement of specific metric types on their respective devices. They cannot implement different metric normalization strategies for different FAs during route computation. Therefore, this document proposes advertising metric normalization strategies through FA constraint conditions. By advertising normalization strategies for specific metric types within an FA, different FAs can execute distinct metric normalization strategies during path computation. Gong & Lin, et al. Expires January 07, 2027 [Page 3] Internet-Draft Metric Normalize for IGP Flex-algo July 2026 4. Solution The routing sender advertises a Normalize policy for a metric type within an FA. When the receiver performs route calculation for that metric type in the corresponding FA, it applies metric standardization according to the following rules: (1) Set two parameters for metric calculation: metric-step and metric-offset. (2) Calculate a. a = metric / metric-step, with the result rounded down (floor function). The metric is the actual metric of the link. (2) Calculate b. b = a * metric-step + metric-offset. (3) Calculate normal-metric (the final advertised metric): If metric <= b, then normal-metric = b; If metric > b, then normal-metric = b + metric-step. By using this method, the results standardized within the metric- step range will be the same when the Metric difference falls within this range. 5. Usecase As shown in Figure 4, due to different link delay metrics between R2<->R3 and R4<->R5, but the difference is not significant. The final computed path from R1 to R6 is R1->R4->R5->R6, and the link between R3 and R6 is idle. To solve the above issue, link delay metrics can be standardized, where metric-step is 10 and metric-offset is 3. The standardization process for the link R2->R3 with link delay metric value 31 is as follows: Gong & Lin, et al. Expires January 07, 2027 [Page 4] Internet-Draft Metric Normalize for IGP Flex-algo July 2026 (1) Calculate a. a = 31 / 10; the result after floor operation is 3. (2) Calculate b. b = 3 * 10 + 3; the result is 33. (3) Calculate normal-metric. Since 31 is less than 33, normal-metric = 33. The link delay metric finally advertised is 33. The standardization process for the link R4->R5 with link delay metric value 29 is as follows: (1) Calculate a. a = 29 / 10; the result after floor operation is 2. (2) Calculate b. b = 2 * 10 + 3; the result is 23. (3) Calculate normal-metric. Since 29 is greater than 23, normal- metric = 23 + 10. The link delay metric finally advertised is 33. After completing the above standardization, Flex-Algo finally computes two paths from R1 to R6: R1->R2->R3->R6 and R1->R4->R5->R6, thereby achieving the goal of fully utilizing link resources. +--+ 31 +--+ +-+R2+------+R3+---+ / +--+ +--+ \20 20/ \ / +--+ ++-+ |R6| |R1| +--+ ++-+ / \ /20 20 \ +--+ 29 +--+ / \+-|R4+------+R5+--+/ +--+ +--+ Figure 4: Link delay Metric Normalize 6. Extensions 6.1. Flex-Algo Extensions [RFC9350] defines constraints and parameters in Flex-Algo to better control network path computations. Gong & Lin, et al. Expires January 07, 2027 [Page 5] Internet-Draft Metric Normalize for IGP Flex-algo July 2026 [RFC9350] Section 5.1 defines the ISIS Flexible Algorithm Definition Advertisement, and Section 5.2 defines the OSPF Flexible Algorithm Definition Advertisement. Based on this, this document extends new Sub-TLV types within the Flexible Algorithm Definition Sub-TLV to advertise Metric Normalize information for the ISIS and OSPF protocols, these constraints to allow multiple paths with metric differences within a certain range to be used as ECMP routes. 6.1.1. ISIS Flex-Algo Metric Normalize Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric Normalize Info | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ISIS Flexible Algorithm Metric Normalize Sub-TLV where: Type(1 octet): TBD1 Length(1 octet): variable, dependent on the size of the Metric Normalize Info. Metric Normalize Info: Multiple Metric Normalize Data, See below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 Gong & Lin, et al. Expires January 07, 2027 [Page 6] Internet-Draft Metric Normalize for IGP Flex-algo July 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric-type | Resved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric-Step | Metric-Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Metric Normalize Data 1. Metric-type (1 octet): An 8-bit field specifying the type of metric. The value is taken from the "IGP Metric-Type" registry maintained by IANA. 2. Metric-Step (2 octets): Value of metric-step 3. Metric-Offset(2octets): Value of metric-offset 6.1.2. OSPF Flexible Algorithm Metric Normalize Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric Normalize Info | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: OSPF Flexible Algorithm Metric Normalize Sub-TLV where: Type(2 octetes): TBD2 Gong & Lin, et al. Expires January 07, 2027 [Page 7] Internet-Draft Metric Normalize for IGP Flex-algo July 2026 Length(2 octetes): variable, dependent on the size of the Metric Normalize Info. Metric Normalize Info: Multiple Metric Normalize Data, See below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric-type | Resved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric-Step | Metric-Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Metric Normalize Data 1. Metric-type (1 octet): An 8-bit field specifying the type of metric. The value is taken from the "IGP Metric-Type" registry maintained by IANA. 2. Metric-Step (2 octets): Value of metric-step 3. Metric-Offset(2octets): Value of metric-offset 7. Security Considerations TBD. 8. IANA Considerations 8.1. ISIS Flex-Algo Metric Normalize IANA is requested to assign a code point for "Metric Normalize" from "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry. [RFC9350, Sec 18.3.3] Value Description Reference ---------------------------------------------------------- TBD1 Metric Normalize This Document Gong & Lin, et al. Expires January 07, 2027 [Page 8] Internet-Draft Metric Normalize for IGP Flex-algo July 2026 8.2. OSPF Flex-Algo Metric Normalize IANA is requested to assign a code point for "Metric Normalize" from "OSPF Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry. [RFC9350, Sec 18.4.8] Value Description Reference ---------------------------------------------------------- TBD2 Metric Normalize This Document 9. Security Considerations TBD. 10. References 10.1. Normative References [RFC9350] P. Psenak, Ed., Cisco Systems, Inc., S. Hegde, Juniper Networks, Inc., C. Filsfils, Cisco Systems, Inc., K. Talaulika, Cisco Systems, Inc, A. Gulko, Edward Jones, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, . 10.2. Informational References TBD Gong & Lin, et al. Expires January 07, 2027 [Page 9] Internet-Draft Metric Normalize for IGP Flex-algo July 2026 Authors' Addresses Liyan Gong China Mobile China Email: gongliyan@chinamobile.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Gong & Lin, et al. Expires January 07, 2027 [Page 10]