Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 29 October 2019 15:45 UTC
Return-Path: <jmh@joelhalpern.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9312F120826; Tue, 29 Oct 2019 08:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tD6zP8A9ypFa; Tue, 29 Oct 2019 08:45:43 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9AD12081E; Tue, 29 Oct 2019 08:45:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 472bX73x4TzXxBh; Tue, 29 Oct 2019 08:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572363943; bh=kN8tcd5trp/EHM9AgCcLpjJVVwxhjWVRF4qlD4wOCko=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gUlDtbypONab4qTiGLHFVLtVG8pB8GH717baX9G5uyOf9/QyZ0LaOvjOzOKsUfvR5 zL5VZ9aBrSyzI5IHmle6r3m69t75axKv6jOklZiDLUY/aGm0CKTiSnggqI4Q3MyuXS 57izBGG96OI9+E9D7uzZ21XBM/DMUmqHcIF2OrdQ=
X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 472bX43h5jzXwvf; Tue, 29 Oct 2019 08:45:39 -0700 (PDT)
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: Santosh P K <santosh.pallagatti@gmail.com>, Dinesh Dutt <didutt@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, Jeffrey Haas <jhaas@pfrc.org>, NVO3 <nvo3@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, xiao.min2@zte.com.cn
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com> <CA+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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <aa853b8e-7ff4-a2d9-9b66-f9c22823ac9d@joelhalpern.com>
Date: Tue, 29 Oct 2019 11:45:35 -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+-tSzw76E0AM2AJR=2GQsXJ3MtFUtsug7KoGQzAP-=Ds8u7Fg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/w8VluX4XksXtINkUiXd38XTWJnw>
X-Mailman-Approved-At: Tue, 29 Oct 2019 11:54:18 -0700
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2019 15:45:49 -0000
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 > > > > >>>> > > > > > > > > > >
- BFD over VXLAN: Trapping BFD Control packet at VT… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… T. Sridhar
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re:BFD over VXLAN: Trapping BFD Control packet at… xiao.min2
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:BFD over VXLAN: Trapping BFD Control packet at… xiao.min2
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… 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 pa… xiao.min2
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: BFD over VXLAN: Trapping BFD Control packet a… Jeffrey Haas
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- 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… 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… 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… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- 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… 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… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- 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… 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… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- 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… 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… 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… 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