Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

[Nobo Akiya <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] *On Behalf Of *S. Davari
> *Sent:* Friday, July 10, 2015 6:52 PM
> *To:* Nobo Akiya
> *Cc:* Reshad Rahman (rrahman); [e-mail]
>
> *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 <[e-mail]> 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 <[e-mail]>
> wrote:
>
>  Sure.
>
>
>
> *From:* Rtg-bfd [mailto:[e-mail]] *On Behalf Of *Shahram
> Davari
> *Sent:* Thursday, July 02, 2015 11:58 AM
> *To:* Reshad Rahman (rrahman); Shahram Davari
> *Cc:* [e-mail]
> *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:[e-mail]
> <[e-mail]>] *On Behalf Of *Reshad Rahman (rrahman)
> *Sent:* Thursday, July 02, 2015 5:46 AM
> *To:* Shahram Davari
> *Cc:* [e-mail]
> *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 <[e-mail]> on behalf of Shahram Davari <
> [e-mail]>
> *Date: *Thursday, July 2, 2015 at 12:25 AM
> *To: *Reshad <[e-mail]>
> *Cc: *Shahram Davari <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *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) <[e-mail]>
> 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 <[e-mail]> on behalf of Shahram Davari <
> [e-mail]>
> *Date: *Tuesday, June 30, 2015 at 9:24 PM
> *To: *Santosh P K <[e-mail]>, "S. Davari" <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *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:[e-mail] <[e-mail]>
> ]
> *Sent:* Tuesday, June 30, 2015 2:14 AM
> *To:* S. Davari; Shahram Davari; [e-mail]
> *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:[e-mail]
> <[e-mail]>] *On Behalf Of *S. Davari
> *Sent:* Monday, June 29, 2015 10:48 AM
> *To:* Shahram Davari; [e-mail]
> *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 <[e-mail]> 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
>
>
>
>
>
>