Re: [Idr] Éric Vyncke's No Objection on draft-ietf-idr-bgpls-srv6-ext-12: (with COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Eric,

Thanks for your review and comments.

Please check inline below for responses.

On Thu, Dec 15, 2022 at 2:49 PM Éric Vyncke via Datatracker <
[e-mail]> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-idr-bgpls-srv6-ext-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-srv6-ext/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-idr-bgpls-srv6-ext-12
> CC @evyncke
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
>
> Special thanks to Susan Hares for the shepherd's detailed write-up
> including
> the WG consensus *and* the justification of the intended status.
>
> Other thanks to Timothy Winters, the Internet directorate reviewer (at my
> request), please consider this int-dir review:
>
> https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-12-intdir-telechat-winters-2022-12-07/
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## COMMENTS
>
> ### Section 3.1
>
> I second John's point on the lack of specification for the Flag field. This
> document does not specify how to interpret the values. It happens that the
> IS-IS and OSPFv3 specify a 16-bit value with currently the same semantic
> associated to the 16-bit but I fear that this is quite dangerous to have
> the
> *same* field specified in several documents. Strongly suggest creating a
> IANA
> registry for this 16-bit field shared by (at least) 3 IETF drafts.
>
> The same comment applies to many other values in the document.
>

KT> Thanks to Alvaro and John for clarifying this from the separate
discussion thread that we've had including the authors of the corresponding
IGP specs. Please also look at the most recent update posted and my
responses to John on this.


>
> ### Section 4.2
>
> Suggest to replace the very specific "LAN" to the broader "broadcast link"
> ?
>

KT> We are trying to be consistent here with the IGP specs. More
importantly this is reflecting the IGP behavior/working on LAN - I am not
very sure what other broadcast links we are looking to cover and hence not
sure whether or not this would apply so broadly.


>
> ### Section 5.1
>
> ```
>    As specified in [RFC8986], an SRv6 SID comprises Locator, Function
>    and Argument parts.
> ```
> Does the above text assume that *all* SIDs are network programming SIDs ?
> Suggest to qualify as in "a network programming SRv6 DIS"
>

KT> RFC8986 is not introducing a new type of "network programming" SIDs.
This applies to all SRv6 SID.

Thanks,
Ketan


>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
>
>
>
>