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