Re: LCP echo request/reply support over multilink interface (RFC 1990)

Y Prasad wrote:
> Hi Vernon,
> 
> Please see uin-line at yp>

If possible, please do use standard quoting practice rather than rolling
your own, so that attributions remain true.

> If there are persistent problems on one link in a bundle (e.g. a sick
> modem/line card/whatever), how do you figure out which if you have
> only LCP on the bundle and not on each link?
> 
> Yp> I presume you meant LCP echo above. LINK down can be identified by
> many other ways depending on what type of link it is. Eg. carrier detect
> signal becoming up/down can be used for link status.

That's true, but irrelevant.

If you can completely trust link up/down indications, then this entire
discussion is moot.  You don't need LCP Echo-Request at all.  You can
just avoid sending it, and drive on, trusting the RFC 1661 Down event
from the lower layer to tell you all you need to know.

In order to have a discussion about LCP Echo-Request at all, we have to
start from the point of assuming that there are failure modes in the
links that cannot be detected in the usual way.  The link can be damaged
in some way that makes it useless for traffic, but doesn't cause "Down."
 The next questions are what failures, how detected, and what remedies
are available?

As Vern correctly pointed out, if you do LCP Echo-Request at the bundle
level, you cannot reliably detect individual link failures, because the
messages are no longer specific to any member link.  Thus, doing the
echoes at that level actually only tests for implementation flaws in the
MP code itself, rather than external failures.  And there's not much you
can do about that except do your design and testing very carefully.

LCP Echo-Request at the per-link level is different.  It reliably
detects most "silent" failure modes, where the lower-level link status
is still positive, but the link no longer carries any traffic, or is
able to carry traffic in only one direction, or is perhaps just
experiencing an abnormal error rate.  If you detect such a failure, you
can fix it by dropping that one link out of the bundle.

Furthermore, I reject the idea that it's any sort of performance issue.
 If you do send LCP Echo-Request, you're not required to send it at any
particular rate.  Send it as quickly or as slowly as you like.  If you
feel that dividing the rate at which you send it by the number of links
in the bundle is a good strategy (as would occur if echoes were done at
the bundle level), then do it.  Since you're also the one independently
determining when a lack of Echo-Reply messages indicates a problem, you
can choose whether and when to send Echo-Request.

For those reasons, I remain unconvinced that LCP Echo-Request at the
bundle level is more than a curiosity.

>  As per draft
> LCP-req is optional and LCP-echo-reply is mandatory (MUST). Many vendors
> do support no-keepalive  option even on plane PPP interfaces.

Sure.

> Yp> I know that, there can not be versions for RFCs :) 
> In order to clarify the issue being discussed, we can update a new RFC
> if any planned (needed to be planned) about/for MLPPP.

I don't think one is really needed for this sort of issue, but you're
certainly welcome to contribute if you wish.

-- 
James Carlson         42.703N 71.076W         <[email protected]>
_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext