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 07:19 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 C33453A2B45; Mon, 17 May 2021 00:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.794
X-Spam-Level:
X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=no 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 fAiY6Nab_B7S; Mon, 17 May 2021 00:19:26 -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 9EFBE3A2B30; Mon, 17 May 2021 00:19:25 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 9E25E770EB326441F7ED; Mon, 17 May 2021 15:19:20 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 7BBAFDA65C030AC6CB3C; Mon, 17 May 2021 15:19:20 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl1.zte.com.cn with SMTP id 14H7JFRa043511; Mon, 17 May 2021 15:19:15 +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 15:19:15 +0800 (CST)
Date: Mon, 17 May 2021 15:19:15 +0800
X-Zmail-TransId: 2afc60a218f31c0be0b7
X-Mailer: Zmail v1.0
Message-ID: <202105171519155078428@zte.com.cn>
In-Reply-To: <CY4PR05MB3576AA961FC699EE278D044AD52D9@CY4PR05MB3576.namprd05.prod.outlook.com>
References: 0BAE6DBA-04A3-4A3A-A1E3-14EFAA0FBE68@cisco.com, 202105171009360258167@zte.com.cn, CY4PR05MB3576AA961FC699EE278D044AD52D9@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 14H7JFRa043511
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/VnNnJzRQP_rYApRLoNjOlzKVBSg>
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 07:19:31 -0000

Hi Shraddha,






The two methods of automatic generation of BW-metric introduced in the draft are also likely to be the method of manual configuration of BW-metric by operators. Operators can certainly manually configure any  BW-metric he wants to configure.


However, the manually configured BW-metric cannot deviate from the actual bandwidth capacity of the link, otherwise it could be any other names such as BX-metric.


For manual assignment, the problem may still exist We can find an example that  the accumulated bandwidth-metric on the path may offset the manually increased bandwidth-metric of links on the path.



Combination of bandwidth attribute of link and other metric that is cumulative may be another co-exist way to completely address this issue.






Regards,


PSF


















原始邮件



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




Hi Pengshaofu,


 


I was suggesting to manually assign bandwidth metric which will override the automatic metric calculation


as described in the draft section 5. Physically adding more fiber/capacity is not a feasible solution.


 


Rgds


Shraddha


 


 


Juniper Business Use Only



From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn> 
 Sent: Monday, May 17, 2021 7:40 AM
 To: Shraddha Hegde <shraddha@juniper.net>
 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]


 

 

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