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:31 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 D578D3A0652; Fri, 21 May 2021 15:31:56 -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 byE35UvjAITY; Fri, 21 May 2021 15:31:52 -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 BF6E83A0553; Fri, 21 May 2021 15:31:51 -0700 (PDT)
Received: from [240.0.0.1] (unknown [109.166.36.197]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 36ABD1C00C6; Sat, 22 May 2021 06:31:49 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-2414404E-97BB-4C07-AF92-DE821088C304
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Sat, 22 May 2021 06:31:45 +0800
Message-Id: <34045D7F-F878-40C8-954B-47A5CF03EE11@tsinghua.org.cn>
References: <F760E1F6-99ED-4BB8-8F2A-271C7855F88C@cisco.com>
Cc: Tony Li <tony.li@tony.li>, lsr <lsr@ietf.org>, draft-hegde-lsr-flex-algo-bw-con@ietf.org
In-Reply-To: <F760E1F6-99ED-4BB8-8F2A-271C7855F88C@cisco.com>
To: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (18D70)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQkMdQlYaHUhLGEtNHhoeGElVEwETFhoSFyQUDg9ZV1kWGg8SFR0UWUFZT0tIVU pKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PjY6GAw5IT8IDS0IATRRLDpP IgNPCS5VSlVKTUlKTUhNSEtCTU1NVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS0JVSk1NVUhNVUpCTFlXWQgBWUFKT0xMSTcG
X-HM-Tid: 0a79910e60ead993kuws36abd1c00c6
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/F0yLxcH-7FpiogUw2ckIFWg7ofo>
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:31:57 -0000

Hi, Acee:
For adoption call of one document, you are counting the number of support votes, not to let the authors solve/explain the disputed part?
My understanding is that the WG Chairs should help to solve the controversial points, or make judgements based on his knowledges.

Aijun Wang
China Telecom

> On May 21, 2021, at 23:38, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org> wrote:
> 
> 
> Hi Tony, Aijun,
>  
> From: Tony Li <tony1athome@gmail.com> on behalf of Tony Li <tony.li@tony.li>
> Date: Friday, May 21, 2021 at 11:29 AM
> To: Aijun Wang <wangaijun@tsinghua.org.cn>
> Cc: Acee Lindem <acee@cisco.com>om>, lsr <lsr@ietf.org>rg>, "draft-hegde-lsr-flex-algo-bw-con@ietf.org" <draft-hegde-lsr-flex-algo-bw-con@ietf.org>
> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
>  
>  
> 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.
>  
> As WG chair, I don’t see that Aijun’s concerns would prevent WG adoption. The draft has plenty of support. The discussion can continue after adoption.
>  
> Thanks,
> Acee
>  
>  
> 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.
> 
> 
>  
> The usage of bandwidth metric in large network is not feasible. 
>  
>  
> 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.
>  
> Tony
>  
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr