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

[Y Prasad <[e-mail]>]

> 
> 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.

Yp> LCP keep-alives help to identify faulty link and peer state
(alive/dead).
If an user depends on link Career detect (or some other means) to
identify faulty link, he may opt for no-keepalives on that link. And in
order to identify whether peer alive or not just a bundle keep alives
are good enough. This would reduce control traffic and flooding of LCP
keep-alives on multiple link flaps/bundle flaps when links rejoin into
bundle after LCP.
 

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.

Yp> I agree, I meant LCP keepalive traffic after links join.

> 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.

Yp> I agree in case member links are "bad" (meaning can not reflect
faulty link properly).
 "good link" here means it does reflect its faultiness without the need
of LCP keepalives.

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
Yp> Peer thinks optional (not refusal) and the local might think peer is
dead.

you.  You have to stop depending on the feature if you want to
interoperate with those peers.
Yp> Yes with the current form in the draft bundle keep alives can not
work with peer who thinks the same is optional.

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.

Yp> I agree. Only way is bundle-keepalive need to made as optional and
negotiable attribute. Then it would work with existing installations.
down-ward-compatible :).

> 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.

Yp> I think we can club this rectification along with any other if any.
Just for this writing an another draft may not be worth trying :)

Regards,
yp

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