Re: LCP echo request/reply support over multilink interface (RFC 1990)
Ignacio Goyret <[email protected]> Tue, 09 Mar 2010 13:34:27 -0800
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
At 03:32 PM 3/9/2010 -0500, James Carlson wrote: >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. Precisely. My point is that you can't make an assumption based on whether the remote replied or not your Echo-Request at the bundle level. If it did, great. But if it didn't, it doesn't mean anything beyond that the remote didn't send an Echo-Reply, a choice that is perfectly legal given the ambiguities in RFC1990. Some implementors may choose to respond to an Echo-Request at the bundle level, others may choose to not respond -- and both implementations would interoperate successfully so long as there are no assumptions about required responses. It is a basic application of the "be liberal in what you accept" principle. Cheers, -Ignacio _______________________________________________ Pppext mailing list [email protected] https://www.ietf.org/mailman/listinfo/pppext