Re: [Pppext] LCP echo request/reply support over multilink interface (RFC 1990)
James Carlson <carlsonj@workingcode.com> Tue, 23 February 2010 14:32 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 417BE28C125 for <pppext@core3.amsl.com>;
Tue, 23 Feb 2010 06:32:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.982
X-Spam-Level:
X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=-0.167,
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 Ip7w+Ikb4IfG for
<pppext@core3.amsl.com>; Tue, 23 Feb 2010 06:32:37 -0800 (PST)
Received: from carlson.workingcode.com
(carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by
core3.amsl.com (Postfix) with ESMTP id 4162828C122 for <pppext@ietf.org>;
Tue, 23 Feb 2010 06:32:37 -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 o1NEYYQJ020469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA
bits=256 verify=NO); Tue, 23 Feb 2010 09:34:36 -0500 (EST)
Message-ID: <4B83E77A.8050708@workingcode.com>
Date: Tue, 23 Feb 2010 09:34:34 -0500
From: James Carlson <carlsonj@workingcode.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Y Prasad <yprasad@juniper.net>
References: <0DB0FFEA6887E349861A3F6B40D71C3A054E3439@gaugeboson.jnpr.net>
In-Reply-To: <0DB0FFEA6887E349861A3F6B40D71C3A054E3439@gaugeboson.jnpr.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-DCC-dmv.com-Metrics: carlson; whitelist
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, 23 Feb 2010 14:32:38 -0000
Y Prasad wrote: > “Bundle interface is a virtual interface. If there has to be LCP keep > alive on it, it has to go through one of the underlying physical links. > But LCP keep alive packet format does not seem to specify any interface > details. How does the remote identify that the LCP echo received on a > physical link belongs to bundle? If you run those non-negotiation LCP messages on the bundle, they may need to be encapsulated using RFC 1990 fragment headers if you want to segregate bundle and link level traffic. You're not required to do that, though. In general, this is more of an implementation issue than anything else. For example, you need to inspect LCP Protocol-Reject messages to deliver them properly. If the rejected protocol is one of the few per-link protocols, then it should be handled at the link level. If not, then it should be communicated upwards to the bundle head for processing. Some implementations will deliver LCP errors at the link level that are targeting problems detected at the bundle level. You must be prepared to handle that. In the case of LCP Echo Request, if you implement that only at the bundle level, then you can send requests without encapsulation and simply have all of the received LCP Echo Reply messages forwarded up to the bundle head. If you implement only at the link level, then process them there, again without encapsulation. In short, since you know how you send your requests, you can decide how you want to process the replies. (And since implementing at both levels at the same time would likely not serve much of a purpose, it would probably be wise to choose one and stick with it. I'd recommend link-level, as it's links that usually run into trouble, but it's your code ...) Note that packets sent at the bundle level are _not_ required to have MP fragment headers. Using those headers guarantees ordering and reassembly where needed, but it's not a requirement -- either for signaling messages or for user data. The only special action needed to ensure interoperability is that when an implementation receives a bare LCP Echo-Request, it must reply on the same link. -- 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