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 protected]> 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 protected]>
> 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 protected]>
> 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 protected]>
>>> 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 protected]> 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 protected]>
>>>> 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 protected]>
>>>> 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 protected]>
>>>>> 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 protected]>
>>>>>> 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 protected]> 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 protected]
>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>>
>>>>>>
