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>