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

[Santosh P K <[e-mail]>]

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

On Wed, Oct 23, 2019 at 11:40 AM Anoop Ghanwani <[e-mail]>
wrote:

> 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 <[e-mail]> 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 <[e-mail]>
>> wrote:
>>
>> Hi Dinesh,
>> I greatly appreciate your comments. Please heave a look at the attached
>> copy of the working version and its diff to -07 (latest in the datatracker).
>>
>> Regards,
>> Greg
>>
>> On Tue, Oct 22, 2019 at 9:52 PM Dinesh Dutt <[e-mail]> wrote:
>>
>>> I have the same feeling as Anoop. Greg, can you please point me to the
>>> latest draft so that I can quickly glance through it to be doubly sure,
>>>
>>> Dinesh
>>>
>>> On Wed, Oct 23, 2019 at 4:35 AM, Anoop Ghanwani <[e-mail]>
>>> wrote:
>>>
>>> Greg,
>>>
>>> I think the draft is fine as is.
>>>
>>> I discussion with Xiao Min was about #3 and I see that as unnecessary
>>> until we have a draft that explains why that is needed in the context of
>>> the NVO3 architecture.
>>>
>>> Anoop
>>>
>>> On Tue, Oct 22, 2019 at 11:17 AM Greg Mirsky <[e-mail]>
>>> wrote:
>>>
>>>> Hi Anoop, et al.,
>>>> I agree with your understanding of what is being defined in the current
>>>> version of the BFD over VxLAN specification. But, as I understand, the WG
>>>> is discussing the scope before the WGLC is closed. I believe there are
>>>> three options:
>>>>
>>>>    1. single BFD session between two VTEPs
>>>>    2. single BFD session per VNI between two VTEPs
>>>>    3. multiple BFD sessions per VNI between two VTEPs
>>>>
>>>> The current text reflects #2. Is WG accepts this scope? If not, which
>>>> option WG would accept?
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Tue, Oct 22, 2019 at 2:09 PM Anoop Ghanwani <[e-mail]>
>>>> wrote:
>>>>
>>>>> I concur with Joel's assessment with the following clarifications.
>>>>>
>>>>> The current document is already capable of monitoring multiple VNIs
>>>>> between VTEPs.
>>>>>
>>>>> The issue under discussion was how do we use BFD to monitor multiple
>>>>> VAPs that use the same VNI between a pair of VTEPs.  The use case for this
>>>>> is not clear to me, as from my understanding, we cannot have a situation
>>>>> with multiple VAPs using the same VNI--there is 1:1 mapping between VAP and
>>>>> VNI.
>>>>>
>>>>> Anoop
>>>>>
>>>>> On Tue, Oct 22, 2019 at 6:06 AM Joel M. Halpern <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>>  From what I can tell, there are two separate problems.
>>>>>> The document we have is a VTEP-VTEP monitoring document.  There is no
>>>>>> need for that document to handle the multiple VNI case.
>>>>>> If folks want a protocol for doing BFD monitoring of things behind
>>>>>> the
>>>>>> VTEPs (multiple VNIs), then do that as a separate document.   The
>>>>>> encoding will be a tenant encoding, and thus sesparate from what is
>>>>>> defined in this document.
>>>>>>
>>>>>> Yours,
>>>>>> Joel
>>>>>>
>>>>>> On 10/21/2019 5:07 PM, Jeffrey Haas wrote:
>>>>>> > Santosh and others,
>>>>>> >
>>>>>> > On Thu, Oct 03, 2019 at 07:50:20PM +0530, Santosh P K wrote:
>>>>>> >>     Thanks for your explanation. This helps a lot. I would wait
>>>>>> for more
>>>>>> >> comments from others to see if this what we need in this draft to
>>>>>> be
>>>>>> >> supported based on that we can provide appropriate sections in the
>>>>>> draft.
>>>>>> >
>>>>>> > The threads on the list have spidered to the point where it is
>>>>>> challenging
>>>>>> > to follow what the current status of the draft is, or should be.
>>>>>> :-)
>>>>>> >
>>>>>> > However, if I've followed things properly, the question below is
>>>>>> really the
>>>>>> > hinge point on what our encapsulation for BFD over vxlan should
>>>>>> look like.
>>>>>> > Correct?
>>>>>> >
>>>>>> > Essentially, do we or do we not require the ability to permit
>>>>>> multiple BFD
>>>>>> > sessions between distinct VAPs?
>>>>>> >
>>>>>> > If this is so, do we have a sense as to how we should proceed?
>>>>>> >
>>>>>> > -- Jeff
>>>>>> >
>>>>>> > [context preserved below...]
>>>>>> >
>>>>>> >> Santosh P K
>>>>>> >>
>>>>>> >> On Wed, Sep 25, 2019 at 8:10 AM <[e-mail]> wrote:
>>>>>> >>
>>>>>> >>> Hi Santosh,
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> With regard to the question whether we should allow multiple BFD
>>>>>> sessions
>>>>>> >>> for the same VNI or not, IMHO we should allow it, more
>>>>>> explanation as
>>>>>> >>> follows.
>>>>>> >>>
>>>>>> >>> Below is a figure derived from figure 2 of RFC8014 (An
>>>>>> Architecture for
>>>>>> >>> Data-Center Network Virtualization over Layer 3 (NVO3)).
>>>>>> >>>
>>>>>> >>>                      |         Data Center Network (IP)        |
>>>>>> >>>                      |                                         |
>>>>>> >>>                      +-----------------------------------------+
>>>>>> >>>                           |                           |
>>>>>> >>>                           |       Tunnel Overlay      |
>>>>>> >>>              +------------+---------+
>>>>>>  +---------+------------+
>>>>>> >>>              | +----------+-------+ |       |
>>>>>> +-------+----------+ |
>>>>>> >>>              | |  Overlay Module  | |       | |  Overlay Module
>>>>>> | |
>>>>>> >>>              | +---------+--------+ |       |
>>>>>> +---------+--------+ |
>>>>>> >>>              |           |          |       |           |
>>>>>>   |
>>>>>> >>>       NVE1   |           |          |       |           |
>>>>>>   | NVE2
>>>>>> >>>              |  +--------+-------+  |       |
>>>>>> +--------+-------+  |
>>>>>> >>>              |  |VNI1 VNI2  VNI1 |  |       |  | VNI1 VNI2 VNI1
>>>>>> |  |
>>>>>> >>>              |  +-+-----+----+---+  |       |
>>>>>> +-+-----+-----+--+  |
>>>>>> >>>              |VAP1| VAP2|    | VAP3 |       |VAP1| VAP2|     |
>>>>>> VAP3|
>>>>>> >>>              +----+-----+----+------+
>>>>>>  +----+-----+-----+-----+
>>>>>> >>>                   |     |    |                   |     |     |
>>>>>> >>>                   |     |    |                   |     |     |
>>>>>> >>>                   |     |    |                   |     |     |
>>>>>> >>>
>>>>>> -------+-----+----+-------------------+-----+-----+-------
>>>>>> >>>                   |     |    |     Tenant        |     |     |
>>>>>> >>>              TSI1 | TSI2|    | TSI3          TSI1| TSI2|     |TSI3
>>>>>> >>>                  +---+ +---+ +---+             +---+ +---+   +---+
>>>>>> >>>                  |TS1| |TS2| |TS3|             |TS4| |TS5|   |TS6|
>>>>>> >>>                  +---+ +---+ +---+             +---+ +---+   +---+
>>>>>> >>>
>>>>>> >>> To my understanding, the BFD sessions between NVE1 and NVE2 are
>>>>>> actually
>>>>>> >>> initiated and terminated at VAP of NVE.
>>>>>> >>>
>>>>>> >>> If the network operator want to set up one BFD session between
>>>>>> VAP1 of
>>>>>> >>> NVE1 and VAP1of NVE2, at the same time another BFD session
>>>>>> between VAP3 of
>>>>>> >>> NVE1 and VAP3 of NVE2, although the two BFD sessions are for the
>>>>>> same
>>>>>> >>> VNI1, I believe it's reasonable, so that's why I think we should
>>>>>> allow it
>>>>>>
>>>>>> _______________________________________________
>>>>>> nvo3 mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>
>>>>>