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

From: Santosh P K <[email-masked]>
Date: Thu, 3 Oct 2019 19:50:20 +0530

Xiao,
   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.

Thanks
Santosh P K

On Wed, Sep 25, 2019 at 8:10 AM <[email-masked]> 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.
>
>
> Of course, in RFC8014 it also says:
>
> "Note that two different Tenant Systems (and TSIs) attached to a common NVE can share a VAP (e.g., TS1 and TS2 in Figure 2) so long as they connect to the same Virtual Network."
>
> Some people may argue that all Tenant Systems connecting to the same
> Virtual Network MUST share one VAP, if that's true, then VAP1 and VAP3
> should merge into one VAP and my explanation doesn't work. Copying to NVO3
> WG to involve more experts, hope for your clarifications and comments.
>
>
> Best Regards,
>
> Xiao Min
> 原始邮件
> *发件人：*SantoshPK <[email-masked]>
> *收件人：*Greg Mirsky <[email-masked]>;
> *抄送人：[email-masked] <[email-masked]>;Dinesh
> Dutt <[email-masked]>;rtg-bfd WG <[email-masked]>;Joel M. Halpern <
> [email-masked]>;T. Sridhar <[email-masked]>;[email-masked]
> <[email-masked]>;
> *日 期 ：*2019年09月23日 05:39
> *主 题 ：**Re: BFD over VXLAN: Trapping BFD Control packet at VTEP*
> Greg,
>     Please see inline reply tagged [SPK]. I have added text requested.
>
> Thanks
> Santosh P K
>
> On Fri, Aug 16, 2019 at 4:59 AM Greg Mirsky <gregimirsky@gmail...com
> <[email-masked]>> wrote:
>
>> Hi Santosh,
>> thank you for your comments. Please find my notes in-lined and tagged
>> GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Tue, Aug 13, 2019 at 10:24 PM Santosh P K <
>> [email-masked]> wrote:
>>
>>> Greg,
>>>    Thanks for updated version of document. Here are few comments on new
>>> draft.
>>>
>>> Section 4:
>>> Destination MAC: This MUST NOT be of one of tenant's MAC
>>>          addresses.  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.
>>>
>>> I think we may need to give background on why we are saying MAC address
>>> MUST not be one of tenant's MAC address. Like in this thread we have
>>> discussed one of the tenant could have borrowed the same VTEP mac address
>>> and we if we have to use BFD then we need to avoid that conflict to ensure
>>> BFD packets get observed in the VTEP itself. Should we add a section before
>>> 4 to set that context so that above text makes more sense in that context?
>>>
>> GIM>> Certainly. Please share the text you'd like to add.
>>
>
> [SPK]  Proposed text for why we should not use VTEP MAX address as tenant
> MAC address.
>
> "In some scenarios tenant MAC is borrowed from VTEP MAC address. VXLAN BFD
> MUST terminate BFD session at VTEP and MUST not forward BFD packets to
> tenants. To terminate VXLAN BFD packets at VTEP, deployment MUST ensure
> that there are no tenant VM which barrows VTEP MAC address."
>
>
>>>
>>>    IP header:
>>>          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.
>>>
>>>          TTL: MUST be set to 1 to ensure that the BFD packet is not
>>>          routed within the L3 underlay network.
>>>
>>>
>>> I think we have added some text to address Sridhar comments on why TTL
>>> MUST be 1 and dest IP address MUST be 127/8 range. I see that text is
>>> missing now.
>>>
>> GIM>> My apologies that I've missed to include the text from another
>> discussion thread. I believe the following would be complete:
>>           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.
>>
>
> [SPK] This text looks good.
>
>>
>>> Section 5.1:
>>> For such packets, the BFD session MUST be identified
>>>    using the following three-tuples of fields of the inner header: the
>>>    source IP, the destination IP, and the source UDP port number present
>>>    in the IP header carried by the payload of the packet in VXLAN
>>>    encapsulation.  If BFD packet is received with non-zero Your
>>> Discriminator, then BFD session MUST be demultiplexed only with Your
>>>    Discriminator as the key.
>>>
>>> Just with 3 tuple we will not be able to demux packet. We need to
>>> consider VNI as well if we have multiple BFD session between same pair of
>>> VTEP.
>>>
>> GIM>> This is one of comments from Carlos we need to address. Your
>> comment have helped me to form the question:
>>
>> What is the goal running multiple BFD sessions between the pair of VTEPs?
>>
>>
> [SPK] The goal of the multiple BFD session is to ensure check liveliness
> of VXLAN tunnel. There is already a good amount of debate on this topic
> that do we really need that? As per RFC 5884 we are running BFD per LSP and
> we might hit scale issues there too. I think it is up to operator to decide
> how they want to use multiple BFD session per VXLAN tunnel. It could be
> possible that BFD session with special VNI is run at aggressive interval
> where as MAY have multiple BFD sessions for different VNI at a sedate
> interval, for that matter they could be running in demand mode as well (run
> P/F sequence only when there is no data following for that VNI). As WG if
> we think running multiple BFD session make sense then we might need to add
> appropriate text.
>
> If the goal is to monitor per VNI, then the following text should describe
>> the demultiplexing of the initial BFD Control 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.
>>
>
> [SPK]  I think this text for multiple BFD session between same pair of
> VTEPs for multiple VNI makes sense only if as WG we think that could be use
> case.
>
> Would there be need to run multiple BFD sessions with the same VNI number?
>>
>
> [SPK] IMHO we should not allow multiple BFD session for the same VNI.
>
>
>>
>>
>>>
>>> Thanks
>>> Santosh P K
>>>
>>>
>>> On Fri, Aug 9, 2019 at 4:27 AM Greg Mirsky <[email-masked]>
>>> wrote:
>>>
>>>> Dinesh, thank you for your help, much appreciated.
>>>> Hi Joel and Sridhar,
>>>> could you please check if the updated text on the inner Ethernet frame
>>>> addressed your concern.
>>>>
>>>> On Wed, Aug 7, 2019 at 2:25 PM Dinesh Dutt <[email-masked]> wrote:
>>>>
>>>>> Looks god to me Greg. Thank you for your hard work in this,
>>>>>
>>>>> Dinesh
>>>>>
>>>>> On Wed, Aug 7, 2019 at 9:25 AM Greg Mirsky <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Hi Dinesh, Joel, Sridhar, et al.,
>>>>>> much appreciate the help you've given me sharing your expertise. I
>>>>>> hope that the updates you will find in the attached diff and the working
>>>>>> copy of the draft be closer to the acceptable solution for VTEP-VTEP BFD.
>>>>>> Please note, that I'll shortly start a new discussion thread to address one
>>>>>> of Carlos's questions on the ambiguity of the text on multiple concurrent
>>>>>> sessions between the same pair of VTEPs.
>>>>>> Please review the changes to Sections 4 and 6 and share your
>>>>>> feedback, suggestions, and questions.
>>>>>>
>>>>>> Regards,
>>>>>> Greg
>>>>>>
>>>>>> On Mon, Aug 5, 2019 at 6:03 PM Dinesh Dutt <[email-masked]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 5, 2019 at 5:56 PM Greg Mirsky <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Dinesh,
>>>>>>>> thank you for your expedient detailed response.
>>>>>>>> I believe that the ability to run BFD session up to a tenant
>>>>>>>> (VTEP-VTEP-tenant or tenant-tenant) was never in jeopardy from this
>>>>>>>> specification.
>>>>>>>> I'm trying to provide precise specification on what can be used ad
>>>>>>>> the destination MAC and IP addresses in the inner frame/packet as I believe
>>>>>>>> that likely will help to avoid interoperability issues.
>>>>>>>> I'm interested to learn some more about the "martian checking"
>>>>>>>> function. As you know, martian addresses have been used as destination IP
>>>>>>>> address in LSP Ping and BFD over MPLS LSP and PW. I haven't heard that any
>>>>>>>> silicon feature caused problems for operators using these tools.
>>>>>>>>
>>>>>>>
>>>>>>> Interesting. I didn't know this aspect of use with MPLS ping. Did
>>>>>>> those packets ever go through a firewall though? In any case, maybe suggest
>>>>>>> the use of those addresses with a statement that this is how LSP does it,
>>>>>>> but that other MAC/IP pairs are possible as long as the conditions of the
>>>>>>> endpoint owning the MAC/IP was honored.
>>>>>>>
>>>>>>> Dinesh
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Greg
>>>>>>>>
>>>>>>>> On Mon, Aug 5, 2019 at 3:59 PM Dinesh Dutt <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Greg,
>>>>>>>>>
>>>>>>>>> That we agree on the problem definition is the first step forward.
>>>>>>>>> Your original document had my cases covered and so I was surprised by the
>>>>>>>>> track this thread took. It doesn't matter, we're back on track.
>>>>>>>>>
>>>>>>>>> My recommendation is to not worry about specifying the precise
>>>>>>>>> MAC/IP address used in the inner header. The addresses chosen MUST ensure
>>>>>>>>> that the packet is trapped to the control plane of the VTEP and not escape
>>>>>>>>> to the tenant if the BFD is to the VTEP. Any solution MUST also not
>>>>>>>>> preclude the use of the BFD by tenant systems for that VNI. There are many
>>>>>>>>> ways an implementer can choose to implement this. For example, the inner
>>>>>>>>> MAC address is whatever the VTEP implementer would return if ARP'd for the
>>>>>>>>> IP address used in the inner header in the given VNI. The implementer can
>>>>>>>>> pick a fixed MAC address, one that they own etc. Multiple BFD sessions can
>>>>>>>>> be run for testing path connectivity on more than one VNIs. Limits should
>>>>>>>>> be in place to avoid overwhelming the receiver with BFD messages (you had
>>>>>>>>> words about this in your currently published draft).  If the VNI is
>>>>>>>>> irrelevant in the test i.e. only the VXLAN pipe at the VTEP is being
>>>>>>>>> tested. the user can use any VNI active on the VTEP on which the VTEP owns
>>>>>>>>> an IP address.
>>>>>>>>>
>>>>>>>>> I'm concerned about the use of 127/8 address only because of
>>>>>>>>> firewalls or implementations that drop packets with these addresses as
>>>>>>>>> either the source or destination. For example, on many merchant silicon, I
>>>>>>>>> don't believe you can turn off martian checking and drops *only* for
>>>>>>>>> VXLAN-encapsulated BFD packets. I don't know what the Linux kernel does
>>>>>>>>> today on such packets, for example (or Hyper-V). I'd like a solution that
>>>>>>>>> doesn't demand additional or new chip functionality or require additional
>>>>>>>>> middle-box hole punch.
>>>>>>>>>
>>>>>>>>> Why do you feel you MUST to specify the MAC/IP address on the
>>>>>>>>> inner packet? What am I missing here?
>>>>>>>>>
>>>>>>>>> Dinesh
>>>>>>>>>
>>>>>>>>> On Mon, Aug 5, 2019 at 3:04 PM Greg Mirsky <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Dinesh,
>>>>>>>>>> what do you see as the way forward? I agree, that the proposed
>>>>>>>>>> text doesn't work for multi-VNI concurrent monitoring because these VNIs
>>>>>>>>>> are tenant's VNIs. And in that case, we need to specify another mechanism
>>>>>>>>>> to trap the BFD Control packet at VTEP. It seems that VTEP's Ethernet
>>>>>>>>>> address must be used as the destination MAC address in the inner Ethernet
>>>>>>>>>> frame. The destination IP address may be either VTEP's address of martian
>>>>>>>>>> (I do prefer martian). Let me give it  try:
>>>>>>>>>> NEW TEXT:
>>>>>>>>>>
>>>>>>>>>> To monitor continuity of the path between two VTEPs, an operator
>>>>>>>>>> MUST select a VNI number to be used as Management VNI. Management VNI
>>>>>>>>>> number MUST NOT be one of the tenant's VNIs to prevent sending VXLAN
>>>>>>>>>> packets received on Management VNI to a tenant. VNI number 1 is RECOMMENDED
>>>>>>>>>> as the default for Management VNI. [Ed.note: What we set the Destination
>>>>>>>>>> MAC to? Can it be invalid MAC that MUST be ignored on receipt?]
>>>>>>>>>>
>>>>>>>>>> If an implementation supports concurrent monitoring of multiple
>>>>>>>>>> VNIs, then the value of VNI number MAY be one of tenant's VNIs. The
>>>>>>>>>> destination MAC address in the inner Ethernet frame encapsulating BFD
>>>>>>>>>> Control packet MUST be MAC associated with the remote VTEP.
>>>>>>>>>> The destination IP address of the inner IP packet MUST be
>>>>>>>>>> selected from the range 127/8 for IPv4, and for IPv6 from the range
>>>>>>>>>> 0:0:0:0:0:FFFF:7F00:0/104. The TTL value in the inner IP header MUST be set
>>>>>>>>>> to 1.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Greg
>>>>>>>>>>
>>>>>>>>>> On Sun, Aug 4, 2019 at 9:07 AM Dinesh Dutt <[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Greg,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your clarifications. I agree with your sentiment on
>>>>>>>>>>> why you're running BFD over VXLAN between VTEPs. I wasn't arguing against
>>>>>>>>>>> it at all. All I was saying was pointing to the limitations of the use of
>>>>>>>>>>> management VNI. I spoke to some operators who're running EVPN and mentioned
>>>>>>>>>>> the discussion on this thread. They concur that they're using specific VNIs
>>>>>>>>>>> to test connectivity over that VNI between VTEPs to ensure misconfiguration
>>>>>>>>>>> doesn't lead to blackholes. My statements are based in real world operator
>>>>>>>>>>> experience. And I was providing language that ensured packets didn't leak
>>>>>>>>>>> across to tenants when they were destined to VTEPs.
>>>>>>>>>>>
>>>>>>>>>>> Dinesh
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Aug 3, 2019 at 10:34 AM Greg Mirsky <
>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Dinesh,
>>>>>>>>>>>> many thanks for your detailed updates on how some
>>>>>>>>>>>> implementations process VXLAN header and the inner Ethernet frame. These
>>>>>>>>>>>> are very helpful in achieving the workable solution for the problem at hand.
>>>>>>>>>>>> You've noted that a path between VTEPs may be monitored in the
>>>>>>>>>>>> underlay network by merely establishing a BFD session. That is true, but by
>>>>>>>>>>>> using BFD with VXLAN encapsulation between the pair of VTEPs we are
>>>>>>>>>>>> extending the OAM domain by including, to some extent, VXLAN forwarding
>>>>>>>>>>>> engine. Abstract in RFC 5880 defines the goal and the domain in which BFD
>>>>>>>>>>>> protocol can detect a fault as:
>>>>>>>>>>>>    This document describes a protocol intended to detect faults
>>>>>>>>>>>> in the
>>>>>>>>>>>>    bidirectional path between two forwarding engines, including
>>>>>>>>>>>>    interfaces, data link(s), and to the extent possible the
>>>>>>>>>>>> forwarding
>>>>>>>>>>>>    engines themselves, with potentially very low latency.
>>>>>>>>>>>> Thus, BFD in the underlay will exercise a part of IP forwarding
>>>>>>>>>>>> engine while BFD with VXLAN encapsulation, ran between the same pair of
>>>>>>>>>>>> VTEPs, extends the OAM domain. At the same time, defining BFD between
>>>>>>>>>>>> tenant systems in outside the goal of this specification. But VXLAN BFD
>>>>>>>>>>>> session between VTEPs may be useful in monitoring e2e path between tenants,
>>>>>>>>>>>> as described in the update to -07:
>>>>>>>>>>>>    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].
>>>>>>>>>>>> I've attached the current working version of the draft.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Greg
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Aug 2, 2019 at 5:43 PM Dinesh Dutt <[email-masked]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> What I mean is "How do you infer that it excludes the case I'm
>>>>>>>>>>>>> talking about?".
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dinesh
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Aug 2, 2019 at 5:41 PM Dinesh Dutt <[email-masked]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The abstract reads this: "
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How do you infer what you said?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dinesh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Aug 2, 2019 at 5:38 PM Joel M. Halpern <
>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am going by what the draft says its purpose is.  If you
>>>>>>>>>>>>>>> (Dinesh) want
>>>>>>>>>>>>>>> the draft to fulfill a different purpose, then either ask
>>>>>>>>>>>>>>> the chairs to
>>>>>>>>>>>>>>> take this draft back to the WG, or write a separate draft.
>>>>>>>>>>>>>>> As currently written, the behavior Greg proposed meets the
>>>>>>>>>>>>>>> needs, and
>>>>>>>>>>>>>>> does so in a way that is consistent with VxLAN.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yours,
>>>>>>>>>>>>>>> Joel
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 8/2/2019 8:30 PM, Dinesh Dutt wrote:
>>>>>>>>>>>>>>> > What is the stated purpose of this BFD session? The VTEP
>>>>>>>>>>>>>>> reachability is
>>>>>>>>>>>>>>> > determined by the underlay, I don't need VXLAN-encaped
>>>>>>>>>>>>>>> packet for that.
>>>>>>>>>>>>>>> > Do we agree?
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > If I want to test the VXLAN encap/decap functionality
>>>>>>>>>>>>>>> alone, picking any
>>>>>>>>>>>>>>> > single VNI maybe fine. But is this all any network
>>>>>>>>>>>>>>> operator wants? Why?
>>>>>>>>>>>>>>> > In what situations has this been a problem? I suspect
>>>>>>>>>>>>>>> operators also
>>>>>>>>>>>>>>> > want to verify path continuity over a specific VNI. If you
>>>>>>>>>>>>>>> say this is
>>>>>>>>>>>>>>> > not defined by the document, I disagree because the
>>>>>>>>>>>>>>> current version
>>>>>>>>>>>>>>> > talks about controlling the number of BFD sessions between
>>>>>>>>>>>>>>> the VTEPs
>>>>>>>>>>>>>>> > (see section 3). More importantly, this is a real problem
>>>>>>>>>>>>>>> that operators
>>>>>>>>>>>>>>> > like to verify.
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > Dinesh
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > On Fri, Aug 2, 2019 at 5:08 PM Joel M. Halpern <
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> > <mailto:[email-masked]>> wrote:
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> >     What is special about the management VNI is precisely
>>>>>>>>>>>>>>> that it is NOT a
>>>>>>>>>>>>>>> >     tenant VNI.  The VxLAN administration does know how it
>>>>>>>>>>>>>>> allocates VNI to
>>>>>>>>>>>>>>> >     tenants, and which VNI it has allocated.  In contrast,
>>>>>>>>>>>>>>> it does not know
>>>>>>>>>>>>>>> >     which IP addresses or MAC adddresses teh tenant is
>>>>>>>>>>>>>>> using or may plan
>>>>>>>>>>>>>>> >     to use.
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> >     Yours,
>>>>>>>>>>>>>>> >     Joel
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> >     On 8/2/2019 6:41 PM, Dinesh Dutt wrote:
>>>>>>>>>>>>>>> >      > The assumption of an IP address within any VNI is
>>>>>>>>>>>>>>> suspect that way.
>>>>>>>>>>>>>>> >      > What's special about a single VNI, the management
>>>>>>>>>>>>>>> VNI? The VTEP IP
>>>>>>>>>>>>>>> >      > address does not belong in reality in any VNI...
>>>>>>>>>>>>>>> >      >
>>>>>>>>>>>>>>> >      > Dinesh
>>>>>>>>>>>>>>> >      >
>>>>>>>>>>>>>>> >      > On Fri, Aug 2, 2019 at 3:17 PM Joel M. Halpern
>>>>>>>>>>>>>>> >     <[email-masked] <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      > <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>> wrote:
>>>>>>>>>>>>>>> >      >
>>>>>>>>>>>>>>> >      >     Your response seems to miss two points:
>>>>>>>>>>>>>>> >      >
>>>>>>>>>>>>>>> >      >     First, the problem you describe is not what the
>>>>>>>>>>>>>>> document says
>>>>>>>>>>>>>>> >     it is
>>>>>>>>>>>>>>> >      >     solving.  To the degree it discusses it at all,
>>>>>>>>>>>>>>> the document
>>>>>>>>>>>>>>> >     says "
>>>>>>>>>>>>>>> >      >       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 in common. "
>>>>>>>>>>>>>>> >      >
>>>>>>>>>>>>>>> >      >     Second, you assume the existence of an IP
>>>>>>>>>>>>>>> address for a VTEP
>>>>>>>>>>>>>>> >     within a
>>>>>>>>>>>>>>> >      >     VNI.  As with the MAC address, the VTEP does
>>>>>>>>>>>>>>> not have an IP
>>>>>>>>>>>>>>> >     address
>>>>>>>>>>>>>>> >      >     within the VNI.  Some implementations may have
>>>>>>>>>>>>>>> created such a
>>>>>>>>>>>>>>> >     thing,
>>>>>>>>>>>>>>> >      >     but
>>>>>>>>>>>>>>> >      >     the general construct, as defined to date, does
>>>>>>>>>>>>>>> not support such.
>>>>>>>>>>>>>>> >      >
>>>>>>>>>>>>>>> >      >     In short, you are requiring a behavior that
>>>>>>>>>>>>>>> violates the
>>>>>>>>>>>>>>> >     architectural
>>>>>>>>>>>>>>> >      >     structure of overlay / underlay separation, and
>>>>>>>>>>>>>>> common
>>>>>>>>>>>>>>> >     usage.  And you
>>>>>>>>>>>>>>> >      >     are doing so to support a use case that the
>>>>>>>>>>>>>>> working group has not
>>>>>>>>>>>>>>> >      >     indicated in the document as important.
>>>>>>>>>>>>>>> >      >
>>>>>>>>>>>>>>> >      >     Yours,
>>>>>>>>>>>>>>> >      >     Joel
>>>>>>>>>>>>>>> >      >
>>>>>>>>>>>>>>> >      >     On 8/2/2019 5:01 PM, Dinesh Dutt wrote:
>>>>>>>>>>>>>>> >      >      > Joel,
>>>>>>>>>>>>>>> >      >      >
>>>>>>>>>>>>>>> >      >      > You understood correctly.
>>>>>>>>>>>>>>> >      >      >
>>>>>>>>>>>>>>> >      >      > The VNIs may not share fate due to
>>>>>>>>>>>>>>> misconfiguration. And I
>>>>>>>>>>>>>>> >     strongly
>>>>>>>>>>>>>>> >      >      > suspect someone will want to use BFD for
>>>>>>>>>>>>>>> that because its
>>>>>>>>>>>>>>> >     about
>>>>>>>>>>>>>>> >      >     checking
>>>>>>>>>>>>>>> >      >      > path continuity as stated by the draft. As
>>>>>>>>>>>>>>> long as there's a
>>>>>>>>>>>>>>> >      >     valid IP
>>>>>>>>>>>>>>> >      >      > (because it's BFD) owned by the VTEP in that
>>>>>>>>>>>>>>> VNI, you can
>>>>>>>>>>>>>>> >     use BFD in
>>>>>>>>>>>>>>> >      >      > that VNI. Thats all that you need to
>>>>>>>>>>>>>>> dictate.  That IP address
>>>>>>>>>>>>>>> >      >     has a MAC
>>>>>>>>>>>>>>> >      >      > address and you can use that on the inner
>>>>>>>>>>>>>>> frame. That is
>>>>>>>>>>>>>>> >     all normal
>>>>>>>>>>>>>>> >      >      > VXLAN processing. The outer IP is always
>>>>>>>>>>>>>>> that of the VTEP.
>>>>>>>>>>>>>>> >      >      >
>>>>>>>>>>>>>>> >      >      > Dinesh
>>>>>>>>>>>>>>> >      >      >
>>>>>>>>>>>>>>> >      >      > On Fri, Aug 2, 2019 at 11:03 AM Joel M.
>>>>>>>>>>>>>>> Halpern
>>>>>>>>>>>>>>> >      >     <[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>
>>>>>>>>>>>>>>> >      >      > <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>>> wrote:
>>>>>>>>>>>>>>> >      >      >
>>>>>>>>>>>>>>> >      >      >     If I am reading your various emails
>>>>>>>>>>>>>>> correctly Dinesh
>>>>>>>>>>>>>>> >     (and I
>>>>>>>>>>>>>>> >      >     may have
>>>>>>>>>>>>>>> >      >      >     missed something) you are trying to use
>>>>>>>>>>>>>>> the MAC address
>>>>>>>>>>>>>>> >      >     because you
>>>>>>>>>>>>>>> >      >      >     want
>>>>>>>>>>>>>>> >      >      >     to be able to send these BFD packets
>>>>>>>>>>>>>>> over arbitrary VNI to
>>>>>>>>>>>>>>> >      >     monitor the
>>>>>>>>>>>>>>> >      >      >     VNI.  That is not a requirement
>>>>>>>>>>>>>>> identified in the
>>>>>>>>>>>>>>> >     document.
>>>>>>>>>>>>>>> >      >     It is not
>>>>>>>>>>>>>>> >      >      >     even a problem I understand, since all
>>>>>>>>>>>>>>> the VNI between an
>>>>>>>>>>>>>>> >      >     ingress and
>>>>>>>>>>>>>>> >      >      >     egress VTEP share fate.
>>>>>>>>>>>>>>> >      >      >
>>>>>>>>>>>>>>> >      >      >     Yours,
>>>>>>>>>>>>>>> >      >      >     Joel
>>>>>>>>>>>>>>> >      >      >
>>>>>>>>>>>>>>> >      >      >     On 8/2/2019 1:44 PM, Dinesh Dutt wrote:
>>>>>>>>>>>>>>> >      >      >      > Thanks for verifying this. On Linux
>>>>>>>>>>>>>>> and hardware
>>>>>>>>>>>>>>> >     routers
>>>>>>>>>>>>>>> >      >     that I'm
>>>>>>>>>>>>>>> >      >      >     aware
>>>>>>>>>>>>>>> >      >      >      > of (Cisco circa 2012 and Cumulus),
>>>>>>>>>>>>>>> the physical MAC
>>>>>>>>>>>>>>> >     address is
>>>>>>>>>>>>>>> >      >      >     reused
>>>>>>>>>>>>>>> >      >      >      > across the VNIs on the VTEP. Did you
>>>>>>>>>>>>>>> check on a non-VMW
>>>>>>>>>>>>>>> >      >     device?
>>>>>>>>>>>>>>> >      >      >     This is
>>>>>>>>>>>>>>> >      >      >      > more for my own curiosity.
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      > To address the general case, can we
>>>>>>>>>>>>>>> not define a
>>>>>>>>>>>>>>> >      >     well-known (or
>>>>>>>>>>>>>>> >      >      >     reserve
>>>>>>>>>>>>>>> >      >      >      > one) unicast MAC address for use with
>>>>>>>>>>>>>>> VTEP? If the MAC
>>>>>>>>>>>>>>> >      >     address is
>>>>>>>>>>>>>>> >      >      >      > configurable in BFD command, this can
>>>>>>>>>>>>>>> be moot.
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      > Dinesh
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      > On Fri, Aug 2, 2019 at 10:27 AM
>>>>>>>>>>>>>>> Santosh P K
>>>>>>>>>>>>>>> >      >      >      > <[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:santosh.pallagatti@gmail...com
>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:santosh.pallagatti@gmail...com
>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:santosh.pallagatti@gmail...com
>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:santosh.pallagatti@gmail...com
>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>>>> wrote:
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >     I have cross checked point raised
>>>>>>>>>>>>>>> about MAC address
>>>>>>>>>>>>>>> >      >     usage. It is
>>>>>>>>>>>>>>> >      >      >      >     possible that tenant could be
>>>>>>>>>>>>>>> using physical MAC
>>>>>>>>>>>>>>> >      >     address and
>>>>>>>>>>>>>>> >      >      >     when a
>>>>>>>>>>>>>>> >      >      >      >     packet comes with valid VNI with
>>>>>>>>>>>>>>> a MAC address
>>>>>>>>>>>>>>> >     that is
>>>>>>>>>>>>>>> >      >     being
>>>>>>>>>>>>>>> >      >      >     used by
>>>>>>>>>>>>>>> >      >      >      >     tenant then packet will be sent
>>>>>>>>>>>>>>> to that tenant.
>>>>>>>>>>>>>>> >     This rules
>>>>>>>>>>>>>>> >      >      >     out the
>>>>>>>>>>>>>>> >      >      >      >     fact that we could use physical
>>>>>>>>>>>>>>> MAC address as
>>>>>>>>>>>>>>> >     inner
>>>>>>>>>>>>>>> >      >     MAC to
>>>>>>>>>>>>>>> >      >      >     ensure
>>>>>>>>>>>>>>> >      >      >      >     packets get terminated at VTEP
>>>>>>>>>>>>>>> itself.
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >     Thanks
>>>>>>>>>>>>>>> >      >      >      >     Santosh P K
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >     On Wed, Jul 31, 2019 at 11:00 AM
>>>>>>>>>>>>>>> Santosh P K
>>>>>>>>>>>>>>> >      >      >      >     <[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:santosh.pallagatti@gmail...com
>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:santosh.pallagatti@gmail...com
>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:santosh.pallagatti@gmail...com
>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:santosh.pallagatti@gmail...com
>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>>>>
>>>>>>>>>>>>>>> >      >      >      >     wrote:
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >         Joel,
>>>>>>>>>>>>>>> >      >      >      >             Thanks for your inputs. I
>>>>>>>>>>>>>>> checked
>>>>>>>>>>>>>>> >      >     implementation within
>>>>>>>>>>>>>>> >      >      >      >         Vmware. Perhaps I should have
>>>>>>>>>>>>>>> been more clear
>>>>>>>>>>>>>>> >      >     about MAC
>>>>>>>>>>>>>>> >      >      >     address
>>>>>>>>>>>>>>> >      >      >      >         space while checking
>>>>>>>>>>>>>>> internally. I will cross
>>>>>>>>>>>>>>> >      >     check again for
>>>>>>>>>>>>>>> >      >      >      >         the same and get back on this
>>>>>>>>>>>>>>> list.
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >         Thanks
>>>>>>>>>>>>>>> >      >      >      >         Santosh P K
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >         On Wed, Jul 31, 2019 at 10:54
>>>>>>>>>>>>>>> AM Joel M.
>>>>>>>>>>>>>>> >     Halpern
>>>>>>>>>>>>>>> >      >      >      >         <[email-masked]
>>>>>>>>>>>>>>> <jmh@joelhalpern...com>
>>>>>>>>>>>>>>> >     <mailto:[email-masked]> <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]> <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>>>> wrote:
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >             Sorry to ask a stupid
>>>>>>>>>>>>>>> question.  Whose
>>>>>>>>>>>>>>> >      >     implementation?
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >             The reason I ask is that
>>>>>>>>>>>>>>> as far as I
>>>>>>>>>>>>>>> >     can tell,
>>>>>>>>>>>>>>> >      >     since the
>>>>>>>>>>>>>>> >      >      >      >             tenant does not
>>>>>>>>>>>>>>> >      >      >      >             have any control access
>>>>>>>>>>>>>>> to the VTEP,
>>>>>>>>>>>>>>> >     there is no
>>>>>>>>>>>>>>> >      >      >     reason for
>>>>>>>>>>>>>>> >      >      >      >             the VTEP to
>>>>>>>>>>>>>>> >      >      >      >             have a MAC address in the
>>>>>>>>>>>>>>> tenant
>>>>>>>>>>>>>>> >     space.  Yes, the
>>>>>>>>>>>>>>> >      >      >     device has
>>>>>>>>>>>>>>> >      >      >      >             a physical
>>>>>>>>>>>>>>> >      >      >      >             MAC address.  But the
>>>>>>>>>>>>>>> tenant could well be
>>>>>>>>>>>>>>> >      >     using that MAC
>>>>>>>>>>>>>>> >      >      >      >             address.  Yes,
>>>>>>>>>>>>>>> >      >      >      >             they would be violating
>>>>>>>>>>>>>>> the Ethernet spec.
>>>>>>>>>>>>>>> >      >     But the whole
>>>>>>>>>>>>>>> >      >      >      >             point of
>>>>>>>>>>>>>>> >      >      >      >             segregation is not to
>>>>>>>>>>>>>>> care about such
>>>>>>>>>>>>>>> >     issues.
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >             On the other hand, if you
>>>>>>>>>>>>>>> tell me that
>>>>>>>>>>>>>>> >     the VMWare
>>>>>>>>>>>>>>> >      >      >      >             implementation has an
>>>>>>>>>>>>>>> >      >      >      >             Ethernet address that is
>>>>>>>>>>>>>>> part of the tenant
>>>>>>>>>>>>>>> >      >     space, well,
>>>>>>>>>>>>>>> >      >      >      >             they made up
>>>>>>>>>>>>>>> >      >      >      >             this particular game.
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >             Yours,
>>>>>>>>>>>>>>> >      >      >      >             Joel
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >      >             On 7/31/2019 1:44 PM,
>>>>>>>>>>>>>>> Santosh P K wrote:
>>>>>>>>>>>>>>> >      >      >      >              > I have checked with
>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>> >     in data
>>>>>>>>>>>>>>> >      >     path.
>>>>>>>>>>>>>>> >      >      >     When we
>>>>>>>>>>>>>>> >      >      >      >             receive a
>>>>>>>>>>>>>>> >      >      >      >              > packet with valid VNI
>>>>>>>>>>>>>>> then lookup
>>>>>>>>>>>>>>> >     for MAC will
>>>>>>>>>>>>>>> >      >      >     happen and
>>>>>>>>>>>>>>> >      >      >      >             it is VTEP own
>>>>>>>>>>>>>>> >      >      >      >              > MAC then it will be
>>>>>>>>>>>>>>> trapped to control
>>>>>>>>>>>>>>> >      >     plane for
>>>>>>>>>>>>>>> >      >      >      >             processing. I think we
>>>>>>>>>>>>>>> >      >      >      >              > can have following
>>>>>>>>>>>>>>> options
>>>>>>>>>>>>>>> >      >      >      >              > 1. Optional managment
>>>>>>>>>>>>>>> VNI
>>>>>>>>>>>>>>> >      >      >      >              > 2. Mandatory inner MAC
>>>>>>>>>>>>>>> set to VTEP mac
>>>>>>>>>>>>>>> >      >      >      >              > 3. Inner IP TTL set to
>>>>>>>>>>>>>>> 1 to avoid
>>>>>>>>>>>>>>> >      >     forwarding of packet
>>>>>>>>>>>>>>> >      >      >      >             via inner IP
>>>>>>>>>>>>>>> >      >      >      >              > address.
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              > Thoughts?
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              > Thansk
>>>>>>>>>>>>>>> >      >      >      >              > Santosh P K
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              > On Wed, Jul 31, 2019
>>>>>>>>>>>>>>> at 9:20 AM Greg
>>>>>>>>>>>>>>> >     Mirsky
>>>>>>>>>>>>>>> >      >      >      >             <[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]> <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>>>
>>>>>>>>>>>>>>> >      >      >      >              > <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]> <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>>
>>>>>>>>>>>>>>> >      >      >      >             <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>>>>> wrote:
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >     Hi Dinesh,
>>>>>>>>>>>>>>> >      >      >      >              >     thank you for your
>>>>>>>>>>>>>>> consideration
>>>>>>>>>>>>>>> >     of the
>>>>>>>>>>>>>>> >      >      >     proposal and
>>>>>>>>>>>>>>> >      >      >      >             questions. What
>>>>>>>>>>>>>>> >      >      >      >              >     would you see as
>>>>>>>>>>>>>>> the scope of
>>>>>>>>>>>>>>> >     testing the
>>>>>>>>>>>>>>> >      >      >      >             connectivity for the
>>>>>>>>>>>>>>> >      >      >      >              >     specific VNI? If
>>>>>>>>>>>>>>> it is
>>>>>>>>>>>>>>> >      >     tenant-to-tenant, then
>>>>>>>>>>>>>>> >      >      >     VTEPs
>>>>>>>>>>>>>>> >      >      >      >             will treat these
>>>>>>>>>>>>>>> >      >      >      >              >     packets as regular
>>>>>>>>>>>>>>> user frames. More
>>>>>>>>>>>>>>> >      >     likely, these
>>>>>>>>>>>>>>> >      >      >      >             could be Layer 2
>>>>>>>>>>>>>>> >      >      >      >              >     OAM, e.g. CCM
>>>>>>>>>>>>>>> frames. The reason
>>>>>>>>>>>>>>> >     to use
>>>>>>>>>>>>>>> >      >     127/8 for
>>>>>>>>>>>>>>> >      >      >      >             IPv4, and
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>>  0:0:0:0:0:FFFF:7F00:0/104 for
>>>>>>>>>>>>>>> >     IPv6 is
>>>>>>>>>>>>>>> >      >     to safeguard
>>>>>>>>>>>>>>> >      >      >      >             from leaking
>>>>>>>>>>>>>>> >      >      >      >              >     Ethernet frames
>>>>>>>>>>>>>>> with BFD Control
>>>>>>>>>>>>>>> >     packet
>>>>>>>>>>>>>>> >      >     to a
>>>>>>>>>>>>>>> >      >      >     tenant.
>>>>>>>>>>>>>>> >      >      >      >              >     You've suggested
>>>>>>>>>>>>>>> using a MAC
>>>>>>>>>>>>>>> >     address to
>>>>>>>>>>>>>>> >      >     trap the
>>>>>>>>>>>>>>> >      >      >      >             control packet at
>>>>>>>>>>>>>>> >      >      >      >              >     VTEP. What that
>>>>>>>>>>>>>>> address could be? We
>>>>>>>>>>>>>>> >      >     had proposed
>>>>>>>>>>>>>>> >      >      >      >             using the
>>>>>>>>>>>>>>> >      >      >      >              >     dedicated MAC and
>>>>>>>>>>>>>>> VTEP's MAC and
>>>>>>>>>>>>>>> >     both
>>>>>>>>>>>>>>> >      >     raised
>>>>>>>>>>>>>>> >      >      >     concerns
>>>>>>>>>>>>>>> >      >      >      >             among VXLAN
>>>>>>>>>>>>>>> >      >      >      >              >     experts. The idea
>>>>>>>>>>>>>>> of using
>>>>>>>>>>>>>>> >     Management
>>>>>>>>>>>>>>> >      >     VNI may
>>>>>>>>>>>>>>> >      >      >     be more
>>>>>>>>>>>>>>> >      >      >      >             acceptable
>>>>>>>>>>>>>>> >      >      >      >              >     based on its
>>>>>>>>>>>>>>> similarity to the
>>>>>>>>>>>>>>> >     practice
>>>>>>>>>>>>>>> >      >     of using
>>>>>>>>>>>>>>> >      >      >      >             Management VLAN.
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >     Regards,
>>>>>>>>>>>>>>> >      >      >      >              >     Greg
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >     On Wed, Jul 31,
>>>>>>>>>>>>>>> 2019 at 12:03 PM
>>>>>>>>>>>>>>> >     Dinesh
>>>>>>>>>>>>>>> >      >     Dutt
>>>>>>>>>>>>>>> >      >      >      >             <[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]> <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:[email-masked]>>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:[email-masked]>>>>
>>>>>>>>>>>>>>> >      >      >      >              >     <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:[email-masked]>>>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>
>>>>>>>>>>>>>>> >     <mailto:[email-masked] <mailto:[email-masked]
>>>>>>>>>>>>>>> >>>>>>
>>>>>>>>>>>>>>> >      >      >      >             wrote:
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >         Hi Greg,
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >         As long as the
>>>>>>>>>>>>>>> inner MAC
>>>>>>>>>>>>>>> >     address is
>>>>>>>>>>>>>>> >      >     such
>>>>>>>>>>>>>>> >      >      >     that the
>>>>>>>>>>>>>>> >      >      >      >             packet is
>>>>>>>>>>>>>>> >      >      >      >              >         trapped to the
>>>>>>>>>>>>>>> CPU, it should be
>>>>>>>>>>>>>>> >      >     fine for
>>>>>>>>>>>>>>> >      >      >     use as
>>>>>>>>>>>>>>> >      >      >      >             an inner MAC is
>>>>>>>>>>>>>>> >      >      >      >              >         it not?
>>>>>>>>>>>>>>> Stating that is
>>>>>>>>>>>>>>> >     better than
>>>>>>>>>>>>>>> >      >     trying to
>>>>>>>>>>>>>>> >      >      >      >             force a management
>>>>>>>>>>>>>>> >      >      >      >              >         VNI. What if
>>>>>>>>>>>>>>> someone wants
>>>>>>>>>>>>>>> >     to test
>>>>>>>>>>>>>>> >      >      >     connectivity
>>>>>>>>>>>>>>> >      >      >      >             on a specific
>>>>>>>>>>>>>>> >      >      >      >              >         VNI? I would
>>>>>>>>>>>>>>> not pick a
>>>>>>>>>>>>>>> >     loopback IP
>>>>>>>>>>>>>>> >      >      >     address for
>>>>>>>>>>>>>>> >      >      >      >             this since that
>>>>>>>>>>>>>>> >      >      >      >              >         address range
>>>>>>>>>>>>>>> is host/node local
>>>>>>>>>>>>>>> >      >     only. Is
>>>>>>>>>>>>>>> >      >      >     there a
>>>>>>>>>>>>>>> >      >      >      >             reason you're
>>>>>>>>>>>>>>> >      >      >      >              >         not using the
>>>>>>>>>>>>>>> VTEP IP as the
>>>>>>>>>>>>>>> >     inner IP
>>>>>>>>>>>>>>> >      >      >     address ?
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >         Dinesh
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >         On Wed, Jul
>>>>>>>>>>>>>>> 31, 2019 at 5:48 AM
>>>>>>>>>>>>>>> >      >     Greg Mirsky
>>>>>>>>>>>>>>> >      >      >      >              >         <
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]> <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>>
>>>>>>>>>>>>>>> >      >      >      >             <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>>> <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]> <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>>
>>>>>>>>>>>>>>> >      >      >      >             <mailto:
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked] <mailto:
>>>>>>>>>>>>>>> [email-masked]>>
>>>>>>>>>>>>>>> >      >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>
>>>>>>>>>>>>>>> >      >     <mailto:[email-masked]
>>>>>>>>>>>>>>> >     <mailto:[email-masked]>>>>>> wrote:
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >             Dear All,
>>>>>>>>>>>>>>> >      >      >      >              >             thank you
>>>>>>>>>>>>>>> for your comments,
>>>>>>>>>>>>>>> >      >      >     suggestions on
>>>>>>>>>>>>>>> >      >      >      >             this issue,
>>>>>>>>>>>>>>> >      >      >      >              >             probably
>>>>>>>>>>>>>>> the most
>>>>>>>>>>>>>>> >     challenging
>>>>>>>>>>>>>>> >      >     for this
>>>>>>>>>>>>>>> >      >      >      >             specification. In the
>>>>>>>>>>>>>>> >      >      >      >              >             course of
>>>>>>>>>>>>>>> our discussions,
>>>>>>>>>>>>>>> >      >     we've agreed to
>>>>>>>>>>>>>>> >      >      >      >             abandon the
>>>>>>>>>>>>>>> >      >      >      >              >             request to
>>>>>>>>>>>>>>> allocate the
>>>>>>>>>>>>>>> >      >     dedicated MAC
>>>>>>>>>>>>>>> >      >      >     address
>>>>>>>>>>>>>>> >      >      >      >             to be used as
>>>>>>>>>>>>>>> >      >      >      >              >             the
>>>>>>>>>>>>>>> destination MAC
>>>>>>>>>>>>>>> >     address in
>>>>>>>>>>>>>>> >      >     the inner
>>>>>>>>>>>>>>> >      >      >      >             Ethernet frame.
>>>>>>>>>>>>>>> >      >      >      >              >             Also,
>>>>>>>>>>>>>>> earlier using VNI
>>>>>>>>>>>>>>> >     0 was
>>>>>>>>>>>>>>> >      >     changed from
>>>>>>>>>>>>>>> >      >      >      >             mandatory to one
>>>>>>>>>>>>>>> >      >      >      >              >             of the
>>>>>>>>>>>>>>> options an
>>>>>>>>>>>>>>> >      >     implementation may
>>>>>>>>>>>>>>> >      >      >     offer to
>>>>>>>>>>>>>>> >      >      >      >             an operator.
>>>>>>>>>>>>>>> >      >      >      >              >             The most
>>>>>>>>>>>>>>> recent
>>>>>>>>>>>>>>> >     discussion was
>>>>>>>>>>>>>>> >      >     whether
>>>>>>>>>>>>>>> >      >      >     VTEP's
>>>>>>>>>>>>>>> >      >      >      >             MAC address
>>>>>>>>>>>>>>> >      >      >      >              >             might be
>>>>>>>>>>>>>>> used as the
>>>>>>>>>>>>>>> >      >     destination MAC
>>>>>>>>>>>>>>> >      >      >     address
>>>>>>>>>>>>>>> >      >      >      >             in the inner
>>>>>>>>>>>>>>> >      >      >      >              >             Ethernet
>>>>>>>>>>>>>>> frame. As I
>>>>>>>>>>>>>>> >     recall it, the
>>>>>>>>>>>>>>> >      >      >     comments
>>>>>>>>>>>>>>> >      >      >      >             from VXLAN
>>>>>>>>>>>>>>> >      >      >      >              >             experts
>>>>>>>>>>>>>>> equally split
>>>>>>>>>>>>>>> >     with one
>>>>>>>>>>>>>>> >      >     for it
>>>>>>>>>>>>>>> >      >      >     and one
>>>>>>>>>>>>>>> >      >      >      >             against. Hence
>>>>>>>>>>>>>>> >      >      >      >              >             I would
>>>>>>>>>>>>>>> like to propose
>>>>>>>>>>>>>>> >     a new
>>>>>>>>>>>>>>> >      >     text to
>>>>>>>>>>>>>>> >      >      >     resolve
>>>>>>>>>>>>>>> >      >      >      >             the issue. The
>>>>>>>>>>>>>>> >      >      >      >              >             idea is to
>>>>>>>>>>>>>>> let an
>>>>>>>>>>>>>>> >     operator select
>>>>>>>>>>>>>>> >      >      >     Management
>>>>>>>>>>>>>>> >      >      >      >             VNI and use
>>>>>>>>>>>>>>> >      >      >      >              >             that VNI
>>>>>>>>>>>>>>> in VXLAN
>>>>>>>>>>>>>>> >     encapsulation
>>>>>>>>>>>>>>> >      >     of BFD
>>>>>>>>>>>>>>> >      >      >      >             Control packets:
>>>>>>>>>>>>>>> >      >      >      >              >             NEW TEXT:
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >                 An
>>>>>>>>>>>>>>> operator MUST
>>>>>>>>>>>>>>> >     select a VNI
>>>>>>>>>>>>>>> >      >      >     number to
>>>>>>>>>>>>>>> >      >      >      >             be used as
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>>  Management VNI. VXLAN
>>>>>>>>>>>>>>> >      >     packet for
>>>>>>>>>>>>>>> >      >      >      >             Management VNI MUST NOT
>>>>>>>>>>>>>>> >      >      >      >              >                 be
>>>>>>>>>>>>>>> sent to a tenant. VNI
>>>>>>>>>>>>>>> >      >     number 1 is
>>>>>>>>>>>>>>> >      >      >      >             RECOMMENDED as the
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>>  default for
>>>>>>>>>>>>>>> >     Management VNI.
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >             With that
>>>>>>>>>>>>>>> new text, what
>>>>>>>>>>>>>>> >     can be the
>>>>>>>>>>>>>>> >      >      >     value of
>>>>>>>>>>>>>>> >      >      >      >             the destination
>>>>>>>>>>>>>>> >      >      >      >              >             MAC in the
>>>>>>>>>>>>>>> inner Ethernet? I
>>>>>>>>>>>>>>> >      >     tend to
>>>>>>>>>>>>>>> >      >      >     believe
>>>>>>>>>>>>>>> >      >      >      >             that it can be
>>>>>>>>>>>>>>> >      >      >      >              >             anything
>>>>>>>>>>>>>>> and ignored by the
>>>>>>>>>>>>>>> >      >     reciever VTEP.
>>>>>>>>>>>>>>> >      >      >      >             Also, if the
>>>>>>>>>>>>>>> >      >      >      >              >             trapping
>>>>>>>>>>>>>>> is based on VNI
>>>>>>>>>>>>>>> >      >     number, the
>>>>>>>>>>>>>>> >      >      >      >             destination IP address
>>>>>>>>>>>>>>> >      >      >      >              >             of the
>>>>>>>>>>>>>>> inner IP packet
>>>>>>>>>>>>>>> >     can from
>>>>>>>>>>>>>>> >      >     the range
>>>>>>>>>>>>>>> >      >      >      >             127/8 for IPv4,
>>>>>>>>>>>>>>> >      >      >      >              >             and for
>>>>>>>>>>>>>>> IPv6 from the range
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>>  0:0:0:0:0:FFFF:7F00:0/104. And
>>>>>>>>>>>>>>> >      >      >      >              >             lastly,
>>>>>>>>>>>>>>> the TTL to be
>>>>>>>>>>>>>>> >     set to 1 (no
>>>>>>>>>>>>>>> >      >      >     change here).
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >             Much
>>>>>>>>>>>>>>> appreciate your
>>>>>>>>>>>>>>> >     comments,
>>>>>>>>>>>>>>> >      >      >     questions, and
>>>>>>>>>>>>>>> >      >      >      >             suggestions.
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >              >             Best
>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>> >      >      >      >              >             Greg
>>>>>>>>>>>>>>> >      >      >      >              >
>>>>>>>>>>>>>>> >      >      >      >
>>>>>>>>>>>>>>> >      >      >
>>>>>>>>>>>>>>> >      >
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>

---

From: Santosh P K <[email-masked]>
Date: Thu, 3 Oct 2019 19:50:50 +0530

Joel,
    Sure based on how the discussion goes will modify or keep the document
as it is.

Thanks
Santosh P K

On Wed, Sep 25, 2019 at 8:29 AM Joel M. Halpern <[email-masked]> wrote:

> As far as I can tell, the current document we have in front of us is
> explicit that the messages are originated and terminated at the VNI.  If
> you want some other behavior, then we need a document that describes
> that behaviors.
>
> Yours,
> Joel
>
> On 9/24/2019 10:39 PM, [email-masked] 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.
> >
> > 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
> > "Note that two different Tenant Systems (and TSIs) attached to a common
> NVE can share a VAP (e.g., TS1 and TS2 in Figure 2) so long as they connect
> to the same Virtual Network."
> >
> > should merge into one VAP and my explanation doesn't work. Copying to
> > NVO3 WG to involve more experts, hope for your clarifications and
> comments.
> >
> >
> > Best Regards,
> >
> > Xiao Min
> >
> > 原始邮件
> > *抄送人：[email-masked]
> > <[email-masked]>;Dinesh Dutt <[email-masked]>;rtg-bfd
> > WG <[email-masked]>;Joel M. Halpern <[email-masked]>;T. Sridhar
> > <[email-masked]>;[email-masked] <[email-masked]>;
> > *日 期 ：*2019年09月23日 05:39
> > <mailto:[email-masked]>> wrote:
> >
> >     Hi Santosh,
> >     thank you for your comments. Please find my notes in-lined and
> >     tagged GIM>>.
> >
> >     Regards,
> >     Greg
> >
> >     On Tue, Aug 13, 2019 at 10:24 PM Santosh P K
> >     <[email-masked] <mailto:[email-masked]>>
> >     wrote:
> >
> >         Greg,
> >             Thanks for updated version of document. Here are few
> >         comments on new draft.
> >
> >         Section 4:
> >         I think we may need to give background on why we are saying MAC
> >         address MUST not be one of tenant's MAC address. Like in this
> >         thread we have discussed one of the tenant could have borrowed
> >         the same VTEP mac address and we if we have to use BFD then we
> >         need to avoid that conflict to ensure BFD packets get observed
> >         in the VTEP itself. Should we add a section before 4 to set that
> >         context so that above text makes more sense in that context?
> >
> > [SPK]  Proposed text for why we should not use VTEP MAX address as
> > tenant MAC address.
> >
> > "In some scenarios tenant MAC is borrowed from VTEP MAC address. VXLAN
> > BFD MUST terminate BFD session at VTEP and MUST not forward BFD packets
> > to tenants. To terminate VXLAN BFD packets at VTEP, deployment MUST
> > ensure that there are no tenant VM which barrows VTEP MAC address."
> >
> >
> >
> >             IP header:
> >         I think we have added some text to address Sridhar comments on
> >         why TTL MUST be 1 and dest IP address MUST be 127/8 range. I see
> >         that text is missing now.
> >
> >         Just with 3 tuple we will not be able to demux packet. We need
> >         to consider VNI as well if we have multiple BFD session between
> >         same pair of VTEP.
> >
> > that do we really need that? As per RFC 5884 we are running BFD per LSP
> > and we might hit scale issues there too. I think it is up to operator to
> > decide how they want to use multiple BFD session per VXLAN tunnel. It
> > could be possible that BFD session with special VNI is run at aggressive
> > interval where as MAY have multiple BFD sessions for different VNI at a
> > sedate interval, for that matter they could be running in demand mode as
> > well (run P/F sequence only when there is no data following for that
> > VNI). As WG if we think running multiple BFD session make sense then we
> > might need to add appropriate text.
> >
> >     If the goal is to monitor per VNI, then the following text should
> >     describe the demultiplexing of the initial BFD Control packet:
> > VTEPs for multiple VNI makes sense only if as WG we think that could be
> > use case.
> >
> >         On Fri, Aug 9, 2019 at 4:27 AM Greg Mirsky
> >         <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >             could you please check if the updated text on the inner
> >             Ethernet frame addressed your concern.
> >
> >             On Wed, Aug 7, 2019 at 2:25 PM Dinesh Dutt <[email-masked]
> >             <mailto:[email-masked]>> wrote:
> >
> >                 On Wed, Aug 7, 2019 at 9:25 AM Greg Mirsky
> >                 <[email-masked] <mailto:[email-masked]>>
> >                 wrote:
> >
> >                     much appreciate the help you've given me sharing
> >                     your expertise. I hope that the updates you will
> >                     find in the attached diff and the working copy of
> >                     the draft be closer to the acceptable solution for
> >                     VTEP-VTEP BFD. Please note, that I'll shortly start
> >                     a new discussion thread to address one of Carlos's
> >                     questions on the ambiguity of the text on multiple
> >                     concurrent sessions between the same pair of VTEPs.
> >                     Please review the changes to Sections 4 and 6 and
> >                     share your feedback, suggestions, and questions.
> >
> >                     Regards,
> >                     Greg
> >
> >                     On Mon, Aug 5, 2019 at 6:03 PM Dinesh Dutt
> >                     <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >
> >
> >                         On Mon, Aug 5, 2019 at 5:56 PM Greg Mirsky
> >                         <[email-masked]
> >                         <mailto:[email-masked]>> wrote:
> >
> >                             Hi Dinesh,
> >                             I believe that the ability to run BFD
> >                             session up to a tenant (VTEP-VTEP-tenant or
> >                             tenant-tenant) was never in jeopardy from
> >                             this specification.
> >                             I'm trying to provide precise specification
> >                             on what can be used ad the destination MAC
> >                             and IP addresses in the inner frame/packet
> >                             as I believe that likely will help to avoid
> >                             interoperability issues.
> >                             I'm interested to learn some more about the
> >                             "martian checking" function. As you know,
> >                             martian addresses have been used as
> >                             destination IP address in LSP Ping and BFD
> >                             over MPLS LSP and PW. I haven't heard that
> >                             any silicon feature caused problems for
> >                             operators using these tools.
> >
> >
> >                         Interesting. I didn't know this aspect of use
> >                         with MPLS ping. Did those packets ever go
> >                         through a firewall though? In any case, maybe
> >                         suggest the use of those addresses with a
> >                         statement that this is how LSP does it, but that
> >                         other MAC/IP pairs are possible as long as the
> >                         conditions of the endpoint owning the MAC/IP was
> >                         honored.
> >
> >                         Dinesh
> >
> >
> >                             Regards,
> >                             Greg
> >
> >                             On Mon, Aug 5, 2019 at 3:59 PM Dinesh Dutt
> >                             <[email-masked] <mailto:[email-masked]>>
> >                             wrote:
> >
> >                                 Hi Greg,
> >
> >                                 That we agree on the problem definition
> >                                 is the first step forward. Your original
> >                                 document had my cases covered and so I
> >                                 was surprised by the track this thread
> >                                 took. It doesn't matter, we're back on
> >                                 track.
> >
> >                                 My recommendation is to not worry about
> >                                 specifying the precise MAC/IP address
> >                                 used in the inner header. The addresses
> >                                 chosen MUST ensure that the packet is
> >                                 trapped to the control plane of the VTEP
> >                                 and not escape to the tenant if the BFD
> >                                 is to the VTEP. Any solution MUST also
> >                                 not preclude the use of the BFD by
> >                                 tenant systems for that VNI. There are
> >                                 many ways an implementer can choose to
> >                                 implement this. For example, the inner
> >                                 MAC address is whatever the VTEP
> >                                 implementer would return if ARP'd for
> >                                 the IP address used in the inner header
> >                                 in the given VNI. The implementer can
> >                                 pick a fixed MAC address, one that they
> >                                 own etc. Multiple BFD sessions can be
> >                                 run for testing path connectivity on
> >                                 more than one VNIs. Limits should be in
> >                                 place to avoid overwhelming the receiver
> >                                 with BFD messages (you had words about
> >                                 this in your currently published
> >                                 draft).  If the VNI is irrelevant in the
> >                                 test i.e. only the VXLAN pipe at the
> >                                 VTEP is being tested. the user can use
> >                                 any VNI active on the VTEP on which the
> >                                 VTEP owns an IP address.
> >
> >                                 I'm concerned about the use of 127/8
> >                                 address only because of firewalls or
> >                                 implementations that drop packets with
> >                                 these addresses as either the source or
> >                                 destination. For example, on many
> >                                 merchant silicon, I don't believe you
> >                                 can turn off martian checking and drops
> >                                 *only* for VXLAN-encapsulated BFD
> >                                 packets. I don't know what the Linux
> >                                 kernel does today on such packets, for
> >                                 example (or Hyper-V). I'd like a
> >                                 solution that doesn't demand additional
> >                                 or new chip functionality or require
> >                                 additional middle-box hole punch.
> >
> >                                 Why do you feel you MUST to specify the
> >                                 MAC/IP address on the inner packet? What
> >                                 am I missing here?
> >
> >                                 Dinesh
> >
> >                                 On Mon, Aug 5, 2019 at 3:04 PM Greg
> >                                 Mirsky <[email-masked]
> >                                 <mailto:[email-masked]>> wrote:
> >
> >                                     Hi Dinesh,
> >                                     what do you see as the way forward?
> >                                     I agree, that the proposed text
> >                                     doesn't work for multi-VNI
> >                                     concurrent monitoring because these
> >                                     VNIs are tenant's VNIs. And in that
> >                                     case, we need to specify another
> >                                     mechanism to trap the BFD Control
> >                                     packet at VTEP. It seems that VTEP's
> >                                     Ethernet address must be used as the
> >                                     destination MAC address in the inner
> >                                     Ethernet frame. The destination IP
> >                                     address may be either VTEP's address
> >                                     of martian (I do prefer martian).
> >                                     Let me give it  try:
> >                                     NEW TEXT:
> >
> >                                         To monitor continuity of the
> >                                         path between two VTEPs, an
> >                                         operator MUST select a VNI
> >                                         number to be used as Management
> >                                         VNI. Management VNI number MUST
> >                                         NOT be one of the tenant's VNIs
> >                                         to prevent sending VXLAN packets
> >                                         received on Management VNI to a
> >                                         tenant. VNI number 1 is
> >                                         RECOMMENDED as the default for
> >                                         Management VNI. [Ed.note: What
> >                                         we set the Destination MAC to?
> >                                         Can it be invalid MAC that MUST
> >                                         be ignored on receipt?]
> >
> >                                         If an implementation supports
> >                                         concurrent monitoring of
> >                                         multiple VNIs, then the value of
> >                                         VNI number MAY be one of
> >                                         tenant's VNIs. The destination
> >                                         MAC address in the inner
> >                                         Ethernet frame encapsulating BFD
> >                                         selected from the range 127/8
> >                                         for IPv4, and for IPv6 from the
> >                                         range 0:0:0:0:0:FFFF:7F00:0/104.
> >                                         The TTL value in the inner IP
> >                                         header MUST be set to 1.
> >
> >                                     Regards,
> >                                     Greg
> >
> >                                     On Sun, Aug 4, 2019 at 9:07 AM
> >                                     Dinesh Dutt <[email-masked]
> >                                     <mailto:[email-masked]>> wrote:
> >
> >                                         Hi Greg,
> >
> >                                         why you're running BFD over
> >                                         VXLAN between VTEPs. I wasn't
> >                                         arguing against it at all. All I
> >                                         was saying was pointing to the
> >                                         limitations of the use of
> >                                         management VNI. I spoke to some
> >                                         operators who're running EVPN
> >                                         and mentioned the discussion on
> >                                         this thread. They concur that
> >                                         they're using specific VNIs to
> >                                         test connectivity over that VNI
> >                                         between VTEPs to ensure
> >                                         misconfiguration doesn't lead to
> >                                         blackholes. My statements are
> >                                         based in real world operator
> >                                         experience. And I was providing
> >                                         language that ensured packets
> >                                         didn't leak across to tenants
> >                                         when they were destined to VTEPs.
> >
> >                                         Dinesh
> >
> >                                         On Sat, Aug 3, 2019 at 10:34 AM
> >                                         Greg Mirsky
> >                                         <[email-masked]
> >                                             implementations process
> >                                             VXLAN header and the inner
> >                                             Ethernet frame. These are
> >                                             very helpful in achieving
> >                                             the workable solution for
> >                                             the problem at hand.
> >                                             You've noted that a path
> >                                             between VTEPs may be
> >                                             monitored in the underlay
> >                                             network by merely
> >                                             establishing a BFD session.
> >                                             That is true, but by using
> >                                             BFD with VXLAN encapsulation
> >                                             between the pair of VTEPs we
> >                                             are extending the OAM domain
> >                                             by including, to some
> >                                             extent, VXLAN forwarding
> >                                             engine. Abstract in RFC 5880
> >                                             defines the goal and the
> >                                             domain in which BFD protocol
> >                                             can detect a fault as:
> >                                                 This document describes
> >                                             a protocol intended to
> >                                             detect faults in the
> >                                                 bidirectional path
> >                                             between two forwarding
> >                                             engines, including
> >                                                 interfaces, data
> >                                             link(s), and to the extent
> >                                             possible the forwarding
> >                                                 engines themselves, with
> >                                             Thus, BFD in the underlay
> >                                             will exercise a part of IP
> >                                             forwarding engine while BFD
> >                                             with VXLAN encapsulation,
> >                                             ran between the same pair of
> >                                             VTEPs, extends the OAM
> >                                             domain. At the same time,
> >                                             defining BFD between tenant
> >                                             systems in outside the goal
> >                                             of this specification. But
> >                                             VXLAN BFD session between
> >                                             VTEPs may be useful in
> >                                             monitoring e2e path between
> >                                             tenants, as described in the
> >                                             update to -07:
> >                                                 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].
> >                                             On Fri, Aug 2, 2019 at 5:43
> >                                             PM Dinesh Dutt
> >                                             <[email-masked]
> >                                                 What I mean is "How do
> >                                                 you infer that it
> >                                                 excludes the case I'm
> >                                                 On Fri, Aug 2, 2019 at
> >                                                 5:41 PM Dinesh Dutt
> >                                                 <mailto:[email-masked]
> >                                                     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."
> >
> >                                                     How do you infer
> >                                                     what you said?
> >
> >                                                     Dinesh
> >
> >
> >                                                     On Fri, Aug 2, 2019
> >                                                     at 5:38 PM Joel M.
> >                                                     Halpern
> >                                                     <[email-masked]
> >                                                     <mailto:
> [email-masked]>>
> >                                                     wrote:
> >
> >                                                         I am going by
> >                                                         what the draft
> >                                                         says its purpose
> >                                                         is.  If you
> >                                                         (Dinesh) want
> >                                                         the draft to
> >                                                         fulfill a
> >                                                         different
> >                                                         purpose, then
> >                                                         either ask the
> >                                                         chairs to
> >                                                         take this draft
> >                                                         back to the WG,
> >                                                         or write a
> >                                                         separate draft.
> >                                                         As currently
> >                                                         written, the
> >                                                         behavior Greg
> >                                                         proposed meets
> >                                                         the needs, and
> >                                                         does so in a way
> >                                                         that is
> >                                                         consistent with
> >                                                         VxLAN.
> >
> >                                                         Yours,
> >                                                         Joel
> >
> >                                                         On 8/2/2019 8:30
> >                                                         PM, Dinesh Dutt
> >                                                         wrote:
> >                                                          > What is the
> >                                                         stated purpose
> >                                                         of this BFD
> >                                                         session? The
> >                                                         VTEP
> >                                                         reachability is
> >                                                          > determined by
> >                                                         the underlay, I
> >                                                         don't need
> >                                                         VXLAN-encaped
> >                                                         packet for that.
> >                                                          > Do we agree?
> >                                                          >
> >                                                          > If I want to
> >                                                         test the VXLAN
> >                                                         encap/decap
> >                                                         functionality
> >                                                         alone, picking
> any
> >                                                          > single VNI
> >                                                         maybe fine. But
> >                                                         is this all any
> >                                                         network operator
> >                                                         wants? Why?
> >                                                          > In what
> >                                                         situations has
> >                                                         this been a
> >                                                         problem? I
> >                                                         suspect
> >                                                         operators also
> >                                                          > want to
> >                                                         verify path
> >                                                         continuity over
> >                                                         a specific VNI.
> >                                                         If you say this
> is
> >                                                          > not defined
> >                                                         by the document,
> >                                                         I disagree
> >                                                         because the
> >                                                         current version
> >                                                          > talks about
> >                                                         controlling the
> >                                                         number of BFD
> >                                                         sessions between
> >                                                         the VTEPs
> >                                                          > (see section
> >                                                         3). More
> >                                                         importantly,
> >                                                         this is a real
> >                                                         problem that
> >                                                         operators
> >                                                          > like to
> verify.
> >                                                          >
> >                                                          > Dinesh
> >                                                          >
> >                                                          > On Fri, Aug
> >                                                         2, 2019 at 5:08
> >                                                         PM Joel M.
> >                                                         Halpern
> >                                                         <
> [email-masked]
> >                                                         <mailto:
> [email-masked]>
> >
> >                                                          >
> >                                                         <mailto:
> [email-masked]
> >                                                         <mailto:
> [email-masked]>>>
> >                                                         wrote:
> >                                                          >
> >                                                          >     What is
> >                                                         special about
> >                                                         the management
> >                                                         VNI is precisely
> >                                                         that it is NOT a
> >                                                          >     tenant
> >                                                         VNI.  The VxLAN
> >                                                         administration
> >                                                         does know how it
> >                                                         allocates VNI to
> >                                                          >     tenants,
> >                                                         and which VNI it
> >                                                         has allocated.
> >                                                         In contrast, it
> >                                                         does not know
> >                                                          >     which IP
> >                                                         addresses or MAC
> >                                                         adddresses teh
> >                                                         tenant is using
> >                                                         or may plan
> >                                                          >     to use.
> >                                                          >
> >                                                          >     Yours,
> >                                                          >     Joel
> >                                                          >
> >                                                          >     On
> >                                                         8/2/2019 6:41
> >                                                         PM, Dinesh Dutt
> >                                                         wrote:
> >                                                          >      > The
> >                                                         assumption of an
> >                                                         IP address
> >                                                         within any VNI
> >                                                         is suspect that
> way.
> >                                                          >      > What's
> >                                                         special about a
> >                                                         single VNI, the
> >                                                         management VNI?
> >                                                         The VTEP IP
> >                                                          >      >
> >                                                         address does not
> >                                                         belong in
> >                                                         reality in any
> >                                                         VNI...
> >                                                          >      >
> >                                                          >      > Dinesh
> >                                                          >      >
> >                                                          >      > On
> >                                                         Fri, Aug 2, 2019
> >                                                         at 3:17 PM Joel
> >                                                         M. Halpern
> >                                                          >
> >                                                           <
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                         <mailto:
> [email-masked]
> >                                                         <mailto:
> [email-masked]>
> >                                                         <mailto:
> [email-masked]
> >                                                         <mailto:
> [email-masked]>>>>
> >                                                         wrote:
> >                                                          >      >
> >                                                          >      >
> >                                                           Your response
> >                                                         seems to miss
> >                                                         two points:
> >                                                          >      >
> >                                                          >      >
> >                                                           First, the
> >                                                         problem you
> >                                                         describe is not
> >                                                         what the
> >                                                         document says
> >                                                          >     it is
> >                                                          >      >
> >                                                           solving.  To
> >                                                         the degree it
> >                                                         discusses it at
> >                                                         all, the document
> >                                                          >     says "
> >                                                          >      >
>  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 in
> common. "
> >                                                          >      >
> >                                                          >      >
> >                                                           Second, you
> >                                                         assume the
> >                                                         existence of an
> >                                                         IP address for a
> >                                                         VTEP
> >                                                          >     within a
> >                                                          >      >
> >                                                           VNI.  As with
> >                                                         the MAC address,
> >                                                         the VTEP does
> >                                                         not have an IP
> >                                                          >     address
> >                                                          >      >
> >                                                           within the
> >                                                         VNI.  Some
> >                                                         implementations
> >                                                         may have created
> >                                                         such a
> >                                                          >     thing,
> >                                                          >      >     but
> >                                                          >      >
> >                                                           the general
> >                                                         construct, as
> >                                                         defined to date,
> >                                                         does not support
> >                                                         such.
> >                                                          >      >
> >                                                          >      >     In
> >                                                         short, you are
> >                                                         requiring a
> >                                                         behavior that
> >                                                         violates the
> >                                                          >
>  architectural
> >                                                          >      >
> >                                                           structure of
> >                                                         overlay /
> >                                                         underlay
> >                                                         separation, and
> >                                                         common
> >                                                          >     usage.
> >                                                         And you
> >                                                          >      >
> >                                                           are doing so
> >                                                         to support a use
> >                                                         case that the
> >                                                         working group
> >                                                         has not
> >                                                          >      >
> >                                                           indicated in
> >                                                         the document as
> >                                                         important.
> >                                                          >      >
> >                                                          >      >
>  Yours,
> >                                                          >      >
>  Joel
> >                                                          >      >
> >                                                          >      >     On
> >                                                         8/2/2019 5:01
> >                                                         PM, Dinesh Dutt
> >                                                         wrote:
> >                                                          >      >      >
> >                                                         Joel,
> >                                                          >      >      >
> >                                                          >      >      >
> >                                                         You understood
> >                                                         correctly.
> >                                                          >      >      >
> >                                                          >      >      >
> >                                                         The VNIs may not
> >                                                         share fate due
> >                                                         to
> >
>  misconfiguration. And
> >                                                         I
> >                                                          >     strongly
> >                                                          >      >      >
> >                                                         suspect someone
> >                                                         will want to use
> >                                                         BFD for that
> >                                                         because its
> >                                                          >     about
> >                                                          >      >
> >                                                           checking
> >                                                          >      >      >
> >                                                         path continuity
> >                                                         as stated by the
> >                                                         draft. As long
> >                                                         as there's a
> >                                                          >      >
> >                                                           valid IP
> >                                                          >      >      >
> >                                                         (because it's
> >                                                         BFD) owned by
> >                                                         the VTEP in that
> >                                                         VNI, you can
> >                                                          >     use BFD in
> >                                                          >      >      >
> >                                                         that VNI. Thats
> >                                                         all that you
> >                                                         need to
> >                                                         dictate.  That
> >                                                         IP address
> >                                                          >      >
> >                                                           has a MAC
> >                                                          >      >      >
> >                                                         address and you
> >                                                         can use that on
> >                                                         the inner frame.
> >                                                         That is
> >                                                          >     all normal
> >                                                          >      >      >
> >                                                         VXLAN
> >                                                         processing. The
> >                                                         outer IP is
> >                                                         always that of
> >                                                         the VTEP.
> >                                                          >      >      >
> >                                                          >      >      >
> >                                                         Dinesh
> >                                                          >      >      >
> >                                                          >      >      >
> >                                                         On Fri, Aug 2,
> >                                                         2019 at 11:03 AM
> >                                                         Joel M. Halpern
> >                                                          >      >
> >                                                           <
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >      >
> >                                                         <mailto:
> [email-masked]
> >                                                         <mailto:
> [email-masked]>
> >                                                         <mailto:
> [email-masked]
> >                                                         <mailto:
> [email-masked]>>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>>> wrote:
> >                                                          >      >      >
> >                                                          >      >
> >                                                          >     If I am
> >                                                         reading your
> >                                                         various emails
> >                                                         correctly Dinesh
> >                                                          >     (and I
> >                                                          >      >
> >                                                           may have
> >                                                          >      >
> >                                                          >     missed
> >                                                         something) you
> >                                                         are trying to
> >                                                         use the MAC
> address
> >                                                          >      >
> >                                                           because you
> >                                                          >      >
> >                                                          >     want
> >                                                          >      >
> >                                                          >     to be
> >                                                         able to send
> >                                                         these BFD
> >                                                         packets over
> >                                                         arbitrary VNI to
> >                                                          >      >
> >                                                           monitor the
> >                                                          >      >
> >                                                          >     VNI.
> >                                                         That is not a
> >                                                         requirement
> >                                                         identified in the
> >                                                          >     document.
> >                                                          >      >     It
> >                                                         is not
> >                                                          >      >
> >                                                          >     even a
> >                                                         problem I
> >                                                         understand,
> >                                                         since all the
> >                                                         VNI between an
> >                                                          >      >
> >                                                           ingress and
> >                                                          >      >
> >                                                          >     egress
> >                                                         VTEP share fate.
> >                                                          >      >      >
> >                                                          >      >
> >                                                          >     Yours,
> >                                                          >      >
> >                                                          >     Joel
> >                                                          >      >      >
> >                                                          >      >
> >                                                          >     On
> >                                                         8/2/2019 1:44
> >                                                         PM, Dinesh Dutt
> >                                                         wrote:
> >                                                          >      >
> >                                                          >      > Thanks
> >                                                         for verifying
> >                                                         this. On Linux
> >                                                         and hardware
> >                                                          >     routers
> >                                                          >      >
> >                                                           that I'm
> >                                                          >      >
> >                                                          >     aware
> >                                                          >      >
> >                                                          >      > of
> >                                                         (Cisco circa
> >                                                         2012 and
> >                                                         Cumulus), the
> >                                                         physical MAC
> >                                                          >     address is
> >                                                          >      >
> >                                                          >     reused
> >                                                          >      >
> >                                                          >      > across
> >                                                         the VNIs on the
> >                                                         VTEP. Did you
> >                                                         check on a
> non-VMW
> >                                                          >      >
> >                                                           device?
> >                                                          >      >
> >                                                          >     This is
> >                                                          >      >
> >                                                          >      > more
> >                                                         for my own
> >                                                         curiosity.
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      > To
> >                                                         address the
> >                                                         general case,
> >                                                         can we not
> define a
> >                                                          >      >
> >                                                           well-known (or
> >                                                          >      >
> >                                                          >     reserve
> >                                                          >      >
> >                                                          >      > one)
> >                                                         unicast MAC
> >                                                         address for use
> >                                                         with VTEP? If
> >                                                         the MAC
> >                                                          >      >
> >                                                           address is
> >                                                          >      >
> >                                                          >      >
> >                                                         configurable in
> >                                                         BFD command,
> >                                                         this can be moot.
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      > Dinesh
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      > On
> >                                                         Fri, Aug 2, 2019
> >                                                         at 10:27 AM
> >                                                         Santosh P K
> >                                                          >      >
> >                                                          >      >
> >                                                         <
> [email-masked]
> >                                                         <mailto:
> [email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> santosh.pallagatti@gmail...com <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> santosh.pallagatti@gmail...com <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> santosh.pallagatti@gmail...com <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> santosh.pallagatti@gmail...com <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>>>>
> wrote:
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >     I
> >                                                         have cross
> >                                                         checked point
> >                                                         raised about MAC
> >                                                         address
> >                                                          >      >
> >                                                           usage. It is
> >                                                          >      >
> >                                                          >      >
> >                                                           possible that
> >                                                         tenant could be
> >                                                         using physical
> MAC
> >                                                          >      >
> >                                                           address and
> >                                                          >      >
> >                                                          >     when a
> >                                                          >      >
> >                                                          >      >
> >                                                           packet comes
> >                                                         with valid VNI
> >                                                         with a MAC
> address
> >                                                          >     that is
> >                                                          >      >
>  being
> >                                                          >      >
> >                                                          >     used by
> >                                                          >      >
> >                                                          >      >
> >                                                           tenant then
> >                                                         packet will be
> >                                                         sent to that
> tenant.
> >                                                          >     This rules
> >                                                          >      >
> >                                                          >     out the
> >                                                          >      >
> >                                                          >      >
> >                                                           fact that we
> >                                                         could use
> >                                                         physical MAC
> >                                                         address as
> >                                                          >     inner
> >                                                          >      >
>  MAC to
> >                                                          >      >
> >                                                          >     ensure
> >                                                          >      >
> >                                                          >      >
> >                                                           packets get
> >                                                         terminated at
> >                                                         VTEP itself.
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
>  Thanks
> >                                                          >      >
> >                                                          >      >
> >                                                           Santosh P K
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >     On
> >                                                         Wed, Jul 31,
> >                                                         2019 at 11:00 AM
> >                                                         Santosh P K
> >                                                          >      >
> >                                                          >      >
> >                                                           <
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> santosh.pallagatti@gmail...com <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> santosh.pallagatti@gmail...com <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> santosh.pallagatti@gmail...com <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> santosh.pallagatti@gmail...com <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>>>>
> >                                                          >      >
> >                                                          >      >
>  wrote:
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                           Joel,
> >                                                          >      >
> >                                                          >      >
> >                                                               Thanks for
> >                                                         your inputs. I
> >                                                         checked
> >                                                          >      >
> >                                                           implementation
> >                                                         within
> >                                                          >      >
> >                                                          >      >
> >                                                           Vmware.
> >                                                         Perhaps I should
> >                                                         have been more
> clear
> >                                                          >      >
> >                                                           about MAC
> >                                                          >      >
> >                                                          >     address
> >                                                          >      >
> >                                                          >      >
> >                                                           space while
> >                                                         checking
> >                                                         internally. I
> >                                                         will cross
> >                                                          >      >
> >                                                           check again for
> >                                                          >      >
> >                                                          >      >
> >                                                           the same and
> >                                                         get back on this
> >                                                         list.
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                           Thanks
> >                                                          >      >
> >                                                          >      >
> >                                                           Santosh P K
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                           On Wed, Jul
> >                                                         31, 2019 at
> >                                                         10:54 AM Joel M.
> >                                                          >     Halpern
> >                                                          >      >
> >                                                          >      >
> >                                                           <
> [email-masked] <mailto:jmh@joelhalpern...com>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>> <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>> <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>>>> wrote:
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                               Sorry to
> >                                                         ask a stupid
> >                                                         question.  Whose
> >                                                          >      >
> >                                                           implementation?
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                               The reason
> >                                                         I ask is that as
> >                                                         far as I
> >                                                          >     can tell,
> >                                                          >      >
> >                                                           since the
> >                                                          >      >
> >                                                          >      >
> >                                                               tenant
> >                                                         does not
> >                                                          >      >
> >                                                          >      >
> >                                                               have any
> >                                                         control access
> >                                                         to the VTEP,
> >                                                          >     there is
> no
> >                                                          >      >
> >                                                          >     reason for
> >                                                          >      >
> >                                                          >      >
> >                                                               the VTEP to
> >                                                          >      >
> >                                                          >      >
> >                                                               have a MAC
> >                                                         address in the
> >                                                         tenant
> >                                                          >     space.
> >                                                         Yes, the
> >                                                          >      >
> >                                                          >     device has
> >                                                          >      >
> >                                                          >      >
> >                                                               a physical
> >                                                          >      >
> >                                                          >      >
> >                                                               MAC
> >                                                         address.  But
> >                                                         the tenant could
> >                                                         well be
> >                                                          >      >
> >                                                           using that MAC
> >                                                          >      >
> >                                                          >      >
> >                                                               address.
> Yes,
> >                                                          >      >
> >                                                          >      >
> >                                                               they would
> >                                                         be violating the
> >                                                         Ethernet spec.
> >                                                          >      >
> >                                                           But the whole
> >                                                          >      >
> >                                                          >      >
> >                                                               point of
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           segregation is
> >                                                         not to care
> >                                                         about such
> >                                                          >     issues.
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                               On the
> >                                                         other hand, if
> >                                                         you tell me that
> >                                                          >     the VMWare
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           implementation
> >                                                         has an
> >                                                          >      >
> >                                                          >      >
> >                                                               Ethernet
> >                                                         address that is
> >                                                         part of the
> tenant
> >                                                          >      >
> >                                                           space, well,
> >                                                          >      >
> >                                                          >      >
> >                                                               they made
> up
> >                                                          >      >
> >                                                          >      >
> >                                                               this
> >                                                         particular game.
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                               Yours,
> >                                                          >      >
> >                                                          >      >
> >                                                               Joel
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                          >      >
> >                                                               On
> >                                                         7/31/2019 1:44
> >                                                         PM, Santosh P K
> >                                                         wrote:
> >                                                          >      >
> >                                                          >      >
> >                                                                > I have
> >                                                         checked with
> >                                                         implementation
> >                                                          >     in data
> >                                                          >      >
>  path.
> >                                                          >      >
> >                                                          >     When we
> >                                                          >      >
> >                                                          >      >
> >                                                               receive a
> >                                                          >      >
> >                                                          >      >
> >                                                                > packet
> >                                                         with valid VNI
> >                                                         then lookup
> >                                                          >     for MAC
> will
> >                                                          >      >
> >                                                          >     happen and
> >                                                          >      >
> >                                                          >      >
> >                                                               it is VTEP
> own
> >                                                          >      >
> >                                                          >      >
> >                                                                > MAC
> >                                                         then it will be
> >                                                         trapped to
> control
> >                                                          >      >
> >                                                           plane for
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           processing. I
> >                                                         think we
> >                                                          >      >
> >                                                          >      >
> >                                                                > can
> >                                                         have following
> >                                                         options
> >                                                          >      >
> >                                                          >      >
> >                                                                > 1.
> >                                                         Optional
> >                                                         managment VNI
> >                                                          >      >
> >                                                          >      >
> >                                                                > 2.
> >                                                         Mandatory inner
> >                                                         MAC set to VTEP
> mac
> >                                                          >      >
> >                                                          >      >
> >                                                                > 3.
> >                                                         Inner IP TTL set
> >                                                         to 1 to avoid
> >                                                          >      >
> >                                                           forwarding of
> >                                                         packet
> >                                                          >      >
> >                                                          >      >
> >                                                               via inner
> IP
> >                                                          >      >
> >                                                          >      >
> >                                                                > address.
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> Thoughts?
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                > Thansk
> >                                                          >      >
> >                                                          >      >
> >                                                                > Santosh
> P K
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                > On Wed,
> >                                                         Jul 31, 2019 at
> >                                                         9:20 AM Greg
> >                                                          >     Mirsky
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           <
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>> <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>>>
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                         <mailto:
> [email-masked]
> >                                                         <mailto:
> [email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>> <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>>
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>>>>> wrote:
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                >     Hi
> >                                                         Dinesh,
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           thank you for
> >                                                         your
> consideration
> >                                                          >     of the
> >                                                          >      >
> >                                                          >     proposal
> and
> >                                                          >      >
> >                                                          >      >
> >                                                               questions.
> >                                                         What
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           would you see
> >                                                         as the scope of
> >                                                          >     testing
> the
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           connectivity
> >                                                         for the
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           specific VNI?
> >                                                         If it is
> >                                                          >      >
> >
>  tenant-to-tenant, then
> >                                                          >      >
> >                                                          >     VTEPs
> >                                                          >      >
> >                                                          >      >
> >                                                               will treat
> >                                                         these
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           packets as
> >                                                         regular user
> >                                                         frames. More
> >                                                          >      >
> >                                                           likely, these
> >                                                          >      >
> >                                                          >      >
> >                                                               could be
> >                                                         Layer 2
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           OAM, e.g. CCM
> >                                                         frames. The
> reason
> >                                                          >     to use
> >                                                          >      >
> >                                                           127/8 for
> >                                                          >      >
> >                                                          >      >
> >                                                               IPv4, and
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >
> >                                                          >      >     to
> >                                                         safeguard
> >                                                               from
> leaking
> >                                                         frames with BFD
> >                                                         Control
> >                                                          >      >     to
> a
> >                                                           You've
> >                                                         suggested using
> >                                                         a MAC
> >                                                               control
> >                                                         packet at
> >                                                           VTEP. What
> >                                                         that address
> >                                                         could be? We
> >                                                         and VTEP's MAC
> and
> >                                                           experts. The
> >                                                         idea of using
> >                                                          >      >     of
> >                                                         using
> >                                                         VLAN.
> >                                                                >     On
> >                                                         Wed, Jul 31,
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>>>
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>>>>>
> >                                                          >      >
> >                                                          >      >
> >                                                               wrote:
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           Hi Greg,
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           As long as the
> >                                                         inner MAC
> >                                                          >     address is
> >                                                          >      >
>  such
> >                                                          >      >
> >                                                          >     that the
> >                                                          >      >
> >                                                          >      >
> >                                                               packet is
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           trapped to the
> >                                                         CPU, it should be
> >                                                          >      >
> >                                                           fine for
> >                                                          >      >
> >                                                          >     use as
> >                                                          >      >
> >                                                          >      >
> >                                                               an inner
> >                                                         MAC is
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           it not?
> >                                                         Stating that is
> >                                                          >     better
> than
> >                                                          >      >
> >                                                           trying to
> >                                                          >      >
> >                                                          >      >
> >                                                               force a
> >                                                         management
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           VNI. What if
> >                                                         someone wants
> >                                                          >     to test
> >                                                          >      >
> >                                                          >
>  connectivity
> >                                                          >      >
> >                                                          >      >
> >                                                               on a
> specific
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           VNI? I would
> >                                                         not pick a
> >                                                          >     loopback
> IP
> >                                                          >      >
> >                                                          >     address
> for
> >                                                          >      >
> >                                                          >      >
> >                                                               this since
> >                                                         that
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           address range
> >                                                         is host/node
> local
> >                                                          >      >
> >                                                           only. Is
> >                                                          >      >
> >                                                          >     there a
> >                                                          >      >
> >                                                          >      >
> >                                                               reason
> you're
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           not using the
> >                                                         VTEP IP as the
> >                                                          >     inner IP
> >                                                          >      >
> >                                                          >     address ?
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           Dinesh
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           On Wed, Jul
> >                                                         31, 2019 at 5:48
> AM
> >                                                          >      >
> >                                                           Greg Mirsky
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                           <
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>> <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>>
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>>> <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>> <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>>
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >                                                          >      >
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>
> >                                                          >      >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>
> >                                                          >
> >                                                           <mailto:
> [email-masked] <mailto:[email-masked]>>>>>>> wrote:
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               Dear All,
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               thank you
> >                                                         for your
> comments,
> >                                                          >      >
> >                                                          >
> >                                                           suggestions on
> >                                                          >      >
> >                                                          >      >
> >                                                               this issue,
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               probably
> >                                                         the most
> >                                                          >
>  challenging
> >                                                          >      >
> >                                                           for this
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           specification.
> >                                                         In the
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               course of
> >                                                         our discussions,
> >                                                          >      >
> >                                                           we've agreed to
> >                                                          >      >
> >                                                          >      >
> >                                                               abandon the
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               request to
> >                                                         allocate the
> >                                                          >      >
> >                                                           dedicated MAC
> >                                                          >      >
> >                                                          >     address
> >                                                          >      >
> >                                                          >      >
> >                                                               to be used
> as
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               the
> >                                                         destination MAC
> >                                                          >     address in
> >                                                          >      >
> >                                                           the inner
> >                                                          >      >
> >                                                          >      >
> >                                                               Ethernet
> >                                                         frame.
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               Also,
> >                                                         earlier using VNI
> >                                                          >     0 was
> >                                                          >      >
> >                                                           changed from
> >                                                          >      >
> >                                                          >      >
> >                                                               mandatory
> >                                                         to one
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               of the
> >                                                         options an
> >                                                          >      >
> >                                                           implementation
> may
> >                                                          >      >
> >                                                          >     offer to
> >                                                          >      >
> >                                                          >      >
> >                                                               an
> operator.
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               The most
> >                                                         recent
> >                                                          >
> >                                                           discussion was
> >                                                          >      >
> >                                                           whether
> >                                                          >      >
> >                                                          >     VTEP's
> >                                                          >      >
> >                                                          >      >
> >                                                               MAC address
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               might be
> >                                                         used as the
> >                                                          >      >
> >                                                           destination MAC
> >                                                          >      >
> >                                                          >     address
> >                                                          >      >
> >                                                          >      >
> >                                                               in the
> inner
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               Ethernet
> >                                                         frame. As I
> >                                                          >     recall
> >                                                         it, the
> >                                                          >      >
> >                                                          >     comments
> >                                                          >      >
> >                                                          >      >
> >                                                               from VXLAN
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               experts
> >                                                         equally split
> >                                                          >     with one
> >                                                          >      >
>  for it
> >                                                          >      >
> >                                                          >     and one
> >                                                          >      >
> >                                                          >      >
> >                                                               against.
> Hence
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               I would
> >                                                         like to propose
> >                                                          >     a new
> >                                                          >      >
> >                                                           text to
> >                                                          >      >
> >                                                          >     resolve
> >                                                          >      >
> >                                                          >      >
> >                                                               the issue.
> The
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               idea is to
> >                                                         let an
> >                                                          >     operator
> >                                                         select
> >                                                          >      >
> >                                                          >     Management
> >                                                          >      >
> >                                                          >      >
> >                                                               VNI and use
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               that VNI
> >                                                         in VXLAN
> >                                                          >
>  encapsulation
> >                                                          >      >     of
> BFD
> >                                                          >      >
> >                                                          >      >
> >                                                               Control
> >                                                         packets:
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               NEW TEXT:
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                                   An
> >                                                         operator MUST
> >                                                          >     select a
> VNI
> >                                                          >      >
> >                                                          >     number to
> >                                                          >      >
> >                                                          >      >
> >                                                               be used as
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >
> >                                                           Management
> >                                                         VNI. VXLAN
> >                                                          >      >
> >                                                           packet for
> >                                                          >      >
> >                                                          >      >
> >                                                               Management
> >                                                         VNI MUST NOT
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                                   be
> >                                                         sent to a
> >                                                         tenant. VNI
> >                                                          >      >
> >                                                           number 1 is
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           RECOMMENDED as
> the
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >
> >                                                           default for
> >                                                          >
> >                                                           Management VNI.
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               With that
> >                                                         new text, what
> >                                                          >     can be the
> >                                                          >      >
> >                                                          >     value of
> >                                                          >      >
> >                                                          >      >
> >                                                               the
> >                                                         destination
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               MAC in the
> >                                                         inner Ethernet? I
> >                                                          >      >
> >                                                           tend to
> >                                                          >      >
> >                                                          >     believe
> >                                                          >      >
> >                                                          >      >
> >                                                               that it
> can be
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               anything
> >                                                         and ignored by
> the
> >                                                          >      >
> >                                                           reciever VTEP.
> >                                                          >      >
> >                                                          >      >
> >                                                               Also, if
> the
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               trapping
> >                                                         is based on VNI
> >                                                          >      >
> >                                                           number, the
> >                                                          >      >
> >                                                          >      >
> >
> >                                                           destination IP
> >                                                         address
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               of the
> >                                                         inner IP packet
> >                                                          >     can from
> >                                                          >      >
> >                                                           the range
> >                                                          >      >
> >                                                          >      >
> >                                                               127/8 for
> >                                                         IPv4,
> >                                                          >      >
> >                                                          >      >
> >                                                                >
> >                                                               and for
> >                                                         IPv6 from the
> range
> >                                                          >      >
> >                                                          >      >
> >
> >
> >                                                          >     set to 1
> (no
> >                                                          >     change
> here).
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: <[email-masked]>
Date: Tue, 8 Oct 2019 10:45:43 +0800 (CST)

Hi Santosh,

Thanks for your consideration.

Best Regards,

Xiao Min

原始邮件

发件人：SantoshPK <[email-masked]>
收件人：肖敏10093570;
抄送人：Greg Mirsky <[email-masked]>;[email-masked] <[email-masked]>;Dinesh Dutt <[email-masked]>;rtg-bfd WG <[email-masked]>;Joel Halpern <[email-masked]>;T. Sridhar <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年10月03日 22:22
主 题 ：Re: BFD over VXLAN: Trapping BFD Control packet at VTEP

Xiao,   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. 

Thanks
Santosh P K 

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)).

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.

"Note that two different Tenant Systems (and TSIs) attached to a common NVE can share a VAP (e.g., TS1 and TS2 in Figure 2) so long as they connect to the same Virtual Network."
Some people may argue that all Tenant Systems connecting to the same Virtual Network MUST share one VAP, if that's true, then VAP1 and VAP3 should merge into one VAP and my explanation doesn't work. Copying to NVO3 WG to involve more experts, hope for your clarifications and comments.

Best Regards,

Xiao Min

原始邮件

发件人：SantoshPK <[email-masked]>
收件人：Greg Mirsky <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;Dinesh Dutt <[email-masked]>;rtg-bfd WG <[email-masked]>;Joel M. Halpern <[email-masked]>;T. Sridhar <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年09月23日 05:39
主 题 ：Re: BFD over VXLAN: Trapping BFD Control packet at VTEP

Greg,

Thanks
Santosh P K 

On Fri, Aug 16, 2019 at 4:59 AM Greg Mirsky <gregimirsky@gmail...com> wrote:

Hi Santosh,thank you for your comments. Please find my notes in-lined and tagged GIM>>.

Regards,
Greg

On Tue, Aug 13, 2019 at 10:24 PM Santosh P K <[email-masked]> wrote:

Greg,   Thanks for updated version of document. Here are few comments on new draft.

Section 4:

I think we may need to give background on why we are saying MAC address MUST not be one of tenant's MAC address. Like in this thread we have discussed one of the tenant could have borrowed the same VTEP mac address and we if we have to use BFD then we need to avoid that conflict to ensure BFD packets get observed in the VTEP itself. Should we add a section before 4 to set that context so that above text makes more sense in that context?

 [SPK]  Proposed text for why we should not use VTEP MAX address as tenant MAC address.

"In some scenarios tenant MAC is borrowed from VTEP MAC address. VXLAN BFD MUST terminate BFD session at VTEP and MUST not forward BFD packets to tenants. To terminate VXLAN BFD packets at VTEP, deployment MUST ensure that there are no tenant VM which barrows VTEP MAC address."

   IP header:

I think we have added some text to address Sridhar comments on why TTL MUST be 1 and dest IP address MUST be 127/8 range. I see that text is missing now.

GIM>> My apologies that I've missed to include the text from another discussion thread. I believe the following would be complete:

Section 5.1:

Just with 3 tuple we will not be able to demux packet. We need to consider VNI as well if we have multiple BFD session between same pair of VTEP.

GIM>> This is one of comments from Carlos we need to address. Your comment have helped me to form the question:

 [SPK] The goal of the multiple BFD session is to ensure check liveliness of VXLAN tunnel. There is already a good amount of debate on this topic that do we really need that? As per RFC 5884 we are running BFD per LSP and we might hit scale issues there too. I think it is up to operator to decide how they want to use multiple BFD session per VXLAN tunnel. It could be possible that BFD session with special VNI is run at aggressive interval where as MAY have multiple BFD sessions for different VNI at a sedate interval, for that matter they could be running in demand mode as well (run P/F sequence only when there is no data following for that VNI). As WG if we think running multiple BFD session make sense then we might need to add appropriate text.

If the goal is to monitor per VNI, then the following text should describe the demultiplexing of the initial BFD Control packet:   Demultiplexing of IP BFD packet has been defined in Section 3 of

 [SPK]  I think this text for multiple BFD session between same pair of VTEPs for multiple VNI makes sense only if as WG we think that could be use case. 

Thanks

Santosh P K

On Fri, Aug 9, 2019 at 4:27 AM Greg Mirsky <[email-masked]> wrote:

Dinesh, thank you for your help, much appreciated.
Hi Joel and Sridhar,
could you please check if the updated text on the inner Ethernet frame addressed your concern.

Dinesh

On Wed, Aug 7, 2019 at 9:25 AM Greg Mirsky <[email-masked]> wrote:

Hi Dinesh, Joel, Sridhar, et al.,much appreciate the help you've given me sharing your expertise. I hope that the updates you will find in the attached diff and the working copy of the draft be closer to the acceptable solution for VTEP-VTEP BFD. Please note, that I'll shortly start a new discussion thread to address one of Carlos's questions on the ambiguity of the text on multiple concurrent sessions between the same pair of VTEPs.
Please review the changes to Sections 4 and 6 and share your feedback, suggestions, and questions.

Regards,
Greg

On Mon, Aug 5, 2019 at 5:56 PM Greg Mirsky <[email-masked]> wrote:

Hi Dinesh,thank you for your expedient detailed response.
I believe that the ability to run BFD session up to a tenant (VTEP-VTEP-tenant or tenant-tenant) was never in jeopardy from this specification.
I'm trying to provide precise specification on what can be used ad the destination MAC and IP addresses in the inner frame/packet as I believe that likely will help to avoid interoperability issues.
I'm interested to learn some more about the "martian checking" function. As you know, martian addresses have been used as destination IP address in LSP Ping and BFD over MPLS LSP and PW. I haven't heard that any silicon feature caused problems for operators using these tools.

Interesting. I didn't know this aspect of use with MPLS ping. Did those packets ever go through a firewall though? In any case, maybe suggest the use of those addresses with a statement that this is how LSP does it, but that other MAC/IP pairs are possible as long as the conditions of the endpoint owning the MAC/IP was honored.

Dinesh

Regards,
Greg

On Mon, Aug 5, 2019 at 3:59 PM Dinesh Dutt <[email-masked]> wrote:

Hi Greg,

That we agree on the problem definition is the first step forward. Your original document had my cases covered and so I was surprised by the track this thread took. It doesn't matter, we're back on track.

My recommendation is to not worry about specifying the precise MAC/IP address used in the inner header. The addresses chosen MUST ensure that the packet is trapped to the control plane of the VTEP and not escape to the tenant if the BFD is to the VTEP. Any solution MUST also not preclude the use of the BFD by tenant systems for that VNI. There are many ways an implementer can choose to implement this. For example, the inner MAC address is whatever the VTEP implementer would return if ARP'd for the IP address used in the inner header in the given VNI. The implementer can pick a fixed MAC address, one that they own etc. Multiple BFD sessions can be run for testing path connectivity on more than one VNIs. Limits should be in place to avoid overwhelming the receiver with BFD messages (you had words about this in your currently published draft).  If the VNI is irrelevant in the test i.e. only the VXLAN pipe at the VTEP is being tested. the user can use any VNI active on the VTEP on which the VTEP owns an IP address.

I'm concerned about the use of 127/8 address only because of firewalls or implementations that drop packets with these addresses as either the source or destination. For example, on many merchant silicon, I don't believe you can turn off martian checking and drops *only* for VXLAN-encapsulated BFD packets. I don't know what the Linux kernel does today on such packets, for example (or Hyper-V). I'd like a solution that doesn't demand additional or new chip functionality or require additional middle-box hole punch.

Why do you feel you MUST to specify the MAC/IP address on the inner packet? What am I missing here?

Dinesh

On Mon, Aug 5, 2019 at 3:04 PM Greg Mirsky <[email-masked]> wrote:

Hi Dinesh,what do you see as the way forward? I agree, that the proposed text doesn't work for multi-VNI concurrent monitoring because these VNIs are tenant's VNIs. And in that case, we need to specify another mechanism to trap the BFD Control packet at VTEP. It seems that VTEP's Ethernet address must be used as the destination MAC address in the inner Ethernet frame. The destination IP address may be either VTEP's address of martian (I do prefer martian). Let me give it  try:
NEW TEXT:

To monitor continuity of the path between two VTEPs, an operator MUST select a VNI number to be used as Management VNI. Management VNI number MUST NOT be one of the tenant's VNIs to prevent sending VXLAN packets received on Management VNI to a tenant. VNI number 1 is RECOMMENDED as the default for Management VNI. [Ed.note: What we set the Destination MAC to? Can it be invalid MAC that MUST be ignored on receipt?]

If an implementation supports concurrent monitoring of multiple VNIs, then the value of VNI number MAY be one of tenant's VNIs. The destination MAC address in the inner Ethernet frame encapsulating BFD Control packet MUST be MAC associated with the remote VTEP. 
The destination IP address of the inner IP packet MUST be selected from the range 127/8 for IPv4, and for IPv6 from the range 0:0:0:0:0:FFFF:7F00:0/104. The TTL value in the inner IP header MUST be set to 1.

Regards,Greg 

On Sun, Aug 4, 2019 at 9:07 AM Dinesh Dutt <[email-masked]> wrote:

Hi Greg,

Thanks for your clarifications. I agree with your sentiment on why you're running BFD over VXLAN between VTEPs. I wasn't arguing against it at all. All I was saying was pointing to the limitations of the use of management VNI. I spoke to some operators who're running EVPN and mentioned the discussion on this thread. They concur that they're using specific VNIs to test connectivity over that VNI between VTEPs to ensure misconfiguration doesn't lead to blackholes. My statements are based in real world operator experience. And I was providing language that ensured packets didn't leak across to tenants when they were destined to VTEPs.

Dinesh

On Sat, Aug 3, 2019 at 10:34 AM Greg Mirsky <[email-masked]> wrote:

Hi Dinesh,many thanks for your detailed updates on how some implementations process VXLAN header and the inner Ethernet frame. These are very helpful in achieving the workable solution for the problem at hand.
You've noted that a path between VTEPs may be monitored in the underlay network by merely establishing a BFD session. That is true, but by using BFD with VXLAN encapsulation between the pair of VTEPs we are extending the OAM domain by including, to some extent, VXLAN forwarding engine. Abstract in RFC 5880 defines the goal and the domain in which BFD protocol can detect a fault as:
   This document describes a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves, with potentially very low latency. 

Thus, BFD in the underlay will exercise a part of IP forwarding engine while BFD with VXLAN encapsulation, ran between the same pair of VTEPs, extends the OAM domain. At the same time, defining BFD between tenant systems in outside the goal of this specification. But VXLAN BFD session between VTEPs may be useful in monitoring e2e path between tenants, as described in the update to -07:
   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].

Regards,
Greg

On Fri, Aug 2, 2019 at 5:43 PM Dinesh Dutt <[email-masked]> wrote:

What I mean is "How do you infer that it excludes the case I'm talking about?". 

Dinesh

On Fri, Aug 2, 2019 at 5:41 PM Dinesh Dutt <[email-masked]> wrote:

Dinesh

On Fri, Aug 2, 2019 at 5:38 PM Joel M. Halpern <[email-masked]> wrote:

I am going by what the draft says its purpose is.  If you (Dinesh) want 
the draft to fulfill a different purpose, then either ask the chairs to 
take this draft back to the WG, or write a separate draft.
As currently written, the behavior Greg proposed meets the needs, and 
does so in a way that is consistent with VxLAN.

Yours,
Joel

On 8/2/2019 8:30 PM, Dinesh Dutt wrote:
> What is the stated purpose of this BFD session? The VTEP reachability is 
> determined by the underlay, I don't need VXLAN-encaped packet for that. 
> Do we agree?
> 
> If I want to test the VXLAN encap/decap functionality alone, picking any 
> single VNI maybe fine. But is this all any network operator wants? Why? 
> In what situations has this been a problem? I suspect operators also 
> want to verify path continuity over a specific VNI. If you say this is 
> not defined by the document, I disagree because the current version 
> talks about controlling the number of BFD sessions between the VTEPs 
> (see section 3). More importantly, this is a real problem that operators 
> like to verify.
> 
> Dinesh
> 
> On Fri, Aug 2, 2019 at 5:08 PM Joel M. Halpern <[email-masked] 
>     What is special about the management VNI is precisely that it is NOT a
>     tenant VNI.  The VxLAN administration does know how it allocates VNI to
>     tenants, and which VNI it has allocated.  In contrast, it does not know
>     which IP addresses or MAC adddresses teh tenant is using or may plan
>     to use.
> 
>     Yours,
>     Joel
> 
>      > The assumption of an IP address within any VNI is suspect that way.
>      > What's special about a single VNI, the management VNI? The VTEP IP
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     First, the problem you describe is not what the document says
>     it is
>      >     solving.  To the degree it discusses it at all, the document
>     says "
>      >       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 in common. "
>      >
>      >     Second, you assume the existence of an IP address for a VTEP
>     within a
>      >     VNI.  As with the MAC address, the VTEP does not have an IP
>     address
>      >     within the VNI.  Some implementations may have created such a
>     thing,
>      >     but
>      >     the general construct, as defined to date, does not support such.
>      >
>      >     In short, you are requiring a behavior that violates the
>     architectural
>      >     structure of overlay / underlay separation, and common
>     usage.  And you
>      >     are doing so to support a use case that the working group has not
>      >      > The VNIs may not share fate due to misconfiguration. And I
>     strongly
>      >      > suspect someone will want to use BFD for that because its
>     about
>      >     checking
>      >      > path continuity as stated by the draft. As long as there's a
>      >     valid IP
>      >      > (because it's BFD) owned by the VTEP in that VNI, you can
>     use BFD in
>      >      > that VNI. Thats all that you need to dictate.  That IP address
>      >     has a MAC
>      >      > address and you can use that on the inner frame. That is
>     all normal
>      >      > VXLAN processing. The outer IP is always that of the VTEP.
>      >      >
>      >      > Dinesh
>      >      >
>      >      > On Fri, Aug 2, 2019 at 11:03 AM Joel M. Halpern
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     If I am reading your various emails correctly Dinesh
>     (and I
>      >     may have
>      >      >     missed something) you are trying to use the MAC address
>      >     because you
>      >      >     want
>      >      >     to be able to send these BFD packets over arbitrary VNI to
>      >     monitor the
>      >      >     VNI.  That is not a requirement identified in the
>     document.
>      >     It is not
>      >      >     even a problem I understand, since all the VNI between an
>      >     ingress and
>      >      >     egress VTEP share fate.
>      >      >
>      >      >     Yours,
>      >      >     Joel
>      >      >
>      >      >      > Thanks for verifying this. On Linux and hardware
>     routers
>      >     that I'm
>      >      >     aware
>      >      >      > of (Cisco circa 2012 and Cumulus), the physical MAC
>     address is
>      >      >     reused
>      >      >      > across the VNIs on the VTEP. Did you check on a non-VMW
>      >     device?
>      >      >     This is
>      >      >      > To address the general case, can we not define a
>      >     well-known (or
>      >      >     reserve
>      >      >      > one) unicast MAC address for use with VTEP? If the MAC
>      >     address is
>      >      >      > configurable in BFD command, this can be moot.
>      >      >      >
>      >      >      > Dinesh
>      >      >      >
>      >      >      > On Fri, Aug 2, 2019 at 10:27 AM Santosh P K
>      >      >      >     I have cross checked point raised about MAC address
>      >     usage. It is
>      >      >      >     possible that tenant could be using physical MAC
>      >     address and
>      >      >     when a
>      >      >      >     packet comes with valid VNI with a MAC address
>     that is
>      >     being
>      >      >     used by
>      >      >      >     tenant then packet will be sent to that tenant.
>     This rules
>      >      >     out the
>      >      >      >     fact that we could use physical MAC address as
>     inner
>      >     MAC to
>      >      >     ensure
>      >      >      >     packets get terminated at VTEP itself.
>      >      >      >
>      >      >      >     Thanks
>      >      >      >     Santosh P K
>      >      >      >
>      >      >      >     On Wed, Jul 31, 2019 at 11:00 AM Santosh P K
>      >      >      >             Thanks for your inputs. I checked
>      >     implementation within
>      >      >      >         Vmware. Perhaps I should have been more clear
>      >     about MAC
>      >      >     address
>      >      >      >         space while checking internally. I will cross
>      >     check again for
>      >      >      >         the same and get back on this list.
>      >      >      >
>      >      >      >         Thanks
>      >      >      >         Santosh P K
>      >      >      >
>      >      >      >         On Wed, Jul 31, 2019 at 10:54 AM Joel M.
>     Halpern
>      >      >      >         <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>      >      >      >
>      >      >      >             Sorry to ask a stupid question.  Whose
>      >     implementation?
>      >      >      >
>      >      >      >             The reason I ask is that as far as I
>     can tell,
>      >     since the
>      >      >      >             tenant does not
>      >      >      >             have any control access to the VTEP,
>     there is no
>      >      >     reason for
>      >      >      >             the VTEP to
>      >      >      >             have a MAC address in the tenant
>     space.  Yes, the
>      >      >     device has
>      >      >      >             a physical
>      >      >      >             MAC address.  But the tenant could well be
>      >     using that MAC
>      >      >      >             address.  Yes,
>      >      >      >             they would be violating the Ethernet spec.
>      >     But the whole
>      >      >      >             point of
>      >      >      >             segregation is not to care about such
>     issues.
>      >      >      >
>      >      >      >             On the other hand, if you tell me that
>     the VMWare
>      >      >      >             implementation has an
>      >      >      >             Ethernet address that is part of the tenant
>      >     space, well,
>      >      >      >             they made up
>      >      >      >             this particular game.
>      >      >      >
>      >      >      >             Yours,
>      >      >      >             Joel
>      >      >      >
>      >      >      >             On 7/31/2019 1:44 PM, Santosh P K wrote:
>      >      >      >              > I have checked with implementation
>     in data
>      >     path.
>      >      >     When we
>      >      >      >             receive a
>      >      >      >              > packet with valid VNI then lookup
>     for MAC will
>      >      >     happen and
>      >      >      >             it is VTEP own
>      >      >      >              > MAC then it will be trapped to control
>      >     plane for
>      >      >      >             processing. I think we
>      >      >      >              > can have following options
>      >      >      >              > 1. Optional managment VNI
>      >      >      >              > 2. Mandatory inner MAC set to VTEP mac
>      >      >      >              > 3. Inner IP TTL set to 1 to avoid
>      >     forwarding of packet
>      >      >      >             via inner IP
>      >      >      >              > address.
>      >      >      >              >
>      >      >      >              >
>      >      >      >              > Thoughts?
>      >      >      >              >
>      >      >      >              > Thansk
>      >      >      >              > Santosh P K
>      >      >      >              >
>      >      >      >              > On Wed, Jul 31, 2019 at 9:20 AM Greg
>     Mirsky
>      >      >      >             <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >      >              >     thank you for your consideration
>     of the
>      >      >     proposal and
>      >      >      >             questions. What
>      >      >      >              >     would you see as the scope of
>     testing the
>      >      >      >             connectivity for the
>      >      >      >              >     specific VNI? If it is
>      >     tenant-to-tenant, then
>      >      >     VTEPs
>      >      >      >             will treat these
>      >      >      >              >     packets as regular user frames. More
>      >     likely, these
>      >      >      >             could be Layer 2
>      >      >      >              >     OAM, e.g. CCM frames. The reason
>     to use
>      >     127/8 for
>      >      >      >             IPv4, and
>      >      >      >              >     Ethernet frames with BFD Control
>     packet
>      >     to a
>      >      >     tenant.
>      >      >      >              >     You've suggested using a MAC
>     address to
>      >     trap the
>      >      >      >             control packet at
>      >      >      >              >     VTEP. What that address could be? We
>      >     had proposed
>      >      >      >             using the
>      >      >      >              >     dedicated MAC and VTEP's MAC and
>     both
>      >     raised
>      >      >     concerns
>      >      >      >             among VXLAN
>      >      >      >              >     experts. The idea of using
>     Management
>      >     VNI may
>      >      >     be more
>      >      >      >             acceptable
>      >      >      >              >     based on its similarity to the
>     practice
>      >     of using
>      >      >      >             Management VLAN.
>      >      >      >              >
>      >      >      >              >     Regards,
>      >      >      >              >     Greg
>      >      >      >              >
>      >      >      >              >     On Wed, Jul 31, 2019 at 12:03 PM
>     Dinesh
>      >     Dutt
>      >      >      >             <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>>
>      >      >      >             wrote:
>      >      >      >              >
>      >      >      >              >         Hi Greg,
>      >      >      >              >
>      >      >      >              >         As long as the inner MAC
>     address is
>      >     such
>      >      >     that the
>      >      >      >             packet is
>      >      >      >              >         trapped to the CPU, it should be
>      >     fine for
>      >      >     use as
>      >      >      >             an inner MAC is
>      >      >      >              >         it not? Stating that is
>     better than
>      >     trying to
>      >      >      >             force a management
>      >      >      >              >         VNI. What if someone wants
>     to test
>      >      >     connectivity
>      >      >      >             on a specific
>      >      >      >              >         VNI? I would not pick a
>     loopback IP
>      >      >     address for
>      >      >      >             this since that
>      >      >      >              >         address range is host/node local
>      >     only. Is
>      >      >     there a
>      >      >      >             reason you're
>      >      >      >              >         not using the VTEP IP as the
>     inner IP
>      >      >     address ?
>      >      >      >              >
>      >      >      >              >         Dinesh
>      >      >      >              >
>      >      >      >              >         On Wed, Jul 31, 2019 at 5:48 AM
>      >     Greg Mirsky
>      >      >      >              >         <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]>>>> <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >      >              >             thank you for your comments,
>      >      >     suggestions on
>      >      >      >             this issue,
>      >      >      >              >             probably the most
>     challenging
>      >     for this
>      >      >      >             specification. In the
>      >      >      >              >             course of our discussions,
>      >     we've agreed to
>      >      >      >             abandon the
>      >      >      >              >             request to allocate the
>      >     dedicated MAC
>      >      >     address
>      >      >      >             to be used as
>      >      >      >              >             the destination MAC
>     address in
>      >     the inner
>      >      >      >             Ethernet frame.
>      >      >      >              >             Also, earlier using VNI
>     0 was
>      >     changed from
>      >      >      >             mandatory to one
>      >      >      >              >             of the options an
>      >     implementation may
>      >      >     offer to
>      >      >      >             an operator.
>      >      >      >              >             The most recent
>     discussion was
>      >     whether
>      >      >     VTEP's
>      >      >      >             MAC address
>      >      >      >              >             might be used as the
>      >     destination MAC
>      >      >     address
>      >      >      >             in the inner
>      >      >      >              >             Ethernet frame. As I
>     recall it, the
>      >      >     comments
>      >      >      >             from VXLAN
>      >      >      >              >             experts equally split
>     with one
>      >     for it
>      >      >     and one
>      >      >      >             against. Hence
>      >      >      >              >             I would like to propose
>     a new
>      >     text to
>      >      >     resolve
>      >      >      >             the issue. The
>      >      >      >              >             idea is to let an
>     operator select
>      >      >     Management
>      >      >      >             VNI and use
>      >      >      >              >             that VNI in VXLAN
>     encapsulation
>      >     of BFD
>      >      >      >             Control packets:
>      >      >      >              >             NEW TEXT:
>      >      >      >              >
>      >      >      >              >                 An operator MUST
>     select a VNI
>      >      >     number to
>      >      >      >             be used as
>      >      >      >              >                 Management VNI. VXLAN
>      >     packet for
>      >      >      >             Management VNI MUST NOT
>      >      >      >              >                 be sent to a tenant. VNI
>      >     number 1 is
>      >      >      >             RECOMMENDED as the
>      >      >      >              >                 default for
>     Management VNI.
>      >      >      >              >
>      >      >      >              >             With that new text, what
>     can be the
>      >      >     value of
>      >      >      >             the destination
>      >      >      >              >             MAC in the inner Ethernet? I
>      >     tend to
>      >      >     believe
>      >      >      >             that it can be
>      >      >      >              >             anything and ignored by the
>      >     reciever VTEP.
>      >      >      >             Also, if the
>      >      >      >              >             trapping is based on VNI
>      >     number, the
>      >      >      >             destination IP address
>      >      >      >              >             of the inner IP packet
>     can from
>      >     the range
>      >      >      >             127/8 for IPv4,
>      >      >      >              >             and for IPv6 from the range
>      >      >      >              >             lastly, the TTL to be
>      >      >      >              >             Much appreciate your
>      >      >      >              >             Best regards,

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Oct 2019 17:07:52 -0400

Santosh and others,

> 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...]

> > VNI1, I believe it's reasonable, so that's why I think we should allow it

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Oct 2019 09:05:58 -0400

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

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 22 Oct 2019 11:09:05 -0700

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 <[email-masked]> wrote:

> sessions
> >>>       NVE1   |           |          |       |           |          |
> NVE2

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 22 Oct 2019 14:17:30 -0400

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 <[email-masked]>
wrote:

> The current document is already capable of monitoring multiple VNIs
> between VTEPs.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Oct 2019 15:06:33 -0400

I do not understand the value of option 2.
Which is why I asked in my initial review to move to option 1.

And option 2 requires stealing MAC addresses from the users, which seems 
to me to be a very bad thing that option 1 avoids.

Yours,
Joel

On 10/22/2019 2:17 PM, Greg Mirsky wrote:
> 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:
> 
> On Tue, Oct 22, 2019 at 2:09 PM Anoop Ghanwani <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     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 <[email-masked]
>          >> On Wed, Sep 25, 2019 at 8:10 AM <[email-masked]
>         <mailto:[email-masked]>> wrote:
>          >>
>          >>> Hi Santosh,
>          >>>
>          >>>
>          >>>                      |                                     
>             |
>          >>>              |           |          |       |           | 
>                  |
>          >>>       NVE1   |           |          |       |           | 
>                  | NVE2
>         [email-masked] <mailto:[email-masked]>

---

From: John E Drake <[email-masked]>
Date: Tue, 22 Oct 2019 19:15:36 +0000

Hi,

What is the marginal utility of either 2 or 3?

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: nvo3 <[email-masked]> On Behalf Of Joel M. Halpern
> Sent: Tuesday, October 22, 2019 3:07 PM
> To: Greg Mirsky <[email-masked]>; Anoop Ghanwani
> <[email-masked]>
> Cc: Dinesh Dutt <[email-masked]>; [email-masked]; NVO3
> <[email-masked]>; Santosh P K <[email-masked]>; Jeffrey Haas
> <[email-masked]>; rtg-bfd WG <[email-masked]>; T. Sridhar
> <[email-masked]>; [email-masked]
> Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
> 
> And option 2 requires stealing MAC addresses from the users, which seems to
> me to be a very bad thing that option 1 avoids.
> 
> Yours,
> Joel
> 
> > 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
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/nvo3
> > __;!8WoA6RjC81c!TqBnCBob-
> mGlRIth01cY0gBaFxq5GzSZjQh6CW4FENMMATOR6aryer
> > Pnf__xrJY$
> >
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/nvo3__;!8
> WoA6RjC81c!TqBnCBob-
> mGlRIth01cY0gBaFxq5GzSZjQh6CW4FENMMATOR6aryerPnf__xrJY$

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 22 Oct 2019 15:16:30 -0400

Hi Joel,
if the underlay may balance VXLAN between two VTEPs using VNI in addition
to other fields, then Option 2 has a certain value in my opinion.

Regards,
Greg

On Tue, Oct 22, 2019 at 3:06 PM Joel M. Halpern <[email-masked]> wrote:

> >          >>>                   |     |    |     Tenant        |     |

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Oct 2019 15:30:39 -0400

As I recall, the VNI is not in the same place nor the same size as the 
TCP / UDP ports.  So it seems very unlikely that it would be used in 
ECMP.  In fact, avoiding that is why VXLAN does interesting things with 
the source UDP port.  Which the BFD can do.  And presumably MUST do if 
it was path matching.

Yours,
Joel

On 10/22/2019 3:16 PM, Greg Mirsky wrote:
> Hi Joel,
> if the underlay may balance VXLAN between two VTEPs using VNI in 
> addition to other fields, then Option 2 has a certain value in my opinion.
> 
> Regards,
> Greg
> 
> On Tue, Oct 22, 2019 at 3:06 PM Joel M. Halpern <[email-masked] 
>     current
>      > On Tue, Oct 22, 2019 at 2:09 PM Anoop Ghanwani
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     On Tue, Oct 22, 2019 at 6:06 AM Joel M. Halpern
>      >         The document we have is a VTEP-VTEP monitoring document. 
>     There
>      >         is no
>      >          > 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 <[email-masked]
>     <mailto:[email-masked]>
>      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>> 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
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 22 Oct 2019 15:55:28 -0400

Hi Joel,
RFC 7348 suggests using information from the inner packet to calculate the
value to be used in the Source UDP port number:
      -  Source Port:  It is recommended that the UDP source port number
         be calculated using a hash of fields from the inner packet --
         one example being a hash of the inner Ethernet frame's headers.
         This is to enable a level of entropy for the ECMP/load-
         balancing of the VM-to-VM traffic across the VXLAN overlay.
>From that text, I assume that VNI may be used as input for hashing
function. If BFD over VXLAN doesn't support per VNI BFD session, then it
cannot monitor multiple paths in underlay used to balance VM-to-VM traffic
between the same pair of VTEPs. In my opinion, this is perfectly fine if
that is WG's agreement. I'm glad we are discussing this and will have a
conclusion.

Regards,
Greg

On Tue, Oct 22, 2019 at 3:30 PM Joel M. Halpern <[email-masked]> wrote:

> >      >         If folks want a protocol for doing BFD monitoring of
> things
> >      >         behind the
> >      >          >>     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
> >      >          >>> 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
> (IP)
> >      >          >>>                           |       Tunnel Overlay
> >      >          >>>              | |  Overlay Module  | |       | |
> Overlay
> >      >         Module  | |
> >      >          >>>              |           |          |       |
> >      >          >>>       NVE1   |           |          |       |
> >      >          >>>              |  |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
> >      >          >>> 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
> >      >

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 22 Oct 2019 15:58:38 -0400

That is input to the calculation at the VTEP.  It is NOT information 
sued by the network between the VTEPs.

As such, the VTEPs can emulate that by adjusting the source ports that 
it uses for the VFD packets.  The network does not need the VNI to 
actually be varied to achieve this purpose.

Yours,
Joel

On 10/22/2019 3:55 PM, Greg Mirsky wrote:
> Hi Joel,
> RFC 7348 suggests using information from the inner packet to calculate 
> the value to be used in the Source UDP port number:
> cannot monitor multiple paths in underlay used to balance VM-to-VM 
> traffic between the same pair of VTEPs. In my opinion, this is perfectly 
> fine if that is WG's agreement. I'm glad we are discussing this and will 
> have a conclusion.
> 
> Regards,
> Greg
> 
> On Tue, Oct 22, 2019 at 3:30 PM Joel M. Halpern <[email-masked] 
>      > On Tue, Oct 22, 2019 at 3:06 PM Joel M. Halpern
>      >     And option 2 requires stealing MAC addresses from the users,
>     which
>      >     seems
>      >      > 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
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>> 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
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>> 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
>     <[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >         <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     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
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > https://www.ietf.org/mailman/listinfo/nvo3
>      >      >
>      >
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 22 Oct 2019 16:05:32 -0700

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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 22 Oct 2019 22:28:19 -0400

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 <[email-masked]> 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 <[email-masked]>
> wrote:
>
> Greg,
>
> 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
>
>>> 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
>>>

---

From: <[email-masked]>
Date: Wed, 23 Oct 2019 10:42:09 +0800 (CST)

Yes, what I discussed with Anoop was on Greg's option #3.

Respecting BFD over VxLAN, option #2 and #3 both are ok to me, I have no preference.

Respecting BFD over Geneve, option #2 and #3 both are ok to me, although I personally prefer #3.

Best Regards,

Xiao Min

原始邮件

发件人：AnoopGhanwani <[email-masked]>
收件人：Greg Mirsky <[email-masked]>;
抄送人：Joel M. Halpern <[email-masked]>;Jeffrey Haas <[email-masked]>;Santosh P K <[email-masked]>;NVO3 <[email-masked]>;[email-masked] <[email-masked]>;Dinesh Dutt <[email-masked]>;rtg-bfd WG <[email-masked]>;T. Sridhar <[email-masked]>;肖敏10093570;Yes
日 期 ：2019年10月23日 07:05
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

Greg,

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

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:
single BFD session between two VTEPs

single BFD session per VNI between two VTEPs

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 <[email-masked]> wrote:

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

Yours,
Joel

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 22 Oct 2019 23:09:48 -0700

Hi Greg,

The part about the use of 127/8 address appears to be a new thing
introduced in the version of the draft that is as of yet unpublished.  What
was the motivation for the change?  Previously, the DA was simply set to
the destination VTEP's IP address which seemed fine.

Anoop

On Tue, Oct 22, 2019 at 7:48 PM Dinesh Dutt <[email-masked]> wrote:

> Greg,
>
> Two comments, one minor and one maybe not.
>
> - 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.
>
> - 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.
>
> The rest of the draft looks good to me,
>
> Dinesh
>
> On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky <[email-masked]>
> wrote:
>
> Hi Dinesh,

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 23 Oct 2019 01:17:50 +0500

oel,

I'm a tad frustrated that we're rehashing this discussions all over 
again. I specifically explained all the questions that were raised at 
that time. Let me try one last time.

1. BFD for VTEP is only useful for testing VXLAN plumbing, not the 
underlay itself.
2. So, the question is what do we use for VNI and the inner header?
3. The inner header is an IP packet because it is BFD. The IP address 
and the corresponding MAC address used MUST be one that is owned by the 
VTEP in the VNI that is used in the packet

This is sufficient to come up with an implementation that only ever 
tests one VNI or multiple VNIs between thr same pair of VTEPs. It is 
upto the users to decide what VNI, inner MAC and IP to use. The only 
restriction is that the VTEP must own those addresses to (i) prevent 
the packet from leaking to tenants and (ii) allow the tenants 
themselves to be running BFD.

If implementations want to use VNI 1 as the recommended default VNI to 
use, that is fine. But if implementations want to pick more than 1 
because they have a need to do so (I've seen operators do this because 
of their specific use case), then they can as long as they satisfy 
point 3, the draft is done. Why does there need to be any more 
discussion? The draft does need to spell out that using more than VNI 
has scaling issues that the user needs to be aware of, and it does.

Dinesh

On Wed, Oct 23, 2019 at 1:28 AM, Joel Halpern Direct 
<[email-masked]> wrote:
> As such, the VTEPs can emulate that by adjusting the source ports 
> that it uses for the VFD packets.  The network does not need the VNI 
> to actually be varied to achieve this purpose.
> 
> Yours,
> Joel
> 
>> RFC 7348 suggests using information from the inner packet to 
>> calculate the value to be used in the Source UDP port number:
>> function. If BFD over VXLAN doesn't support per VNI BFD session, 
>> then it cannot monitor multiple paths in underlay used to balance 
>> VM-to-VM traffic between the same pair of VTEPs. In my opinion, 
>> this is perfectly fine if that is WG's agreement. I'm glad we are 
>> discussing this and will have a conclusion.
>> 
>> Regards,
>> Greg
>> 
>>      > addition to other fields, then Option 2 has a certain value 
>> in my
>>     opinion.
>>      >
>>      > Regards,
>>      > Greg
>>      >
>>      >      > I agree with your understanding of what is being 
>> defined
>>     in the
>>      >     current
>>      >      > WG is discussing the scope before the WGLC is closed. I
>>     believe
>>      >     there
>>      >      > are three options:
>>      >      >
>>      >      > The current text reflects #2. Is WG accepts this 
>> scope? If
>>     not,
>>      >     which
>>      >      > option WG would accept?
>>      >      >
>>      >      > Regards,
>>      >      > Greg
>>      >      >
>>      >      > <mailto:[email-masked]
>>      >      >     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
>>      >      >     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
>>      >      >         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
>>      >      >          > 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
>>      >      >          > to follow what the current status of the 
>> draft
>>     is, or
>>      >     should
>>      >      >         be.  :-)
>>      >      >          >
>>      >      >          > hinge point on what our encapsulation for 
>> BFD
>>     over vxlan
>>      >      >         should look like.
>>      >      >          > Correct?
>>      >      >          >
>>      >      >          > If this is so, do we have a sense as to how 
>> we
>>     should
>>      >     proceed?
>>      >      >          >
>>      >      >          > -- Jeff
>>      >      >          >
>>      >      >          >> On Wed, Sep 25, 2019 at 8:10 AM
>> <mailto:[email-masked]>>
>> <mailto:[email-masked]>>>>
>>     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 Module  | |     
>>      >      >          >>>              | +---------+--------+ |     
>>      >      >          >>>              |           |          |     
>>      >      >          >>>       NVE1   |           |          |     
>>      >      >          >>>              |  +--------+-------+  |     
>>      >      >          >>>              |  |VNI1 VNI2  VNI1 |  |     
>>      >      >          >>>              |  +-+-----+----+---+  |     
>>      >      >          >>>                   |     |    |            
>>      >      >          >>>                   |     |    |            
>>      >      >          >>>                   |     |    |            
>>      >      >          >>>                   |     |    |     Tenant 
>>      >      >          >>>              TSI1 | TSI2|    | TSI3       
>>      >      >          >>>                  +---+ +---+ +---+        
>>      >      >          >>>                  |TS1| |TS2| |TS3|        
>>      >      >          >>>                  +---+ +---+ +---+        
>>      >      >          >>> To my understanding, the BFD sessions 
>> between
>>     NVE1
>>      >     and NVE2
>>      >      >         are actually
>>      >      >          >>> If the network operator want to set up one
>>     BFD session
>>      >      >         between VAP1 of
>>      >      >          >>> NVE1 and VAP3 of NVE2, although the two 
>> BFD
>>     sessions are
>>      >      >         for the same
>> <mailto:[email-masked]

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 23 Oct 2019 01:20:00 +0500

Oops, sorry for misspelling your name Joel,

Dinesh

On Wed, Oct 23, 2019 at 1:47 AM, Dinesh Dutt <[email-masked]> wrote:
> and the corresponding MAC address used MUST be one that is owned by 
> the VTEP in the VNI that is used in the packet
> 
> If implementations want to use VNI 1 as the recommended default VNI 
> to use, that is fine. But if implementations want to pick more than 1 
> because they have a need to do so (I've seen operators do this 
> because of their specific use case), then they can as long as they 
> satisfy point 3, the draft is done. Why does there need to be any 
> more discussion? The draft does need to spell out that using more 
> than VNI has scaling issues that the user needs to be aware of, and 
> it does.
> 
> Dinesh
> 
>>> On Tue, Oct 22, 2019 at 3:30 PM Joel M. Halpern 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>      >      >          > If this is so, do we have a sense as to 
>>> how we
>>>     should
>>>      >     proceed?
>>>      >      >          >
>>>      >      >          > -- Jeff
>>>      >      >          >
>>>      >      >          >>>                      |         Data 
>>> Center
>>> Tenant            |

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 23 Oct 2019 06:52:22 +0500

Dinesh

On Wed, Oct 23, 2019 at 4:35 AM, Anoop Ghanwani <[email-masked]> 
wrote:
> until we have a draft that explains why that is needed in the context 
> of the NVO3 architecture.
> 
> Anoop
> 
>> understand, the WG is discussing the scope before the WGLC is 
>> closed. I believe there are three options:
>> <[email-masked]> wrote:
>>> 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
>>> 
>>> <[email-masked]> wrote:

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 23 Oct 2019 07:47:49 +0500

Greg,

- 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.

Dinesh

On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky <[email-masked]> 
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
> 
>> 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 
>>> 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
>>> 
>>>>> use case for this is not clear to me, as from my understanding, 
>>>>> we cannot have a situation with multiple VAPs using the same

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Oct 2019 07:49:01 -0400

Anoop, you refer to "the destination VTEP's IP address".  Since this is 
a field inside the Ethernet header inside the VxLAN header, what VTEP 
assigned IP address?  The customer (whose address space this is in may 
not be using IP.  Or may be using IP and presumably has NOT assigned an 
IP address to the VTEP.

If we were using VNI 0, then wew would be free to use whatever IP 
address we wanted, as there would be no tenant.  Since folks seem to 
want to use option #2, something has to go in the IP dest address. 
Since there is no IP assigned to the VTEP within the VNI being tested, 
we have to specify something.

Yours,
Joel

On 10/23/2019 2:09 AM, Anoop Ghanwani wrote:
> introduced in the version of the draft that is as of yet unpublished.  
> What was the motivation for the change?  Previously, the DA was simply 
> set to the destination VTEP's IP address which seemed fine.
> 
> Anoop
> 
> On Tue, Oct 22, 2019 at 7:48 PM Dinesh Dutt <[email-masked] 
>     - 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.
> 
>     - 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?
>     On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky <[email-masked]
>>     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 <[email-masked]
>>         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
>>
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>         Greg,
>>>
>>>         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
>>>             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:
>>>
>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>                 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
>>>                     sesparate from what is
>>>                     need in this draft to be
>>>                     question below is really the
>>>                     <[email-masked]
>>>                     RFC8014 (An Architecture for
>>>                     Network (IP)        |
>>>                      |           |          | NVE2
>>>                      |  | VNI1 VNI2 VNI1 |  |
>>>                      |  +-+-----+-----+--+  |
>>>                     TSI1| TSI2|     |TSI3
>>>                      |TS4| |TS5|   |TS6|
>>>                     BFD session between VAP1 of

---

From: Santosh P K <[email-masked]>
Date: Wed, 23 Oct 2019 20:08:37 +0530

Anoop,
   I guess there were multiple discussion over this should we have inner
TTL as 1 or destination IP address as 127/8 range so that if packet gets
exposed in underlay it should not be routed via underlay to VTEP.

Thanks
Santosh P K

---

From: Santosh P K <[email-masked]>
Date: Wed, 23 Oct 2019 20:17:22 +0530

Dinesh,
     Please see my inline comments [SPK]

> [SPK] Thanks for comments. We will change this.

> 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.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 23 Oct 2019 11:06:07 -0400

Hi Dinesh, et al.,
please check the updated version that removed the reference to Hypervisor
in the text and Figure 1.

Regards,
Greg

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 23 Oct 2019 08:20:59 -0700

Thanks Joel.

I see the issue.  In the case of IRB, the VTEP will likely have IP
addresses assigned from the tenant space for each VNI.  But if there is no
IRB, then it could be a problem.  Thus far, my assumption had been that the
underlay address would be used and that the inner addresses would be
inconsequential in terms of terminating the BFD messages.  But I can see
now how that would cause problems if the tenant devices are running BFD and
their addresses conflict with the underlay's addresses.

As indicated by Santosh, it looks like there's a precedence with MPLS OAM
using 127/8 so perhaps that is a reasonable solution.  I also think that
setting the TTL to 1 to prevent leakage may not work because the TTL would
not be decremented at the VTEP.  The outer TTL would just be checked, and
the inner TTL would be decremented only if routing.

The language around tenant IP may need to be clarified a bit because the
VTEP may have IP addresses from the tenant space assigned to its interfaces
when it's doing IRB.

Anoop

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 23 Oct 2019 16:03:04 -0400

Hi Dinesh,
many thanks for your time, the expertise you've kindly shared on this
discussion.
I believe that Santosh has volunteered ;) to provide some text on the
firewall interaction. Any other contributions are welcome and greatly
appreciated.

Regards,
Greg

On Wed, Oct 23, 2019 at 3:54 PM Dinesh Dutt <[email-masked]> 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 <[email-masked]>
> wrote:
>
> Hi Dinesh, et al.,
>>> the inner header in MPLS. I have no specific comments in that area. I have
>>> only two questions:
>> [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
>>>>> 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:
>>>>>

---

From: Santosh P K <[email-masked]>
Date: Mon, 28 Oct 2019 20:21:13 +0530

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

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 28 Oct 2019 09:23:02 -0700

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 <[email-masked]>
wrote:

> <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 Wed, Oct 23, 2019 at 10:47 AM Santosh P K <

---

From: Santosh P K <[email-masked]>
Date: Mon, 28 Oct 2019 22:24:06 +0530

Anoop,
   You are right and Greg did remind me and it skipped my mind my bad.

[Current text in section 4.0]

      IP header:

[proposed]

      IP header:

         Destination IP: IP address MUST NOT be of one of tenant's IP
         addresses.  IP address MAY be set to VTEP IP address or it
MAY be selected

         from the range 127/8 for IPv4, for IPv6 - from the range
0:0:0:0:0:FFFF:7F00:0/104.

                  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>].

"As per section 4 inner destination IP address MAY be set to 127/8 address.
There could 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 inner IP header's destination IP is
set to 127/8 IP address."

Thanks

Santosh P K

On Mon, Oct 28, 2019 at 9:53 PM Anoop Ghanwani <[email-masked]>
wrote:

>> 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]
>>> 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
>>>
>>> please check the updated version that removed the reference to
>>> Hypervisor in the text and Figure 1.
>>>
>>> Regards,
>>> Greg
>>>
>>>>> - 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
>>>>> 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
>>>>> attached copy of the working version and its diff to -07 (latest in the
>>>>> datatracker).
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>>> 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 <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>> Greg,
>>>>>>
>>>>>>>> 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
>>>>>>>>

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 28 Oct 2019 10:21:09 -0700

Hi Santosh,

That looks better and I'd be OK with that.

However, I think it would be better if we did something like:

Destination IP: See Section xx.

Where section xx contains the complete description about setting the
destination IP including:
- Use of the underlay VTEP address for VNI 0.
- Use of overlay VTEP address for any other VNI.
- In the absence of available overlay VTEP address, use of 127/8 or IPv6
equivalent and a note about the firewall issue when using such addresses.

Also, I'm not enough of a firewall expert, but is the issue related to
firewalls running off the VTEP only, or are there firewalls that peek in
the inner header?  If there are the latter, then I think the text should be
more generic and just say something like "firewalls that examine the inner
header..." instead of "firewall running on the VTEP..." which is probably
not even technically correct, since the firewall doesn't run on the VTEP.

Anoop

On Mon, Oct 28, 2019 at 9:54 AM Santosh P K <[email-masked]>
wrote:

>          addresses.  IP address MAY be set to VTEP IP address or it MAY be selected
>
>          from the range 127/8 for IPv4, for IPv6 - from the range 0:0:0:0:0:FFFF:7F00:0/104.
>
>                   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>].
>
>
>
> "As per section 4 inner destination IP address MAY be set to 127/8
> address. There could be firewall configured on VTEP to block 127/8 address
> allow 127/8 range address through firewall only if inner IP header's
> destination IP is set to 127/8 IP address."
>
>
>
> Thanks
>
> Santosh P K
>
>
>
>>> to the behavior defined in [RFC1122
>>> <https://tools.ietf.org/html/rfc1122>]."
>>>
>>>
>>>
>>> Thanks
>>> Santosh P K
>>>
>>>
>>>
>>>>>> 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
>>>>> [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.
>>>>>
>>>>>
>>>>>>
>>>>>>> unnecessary until we have a draft that explains why that is needed in the
>>>>>>> context of the NVO3 architecture.
>>>>>>>
>>>>>>> Anoop
>>>>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Oct 2019 13:22:09 -0400

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:
> 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 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Dinesh, Anoop et all,
>     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."
> 
> 
>     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
>     On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt <[email-masked]
>         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
>>         On Wed, Oct 23, 2019 at 10:47 AM Santosh P K
>>         <mailto:[email-masked]>> wrote:
>>
>>             Dinesh,
>>                 - 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.
>>
>>                 - 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
>>             [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.
>>
>>
>>                 On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky
>>>                 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
>>>                     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
>>>
>>>>                     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
>>>>                         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:
>>>>
>>>>                         The current text reflects #2. Is WG accepts
>>>>                         this scope? If not, which option WG would
>>>>                         accept?
>>>>
>>>>                         Regards,
>>>>                         Greg
>>>>
>>>>                             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
>>>>                                 >> 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
>>>>                                 > 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
>>>>                                  Data Center Network (IP)        |
>>>>                                 >>>                      |         
>>>>                                                                |
>>>>                                 >>>                     
>>>>                                  Tunnel Overlay      |
>>>>                                 +----------+-------+ |       |
>>>>                                 >>>              | |  Overlay
>>>>                                 Module  | |       | |  Overlay
>>>>                                 +---------+--------+ |       |
>>>>                                 >>>       NVE1   |           |     
>>>>                                 +--------+-------+  |       | 
>>>>                                 +-+-----+----+---+  |       | 
>>>>                                    Tenant        |     |     |
>>>>                                 >>> To my understanding, the BFD
>>>>                                 sessions between NVE1 and NVE2 are
>>>>                                 actually
>>>>                                 >>> NVE1 and VAP1of NVE2, at the
>>>>                                 same time another BFD session
>>>>                                 between VAP3 of

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 28 Oct 2019 10:32:16 -0700

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 <[email-masked]>
wrote:

> >>>>                                 >>     Thanks for your explanation.
> >>>>                                 This helps a lot. I would wait for
> more
> >>>>                                 >>> Below is a figure derived from
> >>>>                                 figure 2 of RFC8014 (An Architecture
> for
> >>>>                                 >>> Data-Center Network
> >>>>                                 >>> VNI1, I believe it's reasonable,
> >>>>                                 so that's why I think we should allow
> it
> >>>>
> >>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Oct 2019 13:46:15 -0400

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.
> 
> On Mon, Oct 28, 2019 at 10:22 AM Joel M. Halpern <[email-masked] 
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     Dinesh, Anoop et all,
>      >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >         <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>         Hi Dinesh, et al.,
>     <mailto:[email-masked]>>> wrote:
>      >>
>      >>             Dinesh,
>      >>>                 <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>>
>     <mailto:[email-masked]>>> wrote:
>      >>>>                     Greg,
>      >>>>
>     <mailto:[email-masked]>>> wrote:
>      >>>>
>      >>>>                         Hi Anoop, et al.,
>     <mailto:[email-masked]>>> wrote:
>      >>>>
>      >>>>                             I concur with Joel's assessment
>     with the
>      >>>>                             following clarifications.
>      >>>>
>      >>>>                             On Tue, Oct 22, 2019 at 6:06 AM
>     Joel M.
>      >>>>                             Halpern <[email-masked]
>     <mailto:[email-masked]>>> 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
>      >>>>                                 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
>      >>>>                                 >> supported based on that we can
>      >>>>                                 > The threads on the list have
>      >>>>                                 > to follow what the current
>     status
>      >>>>                                 of the draft is, or should
>     be.  :-)
>      >>>>                                 >
>      >>>>                                 > However, if I've followed things
>      >>>>                                 > Essentially, do we or do we not
>      >>>>                                 > If this is so, do we have a
>     sense
>      >>>>                                 as to how we should proceed?
>      >>>>                                 >
>      >>>>                                 > -- Jeff
>      >>>>                                 >
>      >>>>                                 >>> for the same VNI or not,
>     IMHO we
>      >>>>                                 should allow it, more
>     explanation as
>      >>>>                                 >>> follows.
>      >>>>                                 >>>
>      >>>>                                 >>> Data-Center Network
>      >>>>                                 Virtualization over Layer 3
>     (NVO3)).
>      >>>>                                 >>>
>      >>>>                                 >>>                      |
>      >>>>                                 >>>       NVE1   |           |
>      >>>>                                 >>>              |  |VNI1
>     VNI2  VNI1
>      >>>>                                 |  |       |  | VNI1 VNI2 VNI1
>      >>>>                                 >>>              |VAP1| VAP2|    |
>      >>>>                                 VAP3 |       |VAP1| VAP2|   
>      >>>>                                 >>>              TSI1 | TSI2|    |
>      >>>>                                 TSI3          TSI1| TSI2|   
>      >>>>                                 >>>                  +---+ +---+
>      >>>>                                 >>>                  |TS1| |TS2|
>      >>>>                                 |TS3|             |TS4| |TS5| 
>      >>>>                                 >>>                  +---+ +---+
>      >>>>                                 >>> To my understanding, the BFD
>      >>>>                                 >>> 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
>      >>>>                                 >>> 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
>      >>>>
>      >>>>

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 28 Oct 2019 10:58:21 -0700

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 <[email-masked]>
wrote:

> >      >>>>                          3. multiple BFD sessions per VNI
> between
> >      >>>>                             two VTEPs
> >      >>>>
> >      >>>>                                 > On Thu, Oct 03, 2019 at
> >      >>>>                                 >> comments from others to see
> if
> >      >>>>                                 this what we need in this
> >     draft to be
> >      >>>>                                 > to follow what the current
> >     status
> >      >>>>                                 > If this is so, do we have a
> >     sense
> >      >>>>                                 >>> 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.
> >      >>>>                                 >>>
> >      >>>>                                 figure 2 of RFC8014 (An
> >      >>>>                                 >>> Data-Center Network
> >      >>>>                                 >>>              |  |VNI1
> >      >>>>                                 >>>              |VAP1| VAP2|
> >      >>>>                                 >>>              TSI1 | TSI2|
> >      >>>>                                 >>>                  |TS1|
> |TS2|
> >      >>>>                                 >>> initiated and terminated
> >      >>>>                                 >>> If the network operator
> >      >>>>                                 >>> NVE1 and VAP3 of NVE2,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Oct 2019 14:07:22 -0400

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:
> 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 <[email-masked] 
>      > On Mon, Oct 28, 2019 at 10:22 AM Joel M. Halpern
>      >     in terms of the VxLAN architecture the IRB is an entity
>     behind the
>      >     VTEP,
>      >     not part of the VTEP.
>      >
>      >     Yours,
>      >     Joel
>      >
>      >      > 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
>      >      > <[email-masked]
>     <mailto:[email-masked]>>>> 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
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> 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
>      >      >         <[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>> 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
>      >      >>         <[email-masked]
>      >      >>         <mailto:[email-masked]
>     <mailto:[email-masked]>>>> 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
>      >      >>                 <[email-masked]
>      >      >>                 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
>      >      >>>                 <[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>> 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
>      >      >>>                     <[email-masked]
>     <mailto:[email-masked]>
>      >      >>>                     <mailto:[email-masked]
>      >      >>>>                     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
>      >      >>>>                     <[email-masked]
>      >      >>>>                     <mailto:[email-masked]
>     <mailto:[email-masked]>>>> 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 <[email-masked]
>     <mailto:[email-masked]>
>      >      >>>>                         <mailto:[email-masked]
>      >      >>>>
>      >      >>>>                             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
>      >      >>>>                             <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >      >>>>
>      >      >>>>                                  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
>      >      >>>>                                 <[email-masked]
>      >      >>>>                               
>       <mailto:[email-masked] <mailto:[email-masked]>
>      >      >>>>                                 >>
>      >      >>>>                                 >>> 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|
>      >      >>>>                                 >>>                 
>     +---+ +---+
>      >      >>>>                                 +---+             +---+
>      >      >>>>                                 >>>                 
>     |TS1| |TS2|
>      >      >>>>                                 |TS3|             |TS4|
>      >      >>>>                                 >>>                 
>     +---+ +---+
>      >      >>>>                                 +---+             +---+
>      >      >>>>                                 >>>
>      >      >>>>                                 >>> 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
>      >      >>>> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >      >>>> https://www.ietf.org/mailman/listinfo/nvo3
>      >      >>>>
>      >
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 28 Oct 2019 11:30:00 -0700

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 <[email-masked]>
wrote:

> >      >      > Does it have to be a MUST?  What if I am running IRB and
> there
> >      >     are IP
> >      >      >     "As per section 4 inner destination IP address MUST be
> >     set to
> >      >     127/8
> >      >      >     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
> >      >      >     On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt
> >      >      >         Looks good to me Greg. I see that the text around
> >     the use
> >      >     of the
> >      >      >>                 packets intended for a Hypervisor VTEP
> MUST
> >      >     NOT..". I
> >      >      >>                 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
> >      >     <mailto:[email-masked] <mailto:[email-masked]
> >>>>
> >      >      >>                 wrote:
> >      >      >>>                 Hi Dinesh,
> >      >      >>>                     please point me to the latest draft
> >     so that
> >      >     I can
> >      >      >>>>                     that explains why that is needed in
> the
> >      >     context
> >      >      >>>>                         being defined in the current
> >     version
> >      >     of the
> >      >      >>>>                          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
> >      >      >>>>                         On Tue, Oct 22, 2019 at 2:09 PM
> >     Anoop
> >      >      >>>>                         Ghanwani <[email-masked]
> >      >      >>>>                             The current document is
> already
> >      >      >>>>                             The issue under discussion
> >     was how
> >      >     do we
> >      >      >>>>                             we cannot have a situation
> with
> >      >     multiple
> >      >      >>>>                             VAPs using the same
> >     VNI--there is 1:1
> >      >      >>>>                                 The document we have is
> >      >      >>>>                                 need for that document
> >      >      >>>>                                 encoding will be a
> >      >      >>>>                                 defined in this
> >      >      >>>>                                 > On Thu, Oct 03, 2019
> at
> >      >      >>>>                                 +0530, Santosh P K
> >      >      >>>>                                 >> comments from others
> >      >      >>>>                                 this what we need in
> >      >      >>>>                                 provide appropriate
> >      >      >>>>                                 > hinge point on what
> our
> >      >      >>>>                                 >>> for the same VNI or
> >      >      >>>>                                 +------------+---------+
> >      >      >>>>                                 +----------+-------+ |
> >      >      >>>>                                 Module  | |       | |
> >      >      >>>>                                 >>>       NVE1   |
> |VNI1
> >      >      >>>>                                 |  |       |  | VNI1
> >      >      >>>>                                 +-+-----+----+---+  |
> >      >      >>>>                                 VAP3 |       |VAP1|
> >      >      >>>>                                 +----+-----+----+------+
> >      >      >>>>                                 >>>              TSI1 |
> >      >      >>>>                                 TSI3          TSI1|
> >      >      >>>>                                 |TS3|             |TS4|
> >      >      >>>>                                 >>> initiated and
> >      >      >>>>                                 >>> If the network
> >      >      >>>>                                 >>> NVE1 and VAP3 of
> NVE2,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Oct 2019 15:55:25 -0400

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:
> On Mon, Oct 28, 2019 at 11:07 AM Joel M. Halpern <[email-masked] 
>      > On Mon, Oct 28, 2019 at 10:46 AM Joel M. Halpern
>      >     I can live with saying that you SHOULD use loopback, and MAY
>     instead
>      >     use
>      >      > 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
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>      >      >     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
>      >      >      > <[email-masked]
>      >      >     <mailto:[email-masked]
>      >      >     <mailto:[email-masked]
>      >      >     <mailto:[email-masked]
>      >      >      >     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
>      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> 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
>      >      >      >         <[email-masked]
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> 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
>      >      >      >>         <[email-masked]
>      >      >     <mailto:[email-masked]
>      >      >      >>         <mailto:[email-masked]
>      >      >     <mailto:[email-masked]
>      >      >      >>             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
>      >      >      >>                 <[email-masked]
>      >      >     <mailto:[email-masked]
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>>
>      >      >      >>                 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
>      >      >      >>>                 <[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> 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
>      >      >      >>>                     <[email-masked]
>     <mailto:[email-masked]>>>
>      >      >      >>>                     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>> 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
>      >      >      >>>>                     <[email-masked]
>      >      >     <mailto:[email-masked]
>      >      >      >>>>                   
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>> 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
>     <mailto:[email-masked]>>>
>      >      >      >>>>                       
>       <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>>>>> 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
>     <mailto:[email-masked]>>>
>      >      >      >>>>                           
>     <mailto:[email-masked]>>>>>
>      >     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
>      >      >      >>>>                               
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      >      >>>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>>
>      >     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 
>      >      >      >>>>                                 >>>
>      >      >      >>>>                               
>      >      >      >>>>                               
>      >      >      >>>>                                 >>>              |
>      >      >      >>>>                               
>      >      >      >>>>                               
>      >      >      >>>>                                 >>>             
>      >      >      >>>>                                 Module  | |     
>      >      >      >>>>                                 Module  | |
>      >      >      >>>>                                 >>>              |
>      >      >      >>>>                               
>      >      >      >>>>                               
>      >      >      >>>>                                 >>>              |
>      >      >      >>>>                                     |       |   
>      >      >      >>>>                                 >>>       NVE1   |
>      >      >      >>>>                                     |       |   
>      >      >      >>>>                                 NVE2
>      >      >      >>>>                                 >>>              |
>      >      >      >>>>                               
>      >      >      >>>>                               
>      >      >      >>>>                                 >>>             
>      >      >     VNI2  VNI1
>      >      >      >>>>                                 |  |       |  | VNI1
>      >      >     |  |
>      >      >      >>>>                                 >>>              |
>      >      >      >>>>                               
>      >      >      >>>>                               
>      >      >      >>>>                                 >>>             
>      >      >      >>>>                                 VAP3 |     
>      >      >      >>>>                                 >>>
>      >      >      >>>>                               
>      >      >      >>>>                               
>      >      >      >>>>                                 >>>
>      >      >      >>>>                                                  |
>      >      >      >>>>                                 >>>
>      >      >      >>>>                                                  |
>      >      >      >>>>                                 >>>
>      >      >      >>>>                                                  |
>      >      >      >>>>                                 >>>
>      >      >      >>>>
>      >      >      >>>>                                 >>>
>      >      >      >>>>                                    Tenant        |
>      >      >      >>>>                                 >>>             
>      >      >      >>>>                                 TSI3         
>     TSI1| TSI2|
>      >      >      >>>>                                 >>>
>      >      >      >>>>                                 +---+           
>      >      >      >>>>                                 >>>
>      >      >      >>>>                                 |TS3|           
>      >      >      >>>>                                 >>>
>      >      >      >>>>                                 +---+           
>      >      >      >>>>                                 >>>
>      >      >      >>>>                                 >>> To my
>      >      >      >>>>                                 sessions between
>      >      >      >>>>                                 actually
>      >      >      >>>>                                 >>> initiated and
>      >      >     at VAP
>      >      >      >>>>                                 of NVE.
>      >      >      >>>>                                 >>>
>      >      >      >>>>                                 >>> If the
>      >      >     want to
>      >      >      >>>>                                 set up one BFD
>      >      >     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
>      >      >      >>>> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >>>> https://www.ietf.org/mailman/listinfo/nvo3
>      >      >      >>>>
>      >      >
>      >
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 29 Oct 2019 08:10:21 -0700

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 <[email-masked]>
wrote:

> >      >     an IP address in the customer space known to be owned by the
> VTEP
> >      >     device
> >      >     when such exists.
> >      >
> >      >     Yours,
> >      >     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
> >      >      >
> >      >      >     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,
> >      >      >      > 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
> >      >      >      >
> >      >      >      >     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
> >      >      >      >     127/8 IP address is set as destination address
> >     in inner IP
> >      >      >     header."
> >      >      >      >
> >      >      >      >
> >      >      >      >     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
> https://tools.ietf.org/html/rfc4379#section-2.1>.
> >      >     This is an
> >      >      >      >         inner IP address as also quite acceptable.
> Will
> >      >     you add any
> >      >      >      >>         please check the updated version that
> >     removed the
> >      >      >     reference to
> >      >      >      >>                 - In section 3, there's a sentence
> >     that
> >      >     is: "BFD
> >      >      >      >>                 packets intended for a Hypervisor
> >     VTEP MUST
> >      >      >     NOT..". I
> >      >      >      >>                 - 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
> >      >      >      >>                    - Do we know if Firewalls stop
> >     such VXLAN
> >      >      >     packets?
> >      >      >      >>                 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.
> >      >      >      >>
> >      >      >      >>
> >      >      >      >>>                 I greatly appreciate your
> comments.
> >      >     Please heave a
> >      >      >      >>>                 look at the attached copy of the
> >     working
> >      >      >     version and
> >      >      >      >>>                     I have the same feeling as
> Anoop.
> >      >     Greg, can you
> >      >      >      >>>                     quickly glance through it to
> be
> >      >     doubly sure,
> >      >      >      >>>
> >      >      >      >>>                     Dinesh
> >      >      >      >>>
> >      >      >      >>>                     On Wed, Oct 23, 2019 at 4:35
> AM,
> >      >     Anoop Ghanwani
> >      >      >      >>>                     <[email-masked]
> >      >      >      >>>>                     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
> >      >      >      >>>>                     On Tue, Oct 22, 2019 at
> 11:17 AM
> >      >      >      >>>>                         I agree with your
> >      >      >      >>>>                         BFD over VxLAN
> >      >      >      >>>>                         before the WGLC is
> closed. I
> >      >      >      >>>>                          1. single BFD session
> >      >      >      >>>>                         The current text
> >      >      >      >>>>                         Ghanwani
> >      >      >      >>>>                             following
> >      >      >      >>>>                             The current document
> >      >      >      >>>>                             of monitoring
> >      >      >      >>>>                             use BFD to monitor
> >      >      >      >>>>                             use the same VNI
> >      >      >      >>>>                             VTEPs.  The use case
> >      >      >      >>>>                             clear to me, as from
> my
> >      >      >      >>>>                             we cannot have a
> >      >      >      >>>>                                  From what I can
> >      >      >      >>>>                                 The document we
> >      >      >      >>>>                                 need for that
> >      >      >      >>>>                                 multiple VNI
> >      >      >      >>>>                                 BFD monitoring
> >      >      >      >>>>                                 VTEPs (multiple
> >      >      >      >>>>                                 encoding will be
> >      >      >      >>>>                                 and thus
> >      >      >      >>>>                                 On 10/21/2019
> >      >      >      >>>>                                 > Santosh and
> >      >      >      >>>>                                 > On Thu, Oct
> >      >      >      >>>>                                 +0530, Santosh P
> >      >      >      >>>>                                 This helps a
> >      >      >      >>>>                                 >> comments from
> >      >      >      >>>>                                 this what we
> >      >      >      >>>>                                 >> supported
> >      >      >      >>>>                                 provide
> appropriate
> >      >      >      >>>>                                 > The threads on
> >      >      >      >>>>                                 spidered to the
> >      >      >      >>>>                                 > to follow what
> >      >      >      >>>>                                 > However, if
> I've
> >      >      >      >>>>                                 properly, the
> >      >      >      >>>>                                 > hinge point on
> >      >      >      >>>>                                 > Essentially,
> >      >      >      >>>>                                 require the
> >      >      >      >>>>                                 > If this is so,
> >      >      >      >>>>                                 as to how we
> >      >      >      >>>>                                 > [context
> preserved
> >      >      >      >>>>                                 >> On Wed, Sep
> >      >      >      >>>>                                 >>> With regard
> >      >      >      >>>>                                 whether we
> >      >      >      >>>>                                 should allow it,
> >      >      >      >>>>                                 >>> Below is a
> >      >      >      >>>>                                 figure 2 of
> >      >      >      >>>>                                 >>> Data-Center
> >      >      >      >>>>                                  Data Center
> >      >      >      >>>>                                  Tunnel Overlay
> VNI1
> >      >      >      >>>>                                 VAP3 |
> >      >      >      >>>>                                    Tenant
> >      >      >      >>>>                                 TSI3
> >      >      >      >>>>                                 |TS3|
> >      >      >      >>>>                                 >>> If the
> >      >      >      >>>>                                 set up one BFD
> >      >      >      >>>>                                 >>> NVE1 and
> VAP1of
> >      >      >      >>>>                                 same time
> >      >      >      >>>>                                 >>> NVE1 and
> >      >      >      >>>>                                 the two BFD
> >      >      >      >>>>                                 >>> VNI1, I
> >      >      >      >>>>                                 so that's why I

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Oct 2019 11:45:35 -0400

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:
> The version I had reviewed and commented on originally allowed for VNI 
> 0.  The -04 version of the draft has this:
> On Mon, Oct 28, 2019 at 12:55 PM Joel M. Halpern <[email-masked] 
>      > On Mon, Oct 28, 2019 at 11:07 AM Joel M. Halpern
>      >      > 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
>      >      >     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
>      >      >     <[email-masked] <mailto:[email-masked]>
>      >      >      > <mailto:[email-masked]
>      >      >      >     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
>      >      >      >      > <[email-masked]
>      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >      >     <mailto:[email-masked]
>      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>>> 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]
>      >      >      >      >   
>      >      >     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
>      >      >     <[email-masked] <mailto:[email-masked]>
>      >      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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
>      >      >      >      >         <[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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
>      >      >      >      >>         <[email-masked]
>      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >      >      >>       
>      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>>> 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
>      >      >      >      >>                 <[email-masked]
>      >      >      >     <mailto:[email-masked]
>      >      >      >     <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>>>
>      >      >      >      >>                 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
>      >      >      >      >>>                 <[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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
>      >      >      >      >>>                     <[email-masked]
>      >      >      >     <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >      >>>                   
>      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>>> 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
>      >      >      >      >>>>                   
>      >      >      >     <mailto:[email-masked]
>      >      >      >      >>>>
>      >      >      >     <mailto:[email-masked]
>      >      >      >      >>>>
>      >      >      >      >>>>                         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
>      >      >      >     <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >      >>>>
>     <mailto:[email-masked]>>
>      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>>> 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
>      >      >     <[email-masked] <mailto:[email-masked]>
>      >      >      >     <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >      >>>>
>      >      >      >     <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>>>
>      >      >     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
>      >      >      >      >>>>
>      >      >      >     <mailto:[email-masked]
>      >      >      >      >>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      >     <mailto:[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>>>
>      >      >     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|
>      >      >      >      >>>>                                 >>>
>      >      >      >      >>>>
>      >       +----+-----+----+------+
>      >      >      >      >>>>
>      >        +----+-----+-----+-----+
>      >      >      >      >>>>                                 >>>
>      >      >       |     |
>      >      >      >        |
>      >      >      >      >>>>                                          
>             |
>      >      >       |     |
>      >      >      >      >>>>                                 >>>
>      >      >       |     |
>      >      >      >        |
>      >      >      >      >>>>                                          
>             |
>      >      >       |     |
>      >      >      >      >>>>                                 >>>
>      >      >       |     |
>      >      >      >        |
>      >      >      >      >>>>                                          
>             |
>      >      >       |     |
>      >      >      >      >>>>                                 >>>
>      >      >      >      >>>>
>      >      >      >
>      >      >      >      >>>>                                 >>>
>      >      >      >        |
>      >      >      >      >>>>                                  
>      >      >      >      >>>>                                 >>>
>      >      >     TSI2|    |
>      >      >      >      >>>>                                 TSI3
>      >      >      >       |TSI3
>      >      >      >      >>>>                                 >>>
>      >      >     +---+ +---+
>      >      >      >      >>>>                                 +---+
>      >      >      >       +---+
>      >      >      >      >>>>                                 >>>
>      >      >     |TS1| |TS2|
>      >      >      >      >>>>                                 |TS3|
>      >      >     |TS5|
>      >      >      >       |TS6|
>      >      >      >      >>>>                                 >>>
>      >      >     +---+ +---+
>      >      >      >      >>>>                                 +---+
>      >      >      >       +---+
>      >      >      >      >>>>                                 >>>
>      >      >      >      >>>>                                 >>> To my
>      >      >     understanding, the BFD
>      >      >      >      >>>>                                 sessions
>      >      >     and NVE2 are
>      >      >      >      >>>>                                 actually
>      >      >      >      >>>>                                 >>>
>      >      >     terminated
>      >      >      >     at VAP
>      >      >      >      >>>>                                 of NVE.
>      >      >      >      >>>>                                 >>>
>      >      >      >      >>>>                                 >>> If the
>      >      >      >     want to
>      >      >      >      >>>>                                 set up
>     one BFD
>      >      >     between
>      >      >      >     VAP1 of
>      >      >      >      >>>>                                 >>> NVE1
>     and VAP1of
>      >      >     NVE2, at the
>      >      >      >      >>>>                                 same time
>      >      >     session
>      >      >      >      >>>>                                 between
>     VAP3 of
>      >      >      >      >>>>                                 >>> NVE1 and
>      >      >      >     although
>      >      >      >      >>>>                                 the two
>     BFD sessions
>      >      >     are for
>      >      >      >     the same
>      >      >      >      >>>>                                 >>> VNI1, I
>      >      >      >     reasonable,
>      >      >      >      >>>>                                 so that's
>     why I
>      >      >      >     should allow it
>      >      >      >      >>>>
>      >      >      >      >>>>
>      >      >      >       _______________________________________________
>      >      >      >      >>>>                                 nvo3
>     mailing list
>      >      >      >      >>>> [email-masked] <mailto:[email-masked]>
>      >      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>
>      >      >      >      >>>> https://www.ietf.org/mailman/listinfo/nvo3
>      >      >      >      >>>>
>      >      >      >
>      >      >
>      >
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 29 Oct 2019 08:55:09 -0700

Joel,

I think this would be better than disallowing anything other than an
address from the loopback subnet.

Thanks,
Anoop

On Tue, Oct 29, 2019 at 8:45 AM Joel M. Halpern <[email-masked]> wrote:

> >      >      >     an IP address in the customer space known to be owned
> >     by the VTEP
> >      >      >     device
> >      >      >     when such exists.
> >      >      >
> >      >      >     Yours,
> >      >      >     Joel
> >      >      >
> >      >      >      > Perhaps we need to say use of an address owned by
> >     the device
> >      >      >     containing
> >      >      >      > the VTEP.
> >      >      >      >
> >      >      >      >     There is something I am missing in your
> assumption
> >      >     about IRB.
> >      >      >      >
> >      >      >      >     Yes, an operator may offer IRB.  But as I
> >     understand it,
> >      >      >     conceptually,
> >      >      >      >      > addresses per VNI assigned to the VTEPs?
> >     Why can the
> >      >      >     operator not
> >      >      >      >      > choose to use those?
> >      >      >      >      >
> >      >      >      >      > Anoop
> >      >      >      >      >
> >      >      >      >      >           Lets us know if this text works
> >     for 127/8
> >      >      >     address range?
> >      >      >      >      >
> >      >      >      >      >     "As per section 4 inner destination IP
> >     address
> >      >     MUST be
> >      >      >     set to
> >      >      >      >     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
> >      >      >      >      >     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]
> >      >      >      >      >         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
> >      >      >      >      >>                 recommend getting rid of
> >      >      >      >      >>             [SPK] Thanks for comments. We
> will
> >      >     change this.
> >      >      >      >      >>
> >      >      >      >      >>                 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
> >      >      >      >      >>                 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
> >      >      >      >      >>             [SPK] I think we may need to
> >     add the text
> >      >      >     about firewall
> >      >      >      >      >>             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
> >      >      >      >      >>                 <[email-masked]
> >      >      >      >      >>>                 its diff to -07 (latest in
> the
> >      >     datatracker).
> >      >      >      >      >>>
> >      >      >      >      >>>                 Regards,
> >      >      >      >      >>>                 Greg
> >      >      >      >      >>>
> >      >      >      >      >>>                 On Tue, Oct 22, 2019 at
> >     9:52 PM
> >      >     Dinesh Dutt
> >      >      >      >      >>>                 <[email-masked]
> >      >      >      >      >>>                     I have the same
> >      >      >      >      >>>                     please point me to the
> >      >      >      >      >>>                     quickly glance through
> >      >      >      >      >>>                     On Wed, Oct 23, 2019
> >      >     <mailto:[email-masked] <mailto:[email-masked]
> >>>>
> >      >      >      >      >>>
> >      >      >      >      >>>>                     I discussion with
> >      >      >      >      >>>>                     see that as
> >      >      >      >      >>>>                     that explains why
> >      >      >      >      >>>>                     of the NVO3
> >      >      >      >      >>>>                     On Tue, Oct 22, 2019
> WG is
> >      >      >      >      >>>>                         before the WGLC
> >      >      >      >      >>>>                          1. single BFD
> >      >      >      >      >>>>                          2. single BFD
> >      >      >      >      >>>>                         this scope? If
> >      >      >      >      >>>>                         On Tue, Oct 22,
> >      >     <mailto:[email-masked] <mailto:[email-masked]
> >>>>
> >      >      >      >      >>>>
> >      >      >      >      >>>>                             I concur with
> >      >      >      >      >>>>                             The current
> >      >      >      >      >>>>                             The issue
> under
> >      >      >      >      >>>>                             use BFD to
> >      >      >      >      >>>>                             use the same
> >      >      >      >      >>>>                             VTEPs.  The
> >      >      >      >      >>>>                             clear to me,
> >      >      >      >      >>>>                             VAPs using
> >      >      >      >      >>>>                             mapping
> >      >      >      >      >>>>                             On Tue, Oct
> >      >      >      >      >>>>                                  From
> >      >      >      >      >>>>                                 need for
> >      >      >      >      >>>>                                 If folks
> >      >      >      >      >>>>                                 as a
> >      >      >      >      >>>>                                 encoding
> 10/21/2019
> >      >      >      >      >>>>                                 > On Thu,
> Oct
> >      >      >      >      >>>>                                 +0530,
> >      >      >      >      >>>>                                 This
> >      >      >      >      >>>>                                 this what
> >      >      >      >      >>>>                                 spidered
> >      >      >      >      >>>>                                 properly,
> >      >      >      >      >>>>                                 > hinge
> >      >      >      >      >>>>                                 require
> >      >      >      >      >>>>                                 > If this
> >      >      >      >      >>>>                                 as to how
> >      >     <mailto:[email-masked] <mailto:[email-masked]
> >>>>>>
> >      >      >     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
> >      >      >      >      >>>>                                 Module  |
> >      >      >      >      >>>>                                 Module  |
> >      >      >      >      >>>>                                 set up
> >      >      >      >      >>>>                                 the two
> >      >      >      >      >>>>                                 >>> VNI1,
> >      >      >      >      >>>>                                 so that's
> >      >      >      >      >>>>                                 nvo3

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 Oct 2019 16:56:52 -0400

Santosh,

> set to 127/8 IP address."

Would it be reasonable to suggest "SHOULD be set"?

Our motivation in this section is to offer what is likely to be a reasonable
default, without providing restriction from something more amenable to some
provider's requirement.

Similarly, based on this text, we'll get asked about "recommended" vs.
"RECOMMENDED".  What level of strength do you think we should have here?

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Oct 2019 22:08:55 -0400

I presume that most silicon implementations of VxLAN VTEPs do not have 
any logic for trapping out BFD packets under any circumstances.  While 
some may have been built anticipating this draft, we have to assume that 
many will not be able to support this.  So it goes when you add features 
to a protocol.

I can live with requrieing 127/8, or requiring ignoring the IP 
destination address.  I do think we should be clear about what is going 
in the field (since BFD requires it), and how it is to be processed.

Yours,
Joel

On 10/29/2019 9:59 PM, Dinesh Dutt 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 <[email-masked]> 
> 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:
>>      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 <[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]>> 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
>>     <mailto:[email-masked]> > <mailto:[email-masked]
>>     <mailto:[email-masked]>>> 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 >     <[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>> >      >
>>     >      > >      >     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 >     
>>     <mailto:[email-masked]>> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>> >      >      >
>>     <mailto:[email-masked] <mailto:[email-masked]>> >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>>>>
>>     wrote: >      >      > >      >      >     There is something I am
>>     missing in your assumption >     about IRB. >      >      > >     
>>     >     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, >      > 
>>     >      >     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 >      >      > 
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>>> >      >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>>>> >      >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>>> >      >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>>>>>> wrote: >      >      > 
>>         > >      >      >      >     Dinesh, Anoop et all, >      >   
>>       >      >           Lets us know if this text works for 127/8 > 
>>         >     address range? >      >      >      > >      >      >   
>>       >     [proposed text for firewall] >      >      >      > >     
>>     >     MUST be >      >     set to >      >      >     127/8 >     
>>     >     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 >     
>>     >     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 >     
>>     <mailto:[email-masked]>> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>> >      >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>> >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >   
>>       >      >     <mailto:[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]> >   
>>      <mailto:[email-masked] <mailto:[email-masked]>>> >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>> >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >       
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>> > 
>>     <mailto:[email-masked] <mailto:[email-masked]>> >   
>>     <mailto:[email-masked]>>>> >      >      >   
>>      <mailto:[email-masked] <mailto:[email-masked]> >   
>>     <mailto:[email-masked] <mailto:[email-masked]> >   
>>      <mailto:[email-masked] <mailto:[email-masked]>>> > 
>>     <mailto:[email-masked]>> >   
>>     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 >      >     
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>>> >      >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>>>> >      >      >      >> 
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>>> >      >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked]> >   
>>     <mailto:[email-masked]>>>>>> 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 >      >      >      >>       
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>> > 
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> <mailto:[email-masked]
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>> >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>> >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>> > 
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> <mailto:[email-masked]
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>>>> >      >      >      >>       
>>              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 >      >      >     
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> >      >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> >      >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>> >      >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>> >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>> >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>> >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>>>>> wrote: > 
>>         >      >      >>> >      >      >      >>>                   
>>      I have the same feeling as Anoop. >      >     Greg, can you >   
>>     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 >     
>>     <mailto:[email-masked]> <mailto:[email-masked]> >   
>>      <mailto:[email-masked] <mailto:[email-masked]>> > 
>>     <mailto:[email-masked]>>> >      >      >   
>>      <mailto:[email-masked] <mailto:[email-masked]> >   
>>     <mailto:[email-masked] <mailto:[email-masked]> >   
>>     >      >      >      >>>   <mailto:[email-masked]
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>> > 
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> >      >   
>>      <mailto:[email-masked] <mailto:[email-masked]> >   
>>      <mailto:[email-masked] <mailto:[email-masked]>>>>>>
>>     wrote: >      >      >      >>>>                     Greg, >     
>>     >      >      >>>> >      >      >      >>>>                     I
>>     think the draft is fine as is. >      >      >      >>>> >      > 
>>     >      >     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 >      >      >      >>>>   <[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]> >   
>>      <mailto:[email-masked] <mailto:[email-masked]>> > 
>>     <mailto:[email-masked]>>> >      >      >   
>>      <mailto:[email-masked] <mailto:[email-masked]> >   
>>     <mailto:[email-masked] <mailto:[email-masked]> >   
>>     >      >      >      >>>> >       <mailto:[email-masked]
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>> > 
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> >      >   
>>      <mailto:[email-masked] <mailto:[email-masked]> >   
>>     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 >   
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>> > 
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> <mailto:[email-masked]
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>> >      >      >      >>>> >     
>>     <mailto:[email-masked] <mailto:[email-masked]>> >   
>>     <mailto:[email-masked]>>> >      >      >   
>>      <mailto:[email-masked] <mailto:[email-masked]> >   
>>      <mailto:[email-masked] <mailto:[email-masked]>> > 
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>>>> 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 >     
>>     >     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 >      >   
>>     <mailto:[email-masked]>> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>> >      >      >   
>>      <mailto:[email-masked] <mailto:[email-masked]> >   
>>     <mailto:[email-masked] <mailto:[email-masked]> >   
>>      <mailto:[email-masked] <mailto:[email-masked]>>>> >   
>>       >      >      >>>> >       <mailto:[email-masked]
>>     <mailto:[email-masked]>> >      >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>> >     
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> <mailto:[email-masked]
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>>>> >      >     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. >     
>>     >      >      >>>>                                 > >      >     
>>     >      >     list have >      >      >      >>>>                 
>>                    spidered to the >     point >      >     where it
>>     is >      >      >      >>>>                               
>>      challenging >      >      >      >>>>                           
>>          > to follow what the >      >     current >      >      >   
>>      status >      >      >      >>>>                               
>>      of the draft is, >     or should >      >      >     be.  :-) > 
>>         >      >      >>>>                                 > >      > 
>>     >      >     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 >      >     
>>     >      >>>> >       <[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>> >     
>>     <mailto:[email-masked] <mailto:[email-masked]>>> >   
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> <mailto:[email-masked]
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>> >      >      >      >>>> >     
>>     <mailto:[email-masked] <mailto:[email-masked]>> >   
>>     <mailto:[email-masked] <mailto:[email-masked]>>> >   
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> <mailto:[email-masked]
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>>>> >      >     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 >      >     
>>     >      >     are for >      >      >     the same >      >      > 
>>         >>>>                                 >>> VNI1, I >     believe
>>     it's >      >      >     reasonable, >      >      >      >>>>   
>>                                  so that's why I >     think we >     
>>     >      >     should allow it >      >      >      >>>> >      >   
>>       >      >>>> >      >      >     
>>      _______________________________________________ >      >      > 
>>         >>>>                                 nvo3 mailing list >     
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>> >     <mailto:[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>> >      >     <mailto:[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>> >     <mailto:[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>> <mailto:[email-masked]
>>     <mailto:[email-masked]> >     <mailto:[email-masked]
>>     <mailto:[email-masked]>> >      >     <mailto:[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>> >     <mailto:[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>>> >      >      >      >>>>
>>     https://www.ietf.org/mailman/listinfo/nvo3 >      >      >     
>>     >>>> >      >      > >      > >

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 29 Oct 2019 21:56:12 -0700

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 <[email-masked]> wrote:

> 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
>
> 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:
> 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:
> version are you referring to? Thanks, Anoop On Mon, Oct 28, 2019 at 12:55
> PM Joel M. Halpern <[email-masked] <mailto:[email-masked]
> <[email-masked]>>> 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 <[email-masked] <mailto:[email-masked]
> <[email-masked]>> > <mailto:[email-masked] <[email-masked]>
> <mailto:[email-masked] <[email-masked]>>>> wrote: > >     I
> assumed this was only for the case where a tenant VNI was being used. > >
> >     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 >     <[email-masked] <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      > <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>> 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 >      >     <[email-masked] <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      > <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>>> 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 >      >      >      > <[email-masked] <
> mailto:[email-masked] <[email-masked]>> >
>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >
>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >
>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >
>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>>>>> wrote: >      >      >      > >
> >      >      >     Dinesh, Anoop et all, >      >      >      >
>  Lets us know if this text works for 127/8 >      >     address range? >
> >      >      >      > >      >      >      >     "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] >      >      >
>  This is an >      >      >      >     exception to the behavior defined in
> [RFC1122 >      >      >      >     <https://tools.ietf.org/html/rfc1122>]."
> >      >      >      > >      >      >      > >      >      >      > >
>     >     On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt >      >     <
> [email-masked] <mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>> >     <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>>>> >
> >      >     <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>>> >     <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>> >      >      >      >
>  <mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>> >      >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>> >     <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>>>>>>>
> 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 >      >      >      >         <
> [email-masked] <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>> >      >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>> >      >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>>>> wrote: >
> >      >      >>         Hi Dinesh, et al., >      >      >      >>
>  please check the updated version that >     removed the >      >      >
>  reference to >      >      >      >>         Hypervisor in the text and
> Figure 1. >      >      >      >> >      >      >      >>         Regards,
> >      >      >      >>         Greg >      >      >      >> >      >
>   >      >>         <[email-masked] <
> mailto:[email-masked] <[email-masked]>> >
>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >
>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>>> >      >      >      >>  <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >
>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >
>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>>>>> 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 >
> 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
> 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 >      >
> address, one that is >     owned >      >     by the >      >      >
>     - 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 >
>   >      >      >>                 <[email-masked] <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      >
>    <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      >
>    <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>>>> >      >
> >      >>                 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 >      >      >      >>>
>              <[email-masked] <mailto:[email-masked] <[email-masked]>>
> >     <mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>> >      >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>> >     <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>>> >
> >     <mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >     <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >     <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >     <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>>>> 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 >      >      >      >>>
>                <[email-masked] <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>> >      >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>> >      >      >
>     >>>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      >
>    <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>>>> wrote: >
> >      >      >>>>                     Greg, >      >      >      >>>> >
> 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 >      >      >      >>>>  <
> [email-masked] <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>> >      >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>> >      >      >
>     >>>> >       <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      >
>    <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>>>> 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 >
>  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 >     <[email-masked] <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      >
>    <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>> >      >      >
>     >>>> >       <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      >
>    <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>>>> 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 >      >     <
> [email-masked] <mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>> >      >      >
> >>>> >       <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>>>> >      >
>    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, >      >      >
> >     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 >      >      >
>  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
>                > sessions between >      >     distinct VAPs? >      >
> >      >>>>                                 > >      >      >      >>>>
>                              > If this is so, >     do we >      >     have
> a >      >      >     sense >      >      >      >>>>
>                      > -- Jeff >      >      >      >>>>
> [context preserved >      >     below...] >      >      >      >>>>
>                          > >      >      >      >>>>
>          >> Santosh P K >      >      >      >>>>
>        >> >      >      >      >>>>                                 >> On
> Wed, Sep >     25, 2019 >      >     at 8:10 AM >      >      >      >>>>
> >       <[email-masked] <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>>>
> >      >     <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      >
>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>> >      >      >
>   >>>> >      >       <mailto:[email-masked] <[email-masked]>
> <mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>> >      >      >
>  <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> >     <
> mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>>>>>> >      >
>  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 >          | >      >      >      >>>>
>                        >>> >      >      >      >>>> >
>  +------------+---------+ >      >      >      >>>> >
>   +---------+------------+ >      >      >      >>>>
>          >>>         | >      >      >      >>>> >
>  +----------+-------+ | >      >           | >      >      >      >>>> >
>    +-------+----------+ | >      >      >      >>>>
>     >      >      >>>>                                 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, >      >      >
> >      >     should allow it >      >      >      >>>> >      >      >
> >      >      >      >>>> [email-masked] <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked] <[email-masked]>>>>
> >      >     <mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked] <[email-masked]>>>>>
> <mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>> >     <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>> >      >     <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked] <[email-masked]>>>>
> >      >      >     <mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> <mailto:[email-masked]
> <[email-masked]> <mailto:[email-masked] <[email-masked]>>> >     <
> mailto:[email-masked] <[email-masked]> <mailto:[email-masked] <[email-masked]>>
> <mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
> <[email-masked]>>>>>> >      >      >      >>>>
> https://www.ietf.org/mailman/listinfo/nvo3 >      >      >      >>>> >
>   >      > >      > >
>
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 29 Oct 2019 23:10:16 -0700

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.

Thanks,
Anoop

On Tue, Oct 29, 2019 at 10:02 PM Dinesh Dutt <[email-masked]> 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 <[email-masked]>,
> wrote:
>
> Hi Dinesh,
>
> What would break?  If messages are trapped to CPU based on the MAC DA,
> what is the problem?
>
>        *b**f**d**_**c**o**n**f**i**g**_**l**o**c**a**l* *:* *b**f**d**_**d**s**t**_**i**p*: optional string
>> Hi Joel, Yes, existing implementations use VNI 0 for BFD over VXLAN.
>> Here are a couple of references:
>> <[email-masked]>> > <mailto:[email-masked]
>> <[email-masked]> <mailto:[email-masked] <[email-masked]>>>>
>> 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
>> Mon, Oct 28, 2019 at 10:46 AM Joel M. Halpern >     <[email-masked]
>> <mailto:[email-masked] <[email-masked]>> <
>> <[email-masked]>> <mailto:[email-masked] <[email-masked]>
>> <mailto:[email-masked] <[email-masked]>>> >     <
>> 7:51 AM Santosh P K >      >      >      > <[email-masked]
>> <mailto:[email-masked] <[email-masked]>> >
>> <[email-masked]>> >     <
>> mailto:[email-masked] <[email-masked]>>>> >
>> <[email-masked]>> >     <
>> <[email-masked]>> >     <
>> mailto:[email-masked] <[email-masked]>>>>>
>> <[email-masked]>> >     <
>> <[email-masked]>> >     <
>> mailto:[email-masked] <[email-masked]>>>> >
>> <[email-masked]>> >     <
>> <[email-masked]>> >     <
>> mailto:[email-masked] <[email-masked]>>>>>>>
>> 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>]." >
>>   >      >      > >      >      >      > >      >      >      > >      >
>> <[email-masked]>> >     <
>> mailto:[email-masked] <[email-masked]>>>> >
>> <[email-masked]>> >     <
>> <[email-masked]>> >     <
>> mailto:[email-masked] <[email-masked]>>>>>
>> <[email-masked]>> >     <
>> <[email-masked]>> >     <
>> mailto:[email-masked] <[email-masked]>>>> >
>> <[email-masked]>> >     <
>> <[email-masked]>> >     <
>> mailto:[email-masked] <[email-masked]>>>>>>>
>> 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 >
>>    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
>> >      >>             [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. >
>>   >      >      >> >      >      >      >> >      >      >      >>
>> >> >      >      >      >>                 Dinesh >      >      >      >>
>> >      >      >      >>                 On Wed, Oct 23, 2019 at 7:58 AM, >
>>    Greg Mirsky >      >      >      >>                 <
>>              <[email-masked] <mailto:[email-masked]
>> mailto:[email-masked] <[email-masked]>>> >      >     <
>> mailto:[email-masked] <[email-masked]>>>> >     <
>> mailto:[email-masked] <[email-masked]>>> >      >     <
>> mailto:[email-masked] <[email-masked]>>>>> >      >
>> mailto:[email-masked] <[email-masked]>>>>> >      >
>> >      >>>> >       <mailto:[email-masked] <[email-masked]>
>> <mailto:[email-masked] <[email-masked]>> <
>> mailto:[email-masked] <[email-masked]>>>>> >      >
>> >      >>>> >       <mailto:[email-masked] <[email-masked]>
>> <mailto:[email-masked] <[email-masked]>> <
>> <[email-masked]> <mailto:[email-masked]
>> <[email-masked]>>> >      >     <mailto:[email-masked]
>> <[email-masked]> <mailto:[email-masked]
>> <[email-masked]> <mailto:[email-masked]
>> <[email-masked]>>>> >      >      >     <
>> <[email-masked]> <mailto:[email-masked]
>> <[email-masked]> <mailto:[email-masked]
>> <[email-masked]>>> >     <mailto:[email-masked]
>> <[email-masked]> <mailto:[email-masked]
>> <[email-masked]> <mailto:[email-masked]
>> <[email-masked]>>>> >      >      >     <
>> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
>> <[email-masked]>>>> >      >     <mailto:[email-masked] <[email-masked]> <
>> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
>> mailto:[email-masked] <[email-masked]>>>>> <mailto:[email-masked]
>> <[email-masked]> <mailto:[email-masked] <[email-masked]>> >     <
>> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]
>> <[email-masked]>>> >      >     <mailto:[email-masked] <[email-masked]> <
>> <[email-masked]> <mailto:[email-masked] <[email-masked]>>>> >      >
>> mailto:[email-masked] <[email-masked]> <mailto:[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Oct 2019 07:21:47 -0400

Joel,

> On Oct 29, 2019, at 10:08 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> I presume that most silicon implementations of VxLAN VTEPs do not have any logic for trapping out BFD packets under any circumstances.  While some may have been built anticipating this draft, we have to assume that many will not be able to support this.  So it goes when you add features to a protocol.

Just to be clear, BFD itself (RFC 5880) doesn't necessarily require the IP portion of the stack. What's required is sufficient information for an implementation to manage the BFD session for the transport in question.

Things that tend to run IP usually end up with a bit of programming that tells it that the forwarding layer can trap on a given 5-tuple signature.  Things like BFD on LAG will catch a layer deeper in some circumstances such as startup.

This discussion is running rather similar (albeit more publicly) to the BFD on LAG discussion as various vendors try to figure out how they can successfully trap BFD for the testing point in question.

-- Jeff

---

From: Dinesh Dutt <[email-masked]>
Date: Thu, 24 Oct 2019 00:54:30 +0500

Dinesh

On Wed, Oct 23, 2019 at 8:36 PM, Greg Mirsky <[email-masked]> 
wrote:
> <[email-masked]> wrote:
>> Dinesh,
>>> 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 
>> checks in firewall will be there if they are not already using MPLS 
>> OAM which has inner IP header with 127/8 address range.
>> 
>>> 
>>> <[email-masked]> wrote:
>>>> Hi Dinesh,
>>>>> 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
>>>>> 
>>>>>> <[email-masked]> wrote:
>>>>>>> Hi Anoop, et al.,
>>>>>>>> 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
>>>>>>>> 
>>>>>>>>> sections in the draft.
>>>>>>>>> should be.  :-)
>>>>>>>>> permit multiple BFD
>>>>>>>>> |TS5|   |TS6|
>>>>>>>>> session between VAP3 of

---

From: Dinesh Dutt <[email-masked]>
Date: Thu, 24 Oct 2019 02:55:56 +0530

You're welcome Greg. I'm glad my input was useful,

Dinesh
On Oct 24, 2019, 1:33 AM +0530, Greg Mirsky <[email-masked]>, wrote:
> Hi Dinesh,
> many thanks for your time, the expertise you've kindly shared on this discussion.
> I believe that Santosh has volunteered ;) to provide some text on the firewall interaction. Any other contributions are welcome and greatly appreciated.
>
> Regards,
> Greg
>
> > > 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 <[email-masked]> 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 <[email-masked]> wrote:
> > > > > > Dinesh,
> > > > > > > > - 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.
> > > > > > > >
> > > > > > > > - 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.
> > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky <[email-masked]> 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
> > > > > > > > >
> > > > > > > > > > > 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 <[email-masked]> wrote:
> > > > > > > > > > > > Greg,
> > > > > > > > > > > >
> > > > > > > > > > > > > > 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:
> > > > > > > > > > > > > >

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 30 Oct 2019 06:59:38 +0500

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 <[email-masked]> 
wrote:
> 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
> 
>> Yes, existing implementations use VNI 0 for BFD over VXLAN.  Here 
>> 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:
>> On Mon, Oct 28, 2019 at 12:55 PM Joel M. Halpern 
>>      >     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
>>      >      >     I can live with saying that you SHOULD use 
>> loopback,
>>     and MAY
>>      >     instead
>>      >      >     use
>> by
>>      >      >      >     As such, it is a pure bridge.  If you run 
>> IRB
>>     behind
>>      >     it, that
>>      >      >     is fine.
>>      >      >      >     in terms of the VxLAN architecture the IRB 
>> is
>>     an entity
>>      >      >     behind the
>>      >      >      >     VTEP,
>>      >      >      >     not part of the VTEP.
>>      >      >      >
>>      >      >      >     Yours,
>>      >      >      >     Joel
>>      >      >      >
>>      >      >      >      >     127/8 IP address is set as 
>> destination
>>     address
>>      >     in inner IP
>>      >      >      >     header."
>>      >      >      >      >
>>      >      >      >      >
>>      >      >      >      >>                 - In section 3, there's 
>>      >      >      >      >>             [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.
>>      >      >      >      >>
>>      >      >      >      >>>                 I greatly appreciate 
>>      >      >      >      >>>                 look at the attached 
>> copy
>>      >      >      >      >>>                 its diff to -07 
>> (latest in the
>>      >      >      >      >>>                     please point me to 
>>      >      >      >      >>>                     quickly glance 
>> 2019
>> <mailto:[email-masked]>>>>
>>      >      >      >      >>>                         
>>      >      >      >      >>>>                     I think the draft 
>> 2019
>>      >      >      >      >>>>                         Hi Anoop, et 
>> al.,
>>      >      >      >      >>>>                         I agree with 
>>      >      >      >      >>>>                         being defined 
>> the WG is
>>      >      >      >      >>>>                         before the 
>> WGLC
>>      >      >      >      >>>>                         are three 
>> options:
>>      >      >      >      >>>>                          3. multiple 
>> 22,
>> <mailto:[email-masked]>>>>
>>      >      >      >      >>>>
>>      >      >      >      >>>>                             I concur 
>>      >      >      >      >>>>                             use the 
>> same VNI
>>      >      >      >      >>>>                             clear to 
>> me,
>>      >      >      >      >>>>                             On Tue, 
>> <mailto:[email-masked]>>>>
>>      >      >      >      >>>>
>> <mailto:[email-masked]>>>>>>
>>      >      >     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
>>      >      >      >      >>>>
>> <mailto:[email-masked]>>>>>>
>>      >      >     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)        |
>>      >      >      >      >>>>                                 >>>
>>      >              |
>>      >      >      >      >>>>
>>      >      >             |
>>      >      >      >      >>>>                                 >>>
>>      >      >      >      >>>>
>>      >      >      >       
>> NVE.
>>      >      >      >      >>>>                                 same 
>> time
>> two
>>      >      >      >      >>>>                                 so 
>> that's

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 30 Oct 2019 07:02:45 +0500

> Would it be reasonable to suggest "SHOULD be set"?

This sounds reasonable to me.

Dinesh

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 30 Oct 2019 10:31:42 +0530

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 <[email-masked]>, 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:
>       bfd_config_local : bfd_dst_ip: optional string
>              169.254.1.0.
> > > 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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]> > <mailto:[email-masked] <mailto:[email-masked]>>> 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 >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> 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 >      >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>> 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 >      >      >      > <[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >         <[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>         <[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>  <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>                 <[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> >      >      >      >>                 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 >      >      >      >>>                 <[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>>                     <[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>  <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>>>  <[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> >      >     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 >      >      >      >>>> >       <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >      >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> >      >     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 >      >      >      >>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>> >      >      >      >>>> https://www.ietf.org/mailman/listinfo/nvo3 >      >      >      >>>> >      >      > >      > >

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 30 Oct 2019 16:45:56 +0500

On Wed, Oct 30, 2019 at 11:40 AM, Anoop Ghanwani 
<[email-masked]> 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
>> 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 the flip side, there are implementations running BFD today which 
>>> use different addresses as specified here:
>>>> 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
>>>> 
>>>>> 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:
>>>>>> What version are you referring to? Thanks, Anoop On Mon, Oct 28, 
>>>>>> 2019 at 12:55 PM Joel M. Halpern <[email-masked] 
>>>>>> <mailto:[email-masked]>> 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, > 
>>>>>> <[email-masked] <mailto:[email-masked]> > 
>>>>>> 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 >     <[email-masked] 
>>>>>> 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 >      >     <[email-masked] 
>>>>>> 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. >      >      >     
>>>>>> 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 >      >      >      > 
>>>>>> <mailto:[email-masked]>>>>>> 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 
>>>>>>     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 
>>>>>> <mailto:[email-masked]>> <mailto:[email-masked] 
>>>>>> <mailto:[email-masked]>>> >      >     
>>>>>>      >      >      > >      >      >      >         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 >      >      >      >         
>>>>>> <[email-masked] <mailto:[email-masked]> >     
>>>>>> <mailto:[email-masked]>>> >     
>>>>>> <mailto:[email-masked]>>>>>> wrote: >      >      >      
>>>>>> 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 >      >      >     
>>>>>> <mailto:[email-masked]>>>>>> wrote: >      >      
>>>>>> >      >> >      >      >      >>             Dinesh, >      >   
>>>>>> [SPK] >      >      >      >> >      >      >      >> >      >   
>>>>>> >     that >      >     is: "BFD >      >      >      >>         
>>>>>> >      >     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 >      >      >     
>>>>>>  >     only two >      >      >      >>                 
>>>>>> questions: >      >      >      >>                    - Has 
>>>>>> anybody verified that the >     use of >      >     127/8 >      
>>>>>> works with >      >     existing >      >      >      >>         
>>>>>> ones? If this >      >      >      >>                 doesn't 
>>>>>> work there, is it worth >     adding the >      >      >     
>>>>>>   >     VTEP node? >      >      >      >> >      >      >      
>>>>>> >>                    - Do we know if Firewalls stop >     such 
>>>>>> VXLAN >      >      >     packets? >      >      >      >>       
>>>>>>           I ask this because VXLAN has an IP >     header >      
>>>>>>              know if firewalls stop packets >     with 127/8 >   
>>>>>>    >     in the >      >      >     inner >      >      >      
>>>>>>     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 >      >      > 
>>>>>> 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 >      >      >      >>                 
>>>>>> <[email-masked] <mailto:[email-masked]> >     
>>>>>> <mailto:[email-masked]> >     
>>>>>>    >      >>>                 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 >      > 
>>>>>>      >      >>>                 <[email-masked] 
>>>>>>    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 
>>>>>> >      >      >      >>>                     
>>>>>> <[email-masked] <mailto:[email-masked]> >     
>>>>>> <mailto:[email-masked]>>>> >      >      >      >>>  
>>>>>> >      >      >>>>                     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 
>>>>>> >      >      >      >>>>  <[email-masked] 
>>>>>> <mailto:[email-masked]> >     
>>>>>> <mailto:[email-masked]>>>> >      >      >      >>>> >    
>>>>>> <mailto:[email-masked]>>>>>> 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 >      >     
>>>>>>       before the WGLC is closed. I >      >     believe there >  
>>>>>>     >      >      >>>>                         are three 
>>>>>>                      1. single BFD session >     between >      
>>>>>> >     two VTEPs >      >      >      >>>>                        
>>>>>>           3. multiple BFD >     sessions per >      >     VNI 
>>>>>> between >      >      >      >>>>                             
>>>>>> two VTEPs >      >      >      >>>> >      >      >      >>>>    
>>>>>>                      The current text >     reflects #2. Is WG > 
>>>>>>      >      >     accepts >      >      >      >>>>              
>>>>>> would >      >      >      >>>>                         accept? 
>>>>>>            Regards, >      >      >      >>>>                    
>>>>>>      Greg >      >      >      >>>> >      >      >      >>>>    
>>>>>>                      On Tue, Oct 22, 2019 at >     2:09 PM >     
>>>>>>  >     Anoop >      >      >      >>>>                         
>>>>>> Ghanwani >     <[email-masked] 
>>>>>> <mailto:[email-masked]> >     
>>>>>>     >>>>                             The current document >     
>>>>>> is already >      >      >     capable >      >      >      >>>> 
>>>>>>                             of monitoring >     multiple VNIs >  
>>>>>>     >      >     between VTEPs. >      >      >      >>>> >      
>>>>>> >      >      >>>>                             The issue under > 
>>>>>> monitor >     multiple >      >     VAPs that >      >      >    
>>>>>>   >>>>                             use the same VNI >     
>>>>>> between a >      >     pair of >      >      >      >>>>         
>>>>>> 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 >      >      >      >>>>                     
>>>>>>                On Tue, Oct 22, 2019 >     at 6:06 AM >      >    
>>>>>>   >     Joel M. >      >      >      >>>>                        
>>>>>>      Halpern >      >     <[email-masked] 
>>>>>>                         The document we >     have is a >      > 
>>>>>>      >     VTEP-VTEP >      >      >      >>>>                   
>>>>>>               monitoring >     document. >      >     There is 
>>>>>> no >      >      >      >>>>                                 
>>>>>> 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 
>>>>>>    >>>>                                 Yours, >      >      >   
>>>>>>    >>>>                                 Joel >      >      >     
>>>>>> On 10/21/2019 >     5:07 PM, >      >     Jeffrey >      >      
>>>>>> >     Haas >      >      >      >>>>                             
>>>>>>     wrote: >      >      >      >>>>                             
>>>>>>                     > On Thu, Oct >     03, 2019 at >      >     
>>>>>>  >     07:50:20PM >      >      >      >>>>                      
>>>>>>            +0530, Santosh P >     K wrote: >      >      >      
>>>>>> >>>>                                 >>     Thanks >     for 
>>>>>> your >      >      >     explanation. >      >      >      >>>>  
>>>>>>                                This helps a lot. I >      >     
>>>>>> >>>>                                 >> 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 >   
>>>>>>    >      >      >>>>                                 
>>>>>>  >      >>>>                                 should look like. > 
>>>>>> Correct? >      >      >      >>>>                               
>>>>>> Essentially, >     do we or >      >     do we not >      >      
>>>>>> >      >>>>                                 require the >     
>>>>>>                               > sessions between >      >     
>>>>>>    > If this is so, >     do we >      >     have a >      >     
>>>>>>  >     sense >      >      >      >>>>                           
>>>>>> >>>>                                 > -- Jeff >      >      >   
>>>>>> >>>>                                 > [context preserved >      
>>>>>>         >> On Wed, Sep >     25, 2019 >      >     at 8:10 AM >  
>>>>>>     >      >      >>>> >       <[email-masked] 
>>>>>> <mailto:[email-masked]>> >      >     
>>>>>> <mailto:[email-masked]>> >     
>>>>>> >     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)        | >  
>>>>>>     >      >      >>>>                                 >>> >     
>>>>>>          | >      >      >      >>>> >      >             | >    
>>>>>>   >      >      >>>>                                 >>> >      
>>>>>> >      >      >>>> >      >      >       
>>>>>>  +----------+-------+ | >      >           | >      >      >     
>>>>>>                               >>> >     | | >      >     Overlay 
>>>>>> >      >      >      >>>>                                 Module 
>>>>>>  | | >       | | >      >     Overlay >      >      >      >>>>  
>>>>>>                                Module  | | >      >      >      
>>>>>> >>>>                                 >>>         | >      >      
>>>>>> >      >>>> >       +---------+--------+ | >      >           | 
>>>>>> >      >      >      >>>> >       +---------+--------+ | >      
>>>>>> >      >      >>>>                                 >>>         | 
>>>>>> >      >           | >      >      >      >>>>                   
>>>>>>                   |    | >             | >      >      >         
>>>>>>  | >      >      >      >>>>                                 >>> 
>>>>>>  NVE1   | >      >           | >      >      >      >>>>         
>>>>>>                             |    | >             | >      >      
>>>>>> >          | >      >      >      >>>>                           
>>>>>>       NVE2 >      >      >      >>>>                             
>>>>>>     >>>         | >      >      >      >>>> >       
>>>>>> +--------+-------+  | >      >           | >      >      >      
>>>>>> >>>> >       +--------+-------+  | >      >      >      >>>>     
>>>>>>                             >>> >     |  |VNI1 >      >      >   
>>>>>>   VNI2  VNI1 >      >      >      >>>>                           
>>>>>>       |  |  |  | VNI1 >      >     VNI2 VNI1 >      >      >     
>>>>>> |  | >      >      >      >>>>                                 
>>>>>> >>>         | >      >      >      >>>> >       
>>>>>>                             >>> >     |VAP1| >      >     VAP2|  
>>>>>> VAP3 | >       |VAP1| VAP2| >      >      >       | VAP3| >      
>>>>>> >      >      >>>>                                 >>> >      >  
>>>>>>     >      >>>> >       +----+-----+----+------+ >      >      > 
>>>>>>      >>>> >        +----+-----+-----+-----+ >      >      >      
>>>>>> >>>>                                 >>> >      >       |     | 
>>>>>> >      >      >        | >      >      >      >>>>        | >    
>>>>>>   >       |     | >      >      >      >>>>                      
>>>>>>            >>> >      >       |     | >      >      >        | > 
>>>>>>      >      >      >>>>        | >      >       |     | >      > 
>>>>>>      >      >>>>                                 >>> >      >    
>>>>>>    |     | >      >      >        | >      >      >      >>>>    
>>>>>>     | >      >       |     | >      >      >      >>>>           
>>>>>>                       >>> >      >      >      >>>> >      >     
>>>>>>  > >       
>>>>>>  Tenant        | >      >       |     | >      >      >      
>>>>>>    >>> >      >     |TS1| |TS2| >      >      >      >>>>        
>>>>>>                          |TS3| >       |TS4| >      >     |TS5| 
>>>>>> >      >      >       |TS6| >      >      >      >>>>            
>>>>>>                      >>> >      >     +---+ +---+ >      >      
>>>>>> >      >>>>                                 +---+ >       +---+ 
>>>>>> >      >     +---+ >      >      >       +---+ >      >      >   
>>>>>> 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 >      >      >      >>>>      
>>>>>>                  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 >     
>>>>>> <mailto:[email-masked] <mailto:[email-masked]>> >     
>>>>>> <mailto:[email-masked] <mailto:[email-masked]>>> >      >     
>>>>>> <mailto:[email-masked] <mailto:[email-masked]>> >     
>>>>>> <mailto:[email-masked] <mailto:[email-masked]> >     
>>>>>> <mailto:[email-masked] <mailto:[email-masked]>> >      >     
>>>>>> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >   
>>>>>> <mailto:[email-masked] <mailto:[email-masked]>> >     
>>>>>> <mailto:[email-masked] <mailto:[email-masked]>>>>> >      >      > 
>>>>>>      >>>> https://www.ietf.org/mailman/listinfo/nvo3 >      >    
>>>>>>   >      >>>> >      >      > >      > >
>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 30 Oct 2019 13:06:23 -0700

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 <[email-masked]> wrote:

>
>
> On Wed, Oct 30, 2019 at 11:40 AM, Anoop Ghanwani <[email-masked]>
> wrote:
>
> Hi Dinesh,
>
> 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
>
>>> 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,
>>> >      >     behind the >      >      >     VTEP, >      >      >     not
>>> part of the VTEP. >      >      > >      >      >     Yours, >      >
>>> >     Joel >      >      > >      >      >     On 10/28/2019 12:23 PM,
>>> Anoop Ghanwani wrote: >      >      >      > Santosh, >      >      >
>>> >     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 >      >      >      > <
>>> [email-masked] <mailto:[email-masked]
>>> mailto:[email-masked] <[email-masked]>>>>
>>> mailto:[email-masked] <[email-masked]>>>>
>>> mailto:[email-masked] <[email-masked]>>>>
>>> mailto:[email-masked] <[email-masked]>>>>
>>> mailto:[email-masked] <[email-masked]>>>> >      >
>>> mailto:[email-masked] <[email-masked]>>>>>>> wrote: >      >
>>> >      >>> >      >      >      >>>                     I have the same
>>> mailto:[email-masked] <[email-masked]>>>> >      >
>>> mailto:[email-masked] <[email-masked]>>>> >      >
>>>  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 >
>>>              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. >
>>> >      >      >>>> >      >      >      >>>>
>>>            On Tue, Oct 22, 2019 >     at 6:06 AM >      >      >     Joel
>>> M. >      >      >      >>>>                             Halpern >      >
>>>    <[email-masked] <mailto:[email-masked]
>>> mailto:[email-masked] <[email-masked]>>>> >      >      >
>>> mailto:[email-masked] <[email-masked]>>>> >      >      >

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Oct 2019 16:30:51 -0400

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

> 
> 
> 
> 
> 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
> 
>    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
> 
> 
>    In such case, for VTEPs BFD Control packets of that session are
> 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
> 
> 
>          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:
> 
>          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.
> 
>       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
> 
> 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
>    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
>    [email-masked]
>    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: [email-masked]
> 
> 
>    Sudarsan Paragiri
>    Individual Contributor
> 
>    Email: [email-masked]
> 
> 
>    Vengada Prasad Govindan
>    Cisco
> 
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> Pallagatti, et al.         Expires May 2, 2020                 [Page 10]
> 
> Internet-Draft                BFD for VXLAN                 October 2019
> 
> 
>    Mallik Mudigonda
>    Cisco
> 
>    Email: [email-masked]
> 
> 
>    Greg Mirsky
>    ZTE Corp.
> 
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 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">   [email-masked]</td><td> </td><td class="right">   [email-masked]</td><td class="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: [email-masked]</td><td> </td><td class="right">   Email: [email-masked]</td><td class="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: [email-masked]</td><td> </td><td class="right">   Email: [email-masked]</td><td class="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>

---

From: Selvakumar Sivaraj <[email-masked]>
Date: Wed, 30 Oct 2019 20:36:29 +0000

Greg,

>Section 5.
>If the Destination MAC of the inner Ethernet frame doesn't
>BFD Control packets with unknown MAC address MUST NOT be
> forwarded to VMs.

If the packet doesn’t match VTEP mac address, the packet is forwarded based on  Section 4.1 [RFC7348]. What is the assumption behind this statement “BFD Control packets with unknown MAC address MUST NOT be forwarded to VMs”?

Thanks,
Selvakumar

From: nvo3 <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Wednesday, October 30, 2019 at 1:08 PM
To: Dinesh Dutt <[email-masked]>
Cc: NVO3 <[email-masked]>, "[email-masked]" <[email-masked]>, Anoop Ghanwani <[email-masked]>, Santosh P K <[email-masked]>, Jeffrey Haas <[email-masked]>, rtg-bfd WG <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "T. Sridhar" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

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:

  *   firewall. Appended Section 3 Deployment with the following paragraph:

Regarding the use of VNI 0 as the Management VNI. In Section 6 has been noted:

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 <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Oct 30, 2019 at 11:40 AM, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>, wrote:

Hi Dinesh,

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<https://urldefense.com/v3/__http:/www.openvswitch.org/support/dist-docs/vtep.5.html__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D8TPFzme$>

              169.254.1.0.

Thanks,
Anoop

On Tue, Oct 29, 2019 at 7:01 PM Dinesh Dutt <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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<https://urldefense.com/v3/__https:/www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-740091.html*_Toc18013665__;Iw!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D-WWtRSX$> 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<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bfd-vxlan-04*section-7__;Iw!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D1ZHtv2T$> What version are you referring to? Thanks, Anoop On Mon, Oct 28, 2019 at 12:55 PM Joel M. Halpern <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> > <mailto:[email-masked] <mailto:[email-masked]>>> 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 >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> 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 >      >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>> 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 >      >      >      > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4379*section-2.1__;Iw!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D1QXo1ID$>>. >      >     This is an >      >      >      >     exception to the behavior defined in [RFC1122 >      >      >      >     <https://tools.ietf.org/html/rfc1122<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc1122__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D7jd9cRn$>>]." >      >      >      > >      >      >      > >      >      >      > >      >      >      >     Thanks >      >      >      >     Santosh P K >      >      >      > >      >      >      > >      >      >      > >      >      >      >     On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt >      >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >         <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>         <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>  <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>                 <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> >      >      >      >>                 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 >      >      >      >>>                 <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>>                     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>  <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>>>  <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> >      >     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 >      >      >      >>>> >       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >      >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> >      >     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 >      >      >      >>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>> >      >      >      >>>> https://www.ietf.org/mailman/listinfo/nvo3<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/nvo3__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70Dwxv3b_a$> >      >      >      >>>> >      >      > >      > >

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 30 Oct 2019 13:48:56 -0700

Hi Selvakumar,
a packet can be identified as a BFD Control message by the value of the
destination UDP port field. The intention of the text you've quoted is to
suggest that if the received by VTEP packet has been identified as a BFD
control packet it SHOULD NOT be forwarded to a tenant. What to do with such
packet? I believe it must be silently dropped.
Does it make sense?

Regards,
Greg

On Wed, Oct 30, 2019 at 1:36 PM Selvakumar Sivaraj <[email-masked]>
wrote:

> If the packet doesn’t match VTEP mac address, the packet is forwarded
> based on  Section 4.1 [RFC7348]. What is the assumption behind this
> statement “BFD Control packets with unknown MAC address MUST NOT be
> forwarded to VMs”?
>
>
>
> Thanks,
>
> Selvakumar
>
>
>
>
>
> *From: *nvo3 <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Wednesday, October 30, 2019 at 1:08 PM
> *To: *Dinesh Dutt <[email-masked]>
> *Cc: *NVO3 <[email-masked]>, "[email-masked]" <
> [email-masked]>, Anoop Ghanwani <[email-masked]>,
> Santosh P K <[email-masked]>, Jeffrey Haas <[email-masked]>,
> rtg-bfd WG <[email-masked]>, "Joel M. Halpern" <[email-masked]>,
> "T. Sridhar" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
>
>
>
> Dear All,
>
> <https://urldefense.com/v3/__http:/www.openvswitch.org/support/dist-docs/vtep.5.html__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D8TPFzme$>
>
> >>>
>
>        *bfd_config_local* *:* *bfd_dst_ip*: optional string
>
>               *169.254.1.0*.
> <https://urldefense.com/v3/__https:/www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-740091.html*_Toc18013665__;Iw!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D-WWtRSX$>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bfd-vxlan-04*section-7__;Iw!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D1ZHtv2T$>
> What version are you referring to? Thanks, Anoop On Mon, Oct 28, 2019 at
> 12:55 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]
>     >  <https://tools.ietf.org/html/rfc4379#section-2.1
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4379*section-2.1__;Iw!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D1QXo1ID$>>.
> >      >     This is an >      >      >      >     exception to the
> behavior defined in [RFC1122 >      >      >      >     <
> https://tools.ietf.org/html/rfc1122
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc1122__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D7jd9cRn$>>]."
> >      >      >      > >      >      >      > >      >      >      > >
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/nvo3__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70Dwxv3b_a$>
> >      >      >      >>>> >      >      > >      > >
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 30 Oct 2019 13:58:30 -0700

Hi Jeff,
thank you for your comments and suggestion. Please find my answers below
in-lined under the GIM>> tag.

Regards,
Greg

> detect BFD sessions between servers and change them to a concatenated
GIM>> No, we do not suggest that the concatenation of BFD sessions be
automagical. That may be controlled via the management plane though.

> deals with MAC addresses rather than the UDP procedures.
GIM>> Could you please clarify your suggestion - move to Section 4 or to
the preceding paragraph? I think it is the latter but wanted to make sure.

> what to
> logic is
> support, I
> it. The
> > >>> inner IPDA. >      > >      > Thanks, >      > Anoop >      > >
> > On
> > >>> mailto:[email-masked] <[email-masked]>>>>> wrote: >
> > >
> > >>> exists. >      > >      >     Yours, >      >     Joel >      > >
>   >
> Joel, >
> > >>> by the device >      >     containing >      >      > the VTEP. >
>   >
> > >>> address >     space >      >     is a MUST? >      >      > >
> >      >
> > >>> mailto:[email-masked] <[email-masked]>>>>>> wrote: >
> >
> > >>> not >      >      >      > choose to use those? >      >      >
> > >
> > >>>   >      >      > Anoop >      >      >      > >      >      >
> > On
> > >>> mailto:[email-masked] <[email-masked]>>>
> >
> > >>> mailto:[email-masked] <[email-masked]
> >>>>
> > >>> mailto:[email-masked] <[email-masked]>>>
> >
> > >>> mailto:[email-masked] <[email-masked]
> >>>>>
> > >>> mailto:[email-masked] <[email-masked]>>>
> >
> > >>> mailto:[email-masked] <[email-masked]
> >>>>
> > >>> mailto:[email-masked] <[email-masked]>>>
> >
> > >>> mailto:[email-masked] <[email-masked]
> >>>>>>>
> > >>> 127/8 >      >     address range? >      >      >      > >      >
>   >
>  firewall
> > >>> address >     in inner IP >      >      >     header." >      >
> >
> > >>> > >      >      >      > >      >      >      >     In section 4 we
> are
> > >>>     >      >     Thanks >      >      >      >     Santosh P K >
>   >
> > >>>   >      > >      >      >      > >      >      >      > >      >
>   >
> > >>> mailto:[email-masked] <[email-masked]>>>>> >      >      >
> >
> > >>> quite acceptable. Will >      >     you add any >      >      >
> >
> > >>>    words about the firewall? >      >      >      > >      >      >
>     >
> > >>>        Dinesh >      >      >      > >      >      >      >
>  On Wed,
> > >>> >      >>         On Wed, Oct 23, 2019 at 10:47 AM Santosh P K >
>   >
> > >>> mailto:[email-masked] <[email-masked]>>
> >
> > >>> mailto:[email-masked] <[email-masked]>>>
> >
> > >>> mailto:[email-masked] <[email-masked]
> >>>>
> > >>> mailto:[email-masked] <[email-masked]>>>
> >
> > >>> mailto:[email-masked] <[email-masked]
> >>>>>
> > >>> mailto:[email-masked] <[email-masked]>>>
> >
> > >>> mailto:[email-masked] <[email-masked]
> >>>>
> > >>> mailto:[email-masked] <[email-masked]>>>
> >
> > >>> mailto:[email-masked] <[email-masked]
> >>>>>>>
> > >>> wrote: >      >      >      >> >      >      >      >>
>  Dinesh,
> > >>> >      >      >      >>                  Please see my inline
> comments
> > >>> >>                 - In section 3, there's a sentence >     that >
>     >
> > >>> Hypervisor >     VTEP MUST >      >      >     NOT..". I >      >
>   >
> > >>> Thanks for comments. We will >     change this. >      >      >
> >> >
> > >>>    127/8 address in the inner header in >      >     MPLS. I have no
> >
> have >
>  questions: >
> > >>>     >     by the >      >      >     VTEP node? >      >      >
> >> >
>  and I >
> > >>>     >      >     don't >      >      >      >>                 know
> > >>> >     this case >      >     as well. >      >      >      >> >
> >
> > >>> >      >>             [SPK] I think we may need to add the text >
>   >
> > >>> firewall will be >     there if >      >     they are not >      >
>     >
> range. >
> > >>> >> >      >      >      >>                 Dinesh >      >      >
> > >>>          look at the attached copy of the >     working >      >
>   >
> > >>> Tue, Oct 22, 2019 at 9:52 PM >     Dinesh Dutt >      >      >
> >>>
> > >>> >      >>> >      >      >      >>>                     I have the
> > >>>  quickly glance through it to be >      >     doubly sure, >      >
>     >
> > >>>     >>> >      >      >      >>>                     Dinesh >      >
> > >>> >      >>> >      >      >      >>>                     On Wed, Oct
> 23,
> > >>>   >      >      >>>>                     Greg, >      >      >
> as is.
> > >>> discussion with Xiao Min was >      >     about #3 and I >      >
>   >
> Oct 22,
> > >>>  before the WGLC is closed. I >      >     believe there >      >
>   >
> > >>>   >>>>                         are three options: >      >      >
>   >>>>
> > >>> >      >      >      >>>>                          1. single BFD
> session >
> > >>> >      >>>>                             two VTEPs >      >      >
> > >>>  reflects #2. Is WG >      >      >     accepts >      >      >
> >>>>
> > >>> would >      >      >      >>>>                         accept? >
>   >
> > >>>   >      >>>> >      >      >      >>>>
>  Regards, >
> > >>>     >      >      >>>>                         Greg >      >      >
> > >>> >>>> >      >      >      >>>>                         On Tue, Oct
> 22, 2019
> > >>>                      The current document >     is already >      >
>     >
> > >>>    capable >      >      >      >>>>                             of
> > >>> monitoring >     multiple VNIs >      >      >     between VTEPs. >
>     >
> > >>>     >      >>>> >      >      >      >>>>
>  The
> monitor >
> for >
> > >>> M. >      >      >      >>>>                             Halpern >
> > >>>                   From what I can >     tell, >      >     there >
>     >
> > >>>     >     are two >      >      >      >>>>
> > >>>    The document we >     have is a >      >      >     VTEP-VTEP >
>     >
> > >>>     >      >>>>                                 monitoring >
>  document.
> > >>> >      >     There is no >      >      >      >>>>
> case. >
> > >>>     >      >      >>>>                                 If folks want
> a >
> > >>>  The >      >      >      >>>>
> > >>>  defined in this >     document. >      >      >      >>>> >      >
>     >
> > >>>     >>>>                                 Yours, >      >      >
> >>>>
> > >>>                                Joel >      >      >      >>>> >
> >
> > >>> >      >>>>                                 On 10/21/2019 >     5:07
> PM, >
> Santosh P >
> > >>>    K wrote: >      >      >      >>>>
> > >>>  Thanks >     for your >      >      >     explanation. >      >
>   >
> > >>>   >>>>                                 This helps a lot. I >      >
> we >
> > >>>  need in this >      >      >     draft to be >      >      >
> >>>>
> > >>>                              >> supported >     based on >      >
>  that
> > >>> we can >      >      >      >>>>
>  provide
> > >>>                      > The threads on the >      >     list have >
>     >
> > >>>     >      >>>>                                 spidered to the >
>  point
> > >>> >      >     where it is >      >      >      >>>>
> > >>>        challenging >      >      >      >>>>
> > >>>   >      >      >>>>                                 of the draft
> is, >
> > >>> >>>>                                 properly, the >     question >
>     >
> > >>>    below is >      >      >      >>>>
> > >>>  really the >      >      >      >>>>
>  >
> > >>>              encapsulation >     for BFD >      >     over vxlan >
>     >
> > >>>     >      >>>>                                 should look like. >
>     >
> > >>>     >      >>>>                                 > Correct? >      >
>     >
> > >>>     >>>>                                 > >      >      >      >>>>
> > >>>                > sessions between >      >     distinct VAPs? >
> >
> > >>> >      >>>>                                 > >      >      >
> >>>>
> > >>> Wed, Sep >     25, 2019 >      >     at 8:10 AM >      >      >
> >>>>
> > >>> mailto:[email-masked] <[email-masked]>>>>> >      >
>   >
> > >>>  wrote: >      >      >      >>>>                                 >>
> > >>>  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 >      >      >      >>>>
> > >>>   Data Center Network >      >     (IP)        | >      >      >
>   >>>>
> > >>>                                >>> >              | >      >      >
> > >>> >>>> >      >             | >      >      >      >>>>
> > >>>            >>> >      >      >      >>>> >      >      >
> > >>> >      >      >>>>                                 >>>         | >
>  | >
> > >>> >>>>                                     |    | >             | >
> > >>>  |  |  |  | VNI1 >      >     VNI2 VNI1 >      >      >     |  | >
>     >
> > >>>     >      >>>>                                 >>>         | >
> >
> > >>> >      >>>> >       +-+-----+----+---+  | >      >           | >
>   >
> > >>> >      >      >>>>                                 VAP3 | >
> > >>>   | >      >      >      >>>>        | >      >       |     | >
>  | >
> > >>>   >      >        | >      >      >      >>>>        | >      >
> > >>>  | >      >      >      >>>>                                 >>> >
>  | >
> > >>>   >      >        | >      >      >      >>>>  Tenant        | >
>  +---+ >
> > >>>    +---+ >      >     +---+ >      >      >       +---+ >      >
>   >
> > >>>   >>>>                                 >>> >      >     |TS1| |TS2| >
> > >>> >      >      >>>>                                 |TS3| >
>  |TS4| >
> > >>>  >>> To my >      >     understanding, the BFD >      >      >
> >>>>
> > >>> >>>>                                 of NVE. >      >      >
> > >>> >      >      >      >>>>                                 set up one
> BFD >
> > >>> >      >>>>                                 >>> NVE1 and VAP1of >
> > >>> >      >     should allow it >      >      >      >>>> >      >
> >
> > >>> >>>> >      >      >
> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> > <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">
> >
> >     span.hide { display: none; color: #aaa;}    a:hover span { display:
> inline; }    tr.change { background-color: gray; }
> >   <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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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="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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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">   [email-masked]</td><td>
> </td><td class="right">   [email-masked]</td><td
> class="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><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:
> [email-masked]</td><td> </td><td class="right">   Email:
> [email-masked]</td><td class="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:
> [email-masked]</td><td> </td><td class="right">   Email:
> [email-masked]</td><td class="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 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>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 Oct 2019 16:58:58 -0400

That sounds very dangerous.  If a VTEP receives a packet with an unknown 
MAC address on a VNI associated with a user, it could well have any UDP 
port value.  The BFD port value is NOT magically reserved on end systems 
that are not running BFD.  (We gave up on reserved ports long ago.)

Yours,
Joel

On 10/30/2019 4:48 PM, Greg Mirsky wrote:
> destination UDP port field. The intention of the text you've quoted is 
> to suggest that if the received by VTEP packet has been identified as a 
> BFD control packet it SHOULD NOT be forwarded to a tenant. What to do 
> with such packet? I believe it must be silently dropped.
> Does it make sense?
> 
> Regards,
> Greg
> 
> On Wed, Oct 30, 2019 at 1:36 PM Selvakumar Sivaraj <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Greg,____
> 
>     __ __
> 
>     >Section 5.____
> 
>     >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].____
> 
>     >BFD Control packets with unknown MAC address MUST NOT be____
> 
>     > forwarded to VMs.____
> 
>     __ __
> 
>     If the packet doesn’t match VTEP mac address, the packet is
>     forwarded based on  Section 4.1 [RFC7348]. What is the assumption
>     behind this statement “BFD Control packets with unknown MAC address
>     MUST NOT be forwarded to VMs”? ____
> 
>     __ __
> 
>     Thanks,____
> 
>     Selvakumar____
> 
>     __ __
> 
>     __ __
> 
>     *From: *nvo3 <[email-masked] <mailto:[email-masked]>>
>     on behalf of Greg Mirsky <[email-masked]
>     *To: *Dinesh Dutt <[email-masked] <mailto:[email-masked]>>
>     *Cc: *NVO3 <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>, Anoop Ghanwani
>     <[email-masked] <mailto:[email-masked]>>, Santosh P K
>     <mailto:[email-masked]>>, Jeffrey Haas <[email-masked]
>     <mailto:[email-masked]>>, rtg-bfd WG <[email-masked]
>     <mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]
>     <mailto:[email-masked]>>, "T. Sridhar" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     *Subject: *Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at
>     VTEP____
> 
>     __ __
> 
>     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:____
> 
>               IPv4, for IPv6 - from the range 0:0:0:0:0:FFFF:7F00:0/104.____
> 
>     NEW TEXT:____
> 
>               IP address.____
>       * firewall. Appended Section 3 Deployment with the following
>         paragraph:____
> 
>         destination UDP port is set to 3784 [RFC5881].____
> 
>     __ __
> 
>     Regarding the use of VNI 0 as the Management VNI. In Section 6 has
>     been noted:____
> 
>         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 <[email-masked]
>     <mailto:[email-masked]>> 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
>             <[email-masked] <mailto:[email-masked]>> 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
>                 <[email-masked] <mailto:[email-masked]>>,
>                 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:____
> 
>                     <https://urldefense.com/v3/__http:/www.openvswitch.org/support/dist-docs/vtep.5.html__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D8TPFzme$>____
> 
>                      >>>__ __
> 
>                     *bfd_config_local* *:* *bfd_dst_ip*: optional string____
> 
>                                    Set to an IPv4 address to set the IP
>                     address that is expected as____
> 
>                                    destination   for   received   BFD  
>                     packets.   The  default  is____
> 
>                     *169.254.1.0*.____
> 
>                      >>>__ __
> 
>                     __ __
> 
>                     Thanks,____
> 
>                     Anoop____
> 
>                     __ __
> 
>                     On Tue, Oct 29, 2019 at 7:01 PM Dinesh Dutt
>                     <[email-masked] <mailto:[email-masked]>> 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
>                         <[email-masked]
>                         ____
>                             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:
>                                 version I had reviewed and commented on
>                                 originally allowed for VNI 0.  The -04
>                                 version of the draft has this:
>                                 Thanks, Anoop On Mon, Oct 28, 2019 at
>                                 12:55 PM Joel M. Halpern
>                                 <[email-masked]
>                                 <mailto:[email-masked]>> 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.
>                                 <mailto:[email-masked]>>> wrote: >
>                                  >     address.  There are no addresses
>                                 assigned to the VTEP in that space. >   
>                                 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 >     <[email-masked]
>                                  >      > >      >     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 >     
>                                  >     <[email-masked]
>                                 <mailto:[email-masked]>>> >      > 
>                                 <mailto:[email-masked]>>>>> wrote:
>                                  >      >      > >      >      >   
>                                   There is something I am missing in
>                                 your assumption >     about IRB. >     
>                                  >      > >      >      >     As I
>                                   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 >      >      >      >
>                                 <mailto:[email-masked]>>>>>>
>                                 wrote: >      >      >      > >      > 
>                                  >      >      >      >           Lets
>                                 us know if this text works for 127/8 > 
>                                      >     address range? >      >     
>                                  >      > >      >      >      >   
>                                   [proposed text for firewall] >      > 
>                                      >      > >      >      >      >   
>                                 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 >      >      >      > 
>                                 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 >      >      >      >   
>                                   <https://tools.ietf.org/html/rfc4379#section-2.1 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4379*section-2.1__;Iw!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D1QXo1ID$>>. >      >     This is an >      >      >      >     exception to the behavior defined in [RFC1122 >      >      >      >     <https://tools.ietf.org/html/rfc1122 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc1122__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70D7jd9cRn$>>]." >      >      >      > >      >      >      > >      >      >      > >      >      >      >     Thanks >      >      >      >     Santosh P K >      >      >      > >      >      >      > >      >      >      > >      >      >      >     On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt >      >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >    <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >      <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>         <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>  <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>                 <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> >      >      >      >>                 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 >      >      >      >>>                 <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> >      > >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>>                     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>  <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >      >      >>>>  <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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 >      >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> >      >     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 >      >      >      >>>> >       <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>> >      >      >      >>>> >      >       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>>>>>> >      >     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 >      >      >      >>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> <mailto:[email-masked] <mailto:[email-masked]> >     <mailto:[email-masked] <mailto:[email-masked]>> >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> >      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>> >      >      >      >>>> https://www.ietf.org/mailman/listinfo/nvo3 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/nvo3__;!8WoA6RjC81c!XSnPbDk99ntaSkrho1h-7Nk38vE1gJ9GQ7udWfbGLtCOiKt6Yz9oRI70Dwxv3b_a$> >      >      >      >>>> >      >      > >      > >____
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Oct 2019 17:17:42 -0400

Greg,

> automagical. That may be controlled via the management plane though.

Then my suggestion is we may not want this text.

It's fine to say "if tenants want to run BFD to each other, and that is
standard BFD (RFC 5881) from the perspective of those tenants" if that's
your intent.  Leave automagic out of the spec. :-)

> the preceding paragraph? I think it is the latter but wanted to make sure.

Full section 5 from your draft-8 candidate:
: 5.  Reception of BFD Packet from VXLAN Tunnel
: 
:    Once a packet is received, the 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].

It's not clear what that procedure is, with respect to BFD.  Section 4.1
basically says is that when a mapping is discovered, deliver it to that VM
with headers removed.

Section 4.1 really doesn't discuss dropping behavior.

: 
:    BFD.

This is fine.

:    BFD Control packets with unknown MAC address MUST NOT be
:    forwarded to VMs.

This appears to be clarifying the missing point in the prior paragraph.  If
that's the case, why is this sentence not part of the prior paragraph?

-- Jeff

---

From: Selvakumar Sivaraj <[email-masked]>
Date: Thu, 31 Oct 2019 02:34:21 +0000

Greg,

Here the assumption is that the VTEP incorrectly received a BFD packet and it needs to be dropped. What if there is an end to end BFD and VTEP is only transporting those packets? If the tenant needs the BFD packet then this requirement to drop is making it mutually exclusive with VTEP BFD capability.

Thanks,
Selvakumar

From: Greg Mirsky <[email-masked]>
Date: Wednesday, October 30, 2019 at 1:49 PM
To: Selvakumar Sivaraj <[email-masked]>
Cc: Dinesh Dutt <[email-masked]>, NVO3 <[email-masked]>, "[email-masked]" <[email-masked]>, Anoop Ghanwani <[email-masked]>, Santosh P K <[email-masked]>, Jeffrey Haas <[email-masked]>, rtg-bfd WG <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "T. Sridhar" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

Hi Selvakumar,
a packet can be identified as a BFD Control message by the value of the destination UDP port field. The intention of the text you've quoted is to suggest that if the received by VTEP packet has been identified as a BFD control packet it SHOULD NOT be forwarded to a tenant. What to do with such packet? I believe it must be silently dropped.
Does it make sense?

Regards,
Greg

On Wed, Oct 30, 2019 at 1:36 PM Selvakumar Sivaraj <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Thanks,
Selvakumar

From: nvo3 <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 30, 2019 at 1:08 PM
To: Dinesh Dutt <[email-masked]<mailto:[email-masked]>>
Cc: NVO3 <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, Santosh P K <[email-masked]<mailto:[email-masked]>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, rtg-bfd WG <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>, "T. Sridhar" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

Dear All,

Regards,
Greg

Hi Anoop,

Dinesh

Thanks,
Anoop

Dinesh

              169.254.1.0.

Thanks,
Anoop

Dinesh

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 31 Oct 2019 08:48:08 -0700

Hi Jeff,
thank you for the detailed clarification of your questions. Please find my
follow-up notes in-lined tagged GIM2>>.

Regards,
Greg

> your intent.  Leave automagic out of the spec. :-)
GIM2>> I'd take the passage referring to the concatenated path out. That
will leave it as:
   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.

> that's the case, why is this sentence not part of the prior paragraph?
GIM>> So I thought. Moving the sentence to the first paragraph highlighted
the contradiction others had pointed earlier:
On the one hand:
   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].
To which we add:
   BFD Control packets with unknown MAC address
   MUST NOT be forwarded to VMs.
But the unknown MACs are treated as BUM according to the last paragraph in
Section 4.2 of RFC 7348:
   Note that multicast frames and "unknown MAC destination" frames are
   also sent using the multicast tree, similar to the broadcast frames.
In light of that, can this draft require that BFD packets with unknown MAC
be dropped and not flooded over the corresponding to the VNI domain? I
think that in addition to moving the sentence up the statement must be
updated:
OLD TEXT:
   BFD Control packets with unknown MAC address
   MUST NOT be forwarded to VMs.
NEW TEXT:
   If the BFD session is using the Management VNI (Section 6),
   BFD Control packets with unknown MAC address
   MUST NOT be forwarded to VMs.
 Comments? Suggestions?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 31 Oct 2019 11:59:14 -0400

Explicitly restricting the discard behavior to the management VNI takes 
care of my concern.

Thank you,
Joel

On 10/31/2019 11:48 AM, Greg Mirsky wrote:
> Hi Jeff,
> thank you for the detailed clarification of your questions. Please find 
> my follow-up notes in-lined tagged GIM2>>.
> 
> Regards,
> Greg
> 
> On Wed, Oct 30, 2019 at 2:14 PM Jeffrey Haas <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Greg,
> 
>      > On Wed, Oct 30, 2019 at 1:27 PM Jeffrey Haas <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      > > Greg,
>      > >
>      > > From the updated text:
>      > >
>     management. In
>     detection is
> GIM>> So I thought. Moving the sentence to the first paragraph 
> highlighted the contradiction others had pointed earlier:
> On the one hand:
> But the unknown MACs are treated as BUM according to the last paragraph 
> in Section 4.2 of RFC 7348:
> In light of that, can this draft require that BFD packets with unknown 
> MAC be dropped and not flooded over the corresponding to the VNI domain? 
> I think that in addition to moving the sentence up the statement must be 
> updated:
> OLD TEXT:

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 31 Oct 2019 12:21:59 -0400

I also agree with Joel.

-- Jeff

> On Oct 31, 2019, at 11:59 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Explicitly restricting the discard behavior to the management VNI takes care of my concern.
> 
> Thank you,
> Joel
> 
>> thank you for the detailed clarification of your questions. Please find my follow-up notes in-lined tagged GIM2>>.
>> Regards,
>> Greg
>> On Wed, Oct 30, 2019 at 2:14 PM Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>>    Greg,
>> GIM2>> I'd take the passage referring to the concatenated path out. That will leave it as:
>> GIM>> So I thought. Moving the sentence to the first paragraph highlighted the contradiction others had pointed earlier:
>> On the one hand:
>> But the unknown MACs are treated as BUM according to the last paragraph in Section 4.2 of RFC 7348:
>> In light of that, can this draft require that BFD packets with unknown MAC be dropped and not flooded over the corresponding to the VNI domain? I think that in addition to moving the sentence up the statement must be updated:
>> OLD TEXT:

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 31 Oct 2019 09:33:36 -0700

What is the definition of management VNI?  Is it that there is no VAP
corresponding to that VNI or something else?  If there is no VAP, then
there is no chance of forwarding such packets anyway.

Anoop

On Thu, Oct 31, 2019 at 9:22 AM Jeffrey Haas <[email-masked]> wrote:

> MAC be dropped and not flooded over the corresponding to the VNI domain? I

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 31 Oct 2019 12:43:25 -0400

I do assume there is no chance of forwarding the packet.  The reason for 
specifying it is to be clear what the VTEP is expected to do in that 
case.  (Which does mean the text has marginal, but non-zero value.)
Yours,
Joel

On 10/31/2019 12:33 PM, Anoop Ghanwani wrote:
> On Thu, Oct 31, 2019 at 9:22 AM Jeffrey Haas <[email-masked] 
>      > On Oct 31, 2019, at 11:59 AM, Joel M. Halpern
>      >> thank you for the detailed clarification of your questions.
>     Please find my follow-up notes in-lined tagged GIM2>>.
>      >> Regards,
>      >> Greg
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>    Greg,
>      >>     > On Wed, Oct 30, 2019 at 1:27 PM Jeffrey Haas
>     <[email-masked] <mailto:[email-masked]>
>      >>    <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>     >
>      >>     > > Greg,
>      >>     > >
>      >>     > > From the updated text:
>      >>     > >
>      >>     > > "At the same time, a service layer BFD session may be used
>      >>    between the
>      >>     > > tenants of VTEPs IP1 and IP2 to provide end-to-end fault
>      >>    management. In
>      >>     > > such case, for VTEPs BFD Control packets of that session are
>      >>     > > indistinguishable from data packets.  If end-to-end defect
>      >>    detection is
>      >>     > > realized as the set of concatenated OAM domains, e.g.,
>     VM1-1 -
>      >>    IP1 --
>      >>     > > IP2 - VM2-1, then the BFD session over VXLAN between
>     VTEPs SHOULD
>      >>     > > follow the procedures described in Section 6.8.17
>     [RFC5880]."
>      >>     > >
>      >>     > > In the case that two VMs are running BFD to each other
>     as a user
>      >>     > > application
>      >>     > > rather than as part of the virtualized environment, it's
>      >>    unlikely that
>      >>     > > they'd be treated as concatenated domains.  To do so, the
>      >>    tenant VMs would
>      >>     > > have to have a sense that they are indeed virtual.
>      >>     > >
>      >>     > > Is your intent in this text that BFD implementations on the
>      >>    server should
>      >>     > > detect BFD sessions between servers and change them to a
>      >>    concatenated
>      >>     > > session?
>      >>     > >
>      >>     > GIM>> No, we do not suggest that the concatenation of BFD
>     sessions be
>      >>     > automagical. That may be controlled via the management
>     plane though.
>      >>     > > Section 5 comment:
>      >>     > > :   The UDP destination port and the TTL of the inner IP
>     packet
>      >>    MUST be
>      >>     > > :   validated to determine if the received packet can be
>      >>    processed by
>      >>     > > :   BFD.  BFD Control packets with unknown MAC address
>     MUST NOT be
>      >>     > > :   forwarded to VMs.
>      >>     > >
>      >>     > > I'd suggest pushing the second sentence into the prior
>     section
>      >>    since it
>      >>     > > deals with MAC addresses rather than the UDP procedures.
>      >>     > >
>      >>     > GIM>> Could you please clarify your suggestion - move to
>     Section
>      >>    4 or to
>      >>     > the preceding paragraph? I think it is the latter but
>     wanted to
>      >>    make sure.
>      >>    basically says is that when a mapping is discovered, deliver
>     it to
>      >>    that VM
>      >>    with headers removed.
>      >> In light of that, can this draft require that BFD packets with
>     unknown MAC be dropped and not flooded over the corresponding to the
>     VNI domain? I think that in addition to moving the sentence up the
>     statement must be updated:
>      >> OLD TEXT:

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 31 Oct 2019 13:09:50 -0700

Thank you, Joel and Jeff.

I'll upload the working version shortly. I hope that updates will address
all comments and concerns shared on several threads by Anoop, Dinesh, Joel,
and many others. I greatly value and appreciate the time, expertise, and
consideration you've given to this work, and have shared with me.

Regards,
Greg