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 <[email protected]>
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 <[email protected]>
> 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 <[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
>>>>>>>>>
>>>>>>>>
