Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

Anoop Ghanwani <anoop@alumni.duke.edu> Tue, 22 October 2019 23:05 UTC

Return-Path: <ghanwani@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 86DB312006A; Tue, 22 Oct 2019 16:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.226, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 a2tW65WtL0TF; Tue, 22 Oct 2019 16:05:45 -0700 (PDT)
Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) (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 5357612001E; Tue, 22 Oct 2019 16:05:45 -0700 (PDT)
Received: by mail-ua1-f54.google.com with SMTP id u31so5447658uah.0; Tue, 22 Oct 2019 16:05:45 -0700 (PDT)
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=asCXrxeevewSIYyXd/LHyCertFF0hTggucXrIxlmDZ8=; b=JyZUUPNSoPwSt7+ESDcOOekS3g8V/ybgV5Xnxx/AjcUGmXRM9S6sps8bBoEaIA8Dye MU4KDTTKwuUs3dHcW0C4UfvJ1Zth4MOVdzMHSQzZntTkQHpAN+TT6Ud9L9IwV6GyDhKs RoeE4UuR1jVOLGZxajYGguvLs3Cm0/GZDsf45ShELdyK1NkBRDwcpHWpFGnxMCwQLHLC z6uTiFL0YeQs9mSAdptBR8zSwBRMfA65BmVP9oF8hX5lDtGm3UkuooBs7412jMs4YDHq 0/PHHfhwQw2ECudbtFnZVXw0dIkR5c3DJWjFkWrMtHpdv95fsaig48bvTRXGqCt3KQSy k0dA==
X-Gm-Message-State: APjAAAUs/MPQt2tTH+D/jaEFQrk7wrppQfbpC1EQjEi89Pm5//8fUuAT 3ca7Xx0bjkSYsWnqnItubKfmfo0ofJziBjpJU/E=
X-Google-Smtp-Source: APXvYqxWB6wDJXDhU2Is8mrWdC4QJjFcqqGsZsNmXAeFipMxP4r2DbN3HfGcS9SSezveWWSG+EVuhNJROAdGpp8StZw=
X-Received: by 2002:ab0:6409:: with SMTP id x9mr3537252uao.29.1571785544069; Tue, 22 Oct 2019 16:05:44 -0700 (PDT)
MIME-Version: 1.0
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com> <201909251039413767352@zte.com.cn> <CACi9rdv-760M8WgZ1mOOOa=yoJqQFP=vdc3xJKLe7wCR18NSvA@mail.gmail.com> <20191021210752.GA8916@pfrc.org> <0e99a541-b2ca-85d4-4a8f-1165cf7ac01e@joelhalpern.com> <CA+-tSzziDc+Tk8AYfOr5-Xn6oO_uqW2C1dRA9LLOBBVmzVhWEQ@mail.gmail.com> <CA+RyBmVcBgeoGc2z5Gv0grv8OY34tyw+T-T-W2vn1O3AxCSQ9Q@mail.gmail.com>
In-Reply-To: <CA+RyBmVcBgeoGc2z5Gv0grv8OY34tyw+T-T-W2vn1O3AxCSQ9Q@mail.gmail.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Tue, 22 Oct 2019 16:05:32 -0700
Message-ID: <CA+-tSzyHgspKBfLWZ3C69EBb+-k-POqJ7vG7VoN=g077+qzGBA@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, Jeffrey Haas <jhaas@pfrc.org>, Santosh P K <santosh.pallagatti@gmail.com>, NVO3 <nvo3@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, Dinesh Dutt <didutt@gmail.com>, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, xiao.min2@zte.com.cn
Content-Type: multipart/alternative; boundary="000000000000047745059587d725"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/QOB03IJdFVYfHUay1-nJ4MtkV8U>
X-Mailman-Approved-At: Wed, 23 Oct 2019 11:02:10 -0700
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, 22 Oct 2019 23:05:47 -0000

Greg,

I think the draft is fine as is.

I discussion with Xiao Min was about #3 and I see that as unnecessary until
we have a draft that explains why that is needed in the context of the NVO3
architecture.

Anoop

On Tue, Oct 22, 2019 at 11:17 AM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Anoop, et al.,
> I agree with your understanding of what is being defined in the current
> version of the BFD over VxLAN specification. But, as I understand, the WG
> is discussing the scope before the WGLC is closed. I believe there are
> three options:
>
>    1. single BFD session between two VTEPs
>    2. single BFD session per VNI between two VTEPs
>    3. multiple BFD sessions per VNI between two VTEPs
>
> The current text reflects #2. Is WG accepts this scope? If not, which
> option WG would accept?
>
> Regards,
> Greg
>
> On Tue, Oct 22, 2019 at 2:09 PM Anoop Ghanwani <anoop@alumni.duke.edu>
> wrote:
>
>> I concur with Joel's assessment with the following clarifications.
>>
>> The current document is already capable of monitoring multiple VNIs
>> between VTEPs.
>>
>> The issue under discussion was how do we use BFD to monitor multiple VAPs
>> that use the same VNI between a pair of VTEPs.  The use case for this is
>> not clear to me, as from my understanding, we cannot have a situation with
>> multiple VAPs using the same VNI--there is 1:1 mapping between VAP and VNI.
>>
>> Anoop
>>
>> On Tue, Oct 22, 2019 at 6:06 AM Joel M. Halpern <jmh@joelhalpern.com>
>> wrote:
>>
>>>  From what I can tell, there are two separate problems.
>>> The document we have is a VTEP-VTEP monitoring document.  There is no
>>> need for that document to handle the multiple VNI case.
>>> If folks want a protocol for doing BFD monitoring of things behind the
>>> VTEPs (multiple VNIs), then do that as a separate document.   The
>>> encoding will be a tenant encoding, and thus sesparate from what is
>>> defined in this document.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 10/21/2019 5:07 PM, Jeffrey Haas wrote:
>>> > Santosh and others,
>>> >
>>> > On Thu, Oct 03, 2019 at 07:50:20PM +0530, Santosh P K wrote:
>>> >>     Thanks for your explanation. This helps a lot. I would wait for
>>> more
>>> >> comments from others to see if this what we need in this draft to be
>>> >> supported based on that we can provide appropriate sections in the
>>> draft.
>>> >
>>> > The threads on the list have spidered to the point where it is
>>> challenging
>>> > to follow what the current status of the draft is, or should be.  :-)
>>> >
>>> > However, if I've followed things properly, the question below is
>>> really the
>>> > hinge point on what our encapsulation for BFD over vxlan should look
>>> like.
>>> > Correct?
>>> >
>>> > Essentially, do we or do we not require the ability to permit multiple
>>> BFD
>>> > sessions between distinct VAPs?
>>> >
>>> > If this is so, do we have a sense as to how we should proceed?
>>> >
>>> > -- Jeff
>>> >
>>> > [context preserved below...]
>>> >
>>> >> Santosh P K
>>> >>
>>> >> On Wed, Sep 25, 2019 at 8:10 AM <xiao.min2@zte.com.cn> wrote:
>>> >>
>>> >>> Hi Santosh,
>>> >>>
>>> >>>
>>> >>> With regard to the question whether we should allow multiple BFD
>>> sessions
>>> >>> for the same VNI or not, IMHO we should allow it, more explanation as
>>> >>> follows.
>>> >>>
>>> >>> Below is a figure derived from figure 2 of RFC8014 (An Architecture
>>> for
>>> >>> Data-Center Network Virtualization over Layer 3 (NVO3)).
>>> >>>
>>> >>>                      |         Data Center Network (IP)        |
>>> >>>                      |                                         |
>>> >>>                      +-----------------------------------------+
>>> >>>                           |                           |
>>> >>>                           |       Tunnel Overlay      |
>>> >>>              +------------+---------+       +---------+------------+
>>> >>>              | +----------+-------+ |       | +-------+----------+ |
>>> >>>              | |  Overlay Module  | |       | |  Overlay Module  | |
>>> >>>              | +---------+--------+ |       | +---------+--------+ |
>>> >>>              |           |          |       |           |          |
>>> >>>       NVE1   |           |          |       |           |          |
>>> NVE2
>>> >>>              |  +--------+-------+  |       |  +--------+-------+  |
>>> >>>              |  |VNI1 VNI2  VNI1 |  |       |  | VNI1 VNI2 VNI1 |  |
>>> >>>              |  +-+-----+----+---+  |       |  +-+-----+-----+--+  |
>>> >>>              |VAP1| VAP2|    | VAP3 |       |VAP1| VAP2|     | VAP3|
>>> >>>              +----+-----+----+------+       +----+-----+-----+-----+
>>> >>>                   |     |    |                   |     |     |
>>> >>>                   |     |    |                   |     |     |
>>> >>>                   |     |    |                   |     |     |
>>> >>>            -------+-----+----+-------------------+-----+-----+-------
>>> >>>                   |     |    |     Tenant        |     |     |
>>> >>>              TSI1 | TSI2|    | TSI3          TSI1| TSI2|     |TSI3
>>> >>>                  +---+ +---+ +---+             +---+ +---+   +---+
>>> >>>                  |TS1| |TS2| |TS3|             |TS4| |TS5|   |TS6|
>>> >>>                  +---+ +---+ +---+             +---+ +---+   +---+
>>> >>>
>>> >>> To my understanding, the BFD sessions between NVE1 and NVE2 are
>>> actually
>>> >>> initiated and terminated at VAP of NVE.
>>> >>>
>>> >>> If the network operator want to set up one BFD session between VAP1
>>> of
>>> >>> NVE1 and VAP1of NVE2, at the same time another BFD session between
>>> VAP3 of
>>> >>> NVE1 and VAP3 of NVE2, although the two BFD sessions are for the same
>>> >>> VNI1, I believe it's reasonable, so that's why I think we should
>>> allow it
>>>
>>> _______________________________________________
>>> nvo3 mailing list
>>> nvo3@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>
>>