Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Dinesh Dutt <didutt@gmail.com> Tue, 22 October 2019 20:20 UTC
Return-Path: <didutt@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26893120096; Tue, 22 Oct 2019 13:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.796
X-Spam-Level:
X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQB76Qs2Y0dz; Tue, 22 Oct 2019 13:20:07 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 D230C120077; Tue, 22 Oct 2019 13:20:07 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id r1so10606563pgj.12; Tue, 22 Oct 2019 13:20:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=eadX0yqJTdmgFl7qyptwTWbT7FHRo60jJJdZBpGlMEM=; b=T3msxzJ+T90OpkiYpYYV+kx3xx/FtX2D08xtZdeoIQfPPBaPmAn8WY1DTpUys4oDFf gjBz1mPG+0MgkJgrNagKBsiPSrrgm6tqJ2jdR0mA8IpVhXwryYXhjwraMmNabItDQUhD fRsk2T4xlC8jBDTGswfq4udbT2LC2DEP+cq1O+ICUT1IXKQLWtWpReEQbrZXgxVquFAB 9R8UEVNwb+fgJWWQo2jWDf2HHfdSh6pSCfKxh+d+ou2zTFmcEe0BW4mwjH3xYJGUsw+d BcbZ1DC5+0ecAPnnfPoKTcd+MFsicutEuxze9JWrRKhTmTh8Feh8RebSluaCoQcE9NO/ hrsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=eadX0yqJTdmgFl7qyptwTWbT7FHRo60jJJdZBpGlMEM=; b=DlRfLckCCloHcEU/iZWgoxwz/ICXIhz5M2+3vE+8oJyDfhz3c2VlvNi5rZrkHb+Mo+ 2NPuLT+89ZeN4iSqZj6IVOgJJwxFlHMbUVOg0WXGt416rjOLgDxcv7yTaAPdkKVy4dte UM+VIvFMZ3RwE/YjU1VbnoQS3pa0sVMp6QJS2aFDT0Ajr3EK0JqqeIwaCmRqR0vdfaMj ylH+HCHGLeKAiU31X6ePBNqjE3R+kcIg4PvG1jtPhx5z296kjtwc01WT5lNpDcj3dV4I Ns7m0DB/8N/y8yO33XoLTp8/7CjMfyMkDVC23Rq8RbI+1Sbc7ihdGtCnugqD6Fu80i+s fziA==
X-Gm-Message-State: APjAAAXRPVANCnbsXyTKRUQmwdbnVe6BWiZo2Mr6YI4ZK/0fyhJZitPF DHkfmOPO/6vxGY5RzpoCV5s=
X-Google-Smtp-Source: APXvYqzR5b7UXdxZTjj9rF17dkV6GT9za4Q5IvTr5tKa9FrqD73D8bEJXXMQwTdN7SwI5YY+KlxqPA==
X-Received: by 2002:aa7:9157:: with SMTP id 23mr6431884pfi.61.1571775607267; Tue, 22 Oct 2019 13:20:07 -0700 (PDT)
Received: from [192.168.0.108] ([117.216.128.128]) by smtp.gmail.com with ESMTPSA id q33sm19436097pgm.50.2019.10.22.13.20.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2019 13:20:06 -0700 (PDT)
Date: Wed, 23 Oct 2019 01:20:00 +0500
From: Dinesh Dutt <didutt@gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, Anoop Ghanwani <anoop@alumni.duke.edu>, Jeffrey Haas <jhaas@pfrc.org>, Santosh P K <santosh.pallagatti@gmail.com>, NVO3 <nvo3@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, xiao.min2@zte.com.cn
Message-Id: <1571775600.10436.1@smtp.gmail.com>
In-Reply-To: <1571775471.10436.0@smtp.gmail.com>
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> <0b45df12-a7c5-3b5c-db59-5a57c8dfd1b7@joelhalpern.com> <CA+RyBmV9Ynk6fZy6qkvkOz3Pm2AmK7ESy8KoEpqyxP1nvNka0w@mail.gmail.com> <14ec7c38-5a5b-83dd-b4f4-71a29494ebdc@joelhalpern.com> <CA+RyBmWDRrjTR3OAnYsush8+4ORnGdKUqp46bg5MXaPa3zCgZA@mail.gmail.com> <ba234410-ba08-d9a5-0399-edd3901a60a6@joelhalpern.com> <1571775471.10436.0@smtp.gmail.com>
X-Mailer: geary/0.12.4
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-hxPhrjC7/IuCwsRbtq+n"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/2Djl8BOHVb02AMMiVR1p1d4OtJQ>
X-Mailman-Approved-At: Tue, 22 Oct 2019 14:45:07 -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, 22 Oct 2019 20:20:10 -0000
Oops, sorry for misspelling your name Joel, Dinesh On Wed, Oct 23, 2019 at 1:47 AM, Dinesh Dutt <didutt@gmail.com> wrote: > oel, > > I'm a tad frustrated that we're rehashing this discussions all over > again. I specifically explained all the questions that were raised at > that time. Let me try one last time. > > 1. BFD for VTEP is only useful for testing VXLAN plumbing, not the > underlay itself. > 2. So, the question is what do we use for VNI and the inner header? > 3. The inner header is an IP packet because it is BFD. The IP address > and the corresponding MAC address used MUST be one that is owned by > the VTEP in the VNI that is used in the packet > > This is sufficient to come up with an implementation that only ever > tests one VNI or multiple VNIs between thr same pair of VTEPs. It is > upto the users to decide what VNI, inner MAC and IP to use. The only > restriction is that the VTEP must own those addresses to (i) prevent > the packet from leaking to tenants and (ii) allow the tenants > themselves to be running BFD. > > If implementations want to use VNI 1 as the recommended default VNI > to use, that is fine. But if implementations want to pick more than 1 > because they have a need to do so (I've seen operators do this > because of their specific use case), then they can as long as they > satisfy point 3, the draft is done. Why does there need to be any > more discussion? The draft does need to spell out that using more > than VNI has scaling issues that the user needs to be aware of, and > it does. > > Dinesh > > On Wed, Oct 23, 2019 at 1:28 AM, Joel Halpern Direct > <jmh.direct@joelhalpern.com> wrote: >> That is input to the calculation at the VTEP. It is NOT information >> sued by the network between the VTEPs. >> >> As such, the VTEPs can emulate that by adjusting the source ports >> that it uses for the VFD packets. The network does not need the VNI >> to actually be varied to achieve this purpose. >> >> Yours, >> Joel >> >> On 10/22/2019 3:55 PM, Greg Mirsky wrote: >>> Hi Joel, >>> RFC 7348 suggests using information from the inner packet to >>> calculate the value to be used in the Source UDP port number: >>> - Source Port: It is recommended that the UDP source port >>> number >>> be calculated using a hash of fields from the inner >>> packet -- >>> one example being a hash of the inner Ethernet frame's >>> headers. >>> This is to enable a level of entropy for the ECMP/load- >>> balancing of the VM-to-VM traffic across the VXLAN >>> overlay. >>> From that text, I assume that VNI may be used as input for hashing >>> function. If BFD over VXLAN doesn't support per VNI BFD session, >>> then it cannot monitor multiple paths in underlay used to balance >>> VM-to-VM traffic between the same pair of VTEPs. In my opinion, >>> this is perfectly fine if that is WG's agreement. I'm glad we are >>> discussing this and will have a conclusion. >>> >>> Regards, >>> Greg >>> >>> On Tue, Oct 22, 2019 at 3:30 PM Joel M. Halpern >>> <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> wrote: >>> >>> As I recall, the VNI is not in the same place nor the same size >>> as the >>> TCP / UDP ports. So it seems very unlikely that it would be >>> used in >>> ECMP. In fact, avoiding that is why VXLAN does interesting >>> things with >>> the source UDP port. Which the BFD can do. And presumably >>> MUST do if >>> it was path matching. >>> >>> Yours, >>> Joel >>> >>> On 10/22/2019 3:16 PM, Greg Mirsky wrote: >>> > Hi Joel, >>> > if the underlay may balance VXLAN between two VTEPs using >>> VNI in >>> > addition to other fields, then Option 2 has a certain value >>> in my >>> opinion. >>> > >>> > Regards, >>> > Greg >>> > >>> > On Tue, Oct 22, 2019 at 3:06 PM Joel M. Halpern >>> <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> >>> > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>> >>> wrote: >>> > >>> > I do not understand the value of option 2. >>> > Which is why I asked in my initial review to move to >>> option 1. >>> > >>> > And option 2 requires stealing MAC addresses from the >>> users, >>> which >>> > seems >>> > to me to be a very bad thing that option 1 avoids. >>> > >>> > Yours, >>> > Joel >>> > >>> > On 10/22/2019 2:17 PM, Greg Mirsky 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>>>> 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>>>> 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>>>> >>> 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>>> >>> > > 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