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: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
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/rtg-bfd/LIACg77JM79rKr_eNSzQE69T-Mc>
X-Mailman-Approved-At: Wed, 30 Oct 2019 14:22:55 -0700
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2019 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;">&lt;</a>&nbsp;<a href="
> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-07.txt"
> style="color:#008">draft-ietf-bfd-vxlan-07.txt</a>&nbsp;</th><th>
> </th><th>&nbsp;<a href="
> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08.txt"
> style="color:#008">draft-ietf-bfd-vxlan-08.txt</a>&nbsp;<a href="
> https://www6.ietf.org/rfcdiff?url1=draft-ietf-bfd-vxlan-08.txt"
> style="color:#008; text-decoration:none;">&gt;</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">              &lt;
> https://www.rfc-editor.org/info/rfc8365&gt;.</td><td> </td><td
> class="right">              &lt;
> https://www.rfc-editor.org/info/rfc8365&gt;.</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">&nbsp;End of changes. 41 change blocks.&nbsp;</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>
>