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

[[e-mail]]

Hi Shraddha,

Thanks for your response.

I agree with the principle that the more bandwidth the lower BW metric.
Just wonder, assuming that from the operator's perspective, why does the operator believe that for the next two examples, the expected path of Example-1 is B=C=F=D, while the expected path of Example-2 is not ECMP {B-C-F-D plus B-C'-F'-D}.
Example-1:
        A ----------- B === C === F === D
                            ---------- E ---------
Example-2:
        A ----------- B ---- C ---- F ---- D
                            ---- C' ---- F' ---
                            --------- E --------
Yes, A single principle may be difficult to apply in all scenarios. This is not an issue, but may be an improvement of path computation and out the scope of this draft.

Regards,
PSF


Original


From: ShraddhaHegde <[e-mail]>
To: 彭少富10053815;[e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;
Date: 2024年03月26日 19:03
Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt



Hi Pengshaofu,
 
Thank you for review and comments.
Pls see inline..
 
 
Juniper Business Use Only

From: Lsr <[e-mail]> On Behalf Of [e-mail]
 Sent: Thursday, March 21, 2024 3:12 PM
 To: [e-mail]
 Cc: [e-mail]
 Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt



 
[External Email. Be cautious of content]
 
 
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 --------
<SH> I am not sure I understand your comment. The draft emphasizes that B->C->F->D has more bandwidth and hence should have lower metric. Do you agree with that?
                            
[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.
<SH> In case of interface group mode, the link bandwidth is computed based on the parallel links and that’s why the term is used.
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.
<SH> Good catch. I have fixed for both ISIS/OSPF
[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.
<SH> Fixed
 
Regards,
PSF
 

Original

From: AceeLindem <[e-mail]>



To: lsr <[e-mail]>;



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, [e-mail] 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
 > [e-mail]
 > https://www.ietf.org/mailman/listinfo/lsr
 
 _______________________________________________
 Lsr mailing list
 [e-mail]
 https://www.ietf.org/mailman/listinfo/lsr