Subject: BFD for vxlan Destination MAC field (was Re: draft-ietf-bfd-vxlan IESG status)

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Jul 2020 17:37:35 -0400

On Wed, Jun 17, 2020 at 03:52:14PM -0400, Jeffrey Haas wrote:
> >> 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.
> >> 
> > GIM>> Accepted the suggested text. I agree that the flexibility to not use
> > the Management VNI is permitted in the specification and thus SHOULD in the
> > text is consistent with that scenario. How would we pick the MAC address?
> 
> I am out of my area of expertise and I was hoping someone in the IESG can offer a fix. :-)  I am copying Donald Eastlake since he's the designated expert for the IANA MAC address block.
> 
> Donald, review of the thread may be useful, but tersely the need is to have a well known MAC address that can be placed in this vxlan PDU that is literally a placeholder of "not to be used for forwarding".  The packet arrives at the endpoint and, if not immediately accepted, would be dropped.
> 
> If there is no well known MAC that could be used for such a behavior, perhaps an address from the IANA block may be used?
> 
> While I suspect the IANA mac documentation range could be used, IANA may not appreciate that.

Donald is not responding to emails.  Considering I've been similarly bad
about responding, that's forgivable.  However, in the interest of advancing
the document, I'd like to make a proposal.

https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml

Proposed text:

: 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.
: 
: IANA Considerations:
: 
: IANA is requested to assign a single MAC address to the value TBD1 from the
: "IANA Unicast 48-bit MAC Address" registry from the "Unassigned (small
: allocations)" block.  The Usage field will be "BFD for vxlan" with a
: Reference field of this document.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Jul 2020 18:09:18 -0400

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.
> 
> have no dedicated MAC address for decapsulated traffic.  The value X:X:X:X:X
> 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,

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 20 Jul 2020 15:28:36 -0700

Hi Jeff,
thank you for the proposed text. I'll include it in the working version
with capitalizing VXLAN in the IANA section).

Regards,
Greg

On Mon, Jul 20, 2020 at 2:26 PM Jeffrey Haas <[email-masked]> wrote:

> > I am out of my area of expertise and I was hoping someone in the IESG
> can offer a fix. :-)  I am copying Donald Eastlake since he's the
> designated expert for the IANA MAC address block.
> >
> > Donald, review of the thread may be useful, but tersely the need is to
> have a well known MAC address that can be placed in this vxlan PDU that is
> literally a placeholder of "not to be used for forwarding".  The packet
> arrives at the endpoint and, if not immediately accepted, would be dropped.
> >
> > If there is no well known MAC that could be used for such a behavior,
> perhaps an address from the IANA block may be used?
> >

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 20 Jul 2020 16:18:23 -0700

Hi Jeff, et al.,
attached please find the new working version of BFD over VXLAN and its diff
to -13.
Please let me know if you have any questions.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 30 Jul 2020 16:54:54 -0700

Hi Jeff,
do you think that the record in the Usage filed for the requested MAC
address instead of "BFD over VXLAN" be more generic, e.g., "Active OAM over
NVO3"?
What do you think?

Regards,
Greg