Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

Hi Shraddha, 

See one inline. 

> On Mar 6, 2024, at 1:51 AM, Shraddha Hegde <shraddha=40juniper.net@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.lindem@gmail.com> 
> Sent: Friday, March 1, 2024 4:16 AM
> To: Acee Lindem <acee.lindem@gmail.com>
> Cc: lsr <lsr@ietf.org>; draft-ietf-lsr-flex-algo-bw-con@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.lindem@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