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]] On Behalf Of S. Davari
Sent: Friday, July 10, 2015 6:52 PM
To: Nobo Akiya
Cc: Reshad Rahman (rrahman); [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]] 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]]
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
