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

[James Carlson <[e-mail]>]

Ignacio Goyret wrote:
> No, the remote peer is not required to respond to the Echo-Request
> on the bundle (meaning, with MP headers).
> 
> If you make any assumption based on not receiving a response in
> this case (other than the remote didn't answer), you are writing
> code that it is not interoperable.

I tend to agree with the sentiment, especially so as I think LCP
Echo-Request on the bundle is a mostly silly idea, but the documents
don't seem to say the same thing.

RFC 1990 says only that you MAY send LCP Echo-Request (et al.) on the
bundle.  It doesn't say anything at all about whether response is
required or optional or what.  RFC 1661, however, says that response to
LCP Echo-Request is mandatory.

Obviously, RFC 1661 applies at the per-link level, but what about LCP
messages at the bundle level?  When using RFC 1661's message atop an RFC
1990 bundle, is the response required or not?  You're saying "no," but
I'm not sure all implementors would agree.

In contrast, if you see LCP Protocol-Reject on the bundle, you'd darn
well better handle it properly.  The NCPs all run at the bundle level,
and it's natural to expect any protocol rejects at that level as well.
(Though it's certainly true that I've seen implementations that insist
on sending Protocol-Reject down at the per-link level at all times, so
you also have to be prepared to handle these by treating them as
applying to the NCPs running atop the bundle _iff_ they don't apply to
any per-link protocol.  These packets are treated as though they were
unencapsulated NCP messages.)

I'm arguing that we're in a grey area.  The best bet, I think, is to
avoid sending LCP Echo-Request on the bundle (unless explicitly
configured to do so), and always reply on the bundle if you receive a
request there.

There's always a bit of a fuzzy line between what's specified in the
documents and what's really required to operate well in the field.

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