Hi Manav,
I’m glad that we’re converging – the final decision would come from our
customers, the operators.
I hope we’ll have their comments.
In the meantime, I invite you and other experts to review the second draft that
looks into the same scenario but over the IP/MPLS network. It may be less
controversial as neither multicast, nor broadcast addresses need to be used as
the destination IP address.
Regards,
Greg
From: Manav Bhatia [mailto:[email protected]]
Sent: Saturday, April 09, 2016 2:08 AM
To: Gregory Mirsky
Cc: Greg Mirsky; Reshad Rahman (rrahman);
[email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces
Hi Greg,
There is a difference, a big one.
When you use CFM or some other L2 OAM protocol, you dont make any claims about
L3 connectivity. However, when you start using BFD it implicitly means that
youre talking about L3 connectivity. So, its going to be bizarre debugging
complex topologies where BFD sessions never flap and yet MPLS LSPs randomly
time out (because there is this one MC-LAG thats dropping packets -- and in the
worst case, only sporadically and intermittently drops IP packets)
It will NOT produce false negatives (as you claim) but rather introduce false
positives, which is more dangerous. The MC-LAG will be up, while it would be
dropping all or few IP packets.
I have no objections if operators and the community think that this is
something that they can live with. I am personally having an out-of-body
experience just discussing this! :-)
Cheers, Manav
On Sat, Apr 9, 2016 at 9:46 AM, Gregory Mirsky
<[email protected]<mailto:[email protected]>> wrote:
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]<mailto:[email protected]>]
Sent: Friday, April 08, 2016 5:38 PM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman);
[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]>; 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
