Hi Eric, We've posted an update that includes the changes discussed in the thread below: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-10
Thanks, Ketan On Wed, Oct 5, 2022 at 12:37 PM Ketan Talaulikar <[email protected]> wrote: > Hi Eric, > > Thanks for your quick response and please check inline below with KT2. > > On Wed, Oct 5, 2022 at 12:22 PM Eric Vyncke (evyncke) <[email protected]> > wrote: > >> Hello Ketan >> >> >> >> As usual, your fast reply is always appreciated. >> >> >> >> See below for EV> (mainly acknowledging your reply) >> >> >> >> Regards >> >> >> >> -éric >> >> >> >> *From: *iesg <[email protected]> on behalf of Ketan Talaulikar < >> [email protected]> >> *Date: *Wednesday, 5 October 2022 at 08:21 >> *To: *Eric Vyncke <[email protected]> >> *Cc: *The IESG <[email protected]>, " >> [email protected]" < >> [email protected]>, "[email protected]" < >> [email protected]>, "[email protected]" <[email protected]>, "Acee Lindem >> (acee)" <[email protected]> >> *Subject: *Re: Éric Vyncke's Yes on >> draft-ietf-lsr-ospf-bfd-strict-mode-09: (with COMMENT) >> >> >> >> Hi Eric, >> >> >> >> Thanks for your review and please check inline below for responses. >> >> >> >> The update discussed below will reflect in the next version of the >> document. >> >> >> >> >> >> On Wed, Oct 5, 2022 at 11:20 AM Éric Vyncke via Datatracker < >> [email protected]> wrote: >> >> Éric Vyncke has entered the following ballot position for >> draft-ietf-lsr-ospf-bfd-strict-mode-09: 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-bfd-strict-mode/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> # Éric Vyncke, INT AD, comments for draft-ietf-lsr-ospf-bfd-strict-mode-09 >> CC @evyncke >> >> Thank you for the work put into this document. It is short, clear, and >> useful >> (hence my YES). >> >> 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. >> >> I hope that this review helps to improve the document, >> >> Regards, >> >> -éric >> >> ## COMMENTS >> >> ### Section 3 >> >> Suggest to move section 3 (Local Interface IPv4 Address TLV) as a >> subsection of >> section 4.1 (OSPFv3 IPv4 Address-Family Specifics) as, at least for me, >> the >> reader cannot understand the use of section 3 before reading section 4.1 >> >> >> >> KT> How about we add a forward reference to section 4.1 in section 3? The >> idea behind the current organization was to specify the protocol encodings >> up front and then their usage/procedures. >> >> >> >> EV> I understand the reasoning of the current document structure even if >> not easy for the reader. Anyway, a forward reference would be a good step >> forward. >> > > KT2> Ack > > >> >> >> >> As I am not an OSPFv3 expert, the following question is possibly >> irrelevant, >> but can the IPv4 address be a link-local (i.e., 169.254/16)? >> >> >> >> KT> AFAIK such usage is not specified. Perhaps the assumption or >> motivation being that they were mainly intended for hosts. That said, >> technically their usage does seem possible to me. Both for OSPFv2 and for >> OSPFv3. >> >> >> >> EV> Thanks. I guess that specifying that it must be a unicast address is >> useless/implicit. >> > > KT2> Yes. It is an interface address. > > >> >> >> >> ### Section 4.1 >> >> ``` >> ... In most deployments of >> OSPFv3 IPv4 AF, it is required that BFD is used to monitor and verify >> IPv4 data plane connectivity between the routers on the link and, >> hence, the BFD session is setup using IPv4 neighbor addresses. >> ``` >> >> The text is a little unclear whether an IPv6 BFD session is also required. >> >> >> >> KT> Yes, it is for OSPv3 IPv6 AF instance adjacencies - that is base >> OSPFv3 protocol interactions with BFD and covered in RFC5882. Here the >> context is specifically on "In ... OSPFv3 IPv4 AF, ...". Note that there >> would be separate OSPFv3 protocol instances for IPv4 and IPv6 with the >> adjacency of each instance monitoring IPv4 and IPv6 BFD connectivity >> respectively. >> >> >> >> EV> this was my **guess**, suggest to make it clearer with " ... the IPv4 >> BFD session is setup ..." >> > > KT2> Ack - will incorporate this suggestion. > > Thanks, > Ketan > > >> >> >> 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
