Re: draft-ietf-bfd-vxlan IESG status

Jeffrey Haas <jhaas@pfrc.org> Mon, 20 July 2020 21:58 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696953A0FE5; Mon, 20 Jul 2020 14:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXyl47J4SiBP; Mon, 20 Jul 2020 14:58:34 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 69F183A0FE3; Mon, 20 Jul 2020 14:58:34 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 95D5F1E2FB; Mon, 20 Jul 2020 18:09:18 -0400 (EDT)
Date: Mon, 20 Jul 2020 18:09:18 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Greg Mirsky <gregimirsky@gmail.com>, iesg@ietf.org
Cc: bfd-chairs@ietf.org, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>
Subject: Re: draft-ietf-bfd-vxlan IESG status
Message-ID: <20200720220917.GD25102@pfrc.org>
References: <20200127221705.GB17622@pfrc.org> <20200616211057.GA21373@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200616211057.GA21373@pfrc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/cmu0mOlPJlsxir30N5AESq32wlg>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2020 21:58:37 -0000

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