Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Tony Li <[e-mail]>]

Hi Aijun,

>>> [WAJ] The operator must plan carefully for the metric assignment accordingly to their specific topology to let the traffic pass the necessary high bandwidth path as done in the following example.
>> 
>> 
>> That’s only if they have no concerns about the hop count.
> [WAJ] Hop count have little influence on the application performance. Nearly every router can forward traffic in line speed as declared by every device vendor?


Yes, but hop count has a significant impact on the bits * miles/km product that represents ISP cost.


>> Previous experience with other routing protocols that have a bandwidth based metric and do compute a cumulative metric does show that it is indeed possible to run many large networks this way and get
>> acceptable results.
> [WAJ] We prefer to the solution that can get determined results under various scenarios, not just fit part of them.


There are no solutions that fit all scenarios. Otherwise, we would not have traffic engineering and interesting path computation.


>>>> Hops are still relevant. An operator can adjust the reference bandwidth and add manual metrics to achieve different effects, depending on their precise needs.
>>> [WAJ] Is it more simple and easy to get determined results via setting the link metric based on the additive information?
>> 
>> 
>> I don’t understand what you’re asking.
> [WAJ] For example, if we set the metric based on the distance between two nodes, we can certainly say that the best path will have the shortest E2E distance; if we set the metric based on the link delay, we can assure the traffic will be forwarded in least delay path. 
> But if we set the metric based on the link bandwidth, I think you cannot assure the E2E traffic will always pass the expected high bandwidth path. Is it right?



Not per the current formulation, but then that’s not what we’re after.



>> Please remember that we are not trying to solve all problems for all people. We are trying to provide tools so that operators can drive traffic automatically in the way that they want. We’re trying to provide a variety of tools, with appropriate nerd knobs so that we can do useful traffic engineering without resorting to the very big hammer of having a centralized controller compute everything and program the entire network.
> 
> [WAJ] My observation is that the operator will need more judgment works in their centralized controller to utilize such tools, especially in some complex topology (because you need even manual intervention in some common topology scenarios)
> I am also prefer to more automatic work been done in distributed manner. But shouldn’t such work/tools get determined expected results automatically even in some simple topology?



As I alluded to previously, bandwidth based metrics that have some respect for hop count have been found to be automatically helpful in MANY, MANY, MANY networks in previous routing protocols.  Perhaps one of my competitors would be willing to say the name that I am unable to mention.

Tony