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

["Eric Vyncke (evyncke)" <[e-mail]>]

Ketan

As always, thank you for your prompt reply and actions.

Very much appreciated

-éric

From: Ketan Talaulikar <[e-mail]>
Date: Thursday, 6 October 2022 at 11:42
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Acee Lindem (acee)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Éric Vyncke's Yes on draft-ietf-lsr-ospf-reverse-metric-08: (with COMMENT)

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]<mailto:[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