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> Wed, 26 May 2021 07:11 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 58B3C3A23D5; Wed, 26 May 2021 00:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 IgPJHwmUTNS0; Wed, 26 May 2021 00:11:28 -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 235383A23DC; Wed, 26 May 2021 00:11:26 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id C0D721C00DB; Wed, 26 May 2021 15:11:22 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Tony Li' <tony.li@tony.li>
Cc: 'lsr' <lsr@ietf.org>, 'Ketan Jivan Talaulikar' <ketant@cisco.com>, "'Acee Lindem (acee)'" <acee=40cisco.com@dmarc.ietf.org>, draft-hegde-lsr-flex-algo-bw-con@ietf.org
References: <0BAE6DBA-04A3-4A3A-A1E3-14EFAA0FBE68@cisco.com> <MW3PR11MB4570FB10A5788FDA3BBA6C91C1269@MW3PR11MB4570.namprd11.prod.outlook.com> <AE6570D7-062E-4F8A-92E8-120FA52D4785@tony.li> <007201d75109$cb3bac00$61b30400$@tsinghua.org.cn> <A804984E-E6A4-4893-AEA7-F0CA5220DAEF@tony.li>
In-Reply-To: <A804984E-E6A4-4893-AEA7-F0CA5220DAEF@tony.li>
Date: Wed, 26 May 2021 15:11:23 +0800
Message-ID: <000a01d751fe$5620c450$02624cf0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01D75241.6444C7A0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGCHewxXNMdyq1O1SgwkvAA6Y4xTwI4yiRDAeQlYygBbjPRVQIBei6nq2NVOWA=
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQ0keTFZJGhgdGEtDTENNSExVEwETFhoSFyQUDg9ZV1kWGg8SFR0UWUFZT0tIVU pKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OD46FRw4KD8JPxk9OAkCMhpC T0xPFBlVSlVKTUlJS0pIS0NISEhPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpPT05LNwY+
X-HM-Tid: 0a79a7837d4ed993kuwsc0d721c00db
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/nd5XON-JXWuJqrs89X92kOHUdZY>
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: Wed, 26 May 2021 07:11:36 -0000

Hi, Tony:

 

From: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of Tony Li
Sent: Wednesday, May 26, 2021 12:31 AM
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: lsr <lsr@ietf.org>; Ketan Jivan Talaulikar <ketant@cisco.com>; Acee Lindem (acee) <acee=40cisco.com@dmarc.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,

 

My suggestion is still not introduce such non-cumulative metric to cumulative based SPF calculation process.

 

Again, what we’re proposing is cumulative.

 

[WAJ] My arguments is that your cumulative proposal (section 4.1.1.1 or 4.1.1.2) can get unexpected result, that is, if there is no manual intervention, the E2E sub-optimal path will be selected. You have also confirmed this in https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/, said as below:

 

“Override the metric on B-E-D to be even higher.

 

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. Hops are still relevant. An operator can adjust the reference bandwidth and add manual metrics to achieve different effects, depending on their precise needs.”

 

The operator must investigate their topology carefully to add necessary manual metric to avoid the unexpected sub-optimal path.  Is it nightmare?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

 

 

Tony