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

Dinesh Dutt <didutt@gmail.com> Wed, 30 October 2019 02:01 UTC

Return-Path: <didutt@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 26F9D12009E; Tue, 29 Oct 2019 19:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TNcn6-AY62g3; Tue, 29 Oct 2019 19:01:15 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 DDB28120059; Tue, 29 Oct 2019 19:01:14 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id w3so361726pgt.5; Tue, 29 Oct 2019 19:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=zD7z8CHd/UzT0dMrqDEmR3657vCn2Zl61k4WSCyKSus=; b=WJJZQIztki9MqMq6zO+WwBdtYJyNTHvWsE9pBWOPKdbNoHn9d/gkCB/lKrKfO/Stg2 sTStkQSAmdE+HinA1fXpUK024ofF2u2GU18R0bcSi68H/sncJVcMdu+GSPi5jXQzXMTX LyZasTUjdZJsh8kHrYAkwzFYkiSyyDHjtMtDQZvPMs/ctreXEoCeMCjk5U+ltPrQI4Rt K5r/5AJyXS1eV1XbXHi79dK1yvCs4k+47ORhCNjm3XDtwLTkBvKqJBLdIAzA3BsJuwyJ ZFLx8jpH5fuvd96fWrdra/D0+GbOLaxTfk5pztrOoBrqAw+1sDDkAHbjxSqCtlzFd9Gi yU2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=zD7z8CHd/UzT0dMrqDEmR3657vCn2Zl61k4WSCyKSus=; b=rJ7q5aP46PedRSihSTo/ty1Ax+yi1jRj5lAu5RXSweNA6mwLxwZZ8qtsUqjAOnrh5T 7rldfkQPWMC88DWsksQ0eHrGD+Bdqge4oC96QRukx9iFnzuGrPn1/568NsbHlyYfy10U SUr8Qb//mewuSB3ed6E7p9xgFNVB91grim1F1pFQk3JN6/uFQtfV9XHyU0TCfhz0yY4y SUkWbbEinFeZy2KP9tfJFTfP0B12Q4L5qSyozWTCJcYwiNvFl2HI4xDfVlvbg61Dq+pC KLWqzwU5Qyo6NBNmvqVWMvxxjHIv8mjWNPqh86Ye+57KOuXinNX906AqfIN6Pv+wCHJj mYIg==
X-Gm-Message-State: APjAAAUcdIMJBgX3Zz7WByYcN4k+u+9Zyskh/PGRW9sW3FvxszwaBFYa bScoKixQ89/ruZ8QBFtYKCI=
X-Google-Smtp-Source: APXvYqyJZcfFunuWCQ2lXXhqXmJ1y0bt8l8HJThA9uf0MITeTIfiwNH1qxJbv1OBWZ+POWiSZHFdxA==
X-Received: by 2002:a17:90a:b946:: with SMTP id f6mr10306275pjw.69.1572400873896; Tue, 29 Oct 2019 19:01:13 -0700 (PDT)
Received: from [192.168.1.9] ([117.213.198.17]) by smtp.gmail.com with ESMTPSA id j25sm389347pfi.113.2019.10.29.19.00.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Oct 2019 19:01:12 -0700 (PDT)
Date: Wed, 30 Oct 2019 06:59:38 +0500
From: Dinesh Dutt <didutt@gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Anoop Ghanwani <anoop@alumni.duke.edu>, Santosh P K <santosh.pallagatti@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
Message-Id: <1572400778.28051.7@smtp.gmail.com>
In-Reply-To: <aa853b8e-7ff4-a2d9-9b66-f9c22823ac9d@joelhalpern.com>
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>
X-Mailer: geary/0.12.4
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-8g7zpW5Bf20wEZ8pdC2M"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/XeNvI7_lTFAtwfDo9LrCkPX0No4>
X-Mailman-Approved-At: Wed, 30 Oct 2019 04:22:38 -0700
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2019 02:01:21 -0000

I suspect silicon implementations will have a problem with saying that 
they can be set to anything and MUST be ignored on reception. Your 
logic is sound, it's just that I fear you'll break many existing 
implementations. I recommend sticking with the 127/8 address for this 
case.

Dinesh

On Tue, Oct 29, 2019 at 9:15 PM, 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
>>      >      >      >      >>>>
>>      >      >      >
>>      >      >
>>      >
>>