Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit
Mark Lanzo <lanzo@cisco.com> Fri, 09 December 2005 16:57 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklYy-0005WC-8z; Fri, 09 Dec 2005 11:57:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklYx-0005VZ-02 for pppext@megatron.ietf.org; Fri, 09 Dec 2005 11:57:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00550 for <pppext@ietf.org>; Fri, 9 Dec 2005 11:56:37 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EklZ2-0002Wy-Qf for pppext@ietf.org; Fri, 09 Dec 2005 11:57:45 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Dec 2005 08:57:21 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,235,1131350400"; d="scan'208"; a="16931721:sNHT22707784"
Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB9GvJ4X028855; Fri, 9 Dec 2005 11:57:20 -0500 (EST)
Received: from cisco.com (lanzo-u10.cisco.com [64.102.48.21]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA28631; Fri, 9 Dec 2005 11:57:15 -0500 (EST)
Message-Id: <200512091657.LAA28631@cisco.com>
Date: Fri, 09 Dec 2005 11:57:12 -0500
From: Mark Lanzo <lanzo@cisco.com>
Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit
To: wsimpson@greendragon.com
In-Reply-To: <43996295.2020003@greendragon.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: pppext@ietf.org
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org
On 9 Dec, William Allen Simpson wrote: > Stan Ratliff (sratliff) wrote: >>> The techniques described in this document are intended for use with >>> a particular deployment technique that uses a PPP termination >>> separated from a radio termination by an Ethernet, and that has >>> radio-side flow control for a slower PPP-only link to remote nodes. >> >> I, for one, would be OK with this text. >> > While I, for one, would not! Merely describing the protocol deployment > environment is a part of the specification, not a WG warning about the > poor design. > > Going back 20+ years, I have had considerable experience deploying > protocols over radio links. The best design would be to put a router > at every radio link. Goodness gracious, TAL did it commercially going > on 15 years ago! Simple 2 port routers are cheap! Hmm ... but this does not address the problem; it is not the issue. The issue is that the routers have to _connect_ to the radios somehow. The radios aren't integral to the router; the radios and router aren't even made by the same company. Ignoring the proposed extensions here, the router is a perfectly ordinary router; it doesn't know anything about radios or radio links in particular. The desired goal is that the router be able to establish ordinary PPP sessions to remote peers, and be none the wiser about the media between itself and its peers. In this particular instance, the router has a plain old ethernet port on it. So do the radios in question. The radios aren't integral to the router, but the desire is make the radios look somewhat as if they were. So the ethernet is being used as the "backplace" for connecting radios to router. -Some- sort of protocol is needed, to allow both for exchange of ordinary data and out-of-band information such as congestion conditions on the radio. Some way to emulate a system where radios were plugged into the router's bus and could appear more like local serial ports. A whole new protocol could have been devised for the purpose; however, it was recognized that with relatively minor modifications, PPPoE (which the router in question already supports) could be adapted to be this "backplane" protocol. The interesting thing here is that there is not really any "PPP" in this at all - it is actually irrelevant that the payloads which will eventually be traded between radio and router for over-the-air transmission be PPP packets. It is the out-of-band signalling capabilities, not the in-band data, which is the aspect of interest here. The name "PPPoE" seems an unfortunate choice, both because PPP wasn't the real point and because PPPoE is already a sore subject with many folk. Meanwhile, I believe it was thought that not reinventing the wheel, and trying to have a published standard which radio manufacturers and router vendors could agree to use for interconnecting their equipment, would be a Good Thing. Is there some other protocol out there already, which is a better choice [especially one whose very mention won't automatically trigger a knee-jerk negative reflexive action]? Note please that I am writing merely as an interested party and am not part of the group submitting the proposal, nor am I trying to endorse the proposal in any particular way. I have talked to that group though, and I have read the dialogs on this list, and I think that there is a bit of a disconnect, and that the group in question is suffering from the unfortunate backlash that results from association with a protocol that historically is not well-received. Would it help if the proposal began with a clearer explanation that although it "extends" PPPoE, that the usage is not in fact for PPPoE as traditionally recognized, but instead is being used as a protocol for using an ethernet as a backplace for communicating with external serial-port "concentrators"? Is there a different RFC this group should be looking at, which already provides just this sort of thing? _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext
- [Pppext] warning suggestions for draft-bberry-ppp… James Carlson
- RE: [Pppext] warning suggestions for draft-bberry… Stan Ratliff (sratliff)
- RE: [Pppext] warning suggestions for draft-bberry… James Carlson
- RE: [Pppext] warning suggestions for draft-bberry… Stan Ratliff (sratliff)
- RE: [Pppext] warning suggestions for draft-bberry… James Carlson
- RE: [Pppext] warning suggestions for draft-bberry… Vernon Schryver
- RE: [Pppext] warning suggestions for draft-bberry… Stan Ratliff (sratliff)
- Re: [Pppext] warning suggestions for draft-bberry… William Allen Simpson
- Re: [Pppext] warning suggestions for draft-bberry… James Carlson
- Re: [Pppext] warning suggestions for draft-bberry… Karl Fox
- Re: [Pppext] warning suggestions for draft-bberry… Karl Fox
- Re: [Pppext] warning suggestions for draft-bberry… James Carlson
- Re: [Pppext] warning suggestions for draft-bberry… Vernon Schryver
- Re: [Pppext] warning suggestions for draft-bberry… Karl Fox
- Re: [Pppext] warning suggestions for draft-bberry… James Carlson
- Re: [Pppext] warning suggestions for draft-bberry… Bo Berry
- Re: [Pppext] warning suggestions for draft-bberry… Vernon Schryver
- Re: [Pppext] warning suggestions for draft-bberry… Karl Fox
- Re: [Pppext] warning suggestions for draft-bberry… James Carlson
- Re: [Pppext] warning suggestions for draft-bberry… Mark Lanzo
- RE: [Pppext] warning suggestions for draft-bberry… Nelson, David
- Re: [Pppext] warning suggestions for draft-bberry… Vernon Schryver
- Re: [Pppext] warning suggestions for draft-bberry… James Carlson
- Re: [Pppext] warning suggestions for draft-bberry… James Carlson
- Re: [Pppext] warning suggestions for draft-bberry… William Allen Simpson
- Re: [Pppext] warning suggestions for draft-bberry… William Allen Simpson