Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-flex-algo-08

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

Thanks for your quick response and please check inline below with KT2.

On Wed, Jul 20, 2022 at 12:16 AM Alvaro Retana <[e-mail]>
wrote:

> On July 19, 2022 at 11:42:44 AM, Ketan Talaulikar wrote:
>
>
> Ketan:
>
> Hi!
>
>
> > Since the gates are closed for posting, please find attached the updated
> > draft and its diff for your review.
>
> I put some comments in-line and will start the IETF LC then the update
> is posted.
>
> Thanks!
>
> Alvaro.
>
>
>
> ...
> > > 145 Thus a controller or a Path Computation Engine (PCE) is aware of
> the
> > > 146 IGP topology across multiple domains which includes the above
> > > 147 information related to the flexible algorithm. This draft defines
> > > 148 extensions to BGP-LS for carrying the FAD information so that it
> > > 149 enables the controller/PCE to learn the mapping of the flex
> algorithm
> > > 150 number to its definition in each area/domain of the underlying IGP.
> > > 151 The controller/PCE also learns the type of computation used and the
> > > 152 constraints for the same. This information can then be leveraged by
> > > 153 it for setting up SR Policy paths end to end across domains by
> > > 154 leveraging the appropriate Flex Algorithm specific SIDs in its
> > > 155 Segment List [I-D.ietf-spring-segment-routing-policy]. e.g. picking
> > > 156 the Flex Algorithm Prefix SID (in case of SR-MPLS) or End SID (in
> > > 157 case of SRv6) of ABRs/ASBRs corresponding to a definition that
> > > 158 optimizes on the delay metric enables the PCE/controller to build
> an
> > > 159 end to end low latency path across IGP domains with minimal SIDs in
> > > 160 the SID list.
> > >
> > > [major] This paragraph goes back into what this document defines, but
> > > it also tries to explain the consumer-specific use of the information,
> > > which is out of scope for BGP-LS.
> >
> > KT> The text has been reworded. The objective is to briefly inform the
> reader
> > of a use case for these extensions. Even RFC7752 has covered the use
> cases or
> > applications that may leverage BGP-LS. IMHO, it is good to get some
> > description of the use case or reason for pushing things from the IGPs
> into
> > BGP-LS.
>
> Some background is ok.  However, my opinion is that rfc7752 already
> covered the motivation -- we don't need to refresh the motivation in
> every draft.
>

KT2> Ack and therefore I've cut out a lot of the text related to
PCE/controller and TE from the v08.


>
> The part about "BGP-LS extensions for SR are defined in [RFC9085]
> and     [I-D.ietf-idr-bgpls-srv6-ext].  They include the
> [I-D.ietf-idr-bgpls-srv6-ext]" is not needed because none of those
> extensions are used here.
>

KT2> As an implementor, this text helps inform that there are certain
aspects of the FlexAlgo solution that are already covered in other BGP-LS
specs. Without implementing those aspects, the solution is not workable.
Therefore, IMHO, this text needs to be retained. Also, it does no harm.


>
> The text starting with "This information can then be leveraged..." is
> about what the consumer might do.
>

KT2> This is a specific use case enabled by the extensions in this
document. IMHO this helps the reader, but I am ok to remove if you feel
strongly that it needs to be removed :-)


>
>
> ...
> > > 508 o Flex-Algorithm...
> >
> > > [major] Please simply refer to the definition in
> I-D.ietf-lsr-flex-algo.
> > > Note that in this case the definition above says more than the one in
> > > I-D.ietf-lsr-flex-algo: "Flex-Algorithm: Single octet value between
> 128 and
> > > 255 inclusive." ...
> >
> > KT> Ack
>
> The description now uses "Flexible Algorithm" while the figure calls
> the field "Flex. Algo.".  Perhaps for the description: "Flexible
> Algorithm (Flex. Algo.)" (maybe even eliminate the "." in both
> places).
>

KT> Fixed.


>
>
>
> ...
> > > 522 The FAPM TLV...
> >
> > KT> Ack. Fixed.
>
> The text mentions the FAD TLV (instead of the FAPM TLV).
>

KT2> Fixed.

Thanks,
Ketan