Ketan As always, thank you for your prompt reply and actions.
Very much appreciated -éric From: Ketan Talaulikar <[email protected]> Date: Thursday, 6 October 2022 at 11:42 To: Eric Vyncke <[email protected]> Cc: The IESG <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "Acee Lindem (acee)" <[email protected]>, "[email protected]" <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
