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

[Anoop Ghanwani <[e-mail]>]

Santosh,

Does it have to be a MUST?  What if I am running IRB and there are IP
addresses per VNI assigned to the VTEPs?  Why can the operator not choose
to use those?

Anoop

On Mon, Oct 28, 2019 at 7:51 AM Santosh P K <[e-mail]>
wrote:

> Dinesh, Anoop et all,
>      Lets us know if this text works for 127/8 address range?
>
> [proposed text for firewall]
>
> "As per section 4 inner destination IP address MUST be set to 127/8
> address. There may be firewall configured on VTEP to block 127/8 address
> range if set as destination IP in inner IP header. It is recommended to
> allow 127/8 range address through firewall only if 127/8 IP address is set
> as destination address in inner IP header."
>
>
> In section 4 we are talking about using 127/8 and not really giving reason
> why. I think we should have text as RFC 5884 has mentioned with below text.
>
> [From RFC 5884]
> " The motivation for using the address range 127/8 is the same as specified
> in Section 2.1 of [RFC4379]
> <https://tools.ietf.org/html/rfc4379#section-2.1>. This is an exception
> to the behavior defined in [RFC1122 <https://tools.ietf.org/html/rfc1122>
> ]."
>
>
>
> Thanks
> Santosh P K
>
>
>
> On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt <[e-mail]> 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
>>>>>>>>
>>>>>>>