[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
- [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