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] > <[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] <[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] > <[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 > > > > > >
