Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Greg Mirsky <gregimirsky@gmail.com> Wed, 30 October 2019 20:59 UTC
Return-Path: <gregimirsky@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 D7B6A120825; Wed, 30 Oct 2019 13:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, 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 oWhL3zP3UZNQ; Wed, 30 Oct 2019 13:58:48 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 C2521120103; Wed, 30 Oct 2019 13:58:46 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id 139so4269035ljf.1; Wed, 30 Oct 2019 13:58:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O1Svw3meB4XEO3IoTdkP02rtQHkAYb2vhmvqMNTvxPU=; b=fjOgNGnA32+ayfMbR3Mc/2nzUboRpf2a/rN8x1GJJayhXnJUorVe66CdyJrnK1q6WR YliGNscMVdAmyKKpt334cSeakjjikGXlxT0IpilcKFM07pnxISTGq9tAB7vb50WpNLZy Vupr6uMoYT6Nx5YHzHvUnYD0ZbwOVqIRnx324IU/wmUzWL0VahhbDN2OiVU9B+MKtGIB NmdEbyhTJ9QhTu4jnnSphgabqq7CQuJccLZNymO98OwUB1EqjyPl70FEzzS9ExkloU5n jiOxPJJeAtO/ZoRmJvBtEy5XozG+mQQEXMznRaosk78rMxh7zOJLVk6dCNvd4uJOljr3 ziYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O1Svw3meB4XEO3IoTdkP02rtQHkAYb2vhmvqMNTvxPU=; b=I7CvNc56fBxrAWYjhCrl5m6s15EdcbCpMtP0BonwP2+T8Y3K8WSs5jNecyNAGICUJ9 jCGwrAefjpquthRLJ4oufFIbmynxFHcamsDNtkQc3aJeSq1sM0WuauTmqg/fZV4rwgL8 PoLBLAPs3aNZLhizBuN/aNoGCVyfJht00zQ1ONsnK1HYK4UuVER6ZxF3lDrXw3qorY3U zbiK6h8aigfzW42Q03DJVimqCa9PXocZPRZI+DKPIkdeY8i0QIhzLg5cNO03eYl+SWIR clbSWxiyLZxzlm1ss/i55oSqMtp6C4KyFox8gbEYTe3t4j10TnXXBf7BaW0zpQ+EyuAM vsyg==
X-Gm-Message-State: APjAAAVKyrSJ76pgBXfiWRJdthGB2JsbcDUC3Vv2eROBBdd3KN1tGKWZ oU28YsKHY3+DNt9cy5rfihNLQPrTdvvfa7JAOMQ=
X-Google-Smtp-Source: APXvYqxsPVgwc4WXpGX3q/I1iERlRB33VzBB/DLB1frx0/0Jj4E8r+3pVZ+zfFq+sFwYqZgZxBPthUPGLe4KK5MV04w=
X-Received: by 2002:a2e:9e4c:: with SMTP id g12mr1214499ljk.103.1572469124336; Wed, 30 Oct 2019 13:58:44 -0700 (PDT)
MIME-Version: 1.0
References: <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> <1572435956.28051.12@smtp.gmail.com> <CA+RyBmWgvjDLdxEz7oZEfYjtJT=7CZbiV5bRkx=gf3hQHHokOw@mail.gmail.com> <20191030203051.GD10145@pfrc.org>
In-Reply-To: <20191030203051.GD10145@pfrc.org>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 30 Oct 2019 13:58:30 -0700
Message-ID: <CA+RyBmVTWMOuXaWVk_i1Lk7i+GgfiESkfVcLXARNnPD0Y3N5zQ@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: Dinesh Dutt <didutt@gmail.com>, Anoop Ghanwani <anoop@alumni.duke.edu>, "Joel M. Halpern" <jmh@joelhalpern.com>, Santosh P K <santosh.pallagatti@gmail.com>, NVO3 <nvo3@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, xiao.min2@zte.com.cn
Content-Type: multipart/alternative; boundary="000000000000939187059626ff41"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/_S2oG3g0oTbiVU6lnSLOnsgwlj0>
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 20:59:06 -0000
Hi Jeff, thank you for your comments and suggestion. Please find my answers below in-lined under the GIM>> tag. Regards, Greg On Wed, Oct 30, 2019 at 1:27 PM Jeffrey Haas <jhaas@pfrc.org> wrote: > Greg, > > From the updated text: > > "At the same time, a service layer BFD session may be used between the > tenants of VTEPs IP1 and IP2 to provide end-to-end fault management. In > such case, for VTEPs BFD Control packets of that session are > indistinguishable from data packets. If end-to-end defect detection is > realized as the set of concatenated OAM domains, e.g., VM1-1 - IP1 -- > IP2 - VM2-1, then the BFD session over VXLAN between VTEPs SHOULD > follow the procedures described in Section 6.8.17 [RFC5880]." > > In the case that two VMs are running BFD to each other as a user > application > rather than as part of the virtualized environment, it's unlikely that > they'd be treated as concatenated domains. To do so, the tenant VMs would > have to have a sense that they are indeed virtual. > > Is your intent in this text that BFD implementations on the server should > detect BFD sessions between servers and change them to a concatenated > session? > GIM>> No, we do not suggest that the concatenation of BFD sessions be automagical. That may be controlled via the management plane though. > > Section 5 comment: > > : The UDP destination port and the TTL of the inner IP packet MUST be > : validated to determine if the received packet can be processed by > : BFD. BFD Control packets with unknown MAC address MUST NOT be > : forwarded to VMs. > > I'd suggest pushing the second sentence into the prior section since it > deals with MAC addresses rather than the UDP procedures. > GIM>> Could you please clarify your suggestion - move to Section 4 or to the preceding paragraph? I think it is the latter but wanted to make sure. > > -- Jeff > > > On Wed, Oct 30, 2019 at 01:06:23PM -0700, Greg Mirsky wrote: > > Dear All, > > thank you for your comments, suggestions that have made the discussion > the > > most helpful to the Editors. I've tried to reflect your comments in the > > updates listed below: > > > > - on the inner destination IP address: > > > > OLD TEXT: > > Destination IP: IP address MUST NOT be of one of tenant's IP > > addresses. IP address MAY be selected from the range 127/8 for > > IPv4, for IPv6 - from the range 0:0:0:0:0:FFFF:7F00:0/104. > > NEW TEXT: > > Destination IP: IP address MUST NOT be of one of tenant's IP > > addresses. The IP address SHOULD be selected from the range > 127/8 > > for IPv4, for IPv6 - from the range 0:0:0:0:0:FFFF:7F00:0/104. > > Alternatively, the destination IP address MAY be set to VTEP's > > IP address. > > > > - firewall. Appended Section 3 Deployment with the following > paragraph: > > > > As per Section 4, the inner destination IP address SHOULD be set to > > one of the loopback addresses (127/8 range for IPv4 and > > 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6). There could be a firewall > > configured on VTEP to block loopback addresses if set as the > > destination IP in the inner IP header. It is RECOMMENDED to allow > > addresses from the loopback range through a firewall only if it is > > used as the destination IP address in the inner IP header, and the > > destination UDP port is set to 3784 [RFC5881]. > > > > Regarding the use of VNI 0 as the Management VNI. In Section 6 has been > > noted: > > An implementation MAY support the use of the Management > > VNI as control and management channel between VTEPs. The selection > > of the VNI number of the Management VNI MUST be controlled through > > management plane. An implementation MAY use VNI number 1 as the > > default value for the Management VNI. > > > > Attached, please find the updated working version and the diff to -07. > > Editors much appreciate your comments, suggestions, abd help to have the > > new version uploaded before the cut-off deadline. > > > > Regards, > > Greg > > > > On Wed, Oct 30, 2019 at 4:46 AM Dinesh Dutt <didutt@gmail.com> wrote: > > > > > > > > > > > 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 > > >> >>> > > >> > > >> *b**f**d**_**c**o**n**f**i**g**_**l**o**c**a**l* *:* > *b**f**d**_**d**s**t**_**i**p*: optional string > > >> Set to an IPv4 address to set the IP address that is > expected as > > >> destination for received BFD packets. The > default is > > >> *1**6**9**.**2**5**4**.**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 > > >>> <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 > > >>> <jmh@joelhalpern.com>> > <mailto:jmh@joelhalpern.com > > >>> <jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com < > 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 <jmh@joelhalpern.com>> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>> > > < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <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 > > >>> <jmh@joelhalpern.com>> <mailto:jmh@joelhalpern.com < > jmh@joelhalpern.com> > > >>> <mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>> > < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>>> > > > > < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>> > < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <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 > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>>> > > > > >>> > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com > >>>> > > >>> > > > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>>> > > > > >>> > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com > >>>>> > > >>> > > > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>>> > > > > >>> > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com > >>>> > > >>> > > > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>>> > > > > >>> > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <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 <didutt@gmail.com>> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>>> > <mailto:didutt@gmail.com < > didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com> <mailto:didutt@gmail.com <didutt@gmail.com>>>> > > > >>> > > <mailto:didutt@gmail.com <didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com> <mailto:didutt@gmail.com <didutt@gmail.com>>> > > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>> <mailto:didutt@gmail.com <didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>>>>> > > > > > > > >>> <mailto:didutt@gmail.com <didutt@gmail.com> <mailto: > didutt@gmail.com > > >>> <didutt@gmail.com>> > <mailto:didutt@gmail.com <didutt@gmail.com> > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>>> <mailto: > didutt@gmail.com > > >>> <didutt@gmail.com> <mailto:didutt@gmail.com <didutt@gmail.com>> > > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>>>> > > <mailto:didutt@gmail.com > > >>> <didutt@gmail.com> <mailto:didutt@gmail.com <didutt@gmail.com>> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>>> > <mailto:didutt@gmail.com < > didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com> <mailto:didutt@gmail.com <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 > > >>> <gregimirsky@gmail.com>> > <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>>> > > <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>>>> > <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>>> > > <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>>>>> > > > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>>> > > > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <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 <santosh.pallagatti@gmail.com>> > > > > >>> <mailto:santosh.pallagatti@gmail.com < > santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>>> > > > > >>> > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com > >>>> > > >>> > > > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>>> > > > > >>> > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com > >>>>> > > >>> > > > >> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>>> > > > > >>> > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com > >>>> > > >>> > > > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>>> > > > > >>> > <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com> <mailto:santosh.pallagatti@gmail.com > > >>> <santosh.pallagatti@gmail.com>> > < > > >>> mailto:santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com> < > > >>> mailto:santosh.pallagatti@gmail.com <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 > > >>> <gregimirsky@gmail.com>> > <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>>> > > <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>>>> > > > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>>>> > > > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>>> > > > > >>> > <mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <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 > > >>> <didutt@gmail.com>> > <mailto:didutt@gmail.com <didutt@gmail.com> > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>>> > > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>> <mailto:didutt@gmail.com <didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>>>> > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>> <mailto:didutt@gmail.com <didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>>> > > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>> <mailto:didutt@gmail.com <didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>>>>> > > > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>> <mailto:didutt@gmail.com <didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>>> > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>> <mailto:didutt@gmail.com <didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>>>> > > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>> <mailto:didutt@gmail.com <didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <didutt@gmail.com>>> > < > > >>> mailto:didutt@gmail.com <didutt@gmail.com> <mailto:didutt@gmail.com > > >>> <didutt@gmail.com>> <mailto:didutt@gmail.com <didutt@gmail.com> < > > >>> mailto:didutt@gmail.com <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 > > >>> <anoop@alumni.duke.edu>> > <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu>>> > > <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu>> <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu>>>> > > > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>>> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>>>>> > > > > >>> > >>> <mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>>> > > > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>>>> > > > > >>> > <mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>>> > > > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <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 > > >>> <gregimirsky@gmail.com>> > <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>>> > > <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>>>> > > > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>>>> > > > > >>> > >>>> > <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>>> > > <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > >>> <gregimirsky@gmail.com>>>> > > > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>>> > > > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>> > < > > >>> mailto:gregimirsky@gmail.com <gregimirsky@gmail.com> < > > >>> mailto:gregimirsky@gmail.com <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 <anoop@alumni.duke.edu>> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>>> > > > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>>>> > > > > >>> > <mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>>> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>>>>> > > > > >>> > >>>> > <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu>> <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu>>> > > <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu>> <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu> <mailto:anoop@alumni.duke.edu > > >>> <anoop@alumni.duke.edu>>>> > > > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>>> > > > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu>> > < > > >>> mailto:anoop@alumni.duke.edu <anoop@alumni.duke.edu> < > > >>> mailto:anoop@alumni.duke.edu <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 > > >>> <jmh@joelhalpern.com>> <mailto:jmh@joelhalpern.com < > jmh@joelhalpern.com> > > >>> <mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>> > < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>>> > > > > > >>> <mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> > < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> > < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>>>> > > > > > >>> >>>> > <mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>> > > < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>>> > > > > > >>> <mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> > < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>>> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com>> > < > > >>> mailto:jmh@joelhalpern.com <jmh@joelhalpern.com> < > > >>> mailto:jmh@joelhalpern.com <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 > > >>> <xiao.min2@zte.com.cn>> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn>>> > > <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn>> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn>>>> > > > < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>> > < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>>> < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>> > < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>>>>> > > > > > > >>> >>>> > > <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn>> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn>>> > <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn>> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn> <mailto:xiao.min2@zte.com.cn > > >>> <xiao.min2@zte.com.cn>>>> > > > < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>> > < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>>> < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>> > < > > >>> mailto:xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> < > > >>> mailto:xiao.min2@zte.com.cn <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 > > >>> <nvo3@ietf.org>> <mailto:nvo3@ietf.org <nvo3@ietf.org> < > > >>> mailto:nvo3@ietf.org <nvo3@ietf.org>>> > <mailto:nvo3@ietf.org > > >>> <nvo3@ietf.org> <mailto:nvo3@ietf.org <nvo3@ietf.org>> < > > >>> mailto:nvo3@ietf.org <nvo3@ietf.org> <mailto:nvo3@ietf.org > > >>> <nvo3@ietf.org>>>> > > <mailto:nvo3@ietf.org <nvo3@ietf.org> > < > > >>> mailto:nvo3@ietf.org <nvo3@ietf.org>> <mailto:nvo3@ietf.org > > >>> <nvo3@ietf.org> <mailto:nvo3@ietf.org <nvo3@ietf.org>>> > < > > >>> mailto:nvo3@ietf.org <nvo3@ietf.org> <mailto:nvo3@ietf.org > > >>> <nvo3@ietf.org>> <mailto:nvo3@ietf.org <nvo3@ietf.org> < > > >>> mailto:nvo3@ietf.org <nvo3@ietf.org>>>>> <mailto:nvo3@ietf.org > > >>> <nvo3@ietf.org> <mailto:nvo3@ietf.org <nvo3@ietf.org>> > < > > >>> mailto:nvo3@ietf.org <nvo3@ietf.org> <mailto:nvo3@ietf.org > > >>> <nvo3@ietf.org>>> > > <mailto:nvo3@ietf.org <nvo3@ietf.org> > < > > >>> mailto:nvo3@ietf.org <nvo3@ietf.org>> <mailto:nvo3@ietf.org > > >>> <nvo3@ietf.org> <mailto:nvo3@ietf.org <nvo3@ietf.org>>>> > > > > >>> > <mailto:nvo3@ietf.org <nvo3@ietf.org> <mailto:nvo3@ietf.org > > >>> <nvo3@ietf.org>> <mailto:nvo3@ietf.org <nvo3@ietf.org> < > > >>> mailto:nvo3@ietf.org <nvo3@ietf.org>>> > <mailto:nvo3@ietf.org > > >>> <nvo3@ietf.org> <mailto:nvo3@ietf.org <nvo3@ietf.org>> < > > >>> mailto:nvo3@ietf.org <nvo3@ietf.org> <mailto:nvo3@ietf.org > > >>> <nvo3@ietf.org>>>>>> > > > >>>> > > >>> https://www.ietf.org/mailman/listinfo/nvo3 > > > > >>>> > > > >>> > > > > > > > >>> > > >>> > > > > > > > > > > > BFD S. Pallagatti, Ed. > > Internet-Draft VMware > > Intended status: Standards Track S. Paragiri > > Expires: May 2, 2020 Individual Contributor > > V. Govindan > > M. Mudigonda > > Cisco > > G. Mirsky > > ZTE Corp. > > October 30, 2019 > > > > > > BFD for VXLAN > > draft-ietf-bfd-vxlan-08 > > > > Abstract > > > > This document describes the use of the Bidirectional Forwarding > > Detection (BFD) protocol in point-to-point Virtual eXtensible Local > > Area Network (VXLAN) tunnels forming up an overlay network. > > > > Status of This Memo > > > > This Internet-Draft is submitted in full conformance with the > > provisions of BCP 78 and BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF). Note that other groups may also distribute > > working documents as Internet-Drafts. The list of current Internet- > > Drafts is at https://datatracker.ietf.org/drafts/current/. > > > > Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > > > This Internet-Draft will expire on May 2, 2020. > > > > Copyright Notice > > > > Copyright (c) 2019 IETF Trust and the persons identified as the > > document authors. All rights reserved. > > > > This document is subject to BCP 78 and the IETF Trust's Legal > > Provisions Relating to IETF Documents > > (https://trustee.ietf.org/license-info) in effect on the date of > > publication of this document. Please review these documents > > carefully, as they describe your rights and restrictions with respect > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 1] > > > > Internet-Draft BFD for VXLAN October 2019 > > > > > > to this document. Code Components extracted from this document must > > include Simplified BSD License text as described in Section 4.e of > > the Trust Legal Provisions and are provided without warranty as > > described in the Simplified BSD License. > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > > 2. Conventions used in this document . . . . . . . . . . . . . . 3 > > 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 > > 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 4. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 5 > > 5. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 7 > > 5.1. Demultiplexing of the BFD Packet . . . . . . . . . . . . 8 > > 6. Use of the Specific VNI . . . . . . . . . . . . . . . . . . . 8 > > 7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 8 > > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 > > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > > 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 > > 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 > > 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 > > 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 > > 12.2. Informational References . . . . . . . . . . . . . . . . 10 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 > > > > 1. Introduction > > > > "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides an > > encapsulation scheme that allows building an overlay network by > > decoupling the address space of the attached virtual hosts from that > > of the network. > > > > One use of VXLAN is in data centers interconnecting virtual machines > > (VMs) of a tenant. VXLAN addresses requirements of the Layer 2 and > > Layer 3 data center network infrastructure in the presence of VMs in > > a multi-tenant environment by providing a Layer 2 overlay scheme on a > > Layer 3 network [RFC7348]. Another use is as an encapsulation for > > Ethernet VPN [RFC8365]. > > > > This document is written assuming the use of VXLAN for virtualized > > hosts and refers to VMs and VXLAN Tunnel End Points (VTEPs) in > > hypervisors. However, the concepts are equally applicable to non- > > virtualized hosts attached to VTEPs in switches. > > > > In the absence of a router in the overlay, a VM can communicate with > > another VM only if they are on the same VXLAN segment. VMs are > > unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VTEP. > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 2] > > > > Internet-Draft BFD for VXLAN October 2019 > > > > > > VTEPs are responsible for encapsulating and decapsulating frames > > exchanged among VMs. > > > > Ability to monitor path continuity, i.e., perform proactive > > continuity check (CC) for point-to-point (p2p) VXLAN tunnels, is > > important. The asynchronous mode of BFD, as defined in [RFC5880], is > > used to monitor a p2p VXLAN tunnel. > > > > In the case where a Multicast Service Node (MSN) (as described in > > Section 3.3 of [RFC8293]) resides behind a Network Virtualization > > Endpoint (NVE), the mechanisms described in this document apply and > > can, therefore, be used to test the connectivity from the source NVE > > to the MSN. > > > > This document describes the use of Bidirectional Forwarding Detection > > (BFD) protocol to enable monitoring continuity of the path between > > VXLAN VTEPs, performing as Network Virtualization Endpoints, and/or > > availability of a replicator multicast service node. > > > > 2. Conventions used in this document > > > > 2.1. Terminology > > > > BFD Bidirectional Forwarding Detection > > > > CC Continuity Check > > > > p2p Point-to-point > > > > MSN Multicast Service Node > > > > NVE Network Virtualization Endpoint > > > > VFI Virtual Forwarding Instance > > > > VM Virtual Machine > > > > VNI VXLAN Network Identifier (or VXLAN Segment ID) > > > > VTEP VXLAN Tunnel End Point > > > > VXLAN Virtual eXtensible Local Area Network > > > > 2.2. Requirements Language > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > > "OPTIONAL" in this document are to be interpreted as described in BCP > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 3] > > > > Internet-Draft BFD for VXLAN October 2019 > > > > > > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > > capitals, as shown here. > > > > 3. Deployment > > > > Figure 1 illustrates the scenario with two servers, each of them > > hosting two VMs. The servers host VTEPs that terminate two VXLAN > > tunnels with VXLAN Network Identifier (VNI) number 100 and 200 > > respectively. Separate BFD sessions can be established between the > > VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 > > and 200). An implementation that supports this specification MUST be > > able to control the number of BFD sessions that can be created > > between the same pair of VTEPs. BFD packets intended for a VTEP MUST > > NOT be forwarded to a VM as a VM may drop BFD packets leading to a > > false negative. This method is applicable whether the VTEP is a > > virtual or physical device. > > > > > > +------------+-------------+ > > | Server 1 | > > | +----+----+ +----+----+ | > > | |VM1-1 | |VM1-2 | | > > | |VNI 100 | |VNI 200 | | > > | | | | | | > > | +---------+ +---------+ | > > | VTEP (IP1) | > > +--------------------------+ > > | > > | +-------------+ > > | | Layer 3 | > > +---| Network | > > +-------------+ > > | > > +-----------+ > > | > > +------------+-------------+ > > | VTEP (IP2) | > > | +----+----+ +----+----+ | > > | |VM2-1 | |VM2-2 | | > > | |VNI 100 | |VNI 200 | | > > | | | | | | > > | +---------+ +---------+ | > > | Server 2 | > > +--------------------------+ > > > > > > Figure 1: Reference VXLAN Domain > > > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 4] > > > > Internet-Draft BFD for VXLAN October 2019 > > > > > > At the same time, a service layer BFD session may be used between the > > tenants of VTEPs IP1 and IP2 to provide end-to-end fault management. > > In such case, for VTEPs BFD Control packets of that session are > > indistinguishable from data packets. If end-to-end defect detection > > is realized as the set of concatenated OAM domains, e.g., VM1-1 - IP1 > > -- IP2 - VM2-1, then the BFD session over VXLAN between VTEPs SHOULD > > follow the procedures described in Section 6.8.17 [RFC5880]. > > > > As per Section 4, the inner destination IP address SHOULD be set to > > one of the loopback addresses (127/8 range for IPv4 and > > 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6). There could be a firewall > > configured on VTEP to block loopback addresses if set as the > > destination IP in the inner IP header. It is RECOMMENDED to allow > > addresses from the loopback range through a firewall only if it is > > used as the destination IP address in the inner IP header, and the > > destination UDP port is set to 3784 [RFC5881]. > > > > 4. BFD Packet Transmission over VXLAN Tunnel > > > > BFD packet MUST be encapsulated and sent to a remote VTEP as > > explained in this section. Implementations SHOULD ensure that the > > BFD packets follow the same lookup path as VXLAN data packets within > > the sender system. > > > > BFD packets are encapsulated in VXLAN as described below. The VXLAN > > packet format is defined in Section 5 of [RFC7348]. The Outer IP/UDP > > and VXLAN headers MUST be encoded by the sender as defined in > > [RFC7348]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 5] > > > > Internet-Draft BFD for VXLAN October 2019 > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Outer Ethernet Header ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Outer IPvX Header ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Outer UDP Header ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ VXLAN Header ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Inner Ethernet Header ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Inner IPvX Header ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Inner UDP Header ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ BFD Control Packet ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | FCS | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2: VXLAN Encapsulation of BFD Control Packet > > > > The BFD packet MUST be carried inside the inner Ethernet frame of the > > VXLAN packet. The choice of Destination MAC and Destination IP > > addresses for the inner Ethernet frame MUST ensure that the BFD > > Control packet is not forwarded to a tenant but is processed locally > > at the remote VTEP. The inner Ethernet frame carrying the BFD > > Control packet- has the following format: > > > > Ethernet Header: > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 6] > > > > Internet-Draft BFD for VXLAN October 2019 > > > > > > Destination MAC: This MUST NOT be of one of tenant's MAC > > addresses. The destination MAC address MAY be the address > > associated with the destination VTEP. The MAC address MAY be > > configured, or it MAY be learned via a control plane protocol. > > The details of how the MAC address is obtained are outside the > > scope of this document. > > > > Source MAC: MAC address associated with the originating VTEP > > > > IP header: > > > > Destination IP: IP address MUST NOT be of one of tenant's IP > > addresses. The IP address SHOULD be selected from the range > > 127/8 for IPv4, for IPv6 - from the range > > 0:0:0:0:0:FFFF:7F00:0/104. Alternatively, the destination IP > > address MAY be set to VTEP's IP address. > > > > Source IP: IP address of the originating VTEP. > > > > TTL or Hop Limit: MUST be set to 1 to ensure that the BFD > > packet is not routed within the Layer 3 underlay network. This > > addresses the scenario when the inner IP destination address is > > of VXLAN gateway and there is a router in underlay which > > removes the VXLAN header, then it is possible to route the > > packet as VXLAN gateway address is routable address. > > > > The fields of the UDP header and the BFD Control packet are > > encoded as specified in [RFC5881]. > > > > 5. Reception of BFD Packet from VXLAN Tunnel > > > > Once a packet is received, VTEP MUST validate the packet. If the > > Destination MAC of the inner Ethernet frame matches one of the MAC > > addresses associated with the VTEP the packet MUST be processed > > further. If the Destination MAC of the inner Ethernet frame doesn't > > match any of VTEP's MAC addresses, then the processing of the > > received VXLAN packet MUST follow the procedures described in > > Section 4.1 [RFC7348]. > > > > The UDP destination port and the TTL of the inner IP packet MUST be > > validated to determine if the received packet can be processed by > > BFD. BFD Control packets with unknown MAC address MUST NOT be > > forwarded to VMs. > > > > > > > > > > > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 7] > > > > Internet-Draft BFD for VXLAN October 2019 > > > > > > 5.1. Demultiplexing of the BFD Packet > > > > Demultiplexing of IP BFD packet has been defined in Section 3 of > > [RFC5881]. Since multiple BFD sessions may be running between two > > VTEPs, there needs to be a mechanism for demultiplexing received BFD > > packets to the proper session. For demultiplexing packets with Your > > Discriminator equal to 0, a BFD session MUST be identified using the > > logical link over which the BFD Control packet is received. In the > > case of VXLAN, the VNI number identifies that logical link. If BFD > > packet is received with non-zero Your Discriminator, then BFD session > > MUST be demultiplexed only with Your Discriminator as the key. > > > > 6. Use of the Specific VNI > > > > In most cases, a single BFD session is sufficient for the given VTEP > > to monitor the reachability of a remote VTEP, regardless of the > > number of VNIs. When the single BFD session is used to monitor the > > reachability of the remote VTEP, an implementation SHOULD choose any > > of the VNIs. An implementation MAY support the use of the Management > > VNI as control and management channel between VTEPs. The selection > > of the VNI number of the Management VNI MUST be controlled through > > management plane. An implementation MAY use VNI number 1 as the > > default value for the Management VNI. All VXLAN packets received on > > the Management VNI MUST be processed locally and MUST NOT be > > forwarded to a tenant. > > > > 7. Echo BFD > > > > Support for echo BFD is outside the scope of this document. > > > > 8. IANA Considerations > > > > This specification has no IANA action requested. This section may be > > deleted before the publication. > > > > 9. Security Considerations > > > > The document requires setting the inner IP TTL to 1, which could be > > used as a DDoS attack vector. Thus the implementation MUST have > > throttling in place to control the rate of BFD Control packets sent > > to the control plane. On the other hand, over-aggressive throttling > > of BFD Control packets may become the cause of the inability to form > > and maintain BFD session at scale. Hence, throttling of BFD Control > > packets SHOULD be adjusted to permit BFD to work according to its > > procedures. > > > > If the implementation supports establishing multiple BFD sessions > > between the same pair of VTEPs, there SHOULD be a mechanism to > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 8] > > > > Internet-Draft BFD for VXLAN October 2019 > > > > > > control the maximum number of such sessions that can be active at the > > same time. > > > > Other than inner IP TTL set to 1 and limit the number of BFD sessions > > between the same pair of VTEPs, this specification does not raise any > > additional security issues beyond those of the specifications > > referred to in the list of normative references. > > > > 10. Contributors > > > > > > Reshad Rahman > > rrahman@cisco.com > > Cisco > > > > > > 11. Acknowledgments > > > > Authors would like to thank Jeff Haas of Juniper Networks for his > > reviews and feedback on this material. > > > > Authors would also like to thank Nobo Akiya, Marc Binderberger, > > Shahram Davari, Donald E. Eastlake 3rd, and Anoop Ghanwani for the > > extensive reviews and the most detailed and helpful comments. > > > > 12. References > > > > 12.1. Normative References > > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, > > DOI 10.17487/RFC2119, March 1997, > > <https://www.rfc-editor.org/info/rfc2119>. > > > > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > > (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, > > <https://www.rfc-editor.org/info/rfc5880>. > > > > [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > > (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, > > DOI 10.17487/RFC5881, June 2010, > > <https://www.rfc-editor.org/info/rfc5881>. > > > > > > > > > > > > > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 9] > > > > Internet-Draft BFD for VXLAN October 2019 > > > > > > [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, > > L., Sridhar, T., Bursell, M., and C. Wright, "Virtual > > eXtensible Local Area Network (VXLAN): A Framework for > > Overlaying Virtualized Layer 2 Networks over Layer 3 > > Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, > > <https://www.rfc-editor.org/info/rfc7348>. > > > > [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC > > 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, > > May 2017, <https://www.rfc-editor.org/info/rfc8174>. > > > > 12.2. Informational References > > > > [RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R. > > Krishnan, "A Framework for Multicast in Network > > Virtualization over Layer 3", RFC 8293, > > DOI 10.17487/RFC8293, January 2018, > > <https://www.rfc-editor.org/info/rfc8293>. > > > > [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., > > Uttaro, J., and W. Henderickx, "A Network Virtualization > > Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, > > DOI 10.17487/RFC8365, March 2018, > > <https://www.rfc-editor.org/info/rfc8365>. > > > > Authors' Addresses > > > > Santosh Pallagatti (editor) > > VMware > > > > Email: santosh.pallagatti@gmail.com > > > > > > Sudarsan Paragiri > > Individual Contributor > > > > Email: sudarsan.225@gmail.com > > > > > > Vengada Prasad Govindan > > Cisco > > > > Email: venggovi@cisco.com > > > > > > > > > > > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 10] > > > > Internet-Draft BFD for VXLAN October 2019 > > > > > > Mallik Mudigonda > > Cisco > > > > Email: mmudigon@cisco.com > > > > > > Greg Mirsky > > ZTE Corp. > > > > Email: gregimirsky@gmail.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Pallagatti, et al. Expires May 2, 2020 [Page 11] > > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " > http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > > <!-- saved from url=(0042)https://www6.ietf.org/rfcdiff/rfcdiff.pyht --> > > <html xmlns="http://www.w3.org/1999/xhtml" > class="gr__www6_ietf_org"><head><meta http-equiv="Content-Type" > content="text/html; charset=UTF-8"> > > > > <meta http-equiv="Content-Style-Type" content="text/css"> > > <title>Diff: draft-ietf-bfd-vxlan-07.txt - > draft-ietf-bfd-vxlan-08.txt</title> > > <style type="text/css"> > > body { margin: 0.4ex; margin-right: auto; } > > tr { } > > td { white-space: pre; font-family: monospace; vertical-align: > top; font-size: 0.86em;} > > th { font-size: 0.86em; } > > .small { font-size: 0.6em; font-style: italic; font-family: > Verdana, Helvetica, sans-serif; } > > .left { background-color: #EEE; } > > .right { background-color: #FFF; } > > .diff { background-color: #CCF; } > > .lblock { background-color: #BFB; } > > .rblock { background-color: #FF8; } > > .insert { background-color: #8FF; } > > .delete { background-color: #ACF; } > > .void { background-color: #FFB; } > > .cont { background-color: #EEE; } > > .linebr { background-color: #AAA; } > > .lineno { color: red; background-color: #FFF; font-size: 0.7em; > text-align: right; padding: 0 2px; } > > .elipsis{ background-color: #AAA; } > > .left .cont { background-color: #DDD; } > > .right .cont { background-color: #EEE; } > > .lblock .cont { background-color: #9D9; } > > .rblock .cont { background-color: #DD6; } > > .insert .cont { background-color: #0DD; } > > .delete .cont { background-color: #8AD; } > > .stats, .stats td, .stats th { background-color: #EEE; padding: 2px > 0; } > > span.hide { display: none; color: #aaa;} a:hover span { display: > inline; } tr.change { background-color: gray; } > > tr.change a { text-decoration: none; color: black } > > </style> > > <script> > > var chunk_index = 0; > > var old_chunk = null; > > > > function format_chunk(index) { > > var prefix = "diff"; > > var str = index.toString(); > > for (x=0; x<(4-str.length); ++x) { > > prefix+='0'; > > } > > return prefix + str; > > } > > > > function find_chunk(n){ > > return document.querySelector('tr[id$="' + n + '"]'); > > } > > > > function change_chunk(offset) { > > var index = chunk_index + offset; > > var new_str; > > var new_chunk; > > > > new_str = format_chunk(index); > > new_chunk = find_chunk(new_str); > > if (!new_chunk) { > > return; > > } > > if (old_chunk) { > > old_chunk.style.outline = ""; > > } > > old_chunk = new_chunk; > > old_chunk.style.outline = "1px solid red"; > > window.location.replace("#" + new_str) > > window.scrollBy(0,-100); > > chunk_index = index; > > } > > > > document.onkeydown = function(e) { > > switch (e.keyCode) { > > case 78: > > change_chunk(1); > > break; > > case 80: > > change_chunk(-1); > > break; > > } > > }; > > </script> > > </head> > > <body data-gr-c-s-loaded="true"> > > <table border="0" cellpadding="0" cellspacing="0"> > > <tbody><tr id="part-1" bgcolor="orange"><th></th><th><a href=" > https://www6.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-07.txt" > style="color:#008; text-decoration:none;"><</a> <a href=" > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-07.txt" > style="color:#008">draft-ietf-bfd-vxlan-07.txt</a> </th><th> > </th><th> <a href=" > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08.txt" > style="color:#008">draft-ietf-bfd-vxlan-08.txt</a> <a href=" > https://www6.ietf.org/rfcdiff?url1=draft-ietf-bfd-vxlan-08.txt" > style="color:#008; text-decoration:none;">></a></th><th></th></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">BFD > S. Pallagatti, Ed.</td><td> </td><td > class="right">BFD S. > Pallagatti, Ed.</td><td class="lineno"></td></tr> > > <tr id="diff0001"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock">Internet-Draft > <span > class="delete">Rtbrick</span></td><td> </td><td > class="rblock">Internet-Draft > <span class="insert"> VMware</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">Intended status: > Standards Track S. Paragiri</td><td> </td><td > class="right">Intended status: Standards Track > S. Paragiri</td><td class="lineno"></td></tr> > > <tr id="diff0002"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock">Expires: <span > class="delete">November 18, 2019</span> Individual > Contributor</td><td> </td><td class="rblock">Expires: <span > class="insert">May 2, 2020 </span> Individual > Contributor</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > V. Govindan</td><td> </td><td > class="right"> > V. Govindan</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > M. Mudigonda</td><td> </td><td > class="right"> > M. Mudigonda</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > Cisco</td><td> </td><td > class="right"> > Cisco</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > G. Mirsky</td><td> </td><td > class="right"> > G. Mirsky</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > ZTE Corp.</td><td> </td><td > class="right"> > ZTE Corp.</td><td class="lineno"></td></tr> > > <tr id="diff0003"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> > <span class="delete"> May 17</span>, > 2019</td><td> </td><td class="rblock"> > <span class="insert">October 30</span>, 2019</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > BFD for VXLAN</td><td> </td><td class="right"> > BFD for VXLAN</td><td class="lineno"></td></tr> > > <tr id="diff0004"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> > draft-ietf-bfd-vxlan-0<span class="delete">7</span></td><td> </td><td > class="rblock"> draft-ietf-bfd-vxlan-0<span > class="insert">8</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">Abstract</td><td> > </td><td class="right">Abstract</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> This document > describes the use of the Bidirectional Forwarding</td><td> </td><td > class="right"> This document describes the use of the Bidirectional > Forwarding</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Detection (BFD) > protocol in point-to-point Virtual eXtensible Local</td><td> </td><td > class="right"> Detection (BFD) protocol in point-to-point Virtual > eXtensible Local</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Area Network > (VXLAN) tunnels forming up an overlay network.</td><td> </td><td > class="right"> Area Network (VXLAN) tunnels forming up an overlay > network.</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">Status of This > Memo</td><td> </td><td class="right">Status of This Memo</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> This > Internet-Draft is submitted in full conformance with the</td><td> </td><td > class="right"> This Internet-Draft is submitted in full conformance with > the</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="part-2" class="change"><td></td><th><small>skipping to > change at</small><a href=" > https://www6.ietf.org/rfcdiff/rfcdiff.pyht#part-2"><em> page 1, line > 38<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping > to change at</small><a href=" > https://www6.ietf.org/rfcdiff/rfcdiff.pyht#part-2"><em> page 1, line > 38<span class="hide"> ¶</span></em></a></th><td></td></tr> > > <tr><td class="lineno"></td><td class="left"> Internet-Drafts > are working documents of the Internet Engineering</td><td> </td><td > class="right"> Internet-Drafts are working documents of the Internet > Engineering</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Task Force > (IETF). Note that other groups may also distribute</td><td> </td><td > class="right"> Task Force (IETF). Note that other groups may also > distribute</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> working documents > as Internet-Drafts. The list of current Internet-</td><td> </td><td > class="right"> working documents as Internet-Drafts. The list of current > Internet-</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Drafts is at > https://datatracker.ietf.org/drafts/current/.</td><td> </td><td > class="right"> Drafts is at https://datatracker.ietf.org/drafts/current/.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Internet-Drafts > are draft documents valid for a maximum of six months</td><td> </td><td > class="right"> Internet-Drafts are draft documents valid for a maximum of > six months</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> and may be > updated, replaced, or obsoleted by other documents at any</td><td> </td><td > class="right"> and may be updated, replaced, or obsoleted by other > documents at any</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> time. It is > inappropriate to use Internet-Drafts as reference</td><td> </td><td > class="right"> time. It is inappropriate to use Internet-Drafts as > reference</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> material or to > cite them other than as "work in progress."</td><td> </td><td > class="right"> material or to cite them other than as "work in > progress."</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0005"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> This > Internet-Draft will expire on <span class="delete">November 18, > 2019</span>.</td><td> </td><td class="rblock"> This Internet-Draft will > expire on <span class="insert">May 2, 2020</span>.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">Copyright > Notice</td><td> </td><td class="right">Copyright Notice</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Copyright (c) 2019 > IETF Trust and the persons identified as the</td><td> </td><td > class="right"> Copyright (c) 2019 IETF Trust and the persons identified > as the</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> document authors. > All rights reserved.</td><td> </td><td class="right"> document authors. > All rights reserved.</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> This document is > subject to BCP 78 and the IETF Trust's Legal</td><td> </td><td > class="right"> This document is subject to BCP 78 and the IETF Trust's > Legal</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Provisions > Relating to IETF Documents</td><td> </td><td class="right"> Provisions > Relating to IETF Documents</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> ( > https://trustee.ietf.org/license-info) in effect on the date of</td><td> > </td><td class="right"> (https://trustee.ietf.org/license-info) in > effect on the date of</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> publication of > this document. Please review these documents</td><td> </td><td > class="right"> publication of this document. Please review these > documents</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="part-3" class="change"><td></td><th><small>skipping to > change at</small><a href=" > https://www6.ietf.org/rfcdiff/rfcdiff.pyht#part-3"><em> page 2, line > 17<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping > to change at</small><a href=" > https://www6.ietf.org/rfcdiff/rfcdiff.pyht#part-3"><em> page 2, line > 17<span class="hide"> ¶</span></em></a></th><td></td></tr> > > <tr><td class="lineno"></td><td class="left"> described in the > Simplified BSD License.</td><td> </td><td class="right"> described in the > Simplified BSD License.</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">Table of > Contents</td><td> </td><td class="right">Table of Contents</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 1. Introduction > . . . . . . . . . . . . . . . . . . . . . . . . 2</td><td> </td><td > class="right"> 1. Introduction . . . . . . . . . . . . . . . . . . . . > . . . . 2</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 2. Conventions > used in this document . . . . . . . . . . . . . . 3</td><td> </td><td > class="right"> 2. Conventions used in this document . . . . . . . . . . > . . . . 3</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 2.1. > Terminology . . . . . . . . . . . . . . . . . . . . . . . 3</td><td> > </td><td class="right"> 2.1. Terminology . . . . . . . . . . . . . . . > . . . . . . . . 3</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 2.2. > Requirements Language . . . . . . . . . . . . . . . . . . 3</td><td> > </td><td class="right"> 2.2. Requirements Language . . . . . . . . . . > . . . . . . . . 3</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 3. Deployment . > . . . . . . . . . . . . . . . . . . . . . . . . 4</td><td> </td><td > class="right"> 3. Deployment . . . . . . . . . . . . . . . . . . . . . > . . . . 4</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 4. BFD Packet > Transmission over VXLAN Tunnel . . . . . . . . . . 5</td><td> </td><td > class="right"> 4. BFD Packet Transmission over VXLAN Tunnel . . . . . . > . . . . 5</td><td class="lineno"></td></tr> > > <tr id="diff0006"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> 4.1. BFD Packet Encapsulation in VXLAN . . . . . . . . > . . . . 6</span></td><td> </td><td class="rblock"></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 5. Reception of > BFD Packet from VXLAN Tunnel . . . . . . . . . . 7</td><td> </td><td > class="right"> 5. Reception of BFD Packet from VXLAN Tunnel . . . . . . > . . . . 7</td><td class="lineno"></td></tr> > > <tr id="diff0007"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> 5.1. > Demultiplexing of the BFD Packet . . . . . . . . . . . . <span > class="delete">7</span></td><td> </td><td class="rblock"> 5.1. > Demultiplexing of the BFD Packet . . . . . . . . . . . . <span > class="insert">8</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 6. Use of the > Specific VNI . . . . . . . . . . . . . . . . . . . 8</td><td> </td><td > class="right"> 6. Use of the Specific VNI . . . . . . . . . . . . . . . > . . . . 8</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 7. Echo BFD . . > . . . . . . . . . . . . . . . . . . . . . . . . 8</td><td> </td><td > class="right"> 7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . > . . . . 8</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 8. IANA > Considerations . . . . . . . . . . . . . . . . . . . . . 8</td><td> > </td><td class="right"> 8. IANA Considerations . . . . . . . . . . . . . > . . . . . . . . 8</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 9. Security > Considerations . . . . . . . . . . . . . . . . . . . 8</td><td> </td><td > class="right"> 9. Security Considerations . . . . . . . . . . . . . . . > . . . . 8</td><td class="lineno"></td></tr> > > <tr id="diff0008"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> 10. > Contributors . . . . . . . . . . . . . . . . . . . . . . . . <span > class="delete">8</span></td><td> </td><td class="rblock"> 10. > Contributors . . . . . . . . . . . . . . . . . . . . . . . . <span > class="insert">9</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 11. > Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9</td><td> > </td><td class="right"> 11. Acknowledgments . . . . . . . . . . . . . . . > . . . . . . . . 9</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 12. References . > . . . . . . . . . . . . . . . . . . . . . . . . 9</td><td> </td><td > class="right"> 12. References . . . . . . . . . . . . . . . . . . . . . > . . . . 9</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 12.1. Normative > References . . . . . . . . . . . . . . . . . . 9</td><td> </td><td > class="right"> 12.1. Normative References . . . . . . . . . . . . . . > . . . . 9</td><td class="lineno"></td></tr> > > <tr id="diff0009"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> 12.2. > Informational References . . . . . . . . . . . . . . . . <span > class="delete"> 9</span></td><td> </td><td class="rblock"> 12.2. > Informational References . . . . . . . . . . . . . . . . <span > class="insert">10</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Authors' > Addresses . . . . . . . . . . . . . . . . . . . . . . . 10</td><td> > </td><td class="right"> Authors' Addresses . . . . . . . . . . . . . . . > . . . . . . . . 10</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">1. > Introduction</td><td> </td><td class="right">1. Introduction</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> "Virtual > eXtensible Local Area Network" (VXLAN) [RFC7348] provides an</td><td> > </td><td class="right"> "Virtual eXtensible Local Area Network" (VXLAN) > [RFC7348] provides an</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> encapsulation > scheme that allows building an overlay network by</td><td> </td><td > class="right"> encapsulation scheme that allows building an overlay > network by</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> decoupling the > address space of the attached virtual hosts from that</td><td> </td><td > class="right"> decoupling the address space of the attached virtual hosts > from that</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> of the > network.</td><td> </td><td class="right"> of the network.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> One use of VXLAN > is in data centers interconnecting virtual machines</td><td> </td><td > class="right"> One use of VXLAN is in data centers interconnecting > virtual machines</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="part-4" class="change"><td></td><th><small>skipping to > change at</small><a href=" > https://www6.ietf.org/rfcdiff/rfcdiff.pyht#part-4"><em> page 3, line > 5<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to > change at</small><a href=" > https://www6.ietf.org/rfcdiff/rfcdiff.pyht#part-4"><em> page 3, line > 4<span class="hide"> ¶</span></em></a></th><td></td></tr> > > <tr><td class="lineno"></td><td class="left"> Ethernet VPN > [RFC8365].</td><td> </td><td class="right"> Ethernet VPN > [RFC8365].</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> This document is > written assuming the use of VXLAN for virtualized</td><td> </td><td > class="right"> This document is written assuming the use of VXLAN for > virtualized</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> hosts and refers > to VMs and VXLAN Tunnel End Points (VTEPs) in</td><td> </td><td > class="right"> hosts and refers to VMs and VXLAN Tunnel End Points > (VTEPs) in</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> hypervisors. > However, the concepts are equally applicable to non-</td><td> </td><td > class="right"> hypervisors. However, the concepts are equally applicable > to non-</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> virtualized hosts > attached to VTEPs in switches.</td><td> </td><td class="right"> > virtualized hosts attached to VTEPs in switches.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> In the absence of > a router in the overlay, a VM can communicate with</td><td> </td><td > class="right"> In the absence of a router in the overlay, a VM can > communicate with</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> another VM only if > they are on the same VXLAN segment. VMs are</td><td> </td><td > class="right"> another VM only if they are on the same VXLAN segment. > VMs are</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> unaware of VXLAN > tunnels as a VXLAN tunnel is terminated on a VTEP.</td><td> </td><td > class="right"> unaware of VXLAN tunnels as a VXLAN tunnel is terminated > on a VTEP.</td><td class="lineno"></td></tr> > > <tr id="diff0010"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> > </span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> VTEPs are > responsible for encapsulating and decapsulating frames</td><td> </td><td > class="right"> VTEPs are responsible for encapsulating and decapsulating > frames</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> exchanged among > VMs.</td><td> </td><td class="right"> exchanged among VMs.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Ability to monitor > path continuity, i.e., perform proactive</td><td> </td><td class="right"> > Ability to monitor path continuity, i.e., perform proactive</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> continuity check > (CC) for point-to-point (p2p) VXLAN tunnels, is</td><td> </td><td > class="right"> continuity check (CC) for point-to-point (p2p) VXLAN > tunnels, is</td><td class="lineno"></td></tr> > > <tr id="diff0011"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> important. The > asynchronous mode of BFD, as defined in [RFC5880],</td><td> </td><td > class="rblock"> important. The asynchronous mode of BFD, as defined in > [RFC5880], <span class="insert">is</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> <span > class="delete">can be</span> used to monitor a p2p VXLAN tunnel.</td><td> > </td><td class="rblock"> used to monitor a p2p VXLAN tunnel.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> In the case where > a Multicast Service Node (MSN) (as described in</td><td> </td><td > class="right"> In the case where a Multicast Service Node (MSN) (as > described in</td><td class="lineno"></td></tr> > > <tr id="diff0012"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> Section 3.3 of > [RFC8293]) resides behind <span class="delete">an NVE,</span> the > mechanisms</td><td> </td><td class="rblock"> Section 3.3 of [RFC8293]) > resides behind <span class="insert">a Network Virtualization</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> described in > this document apply and can, therefore, be used to test</td><td> </td><td > class="rblock"><span class="insert"> Endpoint (NVE),</span> the > mechanisms described in this document apply and</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> the connectivity > from the source NVE to the MSN.</td><td> </td><td class="rblock"> can, > therefore, be used to test the connectivity from the source NVE</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> to the MSN.</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> This document > describes the use of Bidirectional Forwarding Detection</td><td> </td><td > class="right"> This document describes the use of Bidirectional > Forwarding Detection</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> (BFD) protocol to > enable monitoring continuity of the path between</td><td> </td><td > class="right"> (BFD) protocol to enable monitoring continuity of the path > between</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> VXLAN VTEPs, > performing as Network Virtualization Endpoints, and/or</td><td> </td><td > class="right"> VXLAN VTEPs, performing as Network Virtualization > Endpoints, and/or</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> availability of a > replicator multicast service node.</td><td> </td><td class="right"> > availability of a replicator multicast service node.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">2. Conventions used > in this document</td><td> </td><td class="right">2. Conventions used in > this document</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">2.1. > Terminology</td><td> </td><td class="right">2.1. Terminology</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> BFD Bidirectional > Forwarding Detection</td><td> </td><td class="right"> BFD Bidirectional > Forwarding Detection</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> CC Continuity > Check</td><td> </td><td class="right"> CC Continuity Check</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> p2p > Point-to-point</td><td> </td><td class="right"> p2p > Point-to-point</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> MSN Multicast > Service Node</td><td> </td><td class="right"> MSN Multicast Service > Node</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0013"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> <span class="insert">NVE Network Virtualization > Endpoint</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> > </td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> VFI Virtual > Forwarding Instance</td><td> </td><td class="right"> VFI Virtual > Forwarding Instance</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> VM Virtual > Machine</td><td> </td><td class="right"> VM Virtual Machine</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0014"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> <span class="insert">VNI VXLAN Network Identifier (or > VXLAN Segment ID)</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> > </td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> VTEP VXLAN Tunnel > End Point</td><td> </td><td class="right"> VTEP VXLAN Tunnel End > Point</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> VXLAN Virtual > eXtensible Local Area Network</td><td> </td><td class="right"> VXLAN > Virtual eXtensible Local Area Network</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">2.2. Requirements > Language</td><td> </td><td class="right">2.2. Requirements > Language</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> The key words > "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",</td><td> </td><td > class="right"> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT",</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> "SHOULD", "SHOULD > NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and</td><td> </td><td > class="right"> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > "MAY", and</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> "OPTIONAL" in this > document are to be interpreted as described in BCP</td><td> </td><td > class="right"> "OPTIONAL" in this document are to be interpreted as > described in BCP</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 14 [RFC2119] > [RFC8174] when, and only when, they appear in all</td><td> </td><td > class="right"> 14 [RFC2119] [RFC8174] when, and only when, they appear in > all</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> capitals, as shown > here.</td><td> </td><td class="right"> capitals, as shown here.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">3. > Deployment</td><td> </td><td class="right">3. Deployment</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Figure 1 > illustrates the scenario with two servers, each of them</td><td> </td><td > class="right"> Figure 1 illustrates the scenario with two servers, each > of them</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> hosting two VMs. > The servers host VTEPs that terminate two VXLAN</td><td> </td><td > class="right"> hosting two VMs. The servers host VTEPs that terminate > two VXLAN</td><td class="lineno"></td></tr> > > <tr id="diff0015"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> tunnels with > <span class="delete">VNI</span> number 100 and 200 respectively. Separate > BFD</td><td> </td><td class="rblock"> tunnels with <span > class="insert">VXLAN Network Identifier (VNI)</span> number 100 and > 200</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> sessions can be > established between the VTEPs (IP1 and IP2) for</td><td> </td><td > class="rblock"> respectively. Separate BFD sessions can be established > between the</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> monitoring each > of the VXLAN tunnels (VNI 100 and 200). An</td><td> </td><td > class="rblock"> VTEPs (IP1 and IP2) for monitoring each of the VXLAN > tunnels (VNI 100</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> implementation > that supports this specification MUST be able to</td><td> </td><td > class="rblock"> and 200). An implementation that supports this > specification MUST be</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> control the > number of BFD sessions that can be created between the</td><td> </td><td > class="rblock"> able to control the number of BFD sessions that can be > created</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> same pair of > VTEPs. BFD packets intended for a <span class="delete">Hypervisor</span> > VTEP MUST</td><td> </td><td class="rblock"> between the same pair of > VTEPs. BFD packets intended for a VTEP MUST</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> NOT be forwarded > to a VM as a VM may drop BFD packets leading to a</td><td> </td><td > class="right"> NOT be forwarded to a VM as a VM may drop BFD packets > leading to a</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> false negative. > This method is applicable whether the VTEP is a</td><td> </td><td > class="right"> false negative. This method is applicable whether the > VTEP is a</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> virtual or > physical device.</td><td> </td><td class="right"> virtual or physical > device.</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +------------+-------------+</td><td> </td><td class="right"> > +------------+-------------+</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | Server > 1 |</td><td> </td><td class="right"> | Server 1 > |</td><td class="lineno"></td></tr> > > <tr id="diff0016"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> | |</span></td><td> </td><td > class="rblock"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | +----+----+ > +----+----+ |</td><td> </td><td class="right"> | +----+----+ > +----+----+ |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | |VM1-1 | > |VM1-2 | |</td><td> </td><td class="right"> | |VM1-1 | |VM1-2 > | |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | |VNI 100 | > |VNI 200 | |</td><td> </td><td class="right"> | |VNI 100 | |VNI > 200 | |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | | | > | | |</td><td> </td><td class="right"> | | | | > | |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | +---------+ > +---------+ |</td><td> </td><td class="right"> | +---------+ > +---------+ |</td><td class="lineno"></td></tr> > > <tr id="diff0017"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> | <span > class="delete">Hypervisor VTEP (IP1)</span> |</td><td> </td><td > class="rblock"> | <span class="insert"> VTEP (IP1) </span> > |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +--------------------------+</td><td> </td><td class="right"> > +--------------------------+</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > |</td><td> </td><td class="right"> > |</td><td class="lineno"></td></tr> > > <tr id="diff0018"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> > <span class="delete">|</span></td><td> </td><td > class="rblock"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> |</span></td><td> </td><td > class="rblock"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > | +-------------+</td><td> </td><td class="right"> > | +-------------+</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > | | Layer 3 |</td><td> </td><td class="right"> > | | Layer 3 |</td><td class="lineno"></td></tr> > > <tr id="diff0019"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> > <span class="delete">|---|</span> Network <span > class="delete">|</span></td><td> </td><td class="rblock"> > <span class="insert">+---|</span> Network |</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> |</span> > |</td><td> </td><td class="rblock"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +-------------+</td><td> </td><td class="right"> > +-------------+</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > |</td><td> </td><td class="right"> > |</td><td class="lineno"></td></tr> > > <tr id="diff0020"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> |</span></td><td> > </td><td class="rblock"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +-----------+</td><td> </td><td class="right"> > +-----------+</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > |</td><td> </td><td class="right"> > |</td><td class="lineno"></td></tr> > > <tr id="diff0021"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> > |</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +------------+-------------+</td><td> </td><td > class="right"> > +------------+-------------+</td><td class="lineno"></td></tr> > > <tr id="diff0022"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> > | <span class="delete">Hypervisor VTEP (IP2)</span> > |</td><td> </td><td class="rblock"> > | <span class="insert"> VTEP (IP2) </span> |</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > | +----+----+ +----+----+ |</td><td> </td><td > class="right"> | +----+----+ > +----+----+ |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > | |VM2-1 | |VM2-2 | |</td><td> </td><td > class="right"> | |VM2-1 | > |VM2-2 | |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > | |VNI 100 | |VNI 200 | |</td><td> </td><td > class="right"> | |VNI 100 | |VNI > 200 | |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > | | | | | |</td><td> </td><td > class="right"> | | | | > | |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > | +---------+ +---------+ |</td><td> </td><td > class="right"> | +---------+ > +---------+ |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > | Server 2 |</td><td> </td><td > class="right"> | Server 2 > |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +--------------------------+</td><td> </td><td > class="right"> > +--------------------------+</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > Figure 1: Reference VXLAN Domain</td><td> </td><td class="right"> > Figure 1: Reference VXLAN Domain</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0023"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> <span class="insert">At the same time, a service layer > BFD session may be used between the</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> tenants of VTEPs IP1 and IP2 to > provide end-to-end fault management.</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> In such case, for VTEPs BFD Control > packets of that session are</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> indistinguishable from data > packets. If end-to-end defect detection</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> is realized as the set of > concatenated OAM domains, e.g., VM1-1 - IP1</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> -- IP2 - VM2-1, then the BFD session > over VXLAN between VTEPs SHOULD</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> follow the procedures described in > Section 6.8.17 [RFC5880].</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"></span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> As per Section 4, the inner > destination IP address SHOULD be set to</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> one of the loopback addresses (127/8 > range for IPv4 and</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> 0:0:0:0:0:FFFF:7F00:0/104 range for > IPv6). There could be a firewall</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> configured on VTEP to block loopback > addresses if set as the</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> destination IP in the inner IP > header. It is RECOMMENDED to allow</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> addresses from the loopback range > through a firewall only if it is</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> used as the destination IP address > in the inner IP header, and the</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> destination UDP port is set to 3784 > [RFC5881].</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> > </td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">4. BFD Packet > Transmission over VXLAN Tunnel</td><td> </td><td class="right">4. BFD > Packet Transmission over VXLAN Tunnel</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> BFD packet MUST be > encapsulated and sent to a remote VTEP as</td><td> </td><td class="right"> > BFD packet MUST be encapsulated and sent to a remote VTEP as</td><td > class="lineno"></td></tr> > > <tr id="diff0024"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> explained in > <span class="delete">Section 4.1.</span> Implementations SHOULD ensure > that the BFD</td><td> </td><td class="rblock"> explained in <span > class="insert">this section.</span> Implementations SHOULD ensure that > the</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> packets follow > the same lookup path as VXLAN data packets within the</td><td> </td><td > class="rblock"> BFD packets follow the same lookup path as VXLAN data > packets within</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> sender > system.</td><td> </td><td class="rblock"> the sender system.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> > </td><td> </td><td > class="rblock"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete">4.1. BFD Packet Encapsulation in VXLAN</span></td><td> > </td><td class="rblock"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> BFD packets are > encapsulated in VXLAN as described below. The VXLAN</td><td> </td><td > class="right"> BFD packets are encapsulated in VXLAN as described below. > The VXLAN</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> packet format is > defined in Section 5 of [RFC7348]. The Outer IP/UDP</td><td> </td><td > class="right"> packet format is defined in Section 5 of [RFC7348]. The > Outer IP/UDP</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> and VXLAN headers > MUST be encoded by the sender as defined in</td><td> </td><td > class="right"> and VXLAN headers MUST be encoded by the sender as defined > in</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > [RFC7348].</td><td> </td><td class="right"> [RFC7348].</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 0 > 1 2 3</td><td> </td><td > class="right"> 0 1 2 > 3</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> 0 1 2 3 4 5 6 7 > 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</td><td> </td><td > class="right"> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> > </td><td class="right"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | > |</td><td> </td><td > class="right"> | > |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="part-5" class="change"><td></td><th><small>skipping to > change at</small><a href=" > https://www6.ietf.org/rfcdiff/rfcdiff.pyht#part-5"><em> page 6, line > 44<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping > to change at</small><a href=" > https://www6.ietf.org/rfcdiff/rfcdiff.pyht#part-5"><em> page 6, line > 37<span class="hide"> ¶</span></em></a></th><td></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> > </td><td class="right"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | > |</td><td> </td><td > class="right"> | > |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> ~ > Inner IPvX Header ~</td><td> </td><td > class="right"> ~ Inner IPvX Header > ~</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | > |</td><td> </td><td > class="right"> | > |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> > </td><td class="right"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | > |</td><td> </td><td > class="right"> | > |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> ~ > Inner UDP Header ~</td><td> </td><td > class="right"> ~ Inner UDP Header > ~</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | > |</td><td> </td><td > class="right"> | > |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> > </td><td class="right"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | > |</td><td> </td><td > class="right"> | > |</td><td class="lineno"></td></tr> > > <tr id="diff0025"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> ~ > BFD Control <span class="delete">Message</span> > ~</td><td> </td><td class="rblock"> ~ BFD Control > <span class="insert">Packet</span> ~</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | > |</td><td> </td><td > class="right"> | > |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> > </td><td class="right"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> | > FCS |</td><td> </td><td > class="right"> | FCS > |</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> > </td><td class="right"> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0026"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> <span > class="delete">Figure 2: VXLAN Encapsulation of BFD Control > Message</span></td><td> </td><td class="rblock"> <span > class="insert"> Figure 2: VXLAN Encapsulation of BFD Control > Packet</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0027"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> The BFD packet > MUST be carried inside the inner <span class="delete">MAC</span> frame of > the</td><td> </td><td class="rblock"> The BFD packet MUST be carried > inside the inner <span class="insert">Ethernet</span> frame of the</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> VXLAN packet. > The <span class="delete">inner</span> MAC frame carrying the BFD <span > class="delete">payload</span> has the</td><td> </td><td class="rblock"> > VXLAN packet. The <span class="insert">choice of Destination</span> MAC > <span class="insert">and Destination IP</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> following > format:</td><td> </td><td class="rblock"><span class="insert"> addresses > for the inner Ethernet frame MUST ensure that the BFD</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> Control packet is not forwarded to a > tenant but is processed locally</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> at the remote VTEP. The inner > Ethernet</span> frame carrying the BFD</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> <span class="insert">Control packet-</span> has the > following format:</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Ethernet > Header:</td><td> </td><td class="right"> Ethernet Header:</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0028"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> > Destination MAC: This MUST be <span class="delete">the dedicated</span> > MAC <span class="delete">TBA (Section 8)</span></td><td> </td><td > class="rblock"> Destination MAC: This MUST <span > class="insert">NOT</span> be <span class="insert">of one of tenant's</span> > MAC</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> or the</span> MAC address <span > class="delete">of</span> the destination VTEP. The details of how</td><td> > </td><td class="rblock"> <span class="insert">addresses. The > destination</span> MAC address <span class="insert">MAY be the > address</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> the MAC > address <span class="delete">of the destination VTEP</span> is obtained are > outside</td><td> </td><td class="rblock"><span class="insert"> > associated with</span> the destination VTEP. The <span class="insert">MAC > address MAY be</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> the scope > of this document.</td><td> </td><td class="rblock"><span class="insert"> > configured, or it MAY be learned via a control plane > protocol.</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> The</span> details of how the > MAC address is obtained are outside the</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> scope of this document.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0029"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> Source > MAC: MAC address <span class="delete">of</span> the originating > VTEP</td><td> </td><td class="rblock"> Source MAC: MAC address > <span class="insert">associated with</span> the originating VTEP</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> IP > header:</td><td> </td><td class="right"> IP header:</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0030"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> <span > class="delete">Source</span> IP: IP address of the <span > class="delete">originating VTEP.</span></td><td> </td><td class="rblock"> > <span class="insert">Destination</span> IP: IP address <span > class="insert">MUST NOT be</span> of <span class="insert">one of tenant's > IP</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> addresses. The IP address > SHOULD be selected from the range</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> 127/8 for IPv4, for IPv6 - > from</span> the <span class="insert">range</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> 0:0:0:0:0:FFFF:7F00:0/104. > Alternatively, the destination IP</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> address MAY be set to VTEP's > IP address.</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0031"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> <span > class="delete">Destination IP: IP address of the term</span>inating > VTEP.</td><td> </td><td class="rblock"> <span class="insert">Source > IP: IP address of the orig</span>inating VTEP.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0032"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> <span > class="delete">TTL:</span> MUST be set to 1 to ensure that the BFD packet > is not</td><td> </td><td class="rblock"> <span class="insert">TTL > or Hop Limit:</span> MUST be set to 1 to ensure that the BFD</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> routed > within the <span class="delete">L3</span> underlay network.</td><td> > </td><td class="rblock"> packet is not routed within the <span > class="insert">Layer 3</span> underlay network. <span > class="insert">This</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> addresses the scenario when > the inner IP destination address is</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> of VXLAN gateway and there is > a router in underlay which</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> removes the VXLAN header, then > it is possible to route the</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> packet as VXLAN gateway > address is routable address.</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0033"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> The fields of > the UDP header and the BFD <span class="delete">c</span>ontrol packet > are</td><td> </td><td class="rblock"> The fields of the UDP header and > the BFD <span class="insert">C</span>ontrol packet are</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> encoded as > specified in [RFC5881].</td><td> </td><td class="right"> encoded as > specified in [RFC5881].</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">5. Reception of BFD > Packet from VXLAN Tunnel</td><td> </td><td class="right">5. Reception of > BFD Packet from VXLAN Tunnel</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Once a packet is > received, VTEP MUST validate the packet. If the</td><td> </td><td > class="right"> Once a packet is received, VTEP MUST validate the packet. > If the</td><td class="lineno"></td></tr> > > <tr id="diff0034"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> Destination MAC > of the inner <span class="delete">MAC</span> frame matches <span > class="delete">the dedicated MAC or</span></td><td> </td><td > class="rblock"> Destination MAC of the inner <span > class="insert">Ethernet</span> frame matches <span class="insert">one > of</span> the MAC</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> the MAC <span > class="delete">address of</span> the VTEP the packet MUST be processed > further.</td><td> </td><td class="rblock"> <span class="insert">addresses > associated with</span> the VTEP the packet MUST be processed</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> further. <span class="insert">If the Destination MAC of > the inner Ethernet frame doesn't</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> match any of VTEP's MAC addresses, > then the processing of the</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> received VXLAN packet MUST follow > the procedures described in</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> Section 4.1 > [RFC7348].</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> The UDP > destination port and the TTL of the inner IP packet MUST be</td><td> > </td><td class="right"> The UDP destination port and the TTL of the inner > IP packet MUST be</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> validated to > determine if the received packet can be processed by</td><td> </td><td > class="right"> validated to determine if the received packet can be > processed by</td><td class="lineno"></td></tr> > > <tr id="diff0035"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> BFD. BFD <span > class="delete">packet</span> with <span class="delete">inner MAC set to > VTEP or dedicated</span> MAC address</td><td> </td><td class="rblock"> > BFD. BFD <span class="insert">Control packets</span> with <span > class="insert">unknown</span> MAC address MUST NOT be</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> MUST NOT be > forwarded to VMs.</td><td> </td><td class="rblock"> forwarded to > VMs.</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">5.1. Demultiplexing > of the BFD Packet</td><td> </td><td class="right">5.1. Demultiplexing of > the BFD Packet</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Demultiplexing of > IP BFD packet has been defined in Section 3 of</td><td> </td><td > class="right"> Demultiplexing of IP BFD packet has been defined in > Section 3 of</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> [RFC5881]. Since > multiple BFD sessions may be running between two</td><td> </td><td > class="right"> [RFC5881]. Since multiple BFD sessions may be running > between two</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> VTEPs, there needs > to be a mechanism for demultiplexing received BFD</td><td> </td><td > class="right"> VTEPs, there needs to be a mechanism for demultiplexing > received BFD</td><td class="lineno"></td></tr> > > <tr id="diff0036"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> packets to the > proper session. <span class="delete">The procedure for</span> > demultiplexing</td><td> </td><td class="rblock"> packets to the proper > session. <span class="insert">For</span> demultiplexing packets with > Your</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> packets with > Your Discriminator equal to <span class="delete">0 is different > from</span></td><td> </td><td class="rblock"> Discriminator equal to > <span class="insert">0, a</span> BFD session MUST be identified using > the</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> [RFC5880]. For such packets, the</span> BFD session MUST > be identified</td><td> </td><td class="rblock"> <span > class="insert">logical link over which</span> the <span class="insert">BFD > Control packet is received. In</span> the</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> using the <span > class="delete">inner headers, i.e., the source IP,</span> the <span > class="delete">destination IP, and</span></td><td> </td><td > class="rblock"> <span class="insert">case</span> of <span > class="insert">VXLAN,</span> the VNI <span class="insert">number identifies > that logical link.</span> If BFD</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> the source UDP port number present in the IP header > carried by</span> the</td><td> </td><td class="rblock"> packet is > received with non-zero Your Discriminator, then BFD session</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> <span > class="delete">payload</span> of the <span class="delete">VXLAN > encapsulated packet. The</span> VNI <span class="delete">of the > packet</span></td><td> </td><td class="rblock"> MUST be demultiplexed > only with Your Discriminator as the key.</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> SHOULD be used to derive interface-related information > for</span></td><td> </td><td class="rblock"></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> demultiplexing the packet.</span> If BFD packet is > received with non-zero</td><td> </td><td class="rblock"></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> Your > Discriminator, then BFD session MUST be demultiplexed only with</td><td> > </td><td class="rblock"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> Your > Discriminator as the key.</td><td> </td><td class="rblock"></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">6. Use of the > Specific VNI</td><td> </td><td class="right">6. Use of the Specific > VNI</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> In most cases, a > single BFD session is sufficient for the given VTEP</td><td> </td><td > class="right"> In most cases, a single BFD session is sufficient for the > given VTEP</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> to monitor the > reachability of a remote VTEP, regardless of the</td><td> </td><td > class="right"> to monitor the reachability of a remote VTEP, regardless > of the</td><td class="lineno"></td></tr> > > <tr id="diff0037"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> number of <span > class="delete">VNIs in common.</span> When the single BFD session is used > to</td><td> </td><td class="rblock"> number of <span > class="insert">VNIs.</span> When the single BFD session is used to monitor > the</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> monitor the > reachability of the remote VTEP, an implementation SHOULD</td><td> </td><td > class="rblock"> reachability of the remote VTEP, an implementation SHOULD > choose any</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> choose any of > the <span class="delete">VNIs but</span> MAY <span > class="delete">choose</span> VNI <span class="delete">= 0.</span></td><td> > </td><td class="rblock"> of the <span class="insert">VNIs. An > implementation</span> MAY <span class="insert">support the use of the > Management</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> VNI <span class="insert">as control and management > channel between VTEPs. The selection</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> of the VNI number of the Management > VNI MUST be controlled through</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> management plane. An implementation > MAY use VNI number 1 as the</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> default value for the Management > VNI. All VXLAN packets received on</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> the Management VNI MUST be processed > locally and MUST NOT be</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> forwarded to a > tenant.</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">7. Echo BFD</td><td> > </td><td class="right">7. Echo BFD</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Support for echo > BFD is outside the scope of this document.</td><td> </td><td > class="right"> Support for echo BFD is outside the scope of this > document.</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">8. IANA > Considerations</td><td> </td><td class="right">8. IANA > Considerations</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0038"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> <span > class="delete">IANA</span> has <span class="delete">assigned TBA as a > dedicated MAC address from the</span> IANA <span > class="delete">48-bit</span></td><td> </td><td class="rblock"> <span > class="insert">This specification</span> has <span class="insert">no</span> > IANA <span class="insert">action requested. This section may</span> > be</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> unicast MAC address registry to</span> be <span > class="delete">used as the Destination MAC</span></td><td> </td><td > class="rblock"> <span class="insert">deleted before</span> the <span > class="insert">publication.</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> address of</span> the <span class="delete">inner Ethernet > of VXLAN when carrying BFD control</span></td><td> </td><td > class="rblock"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"><span > class="delete"> packets.</span></td><td> </td><td class="rblock"></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">9. Security > Considerations</td><td> </td><td class="right">9. Security > Considerations</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> The document > requires setting the inner IP TTL to 1, which could be</td><td> </td><td > class="right"> The document requires setting the inner IP TTL to 1, which > could be</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> used as a DDoS > attack vector. Thus the implementation MUST have</td><td> </td><td > class="right"> used as a DDoS attack vector. Thus the implementation > MUST have</td><td class="lineno"></td></tr> > > <tr id="diff0039"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> throttling in > place to control the rate of BFD <span class="delete">control</span> > packets sent</td><td> </td><td class="rblock"> throttling in place to > control the rate of BFD <span class="insert">Control</span> packets > sent</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> to the control > plane. <span class="delete">Throttling MAY be relaxed for</span> BFD > packets</td><td> </td><td class="rblock"> to the control plane. <span > class="insert">On the other hand, over-aggressive throttling</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> <span > class="delete">based on port number.</span></td><td> </td><td > class="rblock"><span class="insert"> of BFD Control packets may become > the cause of the inability to form</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> and maintain BFD session at scale. > Hence, throttling of</span> BFD <span class="insert">Control</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> packets <span class="insert">SHOULD be adjusted to permit > BFD to work according to its</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> procedures.</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="diff0040"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> <span > class="delete">The</span> implementation SHOULD <span > class="delete">have</span> a <span class="delete">reasonable upper bound > on</span> the number</td><td> </td><td class="rblock"> <span > class="insert">If the</span> implementation <span class="insert">supports > establishing multiple BFD sessions</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> of <span > class="delete">BFD</span> sessions that can be <span class="delete">created > between</span> the same <span class="delete">pair of VTEPs.</span></td><td> > </td><td class="rblock"><span class="insert"> between the same pair of > VTEPs, there</span> SHOULD <span class="insert">be</span> a <span > class="insert">mechanism to</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"><span class="insert"> control</span> the <span > class="insert">maximum</span> number of <span class="insert">such</span> > sessions that can be <span class="insert">active at</span> the</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td > class="rblock"> same <span class="insert">time.</span></td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Other than inner > IP TTL set to 1 and limit the number of BFD sessions</td><td> </td><td > class="right"> Other than inner IP TTL set to 1 and limit the number of > BFD sessions</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> between the same > pair of VTEPs, this specification does not raise any</td><td> </td><td > class="right"> between the same pair of VTEPs, this specification does > not raise any</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> additional > security issues beyond those of the specifications</td><td> </td><td > class="right"> additional security issues beyond those of the > specifications</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> referred to in the > list of normative references.</td><td> </td><td class="right"> referred > to in the list of normative references.</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">10. > Contributors</td><td> </td><td class="right">10. Contributors</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Reshad > Rahman</td><td> </td><td class="right"> Reshad Rahman</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> rrahman@cisco.com</td><td> > </td><td class="right"> rrahman@cisco.com</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr id="part-6" class="change"><td></td><th><small>skipping to > change at</small><a href=" > https://www6.ietf.org/rfcdiff/rfcdiff.pyht#part-6"><em> page 10, line > 14<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping > to change at</small><a href=" > https://www6.ietf.org/rfcdiff/rfcdiff.pyht#part-6"><em> page 10, line > 33<span class="hide"> ¶</span></em></a></th><td></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> [RFC8365] > Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,</td><td> </td><td > class="right"> [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., > Shekhar, R.,</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Uttaro, > J., and W. Henderickx, "A Network Virtualization</td><td> </td><td > class="right"> Uttaro, J., and W. Henderickx, "A Network > Virtualization</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Overlay > Solution Using Ethernet VPN (EVPN)", RFC 8365,</td><td> </td><td > class="right"> Overlay Solution Using Ethernet VPN (EVPN)", > RFC 8365,</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> DOI > 10.17487/RFC8365, March 2018,</td><td> </td><td class="right"> > DOI 10.17487/RFC8365, March 2018,</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> < > https://www.rfc-editor.org/info/rfc8365>.</td><td> </td><td > class="right"> < > https://www.rfc-editor.org/info/rfc8365>.</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left">Authors' > Addresses</td><td> </td><td class="right">Authors' Addresses</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Santosh Pallagatti > (editor)</td><td> </td><td class="right"> Santosh Pallagatti > (editor)</td><td class="lineno"></td></tr> > > <tr id="diff0041"><td></td></tr> > > <tr><td class="lineno"></td><td class="lblock"> <span > class="delete">Rtbrick</span></td><td> </td><td class="rblock"> <span > class="insert">VMware</span></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Email: > santosh.pallagatti@gmail.com</td><td> </td><td class="right"> Email: > santosh.pallagatti@gmail.com</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Sudarsan > Paragiri</td><td> </td><td class="right"> Sudarsan Paragiri</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Individual > Contributor</td><td> </td><td class="right"> Individual > Contributor</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Email: > sudarsan.225@gmail.com</td><td> </td><td class="right"> Email: > sudarsan.225@gmail.com</td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"></td><td> </td><td > class="right"></td><td class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Vengada Prasad > Govindan</td><td> </td><td class="right"> Vengada Prasad Govindan</td><td > class="lineno"></td></tr> > > <tr><td class="lineno"></td><td class="left"> Cisco</td><td> > </td><td class="right"> Cisco</td><td class="lineno"></td></tr> > > > > <tr><td></td><td class="left"></td><td> </td><td > class="right"></td><td></td></tr> > > <tr id="end" bgcolor="gray"><th colspan="5" > align="center"> End of changes. 41 change blocks. </th></tr> > > <tr class="stats"><td></td><th><i>76 lines changed or > deleted</i></th><th><i> </i></th><th><i>112 lines changed or > added</i></th><td></td></tr> > > <tr><td colspan="5" align="center" class="small"><br>This html diff > was produced by rfcdiff 1.47. The latest version is available from <a href=" > http://www.tools.ietf.org/tools/rfcdiff/"> > http://tools.ietf.org/tools/rfcdiff/</a> </td></tr> > > </tbody></table> > > > > > > </body></html> >
- 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