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

Reply via email to