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:22 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 439F83A003F; Fri, 21 May 2021 15:22:05 -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 aKsF75jKLLPd; Fri, 21 May 2021 15:22:00 -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 608033A003D; Fri, 21 May 2021 15:21:59 -0700 (PDT)
Received: from [240.0.0.1] (unknown [109.166.36.197]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 726B31C00BC; Sat, 22 May 2021 06:21:56 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-4E0080FB-C828-40A6-B011-0BC139305791"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Sat, 22 May 2021 06:21:52 +0800
Message-Id: <60F81914-2470-4CD4-976B-98893D99BADE@tsinghua.org.cn>
References: <B7C71A4C-4BAC-441D-9FE6-88AF25A16DA3@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: <B7C71A4C-4BAC-441D-9FE6-88AF25A16DA3@tony.li>
To: Tony Li <tony.li@tony.li>
X-Mailer: iPhone Mail (18D70)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQhkfSVZNQh1LHkhKTEJLGE5VEwETFhoSFyQUDg9ZV1kWGg8SFR0UWUFZT0tIVU pKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PTY6FBw*Tz8LPy02PzYILDoY GS1PFAFVSlVKTUlKTUhOTEpNQ0JMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS0JVSk1NVUhNVUpCTFlXWQgBWUFKSENNTDcG
X-HM-Tid: 0a7991055576d993kuws726b31c00bc
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/NOB5sQTEHblxMWyH6D6Zm9Et_sE>
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:22:06 -0000

Hi, Tony:

Aijun Wang
China Telecom

> On May 21, 2021, at 23:29, Tony Li <tony.li@tony.li> wrote:
> 
> 
> 
> Hi Aijun,
> 
>> I support the adoption of the “FAD constraint sub-TLV” part(Section 3),  but not support the introduce of  “Bandwidth Metric Advertisement” part (Section 4) and other related parts.
> 
> 
> As I understand it, we don’t get a line item veto, so I don’t know how the chairs will take this.

[WAJ] The reasonable solution is to take out of the controversial part from the adopted document.

> 
> 
>> 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.
> 
>  
>> The usage of bandwidth metric in large network is not feasible. 
> 
[WAJ] The main reason is that bandwidth metric is not cumulative.  
> 
> Ditto.
> 
> 
>> 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?


> 
> Tony
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr