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

Anoop Ghanwani <anoop@alumni.duke.edu> Tue, 22 October 2019 18:09 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 9A8CD1208DE; Tue, 22 Oct 2019 11:09:20 -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 p7tcnYVNf6Fw; Tue, 22 Oct 2019 11:09:18 -0700 (PDT)
Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) (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 8651B1208F7; Tue, 22 Oct 2019 11:09:18 -0700 (PDT)
Received: by mail-ua1-f44.google.com with SMTP id j5so5187732uak.12; Tue, 22 Oct 2019 11:09:18 -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=zqQSWX0W+LrNHEGNmdRLV31ljY2pZgx6KrvD264KQWA=; b=tchNeyNZByUur783fmcMeCxyFgT1ZCbfAtoVrgwxEM8+5F+ldpQccBXgs3UZrm+npr 3P9BOEuAerLJU4GlHD5wQhxrsMs57tAh4XGANiz73gzk/3NYt7CduBYQ8PnkzX6pJk0D 7sOPkYKU1redDzTPAVc1xd1h7au/bOCTt7WeGzq/shy+sjw06Ssfj2wyFMdfbYEeF/wi 9xDkcAyAZ/0e9SDeDKxV2LLsiON9vzGViX1eLeczM9lR++0QawNLvvfGYOi4t4kFGUU0 19cxhkA+ew+sLZiDr9pLnc8TsuNwWuADn0Fk80ZrEf6GYYQllMXlkLf84UauEcrVr11N cW2w==
X-Gm-Message-State: APjAAAUUcG4yZ0KWLVvlH89tkJyVtI8KtR4/Hi8rE3mhlElFNpLMG2IB Z+Vntvd/CtVXhk6V5e2zZjgbN+yhtZgOf+Lq84E=
X-Google-Smtp-Source: APXvYqwldIaJYz3Yxd5yIDUqRzbOjDqaErqD/UsphZ1xiJeTXZYVWmcgVwHx29WLL653BOtKUMjL4k+wU8l4PCrw150=
X-Received: by 2002:a9f:23ea:: with SMTP id 97mr2678361uao.141.1571767757254; Tue, 22 Oct 2019 11:09:17 -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>
In-Reply-To: <0e99a541-b2ca-85d4-4a8f-1165cf7ac01e@joelhalpern.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Tue, 22 Oct 2019 11:09:05 -0700
Message-ID: <CA+-tSzziDc+Tk8AYfOr5-Xn6oO_uqW2C1dRA9LLOBBVmzVhWEQ@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, Santosh P K <santosh.pallagatti@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, 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="000000000000d73868059583b228"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/E6jZBxMKa0BQUM1jn28ErHbV9pE>
X-Mailman-Approved-At: Tue, 22 Oct 2019 14:45:18 -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 18:09:21 -0000

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
>