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

Y Prasad <yprasad@juniper.net> Tue, 23 February 2010 10:03 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 09D5028C24C for <pppext@core3.amsl.com>; Tue, 23 Feb 2010 02:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.814
X-Spam-Level:
X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uEm7slc5RFyP for <pppext@core3.amsl.com>; Tue, 23 Feb 2010 02:03:15 -0800 (PST)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 09E7428C275 for <pppext@ietf.org>; Tue, 23 Feb 2010 02:03:13 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS4OoWysK/0gkSiJGGHO5gbBO1LhrwRwj@postini.com; Tue, 23 Feb 2010 02:05:16 PST
Received: from gaugeboson.jnpr.net (10.209.194.17) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.1.393.1; Tue, 23 Feb 2010 02:04:36 -0800
x-mimeole: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB46F.4D36D8EF"
Date: Tue, 23 Feb 2010 15:32:26 +0530
Message-ID: <0DB0FFEA6887E349861A3F6B40D71C3A054E3439@gaugeboson.jnpr.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: LCP echo request/reply support over multilink interface (RFC 1990)
Thread-Index: Acq0WhNrJLAfAqi6SsmabrIYPvuWVQ==
From: Y Prasad <yprasad@juniper.net>
To: <pppext@ietf.org>
X-Mailman-Approved-At: Tue, 23 Feb 2010 06:06:20 -0800
Cc: Y Prasad <yprasad@juniper.net>
Subject: [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 10:03:24 -0000

Hi 

 

Can you please help me to understand how LCP echo request/response can
be supported on a bundle? 

 

Page no.4 of RFC 1990 says below.

 

LCP negotiations are not permitted on the bundle itself.  An
   implementation MUST NOT transmit LCP Configure-Request, -Reject,
   -Ack, -Nak, Terminate-Request or -Ack packets via the multilink
   procedure, and an implementation receiving them MUST silently discard
   them.  (By "silently discard" we mean to not generate any PPP packets
   in response; an implementation is free to generate a log entry
   registering the reception of the unexpected packet).  By contrast,
   other LCP packets having control functions not associated with
   changing the defaults for the bundle itself are permitted.  An
   implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo-
   Request, Echo-Reply and Discard-Request Packets.
 

 

"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?

 

Regards

yp