Éric Vyncke's Abstain on draft-ietf-bfd-vxlan-13: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Wed, 22 July 2020 12:28 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 1566A3A0AE6; Wed, 22 Jul 2020 05:28:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-bfd-vxlan@ietf.org, bfd-chairs@ietf.org, rtg-bfd@ietf.org, Jeffrey Haas <jhaas@pfrc.org>, jhaas@pfrc.org
Subject: =?utf-8?q?=C3=89ric_Vyncke=27s_Abstain_on_draft-ietf-bfd-vxlan-13=3A_=28with_COMMENT=29?=
X-Test-IDTracker: no
X-IETF-IDTracker: 7.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
Message-ID: <159542089363.28188.3286555767171732447@ietfa.amsl.com>
Date: Wed, 22 Jul 2020 05:28:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/9wRwegftJ_Li9VTjFJQEB6EXBCs>
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: Wed, 22 Jul 2020 12:28:14 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-bfd-vxlan-13: Abstain

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 work put into this document and its update. I have cleared
one of my DISCUSS point about TTL = Hop Limit not being 255.

But, the authors and I are in an impasse about the use of IPv4-mapped IPv6
addresses but I do not want to block the document. I change my ballot to
"ABSTAIN" in the sense of "I oppose this document but understand that others
differ and am not going to stand in the way of the others".

BTW, I understood that the use a prefix rather than /32 or /128 was to allow
for entropy (to explore multiple ECMP/LAG paths). BTW2, the right wording is
"IPv4-mapped IPv6 address" and not "IPv4-mapped IPv4 address" as written twice
in the document.

Did you (or actually the authors) also investigate the use of the:
- ::/0 : unspecified address
- 100::/8 the discard prefix used for RTBH RFC 6666
- or even requesting a block out of the 2001::/23 (reserved for IETF special
use)

Previous COMMENTs for archive as they were on revision -09

RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer that
this document is only required to address the Ethernet encapsulation ? I.e.
specifying the Ethernet MAC addresses?

-- Section 3 --
At first sight, I was surprized by having a BFD session per VXLAN VNI as it
will create some scalability issue, but, I assume that this is to detect
misconfiguration as well. If so, perhaps worth mentionnig the reasoning behind?

In "the inner destination IP address SHOULD" it is unclear whether it is in the
all BFD packets, or only the request one or ... ?

-- Section 4 --
While probably defined in RFC7348, should "FCS" be renamed as "Outer Ethernet
FCS" for consistency with the "Outer Ethernet Header" in figure 2 ?

Why not using the Source MAC address as the Destination MAC address ? This
would ensure that there is no conflict at the expense of "forcing" the
transmission of the frame even if addressed to itself.

Please consider rewriting the section about TTL/Hop Limit as it is not easy to
parse/read.

-- Section 9 --

This section is mainly about IPv4 (RFC 1812). Please address IPv6 as well in
the explanation of packet not being forwarding when addressed to 127/8