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

> From: Mark Lanzo <[email protected]>

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

No, as far as I can tell PPPoE is being used as a network layer.

> 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 radio is also a router.  That it is routing PPPoE frames instead
of IP packets does not make it other than a router.  There were routers
before IP was invented.  There are still routers that have nothing to
do with IP.

>                   The customer wants the router to run PPP on these 
> serial connections.

Why does the customer care whether PPP runs on the radio links?
What kind of PPP does the customer want?  
Are you sure the customer will be happy to have the crippled PPPoE MTU
further crippled?


> The radio doesn't provide a slew of serial ports to attach to the
> router, one for each of the remote radio nodes.

That seems irrelevant.  Many routers for many inter-network protocols
do not involve banks of serial ports.

>                                                  All it provides is an
> ethernet port.  

Ok, but that is like many other routers.  Consider an 802.3 or FDDI to
ATM or FR router with one physical fiber or RJ-11 connection for the
LAN and one physcial connection to the telephone company ATM or FR wire.

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

That does not change the fact that it is a router.  It routes or
gateways packets between one link layer network that happens to be
running eithernet and another link layer network that happens to involve
the real ether.

I have not figured out whether the frames on the real ether are PPPoE
or some other flavor of PPP or no PPP at all.  I've seen words about
that seem to conflict.


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

By that reasoning, there are no routers in NPXs, where FDDI, 802.3,
and other link layers are just being used as funky backplanes.


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

Why do that?  Why couldn't one do as I said and assign IP addresses
to the radios and use IP packets for all of this multiplexing
and demultiplexing?


> I understand why you think of PPPoE as a kludge, 

Without intending any offense, I really think you do not know why I
think PPPoE is wrong and evil and are even less clear about what I
do not like about this proposal.


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

No the biggest issue (I won't say faux pas) is that the confusion
between the natures of link layers and network layers.  

As far as I can tell, this proposal is a classic example of
re-inventing the idea of an inter-network protocol within a link
layer.  It is certainly not the only example of such re-inventions
since TCP/IP beat the ISO OSI protocol suite.  Other examples
including the obvious case from Cisco may be justified on performance
grounds...or perhaps *were* justified before people started making
silicon that could classify IP headers at very high speed.


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

What's that about "virtual serial connections"?  Exactly what do you
mean?  Many and perhaps most serial connections are "virtual" today.

The IETF standard way for multiplexing virtual serial over an Ethernet
is TCP/IP.
Note that I am *NOT* talking about PPP/telnet/TCP/IP, PPP/rsh/TCP/IP,
or certain other kludges.  I'm expressing my confusion about "virtual
serial connections."

I suspect the idea is to run PPPoE over the radios, and instead of
terminating those PPPoE links in the base station radio card, idea to
be cheap and nasty and let some *other* router do the work of an access
concentrator router.



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

What is that about a "whole new protocol"?  

I do not understand what is running on the radio links.  What do is
used for access control/collision detection/etc., something in the
ALOHA tradition?  Or some kind of slotting or (virtual) token?  How do
you do framing?

What about authentication?  I think you or someone said it was plain
old PPP.   If that's right, is it PPPoE?  But I think other words
said no PPPoE on the real ether.



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

Again, as far as I can tell, the misperceptions are not mine but
fundamental to the proposal to use PPPoE as an inter-network protocol.
The glaring clue is it uses PPPoE for (de)multiplexing of 802.3 packets.


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

That is mistaken.  My reaction is not against using PPPoE, but against
using PPPoE as a replacement for IP.

>                                                   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 agree with that.


Vernon Schryver    [email protected]


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