Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 28 October 2019 17:22 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 799F0120942; Mon, 28 Oct 2019 10:22:15 -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 8UFBLphGtPjm; Mon, 28 Oct 2019 10:22:13 -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 6BC9A12081C; Mon, 28 Oct 2019 10:22:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4721jx2b3Wzdhpf; Mon, 28 Oct 2019 10:22:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572283333; bh=9+0d9G3hlmN/NErle2mTRz7bMFV8MAtWJPc00isgMjU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pLbdEwp73qtA2xiDgCVfo0iEczwb95GvpAbWr6pfymK3KSrdIlUgyx5gj7Z7jl91u lQiaaI/hA2Qua/Ij7laxlSHjKXinxzK370eJE4rtVi3ln+QbCr3hOQ/Ck95AydIKh8 JP2svwbh4s+fk39QdMtg2rd2DMaxU+zm9gfTAv/I=
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 4721jv1XJMzdhpb; Mon, 28 Oct 2019 10:22:10 -0700 (PDT)
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Anoop Ghanwani <anoop@alumni.duke.edu>, Santosh P K <santosh.pallagatti@gmail.com>
Cc: 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> <201909251039413767352@zte.com.cn> <CACi9rdv-760M8WgZ1mOOOa=yoJqQFP=vdc3xJKLe7wCR18NSvA@mail.gmail.com> <20191021210752.GA8916@pfrc.org> <0e99a541-b2ca-85d4-4a8f-1165cf7ac01e@joelhalpern.com> <CA+-tSzziDc+Tk8AYfOr5-Xn6oO_uqW2C1dRA9LLOBBVmzVhWEQ@mail.gmail.com> <CA+RyBmVcBgeoGc2z5Gv0grv8OY34tyw+T-T-W2vn1O3AxCSQ9Q@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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <88a1320e-093a-a101-d8a6-6ae6d7648466@joelhalpern.com>
Date: Mon, 28 Oct 2019 13:22:09 -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+-tSzyi=uDdqSDq4u7kytAucX136mO2XtPtR=DG+KKAC5PjCQ@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/6en_sHPGEzY1H1gtD8ws19L7a8k>
X-Mailman-Approved-At: Mon, 28 Oct 2019 11:38:17 -0700
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2019 17:22:16 -0000
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>> 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>> 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>> 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>> 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>> >> 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>> 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>> 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>> 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>> 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>> 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>> 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> >>>> 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