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

Aijun Wang <> Sat, 22 May 2021 00:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A61F83A0FCD; Fri, 21 May 2021 17:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Eu3hkmfZnRV; Fri, 21 May 2021 17:18:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28AB73A0FCA; Fri, 21 May 2021 17:18:48 -0700 (PDT)
Received: from [] (unknown []) by (Hmail) with ESMTPA id DCC821C00B9; Sat, 22 May 2021 08:18:43 +0800 (CST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Aijun Wang <>
Mime-Version: 1.0 (1.0)
Date: Sat, 22 May 2021 08:18:41 +0800
Message-Id: <>
References: <>
Cc: lsr <>,, "Acee Lindem (acee)" <>
In-Reply-To: <>
To: Tony Li <>
X-Mailer: iPhone Mail (18D70)
X-HM-Tid: 0a7991704243d993kuwsdcc821c00b9
Archived-At: <>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 22 May 2021 00:18:55 -0000

Hi, Tony:

Aijun Wang
China Telecom

> On May 22, 2021, at 07:35, Tony Li <> 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