Hi Tony, Thank you for your comments. Please find replies inline.
From: Tony Li <[email protected]> on behalf of Tony Li <[email protected]> Date: Saturday, 27 February 2021 at 7:26 AM To: William Britto A J <[email protected]> Cc: [email protected] <[email protected]>, Rajesh M <[email protected]>, Shraddha Hegde <[email protected]>, DECRAENE Bruno IMT/OLN <[email protected]> Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints [External Email. Be cautious of content] Hi William & co-authors, Thank you for your contribution. It’s definitely interesting. As bandwidth management is one area where FlexAlgo lags legacy traffic engineering, this is definitely one small step in the right direction. But I have many comments… 1) I’ll start with the title: there is MUCH more here than bandwidth constraints. Perhaps this should be generalized somehow? Sorry, I don’t have a constructive suggestion. [William] Agree. We are introducing few ‘definitions’ for a bandwidth based Flex-Algo, along with couple of link constraints which can be used for any type of flex-algo. Any suggestions are welcome. 2) Section 2: I concur that bandwidth is an important consideration in path computation. At a first reading, it is not at all clear to me that it is optimal to somehow transmogrify things into a metric. Why not simply deal with the bandwidth directly? I did (eventually) realize that you did this because you want SPF to somehow select the path with the minimum product of (# links) * bandwidth. I think you need to be explicit about this motivation and also mention that traditional SPF is not set up to deal with a floating point metric. Note that a bandwidth metric is STILL somewhat counter-intuitive to me, as I would expect that you’d mostly want to route things along the highest bandwidth paths, not the lowest ones. More motivation behind the bandwidth metric would be most welcome. [William] We will try to address this in the next version. 3) Section 2.1: To be consistent with the rest of FlexAlgo, shouldn’t this be advertised as part of the Application Specific Link Attributes? [William] Agree. Will add relevant text clarifying the same. 4) Sectiion 2.1: Why are there two octets reserved in this sub-TLV? If you’re hoping for alignment within an IS-IS LSP, you’ve already lost. Nothing in IS-IS is aligned. [William] Apologies. This was an error in the figure. Intention was one octet for Reserved/future flags, hence the Length of 5 octets. Will correct this in the next version. 5) Section 3.1.1: Here you have chosen to refer directly to subTLV 9. To be consistent with the rest of FlexAlgo, should we use subTLV 9 inside of the Application Specific Link Attribute subTLV. [William] Shouldn’t there be only one Max link BW per link applicable for all applications? However, agree that it could still be in a common ASLA. Will add relevant text to clarify this. Also, I believe that it would be more clear to call this the “Minimum Bandwidth subTLV”. The word ‘exclude’ doesn’t seem to add value here and every word makes our acronyms harder. [William] The intent was to be explicit (in the name) that this is an ‘exclude constraint’. Eg: Consider a FAD which has the above mentioned sub-tlv as a constraint along with some admin-group constraints. If a link has a Max Link BW which is greater that the Min BW constraint defined, that alone won’t qualify this link to be part of that Flex-Algo. IOW, this is not a minimum bw constraint to include a link that satisfies the requirement into Flex-Algo, but rather to exclude a link that doesn’t meet the criteria. Having said that, if its more clear without the ‘explicit’ in the name, we can do away with it. We are planning to add a section in the next version of this draft as an extension to section 13 – “Calculation of Flexible Algorithm Paths” of [I-D.ietf-lsr-flex-algo<https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00#ref-I-D.ietf-lsr-flex-algo>]. Will clarify this there. 6) Section 3.1.2: I’m unclear on the utility of this. I can understand optimizing for path delay against the path metric. I can even understand putting an upper bound on the total path delay. I don’t understand why a bound on an individual link delay is important. If my path delay budget is 100ms, then does it matter if it is exceeded in one hop or ten? Could you please provide more motivation here? Also, wouldn’t a FlexAlgo system be advertising the link delay in the Application Specific Link Attributes subTLV? [William] This constraint could be useful in a Flex-Algo whose Metric-type is anything but Link-delay. Here, Link-delay doesn’t influence the ‘cost’ of a link in that Flex-Algo, but can be used to prune out certain links with very high delay from that Flex-Algo. I’ll stop here for now, but I promise you more comments are still to come. [William] Thanks. Looking forward to it. Regards, Tony On Feb 25, 2021, at 11:36 PM, William Britto A J <[email protected]<mailto:[email protected]>> wrote: All, We would like to draw your attention to a new ID: https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!UtNPytCuEZtqnycoTXAZws2cmdypbPSgYaTM8G0FTw3BnJnDBXqI-YJwYoyG5Heq8Q$> The draft talks about introducing link bandwidth related constraints in Flex-Algorithm which can be used to define a Flex-Algorithm based on bandwidth based metric. Please review. Any questions and comments are welcome. Thanks, William From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Monday, 22 February 2021 at 10:56 PM To: Bruno Decraene <[email protected]<mailto:[email protected]>>, Rajesh M <[email protected]<mailto:[email protected]>>, Rajesh M <[email protected]<mailto:[email protected]>>, Shraddha Hegde <[email protected]<mailto:[email protected]>>, William Britto A J <[email protected]<mailto:[email protected]>>, William Britto A J <[email protected]<mailto:[email protected]>> Subject: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-00.txt [External Email. Be cautious of content] A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt has been successfully submitted by Shraddha Hegde and posted to the IETF repository. Name: draft-hegde-lsr-flex-algo-bw-con Revision: 00 Title: Flexible Algorithms Bandwidth Constraints Document date: 2021-02-22 Group: Individual Submission Pages: 21 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$> Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$> Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$> Htmlized: https://urldefense.com/v3/__https://tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$> Abstract: Many networks configure the link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms provides mechanisms to create constraint based paths in IGP. This draft documents a set of bandwidth related constraints to be used in Flexible Algorithms. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<https://urldefense.com/v3/__http:/tools.ietf.org/__;!!NEt6yMaO-gk!UtNPytCuEZtqnycoTXAZws2cmdypbPSgYaTM8G0FTw3BnJnDBXqI-YJwYoxRR9xeDg$>. The IETF Secretariat Juniper Business Use Only _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!UtNPytCuEZtqnycoTXAZws2cmdypbPSgYaTM8G0FTw3BnJnDBXqI-YJwYozBwudP8w$> Juniper Business Use Only
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
