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

From: William Britto A J <[email-masked]>
Date: Fri, 26 Feb 2021 07:36:26 +0000

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

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-masked] <[email-masked]>
Date: Monday, 22 February 2021 at 10:56 PM
To: Bruno Decraene <[email-masked]>, Rajesh M <[email-masked]>, Rajesh M <[email-masked]>, Shraddha Hegde <[email-masked]>, William Britto A J <[email-masked]>, William Britto A J <[email-masked]>
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.

The IETF Secretariat

Juniper Business Use Only

---

From: Tony Li <[email-masked]>
Date: Fri, 26 Feb 2021 17:56:35 -0800

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 <bwilliam=[email-masked] <mailto:bwilliam=[email-masked]>> 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>
>  
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> To: Bruno Decraene <[email-masked] <mailto:[email-masked]>>, Rajesh M <[email-masked] <mailto:[email-masked]>>, Rajesh M <[email-masked] <mailto:[email-masked]>>, Shraddha Hegde <[email-masked] <mailto:[email-masked]>>, William Britto A J <[email-masked] <mailto:[email-masked]>>, William Britto A J <[email-masked] <mailto:[email-masked]>>
> 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:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Feb 2021 13:24:19 +0100

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-masked]> 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
>
>
>
> 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.
>
>
>
> *From: [email-masked] <[email-masked]>
> *Date: *Monday, 22 February 2021 at 10:56 PM
> *To: *Bruno Decraene <[email-masked]>, Rajesh M <
> [email-masked]>, Rajesh M <[email-masked]>, Shraddha Hegde <
> [email-masked]>, William Britto A J <[email-masked]>, William
> Britto A J <[email-masked]>
> *Subject: *New Version Notification for
> draft-hegde-lsr-flex-algo-bw-con-00.txt
>
> 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:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 27 Feb 2021 11:10:30 -0500

Hi William & Co-authors

>From first read of the draft it does appear your are trying to apply RSVP
TE PCALC path and reserve message link attributes constraints such as
concept of affinity bits to exclude low bandwidth or delay of individual
links without taking into account all of what RSVP TE is reserving of
bandwidth in the end to end path with the Path and Reserve message.  As
mentioned Looking at individual links will not provide the end to end path
view or bandwidth requirements for the entire path to be reserved as
accomplished by RSVP TE.

As Tony and Robert have mentioned I agree this is a good first step but
does need more refinement to make useful.

Kind Regards

Gyan

On Sat, Feb 27, 2021 at 7:24 AM Robert Raszuk <[email-masked]> wrote:

>> [email-masked]>, William Britto A J <[email-masked]>,
>> William Britto A J <[email-masked]>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: William Britto A J <[email-masked]>
Date: Sat, 27 Feb 2021 18:22:00 +0000

Hi Tony,

Thank you for your comments. Please find replies inline.

From: Tony Li <[email-masked]> on behalf of Tony Li <[email-masked]>
Date: Saturday, 27 February 2021 at 7:26 AM
To: William Britto A J <[email-masked]>
Cc: [email-masked] <[email-masked]>, Rajesh M <[email-masked]>, Shraddha Hegde <[email-masked]>, DECRAENE Bruno IMT/OLN <[email-masked]>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
[External Email. Be cautious of content]

Hi William & co-authors,

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 <bwilliam=[email-masked]<mailto:bwilliam=[email-masked]>> 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$>

Thanks,
William

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Date: Monday, 22 February 2021 at 10:56 PM
To: Bruno Decraene <[email-masked]<mailto:[email-masked]>>, Rajesh M <[email-masked]<mailto:[email-masked]>>, Rajesh M <[email-masked]<mailto:[email-masked]>>, Shraddha Hegde <[email-masked]<mailto:[email-masked]>>, William Britto A J <[email-masked]<mailto:[email-masked]>>, William Britto A J <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-00.txt
[External Email. Be cautious of content]

Abstract:

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!UtNPytCuEZtqnycoTXAZws2cmdypbPSgYaTM8G0FTw3BnJnDBXqI-YJwYozBwudP8w$>