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

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 22 October 2019 13:06 UTC

Return-Path: <jmh@joelhalpern.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 DBA44120255; Tue, 22 Oct 2019 06:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 xLl_JvNHjWN7; Tue, 22 Oct 2019 06:06:04 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 27631120227; Tue, 22 Oct 2019 06:06:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 46yDK80X56zTgDG; Tue, 22 Oct 2019 06:06:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1571749564; bh=hw7g4FmiZZoz4siT11FRa44SgTtJGTQSs0La2QHfVOo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=orDzAsoXPrGqQPvCIeCfaB0rLZmE0u+Q1Cf35EaEwKmiCA23HCPnkxuK7yUpmIRzU hUX2/NISAQVgJZnwNDzmF8PUAHM9rBFr6OJnS5YqjS9DNnVyYQ4eVvstep37/kcznr glHRaSEUT3r8+SSfsmEwyyrWNUkF2tRtHBlKoGQw=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.195.197.206] (unknown [135.245.111.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 46yDK50X2vzFps2; Tue, 22 Oct 2019 06:06:00 -0700 (PDT)
Subject: Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Jeffrey Haas <jhaas@pfrc.org>, 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>, "T. Sridhar" <tsridhar@vmware.com>, nvo3@ietf.org
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com> <201909251039413767352@zte.com.cn> <CACi9rdv-760M8WgZ1mOOOa=yoJqQFP=vdc3xJKLe7wCR18NSvA@mail.gmail.com> <20191021210752.GA8916@pfrc.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <0e99a541-b2ca-85d4-4a8f-1165cf7ac01e@joelhalpern.com>
Date: Tue, 22 Oct 2019 09:05:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191021210752.GA8916@pfrc.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/rtulL_pkk74_-SNZpq8q6wLda5E>
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 13:06:06 -0000

 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