Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[Dinesh Dutt <[e-mail]>]

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 <[e-mail]> 
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 <[e-mail]> 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 
>> <[e-mail]> 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 
>>> <[e-mail]> 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 
>>>> <[e-mail]> 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 
>>>>> <[e-mail]> 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 <[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
>>>>>> 
>>>>>> _______________________________________________
>>>>>> nvo3 mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/nvo3