Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[Jeffrey Haas <[e-mail]>]

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? 

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.

-- 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 <[e-mail]> wrote:
> 
> >
> >
> > On Wed, Oct 30, 2019 at 11:40 AM, Anoop Ghanwani <[e-mail]>
> > 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 <[e-mail]> 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 <[e-mail]>,
> >> 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 <[e-mail]> 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 <[e-mail]>
> >>> 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 <[e-mail] <mailto:[e-mail]
> >>> <[e-mail]>>> 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 <[e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> > <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>>>>
> >>> 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 >     <[e-mail]
> >>> <mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >      > <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>> 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 >      >     <[e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]>
> >>> <mailto:[e-mail] <[e-mail]>>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>> >      >      > <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>> 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 >      >      >      > <
> >>> [e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >
> >>>     >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>
> >>> >      >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >
> >>>     >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>
> >>> >      >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >
> >>>     >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>
> >>> >      >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >
> >>>     >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>>>
> >>> 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 >      >     <
> >>> [e-mail] <mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >     <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>>>> >
> >>>   >      >     <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>>> >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>> >      >      >      >
> >>>    <mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>> >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >     <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>>>>>>>
> >>> 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 >      >      >      >         <
> >>> [e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>> >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>>> >      >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>>> 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 >      >
> >>>   >      >>         <[e-mail] <
> >>> mailto:[e-mail] <[e-mail]>> >
> >>>    <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >
> >>>     >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>
> >>> >      >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >
> >>>     >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>
> >>> >      >      >      >>  <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >
> >>>     >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>
> >>> >      >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >
> >>>     >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>>>
> >>> 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 >      >      >      >>                 <
> >>> [e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>> >      >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>> >      >
> >>> >     <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>>> >      >
> >>>   >      >>                 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 >      >      >      >>>
> >>>              <[e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> >     <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>> >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>> >      >      >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>>> 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 >      >      >      >>>
> >>>                <[e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>> >      >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>> >      >
> >>> >      >>>  <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>> >      >
> >>> >     <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>>> 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 >      >      >      >>>>  <
> >>> [e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>> >      >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>> >      >
> >>> >      >>>> >       <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>> >      >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>>> 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 >     <[e-mail] <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>> >      >
> >>> >     <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>> >      >
> >>> >      >>>> >       <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>> >      >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>>> 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 >      >
> >>>    <[e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]>
> >>> <mailto:[e-mail] <[e-mail]>>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>> >      >      >
> >>>  <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>> >      >      >
> >>>   >>>> >       <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>> >      >      >
> >>>  <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>>> >      >
> >>>  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 >      >      >      >>>>
> >>> >       <[e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >      >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>> >      >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>> >      >      >
> >>>     >>>> >      >       <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>> >      >      >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>>>> >      >
> >>>  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
> >>> >      >      >      >>>> [e-mail] <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>> >      >     <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>>> >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>>>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>> >     <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>> >      >     <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>> <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>>>> >      >
> >>> >     <mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>> <mailto:[e-mail] <[e-mail]> <
> >>> mailto:[e-mail] <[e-mail]>>> >     <mailto:[e-mail]
> >>> <[e-mail]> <mailto:[e-mail] <[e-mail]>> <
> >>> mailto:[e-mail] <[e-mail]> <mailto:[e-mail]
> >>> <[e-mail]>>>>>> >      >      >      >>>>
> >>> 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
>    [e-mail]
>    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: [e-mail]
> 
> 
>    Sudarsan Paragiri
>    Individual Contributor
> 
>    Email: [e-mail]
> 
> 
>    Vengada Prasad Govindan
>    Cisco
> 
>    Email: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> Pallagatti, et al.         Expires May 2, 2020                 [Page 10]
> 
> Internet-Draft                BFD for VXLAN                 October 2019
> 
> 
>    Mallik Mudigonda
>    Cisco
> 
>    Email: [e-mail]
> 
> 
>    Greg Mirsky
>    ZTE Corp.
> 
>    Email: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 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">   [e-mail]</td><td> </td><td class="right">   [e-mail]</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: [e-mail]</td><td> </td><td class="right">   Email: [e-mail]</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: [e-mail]</td><td> </td><td class="right">   Email: [e-mail]</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>