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

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 28 October 2019 19:55 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 56BE412006D; Mon, 28 Oct 2019 12:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] 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 zZ6UZREyku4N; Mon, 28 Oct 2019 12:55:30 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 7C75212004E; Mon, 28 Oct 2019 12:55:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47256p3Bq9z15KPf; Mon, 28 Oct 2019 12:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572292530; bh=po0f99wOAqEKgtFvrJdBqXCxRxqZYXfdkjW2xDHsc9o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=e+R9qYis5JWR9jXp9Fg4Q0oBDd+krFCG9yBi0ohXoQH5KtgtRtsMw72U1np6mSQup w/X6yDVwNMngx3D/4MI9u3eH0z1YG+VKk2dYOZMT0C1VY61jKbKcT5RkbuIUrEhAmt feFK6F3llqajVs07cFUA0mCa0u+a5m5Vkz8+GH0E=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 47256m1crSzKmq7; Mon, 28 Oct 2019 12:55:27 -0700 (PDT)
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: Santosh P K <santosh.pallagatti@gmail.com>, Dinesh Dutt <didutt@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, Jeffrey Haas <jhaas@pfrc.org>, NVO3 <nvo3@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, xiao.min2@zte.com.cn
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com> <CA+-tSzyHgspKBfLWZ3C69EBb+-k-POqJ7vG7VoN=g077+qzGBA@mail.gmail.com> <1571795542.10436.5@smtp.gmail.com> <CA+RyBmXkyQMumeCDxM6OSzdn=DCL=aeyQ+tJmUiyEg0VZuUpRg@mail.gmail.com> <1571798869.2855.1@smtp.gmail.com> <CACi9rduyvhweJd_aNx6miiUGyu-nCeqnNHGbPjyCfswHx1RD5A@mail.gmail.com> <CA+RyBmXLBLARxhA4MUvD6DE8vvY1oDP0opkxDqiPA4zYw9Jpug@mail.gmail.com> <1571860470.2855.11@smtp.gmail.com> <CACi9rdtwiuH2VjuUkzeg3+PhwcFMSqFepbcM0tgmRxSbcR3AQQ@mail.gmail.com> <CA+-tSzyi=uDdqSDq4u7kytAucX136mO2XtPtR=DG+KKAC5PjCQ@mail.gmail.com> <88a1320e-093a-a101-d8a6-6ae6d7648466@joelhalpern.com> <CA+-tSzxCpLOmhpBXP1k5vLY20qA5db9nbq4qEiH00jo=EH+w8g@mail.gmail.com> <d7b25f3a-5f1e-30da-8a41-0d11e3c2d04c@joelhalpern.com> <CA+-tSzzBfp9Wy8KO6MbxFNXZBhC3bL7u92VwqJTA82WrwGUAgg@mail.gmail.com> <c773cd4f-320c-fb15-3b7b-d0016b7d5978@joelhalpern.com> <CA+-tSzxUs9PGv+y1PBquaAhuq4wK_=TkR+b_ET6j7OBHf4Mq7Q@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <97bdb8b4-b334-53fb-05a6-2d1fc8684ad3@joelhalpern.com>
Date: Mon, 28 Oct 2019 15:55:25 -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: <CA+-tSzxUs9PGv+y1PBquaAhuq4wK_=TkR+b_ET6j7OBHf4Mq7Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/x7mhfvTrewYtLja4nPA2eMcDcls>
X-Mailman-Approved-At: Tue, 29 Oct 2019 11:54: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: Mon, 28 Oct 2019 19:55:36 -0000

You are saying that there are existing implementations using VNI 0 for 
this?  Given that previous versions of the spec explicitly disallowed 
VNI 0, I am having trouble with your objecting that a spec for how to 
run over VNI 0 breask existing implementations.

Note that when there is a good technical reason, the IETF does change 
Internet Drafts in ways that break early implementations.  That is the 
price of standardization.

Yours,
Joel

On 10/28/2019 2:30 PM, Anoop Ghanwani wrote:
> Hi Joel,
> 
> Writing the spec in that way would make the current, inter-operable 
> implementation of multiple vendors non-compliant with the spec.
> 
> Thanks,
> Anoop
> 
> On Mon, Oct 28, 2019 at 11:07 AM Joel M. Halpern <jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>> wrote:
> 
>     I assumed this was only for the case where a tenant VNI was being used.
> 
>     For the 0 VNI (which is what I prefer), always (MUST) use the loopback
>     address.  There are no addresses assigned to the VTEP in that space.
>     There is no IRB in that space.
> 
>     Yours,
>     Joel
> 
>     On 10/28/2019 1:58 PM, Anoop Ghanwani wrote:
>      > Joel,
>      >
>      > Are we going to qualify this by VNI?  There's a bunch of
>     implementations
>      > out there that don't use a tenant IP or a loopback with VNI 0--they
>      > simply repeat the underlay IP in the inner IPDA.
>      >
>      > Thanks,
>      > Anoop
>      >
>      > On Mon, Oct 28, 2019 at 10:46 AM Joel M. Halpern
>     <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>      > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>> wrote:
>      >
>      >     I can live with saying that you SHOULD use loopback, and MAY
>     instead
>      >     use
>      >     an IP address in the customer space known to be owned by the VTEP
>      >     device
>      >     when such exists.
>      >
>      >     Yours,
>      >     Joel
>      >
>      >     On 10/28/2019 1:32 PM, Anoop Ghanwani wrote:
>      >      > Hi Joel,
>      >      >
>      >      > Perhaps we need to say use of an address owned by the device
>      >     containing
>      >      > the VTEP.
>      >      >
>      >      > Or are you suggesting that the use of the loopback address
>     space
>      >     is a MUST?
>      >      >
>      >      > Anoop
>      >      >
>      >      > On Mon, Oct 28, 2019 at 10:22 AM Joel M. Halpern
>      >     <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>      >      > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>> wrote:
>      >      >
>      >      >     There is something I am missing in your assumption
>     about IRB.
>      >      >
>      >      >     As I understand VxLAN, the VTEP is under the control
>     of the
>      >     operator.
>      >      >     As such, it is a pure bridge.  If you run IRB behind
>     it, that
>      >     is fine.
>      >      >     Yes, an operator may offer IRB.  But as I understand it,
>      >     conceptually,
>      >      >     in terms of the VxLAN architecture the IRB is an entity
>      >     behind the
>      >      >     VTEP,
>      >      >     not part of the VTEP.
>      >      >
>      >      >     Yours,
>      >      >     Joel
>      >      >
>      >      >     On 10/28/2019 12:23 PM, Anoop Ghanwani wrote:
>      >      >      > Santosh,
>      >      >      >
>      >      >      > Does it have to be a MUST?  What if I am running
>     IRB and there
>      >      >     are IP
>      >      >      > addresses per VNI assigned to the VTEPs?  Why can the
>      >     operator not
>      >      >      > choose to use those?
>      >      >      >
>      >      >      > Anoop
>      >      >      >
>      >      >      > On Mon, Oct 28, 2019 at 7:51 AM Santosh P K
>      >      >      > <santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>
>      >      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>>
>      >      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>
>      >      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>>>> wrote:
>      >      >      >
>      >      >      >     Dinesh, Anoop et all,
>      >      >      >           Lets us know if this text works for 127/8
>      >     address range?
>      >      >      >
>      >      >      >     [proposed text for firewall]
>      >      >      >
>      >      >      >     "As per section 4 inner destination IP address
>     MUST be
>      >     set to
>      >      >     127/8
>      >      >      >     address. There may be firewall configured on
>     VTEP to
>      >     block 127/8
>      >      >      >     address range if set as destination IP in inner IP
>      >     header. It is
>      >      >      >     recommended to allow 127/8 range address through
>      >     firewall only if
>      >      >      >     127/8 IP address is set as destination address
>     in inner IP
>      >      >     header."
>      >      >      >
>      >      >      >
>      >      >      >     In section 4 we are talking about using 127/8
>     and not
>      >     really
>      >      >     giving
>      >      >      >     reason why. I think we should have text as RFC 5884
>      >     has mentioned
>      >      >      >     with below text.
>      >      >      >
>      >      >      >     [From RFC 5884]
>      >      >      >     "The motivation for using the address range
>     127/8 is
>      >     the same as
>      >      >      >     specified in Section 2.1 of [RFC4379]
>      >      >      >     <https://tools.ietf.org/html/rfc4379#section-2.1>.
>      >     This is an
>      >      >      >     exception to the behavior defined in [RFC1122
>      >      >      >     <https://tools.ietf.org/html/rfc1122>]."
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >     Thanks
>      >      >      >     Santosh P K
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >     On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt
>      >     <didutt@gmail.com <mailto:didutt@gmail.com>
>     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>
>      >      >     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>
>     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>>
>      >      >      >     <mailto:didutt@gmail.com
>     <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
>     <mailto:didutt@gmail.com>>
>      >     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>
>     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>>>> wrote:
>      >      >      >
>      >      >      >         Looks good to me Greg. I see that the text
>     around
>      >     the use
>      >      >     of the
>      >      >      >         inner IP address as also quite acceptable. Will
>      >     you add any
>      >      >      >         words about the firewall?
>      >      >      >
>      >      >      >         Dinesh
>      >      >      >
>      >      >      >         On Wed, Oct 23, 2019 at 8:36 PM, Greg Mirsky
>      >      >      >         <gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>
>      >     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
>     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
>      >     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>
>      >      >     <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>>
>      >     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
>     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>>> wrote:
>      >      >      >>         Hi Dinesh, et al.,
>      >      >      >>         please check the updated version that
>     removed the
>      >      >     reference to
>      >      >      >>         Hypervisor in the text and Figure 1.
>      >      >      >>
>      >      >      >>         Regards,
>      >      >      >>         Greg
>      >      >      >>
>      >      >      >>         On Wed, Oct 23, 2019 at 10:47 AM Santosh P K
>      >      >      >>         <santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>
>      >      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>>
>      >      >      >>         <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>
>      >      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>      >     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>>>> wrote:
>      >      >      >>
>      >      >      >>             Dinesh,
>      >      >      >>                  Please see my inline comments [SPK]
>      >      >      >>
>      >      >      >>
>      >      >      >>                 - In section 3, there's a sentence
>     that
>      >     is: "BFD
>      >      >      >>                 packets intended for a Hypervisor
>     VTEP MUST
>      >      >     NOT..". I
>      >      >      >>                 recommend getting rid of the word
>      >     "Hypervisor" ashe
>      >      >      >>                 logic applies to any VTEP.
>      >      >      >>
>      >      >      >>             [SPK] Thanks for comments. We will
>     change this.
>      >      >      >>
>      >      >      >>                 - You already explained the
>     precedence of
>      >     the use of
>      >      >      >>                 127/8 address in the inner header in
>      >     MPLS. I have no
>      >      >      >>                 specific comments in that area. I have
>      >     only two
>      >      >      >>                 questions:
>      >      >      >>                    - Has anybody verified that the
>     use of
>      >     127/8
>      >      >      >>                 address (and the right MAC) works with
>      >     existing
>      >      >      >>                 implementations, including the silicon
>      >     ones? If this
>      >      >      >>                 doesn't work there, is it worth
>     adding the
>      >      >     possibilit
>      >      >      >>                 y of another address, one that is
>     owned
>      >     by the
>      >      >     VTEP node?
>      >      >      >>
>      >      >      >>                    - Do we know if Firewalls stop
>     such VXLAN
>      >      >     packets?
>      >      >      >>                 I ask this because VXLAN has an IP
>     header
>      >     and I
>      >      >     don't
>      >      >      >>                 know if firewalls stop packets
>     with 127/8
>      >     in the
>      >      >     inner
>      >      >      >>                 header. If not, is it worth adding a
>      >     sentence to say
>      >      >      >>                 that firewalls  allow such
>     packets? The
>      >     use of a
>      >      >      >>                 non-127/8 address may alleviate
>     this case
>      >     as well.
>      >      >      >>
>      >      >      >>             [SPK] I think we may need to add the text
>      >     about firewall
>      >      >      >>             as some checks in firewall will be
>     there if
>      >     they are not
>      >      >      >>             already using MPLS OAM which has inner IP
>      >     header with
>      >      >      >>             127/8 address range.
>      >      >      >>
>      >      >      >>
>      >      >      >>                 The rest of the draft looks good
>     to me,
>      >      >      >>
>      >      >      >>                 Dinesh
>      >      >      >>
>      >      >      >>                 On Wed, Oct 23, 2019 at 7:58 AM,
>     Greg Mirsky
>      >      >      >>                 <gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>
>      >     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
>      >      >     <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>>>
>      >     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
>     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
>      >      >     <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>>>>>
>      >      >      >>                 wrote:
>      >      >      >>>                 Hi Dinesh,
>      >      >      >>>                 I greatly appreciate your comments.
>      >     Please heave a
>      >      >      >>>                 look at the attached copy of the
>     working
>      >      >     version and
>      >      >      >>>                 its diff to -07 (latest in the
>     datatracker).
>      >      >      >>>
>      >      >      >>>                 Regards,
>      >      >      >>>                 Greg
>      >      >      >>>
>      >      >      >>>                 On Tue, Oct 22, 2019 at 9:52 PM
>     Dinesh Dutt
>      >      >      >>>                 <didutt@gmail.com
>     <mailto:didutt@gmail.com>
>      >     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>
>     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>
>      >     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>>
>      >      >     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>
>     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>
>      >     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>
>     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>>>> wrote:
>      >      >      >>>
>      >      >      >>>                     I have the same feeling as Anoop.
>      >     Greg, can you
>      >      >      >>>                     please point me to the latest
>     draft
>      >     so that
>      >      >     I can
>      >      >      >>>                     quickly glance through it to be
>      >     doubly sure,
>      >      >      >>>
>      >      >      >>>                     Dinesh
>      >      >      >>>
>      >      >      >>>                     On Wed, Oct 23, 2019 at 4:35 AM,
>      >     Anoop Ghanwani
>      >      >      >>>                     <anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu>
>      >     <mailto:anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>>
>      >      >     <mailto:anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu>>>
>      >      >      >>>                     <mailto:anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu>
>      >     <mailto:anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>>
>      >      >     <mailto:anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu>
>      >     <mailto:anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu>>>>> wrote:
>      >      >      >>>>                     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
>     <mailto:gregimirsky@gmail.com>
>      >     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
>      >      >     <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>>>
>      >      >      >>>>                   
>       <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
>      >     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
>      >      >     <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>
>      >     <mailto:gregimirsky@gmail.com
>     <mailto: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:
>      >      >      >>>>
>      >      >      >>>>                          1. single BFD session
>     between
>      >     two VTEPs
>      >      >      >>>>                          2. single BFD session
>     per VNI
>      >     between
>      >      >     two VTEPs
>      >      >      >>>>                          3. 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 <mailto:anoop@alumni.duke.edu>
>      >     <mailto:anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>>
>      >      >     <mailto:anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu>>>
>      >      >      >>>>                       
>       <mailto:anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>
>      >     <mailto:anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>>
>      >      >     <mailto:anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu>
>      >     <mailto:anoop@alumni.duke.edu
>     <mailto: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 <mailto:jmh@joelhalpern.com>
>     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>      >      >     <mailto:jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com>>>
>      >      >      >>>>                           
>       <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>      >     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>      >      >     <mailto:jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com
>     <mailto: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 <mailto:xiao.min2@zte.com.cn>
>      >     <mailto:xiao.min2@zte.com.cn <mailto:xiao.min2@zte.com.cn>>
>      >      >     <mailto:xiao.min2@zte.com.cn
>     <mailto:xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn
>     <mailto:xiao.min2@zte.com.cn>>>
>      >      >      >>>>
>      >       <mailto:xiao.min2@zte.com.cn <mailto:xiao.min2@zte.com.cn>
>     <mailto:xiao.min2@zte.com.cn <mailto:xiao.min2@zte.com.cn>>
>      >      >     <mailto:xiao.min2@zte.com.cn
>     <mailto:xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn
>     <mailto: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 <mailto:nvo3@ietf.org>
>     <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org>>
>      >     <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org>
>     <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org>>> <mailto:nvo3@ietf.org
>     <mailto:nvo3@ietf.org>
>      >     <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org>>
>      >      >     <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org>
>     <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org>>>>
>      >      >      >>>> https://www.ietf.org/mailman/listinfo/nvo3
>      >      >      >>>>
>      >      >
>      >
>