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>
- [Pppext] LCP echo request/reply support over mult… Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … Ignacio Goyret
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Ignacio Goyret
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … Vernon Schryver
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Vernon Schryver
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson