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

[Alvaro Retana <[e-mail]>]

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.

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.

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


...
> > 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).



...
> > 522 The FAPM TLV...
>
> KT> Ack. Fixed.

The text mentions the FAD TLV (instead of the FAPM TLV).