Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

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 <bwilliam@juniper.net>
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 <robert@raszuk.net>
> *Date: *Saturday, 27 February 2021 at 5:54 PM
> *To: *William Britto A J <bwilliam@juniper.net>
> *Cc: *lsr@ietf.org <lsr@ietf.org>, Rajesh M <mrajesh@juniper.net>,
> Shraddha Hegde <shraddha@juniper.net>, DECRAENE Bruno IMT/OLN <
> bruno.decraene@orange.com>
> *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=
> 40juniper.net@dmarc.ietf.org> 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: *internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Date: *Monday, 22 February 2021 at 10:56 PM
> *To: *Bruno Decraene <bruno.decraene@orange.com>, Rajesh M <
> mrajesh@juniper.net>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <
> shraddha@juniper.net>, William Britto A J <bwilliam@juniper.net>, William
> Britto A J <bwilliam@juniper.net>
> *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
> Lsr@ietf.org
> 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
>