Re: Review of draft-bberry-pppoe-credit (Informational)

On 27 Jul, Vernon Schryver wrote:

>> From: Mark Lanzo <[email protected]>
>> To: [email protected]
>> cc: [email protected], [email protected], [email protected],
>>         [email protected], [email protected]
> 
> 
>> PPPoE is really just being used as a means to multiplex multiple
>> PPP sessions over the ethernet link to the radio, and as a carrier
>> for signalling info between radio and router.
> 
> Which raises my question of what PPPoE has to do with the solution
> and my point that PPP(oE) is widely misunderstood as other than a
> link layer protocol.  Why use PPPoE to link networks instead of IP?

The proposal *is* using PPPoE as the link layer.  If anything, more 
than PPPoE is normally used as such.

The whole point is that you have a router and an external radio.  
The radio has an ethernet port on it, by which it attaches to the 
router.  The radio itself detects other radios in its vicinity,
and creates a semblance of a serial connection to each of those
adjacent radios.  The customer wants the router to run PPP on these 
serial connections.

The radio doesn't provide a slew of serial ports to attach to the
router, one for each of the remote radio nodes.  All it provides is an
ethernet port.  So the radio is basically a smarter-than-average serial 
port card with lots of ports, which plugs into the router via an 
ethernet rather than being inserted into a slot on the router's backplane.  
The serial links have to be simulated at the router end. Bottom line 
being that the ethernet is really just a funky "backplane" here, and
the goal is to couple the router as close as is reasonably possible to
its "serial" ports.

All the different serial sessions have to somehow be multiplexed
over the ethernet port which acts as the bus to the radio.  So how do 
you do that?  Obviously you need some sort of frame format which can carry 
a "serial" packet to/from the radio, and which also includes some sort 
of identifier so that both router and radio can distinguish which particular 
remote serial user this packet is for.  It is also desirable to have some 
sort of method for conveying signalling information related to the virtual
serial links - a new link has appeared, an old one is gone, a link
is congested, etc.  

You could invent a new protocol for this, get a new ethertype assigned
to you, etc etc.  Or you could recognize that the PPPoE frame format,
and even the PPPoE protocol (with some relatively minor additions)
fits the bill.

I understand why you think of PPPoE as a kludge, and can understand
reluctance to propogate use of a kludge.  Still, it seems to me that
if anything that the intended use here is a better use - less of a 
kludge - than PPPoE as it is normally deployed.  

It occurs to me that the biggest faux pas here is mentioning PPP in the 
name.  This scheme really does relegate PPPoE to the link layer, and 
for that matter practically divorces PPP from PPPoE altogether.  In
truth, it's just a method for transferring serial packets over the 
"backplane" to the radio.  The fact that the packets contain PPP frames 
is barely relevant.  Unfortunately, describing the proposal as an 
extension to "PPPoE" seems to be having a very negative effect, because 
it brings with it all the negative baggage associated with PPPoE.

>> A completely new protocol could have been devised for all of this,
>> but since the nature of the info traded by that protocol would have
>> been very much like the nature of the info traded by PPPoE, I think
>> the authors wanted to use PPPoE precisely so they wouldn't be
>> completely reinventing the same old wheel.  The purpose of the document
>> isn't to make a general-purpose extension to PPPoE, it's to create
>> a special purpose extension for a very specific sort of environment.
> 
> So why not use the official IETF standard way to link networks instead
> of piling kludges on top of the kludge that is PPPoE? 

What standard official IETF way of multiplexing virtual serial 
connections over an ethernet (or any media) "backplane" are you 
referring to?
 
> The IETF standard way would be to give the routers IP addresses and
> use a real routing protocol (or even static routes) instead of what
> looks sounds like a retread of IGRP.  You might use PPPoE (or not)
> between the access concentrators and their neighboring stationary
> radios.  You might define a PPP over RLP encapsulation that would have
> credits, battery condition, and so forth among the radios.

> Wouldn't that produce products with a wider potential market 

Just the opposite, actually (hopefully).  Routers already exist which 
support PPPoE.  Using PPPoE in this rather unusual fashion means the 
ability to hook these specialized radios into existing router equipment.
Significantly improved performance is gained for those routers which 
implement the proposed extensions.  It seems more likely that manufacturers 
would augment already developed PPPoE implementations than implement a 
whole new protocol.

> ... as well
> as fewer nastinesses such as an MTU that is even smaller than the bad
> old PPPoE MTU of 1492?

That is admittedly still an issue.  As long as the "backplane" to the 
"radio card" is an ethernet, it doesn't seem easy to avoid this (short
of resorting to some form of link layer fragmentation).  It is also
a bit off-topic since this is a technical limitation not arising from
anything within the draft itself, well understood, and which the draft 
makes no claim of trying to overcome.

> Why egregiously violate layering by trying to convert IEEE 802.3
> into an inter-network protocol?

Hopefully it is clear by now that the above statement is inaccurate,
and arises from misperceptions about the proposed mechanisms.

As I indicated above, it seems to me that there is a lot of reaction 
to this draft, but the reaction is due (at least in part) to the bias 
against traditional PPPoE and not due to the technical merits (or lack 
thereof) of this proposal or its intended goals.  My thought is that the 
draft may not be wholly clear about the environment and application, 
and this is leading to confusion.  This suggests to me that the draft 
could bear a fair amount of expansion and augmentation, before it
is ready for RFC status.  I.e. there may be legitimate reason to not
accept the draft as it currently stands, but those reasons have more
to do with clarity and completeness of the document than the technical 
merits of the proposal.

At any rate, I'm going to try to stay out of the discussion after
this.  Despite all the verbiage I've tossed out, it is not my intent
to be a spokesman for the proposed mechanism -- the authors can do 
that.  I don't have a personal stake in this, but I've had the benefit 
of in-person discussions with the group behind this, without which,
I suspect the draft wouldn't have made a lot of sense to me either.



_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext