Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 28 October 2019 19:55 UTC
Return-Path: <jmh@joelhalpern.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BE412006D; Mon, 28 Oct 2019 12:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ6UZREyku4N; Mon, 28 Oct 2019 12:55:30 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C75212004E; Mon, 28 Oct 2019 12:55:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47256p3Bq9z15KPf; Mon, 28 Oct 2019 12:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572292530; bh=po0f99wOAqEKgtFvrJdBqXCxRxqZYXfdkjW2xDHsc9o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=e+R9qYis5JWR9jXp9Fg4Q0oBDd+krFCG9yBi0ohXoQH5KtgtRtsMw72U1np6mSQup w/X6yDVwNMngx3D/4MI9u3eH0z1YG+VKk2dYOZMT0C1VY61jKbKcT5RkbuIUrEhAmt feFK6F3llqajVs07cFUA0mCa0u+a5m5Vkz8+GH0E=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 47256m1crSzKmq7; Mon, 28 Oct 2019 12:55:27 -0700 (PDT)
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: Santosh P K <santosh.pallagatti@gmail.com>, Dinesh Dutt <didutt@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, Jeffrey Haas <jhaas@pfrc.org>, NVO3 <nvo3@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, xiao.min2@zte.com.cn
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com> <CA+-tSzyHgspKBfLWZ3C69EBb+-k-POqJ7vG7VoN=g077+qzGBA@mail.gmail.com> <1571795542.10436.5@smtp.gmail.com> <CA+RyBmXkyQMumeCDxM6OSzdn=DCL=aeyQ+tJmUiyEg0VZuUpRg@mail.gmail.com> <1571798869.2855.1@smtp.gmail.com> <CACi9rduyvhweJd_aNx6miiUGyu-nCeqnNHGbPjyCfswHx1RD5A@mail.gmail.com> <CA+RyBmXLBLARxhA4MUvD6DE8vvY1oDP0opkxDqiPA4zYw9Jpug@mail.gmail.com> <1571860470.2855.11@smtp.gmail.com> <CACi9rdtwiuH2VjuUkzeg3+PhwcFMSqFepbcM0tgmRxSbcR3AQQ@mail.gmail.com> <CA+-tSzyi=uDdqSDq4u7kytAucX136mO2XtPtR=DG+KKAC5PjCQ@mail.gmail.com> <88a1320e-093a-a101-d8a6-6ae6d7648466@joelhalpern.com> <CA+-tSzxCpLOmhpBXP1k5vLY20qA5db9nbq4qEiH00jo=EH+w8g@mail.gmail.com> <d7b25f3a-5f1e-30da-8a41-0d11e3c2d04c@joelhalpern.com> <CA+-tSzzBfp9Wy8KO6MbxFNXZBhC3bL7u92VwqJTA82WrwGUAgg@mail.gmail.com> <c773cd4f-320c-fb15-3b7b-d0016b7d5978@joelhalpern.com> <CA+-tSzxUs9PGv+y1PBquaAhuq4wK_=TkR+b_ET6j7OBHf4Mq7Q@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <97bdb8b4-b334-53fb-05a6-2d1fc8684ad3@joelhalpern.com>
Date: Mon, 28 Oct 2019 15:55:25 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CA+-tSzxUs9PGv+y1PBquaAhuq4wK_=TkR+b_ET6j7OBHf4Mq7Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/mGABUli1_eiFTwS9qYmK6YEBcrw>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2019 19:55:36 -0000
You are saying that there are existing implementations using VNI 0 for this? Given that previous versions of the spec explicitly disallowed VNI 0, I am having trouble with your objecting that a spec for how to run over VNI 0 breask existing implementations. Note that when there is a good technical reason, the IETF does change Internet Drafts in ways that break early implementations. That is the price of standardization. Yours, Joel On 10/28/2019 2:30 PM, Anoop Ghanwani wrote: > Hi Joel, > > Writing the spec in that way would make the current, inter-operable > implementation of multiple vendors non-compliant with the spec. > > Thanks, > Anoop > > On Mon, Oct 28, 2019 at 11:07 AM Joel M. Halpern <jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com>> wrote: > > I assumed this was only for the case where a tenant VNI was being used. > > For the 0 VNI (which is what I prefer), always (MUST) use the loopback > address. There are no addresses assigned to the VTEP in that space. > There is no IRB in that space. > > Yours, > Joel > > On 10/28/2019 1:58 PM, Anoop Ghanwani wrote: > > Joel, > > > > Are we going to qualify this by VNI? There's a bunch of > implementations > > out there that don't use a tenant IP or a loopback with VNI 0--they > > simply repeat the underlay IP in the inner IPDA. > > > > Thanks, > > Anoop > > > > On Mon, Oct 28, 2019 at 10:46 AM Joel M. Halpern > <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> > > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>> wrote: > > > > I can live with saying that you SHOULD use loopback, and MAY > instead > > use > > an IP address in the customer space known to be owned by the VTEP > > device > > when such exists. > > > > Yours, > > Joel > > > > On 10/28/2019 1:32 PM, Anoop Ghanwani wrote: > > > Hi Joel, > > > > > > Perhaps we need to say use of an address owned by the device > > containing > > > the VTEP. > > > > > > Or are you suggesting that the use of the loopback address > space > > is a MUST? > > > > > > Anoop > > > > > > On Mon, Oct 28, 2019 at 10:22 AM Joel M. Halpern > > <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> > > > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>> wrote: > > > > > > There is something I am missing in your assumption > about IRB. > > > > > > As I understand VxLAN, the VTEP is under the control > of the > > operator. > > > As such, it is a pure bridge. If you run IRB behind > it, that > > is fine. > > > Yes, an operator may offer IRB. But as I understand it, > > conceptually, > > > in terms of the VxLAN architecture the IRB is an entity > > behind the > > > VTEP, > > > not part of the VTEP. > > > > > > Yours, > > > Joel > > > > > > On 10/28/2019 12:23 PM, Anoop Ghanwani wrote: > > > > Santosh, > > > > > > > > Does it have to be a MUST? What if I am running > IRB and there > > > are IP > > > > addresses per VNI assigned to the VTEPs? Why can the > > operator not > > > > choose to use those? > > > > > > > > Anoop > > > > > > > > On Mon, Oct 28, 2019 at 7:51 AM Santosh P K > > > > <santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com> > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com>> > > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com> > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com>>> > > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com> > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com>> > > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com> > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com>>>>> wrote: > > > > > > > > Dinesh, Anoop et all, > > > > Lets us know if this text works for 127/8 > > address range? > > > > > > > > [proposed text for firewall] > > > > > > > > "As per section 4 inner destination IP address > MUST be > > set to > > > 127/8 > > > > address. There may be firewall configured on > VTEP to > > block 127/8 > > > > address range if set as destination IP in inner IP > > header. It is > > > > recommended to allow 127/8 range address through > > firewall only if > > > > 127/8 IP address is set as destination address > in inner IP > > > header." > > > > > > > > > > > > In section 4 we are talking about using 127/8 > and not > > really > > > giving > > > > reason why. I think we should have text as RFC 5884 > > has mentioned > > > > with below text. > > > > > > > > [From RFC 5884] > > > > "The motivation for using the address range > 127/8 is > > the same as > > > > specified in Section 2.1 of [RFC4379] > > > > <https://tools.ietf.org/html/rfc4379#section-2.1>. > > This is an > > > > exception to the behavior defined in [RFC1122 > > > > <https://tools.ietf.org/html/rfc1122>]." > > > > > > > > > > > > > > > > Thanks > > > > Santosh P K > > > > > > > > > > > > > > > > On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt > > <didutt@gmail.com <mailto:didutt@gmail.com> > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>> > > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com> > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>> > > > > <mailto:didutt@gmail.com > <mailto:didutt@gmail.com> <mailto:didutt@gmail.com > <mailto:didutt@gmail.com>> > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com> > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>>>> wrote: > > > > > > > > Looks good to me Greg. I see that the text > around > > the use > > > of the > > > > inner IP address as also quite acceptable. Will > > you add any > > > > words about the firewall? > > > > > > > > Dinesh > > > > > > > > On Wed, Oct 23, 2019 at 8:36 PM, Greg Mirsky > > > > <gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com> > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>> > > > <mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com>> > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>>> wrote: > > > >> Hi Dinesh, et al., > > > >> please check the updated version that > removed the > > > reference to > > > >> Hypervisor in the text and Figure 1. > > > >> > > > >> Regards, > > > >> Greg > > > >> > > > >> On Wed, Oct 23, 2019 at 10:47 AM Santosh P K > > > >> <santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com> > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com>> > > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com> > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com>>> > > > >> <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com> > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com>> > > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com> > > <mailto:santosh.pallagatti@gmail.com > <mailto:santosh.pallagatti@gmail.com>>>>> wrote: > > > >> > > > >> Dinesh, > > > >> Please see my inline comments [SPK] > > > >> > > > >> > > > >> - In section 3, there's a sentence > that > > is: "BFD > > > >> packets intended for a Hypervisor > VTEP MUST > > > NOT..". I > > > >> recommend getting rid of the word > > "Hypervisor" ashe > > > >> logic applies to any VTEP. > > > >> > > > >> [SPK] Thanks for comments. We will > change this. > > > >> > > > >> - You already explained the > precedence of > > the use of > > > >> 127/8 address in the inner header in > > MPLS. I have no > > > >> specific comments in that area. I have > > only two > > > >> questions: > > > >> - Has anybody verified that the > use of > > 127/8 > > > >> address (and the right MAC) works with > > existing > > > >> implementations, including the silicon > > ones? If this > > > >> doesn't work there, is it worth > adding the > > > possibilit > > > >> y of another address, one that is > owned > > by the > > > VTEP node? > > > >> > > > >> - Do we know if Firewalls stop > such VXLAN > > > packets? > > > >> I ask this because VXLAN has an IP > header > > and I > > > don't > > > >> know if firewalls stop packets > with 127/8 > > in the > > > inner > > > >> header. If not, is it worth adding a > > sentence to say > > > >> that firewalls allow such > packets? The > > use of a > > > >> non-127/8 address may alleviate > this case > > as well. > > > >> > > > >> [SPK] I think we may need to add the text > > about firewall > > > >> as some checks in firewall will be > there if > > they are not > > > >> already using MPLS OAM which has inner IP > > header with > > > >> 127/8 address range. > > > >> > > > >> > > > >> The rest of the draft looks good > to me, > > > >> > > > >> Dinesh > > > >> > > > >> On Wed, Oct 23, 2019 at 7:58 AM, > Greg Mirsky > > > >> <gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com> > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> > > > <mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com>>> > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> > > > <mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com>>>>> > > > >> wrote: > > > >>> Hi Dinesh, > > > >>> I greatly appreciate your comments. > > Please heave a > > > >>> look at the attached copy of the > working > > > version and > > > >>> its diff to -07 (latest in the > datatracker). > > > >>> > > > >>> Regards, > > > >>> Greg > > > >>> > > > >>> On Tue, Oct 22, 2019 at 9:52 PM > Dinesh Dutt > > > >>> <didutt@gmail.com > <mailto:didutt@gmail.com> > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>> > <mailto:didutt@gmail.com <mailto:didutt@gmail.com> > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>> > > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com> > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>> > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com> > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>>>> wrote: > > > >>> > > > >>> I have the same feeling as Anoop. > > Greg, can you > > > >>> please point me to the latest > draft > > so that > > > I can > > > >>> quickly glance through it to be > > doubly sure, > > > >>> > > > >>> Dinesh > > > >>> > > > >>> On Wed, Oct 23, 2019 at 4:35 AM, > > Anoop Ghanwani > > > >>> <anoop@alumni.duke.edu > <mailto:anoop@alumni.duke.edu> > > <mailto:anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>> > > > <mailto:anoop@alumni.duke.edu > <mailto:anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu > <mailto:anoop@alumni.duke.edu>>> > > > >>> <mailto:anoop@alumni.duke.edu > <mailto:anoop@alumni.duke.edu> > > <mailto:anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>> > > > <mailto:anoop@alumni.duke.edu > <mailto:anoop@alumni.duke.edu> > > <mailto:anoop@alumni.duke.edu > <mailto:anoop@alumni.duke.edu>>>>> wrote: > > > >>>> Greg, > > > >>>> > > > >>>> I think the draft is fine as is. > > > >>>> > > > >>>> I discussion with Xiao Min was > > about #3 and I > > > >>>> see that as unnecessary until we > > have a draft > > > >>>> that explains why that is > needed in the > > > context > > > >>>> of the NVO3 architecture. > > > >>>> > > > >>>> Anoop > > > >>>> > > > >>>> On Tue, Oct 22, 2019 at 11:17 AM > > Greg Mirsky > > > >>>> <gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com> > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> > > > <mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com>>> > > > >>>> > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> > > > <mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com> > > <mailto:gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com>>>>> wrote: > > > >>>> > > > >>>> Hi Anoop, et al., > > > >>>> I agree with your > understanding > > of what is > > > >>>> being defined in the current > > version > > > of the > > > >>>> BFD over VxLAN > specification. > > But, as I > > > >>>> understand, the WG is > > discussing the scope > > > >>>> before the WGLC is closed. I > > believe there > > > >>>> are three options: > > > >>>> > > > >>>> 1. single BFD session > between > > two VTEPs > > > >>>> 2. single BFD session > per VNI > > between > > > two VTEPs > > > >>>> 3. multiple BFD > sessions per > > VNI between > > > >>>> two VTEPs > > > >>>> > > > >>>> The current text > reflects #2. Is WG > > > accepts > > > >>>> this scope? If not, which > > option WG would > > > >>>> accept? > > > >>>> > > > >>>> Regards, > > > >>>> Greg > > > >>>> > > > >>>> On Tue, Oct 22, 2019 at > 2:09 PM > > Anoop > > > >>>> Ghanwani > <anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu> > > <mailto:anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>> > > > <mailto:anoop@alumni.duke.edu > <mailto:anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu > <mailto:anoop@alumni.duke.edu>>> > > > >>>> > <mailto:anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu> > > <mailto:anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>> > > > <mailto:anoop@alumni.duke.edu > <mailto:anoop@alumni.duke.edu> > > <mailto:anoop@alumni.duke.edu > <mailto:anoop@alumni.duke.edu>>>>> wrote: > > > >>>> > > > >>>> I concur with Joel's > assessment > > > with the > > > >>>> following > clarifications. > > > >>>> > > > >>>> The current document > is already > > > capable > > > >>>> of monitoring > multiple VNIs > > > between VTEPs. > > > >>>> > > > >>>> The issue under > discussion > > was how > > > do we > > > >>>> use BFD to monitor > multiple > > VAPs that > > > >>>> use the same VNI > between a > > pair of > > > >>>> VTEPs. The use case for > > this is not > > > >>>> clear to me, as from my > > understanding, > > > >>>> we cannot have a > situation with > > > multiple > > > >>>> VAPs using the same > > VNI--there is 1:1 > > > >>>> mapping between VAP > and VNI. > > > >>>> > > > >>>> Anoop > > > >>>> > > > >>>> On Tue, Oct 22, 2019 > at 6:06 AM > > > Joel M. > > > >>>> Halpern > > <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> > > > <mailto:jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com>>> > > > >>>> > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> > > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> > > > <mailto:jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com>>>>> > > wrote: > > > >>>> > > > >>>> From what I can > tell, > > there > > > are two > > > >>>> separate problems. > > > >>>> The document we > have is a > > > VTEP-VTEP > > > >>>> monitoring > document. > > There is no > > > >>>> need for that > document to > > > handle the > > > >>>> multiple VNI case. > > > >>>> If folks want a > > protocol for doing > > > >>>> BFD monitoring > of things > > > behind the > > > >>>> VTEPs (multiple > VNIs), > > then do > > > that > > > >>>> as a separate > > document. The > > > >>>> encoding will be > a tenant > > > encoding, > > > >>>> and thus > sesparate from > > what is > > > >>>> defined in this > document. > > > >>>> > > > >>>> Yours, > > > >>>> Joel > > > >>>> > > > >>>> On 10/21/2019 > 5:07 PM, > > Jeffrey > > > Haas > > > >>>> wrote: > > > >>>> > Santosh and > others, > > > >>>> > > > > >>>> > On Thu, Oct > 03, 2019 at > > > 07:50:20PM > > > >>>> +0530, Santosh P > K wrote: > > > >>>> >> Thanks > for your > > > explanation. > > > >>>> This helps a lot. I > > would wait > > > for more > > > >>>> >> comments from > others > > to see if > > > >>>> this what we > need in this > > > draft to be > > > >>>> >> supported > based on > > that we can > > > >>>> provide appropriate > > sections > > > in the > > > >>>> draft. > > > >>>> > > > > >>>> > The threads on the > > list have > > > >>>> spidered to the > point > > where it is > > > >>>> challenging > > > >>>> > to follow what the > > current > > > status > > > >>>> of the draft is, > or should > > > be. :-) > > > >>>> > > > > >>>> > However, if I've > > followed things > > > >>>> properly, the > question > > below is > > > >>>> really the > > > >>>> > hinge point on > what our > > > >>>> encapsulation > for BFD > > over vxlan > > > >>>> should look like. > > > >>>> > Correct? > > > >>>> > > > > >>>> > Essentially, > do we or > > do we not > > > >>>> require the > ability to > > permit > > > >>>> multiple BFD > > > >>>> > sessions between > > distinct VAPs? > > > >>>> > > > > >>>> > If this is so, > do we > > have a > > > sense > > > >>>> as to how we should > > proceed? > > > >>>> > > > > >>>> > -- Jeff > > > >>>> > > > > >>>> > [context preserved > > below...] > > > >>>> > > > > >>>> >> Santosh P K > > > >>>> >> > > > >>>> >> On Wed, Sep > 25, 2019 > > at 8:10 AM > > > >>>> > <xiao.min2@zte.com.cn <mailto:xiao.min2@zte.com.cn> > > <mailto:xiao.min2@zte.com.cn <mailto:xiao.min2@zte.com.cn>> > > > <mailto:xiao.min2@zte.com.cn > <mailto:xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn > <mailto:xiao.min2@zte.com.cn>>> > > > >>>> > > <mailto:xiao.min2@zte.com.cn <mailto:xiao.min2@zte.com.cn> > <mailto:xiao.min2@zte.com.cn <mailto:xiao.min2@zte.com.cn>> > > > <mailto:xiao.min2@zte.com.cn > <mailto:xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn > <mailto:xiao.min2@zte.com.cn>>>>> > > wrote: > > > >>>> >> > > > >>>> >>> Hi Santosh, > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> With regard > to the > > question > > > >>>> whether we > should allow > > > multiple BFD > > > >>>> sessions > > > >>>> >>> for the same > VNI or > > not, > > > IMHO we > > > >>>> should allow it, > more > > > explanation as > > > >>>> >>> follows. > > > >>>> >>> > > > >>>> >>> Below is a > figure > > derived from > > > >>>> figure 2 of > RFC8014 (An > > > Architecture for > > > >>>> >>> Data-Center > Network > > > >>>> Virtualization > over Layer 3 > > > (NVO3)). > > > >>>> >>> > > > >>>> >>> > | > > > >>>> Data Center Network > > (IP) | > > > >>>> >>> > | > > > >>>> > > | > > > >>>> >>> > > > >>>> > > > +-----------------------------------------+ > > > >>>> >>> > > | > > > >>>> > | > > > >>>> >>> > > | > > > >>>> Tunnel Overlay > | > > > >>>> >>> > > > >>>> > +------------+---------+ > > > >>>> > +---------+------------+ > > > >>>> >>> | > > > >>>> > +----------+-------+ | > > | > > > >>>> > +-------+----------+ | > > > >>>> >>> > | | > > Overlay > > > >>>> Module | | > | | > > Overlay > > > >>>> Module | | > > > >>>> >>> | > > > >>>> > +---------+--------+ | > > | > > > >>>> > +---------+--------+ | > > > >>>> >>> | > > | > > > >>>> | | > | > > > | > > > >>>> >>> NVE1 | > > | > > > >>>> | | > | > > > | > > > >>>> NVE2 > > > >>>> >>> | > > > >>>> > +--------+-------+ | > > | > > > >>>> > +--------+-------+ | > > > >>>> >>> > | |VNI1 > > > VNI2 VNI1 > > > >>>> | | | | VNI1 > > VNI2 VNI1 > > > | | > > > >>>> >>> | > > > >>>> > +-+-----+----+---+ | > > | > > > >>>> > +-+-----+-----+--+ | > > > >>>> >>> > |VAP1| > > VAP2| | > > > >>>> VAP3 | > |VAP1| VAP2| > > > | VAP3| > > > >>>> >>> > > > >>>> > +----+-----+----+------+ > > > >>>> > +----+-----+-----+-----+ > > > >>>> >>> > > | | > > > | > > > >>>> | > > | | > > > >>>> >>> > > | | > > > | > > > >>>> | > > | | > > > >>>> >>> > > | | > > > | > > > >>>> | > > | | > > > >>>> >>> > > > >>>> > > > > -------+-----+----+-------------------+-----+-----+------- > > > >>>> >>> > > | | > > > | > > > >>>> Tenant | > > | | > > > >>>> >>> > TSI1 | > > TSI2| | > > > >>>> TSI3 > TSI1| TSI2| > > > |TSI3 > > > >>>> >>> > > +---+ +---+ > > > >>>> +---+ > +---+ > > +---+ > > > +---+ > > > >>>> >>> > > |TS1| |TS2| > > > >>>> |TS3| > |TS4| > > |TS5| > > > |TS6| > > > >>>> >>> > > +---+ +---+ > > > >>>> +---+ > +---+ > > +---+ > > > +---+ > > > >>>> >>> > > > >>>> >>> To my > > understanding, the BFD > > > >>>> sessions between > NVE1 > > and NVE2 are > > > >>>> actually > > > >>>> >>> initiated and > > terminated > > > at VAP > > > >>>> of NVE. > > > >>>> >>> > > > >>>> >>> If the > network operator > > > want to > > > >>>> set up one BFD > session > > between > > > VAP1 of > > > >>>> >>> NVE1 and VAP1of > > NVE2, at the > > > >>>> same time > another BFD > > session > > > >>>> between VAP3 of > > > >>>> >>> NVE1 and > VAP3 of NVE2, > > > although > > > >>>> the two BFD sessions > > are for > > > the same > > > >>>> >>> VNI1, I > believe it's > > > reasonable, > > > >>>> so that's why I > think we > > > should allow it > > > >>>> > > > >>>> > > > _______________________________________________ > > > >>>> nvo3 mailing list > > > >>>> nvo3@ietf.org <mailto:nvo3@ietf.org> > <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org>> > > <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org> > <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org>>> <mailto:nvo3@ietf.org > <mailto:nvo3@ietf.org> > > <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org>> > > > <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org> > <mailto:nvo3@ietf.org <mailto:nvo3@ietf.org>>>> > > > >>>> https://www.ietf.org/mailman/listinfo/nvo3 > > > >>>> > > > > > >
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… John E Drake
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel Halpern Direct
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Selvakumar Sivaraj
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Selvakumar Sivaraj
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K