Re: [Pppext] LCP echo request/reply support over multilink interface (RFC 1990)

James Carlson <carlsonj@workingcode.com> Sun, 21 March 2010 19:24 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 1D9613A635F for <pppext@core3.amsl.com>; Sun, 21 Mar 2010 12:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.685
X-Spam-Level:
X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Fhx1ZnByxMA6 for <pppext@core3.amsl.com>; Sun, 21 Mar 2010 12:24:32 -0700 (PDT)
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 30D993A6AF4 for <pppext@ietf.org>; Sun, 21 Mar 2010 12:24:25 -0700 (PDT)
Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o2LJOTOr016642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Mar 2010 15:24:29 -0400 (EDT)
Message-ID: <4BA6726C.8040502@workingcode.com>
Date: Sun, 21 Mar 2010 15:24:28 -0400
From: James Carlson <carlsonj@workingcode.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Lightning/1.0b1 Thunderbird/3.0
MIME-Version: 1.0
To: Y Prasad <yprasad@juniper.net>
References: <4B98E356.2070804@workingcode.com> <201003111520.o2BFKpeP066268@calcite.rhyolite.com> <0DB0FFEA6887E349861A3F6B40D71C3A0639CE88@gaugeboson.jnpr.net> <B8F6B4C5-27F7-41E9-B986-64D3C88BE8D7@columbus.rr.com> <0DB0FFEA6887E349861A3F6B40D71C3A0639D2C4@gaugeboson.jnpr.net>
In-Reply-To: <0DB0FFEA6887E349861A3F6B40D71C3A0639D2C4@gaugeboson.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-DCC-dmv.com-Metrics: carlson; whitelist
Cc: pppext@ietf.org, i.goyret@alcatel-lucent.com, Vernon Schryver <vjs@calcite.rhyolite.com>, Karl Fox <karlfox@columbus.rr.com>
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: Sun, 21 Mar 2010 19:24:33 -0000

On 03/21/10 12:03, Y Prasad wrote:
> Thanks karl. Yes this would work if we are at the sending side.
> Unfortunately we are at the receiving. We have got no other option
> except implementing bundle keep alive reply though its optional.

I'm confused.

I believe the entire discussion we've had so far was with the assumption
that you wanted to send these messages, and you weren't sure whether the
peer would respond properly or how to find out whether the peer was willing.

If you're the recipient of these LCP Echo-Request messages rather than
the sender, though, then things change quite dramatically.  You're in no
position whatsoever to make any demands on your peer; he'll do what he
wants.

I believe your choices are:

  - Be kind, and respond to his messages, regardless of what you
    or anyone else may think of them.

  - Refuse to respond, and suffer the consequences, which may
    include a lack of interoperability with that specific peer.

  - Ask the person who operates that peer system whether it can
    be configured, upgraded, or otherwise modified such that it
    doesn't rely on this useless feature.  (If not, then opt for
    one of the other two above.)

None of those choices involve protocol-level or documentation changes.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>