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