Hi Shraddha,
See one inline.
> On Mar 6, 2024, at 1:51 AM, Shraddha Hegde
> <shraddha=40juniper....@dmarc.ietf.org> wrote:
>
> Hi Acee,
> Thanks for the review and edits.
> I have incorporated all edits.
> Will post -08 when window opens.
> Pls see inline for replies
>
> Juniper Business Use Only
> From: Acee Lindem <acee.lin...@gmail.com>
> Sent: Friday, March 1, 2024 4:16 AM
> To: Acee Lindem <acee.lin...@gmail.com>
> Cc: lsr <lsr@ietf.org>; draft-ietf-lsr-flex-algo-bw-...@ietf.org
> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-ietf-lsr-flex-algo-bw-con-07
> [External Email. Be cautious of content]
>
>
> Authors,
>
> I support publication of this document but not in its current state. I have
> the following comments that should be resolved first:
>
> 1. "Backward Compatibility" section is missing. This should be
> straightforward given that an FAD computation only includes
> nodes supporting that FAD.
> <SH> OK
>
> 2. “Security Considerations” is “TBD”.
> <SH> ok
>
> 3. There is no “Operational Considerations” section. Someone may ask for
> one.
> <SH> ok
>
> 4. The document alludes to the problem with elephant flows. Yet for
> “Interface Group Mode”, the aggregate bandwidth for multiple L3 links is
> used. How would this work when a flow is typically bound to a single L3
> interface?
> <SH> All we are trying to do in this document is to assign metric relative to
> bandwidth. IGPs cannot do any bandwidth management and path placement and
> it’s been mentioned in the introduction section clearly.
The introduction implies the elephant flow problem is fixed.
High bandwidth traffic such as residential internet traffic and
machine to machine elephant flows benefit from using high capacity
links. Accordingly, many network operators define a link's metric
relative to its capacity to help direct traffic to higher bandwidth
links, but this is no guarantee that lower bandwidth links will be
avoided, especially in failure scenarios. To ensure that elephant
flows are only placed on high capacity links, it would be useful to
explicitly exclude the high bandwidth traffic from utilizing links
below a certain capacity.
It seems that the 4.1.1.2 should either have a caveat that elephant flows would
normally be pinned to a single layer-3 link or the flow shouldn't be pinned and
should use all the links in the group.
Also, I'd remove the last sentence of the Introduction or provide an
informational reference on the central controller.
Thus, the procedures described in this document
are not a replacement to the capability of a centralized controller
which has dynamic view of the network and provides real time
bandwidth management or a distributed bandwidth management protocol.
Thanks,
Acee
>
> 5. #3 in section 5 is very hard to parse. Possibly split into multiple
> coherent sentences.
> <SH> will do
>
>
> Lots of editorial nits - I’m attaching some suggested edits but I’m not sure
> I got them all.
>
> 1. Use “sub-TLV” and “Sub-TLV” consistent with the usage in RFC 9350.
> I tried to fix these on the fly but it probably still needs work. Basically,
> it is capitalized when used as part of a proper noun identifying a specific
> sub-TLV. Also, in section titles and captions.
> <SH> will do
>
> 2. Reference RFC9350 rather than the Flex-Algo draft throughout.
> <SH> ok
>
> 3. I didn’t make the change but I’d use “Layer-2” and “Layer-3”
> hyphenated.
> <SH>ok
>
>
> See attached editorial suggestions in the RFC diff.
>
> Thanks,
> Acee
>
>
> > On Feb 19, 2024, at 5:25 PM, Acee Lindem <acee.lin...@gmail.com> wrote:
> >
> >
> > This starts the Working Group Last call for
> > draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm
> > enhancements described in the document have been implemented.
> >
> > Please send your support or objection to this before March 5th, 2024.
> >
> > Thanks,
> > Acee
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$
> _______________________________________________
> 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
