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

[Y Prasad <[e-mail]>]

Hi Vernon,

Please see uin-line at yp>
> 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?

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

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

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.

Regards
yp




Vernon Schryver    [e-mail]