On Sat, Feb 27, 2021 at 2:56 AM Tony Li <[email protected]> wrote: > > 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. >
there is good general, theoretical body of work here that shows what is possible to compute (NP completeness, algorighms, heuristics). short search yields e.g. http://www.csun.edu/~ctoth/Handbook/chap31.pdf https://engineering.purdue.edu/~ece624/Week-9.pdf JSAC '96 Crowcroft is a starting point on additive/multiplicative, other papers even eqarlier called that stuff max/additive, convex/concave (that has to do with linear programming space properties) etc. I'm aware of work going as far back as '92-'93 here. Generally, one max/min & one additive is doable (you need additive to make sure you don't start hamiltonian walks based on a constraint ;-) Mixing up addvitive & mix/min is a fairly poor idea unless one is happy with heurestics that kind of "almost always work" and customer is not looking for hard guarantees but "wishes that maybe granted". > > > 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. > yeah, BW can be made a metric and work, IEEE encoding is simply a funky number and different max/min/additive/multiplicative/any increasing function (whether it has to be stricly monotonic is a more complex discussion). old but very solid stuff for that space https://tools.ietf.org/html/rfc2676 based on even earlier [BP95] J.-Y. Le Boudec and T. Przygienda. A Route Pre-Computation Algorithm for Integrated Services Networks. Journal of Network and Systems Management, 3(4), 1995. [GOW97] R. Guerin, A. Orda, and D. Williams. QoS Routing Mechanisms and OSPF Extensions. In Proceedings of the 2nd IEEE Global Internet Mini-Conference, pages 1903-1908, Phoenix, AZ, November 1997. expired draft-ietf-qosr-framework-04.txt but given graph theory doesn't change things roughly still the same ;-) There is also good body of work on something that quickly interacts with that work, namely k-disjointness. e'thing looking for "fattest pipe" or "shortest-widest" pretty quickly crams all traffic on the same links ;-) unless somehting like RSVP-TE reserves & changes metric. All those things have been implemented and worked in products so we know they work, maybe flex stuff is just a framework now to unify it all a bit. my only small nit on the draft is that the stepping is in practical terms almost always exponewntial so you don't have to encode full value necessarily. the rounding has to adjust to link size as well or is better served as % value. -- tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
