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. 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. 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? 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. 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. 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. 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? I’ll stop here for now, but I promise you more comments are still to come. 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://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00> > > 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 > <http://tools.ietf.org/>. > > The IETF Secretariat > > > > Juniper Business Use Only > > _______________________________________________ > Lsr mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr > <https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
