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

Anoop Ghanwani <anoop@alumni.duke.edu> Tue, 29 October 2019 15:55 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 9E517120894; Tue, 29 Oct 2019 08:55:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 vqiVWTsc9MOV; Tue, 29 Oct 2019 08:55:23 -0700 (PDT)
Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (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 EF05F120819; Tue, 29 Oct 2019 08:55:22 -0700 (PDT)
Received: by mail-vs1-f45.google.com with SMTP id k15so9083208vsp.2; Tue, 29 Oct 2019 08:55:22 -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=Vr3TjuYq5UcbuNpak89LlkWK1XKQHQ7NH95vf/8oBbo=; b=G3gAjRVcKjLRnQiZ0UnUW+0oFclwnleSyty7cd23XmBYsOwluBxnFGGzbxDSJ5gSwk UIsQnLvFOAZTKpO3LS0qPmtdw9Thr8wE7f5wUZJs4Rmx3U2V0w0935sj00O5BoSqMv3E 3TqGFBVg8WJEOSCRC4lw4ykwBT08i38jquQYKRy6aIqr9IGf6pzdZgDNs5v9YOQtS53b gd+g0nacDwjX24HBhq1Ht+MaLObxneZEyhZlcFmu6SE2O5rfW1H8ae3tGQ4Qt63UQFSE y8EfOAcLUEq3spWPTWL9k26CSj2w6ERKS2fATxHwFHqZnU09pxcY8NEpnc13Uzo1Hfa2 y/GQ==
X-Gm-Message-State: APjAAAVF8/kgnHjTL29YK7FCEm3N37vcdfPP8LywSrsr8hDU+p8wxfvy 9nZx5/ieuG2oBQR3ohgpE1PZk597XO5FRjdFyIc=
X-Google-Smtp-Source: APXvYqy2W6YRYzbIiDgISlNwLN/e/DC+nDy5P3f/Xi02QDM3lEU9V9PliBnkcr15IM+JDVfBke73bnrICv/NDeODRmw=
X-Received: by 2002:a67:fe46:: with SMTP id m6mr2266707vsr.119.1572364521603; Tue, 29 Oct 2019 08:55:21 -0700 (PDT)
MIME-Version: 1.0
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.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> <97bdb8b4-b334-53fb-05a6-2d1fc8684ad3@joelhalpern.com> <CA+-tSzw76E0AM2AJR=2GQsXJ3MtFUtsug7KoGQzAP-=Ds8u7Fg@mail.gmail.com> <aa853b8e-7ff4-a2d9-9b66-f9c22823ac9d@joelhalpern.com>
In-Reply-To: <aa853b8e-7ff4-a2d9-9b66-f9c22823ac9d@joelhalpern.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Tue, 29 Oct 2019 08:55:09 -0700
Message-ID: <CA+-tSzxEiMcF3qXauOKfOFPmXY0b+iaXkW6i1HoSeogTX4MfzA@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: "Joel M. Halpern" <jmh@joelhalpern.com>
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
Content-Type: multipart/alternative; boundary="000000000000c488f105960ea4e5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/h5k1v_xiGviFMxu_BXujxxgky3E>
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: Tue, 29 Oct 2019 15:55:29 -0000

Joel,

>>>
Having said that, we could add text saying that since the IP address in
the BFD request in VNI 0 is effectively meaningless, it can be set to
any value on transmission and must be ignored on reception.
>>>

I think this would be better than disallowing anything other than an
address from the loopback subnet.

Thanks,
Anoop

On Tue, Oct 29, 2019 at 8:45 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> In all the discussion about what VNI to use and multiple VNI support, I
> lsot track.  Sorry.
>
> Still, the earlier documents did not specify the IP to use.  That does
> NOT mean that we are required in later revisions of the document to
> allow anything the client wants.
>
> Having said that, we could add text saying that since the IP address in
> the BFD request in VNI 0 is effectively meaningless, it can be set to
> any value on transmission and must be ignored on reception.
> As far as I can tell, it is definitional that the VtEP does not have any
> assigned IP address for VNI 0, so we can't expect that address.
>
> Yours,
> Joel
>
> On 10/29/2019 11:10 AM, Anoop Ghanwani wrote:
> > Hi Joel,
> >
> > Yes, existing implementations use VNI 0 for BFD over VXLAN.  Here are a
> > couple of references:
> >
> https://www.juniper.net/documentation/en_US/junos/topics/concept/sdn-ovsdb-bfd-nsx.html
> >
> >
> https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-740091.html#_Toc18013665
> >
> >
> > I guess this document has been evolving and I have not kept up with it.
> > The version I had reviewed and commented on originally allowed for VNI
> > 0.  The -04 version of the draft has this:
> > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04#section-7
> > What version are you referring to?
> >
> > Thanks,
> > Anoop
> >
> >
> >
> > On Mon, Oct 28, 2019 at 12:55 PM Joel M. Halpern <jmh@joelhalpern.com
> > <mailto:jmh@joelhalpern.com>> wrote:
> >
> >     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>
> >      > <mailto: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>>
> >      >      > <mailto: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>>>
> >      >      >      > <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:
> >      >      >      >
> >      >      >      >     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>>>>
> >      >      >      >     <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
> >     <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>>>>
> >      >      >      >      >     <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 <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>>>>
> >      >      >      >     <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 <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>>>>
> >      >      >      >      >>
> >       <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
> >     <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
> >>>>
> >      >      >     <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 <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>>>>
> >      >      >      >     <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 <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
> >>>>
> >      >      >      >      >>>
> >       <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
> >     <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
> >>>>
> >      >      >      >      >>>>
> >      >       <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
> >     <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
> >>>>
> >      >      >      >      >>>>
> >      >       <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
> >     <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>>>>
> >      >      >      >      >>>>
> >      >       <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 <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>>>>
> >      >      >      >      >>>>
> >      >      >       <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 <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>>>>
> >     <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 <mailto:nvo3@ietf.org>>>>>
> >      >      >      >      >>>>
> https://www.ietf.org/mailman/listinfo/nvo3
> >      >      >      >      >>>>
> >      >      >      >
> >      >      >
> >      >
> >
>