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

peng.shaofu@zte.com.cn Mon, 17 May 2021 02:09 UTC

Return-Path: <peng.shaofu@zte.com.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 6D3013A221F; Sun, 16 May 2021 19:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wT989M2ynQgn; Sun, 16 May 2021 19:09:47 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7573A221D; Sun, 16 May 2021 19:09:46 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id B8FD69694C27DFF1AD2B; Mon, 17 May 2021 10:09:41 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 88CDDE9D41D162DABADA; Mon, 17 May 2021 10:09:41 +0800 (CST)
Received: from njxapp01.zte.com.cn ([10.41.132.200]) by mse-fl1.zte.com.cn with SMTP id 14H29amA052633; Mon, 17 May 2021 10:09:36 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid201; Mon, 17 May 2021 10:09:36 +0800 (CST)
Date: Mon, 17 May 2021 10:09:36 +0800
X-Zmail-TransId: 2afc60a1d0608b57a9ee
X-Mailer: Zmail v1.0
Message-ID: <202105171009360258167@zte.com.cn>
In-Reply-To: <CY4PR05MB3576089A08AF8EF2EA1BD97ED5519@CY4PR05MB3576.namprd05.prod.outlook.com>
References: 0BAE6DBA-04A3-4A3A-A1E3-14EFAA0FBE68@cisco.com, 202105131528535473925@zte.com.cn, 202105131534352994184@zte.com.cn, CY4PR05MB3576089A08AF8EF2EA1BD97ED5519@CY4PR05MB3576.namprd05.prod.outlook.com
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: shraddha@juniper.net
Cc: acee=40cisco.com@dmarc.ietf.org, lsr@ietf.org, draft-hegde-lsr-flex-algo-bw-con@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 14H29amA052633
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/9_kgzLX8WsCSQo1OsEsHktrRH3k>
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: Mon, 17 May 2021 02:09:52 -0000

Hi Shraddha,






Thanks for your rely.


So it seems that the scheme may lead to the selection of links with less bandwidth. To address this point, the method as you described to assign more bandwidth to high bandwidth links seems not always possible, e.g, adding more fiber ?


Can this point can be addressed by combination of bandwidth attribute of link and other metric that is cumulative ? IMO, bandwidth is not cumulative.






Regards


PSF






原始邮件



发件人:ShraddhaHegde
收件人:彭少富10053815;
抄送人:acee=40cisco.com@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-con@ietf.org;
日 期 :2021年05月13日 21:01
主 题 :RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02




Hi Peng shaofu,


 


As per the draft, if automatic metric calculation with reference bandwidth method is used to calculate the metric


Then as per your example s->D path will be chosen since metric is 10.


Lets say operator wants to choose S->X1->X2-àX10->D path then operator can manually assign higher bandwidth


Metric on S->D link which will ensure S->D path is not the least cost path.


 


Rgds


Shraddha


 


 


Juniper Business Use Only



From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn> 
 Sent: Thursday, May 13, 2021 1:05 PM
 To: peng.shaofu@zte.com.cn
 Cc: acee=40cisco.com@dmarc.ietf.org; lsr@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




 


[External Email. Be cautious of content]


 

 

Sorry for spelling mistakens in the previous email.

updated text:

 


 

Hi WG,

 

I have a little doubt about the scheme described in this document.

See the following example:

 

S ---- X1 ----- X2 ---- ... ... ----- X10 ----- D

    \----------------------------------------------/

 

Suppose the links in S---X1---X2...---D have the same bandwidth  10G, and the link S-D has bandwidth 1G.

Suppose that we select "reference bandwidth = 100G", then, 

each link  in S---X1---X2...---D will have the same bandwidth-metric  10 (i.e., 100/10)

link S-D will have a bandwidth-metric 100 (i.e., 100/1)

 

So flex-algo path from S to D based on bandwidth-metric will be S-D, not S---X1---X2...---D, because the later has a large cumulative bandwitdh-metric (i.e., 11*10).

But our expect path should not be S-D, but S---X1---X2...---D, as it has large bandwidth.

Do I misunderstand anything ?

 

Regards,

PSF

 

 

 

 






发件人:AceeLindem(acee)



收件人:lsr@ietf.org;



抄送人:draft-hegde-lsr-flex-algo-bw-con@ietf.org;



日 期 :2021年05月13日 05:49



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




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


Esteemed Members of the LSR WG,


 


This begins a 2 week WG adoption call for the following draft:


 


     https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/    


 


Please indicate your support or objection by May 27th, 2021.


 


Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.


 


Thanks,


Chris and Acee