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 :). > > 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. [SPK] Sure we want to keep the BFD as simple as possible and not divert from base RFC 5880. > > 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. [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. > > 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. [SPK] Thanks for your suggestion. I think it really make sense to add them in our document. We will update our document accordingly. > > 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. [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. > > > 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 ;-) [SPK] Thanks again for suggestion. We will make the required changes. Thanks Santosh P K > > > 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]" <rtg- > [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 > >>>>> > >>>> > >>>> > >>> > >>> > >> > > > >
