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 23:21 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 3D8EC3A0BC2; Fri, 21 May 2021 16:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.885
X-Spam-Level:
X-Spam-Status: No, score=-1.885 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, T_REMOTE_IMAGE=0.01, 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 4xuE0VlAk4ze; Fri, 21 May 2021 16:20:58 -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 BCF643A0BB9; Fri, 21 May 2021 16:20:55 -0700 (PDT)
Received: from [240.0.0.1] (unknown [109.166.36.197]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id B18211C00BB; Sat, 22 May 2021 07:20:53 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-DF915805-0E7C-463C-BEF7-9104049FBEFC
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Sat, 22 May 2021 07:19:50 +0800
Message-Id: <A1FD3F97-9AF9-4E50-BB96-928A1E4A1363@tsinghua.org.cn>
References: <CABNhwV3=yvCe0J9N+gRGLGofJeTRdqpttEncG_5JP641aoGegw@mail.gmail.com>
Cc: Tony Li <tony.li@tony.li>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, draft-hegde-lsr-flex-algo-bw-con@ietf.org, lsr <lsr@ietf.org>
In-Reply-To: <CABNhwV3=yvCe0J9N+gRGLGofJeTRdqpttEncG_5JP641aoGegw@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: iPhone Mail (18D70)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQkhLQlYYSR9NSUgYGBhPGR9VEwETFhoSFyQUDg9ZV1kWGg8SFR0UWUFZT0tIVU pKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6K0k6Qxw*Fz8cGS0BETYzLE8O TDYKFAxVSlVKTUlKTUhCSU5PSUhJVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS0JVSk1NVUhNVUpCTFlXWQgBWUFJSU5OTDcG
X-HM-Tid: 0a79913b4ee3d993kuwsb18211c00bb
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/UvMjjTkqgqIsTREQk34jF7cnByM>
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 23:21:04 -0000

Hi, Gyan:

Aijun Wang
China Telecom

> On May 22, 2021, at 06:59, Gyan Mishra <hayabusagsm@gmail.com> wrote:
> 
> 
> 
> Aijun 
> 
> This is a similar concept to what exists today with most vendors CLI configured reference bandwidth that can be overridden by manual metrics link by link to skew traffic to avoid bottle necks, but now applying that same concept that has existed historically to Flex Algo  new “bandwidth metric” static generic metric TLV and new automatic reference bandwidth based metric.  
[WAJ] Yes, I know.  But the reality is that we rarely use such bandwidth based automatic metric assignments method because it can’t get the determined results as we expected. For example, if two links between the one node pair has different bandwidth, the lower bandwidth link will be not utilized at all.
There may exist other issues in large complex network. The operator must take care of each possible unexpected scenario manually.
> 
> With this algorithm change the issue that has existed with IGP ECMP parallel links is that they are all treated as individual and so the total group bandwidth is not taken into account. 
[WAJ] But in some situations, especially the high bandwidth path has multiple hops than the low bandwidth path, the operator must intervene manually to change the automatic obtained bandwidth metric to achieve the expected results, as also agree with Tony in our discussed example.
Will you bother yourself for knob?

> So this is a major benefit to now being incorporated into Flex Algo.   Also the concept of being able to exclude links based on minimum bandwidth is as well a benefit so traffic is skewed to the higher bandwidth links.  
[WAJ] Yes, I agree with the introduction of minimum bandwidth constraints in Flex-Algorithm, but not the bandwidth metric.
> 
> This is basically another option for operators using Flex Algo in the operators toolbox.
> 
> Kind Regards 
> 
> Gyan
> 
>> On Fri, May 21, 2021 at 6:40 PM Tony Li <tony.li@tony.li> wrote:
>> 
>> Hi Aijun,
>> 
>>>>> 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.
>>> [WAJ]  The introduction part talks mainly how to divert the elephant traffic away from the low bandwidth link. This can be achieved via the introduction of additional constraints information for Flex-ALGO
>> 
>> 
>> Which is exactly what we’ve done: added bandwidth constraints. 
>> 
>> 
>>>>> The usage of bandwidth metric in large network is not feasible. 
>>>> 
>>> [WAJ] The main reason is that bandwidth metric is not cumulative.  
>> 
>> 
>> ??? What are you seeing that implies that?  That is not my understanding at all.
>> 
>> 
>>>>> 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.
>>> 
>>> [WAJ] OK, let’s add two nodes between node B and C, say they are node M and N. They have also two parallel links to B and C respectively. The two possible path from B to D will be:
>>> Path 1: B-M-N-C-F-D
>>> Path 2: B-E-D
>>> If the “reference bandwidth” is 100G, then metric for each link in B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1 “B—N-C-F-D” will be 25, right?
>>> The metric for each link in B-E-D will be 10, the cumulative metric from B-D for Path 2 will be 20, right?
>>> How can you prefer to the high bandwidth path?
>> 
>> 
>> 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.
>> 
>> Tony
>> 
>> 
>> 
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> -- 
> 
> 
> Gyan Mishra
> Network Solutions Architect 
> Email gyan.s.mishra@verizon.com
> M 301 502-1347
> 
>