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