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

[James Carlson <[e-mail]>]

Y Prasad wrote:
> 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.
> Definitely enabling on both bundle and links does not make sense.
> 
> 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.

Sorry; I read from the end of the thread upwards.  I probably should
have started here.

I don't believe that negotiation makes much sense here, given that there
are already a large number of RFC 1990 implementations in the field, and
few (if any) are going to change to accommodate this new mechanism.  And
if any do, they'd likely just agree to it anyway; the Echo-Reply
generation is far easier than the logic required to negotiate for it.

If we're to write a new spec to cover this issue, I suggest that it
should make LCP Echo-Reply generation on the bundle be mandatory (in
order to align better with RFC 1661), and then go on to discuss why
using LCP Echo-Request on the bundle is pointless, and that it isn't
recommended.

Since writing a new document is an important opportunity, it should also
cover other neglected areas, such as proper handling of inbound LCP
Protocol-Reject messages.

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