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

[James Carlson <[e-mail]>]

Y Prasad wrote:
> Folks,
> 
> IMO, having only Bundle LCP keep alives is still a good choice(in cases
> where large number of members/bundles exists and link flap could lead to
> larger bundle re-bring-up time).

I'm unable to parse that statement.  Could you provide specifics on how
running LCP Echo-Request at the bundle level provides some sort of
performance improvement?  Or at least what link flaps have to do with
the problem?  I cannot see how that's so.

As far as I can tell, link flap just takes one link out of the bundle,
and bringing it back into the bundle is dependent on negotiating LCP
(and Authentication, if required).  Neither of those has anything to do
with LCP Echo-Request.

> I was just trying to mention a case where RFC1990 is giving a scope of
> incompatibility.

True; this is an area where the specification is indeed weak.

At least in my experience having worked on a couple of different
implementations, the issue just didn't matter.  It's the member links we
all care about testing, not the bundle itself, because having a single
bad member link in the bundle is toxic to the bundle, due to the way the
reassembly algorithm works.  LCP Echo-Request/-Reply at the per-link
level provides a clean way to test each link to make sure it's still
working properly.  Doing it at the bundle level doesn't do that.

Multilink (with the segmentation feature enabled) tends to run at the
speed of the slowest link, as everything blocks for that one link to
produce updated sequence numbers.

> In fact there are installations from a big vendor where bundles being
> disconnected due to no-reply to bundle LCP ECHO req. Solution to the
> peer is either mandatorily reply (though its optional from RFC point of
> view) to bundle-keep-alives or ask sender side to disable this feature
> :( In fact bundle-keep-alive feature cannot implemented if the reply is
> not made mandatory. 

If the peer refuses to reply, then no mere document is going to help
you.  You have to stop depending on the feature if you want to
interoperate with those peers.

Even if it were made mandatory, that'd still just be in the new
document, and there are many devices out there that are designed to RFC
1990, and might never be changed.

> Anyway if somebody out there trying to obsolete RFC1990, the mentioned
> items can be taken care. I can help here if needed. Not worth trying
> just this update though :)

If you want to take it on, I suspect that you'll likely need to provide
a clear rationale -- complete with worked-out examples that show the
benefits -- in order to convince enough contributors here to achieve
consensus.

It's certainly possible to do that, but it'll take some work.

-- 
James Carlson         42.703N 71.076W         <[e-mail]>