Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Dinesh Dutt <didutt@gmail.com> Wed, 30 October 2019 11:46 UTC
Return-Path: <didutt@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A69312013C; Wed, 30 Oct 2019 04:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.796
X-Spam-Level:
X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYWGlCQ983aQ; Wed, 30 Oct 2019 04:46:08 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 B2CEB1200CE; Wed, 30 Oct 2019 04:46:08 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id 3so1397488pfb.10; Wed, 30 Oct 2019 04:46:08 -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=H7WlfqlE+h3BmhxchDx4L2ZGvSzGkt8snJXe2Krzpyk=; b=orP4Q8Skzp6Qay0Wx6GTwcic6i9VxrOlcdRTL/pTn95hI/AsxoGQKGrT8FGX/cGzMB RqdT7YlfGaCz8LB+ALUQ1MyVsjmPjiSrJvZr5I85iNtLaENbPcyjrgCGZ8R4rp9uQyTT MMCczPtb6+X1tE8kbFP5Y7q8RHkFs6hZ6ZD6pnsJ4B3suV4EHztF+hb8d6UWtZrDo0Wu A9WO9TgPc2fWPeVaHubTIBGtDj+SWMCr/SU1olqN4W2h0BxcdF9ygBSC31FbGfwx2+zl nbcr09qLWyRUapne+mfBJq3S3F48UjaNaCgBWKThlPMUjV7BgkPD1/ydzqSvIgFfv0im m48A==
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=H7WlfqlE+h3BmhxchDx4L2ZGvSzGkt8snJXe2Krzpyk=; b=XiZAyttqZsNtwiOx8ykD35UbtvdLx4ZNU5P0qz95LjUAcgPz6gCSHfU3NvVDKhEp/S nZv7UUmTD6BqlQ+EFu6O7TCJHRnvAKmKJwDTlfb6fzSBR+t/xbjHQmiRnWgy1yjlCkG3 w0PAs7dzjFEVJU//MhduS+gzXqiRiSib1JN4mWboMANGu65pf/NtM1rkpkif4h8RjRDp 4/ov0WBZCosYCbZ22eFg0bzfbikivOoKzH+OZ1IJhvvsIxhjSfYVX2fSccvBA2AQO4GX vF6g5M/RcRj54Tfd/A7Ukfko8Hw48cH5zPlNo7uTETPcoQbLc2fXEiRdMRs6ghNzLv/M JKMw==
X-Gm-Message-State: APjAAAWMAwvmDFEszzIgOxOwo8DBRowlg2yk0M/ApXGijteLZMm3Rgj2 JUpzbe9V2+V7EcSjaLWRk8I=
X-Google-Smtp-Source: APXvYqwBj61vPbcFZInzVt8B/f+DeFNbbAbJJMVDkAOgUnut6K+pReIOoQAU5QE3r8h8WP3OTIbGJQ==
X-Received: by 2002:a63:4a48:: with SMTP id j8mr19580924pgl.221.1572435967831; Wed, 30 Oct 2019 04:46:07 -0700 (PDT)
Received: from [192.168.31.130] ([111.93.158.109]) by smtp.gmail.com with ESMTPSA id 127sm3064153pfw.6.2019.10.30.04.46.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Oct 2019 04:46:06 -0700 (PDT)
Date: Wed, 30 Oct 2019 16:45:56 +0500
From: Dinesh Dutt <didutt@gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, 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: <1572435956.28051.12@smtp.gmail.com>
In-Reply-To: <CA+-tSzzSNnR=fKRU+mEX=d+tL5B0u8eNUAoGcPvfrna_qHL7Hg@mail.gmail.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> <1572400778.28051.7@smtp.gmail.com> <CA+-tSzyNu8XVqL7=cGVaT7Mbg5yO6d3ohgv2qPTrMHRV1vw0rg@mail.gmail.com> <1a38424c-6bc1-4414-a7fd-c1e2105b581a@Spark> <CA+-tSzzSNnR=fKRU+mEX=d+tL5B0u8eNUAoGcPvfrna_qHL7Hg@mail.gmail.com>
X-Mailer: geary/0.12.4
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-ajmQCSFOLmGt2p9Q86gB"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/k9_xG48w-9TM1m3LWRtMehywVxo>
X-Mailman-Approved-At: Wed, 30 Oct 2019 07:36:57 -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: Wed, 30 Oct 2019 11:46:14 -0000
On Wed, Oct 30, 2019 at 11:40 AM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote: > Hi Dinesh, > > Your earlier comment was about silicon, that's why I discussed only > the trapping issue. As far as software goes, IP stacks would > typically discard packets received from a non-loopback interface if > the packet's address is in 127/8. I am not sure a traditional IP > stack can play here because even on Tx, we have the same MAC for > reaching all remote VTEPs. It seems to me the BFD module would have > to be working directly with L2 frames coming off the tunnel. Kind of > like if we were running LLDP between the VTEPs. Hi Anoop, My earlier comment was indeed about silicon, but the packet has to go through the software stack as well once it gets to the CPU. Linux-based solutions such as Linux servers or Cumulus Linux or maybe even SONIC will need to have a valid IP address to process the packet. Given that 127/8 is already mandated by MPLS BFD, sticking with that is better than ignoring the IP address. This is why I agreed with Jeffrey Haas' comment about SHOULD be set. Dinesh > > Thanks, > Anoop > > On Tue, Oct 29, 2019 at 10:02 PM Dinesh Dutt <didutt@gmail.com> wrote: >> Trapping to the CPU would be fine based on MAC DA. But once there, a >> self-respecting network stack would look at the IP header to decide >> what to do. Ignoring it on receive may not be an option, >> >> Dinesh >> On Oct 30, 2019, 10:26 AM +0530, Anoop Ghanwani >> <anoop@alumni.duke.edu>, wrote: >>> Hi Dinesh, >>> >>> What would break? If messages are trapped to CPU based on the MAC >>> DA, what is the problem? >>> >>> On the flip side, there are implementations running BFD today which >>> use different addresses as specified here: >>> http://www.openvswitch.org/support/dist-docs/vtep.5.html >>> >>> >>> bfd_config_local : bfd_dst_ip: optional string >>> Set to an IPv4 address to set the IP address that is >>> expected as >>> destination for received BFD packets. The >>> default is >>> 169.254.1.0. >>> >>> >>> >>> Thanks, >>> Anoop >>> >>> On Tue, Oct 29, 2019 at 7:01 PM Dinesh Dutt <didutt@gmail.com> >>> wrote: >>>> 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 > > >>>>>> > >>>> > > > > > > >>>>>
- 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