Re: LCP echo request/reply support over multilink interface (RFC 1990)
James Carlson <[email protected]> Tue, 09 Mar 2010 16:52:52 -0500
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
Ignacio Goyret wrote: > 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. As a default "assumption," no. But if the administrator configures the link to fail on a lack of replies, then I see no problem at all with failing it out when faced with such a peer. The administrator will have to configure the feature back off in order to interoperate with such a system, but as long as the default is "don't bother with bundle-level LCP echo," there's no problem. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ Pppext mailing list [email protected] https://www.ietf.org/mailman/listinfo/pppext