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 <xiao.m...@zte.com.cn> 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
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
