Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Anoop Ghanwani <anoop@alumni.duke.edu> Mon, 28 October 2019 16:23 UTC
Return-Path: <ghanwani@gmail.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 E5389120113; Mon, 28 Oct 2019 09:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buGt6Lso04Ff; Mon, 28 Oct 2019 09:23:13 -0700 (PDT)
Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7351200B4; Mon, 28 Oct 2019 09:23:13 -0700 (PDT)
Received: by mail-ua1-f44.google.com with SMTP id c16so2841140uan.0; Mon, 28 Oct 2019 09:23:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=edoHcovRZIHSCjzUB5okrwjl5PZd3jhR6O8Leyo6euA=; b=jAljgeCQ+9HEbNgiBF781a2A4fdhrJUEE0xQenHF1gQCwierRVwp0pjBrvsWxeuVhb iXuzItw6AX7fbLBE9iN64iZWgIuidrF8VakXR1D1EabJTvhkXSLZjkvyciTLbM8yocNc CnbqfgdN3r00hQ71qP3OIEotLUvQUzqF6tw6+6diNaGHWkg39S33M6MH74XADPqMdzuM M/i/OXcjEwT/Q5GkxxHFmxAGZLeQ5vw0BuW6fTpQwQIOO83wpqj3kbGOMZ6UbNiW5Tgh e39dE1BP6KPmLVee7GzC2gXsp1fQYIgbDyznMPi2v9KNJSk6DxPGlycRibI18c9tNOcV 1oTg==
X-Gm-Message-State: APjAAAWgmQTa6I0Ga9zYb446l0fAU3Ks++k9RC5VVVM2EC1TMjvk2sC2 x9/GlVg5DT11m5TYDByeEIh+DGCUw0lJqlwSH/8=
X-Google-Smtp-Source: APXvYqzgBu9O5xWgGxzOFuH+VxQR5CLiqqNk8nQyJVRMe8OG/zTmicb5mbaYNQHp+u3/lkFDjwRNpDtrptOeVzKy4MA=
X-Received: by 2002:ab0:4ea9:: with SMTP id l41mr8627963uah.76.1572279792222; Mon, 28 Oct 2019 09:23:12 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CACi9rdtwiuH2VjuUkzeg3+PhwcFMSqFepbcM0tgmRxSbcR3AQQ@mail.gmail.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Mon, 28 Oct 2019 09:23:02 -0700
Message-ID: <CA+-tSzyi=uDdqSDq4u7kytAucX136mO2XtPtR=DG+KKAC5PjCQ@mail.gmail.com>
To: Santosh P K <santosh.pallagatti@gmail.com>
Cc: Dinesh Dutt <didutt@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Jeffrey Haas <jhaas@pfrc.org>, NVO3 <nvo3@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, xiao.min2@zte.com.cn
Content-Type: multipart/alternative; boundary="00000000000080c82c0595faea7c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/mW-3fJtfRJTWo8Ve5-ccYQZg2EY>
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 16:23:16 -0000
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> 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> 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> >> 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> 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> >>>> 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> 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> >>>>> 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> >>>>> 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> >>>>>> 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> >>>>>>> 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> 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 >>>>>>>> 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