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

[Aijun Wang <[e-mail]>]

Hi, Tony:

Aijun Wang
China Telecom

> On May 22, 2021, at 07:35, Tony Li <[e-mail]> wrote:
> 
> 
> 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?
> 
> 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.

> 
> 
>> [WAJ] If such work must be done manually, it certainly weaken the necessary of the automatic metric calculations based on link bandwidth, also the introduction of bandwidth metric.
> 
> 
> In many cases, that’s probably not necessary.
> 
> 
>>> The point of the bandwidth metric (at least in this incarnation) is not to make hop count irrelevant. It is to set the metrics relative to the bandwidth so that traffic skews towards higher bandwidths.
>> 
>> [WAJ] This can be done via the “bandwidth constraints sub TLV” that is introduced in this document.
> 
> 
> No, that alone would exclude the hop count, resulting in a different 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?
> 
> 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?

> 
> Tonny
> 
>