[Gen-art] Re: Gen-art review of draft-bberry-pppoe-credit-04.txt

[Elwyn Davies <[e-mail]>]

James Carlson wrote:

>Elwyn Davies writes:
>  
>
>>>I don't think an extension to PPP would be acceptable to the folks
>>>proposing this PPPoE extension, as that would require changes to the
>>>remote PPP nodes (which are _not_ connected via PPPoE).
>>> 
>>>
>>>      
>>>
>>I am not sure I follow the logic here: Either the modified form of 
>>packets defined in s5 gets to the remote node or it doesn't..
>>    
>>
>
>View the diagram again:
>
>	Server <-- PPPoE ---> Gateway <--- async ---> Client
>
>The proposed protocol runs between Server and Gateway alone.  It does
>_not_ affect the PPP session that runs between Server and Client.
>
>The draft author is able to change Server and Gateway to add this new
>feature.  He cannot change Client.  Those messages do not go to the
>Client, so there's no problem there.
>
>  
>
>> In the 
>>former case, something around the bottom of PPP has to be modified - in 
>>the latter case, conventional PPP works.  If something has to be 
>>modified IMHO it would be better done 'properly'.
>>    
>>
>
>Indeed.
>
>  
>
>> However whether it is 
>>done properly or not, the credit tag effectively needs a previously 
>>unused value from the PPP DLL protocol space to distinguish it from any 
>>PPP packets that might be carried without credit tags.
>>    
>>
>
>No; see above.  It does *not* affect the end-to-end PPP connection;
>merely the leg of that connection that traverses PPPoE.
>
>The author is using PPPoE as if it were a wire emulation protocol and
>he wants flow control in it for that reason.
>  
>
OK - I (now) understand what is being proposed.

>  
>
>> If it is not 
>>allocated properly there is a risk down the line that the value will be 
>>allocated for a 'real' PPP protocol and things then break. Whether you 
>>call this a modification to PPP or not is hair splitting.
>>    
>>
>
>No, that's not what I was saying at all.
>
>PPPoE and PPP are independent protocols.  PPP tunnels over PPPoE.
>  
>
That's fine and dandy but I think the problem is that as drafted, some 
of the PPP packets would not have any credit tag on them so you have to 
distinguish between the ones with a credit tag plus a PPP packet and 
those that just have a PPP packet. A strange form of tunnel!

>  
>
>>I am sure I couldn't comment on this.. but I have to believe that we 
>>should avoid offering to advertise the Emperor's New Clothes.
>>    
>>
>
>It's not exactly "Emporer's New Clothes."
>  
>
There certainly appear to be a few rents leaving the naughty bits 
showing ;-)

>It's a rough solution to a manufactured problem.  The "problem" would
>not exist if any of the following were true:
>
>  - If the author simply ran regular PPP to the Gateway device,
>    terminated PPP there (turning "Gateway" into an access router,
>    rather than just a concentrator device), and routed the IP packets
>    normally, then there'd be no need for PPPoE in this picture at
>    all.
>
>  - If the author just gave up on flow control over the link, because
>    flow control is really a problem for higher-layer (transport and
>    above) protocols, then the problem would not exist.
>
>  - If RFC 1663 reliable were used, then link level flow (and error)
>    control would exist.
>
>  - If the linkage between Server and Gateway were something that
>    allowed for flow control and multiple sessions (something other
>    than Ethernet; say, Frame Relay), then that would potentially
>    provide the solution.
>
>There are probably other ways to accomplish the goal.  The reason it's
>a problem is the essentially ad-hoc nature of the "required"
>deployment architecture.
>
>  
>
I think we know where we stand on this one and we don't need to expend 
any more cycles on it.  Let's see what happens...

Happy New Year,
Elwyn

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art