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

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

The update has been just posted:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-flex-algo-09

Thanks,
Ketan


On Wed, Jul 20, 2022 at 9:14 AM Ketan Talaulikar <[e-mail]>
wrote:

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