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

Greg Mirsky <> Tue, 04 June 2019 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4437E1202E7; Tue, 4 Jun 2019 13:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aX4bpqZtNMqC; Tue, 4 Jun 2019 13:40:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3811912004C; Tue, 4 Jun 2019 13:40:27 -0700 (PDT)
Received: by with SMTP id 131so8487538ljf.4; Tue, 04 Jun 2019 13:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UojGCpH5K3RrHd5m15zt9lvTn9YsSLGvqeGvMY649xo=; b=fF4++0IX9KxowwMCM1KZripNGjTNbE5ZjFuuxuQRbZfhkBh28JrewXZbBLWn8IS8rK fTFzZBiuGmApemfbdxsUCPC15B89fhnX1k1qLlYlRKKyHQultbnnBua7+K9cvtzMYYUe nhuxRT7MysJSq9Aqcy5esFAfm0pqx9OHGgsrZKmFAqD/H89Ul13oEHdgE8OmTrkaLaV0 ZWZ11cwlIO4YUgI9Bmkp79vX7T3PiVukp+C1L3bLFo4GSZw1HXQxScQIGkKFjnon2M4A AyQraXFebX4Ezymj8/gD4917Y5j1BLnpzG3jayAQaZMXYXa7ufhqkz60YXD2nqA5LDLA uv5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UojGCpH5K3RrHd5m15zt9lvTn9YsSLGvqeGvMY649xo=; b=HJtiNcsG7KMeujorG5N3+T3TgrYelkmiTASS6yyLqWq6QJUXH4suqHjTWN8miV21SB S3g0SZtdmet08bpg3grdzWS4VLDrwcRTcx4kWqM5BWrioQylRvXtnwyxQBRHQ+1vH5Un ewFROP4rWJ0CouI1zP9+EA8utCPQYsqooCXhteXOPGJBHcrtaXymwJ5ssb8IGOk0/Rvl tRX4XeVr3czB/XUzCKudH8ykrKz739pkdFeeWTkcBDSnwkKT1sVqzf2SIS6rLbs+ZedB U98BROspuwWrsdkjo46XsWo10HddT08QJDX+53HQRb2eK8zRqkKZ5/yLxRUaULaWMHtz Hb6w==
X-Gm-Message-State: APjAAAWYa8zloUImRmUnv2J3FUFr9riGAOCeZj+7xmyKsb5jyKlqRXI4 JX1muOj6Q7vsLkiIA6L4q1rbnwifgChz8xEp/mg=
X-Google-Smtp-Source: APXvYqyxN1iG60HjjRSYzFmeCUc5G6KASfO7ak4A0CsqgxOIZvBOHveod1WjPGG7s1wXZXPaBYcaju1oa3aJDSzCvKo=
X-Received: by 2002:a2e:654d:: with SMTP id z74mr2538397ljb.111.1559680825406; Tue, 04 Jun 2019 13:40:25 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Tue, 4 Jun 2019 13:40:13 -0700
Message-ID: <>
Subject: Re: Opsdir last call review of draft-ietf-bfd-vxlan-07
To: =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= <>
Cc:, rtg-bfd WG <>,, IETF list <>
Content-Type: multipart/alternative; boundary="0000000000008fba59058a857d2b"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Jun 2019 20:40:29 -0000

Hi Jurgen,
thank you for your review, detailed and precise questions. Please find my
answers in-line and tagged GIM>>.


On Tue, May 21, 2019 at 12:28 AM Jürgen Schönwälder via Datatracker <> wrote:

> 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?
GIM>> That has been somewhat of the way to bring the de-facto standard into
the IETF standardization process.

- 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.
GIM>> That might be useful, thank you. But, AFAIK, at IETF that is not the
traditional format (though I know that other SDOs refer to the source of
the definition used in the document.)

> - Section 3 starts talking about VNI numbers but acronym VNI has not
>   been introduced before. I assume VNI = VXLAN Network Identifier.
GIM>> Thank you. Adding to the Terminology "VXLAN Network Identifier (or
VXLAN Segment ID)" and will expand on the first use.

> - 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.
GIM>> One of the ways could be through exchange of the BFD packets when the
DA MAC is the dedicated MAC. More on that below.

> - 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.
GIM> Would the following text added at the end of Section 4.1 address your
The use of the dedicated MAC allows starting BFD session before
 learning the MAC address of the remote VTEP. As a result, after the
 BFD session has reached the Up state the operational state of the
 VXLAN tunnel to may be set to Up.

> - 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?
GIM>> I agree, that is too vague. Would changing the  text to recommend
that the control mechanism be provided if multiple BFD sessions between the
same piar of VTEP allowed:
   The implementation SHOULD have a reasonable upper bound on the number
   of BFD sessions that can be created between the same pair of VTEPs.
   If the implementation supports establishing multiple BFD sessions
   between the same pair of VTEPs, there SHOULD be a mechanism to control
   the maximum number of such session that can be active at the same

> - 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?
GIM>> For p2p VXLAN tunnel, the Asynchronous mode of BFD is recommended:
The asynchronous mode of BFD, as defined in [RFC5880],
   can be used to monitor a p2p VXLAN tunnel.
The Demand mode is used in RFC 8293 that is recommended if the Multicast
Service Node resides behind the NVE:
   In the case where a Multicast Service Node (MSN) (as described in
   Section 3.3 of [RFC8293]) resides behind an NVE, the mechanisms
   described in this document apply and can, therefore, be used to test
   the connectivity from the source NVE to the MSN.

> - Why is echo BFD outside the scope of this document? Can I just turn
>   on echo mode or will extra specifications be needed?
GIM>> The BFD Echo mode is underspecified in RFC 5880. To achieve
interoperability we need to standardize it first.