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

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

Dinesh, Anoop et all,
     Lets us know if this text works for 127/8 address range?

[proposed text for firewall]

"As per section 4 inner destination IP address MUST be set to 127/8
address. There may be firewall configured on VTEP to block 127/8 address
range if set as destination IP in inner IP header. It is recommended to
allow 127/8 range address through firewall only if 127/8 IP address is set
as destination address in inner IP header."


In section 4 we are talking about using 127/8 and not really giving reason
why. I think we should have text as RFC 5884 has mentioned with below text.

[From RFC 5884]
" The motivation for using the address range 127/8 is the same as specified
in Section 2.1 of [RFC4379]
<https://tools.ietf.org/html/rfc4379#section-2.1>. This is an exception to
the behavior defined in [RFC1122 <https://tools.ietf.org/html/rfc1122>]."



Thanks
Santosh P K



On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt <[e-mail]> wrote:

> Looks good to me Greg. I see that the text around the use of the inner IP
> address as also quite acceptable. Will you add any words about the firewall?
>
> Dinesh
>
> On Wed, Oct 23, 2019 at 8:36 PM, Greg Mirsky <[e-mail]>
> wrote:
>
> Hi Dinesh, et al.,
> please check the updated version that removed the reference to Hypervisor
> in the text and Figure 1.
>
> Regards,
> Greg
>
> On Wed, Oct 23, 2019 at 10:47 AM Santosh P K <[e-mail]>
> wrote:
>
>> Dinesh,
>>      Please see my inline comments [SPK]
>>
>>>
>>> - In section 3, there's a sentence that is: "BFD packets intended for a
>>> Hypervisor VTEP MUST NOT..". I recommend getting rid of the word
>>> "Hypervisor" ashe logic applies to any VTEP.
>>>
>>> [SPK] Thanks for comments. We will change this.
>>
>>
>>> - You already explained the precedence of the use of 127/8 address in
>>> the inner header in MPLS. I have no specific comments in that area. I have
>>> only two questions:
>>>    - Has anybody verified that the use of 127/8 address (and the right
>>> MAC) works with existing implementations, including the silicon ones? If
>>> this doesn't work there, is it worth adding the possibilit y of another
>>> address, one that is owned by the VTEP node?
>>>
>>    - Do we know if Firewalls stop such VXLAN packets? I ask this because
>>> VXLAN has an IP header and I don't know if firewalls stop packets with
>>> 127/8 in the inner header. If not, is it worth adding a sentence to say
>>> that firewalls  allow such packets? The use of a non-127/8 address may
>>> alleviate this case as well.
>>>
>>
>> [SPK] I think we may need to add the text about firewall as some checks
>> in firewall will be there if they are not already using MPLS OAM which has
>> inner IP header with 127/8 address range.
>>
>>
>>>
>>> The rest of the draft looks good to me,
>>>
>>> Dinesh
>>>
>>> On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky <[e-mail]>
>>> 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
>>>>>>>
>>>>>>