[RTG-DIR]Re: Rtgdir early review of draft-ietf-bess-evpn-bfd-07

[Donald Eastlake <[e-mail]>]

Hi Med,

On Mon, Sep 16, 2024 at 10:56 AM Mohamed Boucadair via Datatracker
<[e-mail]> wrote:
> Reviewer: Mohamed Boucadair
> Review result: Has Issues
>
> Hi authors,
>
> Thanks for the effort put into this document.
>
> Overall, the document reads well. The specification leverages existing
> specifications with exceptions called out it in the document. This approach
> seems reasonable,

Thanks.

> but there are some issues that need to be fixed. These are
> highlighted in the detailed review (see below). A subset of them are
> highlighted hereafter:
>
> # Better position the document: For example, I failed to find this "network
> layer" defined in RFC7432 or 7432bis. I think that you are referring to the
> layering in 2.1 of 9062. For example, you can consider adding a sentence in the
> introduction about 2.1 of 9062 to position the layer you are considering.

Will add such a reference to the Abstract and will add some more and
more specific references to 9062. I would point out that the very
first two sentences of the Introduction are as follows:

   [RFC9062] outlines the OAM requirements of Ethernet VPN networks
   (EVPN) [rfc7432bis].  This document specifies mechanisms for
   proactive fault detection at the network (overlay) layer of EVPN,
   that is to say between PEs (Provider Edge nodes).

> # 7432 or 7432bis: Any reason why the bis is cited explicitly here? Are there
> parts of the spec that are not applicable to 7432? I don't think so, but it is
> better clarify this in the doc rather than leaving the readers guess.

If a base document is undergoing revision for clarification and
perhaps minor corrections, I believe that it is best practice to
reference the revision because it would normally be a better document
than the base document, that is, clearer and more
complete/correct.

> # "future versions of this document" vs "other documents": The document says in
> several places that "It is intended to address this in future versions of this
> document.". The intended scope should be clarified.

I think what the authors had in mind was a future expanded RFC that
obsoleted or updated the RFC this draft is intended to become. I will
change the wording to avoid confusion.

> # Internal inconsistency:
>
> ## The document refers to TBD3 and cites Section 8, but there is no such
> definition in the IANA section ## The document cites "dedicated unicast MAC"
> and "dedicated multicast MAC" but these are not defined in the document.

Will fix this. I think a previous change was incorrectly implemented.

> ## RFC 9026
>
> Previous sections state that 9026 is not mandatory and other mechanisms can be
> used. However, Section  This text seems to assume that it is always used:
>
> "It also contains a BFD Discriminator
>    Attribute [RFC9026] with BFD Mode TDB4 giving the BFD discriminator
>    that will be used by the tail.
> "
>
> (note that s/TDB4/TBD2)

Will reword to clarify/correct this.

> # Redundant requirements: For example, the document says
>
> "   The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] and
>    BFD for VXLAN [RFC8971] are, except as otherwise provided herein,
>    applied to test loss of continuity for unicast EVPN traffic.
> "
>  but then
>
> "   Once the BFD session is UP, the ends of the BFD session MUST NOT
>    change the local discriminator values of the BFD Control packets they
>    generate, unless they first bring down the session as specified in
>    [RFC5884].
> "
>
> the intended behavior vs "local discriminator values" here is redundant with
> this part in Section 7 of 5884:
>
> "Note that once the BFD session for the MPLS LSP is UP, either end of the BFD
> session MUST NOT change the source IP address and the local discriminator
> values of the BFD Control packets it generates, unless it first brings down the
> session."
>
> No?

OK but I think noting this is useful so I'll replace the current text
with a clearly labeled quote from RFC 5884 elsewere in the draft.

> # Detailed review can be found here, fwiw:
>
> * pdf:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.pdf
> * doc:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.doc
>
> Feel free to grab whatever you think useful.

Thanks for all the detailed comments. I will adopt most of them. See
responses attached.

> Hope this helps.

Yes. While I don't agree with 100% of your comments, I believe the
ones I have adopted substantially improve the documents.

I will post a revised draft.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> Cheers,
> Med