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

[Shraddha Hegde <[e-mail]>]

Tony,

Thanks for the comments.

Pls see inline for replies...


Juniper Business Use Only

-----Original Message-----
From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Wednesday, March 3, 2021 5:30 AM
To: William Britto A J <[e-mail]>
Cc: [e-mail]; Rajesh M <[e-mail]>; Shraddha Hegde <[e-mail]>; DECRAENE Bruno IMT/OLN <[e-mail]>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[External Email. Be cautious of content]


Hi William,


> 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.


In the hopes of inspiring others with better thoughts:

“Flexible Algorithms: Bandwidth Management Part 1”
“Flexible Algorithms: Some Stuff We Forgot”
“Flexible Algorithms: Bandwidth and Delay, Metrics and Constraints”
“Flexible Algorithms: A Few More Bits”

<SH>  “Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints”  looks like a good title


> 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.


And if you agree with a more general metric, maybe a few of those reserved bits could be used as the index for the user defined metric.

<SH> This is a good idea. Its useful to have flexibility in assigning various metrics to the link and be able to find flex-algo SPF paths for those metric types.
We will update the draft.


> 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.


That argument might well apply to all of our other link attributes as well.  Why do we need a separate administrative group for FlexAlgo?  Why do we need a separate set of SRLGs?  I have to confess that we have added a bit of complexity that I don’t think is very valuable.
<SH> Totally agree with you on this. 

 However, what’s done is done and there’s no point in arguing about it now.  
<SH> Arguing about this during working group adoption of such work didn’t help either! 

We should simply strive to be consistent with what’s already in place so that we don’t create even MORE complexity.
<SH> Agree.

> 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.


Thank you, that’s helpful motivation.  Please add something like this to the draft.
<SH> Sure.

Continuing on from there…

7) Section 4. You’ve hidden a big part of what you want to do down here, 9 pages into the document.  You’ve got one whole sentence in the introduction to motivate it.  It deserves a good bit more.
<SH> ok

8) Section 4.2. You write that an implementation "considers cumulative bandwidth of the parallel links while arriving at the metric for the link”. This seems a bit vague.  I think you’re trying to say that in interface group mode the bandwidth of an adjacency is the sum of the bandwidths of the individual links.  Typically today, if we have L3 parallel links they are encoded as separate adjacencies, complete with unique interface addresses.  How does interface group mode work with that? 
<SH> It continues to work the same way. I mean the topological representation does not change. It is going to be represented as multiple parallel 
Adjacencies. How the metric is assigned to these links differs in simple mode and interface group mode. In simple mode, single l3 link bandwidth is taken and metric is derived by using either of two modes of metric derivation (reference bw or staircase bandwidth thresholds). In  interface group mode, cumulative bandwidth of parallel links is used derive the metric (again either ref bw or staircase method can be used) and same metric is assigned to all parallel links.

Does each adjacency advertise the same metric based on the total bandwidth of all of the links?  
<SH> In automatic metric calculation method, each node derives the metric  based on advertised maximum link bandwidth .
In interface group mode,  metric is derived based on cumulative bandwidth of parallel  links and same metric is assigned for all parallel links.
In automatic metric calculation method, metric is not advertised.

In cases where operators do not want to use this automatic metric derivation, they can advertise bandwidth metric.
How this bandwidth  metric is assigned, whether same metric on all parallel links or different metric and actual metric value is all upto the operator.
When bandwidth metric sub-TLV is advertised on a link, simple mode or interface group mode does not come into play for that link. Bandwidth metric advertisement overrides, automatic metric derivation.

The discussion about reference bandwidths and the staircase mapping seems a bit confusing and redundant.  It appears to be orthogonal to the mode, correct? 
<SH> yes. It is orthogonal to the mode.

Why not describe it independently? More proofreading is necessary here.
<SH> agree. Will update in next revision.


9) Section 4.3.1. The reserved byte is wasteful. Your explanation of the round-off bandwidth is unclear.  Are we expecting dynamic bandwidth changes?  If so, that is an entire discussion unto itself.
<SH> yes we are expecting dynamic bandwidth changes. These dynamic bw changes are applicable to L2 bundled links only. When constituent links go up/down link bw width changes and that’s why you have the dynamic changes. Just to reiterate, these dynamic bw changes are not reflecting any path placement or bw utilization etc its is still total link bandwidth. We will add more text for round-off bw and also about bw changes.

10) Section 4.3.1. The reserved byte here is also wasteful.  Your explanation of how to use this is a bit unclear. 
<SH> ok will fix it.

 Are bandwidth ranges allowed to overlap?  I hope not. Is max[1] == min[2]?  I hope so, otherwise there is a gap in the ranges.  If there is a gap, and a link bandwidth falls in the gap, then what do we do?  Assuming that max[i] == min[i+1], then is there a point in carrying both values all of the time? What happens when a bandwidth exceeeds the highest max? Is below the smallest min?
<SH> yes we have scope to optimize the encodings.  We will post an updated encoding with clarifications.

Regards,
Tony