What kind of lookup happens in these service nodes? Do you do (inner DA, VXLAN/VNI) lookup? Do you keep the VXLAN or do you change it to new VXLAN? Where is this service node operation specified?
Thx SD 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]<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
