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 <[email protected]>
发送时间: 2025年11月6日 3:06
收件人: Gyan Mishra <[email protected]>
抄送: Peter Psenak <[email protected]>; [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 don't create loops (e.g., do a feasible successor check
as EIGRP does).
Thanks,
Acee
> On Nov 4, 2025, at 11:46PM, Gyan Mishra <[email protected]> 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
<[email protected]> 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]
