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 protected]] On Behalf Of Nobo Akiya > Sent: Friday, July 17, 2015 6:25 PM > To: Santosh P K > Cc: Reshad Rahman (rrahman); [email protected]; 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 protected]> 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 protected]] On Behalf Of S. Davari >> Sent: Friday, July 10, 2015 6:52 PM >> To: Nobo Akiya >> Cc: Reshad Rahman (rrahman); [email protected] >> >> 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 protected]> 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 protected]> >>> wrote: >>>> Sure. >>>> >>>> From: Rtg-bfd [mailto:[email protected]] On Behalf Of Shahram >>>> Davari >>>> Sent: Thursday, July 02, 2015 11:58 AM >>>> To: Reshad Rahman (rrahman); Shahram Davari >>>> Cc: [email protected] >>>> 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 protected]] On Behalf Of Reshad >>>> Rahman (rrahman) >>>> Sent: Thursday, July 02, 2015 5:46 AM >>>> To: Shahram Davari >>>> Cc: [email protected] >>>> 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 protected]> on behalf of Shahram Davari >>>> <[email protected]> >>>> Date: Thursday, July 2, 2015 at 12:25 AM >>>> To: Reshad <[email protected]> >>>> Cc: Shahram Davari <[email protected]>, "[email protected]" >>>> <[email protected]> >>>> 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 protected]> >>>>> 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 protected]> on behalf of Shahram Davari >>>>> <[email protected]> >>>>> Date: Tuesday, June 30, 2015 at 9:24 PM >>>>> To: Santosh P K <[email protected]>, "S. Davari" >>>>> <[email protected]>, "[email protected]" <[email protected]> >>>>> 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 protected]] >>>>> Sent: Tuesday, June 30, 2015 2:14 AM >>>>> To: S. Davari; Shahram Davari; [email protected] >>>>> 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 protected]] On Behalf Of S. Davari >>>>> Sent: Monday, June 29, 2015 10:48 AM >>>>> To: Shahram Davari; [email protected] >>>>> 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 protected]> 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 >>>>> >>>> >>>> >>> >>> >> > >
