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> Tue, 25 May 2021 02:01 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 C9D083A09D7; Mon, 24 May 2021 19:01:08 -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=unavailable 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 vgg_Vl6FgOuV; Mon, 24 May 2021 19:01:03 -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 7FC573A09C3; Mon, 24 May 2021 19:01:01 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 7960F1C010D; Tue, 25 May 2021 10:00:53 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'Tony Li'" <tony.li@tony.li>, "'Ketan Jivan Talaulikar'" <ketant@cisco.com>
Cc: <lsr@ietf.org>, <draft-hegde-lsr-flex-algo-bw-con@ietf.org>, "'Acee Lindem \(acee\)'" <acee=40cisco.com@dmarc.ietf.org>
References: <0BAE6DBA-04A3-4A3A-A1E3-14EFAA0FBE68@cisco.com> <MW3PR11MB4570FB10A5788FDA3BBA6C91C1269@MW3PR11MB4570.namprd11.prod.outlook.com> <AE6570D7-062E-4F8A-92E8-120FA52D4785@tony.li>
In-Reply-To: <AE6570D7-062E-4F8A-92E8-120FA52D4785@tony.li>
Date: Tue, 25 May 2021 10:00:53 +0800
Message-ID: <007201d75109$cb3bac00$61b30400$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01D7514C.D961D230"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGCHewxXNMdyq1O1SgwkvAA6Y4xTwI4yiRDAeQlYyirfOuXsA==
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQ0xOS1ZLQkpNSENOQkpLQ0NVEwETFhoSFyQUDg9ZV1kWGg8SFR0UWUFZT0tIVU pKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OQg6Myo6PT8WTiIuHxwRTD8S T1EaC0xVSlVKTUlKQktDS05PSkxMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpITE1KNwY+
X-HM-Tid: 0a79a140deafd993kuws7960f1c010d
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/uMNNi2O_GSOmTKPgjIpVXwVDJh0>
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: Tue, 25 May 2021 02:01:09 -0000

Hi, Tony:

7.      The document introduces a new Generic Metric type called Bandwidth metric. I’ve been trying to follow some of the discussion related to this on the mailing list – about it being cumulative or not. I am perhaps somewhat confused by those discussions. The OSPF/ISIS SPT computation has always worked with cumulative link (and prefix) metrics. If the computation for the Generic Metric of this new type b/w is not going to be cumulative (I thought it is – but not very clear anymore), then the document needs to describe the computation algorithm. Is it then hop count based? Perhaps I am missing something very basic here and if so, please point me to the text in the draft.

 

 

I’m sorry if this has been confusing. My understanding is that the metric is cumulative. Others had other expectations.

 

When there are multiple links with the same bandwidth, and thus the same metric, then the total path metric becomes (link metric) * (number of links).

[WAJ] Such cumulative may be problematic in some situations and would need the manual intervention to “override” the automatic calculation “total path metric” to achieve the desired results. (please refer to the example in https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/

The difficulty is to how to find the unexpected paths in complex topology.

 

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

 

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

 

Regards,

Tony