Re: BFD over VXLAN: Trapping BFD Control packet at VTEP

["Joel M. Halpern" <[e-mail]>]

 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