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

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 22 October 2019 19:06 UTC

Return-Path: <jmh@joelhalpern.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 F26A912082F; Tue, 22 Oct 2019 12:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 fUSAABhR8WTT; Tue, 22 Oct 2019 12:06:38 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21104120862; Tue, 22 Oct 2019 12:06:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 46yNKB0K05zTgTf; Tue, 22 Oct 2019 12:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1571771198; bh=Gw/S3QLLMnX/YsLl9O6Dc4z+k6EJ9+EqAX8+uCfypSk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=P8GqujZg9LLZ6UMgHJQZ+qD+yweUqUHOhqrSilBeA1EWO+5Pq4YjsCvXSQRZRRpdg etk63N/qS1x52juk2KU8cle+321P1UXYSDaGJBVpeV2c9ueh4r3uTIZ7n7Z2cJUwDv PIAzqi3Fdwv+JhYw0qwuL6hROtD8EG84jv9svUjw=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.195.197.206] (unknown [135.245.111.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 46yNK74vF8zTgSM; Tue, 22 Oct 2019 12:06:35 -0700 (PDT)
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Greg Mirsky <gregimirsky@gmail.com>, Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: 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
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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <0b45df12-a7c5-3b5c-db59-5a57c8dfd1b7@joelhalpern.com>
Date: Tue, 22 Oct 2019 15:06:33 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CA+RyBmVcBgeoGc2z5Gv0grv8OY34tyw+T-T-W2vn1O3AxCSQ9Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/hGYpMYNcTKY-NVsqSePfwxzs0oY>
X-Mailman-Approved-At: Tue, 22 Oct 2019 14:45:08 -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 19:06:41 -0000

I do not understand the value of option 2.
Which is why I asked in my initial review to move to option 1.

And option 2 requires stealing MAC addresses from the users, which seems 
to me to be a very bad thing that option 1 avoids.

Yours,
Joel

On 10/22/2019 2:17 PM, Greg Mirsky 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 
> <mailto: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
>     <mailto: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
>         <mailto: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 <mailto:nvo3@ietf.org>
>         https://www.ietf.org/mailman/listinfo/nvo3
>