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

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

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

[Current text in section 4.0]

      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.


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



[proposed text for firewall]

"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 <[e-mail]>
wrote:

> Santosh,
>
> Does it have to be a MUST?  What if I am running IRB and there are IP
> addresses per VNI assigned to the VTEPs?  Why can the operator not choose
> to use those?
>
> Anoop
>
> On Mon, Oct 28, 2019 at 7:51 AM Santosh P K <[e-mail]>
> 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
>>>>>>>>>
>>>>>>>>