Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[[e-mail]]

Dear Acee, Tony,






Thanks!

Tony's explanation gives the essential use of bandwidth-metric. My previous understanding is mainly based on the problem to be solved in another draft https://datatracker.ietf.org/doc/draft-lp-lsr-fa-bandwidth/. Sorry to insert an advertisement in this adoption.  : ) 

In draft-lp, the path will be selected strictly according to the actual bandwidth capacity of the link. The main issue is that the computation method  is not optimal, just a basic expression of this idea. 

Just for the expected requirement "to select a path with the maximum link bandwidth from the source node to the destination node", it seems that one scheme try to satisfy most of scenarios, and the other try to satisfy 100%.




Regards


PSF











原始邮件



发件人：AceeLindem(acee)
收件人：Tony Li;彭少富10053815;
抄送人：[e-mail];[e-mail];[e-mail];
日 期 ：2021年05月20日 18:22
主 题 ：Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02




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 <[e-mail]> on behalf of Tony Li <[e-mail]>
 Date: Thursday, May 20, 2021 at 12:20 AM
 To: "[e-mail]" <[e-mail]>
 Cc: "[e-mail]" <[e-mail]>, Acee Lindem <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
 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, [e-mail] 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