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

James Carlson <carlsonj@workingcode.com> Tue, 09 March 2010 22:02 UTC

Return-Path: <carlsonj@workingcode.com>
X-Original-To: pppext@core3.amsl.com
Delivered-To: pppext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0791A3A6873 for <pppext@core3.amsl.com>; Tue, 9 Mar 2010 14:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.815
X-Spam-Level:
X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_NEED_REPLY=0.784]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luj22kX2XXpQ for <pppext@core3.amsl.com>; Tue, 9 Mar 2010 14:02:50 -0800 (PST)
Received: from carlson.workingcode.com (carlson.workingcode.com [75.150.68.97]) by core3.amsl.com (Postfix) with ESMTP id EF3AB3A6814 for <pppext@ietf.org>; Tue, 9 Mar 2010 14:02:49 -0800 (PST)
Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o29LrDp1003755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Mar 2010 16:53:18 -0500 (EST)
Message-ID: <4B96C334.5060702@workingcode.com>
Date: Tue, 09 Mar 2010 16:52:52 -0500
From: James Carlson <carlsonj@workingcode.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Ignacio Goyret <i.goyret@alcatel-lucent.com>
References: <0DB0FFEA6887E349861A3F6B40D71C3A054E3439@gaugeboson.jnpr.net> <4B83E77A.8050708@workingcode.com> <0DB0FFEA6887E349861A3F6B40D71C3A0625BC6D@gaugeboson.jnpr.net> <201003091929.o29JTmmC006876@cliff.eng.ascend.com> <4B96B075.6010808@workingcode.com> <201003092135.o29LZmXd010085@cliff.eng.ascend.com>
In-Reply-To: <201003092135.o29LZmXd010085@cliff.eng.ascend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-DCC-dcc1.aftenposten.no-Metrics: carlson; whitelist
Cc: pppext@ietf.org, Y Prasad <yprasad@juniper.net>
Subject: Re: [Pppext] LCP echo request/reply support over multilink interface (RFC 1990)
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Mar 2010 22:02:51 -0000

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         <carlsonj@workingcode.com>