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

Anoop Ghanwani <anoop@alumni.duke.edu> Thu, 26 September 2019 15:16 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 1D68712021D; Thu, 26 Sep 2019 08:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ER8QR47hoOVD; Thu, 26 Sep 2019 08:16:42 -0700 (PDT)
Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (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 80EB61201A3; Thu, 26 Sep 2019 08:16:42 -0700 (PDT)
Received: by mail-vs1-f51.google.com with SMTP id b123so1865218vsb.5; Thu, 26 Sep 2019 08:16:42 -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=8vEN964jrxKjC0AkIqPEYSBDMqGN5h8RxGIz6SChypA=; b=g9N8CE7IRzq6o3m8m2n2rK8ZqTWIxc8mEQX5o8QBYUGMntKHkPwdtuuLoGMS/W14fo J7KwQxn93hOB6e6O3qIMpTw9H7lWADdlC8cJW9k4aEjs6GBCkrOhcE6w73b1taTg2N66 HZqPusghdeq7QkhqdIALXCg8IHRlB5PbCvtjj3qqGxI8SPXfwu6p2i+PFPGK6uvYHvDN xQN48Lbenbhdwu2MshB3L2I6jKC1p7QhxKiO8wseuzsysxsD9mNP9K4qruiQdgwdXYTY LvNNQ1PXYq0u/IDlWLRL30BXWGUJF39IR+3FjOZYdoy38891XO+LSdBJi05mXMaOgOjG c6Fw==
X-Gm-Message-State: APjAAAVV1UeGliEyPkijlvgbM6mH2rhj9YO3MmNUZ94MKDhjZ2BQWvHX K2i+UsWtXILFYTpOZJx+KC0ShquLaLKjxXQF1F8=
X-Google-Smtp-Source: APXvYqwPFzL+iX3ZS99Ch0q2IM7duQogj3uIy+NYUXfaPRADC5IZni189qmJIkR1i5SboNR31it2ssXd7oZ3MiI8niw=
X-Received: by 2002:a05:6102:2ca:: with SMTP id h10mr1986045vsh.228.1569511001403; Thu, 26 Sep 2019 08:16:41 -0700 (PDT)
MIME-Version: 1.0
References: <CA+-tSzxqA26RVbRRmX43v9yFkMpe94DEmOze9JD+m=Nj9USQ0Q@mail.gmail.com> <201909261436151696571@zte.com.cn>
In-Reply-To: <201909261436151696571@zte.com.cn>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Thu, 26 Sep 2019 08:16:30 -0700
Message-ID: <CA+-tSzxoPC07Z_Y=LxmLbmC=__NQSK2+r_0jSH53baN+hXExEQ@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: xiao.min2@zte.com.cn
Cc: Greg Mirsky <gregimirsky@gmail.com>, didutt@gmail.com, draft-ietf-bfd-vxlan@ietf.org, nvo3@ietf.org, santosh.pallagatti@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="000000000000b5b59505937641e5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/vwL9wsCCZOdewPD0ImqAE6tMznI>
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: Thu, 26 Sep 2019 15:16:46 -0000

Hi Xiao Min,

I think we would need more detail around the use case below.  What does the
MPLS packet over Tunnel look like?

Thanks,
Anoop

On Wed, Sep 25, 2019 at 11:37 PM <xiao.min2@zte.com.cn> wrote:

> Hi Anoop,
>
>
> Thanks for your comments.
>
> Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet over
> Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e. MAC-Frame
> over Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share one VAP?
>
>
> Best Regards,
>
> Xiao Min
> 原始邮件
> *发件人:*AnoopGhanwani <anoop@alumni.duke.edu>
> *收件人:*肖敏10093570;
> *抄送人:*Greg Mirsky <gregimirsky@gmail.com>;didutt@gmail.com <
> didutt@gmail.com>;draft-ietf-bfd-vxlan@ietf.org <
> draft-ietf-bfd-vxlan@ietf.org>;nvo3@ietf.org <nvo3@ietf.org>rg>;
> santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>;rtg-bfd WG <
> rtg-bfd@ietf.org>;Joel M. Halpern <jmh@joelhalpern.com>om>;
> tsridhar@vmware.com <tsridhar@vmware.com>;bfd-chairs@ietf.org <
> bfd-chairs@ietf.org>gt;;
> *日 期 :*2019年09月26日 08:36
> *主 题 :**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP*
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>
> >>>
> 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
>>
>
>