Speaking as WG member: I agree with Tony.
Furthermore, the extensions in the draft provide mechanisms to constraint bandwidth beyond your concern that bandwidth be used as a cumulative metric. I support WG adoption. Thanks, Acee From: Tony Li <tony1ath...@gmail.com> on behalf of Tony Li <tony...@tony.li> Date: Thursday, May 20, 2021 at 12:20 AM To: "peng.sha...@zte.com.cn" <peng.sha...@zte.com.cn> Cc: "shrad...@juniper.net" <shrad...@juniper.net>, Acee Lindem <a...@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, "draft-hegde-lsr-flex-algo-bw-...@ietf.org" <draft-hegde-lsr-flex-algo-bw-...@ietf.org> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02 Hi Peng Shaofu, On May 19, 2021, at 6:55 PM, peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn> wrote: Let's go back to the bandwidth-metric related to bandwidth capability. My worry is that bandwidth-metric (whether it is automatically calculated or manually configured) is not cumulative in nature, which is different from IGP default metric/TE metric/delay metric, so that SPF based on bandwidth-metric may get an unexpected path (see the example of the original mail). Can more text be added in the draft to describe why this can work ? The whole point of the bandwidth metric (and indeed, of all of FlexAlgo) is to get a different path computation result than what we might get with the standard IGP metric. What it will do in any given topology is highly dependent on the topology, as you’ve seen. It may or may not ‘work’ by whatever definition you have in mind. However, what matters is what the network operator is trying to achieve. It doesn’t have to work for every topology or every purpose. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
