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

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

Regards,
Stan

>-----Original Message-----
>From: James Carlson [mailto:[email protected]] 
>Sent: Thursday, December 08, 2005 1:06 PM
>To: Stan Ratliff (sratliff)
>Cc: [email protected]
>Subject: RE: [Pppext] 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