Hi Wiliam, I get yr point on bw. I was not saying to make any changes in the draft on this. I was more hinting that perhaps deployment scenarios could better articulate pros and cons of use of such static bw parameter.
Regarding the delay - Oh so the delay is a dynamic variable here ? I was under the impression that this would be a static cfg based value. Can you clarify ? Thx, R. On Mon, Mar 1, 2021 at 11:16 AM William Britto A J <[email protected]> wrote: > Hi Robert, > > > > Thanks for your comments. > > > > Currently there are customers who deploy separate networks, of which one > could be assigned metrics relative to the interface bandwidths, while other > could be based on other parameters like latency, etc. Flex-Algo which > facilitates different metric-types for SPF, is a very useful feature for > such network consolidation use-cases. We are trying introduce the protocol > constructs to simplify the use of metric based on bandwidth via Flex-Algo. > > > > Any existing tools and techniques used by operators who configure metric > relative to link bandwidth to optimize the network can be used with these > Flex-Algo constructs too. The Flex-Algo bandwidth constraints defined here > can be used to automatically derive a metric based on reference bw vs link > bw; and if required, this can be overridden using the individual link > bandwidth-metric sub-TLV. We will make this clear in the next version. > > > > RFC 8570 support advertising link delay parameters in ISIS. Protocols like > TWAMP support dynamically measuring the delay. Whether egress queueing > delay is included in the link delay depends on the measuring mechanism. The > Exclude Max Delay sub-TLV introduced in this draft is only meant for > pruning out high latency links from a Flex-Algo, and it is upto the > operator to define the maximum bounds based on the measuring mechanisms > deployed in his network. > > > > Thanks, > > William > > > > *From: *Robert Raszuk <[email protected]> > *Date: *Saturday, 27 February 2021 at 5:54 PM > *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, > > > > I read the draft and have two basic questions. > > > > 1. > > Both bw & delay can be used as defined in the draft to construct new > forwarding topologies. But how practical such topologies would be in the > real life when 40GB links may be heavily occupied with bursty traffic and > 10G links can sit idle ? I suppose you are trying to address the case where > say 12 gbps holographic stream needs to be sent across a network.. But then > I don't think if sending it in a single flow instead of spreading into many > sub-flows and use as much as possible ecmp would not be a better option. > > > > 2. > > Likewise how good is my accumulated link delay value if in between there > are deep buffer network elements and say egress queuing to each link (which > max is unaccounted for in your draft) can significantly alter the end to > end delay ? Have you consider to add MAX_EGRESS_QUEUE_DELAY on a per link > basis (still as static value). So if some traffic is delay sensitive we > will have a much better accuracy not to get into a trap of queuing related > delays. > > > > Thx a lot, > > Robert. > > > > > > On Fri, Feb 26, 2021 at 8:37 AM William Britto A J <bwilliam= > [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!WgwtY1NpSXZkAtkBfmMRfgZABaIBWv534VYF7vvI4eGGuMbmdKMK_VpWFKV2Tba5Qg$> > > > > 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] <[email protected]> > *Date: *Monday, 22 February 2021 at 10:56 PM > *To: *Bruno Decraene <[email protected]>, Rajesh M < > [email protected]>, Rajesh M <[email protected]>, Shraddha Hegde < > [email protected]>, William Britto A J <[email protected]>, William > Britto A J <[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!WgwtY1NpSXZkAtkBfmMRfgZABaIBWv534VYF7vvI4eGGuMbmdKMK_VpWFKXnuJRcew$> > . > > The IETF Secretariat > > > > Juniper Business Use Only > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WgwtY1NpSXZkAtkBfmMRfgZABaIBWv534VYF7vvI4eGGuMbmdKMK_VpWFKV0XHjSNQ$> > > > Juniper Business Use Only >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
