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

<xiao.min2@zte.com.cn> Wed, 23 October 2019 02:43 UTC

Return-Path: <xiao.min2@zte.com.cn>
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 5579412006D; Tue, 22 Oct 2019 19:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 lrEPXFODfzdp; Tue, 22 Oct 2019 19:43:35 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 D8620120048; Tue, 22 Oct 2019 19:43:34 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id AB449CEFF39C0E619070; Wed, 23 Oct 2019 10:43:31 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl1.zte.com.cn with SMTP id x9N2g9Hp034826; Wed, 23 Oct 2019 10:42:09 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Wed, 23 Oct 2019 10:42:09 +0800 (CST)
Date: Wed, 23 Oct 2019 10:42:09 +0800 (CST)
X-Zmail-TransId: 2afa5dafbe0183310913
X-Mailer: Zmail v1.0
Message-ID: <201910231042093577255@zte.com.cn>
In-Reply-To: <CA+-tSzyHgspKBfLWZ3C69EBb+-k-POqJ7vG7VoN=g077+qzGBA@mail.gmail.com>
References: CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com, CACi9rdv-760M8WgZ1mOOOa=yoJqQFP=vdc3xJKLe7wCR18NSvA@mail.gmail.com, 0e99a541-b2ca-85d4-4a8f-1165cf7ac01e@joelhalpern.com, CA+RyBmVcBgeoGc2z5Gv0grv8OY34tyw+T-T-W2vn1O3AxCSQ9Q@mail.gmail.com, CA+-tSzyHgspKBfLWZ3C69EBb+-k-POqJ7vG7VoN=g077+qzGBA@mail.gmail.com
Mime-Version: 1.0
From: <xiao.min2@zte.com.cn>
To: <anoop@alumni.duke.edu>
Cc: <gregimirsky@gmail.com>, <jmh@joelhalpern.com>, <jhaas@pfrc.org>, <santosh.pallagatti@gmail.com>, <nvo3@ietf.org>, <draft-ietf-bfd-vxlan@ietf.org>, <didutt@gmail.com>, <rtg-bfd@ietf.org>, <tsridhar@vmware.com>
Subject: =?UTF-8?B?UmU6W252bzNdIEJGRCBvdmVyIFZYTEFOOiBUcmFwcGluZyBCRkQgQ29udHJvbCBwYWNrZXQgYXQgVlRFUA==?=
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn x9N2g9Hp034826
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/dI9Kg1sZBJV8n8zB2jcFkALvaMg>
X-Mailman-Approved-At: Wed, 23 Oct 2019 11:02:10 -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, 23 Oct 2019 02:43:38 -0000

Yes, what I discussed with Anoop was on Greg's option #3.


Respecting BFD over VxLAN, option #2 and #3 both are ok to me, I have no preference.


Respecting BFD over Geneve, option #2 and #3 both are ok to me, although I personally prefer #3.







Best Regards,


Xiao Min










原始邮件



发件人:AnoopGhanwani <anoop@alumni.duke.edu>
收件人:Greg Mirsky <gregimirsky@gmail.com>om>;
抄送人:Joel M. Halpern <jmh@joelhalpern.com>;Jeffrey Haas <jhaas@pfrc.org>;Santosh P K <santosh.pallagatti@gmail.com>;NVO3 <nvo3@ietf.org>;draft-ietf-bfd-vxlan@ietf.org <draft-ietf-bfd-vxlan@ietf.org>;Dinesh Dutt <didutt@gmail.com>;rtg-bfd WG <rtg-bfd@ietf.org>;T>;T. Sridhar <tsridhar@vmware.com>;肖敏10093570;Yes
日 期 :2019年10月23日 07:05
主 题 :Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP





Greg,

I think the draft is fine as is.


I discussion with Xiao Min was about #3 and I see that as unnecessary until we have a draft that explains why that is needed in the context of the NVO3 architecture.


Anoop




On Tue, Oct 22, 2019 at 11:17 AM Greg Mirsky <gregimirsky@gmail.com> 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:
single BFD session between two VTEPs

single BFD session per VNI between two VTEPs

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> 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> 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