Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Anoop Ghanwani <anoop@alumni.duke.edu> Tue, 29 October 2019 15:55 UTC
Return-Path: <ghanwani@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 9E517120894; Tue, 29 Oct 2019 08:55:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vqiVWTsc9MOV; Tue, 29 Oct 2019 08:55:23 -0700 (PDT)
Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (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 EF05F120819; Tue, 29 Oct 2019 08:55:22 -0700 (PDT)
Received: by mail-vs1-f45.google.com with SMTP id k15so9083208vsp.2; Tue, 29 Oct 2019 08:55:22 -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=Vr3TjuYq5UcbuNpak89LlkWK1XKQHQ7NH95vf/8oBbo=; b=G3gAjRVcKjLRnQiZ0UnUW+0oFclwnleSyty7cd23XmBYsOwluBxnFGGzbxDSJ5gSwk UIsQnLvFOAZTKpO3LS0qPmtdw9Thr8wE7f5wUZJs4Rmx3U2V0w0935sj00O5BoSqMv3E 3TqGFBVg8WJEOSCRC4lw4ykwBT08i38jquQYKRy6aIqr9IGf6pzdZgDNs5v9YOQtS53b gd+g0nacDwjX24HBhq1Ht+MaLObxneZEyhZlcFmu6SE2O5rfW1H8ae3tGQ4Qt63UQFSE y8EfOAcLUEq3spWPTWL9k26CSj2w6ERKS2fATxHwFHqZnU09pxcY8NEpnc13Uzo1Hfa2 y/GQ==
X-Gm-Message-State: APjAAAVF8/kgnHjTL29YK7FCEm3N37vcdfPP8LywSrsr8hDU+p8wxfvy 9nZx5/ieuG2oBQR3ohgpE1PZk597XO5FRjdFyIc=
X-Google-Smtp-Source: APXvYqy2W6YRYzbIiDgISlNwLN/e/DC+nDy5P3f/Xi02QDM3lEU9V9PliBnkcr15IM+JDVfBke73bnrICv/NDeODRmw=
X-Received: by 2002:a67:fe46:: with SMTP id m6mr2266707vsr.119.1572364521603; Tue, 29 Oct 2019 08:55:21 -0700 (PDT)
MIME-Version: 1.0
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> <aa853b8e-7ff4-a2d9-9b66-f9c22823ac9d@joelhalpern.com>
In-Reply-To: <aa853b8e-7ff4-a2d9-9b66-f9c22823ac9d@joelhalpern.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Tue, 29 Oct 2019 08:55:09 -0700
Message-ID: <CA+-tSzxEiMcF3qXauOKfOFPmXY0b+iaXkW6i1HoSeogTX4MfzA@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: "Joel M. Halpern" <jmh@joelhalpern.com>
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
Content-Type: multipart/alternative; boundary="000000000000c488f105960ea4e5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/h5k1v_xiGviFMxu_BXujxxgky3E>
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:55:29 -0000
Joel, >>> 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. >>> I think this would be better than disallowing anything other than an address from the loopback subnet. Thanks, Anoop On Tue, Oct 29, 2019 at 8:45 AM Joel M. Halpern <jmh@joelhalpern.com> wrote: > 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