Re: BFD over VXLAN: Trapping BFD Control packet at VTEP

Jeffrey Haas <jhaas@pfrc.org> Mon, 21 October 2019 21:04 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 A9D15120019; Mon, 21 Oct 2019 14:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 4buQdWS0oQkA; Mon, 21 Oct 2019 14:04:27 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A3FED12090B; Mon, 21 Oct 2019 14:04:27 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id EFE681E2D3; Mon, 21 Oct 2019 17:07:52 -0400 (EDT)
Date: Mon, 21 Oct 2019 17:07:52 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Santosh P K <santosh.pallagatti@gmail.com>
Cc: xiao.min2@zte.com.cn, Greg Mirsky <gregimirsky@gmail.com>, draft-ietf-bfd-vxlan@ietf.org, Dinesh Dutt <didutt@gmail.com>, rtg-bfd WG <rtg-bfd@ietf.org>, Joel Halpern <jmh@joelhalpern.com>, "T. Sridhar" <tsridhar@vmware.com>, bfd-chairs@ietf.org, nvo3@ietf.org
Subject: Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
Message-ID: <20191021210752.GA8916@pfrc.org>
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com> <201909251039413767352@zte.com.cn> <CACi9rdv-760M8WgZ1mOOOa=yoJqQFP=vdc3xJKLe7wCR18NSvA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACi9rdv-760M8WgZ1mOOOa=yoJqQFP=vdc3xJKLe7wCR18NSvA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/psIUo9c6Wu5W_bca_U8eEGQUHCg>
X-Mailman-Approved-At: Mon, 21 Oct 2019 14:05:22 -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: Mon, 21 Oct 2019 21:04:30 -0000

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