Opsdir last call review of draft-ietf-bfd-vxlan-07

Jürgen Schönwälder via Datatracker <noreply@ietf.org> Tue, 21 May 2019 07: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 1BBCF1201CA; Tue, 21 May 2019 00:28:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder_via_Datatracker?= <noreply@ietf.org>
To: <ops-dir@ietf.org>
Cc: rtg-bfd@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, ietf@ietf.org
Subject: Opsdir last call review of draft-ietf-bfd-vxlan-07
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= <j.schoenwaelder@jacobs-university.de>
Message-ID: <155842371303.2459.12357511675299405749@ietfa.amsl.com>
Date: Tue, 21 May 2019 00:28:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/lpGg4l93ZugyygpnISYLIMLOhys>
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, 21 May 2019 07:28:34 -0000

Reviewer: Jürgen Schönwälder
Review result: Has Issues

I only have a very limited understanding of VXLAN ands BFD technology.
Hence, some of my question may look odd to the insiders.

- RFC 7348 defining VXLAN is informational, why would BFD for VXLAN be
  standards track?

- Section 2.1 "Terminology" expands acronyms but it does say where
  these "terms" are actually defined. Some pointers to the relevant
  RFCs may be useful.

- Section 3 starts talking about VNI numbers but acronym VNI has not
  been introduced before. I assume VNI = VXLAN Network Identifier.

- I am not familiar with VXLAN but I wonder how the endpoints
  addresses are obtained in practice. This BFD document says for
  example "The details of how the MAC address of the destination VTEP
  is obtained are outside the scope of this document." Well, OK, but
  how does this work? Is there a document where this is explained?
  Well, I am actually less concerned about how the inner address is
  obtained, I think I am more urgently missing how the VTEP determines
  the remote tunnel endpoint address.

- Why do you need a special MAC address? The text says I can use this
  address or the address of the destination VTEP but there is no
  reasoning when to use what or why a dedicated address is needed.

- What is a 'reasonable upper bound' on the number of BFD sessions
  that can be created between the same pair of VTEPs? 1? 2? 8? 64?
  256? 4096? How does the choice of this upper bound impact security?

- Which BFD mode is assumed to be used, asynchronous or demand? Or
  does this not matter for this usage of BFD, i.e., both work just
  fine and will be interoperable?

- Why is echo BFD outside the scope of this document? Can I just turn
  on echo mode or will extra specifications be needed?