Re: [Lsr] Éric Vyncke's Yes on draft-ietf-lsr-ospf-reverse-metric-08: (with COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Eric,

Thanks for your review and comments/suggestions. Please check inline below
for responses.

The updates as discussed below have been posted in the latest version:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-09

On Wed, Oct 5, 2022 at 8:42 PM Éric Vyncke via Datatracker <[e-mail]>
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-lsr-ospf-reverse-metric-08: Yes
>
> 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-lsr-ospf-reverse-metric/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07
> 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 Acee Lindem for the shepherd's detailed write-up
> including
> the WG consensus *and* the justification of the intended status. Even, if I
> cannot really parse `During the WG last call, a number of WG members the
> draft
> with the only issue being the predominant use cases.`.
>
> Please note that Wassim Haddad is the Internet directorate reviewer (at my
> request) and you may want to consider this int-dir reviews as well when
> Wassim
> will complete the review (no need to wait for it though):
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/reviewrequest/16329/
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## COMMENTS
>
> ### Abstract
>
> `that receiving neighbor(s) should use for a link to the signaling router`
> should the neighbor be qualified by "OSPF" ?
>
> More generally about the abstract: it is rather hard to parse and to
> understand
> (at least for a native English reader).
>

KT> Ack - updated.


>
> ### Generic
>
> Should this be "mirrored metric" rather than "reverse metric". I appreciate
> that this is late in the process, but it sounds clearer.
>

KT> Reverse is accurate since it is the metric "suggested" in the reverse
direction.


>
> ### Section 1
>
> s/and/or/ in `Open Shortest Path First (OSPFv2) [RFC2328] and OSPFv3
> [RFC5340]
> `?
>

KT> Ack


>
> ```
>    ... then R2 advertises this value
>    as its metric to R1 in its Router-LSA instead of its locally
>    configured value.
> ```
> Suggest to s/in its Router-LSA/in its Router-LSAs to all its OSPF
> neighbors/
>

KT> Router LSAs are not advertised just to neighbors but to all routers in
the OSPF area. They may get first transmitted to the neighbor and then
flooded further, that change can be misleading since it gives an impression
of the limit of the LSA being immediate neighbors.


>
> ### Section 2.2
>
> s/some point T/some point in time T/ ?
>

KT> Ack


>
> Please expand "CLOS"
>

KT> It is not actually an acronym. Fixed with added reference.


>
> ### Section 6
>
> ` When using multi-topology routing with OSPF [RFC4915],` what about
> OSPFv3 ?
>

KT> MT has not (yet) been defined for OSPFv3.


>
> ### Section 7
>
> s/The use of reverse metric signaling does not alter the OSPF metric/The
> use of
> *received* reverse metric *signalling* does not alter the OSPF metric/ ?
>

KT> Updated the text as: "The signaled reverse metric does not alter the
OSPF metric parameters stored in a receiving router's persistent
provisioning database."


>
> Rather than `If routers that receive a reverse metric advertisement log an
> event to notify system administration, `, what about using "It is
> RECOMMENDED"
> or a "SHOULD" ?
>

KT> Ack

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