Re: draft-ietf-bfd-vxlan IESG status

[Jeffrey Haas <[e-mail]>]

Review of -13 vs. previous open issues.

The short version is the issue list is largely resolved.  Summary of
actions:
- Update BFD Echo text as per last comment in this reply.
- We need to resolve MAC address assignment.
- There may be a lingering issue over the loopback network which will be
  addressed in a reply to Benjamin.

-- Jeff


On Tue, Jun 16, 2020 at 05:10:57PM -0400, Jeffrey Haas wrote:
> > Open Issue 2: Document Status should be Informational rather than Proposed
> > Standard.
> > 
> > Proposed Action: Greg should make the document Informational.  Prior WG
> > discussion suggested that we don't really care what level it should be at,
> > and had actually requested IESG guidance long ago via our AD.
> 
> This action is pending.

This is resolved.

> > ---
> > 
> > Open Issue 5: Comma parsing issue (COMMENT via Benjamin K.)
> > 
> > Proposed Action: Accept Benjamin's suggested changes.  (RFC Editor will win
> > the day here though!)
> 
> This action is pending.

This is, in my opinion, resolved.

The text in -13 is:

:    This document describes the use of Bidirectional Forwarding Detection
:    (BFD) protocol to enable monitoring continuity of the path between
:    VXLAN VTEPs that are performing as Network Virtualization Endpoints,
:    and/or availability of a replicator MSN using a Management VNI
:    (Section 4).  All other uses of the specification to test toward
:    other VXLAN endpoints are out of the scope.


> > ---
> > 
> > Open Issue 6: "Section 3, MUST NOT be forwarded to a VM" (COMMENT via
> > Benjamin K.)
> > 
> > Proposed Action: The fate of this issue is tied to Open Issue 3.
> > If the proposal is limited solely to management VNI, this text is not
> > relevant and may be deleted.
> 
> This action is still open.  

This is resolved.

> > ---
> > 
> > Open Issue 7: "::FFFF:7F00:0/104 IPv6 range" (COMMENT via Benjamin K.)
> > 
> > Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> > If the proposal is limited solely to management VNI, this text is not
> > relevant and may be deleted.
> 
> This action is still pending. 

I believe this issue should be resolved in its original intent.  However,
Benjamin still has it listed in his most recent comments.  Will move the
lingering response to there.
> > ---
> > 
> > Open Issue 8: "Section 4: MUST ensure that the BFD Control packet is not
> > forwarded to a tenant but is processed locally at the remote VTEP" (COMMENT
> > via Benjamin K.)
> > 
> > Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> > If the proposal is limited solely to management VNI, this text is not
> > relevant and may be deleted.
> 
> This action is still pending and perhaps requires further discussion.
> 
> Benjamin's point was:
> "This has to be 100% reliable, and I think we need to provide some
> example mechanism that has that property even if we don't mandate that
> it be the only allowed mechanism."
> 
> The motivation here was that when this specification was intended to address
> a fully generalized BFD for vxlan for arbitrary VNIs, there was a strong
> need to say "do not forward the BFD traffic to the tenant".
> 
> For the now default scenario of only the management VNI, this text may be
> adequate.  Benjamin should look at the current document and decide if the
> scenario is still of concern.

I believe our discussion is that it's now appropriate in its current form.
I'm considering this resolved.

> > ---
> > 
> > Open Issue 9: "Destination MAC: This MUST NOT be of one of tenant's MAC
> > addresses." (COMMENT via Benjamin K.)
> > 
> > Proposed Action: I believe this issue's fate is similarly tied to Open Issue 3.
> > If the proposal is limited solely to management VNI, this text is not
> > relevant and may be deleted.
> 
> In -12, we now have the following text:
> "Destination MAC: since a Management VNI is the VNI that does
> not have any tenants, the value of this field is not analyzed
> by the receiving VTEP."
> 
> For the management VNI, this text is true.  However, it likely requires a
> value that is described in the specification.
> 
> Proposed solution: A MAC value should be chosen that is well known and the
> text would become:
> 
> "Destination MAC: A Management VNI, which does not have any tenants, will
> have no dedicated MAC address for decapsulated traffic.  The value X:X:X:X:X
> SHOULD be used in this field."
> 
> SHOULD might need to be MUST.  Since a partial motivation for permitting the
> flexibility in the specification to NOT use the management VNI is desired,
> MUST might be inappropriate.

I believe there's consensus that we want a SHOULD here.

The discussion for the MAC address has been split to a separate thread.

> > ---
> > 
> > Open Issue 19: "Section 4...FCS" (COMMENT via Eric V.)
> > 
> > Proposed Action: Accept suggested change to "Outer Ethernet FCS"?
> 
> This action is pending.

This is resolved in -13.

> > ---
> > 
> > Open Issue 20: "using the src mac as the dst mac" (COMMENT via Eric V.)
> > 
> > Proposed Action: ?  I'm unclear what the proposal and comment is here.
> 
> It is unclear what action was requested.

Still lingering.  Will defer to next IESG review.

> > ---
> > 
> > Open Issue 22: "terminology isn't" (COMMENT via Warren K.)
> > 
> > Proposed Action: Either rename the section "acronyms used in this document"
> > or expand the section to cover the terminology.
> 
> This action is still pending.

This is resolved in -13.

> > ---
> > 
> > Open Issue 25: "leading to a false negative" (COMMENT via Barry L.)
> > 
> > Proposed Action: The underlying concern in this sentence is that BFD packets
> > must not be mis-delivered to VMs since there will be no BFD machinery
> > present in that VM to execute the BFD procedures and thus sessions will
> > drop.  Possible action is to simply delete this sentence since it
> > prematurely anticipates procedures later described in the document.
> 
> This action is still pending.

The problematic text was dropped.
This issue is resolved.

> > ---
> > 
> > Open Issue 26: "loopback range through a firewall" (COMMENT via Barry L.)
> > 
> > Proposed Action: Accept suggested rewording.
> 
> This action is still pending.

I believe this issue was resolved by dropping the firewall text in -13.

> ---
> 
> Section 7 should be rewritten as:
> 7. BFD Echo Function
> 
> Support for the BFD Echo function [RFC5880], Section 3.2, is outside the
> scope of this document.

This issue is still pending.

-- Jeff