Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-bfd-vxlan-14: (with COMMENT)

From: Greg Mirsky <[email-masked]>
Date: Thu, 1 Oct 2020 12:56:41 -0700

Hi Ben,
many thanks for your comments, suggestions and the discussions. These
helped a lot in making the better document. Please find my notes in
response to your comments below under the GIM>> tag.

Regards,
Greg

On Tue, Sep 29, 2020 at 1:31 PM Benjamin Kaduk via Datatracker <
[email-masked]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bfd-vxlan-14: No Objection
>
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the discussions around my discuss point, and the ensuing
> changes
> resulting from the discussions!  My apologies that I was tardy in
> re-reviewing after
> the updates were made.
>
> I think the core issues have been resolved, but do have a couple comments
> on the -14:
>
> Section 3 says:
>
>                   Separate BFD sessions can be established between the
>    VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100
>    and 200).  Using a BFD session to monitor a set of VXLAN VNIs between
>    the same pair of VTEPs might help to detect and localize problems
>    caused by misconfiguration.  An implementation that supports this
>    specification MUST be able to control the number of BFD sessions that
>    can be created between the same pair of VTEPs.  [...]
>
> While the first two sentences are probably true, they are arguably out
> of scope for this document, since Section 6 says that BFD control
> packets on non-management VNI is outside the scope of this
> specification.

GIM>> Yes, the document describes applicability of BFD over the Management
VNI. Procedures described in the document might work for non-managemnt VNIs
but the document doesn't make any assumption about that. And that is why a
case of non-management VNI was set outside the scope of the specification.

> The third sentence is quite surprising in the context of
> this document only defining BFD for the management VNI, since multiple
> BFD sessions on the same VNI seem redundant.
>
GIM>> True. The intention was to suggest that if an implementation may be
used on non-management VNIs, then the number of concurrent BFD sessions
must be controlled. I think that it is unlikely that there will be a
document that will define BFD over VXLAN for non-managemet VNIs and
developers may appreciate some guidance this document provides.

>
> Section 5
>
>          Destination MAC: A Management VNI, which does not have any
>          tenants, will have no dedicated MAC address for decapsulated
>          traffic.  The value [TBD1] SHOULD be used in this field.
>
> While this normative language seems like the appropriate level of
> stringency, I do find myself wondering what other value might be used
> and why.  (This, of course, need not be answered in the document, though
> it could be if the answer is known and useful.)
>
GIM>> There are early implementations that have been deployed that use
other MAC values. We might disagree with their choice but wanted to allow
thier conformance to this specification.