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

> From: Y Prasad <[email protected]>
> To: James Carlson <[email protected]>,
>         Ignacio Goyret
> 	<[email protected]>
> Cc: [email protected]

> Having LCP keep-alives on the bundle is not a bad idea in cases where
> member links/lines are very stable and dedicated. By enabling LCP
> keep-alives only on the bundle, it would reduce the control traffic.

The reduction in control traffic had better be insignificant,
or you are spending far too many bits on LCP echos.

The reduced control traffic would fail to detect dead members of
the bundle.  Depending on how packets are spread over the links in
the bundle, you could have a bundle of one live link, one dead, and
everything working fine except for an approximate 50% packet loss rate.

Without LCP on individual links, how do you decide which link in
a bundle should be re-established?

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?


> Definitely enabling on both bundle and links does not make sense.

I don't think much of LCP echo on the bundle.


> Contention here is, peer that is transmitting LCP echo req on the bundle
> can not know if the peer is dead or does not support LCP-echo reply on
> the bundle. As I conveyed initially, cleaner way would be to update RFC
> with one of the following.
>  1) Mention LCP echo reply on the bundle as mandatory
>                 Or
>  2) Make LCP echo AVP(optional) is negotiated initially on the bundle.
>
> Choice 2) would be better as there might be implementations out there,
> that chose the bundle LCP reply as an optional.

There is no such thing as "update [the] RFC." The closest related notion
would be publishing one or more new RFCs.  The at best minor (and I
think undesirable) change does not justify opening that can of worms.


Vernon Schryver    [email protected]
_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext