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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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

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