RE: warning suggestions for draft-bberry-pppoe-credit

Stan Ratliff (sratliff) writes:
> >Ethernet supports multiple protocols.  What would you do if someone
> >ran some protocol *other* than PPPoE over this pseudo-Ethernet?
> >Wouldn't you be forced to fix the problem all over again?
> >
> 
> I don't understand what you mean here. In our implementation, the 
> radio and router are connected via a real Ethernet, not a pseudo-
> Ethernet. There is no intersection I'm aware of with other devices 
> on the Ethernet communicating with each other via different protocols. 
> The intent isn't to create a pseudo-Ethernet with the extensions,
> rather, 
> the intent is to create a group of pseudo point-to-point links,
> representing
> the individual TDMA radio links, tunneling over the Ethernet connection 
> from radio to router. 

It's Ethernet ... but with a kind of L2 backpressure mechanism that
regular Ethernet itself doesn't quite have.

My point is that if you had something *other than* PPP to transmit to
those nodes over the radio, then you'd be sunk.  You'd have to start
over because PPPoE carries only PPP.

Your assertion seems to rest on a particular deployment and
combination of protocols: PPP (and nothing else) between radio and
remote nodes, Ethernet (and nothing else) between radio and router,
and no way to implement the patently obvious solution -- just
terminating PPP in the radio and using regular L2 forwarding or IP
routing outside of that context.  No PPPoE required.

Its narrowness makes it extremely suspicious.  I agree that there may
well be a problem here that needs to be solved.  I'm deeply concerned
that this doesn't actually address the problem in any lasting way and
is instead a diversion for developers.

>   "The techniques described in this document will not be applicable
>   to all radio implementations. This document describes extensions 
>   better applied to radios with point-to-point transmission 
>   characteristics (e.g. TDMA). When used with multi-access, broadcast
>   capable radios such as 802.11, these techniques may have unpredictable
>   interactions with higher and lower layers."

How about:

  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.

-- 
James Carlson, KISS Network                    <[email protected]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

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