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

Anoop Ghanwani <anoop@alumni.duke.edu> Wed, 25 September 2019 23:29 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 562D71201C6; Wed, 25 Sep 2019 16:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, 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 NYpozuovoGga; Wed, 25 Sep 2019 16:29:25 -0700 (PDT)
Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.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 F38B112082D; Wed, 25 Sep 2019 16:29:24 -0700 (PDT)
Received: by mail-vs1-f44.google.com with SMTP id w195so310619vsw.11; Wed, 25 Sep 2019 16:29:24 -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=hV0IhxFEhVM1zJwDgOkiobFjSNrSL7SOljJ+G8YSNiM=; b=aNjNcWUxDJ+MVtE3CPqvVuhN7tVnDoJ8cbfKkFJBfZfVobPHMLXd0nx+udNFn5Xpcu LSD0+f6VVJjkEyGjYDOKLrL0AMayap1IuZctAmbrWd2ObC3cfpdEdzW38vrcHxJSZXrM DIPX4w/+88SGTvctIBBJ0vM/9oR6uQailvgR+DPfl3GU0Qdor8MslROles+b/9MYg0On N0VUeYm8nIshgI2tEUi5Ac03kFGShbnLzqAfTZHkkjYQFIqosWNYqehhxkl0Ee4WRY0e YTOsnZDfCDTaRk9HwDW62CppyfH4KsaLZ37WiYxoQnCGOo27GWmzofIIi7GVxTv1oh9w 41mg==
X-Gm-Message-State: APjAAAVNgfrWgiHeRuvqtjH8oIWUPh8tfWBMcS9ADcpuVUrVtWxISGt7 gRwJxY3opFG8b9pski/AZ4MVHQjHeeKetyfvWYc=
X-Google-Smtp-Source: APXvYqw8FW8KfPTgbuEU9RLrMte+qhq6zNODf8VgDNVjtrBrlWu90SwDjH+FD3675z961OorR8uH6OOQ7ohjJoNlkic=
X-Received: by 2002:a67:ed47:: with SMTP id m7mr602693vsp.60.1569454163948; Wed, 25 Sep 2019 16:29:23 -0700 (PDT)
MIME-Version: 1.0
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com> <201909251039413767352@zte.com.cn>
In-Reply-To: <201909251039413767352@zte.com.cn>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Wed, 25 Sep 2019 16:29:12 -0700
Message-ID: <CA+-tSzxqA26RVbRRmX43v9yFkMpe94DEmOze9JD+m=Nj9USQ0Q@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: xiao.min2@zte.com.cn
Cc: santosh.pallagatti@gmail.com, Greg Mirsky <gregimirsky@gmail.com>, nvo3@ietf.org, draft-ietf-bfd-vxlan@ietf.org, didutt@gmail.com, rtg-bfd WG <rtg-bfd@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, tsridhar@vmware.com, bfd-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000eef94005936905cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/KDWPBo-kZ5fmE6VxyOeJuXfVy58>
X-Mailman-Approved-At: Thu, 26 Sep 2019 08:46:14 -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: Wed, 25 Sep 2019 23:29:28 -0000

>>>
Some people may argue that all Tenant Systems connecting to the same
Virtual Network MUST share one VAP, if that's true, then VAP1 and VAP3
should merge into one VAP and my explanation doesn't work. Copying to NVO3
WG to involve more experts, hope for your clarifications and comments.
>>>

I would be one of those that would argue that they MUST share on VAP if
they connect to the same Virtual Network.  IMO, the NVO3 arch doc should
have been clearer about this.

Thanks,
Anoop

On Tue, Sep 24, 2019 at 7:40 PM <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.
>
>
> Of course, in RFC8014 it also says:
>
> "Note that two different Tenant Systems (and TSIs) attached to a common NVE can share a VAP (e.g., TS1 and TS2 in Figure 2) so long as they connect to the same Virtual Network."
>
> Some people may argue that all Tenant Systems connecting to the same
> Virtual Network MUST share one VAP, if that's true, then VAP1 and VAP3
> should merge into one VAP and my explanation doesn't work. Copying to NVO3
> WG to involve more experts, hope for your clarifications and comments.
>
>
> Best Regards,
>
> Xiao Min
>