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 <[email protected]>
To: 彭少富10053815;[email protected] <[email protected]>;
Cc: [email protected] <[email protected]>;
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 <[email protected]> On Behalf Of [email protected]
Sent: Thursday, March 21, 2024 3:12 PM
To: [email protected]
Cc: [email protected]
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 <[email protected]>
To: lsr <[email protected]>;
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, [email protected] 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
