Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt

peng.shaofu@zte.com.cn Thu, 21 March 2024 09:41 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 24070C1CAF52 for <lsr@ietfa.amsl.com>; Thu, 21 Mar 2024 02:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.893
X-Spam-Level:
X-Spam-Status: No, score=-6.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-TRxDX3JAcX for <lsr@ietfa.amsl.com>; Thu, 21 Mar 2024 02:41:53 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D8CC1519AC for <lsr@ietf.org>; Thu, 21 Mar 2024 02:41:50 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4V0gTS3fqmz4xPYm; Thu, 21 Mar 2024 17:41:48 +0800 (CST)
Received: from njb2app05.zte.com.cn ([10.55.22.121]) by mse-fl1.zte.com.cn with SMTP id 42L9faxU025518; Thu, 21 Mar 2024 17:41:36 +0800 (+08) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njy2app01[null]) by mapi (Zmail) with MAPI id mid201; Thu, 21 Mar 2024 17:41:39 +0800 (CST)
Date: Thu, 21 Mar 2024 17:41:39 +0800
X-Zmail-TransId: 2af965fc00d3020-7e614
X-Mailer: Zmail v1.0
Message-ID: <202403211741391950846@zte.com.cn>
In-Reply-To: <6EA3C518-97A1-4B6E-AAFD-B733F4457022@gmail.com>
References: 171075941763.47754.665628517431322649@ietfa.amsl.com, 6EA3C518-97A1-4B6E-AAFD-B733F4457022@gmail.com
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: acee.lindem@gmail.com
Cc: lsr@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 42L9faxU025518
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 65FC00DC.000/4V0gTS3fqmz4xPYm
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/BJHANBO7sgrotOqDLN99ih9wtlI>
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 21 Mar 2024 09:41:58 -0000

Hi Chairs, WG,

I have relearned this document, and there are some non-blocking comments:

[1]
For Interface Group Mode of automatic metric calculation, it may biases the utilization rate of each link of the parallel link-set. 
Although the document give an example (figure 7) to explain why this mode is applied, it seems not convincing. 
In Figure 7, the expected path is B-C-F-D, while B-E-D is an unexpected path. 
However please consider the following example that I believe that the expected path in this example should also be B-C-F-D + B-C'-F'-D (i.e., an ECMP path) if according to the same intention of the operators, but in this case most people may not consider them (i.e., the ECMP paths) as expected paths. There seems contradictory.
        example:
        A ----------- B ---- C ---- F ---- D
                            ---- C' ---- F' ---
                            --------- E --------
                            
[2]
For the description of Bandwidth Thresholds Sub-TLV of ISIS and OSPF, there are such descripton:
  "When the computed link bandwidth ... "
can it change to "when the used link bandwidth ..." ? 
IMO we can say the computed bandwidth metric but can not say the computed link bandwidth.

Please also check the erros of threshold #number as below:
When the computed link bandwidth is greater than or equal to Bandwidth Threshold 1 and less than Bandwidth Threshold 1(//should be threshold 2), Threshold Metric 1 MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation.  
Similarly, when the computed link bandwidth is greater than or equal to Bandwidth Threshold 1 (//should be threshold 2) and less than Bandwidth Threshold 2(//should be threshold 3), Threshold Metric 2 MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation.

[3]
For section 5. Bandwidth metric considerations, there may have errors:

4.In ISIS the Link Bandwidth for Flex-Algorithm purposes is advertised as a sub-sub-TLV 9 of the Flex-algorithm specific ASLA sub-TLV. It is also possible to advertise the link bandwidth or Flex-Algorith(// should be changed to "for Flex-Algorithm" ?), in sub-TLV 9 of TLV 22/222/23/223/141 [RFC5305], together with the L-Flag set in the Flex-Algorithm specific ASLA advertisement. In the absence of both of these advertisements, the bandwidth of the link is not available for Flex-Algorithm purposes.


Regards,
PSF


Original


From: AceeLindem <acee.lindem@gmail.com>
To: lsr <lsr@ietf.org>;
Date: 2024年03月20日 11:00
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt

Speaking as WG Member:
 
My comments have been addressed with this version and I support publication (as working member).  
 
Speaking as WG Co-Chair:  
 
It would be good for others  to review this draft as well  (and especially those writing Flex-Algo
extension drafts).  We had limited support (5 non-authors including myself). I'll give it another
week or so for review prior to requesting publication.  
 
Thanks,
Acee
 
> On Mar 18, 2024, at 6:56 AM, internet-drafts@ietf.org wrote:
>  
> Internet-Draft draft-ietf-lsr-flex-algo-bw-con-08.txt is now available. It is
> a work item of the Link State Routing (LSR) WG of the IETF.
>  
>   Title:   Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints
>   Authors: Shraddha Hegde
>            William Britto A J
>            Rajesh Shetty
>            Bruno Decraene
>            Peter Psenak
>            Tony Li
>   Name:    draft-ietf-lsr-flex-algo-bw-con-08.txt
>   Pages:   30
>   Dates:   2024-03-18
>  
> Abstract:
>  
>   Many networks configure the link metric relative to the link
>   capacity.  High bandwidth traffic gets routed as per the link
>   capacity.  Flexible algorithms provide mechanisms to create
>   constraint based paths in IGP.  This draft documents a generic metric
>   type and set of bandwidth related constraints to be used in Flexible
>   Algorithms.
>  
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
>  
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-08
>  
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-flex-algo-bw-con-08
>  
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>  
>  
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
 
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr