Re: [Pppext] LCP echo request/reply support over multilink interface (RFC 1990)
Y Prasad <yprasad@juniper.net> Thu, 11 March 2010 04:22 UTC
Return-Path: <yprasad@juniper.net>
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 83DE33A6A35 for <pppext@core3.amsl.com>;
Wed, 10 Mar 2010 20:22:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.815
X-Spam-Level:
X-Spam-Status: No, score=-5.815 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 INNkIJ2HAM9J for
<pppext@core3.amsl.com>; Wed, 10 Mar 2010 20:22:25 -0800 (PST)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173])
by core3.amsl.com (Postfix) with ESMTP id 479FA3A6A42 for <pppext@ietf.org>;
Wed, 10 Mar 2010 20:22:24 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by
exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID
DSNKS5hvxWv4vPeeB/Fd3ARhcDNMO4ZzTcp/@postini.com;
Wed, 10 Mar 2010 20:22:30 PST
Received: from gaugeboson.jnpr.net (10.209.194.17) by P-EMHUB01-HQ.jnpr.net
(172.24.192.35) with Microsoft SMTP Server id 8.1.393.1;
Wed, 10 Mar 2010 20:18:28 -0800
x-mimeole: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Mar 2010 09:48:21 +0530
Message-ID: <0DB0FFEA6887E349861A3F6B40D71C3A0639CB09@gaugeboson.jnpr.net>
In-Reply-To: <4B96C334.5060702@workingcode.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Pppext] LCP echo request/reply support over multilink interface
(RFC 1990)
Thread-Index: Acq/1FBdUJYy5PepTiu1mvwjf0u3PQA+tXKQ
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>
<4B96C334.5060702@workingcode.com>
From: Y Prasad <yprasad@juniper.net>
To: James Carlson <carlsonj@workingcode.com>,
Ignacio Goyret <i.goyret@alcatel-lucent.com>
Cc: pppext@ietf.org
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: Thu, 11 Mar 2010 04:22:26 -0000
Having LCP keep-alives on the bundle is not a bad idea in cases where
member links/lines are very stable and dedicated. By enabling LCP
keep-alives only on the bundle, it would reduce the control traffic.
Definitely enabling on both bundle and links does not make sense.
Contention here is, peer that is transmitting LCP echo req on the bundle
can not know if the peer is dead or does not support LCP-echo reply on
the bundle. As I conveyed initially, cleaner way would be to update RFC
with one of the following.
1) Mention LCP echo reply on the bundle as mandatory
Or
2) Make LCP echo AVP(optional) is negotiated initially on the bundle.
Choice 2) would be better as there might be implementations out there,
that chose the bundle LCP reply as an optional.
Regards
yp
-----Original Message-----
From: James Carlson [mailto:carlsonj@workingcode.com]
Sent: Wednesday, March 10, 2010 3:23 AM
To: Ignacio Goyret
Cc: Y Prasad; pppext@ietf.org
Subject: Re: [Pppext] LCP echo request/reply support over multilink
interface (RFC 1990)
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