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

[Tony Li <[e-mail]>]

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”

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


> 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. However, what’s done is done and there’s no point in arguing about it now.  We should simply strive to be consistent with what’s already in place so that we don’t create even MORE complexity.

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

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.

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? Does each adjacency advertise the same metric based on the total bandwidth of all of the links?  The discussion about reference bandwidths and the staircase mapping seems a bit confusing and redundant.  It appears to be orthogonal to the mode, correct? Why not describe it independently? More proofreading is necessary here.


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.

10) Section 4.3.1. The reserved byte here is also wasteful.  Your explanation of how to use this is a bit unclear.  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?

Regards,
Tony