Re: [Pppext] LCP echo request/reply support over multilink interface (RFC 1990)
Ignacio Goyret <i.goyret@alcatel-lucent.com> Tue, 09 March 2010 19:30 UTC
Return-Path: <i.goyret@alcatel-lucent.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 390CA3A6A3D for <pppext@core3.amsl.com>;
Tue, 9 Mar 2010 11:30:14 -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 SimJTgE2k8vq for
<pppext@core3.amsl.com>; Tue, 9 Mar 2010 11:30:12 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by
core3.amsl.com (Postfix) with ESMTP id B49383A6A28 for <pppext@ietf.org>;
Tue, 9 Mar 2010 11:30:05 -0800 (PST)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53])
by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o29JTpAn007884;
Tue, 9 Mar 2010 13:30:08 -0600 (CST)
Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [135.140.53.169]) by
ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o29JTn24006755;
Tue, 9 Mar 2010 13:29:50 -0600 (CST)
Received: from igoyret-c1.alcatel-lucent.com (dhcp-135-140-27-184
[135.140.27.184]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id
o29JTmmC006876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
verify=NO); Tue, 9 Mar 2010 11:29:48 -0800
Message-Id: <201003091929.o29JTmmC006876@cliff.eng.ascend.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 09 Mar 2010 11:29:21 -0800
To: Y Prasad <yprasad@juniper.net>
From: Ignacio Goyret <i.goyret@alcatel-lucent.com>
In-Reply-To: <0DB0FFEA6887E349861A3F6B40D71C3A0625BC6D@gaugeboson.jnpr.n et>
References: <0DB0FFEA6887E349861A3F6B40D71C3A054E3439@gaugeboson.jnpr.net>
<4B83E77A.8050708@workingcode.com>
<0DB0FFEA6887E349861A3F6B40D71C3A0625BC6D@gaugeboson.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
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: Tue, 09 Mar 2010 19:30:14 -0000
At 10:19 AM 3/3/2010 +0530, Y Prasad wrote: >It says LCP echo-req/reply on the bundle is optional. Assume that an >implementation sends LCP ECHO req. on the bundle and the remote chooses >not to reply (as it is optional) then sender would likely to drop the >bundle. If it does that, then the sender of the Echo-Request is not compliant. > Perhaps mentioning one of the following clauses help. > > 1. Let the peer negotiate "LCP-echo req on the bundle" during LCP req >and subsequently send LCP echo req on the bundle only if it is accepted >by the remote peer. The LCP Echo function is not negotiated. It is mandatory at the link level and optional at the bundle level. >OR > > 2. Sending LCP ECHO-req on the bundle is option. But LCP ECHO-reply on >the bundle need to be mandatory. 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. -Ignacio
- [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