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

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 21 May 2021 22:59 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47643A0A00; Fri, 21 May 2021 15:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs73MXDqlDuR; Fri, 21 May 2021 15:59:55 -0700 (PDT)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150CD3A09FC; Fri, 21 May 2021 15:59:55 -0700 (PDT)
Received: from [240.0.0.1] (unknown [109.166.36.197]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id D0B1D1C009A; Sat, 22 May 2021 06:59:51 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-19758D86-790E-4277-BBC8-0C084A758A2E
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Sat, 22 May 2021 06:59:47 +0800
Message-Id: <61AE2E53-69AA-44A8-8DBE-C82A60F34B1A@tsinghua.org.cn>
References: <7CF141B6-3229-4F38-B8FA-626C593F1E1C@tony.li>
Cc: lsr <lsr@ietf.org>, draft-hegde-lsr-flex-algo-bw-con@ietf.org, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
In-Reply-To: <7CF141B6-3229-4F38-B8FA-626C593F1E1C@tony.li>
To: Tony Li <tony.li@tony.li>
X-Mailer: iPhone Mail (18D70)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGhkYTlZLGB9MTR9IQh9KTB5VEwETFhoSFyQUDg9ZV1kWGg8SFR0UWUFZT0tIVU pKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OAw6PCo6CT8cKy0QLytKLA0I Fj8aCR9VSlVKTUlKTUhMQkJJSENKVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS0JVSk1NVUhNVUpCTFlXWQgBWUFKQ0hOQzcG
X-HM-Tid: 0a7991280db1d993kuwsd0b1d1c009a
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/svdAdEMOw3myQohlfeCAGWOSXmA>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2021 22:59:58 -0000

Hi, Tony:

Aijun Wang
China Telecom

> On May 22, 2021, at 06:40, Tony Li <tony.li@tony.li> wrote:
> 
> 
> 
> Hi Aijun,
> 
>>>> With the introduce of additional constraint information, the problem described in “Introduction” part(Section 1) can be solved.
>>> 
>>> 
>>> Please say more.  Claims without rationale are not reasoning.
>> [WAJ]  The introduction part talks mainly how to divert the elephant traffic away from the low bandwidth link. This can be achieved via the introduction of additional constraints information for Flex-ALGO
> 
> 
> Which is exactly what we’ve done: added bandwidth constraints. 

[WAJ] Yes, I agree with this.

> 
> 
>>>> The usage of bandwidth metric in large network is not feasible. 
>>> 
>> [WAJ] The main reason is that bandwidth metric is not cumulative.  
> 
> 
> ??? What are you seeing that implies that?  That is not my understanding at all.

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

> 
> 
>>>> And, would you like to explain more for the following statements(in Section 4.1.1.2)
>>>> “In the interface group mode, every node MUST identify the set of
>>>>    parallel links between a pair of nodes based on IGP link
>>>>    advertisements and MUST consider cumulative bandwidth of the parallel
>>>>    links while arriving at the metric of each link.”
>>>> based on example described in Figure 7? 
>>> 
>>> 
>>> The paragraph immediately above explains exactly that. B->C has two parallel 10Gbps links, so it should be considered to be 20Gbps.
>>> 
>>>  
>>>> How the cumulative bandwidth will be used to achieve the result that traffic from B to D will prefer B-C-F-D, not B-E-D? 
>>> 
>>> 
>>> B-C-F-D is 20Gbps. B-E-D is 10Gbps.
>> 
>> [WAJ] OK, let’s add two nodes between node B and C, say they are node M and N. They have also two parallel links to B and C respectively. The two possible path from B to D will be:
>> Path 1: B-M-N-C-F-D
>> Path 2: B-E-D
>> If the “reference bandwidth” is 100G, then metric for each link in B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1 “B—N-C-F-D” will be 25, right?
>> The metric for each link in B-E-D will be 10, the cumulative metric from B-D for Path 2 will be 20, right?
>> How can you prefer to the high bandwidth path?
> 
> 
> Override the metric on B-E-D to be even higher.

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

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

> 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?
> 
> Tony
> 
> 
>