Dear Tony,
Thank you for your comments — especially the reminder that "the IGP is not a dump truck." We fully agree. One question we are still thinking about is whether normalization parameters should be treated as node-specific configuration or as FA-level computation policy. We tend to view them as the latter. They define the granularity of metric computation for a given Flex-Algo — i.e., how finely or coarsely the algorithm should treat metric values when computing paths. For example: - FA 100 may use a fine-grained step (e.g., 2us) to preserve small delay differences for ultra-low-latency optimization. - FA 200 may use a coarse-grained step (e.g., 20us) to maximize ECMP bundling. In our view，existing mechanisms (CLI or otherwise) cannot easily support such per-FA, per-Metric-Type policies in a coordinated way — especially when different FAs have different optimization goals. Since FAD is where we define the computation rules for an algorithm (Metric-Type, constraints, etc.), it seems natural to include the normalization granularity there as well. We would like to share our current thinking with the WG and are very open to further discussions. Thanks again for your feedback. Best Regards, Liyan ----邮件原文---- 发件人：Tony Li <[email protected]>收件人：Liyan Gong <[email protected]>抄 送: Peter Psenak <[email protected]>,Acee Lindem <[email protected]>,Gyan Mishra <[email protected]>,lsr <[email protected]>发送时间：2026-07-20 21:13:49主题：Re: [Lsr] Re: draft-gl-lsr-metric-normalize/Hi Liyan,Thank you for sharing your slides. I concur with the previous discussions. I do see the value in binning delay values so that they can be considered for ECMP. However, I also see that if this is in effect, it can be completely and accurately done by the advertiser. As the IGP is not a dump truck, the less information that we propagate, the better, and it would seem like that the additional parameters you suggest need not be in the IGP. Regards, Tony On Mon, Jul 20, 2026 at 12:15PM Liyan Gong - gongliyan at chinamobile.com <[email protected]> wrote: Dear Peter, Acee, Gyan, and All, Thank you again for your valuable feedback on our draft, both on the list and offline. Due to time constraints at this IETF meeting, we did not have the opportunity to present the slides we had prepared. Since we had planned to use that slot for further discussion, we would now like to share the slides with the wider list for reference: [https://datatracker.ietf.org/meeting/126/materials/slides-126-lsr-12-metric-normalize-for-igp-flex-algo-00] These slides summarize our current understanding of the comments received so far and provide a brief overview of the use cases we are trying to address. We hope it will help us better understand each other. We remain open to further discussion and are happy to adjust our proposal based on WG consensus. Your continued guidance is much appreciated. Best Regards, Liyan ----邮件原文----发件人：Peter Psenak <[email protected]>收件人：Liyan Gong <[email protected]>,Acee Lindem <[email protected]>,Gyan Mishra <[email protected]>,lsr <[email protected]>抄 送: (无)发送时间：2026-07-07 18:06:43主题：Re: [Lsr] draft-gl-lsr-metric-normalize/ Liyan, On 07/07/2026 10:44, Liyan Gong wrote: Dear All, Thank you very much for the constructive feedback. We apologize for the delayed response. We took some time to carefully rethink our proposal and align it with the existing architecture. After revisiting the Flex-Algo architecture (RFC 9350) and related work (RFC 9843), we realized that the core question is not only about whether normalization is useful,but also about where the normalization logic should be defined and applied. We tried to reason from the layered design of Flex-Algo: - Link Layer: Links advertise only their intrinsic, raw properties (IGP metric, delay, loss, bandwidth). They should not be aware of, or responsible for, any per-FA normalization logic. - FAD Layer: The FAD defines the calculation rules for a given FA — which Metric-Type to use, what constraints to apply, and how paths should be computed. We view metric normalization parameters (metric-step and metric-offset) as calculation policy at the FA level, not as link configuration. Different FAs may have different optimization goals and thus different normalization needs. FAD was defined to synchronize the path calculation parameters. Metric value is a local parameter, not subject to network wide synchronization. Any metric adjustment, normalization or any other manipulation is a local matter that can be done differently on every node, So I disagree with your point of view. thanks, Peter We have also revisited RFC 9843, which extends Flex-Algo to support bandwidth-based metric calculation. We see this as a helpful precedent: parameters like Reference Bandwidth are carried in the FAD to define how metrics are calculated. Our proposal follows the same pattern, extending this capability to other metric types such as delay and loss. Based on this reasoning, we have submitted an updated version (-01) of the draft. We fully understand that the WG may still have reservations about this approach, and we are genuinely open to further guidance. If the WG feels it would be helpful, we would respectfully request an opportunity to present this updated version at the upcoming IETF meeting. Thank you again for your time and feedback and We look forward to your thoughts. Best Regards, Liyan(on behalf of the co-authors) ----邮件原文---- 发件人：Acee Lindem <[email protected]> 收件人：Peter Psenak <[email protected]> 抄 送: Liyan Gong <[email protected]>,Gyan Mishra <[email protected]>,lsr <[email protected]> 发送时间：2025-11-08 23:27:59 主题：Re: [Lsr] draft-gl-lsr-metric-normalize/ Speaking as WG member: I agree with Peter and have a couple additional concerns. 1. If metric normalization is to be performed in the IGP domain, the LSA/LSP originator should do it rather than having everyone else in the domain do it for the originator39s metrics. 2. The stated goal is to compute more ECMP paths. Did you consider that some vendors have implemented UCMP (Unequal Cost MultiPath)? Thanks, Acee > On Nov 6, 2025, at 8:16AM, Peter Psenak wrote: > > Liyan, > On 06/11/2025 10:40, Liyan Gong wrote: >> Hi All, >> hank you for your valuable comments. >> To ensure we are fully aligned, we would like to further clarify the considerations behind our proposal. >> Please feel free to correct us if we have misunderstood any aspect of your suggestion. >> In designing our approach, we focused on addressing two key aspects: >> 1. **Parameter Consistency**: Parameters such as metric-step and metric-offset need to be consistent across the network. We observed that any inconsistency in static configuration could lead to incorrect normalized metrics, which might in turn affect path selection. > there is no need for consistency of these parameters across the network. > If the configuration consistency is the problem you trying to address, there are existing tools for that. >> 2. **Parameter Optimization**: In dynamic network environments, these parameters may need to be tuned. We think that relying solely on manual reconfiguration in such cases could not only be operationally costly and prone to errors, but also slow down routing convergence, potentially extending periods of network instability. > similarly, FAD is not a configuration tool, there are existing tools for that. > thanks, > Peter > >> These considerations motivated our proposal, which draws inspiration from the established concept of automatic metric calculation — an approach that addresses similar needs. We believe a protocol-based extension could be a suitable way to resolve these issues while staying consistent with existing mechanisms. >> We welcome further discussion. >> >> Best Regards, >> Liyan >> >> -----邮件原件----- >> 发件人: Acee Lindem >> 发送时间: 2025年11月6日 3:06 >> 收件人: Gyan Mishra >> 抄送: Peter Psenak [email protected] >> 主题: [Lsr] Re: draft-gl-lsr-metric-normalize/ >> >> Speaking as WG Member: >> >> Speaking as WG member, I agree with Peter as well. >> >> The additional alternative to local metric normalization is to do UCMP (Unequal Cost Mulltipath) route installation which is also a local behavior. >> Here is one example: >> >> https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/routing/79x/b-routing-cg-ncs5500-79x/implementing-ucmp.html >> >> You do have assure you don39t create loops (e.g., do a feasible successor check as EIGRP does). >> >> >> Thanks, >> Acee >> >>> On Nov 4, 2025, at 11:46PM, Gyan Mishra wrote: >>> >>> >>> I agree with Peter that this draft is unnecessary. >>> >>> Delay metric normalization is common feature implemented by most all SR vendors to circumvent sub optimal undesired routing where ECMP exists or TI-LFA backup path is programmed. A single uS differential in ECMP links can break ECMP as well as TI-LFA. >>> >>> This is all local implementation specific and does not require any standardization. >>> >>> >>> Thanks >>> >>> Gyan >>> >>> >>> >>> On Tue, Nov 4, 2025 at 10:49AM Peter Psenak wrote: >>> Hi, >>> here are my comments on the draft: >>> 1. Normalization of the measured latency, or any other PM related value, is a local behavior on the router. It should really be viewed as a part of the measurement procedure. The measured value is normalized before it is advertised. >>> 2. It is not functionally required for normalization to be used, nor for its logic/parameters to be synchronized across all routers in the network. >>> 3. Felx-algo definition (FAD) is not meant to be used as a management mechanism for distribution of the configuration parameters. There are exiting provisioning tools available for that. >>> To summarize, I find the proposals in the draft to be both unnecessary as well as undesirable. >>> thanks, >>> Peter >>> >>> _______________________________________________ >>> Lsr mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> _______________________________________________ >>> Lsr mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >> > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
