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

Greg Mirsky <gregimirsky@gmail.com> Tue, 04 June 2019 20:40 UTC

Return-Path: <gregimirsky@gmail.com>
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 4437E1202E7; Tue, 4 Jun 2019 13:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 aX4bpqZtNMqC; Tue, 4 Jun 2019 13:40:27 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3811912004C; Tue, 4 Jun 2019 13:40:27 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id 131so8487538ljf.4; Tue, 04 Jun 2019 13:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <155842371303.2459.12357511675299405749@ietfa.amsl.com>
In-Reply-To: <155842371303.2459.12357511675299405749@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 4 Jun 2019 13:40:13 -0700
Message-ID: <CA+RyBmXL7AOv5pJpsOzLZ-_G9TUSO579sf_DqxXgiR8yWJhV_Q@mail.gmail.com>
Subject: Re: Opsdir last call review of draft-ietf-bfd-vxlan-07
To: =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= <j.schoenwaelder@jacobs-university.de>
Cc: ops-dir@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, draft-ietf-bfd-vxlan.all@ietf.org, IETF list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008fba59058a857d2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/hCB_8UQcPvZ0n7cyifprLlwYeyw>
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: 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>>.

Regards,
Greg

On Tue, May 21, 2019 at 12:28 AM Jürgen Schönwälder via Datatracker <
noreply@ietf.org>; 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
question:
NEW TEXT:
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:
OLD TEXT:
   The implementation SHOULD have a reasonable upper bound on the number
   of BFD sessions that can be created between the same pair of VTEPs.
NEW TEXT:
   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
   time.

>
> - 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.