Greg,
Two comments, one minor and one maybe not.
- 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.
- 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.
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:
single BFD session between two VTEPs
single BFD session per VNI between two VTEPs
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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
