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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext
|
