Metric Normalize for IGP Flex-algo
draft-gl-lsr-metric-normalize-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Liyan Gong , Changwang Lin | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gl-lsr-metric-normalize-01
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, <https://www.rfc-editor.org/info/rfc9350>.
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]