Hi Silicon supports L2 lookup after VXLAN termination, and then re-encapsulation in another VXLAN Tunnel. The self MAC should also work if Split Horizon is not enabled.
Thx Shahram > On Jul 17, 2015, at 6:29 PM, Vengada Prasad Govindan (venggovi) > <[email protected]> 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] > <mailto:[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] > <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] <mailto:[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] > <mailto:[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] > <mailto:[email protected]>> wrote: > Sure. > > From: Rtg-bfd [mailto:[email protected] > <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] <mailto:[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] > <mailto:[email protected]>] On Behalf Of Reshad Rahman (rrahman) > Sent: Thursday, July 02, 2015 5:46 AM > To: Shahram Davari > Cc: [email protected] <mailto:[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] <mailto:[email protected]>> on > behalf of Shahram Davari <[email protected] > <mailto:[email protected]>> > Date: Thursday, July 2, 2015 at 12:25 AM > To: Reshad <[email protected] <mailto:[email protected]>> > Cc: Shahram Davari <[email protected] > <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" <[email protected] <mailto:[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] > <mailto:[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] <mailto:[email protected]>> on > behalf of Shahram Davari <[email protected] <mailto:[email protected]>> > Date: Tuesday, June 30, 2015 at 9:24 PM > To: Santosh P K <[email protected] <mailto:[email protected]>>, "S. > Davari" <[email protected] <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[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] > <mailto:[email protected]>] > Sent: Tuesday, June 30, 2015 2:14 AM > To: S. Davari; Shahram Davari; [email protected] <mailto:[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] > <mailto:[email protected]>] On Behalf Of S. Davari > Sent: Monday, June 29, 2015 10:48 AM > To: Shahram Davari; [email protected] <mailto:[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] > <mailto:[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
