Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Dinesh Dutt <didutt@gmail.com> Wed, 30 October 2019 02:01 UTC
Return-Path: <didutt@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 26F9D12009E; Tue, 29 Oct 2019 19:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) 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 TNcn6-AY62g3; Tue, 29 Oct 2019 19:01:15 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 DDB28120059; Tue, 29 Oct 2019 19:01:14 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id w3so361726pgt.5; Tue, 29 Oct 2019 19:01:14 -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=zD7z8CHd/UzT0dMrqDEmR3657vCn2Zl61k4WSCyKSus=; b=WJJZQIztki9MqMq6zO+WwBdtYJyNTHvWsE9pBWOPKdbNoHn9d/gkCB/lKrKfO/Stg2 sTStkQSAmdE+HinA1fXpUK024ofF2u2GU18R0bcSi68H/sncJVcMdu+GSPi5jXQzXMTX LyZasTUjdZJsh8kHrYAkwzFYkiSyyDHjtMtDQZvPMs/ctreXEoCeMCjk5U+ltPrQI4Rt K5r/5AJyXS1eV1XbXHi79dK1yvCs4k+47ORhCNjm3XDtwLTkBvKqJBLdIAzA3BsJuwyJ ZFLx8jpH5fuvd96fWrdra/D0+GbOLaxTfk5pztrOoBrqAw+1sDDkAHbjxSqCtlzFd9Gi yU2A==
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=zD7z8CHd/UzT0dMrqDEmR3657vCn2Zl61k4WSCyKSus=; b=rJ7q5aP46PedRSihSTo/ty1Ax+yi1jRj5lAu5RXSweNA6mwLxwZZ8qtsUqjAOnrh5T 7rldfkQPWMC88DWsksQ0eHrGD+Bdqge4oC96QRukx9iFnzuGrPn1/568NsbHlyYfy10U SUr8Qb//mewuSB3ed6E7p9xgFNVB91grim1F1pFQk3JN6/uFQtfV9XHyU0TCfhz0yY4y SUkWbbEinFeZy2KP9tfJFTfP0B12Q4L5qSyozWTCJcYwiNvFl2HI4xDfVlvbg61Dq+pC KLWqzwU5Qyo6NBNmvqVWMvxxjHIv8mjWNPqh86Ye+57KOuXinNX906AqfIN6Pv+wCHJj mYIg==
X-Gm-Message-State: APjAAAUcdIMJBgX3Zz7WByYcN4k+u+9Zyskh/PGRW9sW3FvxszwaBFYa bScoKixQ89/ruZ8QBFtYKCI=
X-Google-Smtp-Source: APXvYqyJZcfFunuWCQ2lXXhqXmJ1y0bt8l8HJThA9uf0MITeTIfiwNH1qxJbv1OBWZ+POWiSZHFdxA==
X-Received: by 2002:a17:90a:b946:: with SMTP id f6mr10306275pjw.69.1572400873896; Tue, 29 Oct 2019 19:01:13 -0700 (PDT)
Received: from [192.168.1.9] ([117.213.198.17]) by smtp.gmail.com with ESMTPSA id j25sm389347pfi.113.2019.10.29.19.00.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Oct 2019 19:01:12 -0700 (PDT)
Date: Wed, 30 Oct 2019 06:59:38 +0500
From: Dinesh Dutt <didutt@gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Anoop Ghanwani <anoop@alumni.duke.edu>, Santosh P K <santosh.pallagatti@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
Message-Id: <1572400778.28051.7@smtp.gmail.com>
In-Reply-To: <aa853b8e-7ff4-a2d9-9b66-f9c22823ac9d@joelhalpern.com>
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>
X-Mailer: geary/0.12.4
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-8g7zpW5Bf20wEZ8pdC2M"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/qCCuxOCj7lILx_EGxLzZaw8K-Oo>
X-Mailman-Approved-At: Wed, 30 Oct 2019 08:17:16 -0700
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: Wed, 30 Oct 2019 02:01:21 -0000
I suspect silicon implementations will have a problem with saying that they can be set to anything and MUST be ignored on reception. Your logic is sound, it's just that I fear you'll break many existing implementations. I recommend sticking with the 127/8 address for this case. Dinesh On Tue, Oct 29, 2019 at 9:15 PM, 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 >> > > > >>>> >> > > > >> > > >> > >>
- 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