Barry Leiba's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Tue, 17 December 2019 05:39 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-bfd@ietf.org
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43500120059; Mon, 16 Dec 2019 21:39:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-bfd-vxlan@ietf.org, Jeffrey Haas <jhaas@pfrc.org>, bfd-chairs@ietf.org, jhaas@pfrc.org, rtg-bfd@ietf.org
Subject: Barry Leiba's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.113.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <157656119326.24566.9438425082238826931.idtracker@ietfa.amsl.com>
Date: Mon, 16 Dec 2019 21:39:53 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/TgM0iis1c5WK8ky73vKoiIL6MaA>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 17 Dec 2019 05:39:53 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-bfd-vxlan-09: 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:
----------------------------------------------------------------------

I support Ben’s DISCUSS.  In addition, I have a number of editorial comments.

General: there are a lot of missing or incorrect articles, making the document
harder to read than it should be.  It would be good to fix that.  If you let
the RFC Editor fix it, it will require careful review during AUTH48 to make
sure it’s correct.

— Abstract —
The phrase “forming up” is odd; I suggest just “forming”.

— Section 3 —

   BFD packets intended for a VTEP MUST
   NOT be forwarded to a VM as a VM may drop BFD packets leading to a
   false negative.

This needs two commas: one before “as” and one before “leading”.  And what does
“leading to a false negative” mean here?  I don’t understand.

   It is RECOMMENDED to allow
   addresses from the loopback range through a firewall only if it is
   used as the destination IP address in the inner IP header, and the
   destination UDP port is set to 3784 [RFC5881].

I THINK the antecedent for “it” is meant to be “addresses from the loopback
range”, though because of the number mismatch it looks like the antecedent is
“a firewall”.  One fix is to change “addresses” to “an address”, correcting the
number error, but that leaves the ambiguity.  Maybe betterto make it “only if
they are used as destination IP addresses”.  Also, remove the comma.

That fixes the sentence as written, but I also agree with Ben’s comment that
this might need more significant rewording.

— Section 4 —

   BFD packet MUST be encapsulated and sent to a remote VTEP as
   explained in this section.

This needs to be either “A BFD packet” or “BFD packets” and “VTEPs”.

         The MAC address MAY be
         configured, or it MAY be learned via a control plane protocol.

Are those the only two choices?  As both “MAY” are optional, as written it
allows for others.  I suggest not using BCP 14 key words here, and instead
saying, “The MAC address is either configured or learned via a control plane
protocol.”

         This
         addresses the scenario when the inner IP destination address is
         of VXLAN gateway and there is a router in underlay which
         removes the VXLAN header, then it is possible to route the
         packet as VXLAN  gateway address is routable address.

This sentence is too fractured for me to make any sense of it, so I can’t
suggest a fix.  Please fix it.  It looks like Ben made more sense of it than I
could, so maybe his suggestion will work.

— Section 5 —

   received VXLAN packet MUST follow the procedures described in
   Section 4.1 [RFC7348].

This needs to say “Section 4.1 of [RFC7348].”