Hi Manav,
the use case for the BFD over MC-LAG interfaces that I consider the most
important for this drafts to address is to enable sub-second defect detection
in order to trigger LACP convergence and, subsequently, switchover within the
Redundancy Group in Active-Standby case. Hence both unicast and multicast L3
addresses are quite distant from L2 fast path and processing usually taken by
CCM frames. Of course, one can use CFM per LAG Constituent Link, and I have
implemented that and it interoperates with another implementation by other
vendor, but operators prefer ease of BFD provisioning. Thus I’ve to provide
them with ability to monitor MC-LAG and explain that in some cases it may
produce false negative when L2 is functional and the problem is in L3, unicast
or multicast, engine. As you can see, there’s not much value in continuing
argument how much different L3 multicast processing is from L3 unicast as both
are different from L2 path. At the end, as I think, it is up to operators to
decide whether they are comfortable with this mechanism or would require defect
detection at L2.
Regards,
Greg
From: Manav Bhatia [mailto:[email protected]]
Sent: Friday, April 08, 2016 5:38 PM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman); [email protected];
[email protected]; [email protected]; [email protected]; [email protected];
Gregory Mirsky
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces
Hi Greg,
the update could be in addition of either broadcast or link local multicast or
both with appropriate normative language. But I would not agree that these
wouldn't work.
Double negatives make it very hard to parse a sentence.
Anyway, why would you NOT agree that this WOULDNT work?
I am telling you that link local multicasts and unicasts are dealt with
differently in the data plane, so the data path being up for the former may not
necessarily mean that its up for the latter as well. So tell me WHY you think
this argument isnt valid? I was the L3 data plane architect in my former
company for one of the product lines and i am telling you that in my box, which
is very very widely deployed, your scheme will NOT work since i punt all link
local packets to the CPU differently. In fact, in some cases even the TX path
is different. So sure, u-BFD may very well claim that the link is up, but its
possible that there may be no IP connectivity.
Cheers, Manav
Regards, Greg
On Apr 8, 2016 12:34 PM, "Manav Bhatia"
<[email protected]<mailto:[email protected]>> wrote:
Hi Greg,
Not sure i understand how it can "update RFC 7130". Is that by using a link
local mcast IP instead of a Unicast IP?
We know that, that wouldnt work.
Cheers, Manav
On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky
<[email protected]<mailto:[email protected]>> wrote:
Hi Reshad,
thank you for your comments. Indeed, RFC 7130 is restricted and thus hardly
applicable to MC-LAG case. We realize that if this proposal is adopted it not
only enhance applicability on u-BFD but will update RFC 7130.
Regards,
Greg
From: Reshad Rahman (rrahman)
[mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Alia Atlas
([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
I agree with Manav, and nothing in RFC7130 seems to preclude using different
unicast IP address as destination on different member links.
Regards,
Reshad (as individual contributor).
From: Rtg-bfd <[email protected]<mailto:[email protected]>> on
behalf of Manav Bhatia <[email protected]<mailto:[email protected]>>
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky
<[email protected]<mailto:[email protected]>>
Cc:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, "Alia Atlas
([email protected]<mailto:[email protected]>)"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
Hi Greg,
Why cant different micro-BFD packets use the IP address of the MC-LAG end
points? Ones going to router 1 will all carry the same unicast IP address. The
ones going towards the other router will all carry some other IP address, which
would be configured along with the MC-LAG configs.
In fact i would argue that the u-bfd packets going to different routers must
use different IP addresses so that you can actually verify the data plane
liveliness. Whats the point in sending a contrived IP address if the path that
it takes is different from the other regular packets?
Cheers, Manav
On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky
<[email protected]<mailto:[email protected]>> wrote:
Hi Manav,
thank you for sharing insight view of discussions around RFC 7130, extremely
helpful.
We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents
different case and the compromise that you’ve pointed too is justified. We will
add more details on the potential differences between unicast and multicast
fast paths in the next update.
We are open to the discussion and always welcome comments and alternative
proposals.
Regards,
Greg
From: Manav Bhatia [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Alia Atlas
([email protected]<mailto:[email protected]>)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
I believe it had to do with multicast datapath (especially link local) being
different from the unicast datapath in most routers. Using link local multicast
IP addresses may not necessarily guarantee Unicast IP reachability.
When writing 7130 we spent quite a bit of time ensuring that we dont carve out
a special data path for the micro-BFD packets. Using link local would have made
it a lot simpler.
And this is where i think the current proposal is flawed -- they use link local
multicast to ensure IP unicast reachability which is incorrect.
Cheers, Manav
On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen
<[email protected]<mailto:[email protected]>> wrote:
Hi Greg and all,
I just have quick review on the drafts. If my understanding is correct, the
idea is to use multicast destination address other than unicast address when
sending BFD packets over LAG links. And actually this idea has been proposed in
https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the predecessor of RFC
7130). And at that time, the co-authors of RFC 7130 did discuss the idea of
using multicast destination address, but for some reason I forget now(I may
need to reiterate the discussions on the archive), the idea was abandoned,
although I still think multicast destination address is a smart idea.
Best regards,
Mach
________________________________
From: Rtg-bfd [[email protected]<mailto:[email protected]>] on
behalf of Gregory Mirsky
[[email protected]<mailto:[email protected]>]
Sent: Tuesday, April 05, 2016 6:16
To: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Alia Atlas
([email protected]<mailto:[email protected]>)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces
Dear All,
two new drafts, related to RFC 7130, were published before the meeting:
· BFD on MC-LAG interfaces in IP
network<https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00>
· BFD on MC-LAG interfaces in IP/MPLS
network<https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-mpls-00>
Greatly appreciate your reviews, comments, questions and suggestions.
Regards,
Greg
_______________________________________________
mpls mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/mpls
