Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

From: Marc Binderberger <[email-masked]>
Date: Mon, 14 Sep 2015 02:36:21 -0700

Hello Santosh, Vengada et al.,

tuning in a bit late but nevertheless an interesting discussion. Being so 
late I almost expect a version -02 soon (?) :-)

May I encourage the authors to stick to BFD's simplicity. While all the 
comments I've seen have a valid point I do think the original idea of a 
simple unicast asynchronous BFD inside a VxLAN VNI is valid.

Nobo's idea of BFD echo on layer-2 is really nice and you should describe it 
in your document too - as an option. How the learning mechanism reacts to 
src-mac == dst-mac and if the silicon in a server-NIC supports 
decap-lookup-encap seems an implementation detail to me, thus why I would go 
for optional.

For the "shortcomings" of the unicast async approach: well, discuss them in 
the document. It may well be that an implementation can "inject" the 
BFD+ether-frame into the source VTEP hardware/mechanism to go through the 
whole lookup+encap, i.e. the AC->VxLAN forwarding. Just propose that an 
implementation should do so. Similar on the decapsulation side, if your VTEP 
MAC, local IP and BFD exist in a VM (e.g. OpenVswitch) then the delivery may 
be no different from the delivery of a packet to the other (Application) VMs. 
And if your VTEP is a switch/router there is always the option of a loopback 
cable to provide the true AC<->VxLAN experience :-) Just mention this as a 
hint to implementors.

The idea to use multicast packets is interesting. I would see it as an 
additional check as unicast and multicast may use different packet path in 
hardware/software, not as a replacement for unicast VxLAN BFD but I may be 
wrong.

For the document, you are a bit short on the motivation side, IMHO. Saying 
"Main use case of BFD for VXLAN is for tunnel connectivity check. There are 
other use cases such as [...]" and then saying more about the other use cases 
than your main case is a bit odd ;-)

Thanks & Regards,
Marc

On Sat, 18 Jul 2015 01:29:14 +0000, Vengada Prasad Govindan (venggovi) wrote:
> Hello Nobo,
>   While I do agree that there could be value in getting a self-destined 
> packet encapsulated in VxLAN as you describe below, the datapath flow of 
> VxLAN decap followed by a L2 lookup and a VxLAN (re)encap is not supported 
> on most silicon (Shahram, please correct me if I am wrong here) and hence 
> difficult to implement. Instead a VxLAN Async is what is proposed in the 
> draft.
> Thanks
> Prasad
>  
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya
> Sent: Friday, July 17, 2015 6:25 PM
> To: Santosh P K
> Cc: Reshad Rahman (rrahman); [email-masked]; S. Davari
> Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt
>  
> Hi Santosh,
>  
> Essentially the sender can periodically send self-destined packets (MAC-DA 
> = sender VTEP) that gets looped back on the remote VTEP (this better 
> exercises the VNI forwarding on the remote VTEP). Similar concept as BFD 
> echo.
>  
> Thanks!
>  
> -Nobo
>  
> On Fri, Jul 10, 2015 at 11:01 PM, Santosh P K <[email-masked]> wrote:
>> Nobo and Sharram,
>>      I am bit confused did you mean MAC-DA of the receiver VTEP? How would 
>> sender VTEP solve the problem? 
>>  
>>  
>> Thanks
>> Santosh P K 
>>  
>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of S. Davari
>> Sent: Friday, July 10, 2015 6:52 PM
>> To: Nobo Akiya
>> Cc: Reshad Rahman (rrahman); [email-masked]
>> 
>> Subject: Re: New Version Notification for 
>> draft-spallagatti-bfd-vxlan-00.txt
>>  
>> Yes that is the solution.
>> 
>> Regards,
>> Shahram
>>  
>> 
>> On Jul 10, 2015, at 12:12 AM, Nobo Akiya <[email-masked]> wrote:
>>> Long and interesting thread :)
>>>  
>>> How about setting the MAC-DA as the MAC of the sender VTEP?
>>>  
>>> Thanks!
>>>  
>>> -Nobo
>>>  
>>> On Fri, Jul 3, 2015 at 5:39 AM, Shahram Davari <[email-masked]> 
>>> wrote:
>>>> Sure.
>>>>  
>>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Shahram 
>>>> Davari
>>>> Sent: Thursday, July 02, 2015 11:58 AM
>>>> To: Reshad Rahman (rrahman); Shahram Davari
>>>> Cc: [email-masked]
>>>> Subject: RE: New Version Notification for 
>>>> draft-spallagatti-bfd-vxlan-00.txt
>>>>  
>>>> Agree. But we can may be come up with a more efficient solution.
>>>>  
>>>> Thx
>>>> SD
>>>>  
>>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Reshad 
>>>> Rahman (rrahman)
>>>> Sent: Thursday, July 02, 2015 5:46 AM
>>>> To: Shahram Davari
>>>> Cc: [email-masked]
>>>> Subject: Re: New Version Notification for 
>>>> draft-spallagatti-bfd-vxlan-00.txt
>>>>  
>>>> Hi Shahram,
>>>>  
>>>> Agreed. My point is that running BFD on the tunnel is not good enough 
>>>> for some failures.
>>>>  
>>>> Regards,
>>>> Reshad. 
>>>> 
>>>>  
>>>>  
>>>> From: Rtg-bfd <[email-masked]> on behalf of Shahram Davari 
>>>> <[email-masked]>
>>>> Date: Thursday, July 2, 2015 at 12:25 AM
>>>> To: Reshad <[email-masked]>
>>>> Cc: Shahram Davari <[email-masked]>, "[email-masked]" 
>>>> <[email-masked]>
>>>> Subject: Re: New Version Notification for 
>>>> draft-spallagatti-bfd-vxlan-00.txt
>>>>  
>>>> Hi Reshad, 
>>>>  
>>>> You don’t need to run continuous  BFD session per VNI to detect UDP port 
>>>> configuration issue. To justify running BFD per VNI, one needs to show 
>>>> that the forwarding of each of those BFD sessions depends on specific 
>>>> VNI value.   
>>>>  
>>>> Thx
>>>> Shahram
>>>>  
>>>>> On Jul 1, 2015, at 6:22 PM, Reshad Rahman (rrahman) <[email-masked]> 
>>>>> wrote:
>>>>>  
>>>>> Hi Shahram,
>>>>>  
>>>>> I agree that running BFD between VTEPs per VNI might not scale well. 
>>>>> But by just running BFD on the IP tunnel IMO you won’t detect certain 
>>>>> problems, maybe hypothetical, such as the UDP port being blocked (e.g. 
>>>>> Due to a misconfigured ACL).
>>>>>  
>>>>> Regards,
>>>>> Reshad.
>>>>>  
>>>>> From: Rtg-bfd <[email-masked]> on behalf of Shahram Davari 
>>>>> <[email-masked]>
>>>>> Date: Tuesday, June 30, 2015 at 9:24 PM
>>>>> To: Santosh P K <[email-masked]>, "S. Davari" 
>>>>> <[email-masked]>, "[email-masked]" <[email-masked]>
>>>>> Subject: RE: New Version Notification for 
>>>>> draft-spallagatti-bfd-vxlan-00.txt
>>>>>  
>>>>> Santosh,
>>>>>  
>>>>> Is the BFD you  are describing in your draft unicast or multicast? If 
>>>>> unicast then service nodes would not apply.
>>>>>  
>>>>> Also if there is a service node then one can run BFD on the IP tunnel 
>>>>> between source VTEP and service node and between service node and the 
>>>>> destination VTEP. This is much more scalable than running end-to-end 
>>>>> BFD between VTEPs per VNI. You could even use such BFD to switch to a 
>>>>> backup service node if there is failure to the main service node.
>>>>>  
>>>>> Thx
>>>>> Shahram
>>>>>  
>>>>> From: Santosh P K [mailto:[email-masked]] 
>>>>> Sent: Tuesday, June 30, 2015 2:14 AM
>>>>> To: S. Davari; Shahram Davari; [email-masked]
>>>>> Subject: RE: New Version Notification for 
>>>>> draft-spallagatti-bfd-vxlan-00.txt
>>>>>  
>>>>> There can be few VTEPs who might have capabilities to multicast the 
>>>>> packet. In such a scenario VTEP will send that packet to service node 
>>>>> and service node will do a multicast on its behalf. 
>>>>>  
>>>>>  
>>>>> Thanks
>>>>> Santosh P K
>>>>>  
>>>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of S. Davari
>>>>> Sent: Monday, June 29, 2015 10:48 AM
>>>>> To: Shahram Davari; [email-masked]
>>>>> Subject: Re: New Version Notification for 
>>>>> draft-spallagatti-bfd-vxlan-00.txt
>>>>>  
>>>>> Hi
>>>>>  
>>>>> What is a service node?
>>>>>  
>>>>> Thx
>>>>>  
>>>>> Sd
>>>>>  
>>>>>  
>>>>>> Hi Prasad ,
>>>>>> 
>>>>>> I don't see how you get more coverage having a VXLAN tag. 
>>>>>> 
>>>>>> Since you are not testing the VXLAN based VFI/VRF forwarding. By that 
>>>>>> I mean you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding.
>>>>>> GVP1> One of the aspects of the next version of the draft will have a 
>>>>>> valid inner DIP instead of 127/8. This should help address your 
>>>>>> concern to an extent.
>>>>>> Also you are not testing the mapping from AC (Attachment Circuit) to a 
>>>>>> VXLAN tag. 
>>>>>> GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 as 
>>>>>> well, not using it as an excuse but I am just noting the precedent 
>>>>>> here.
>>>>>> 
>>>>>> In my opinion all you are testing, is that at the other end of an IP 
>>>>>> Tunnel a specific VXLAN exist or not. Which does not require running 
>>>>>> continuous BFD.
>>>>>> GVP1> There are specific use-cases (see note about Service Node 
>>>>>> reachability in Sec 2 of the draft) that require continuous monitoring 
>>>>>> of some special-purpose VTEPs.
>>>>>> 
>>>>>> In my opinion this is a very in efficient way of getting that 
>>>>>> information. The controller should be able to get this information 
>>>>>> much more efficiently. 
>>>>>> 
>>>>>> It would be good if you can provide an example of what you think is 
>>>>>> more coverage than BFD. Or at least what extra coverage do you exactly 
>>>>>> have in mind, since this draft is not capable of more coverage than 
>>>>>> standard BFD over the IP tunnel. 
>>>>>> 
>>>>>> Regards,
>>>>>> Shahram
>>>>> Regards,
>>>>> Shahram
>>>>>  
>>>>> 
>>>>> On Jun 27, 2015, at 7:06 AM, Shahram Davari <[email-masked]> wrote:
>>>>>> Hi Prasad ,
>>>>>> 
>>>>>> I don't see how you get more coverage having a VXLAN tag. 
>>>>>> 
>>>>>> Since you are not testing the VXLAN based VFI/VRF forwarding. By that 
>>>>>> I mean you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding.
>>>>>> GVP1> One of the aspects of the next version of the draft will have a 
>>>>>> valid inner DIP instead of 127/8. This should help address your 
>>>>>> concern to an extent.
>>>>>> Also you are not testing the mapping from AC (Attachment Circuit) to a 
>>>>>> VXLAN tag. 
>>>>>> GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 as 
>>>>>> well, not using it as an excuse but I am just noting the precedent 
>>>>>> here.
>>>>>> 
>>>>>> In my opinion all you are testing, is that at the other end of an IP 
>>>>>> Tunnel a specific VXLAN exist or not. Which does not require running 
>>>>>> continuous BFD.
>>>>>> GVP1> There are specific use-cases (see note about Service Node 
>>>>>> reachability in Sec 2 of the draft) that require continuous monitoring 
>>>>>> of some special-purpose VTEPs.
>>>>>> 
>>>>>> In my opinion this is a very in efficient way of getting that 
>>>>>> information. The controller should be able to get this information 
>>>>>> much more efficiently. 
>>>>>> 
>>>>>> It would be good if you can provide an example of what you think is 
>>>>>> more coverage than BFD. Or at least what extra coverage do you exactly 
>>>>>> have in mind, since this draft is not capable of more coverage than 
>>>>>> standard BFD over the IP tunnel. 
>>>>>> 
>>>>>> Regards,
>>>>>> Shahram
>>>>> 
>>>> 
>>>>  
>>> 
>>>  
>> 
> 
>

---

From: Santosh P K <[email-masked]>
Date: Mon, 21 Sep 2015 11:17:17 +0000

Hello Marc,
   Sorry for delayed response. Please see my inline reply tagged [SPK].

> tuning in a bit late but nevertheless an interesting discussion. Being so late I
> almost expect a version -02 soon (?) :-)
> 

[SPK] Yes, we are working on it :).

> simple unicast asynchronous BFD inside a VxLAN VNI is valid.

[SPK] Sure we want to keep the BFD as simple as possible and not divert from base RFC 5880.

> decap-lookup-encap seems an implementation detail to me, thus why I

[SPK] We are discussing on this. Should we need to capture this in the same document or a separate document is required for this? WG can take decision based on WG inputs.

> cable to provide the true AC<->VxLAN experience :-) Just mention this as a

[SPK] Thanks for your suggestion. I think it really make sense to add them in our document. We will update our document accordingly. 

> hardware/software, not as a replacement for unicast VxLAN BFD but I may

[SPK] I don't think we have discussed more on this. I guess it is worth discussing on this and see if we reach any conclusion.

> than your main case is a bit odd ;-)

[SPK] Thanks again for suggestion. We will make the required changes. 

Thanks
Santosh P K