IETF Logo Mail Archive

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

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 22 October 2019 19:30 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 27706120077; Tue, 22 Oct 2019 12:30:50 -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 vMizKFrRAQAz; Tue, 22 Oct 2019 12:30:46 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 A3DE8120041; Tue, 22 Oct 2019 12:30:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 46yNs21JdDz16Hyr; Tue, 22 Oct 2019 12:30:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1571772646; bh=XoWEM3k+baJUMHPDABuW6OIbl4RwMIAYyYm0oDjDbYg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nx6eYQlg6UJepFJ2BxyaKR2/wlOxa5RMppnKFzqBGc8ozye7cVCejvK+WCFpYt0Zu L4Nplh5/6tic2qqNOnIXFiUAzKCr1R8HwKO8wL9M0RaJVAm42ZsvjEKAZqNtzjeKPE 7GXL42sIHG8MYeaj9PpWPIKh4u+Noyc+8w74HFnA=
X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id 46yNrz4gW5z16Hxf; Tue, 22 Oct 2019 12:30:43 -0700 (PDT)
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Anoop Ghanwani <anoop@alumni.duke.edu>, 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> <0b45df12-a7c5-3b5c-db59-5a57c8dfd1b7@joelhalpern.com> <CA+RyBmV9Ynk6fZy6qkvkOz3Pm2AmK7ESy8KoEpqyxP1nvNka0w@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <14ec7c38-5a5b-83dd-b4f4-71a29494ebdc@joelhalpern.com>
Date: Tue, 22 Oct 2019 15:30:39 -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+RyBmV9Ynk6fZy6qkvkOz3Pm2AmK7ESy8KoEpqyxP1nvNka0w@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/b2tPOoeLMSiDQHK2gaQ_CHw3mD0>
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:30:50 -0000

As I recall, the VNI is not in the same place nor the same size as the 
TCP / UDP ports.  So it seems very unlikely that it would be used in 
ECMP.  In fact, avoiding that is why VXLAN does interesting things with 
the source UDP port.  Which the BFD can do.  And presumably MUST do if 
it was path matching.

Yours,
Joel

On 10/22/2019 3:16 PM, Greg Mirsky wrote:
> Hi Joel,
> if the underlay may balance VXLAN between two VTEPs using VNI in 
> addition to other fields, then Option 2 has a certain value in my opinion.
> 
> Regards,
> Greg
> 
> On Tue, Oct 22, 2019 at 3:06 PM Joel M. Halpern <jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>> wrote:
> 
>     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>
>      > <mailto: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>
>      >     <mailto: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>
>      >         <mailto: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> <mailto:nvo3@ietf.org
>     <mailto:nvo3@ietf.org>>
>      > https://www.ietf.org/mailman/listinfo/nvo3
>      >
>

v2.23.0 | Report a Bug | By Email