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