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

James Carlson wrote:

>Elwyn Davies writes:
>  
>
>>>This document is extending PPPoE, which by no means is a standard of 
>>>any kind. I'm not sure what status other than Informational I could 
>>>ask for here.
>>>      
>>>
>>As has been said elsewhere it isn't entirely clear why PPPoE is 
>>Informational.
>>    
>>
>
>It duplicates L2TP and wasn't an IETF effort.
>
>  
>
>> Be that as it may, the mechanism in section 5 is 
>>actually an extension to PPP if it were done properly (as I said in the 
>>review the contents of s5 is IMO unaccpetable - it avoids defining a new 
>>PPP packet format by hacking in an extra field).
>>    
>>
>
>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..  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'.  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.  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.

>PPP intentionally doesn't do any sort of flow control.  But if you
>were to do it there, an extension of RFC 1663 would probably be the
>best way to do it.
>  
>
Indeed: but I am not qualified to judge the relevance or effectiveness 
of the scheme - for the purposes of this review I have only to decide if 
I think one could build interoperable implementations for the spec here.

>Just for reference, the deployment scenario that the draft authors
>employ (not that I personally agree that this is at _all_ a good idea,
>and thus the warning proposed):
>
>	Server <-- PPPoE ---> Gateway <--- async ---> Client
>
>In this scenario, "Server" and "Gateway" are using PPPoE as though it
>were a pseudo-wire protocol.  In using it as a wire-like protocol,
>they feel they need a flow control mechanism comparable to the flow
>control present on the comparatively regular async link between
>"Gateway" and "Client."
>
>The right answer, of course, is to just terminate plain old PPP in the
>"Gateway" device and route (or bridge or otherwise forward) IP
>everywhere, but the draft authors are not interested in that solution
>and we (in the working group) have been unsuccessful in arguing them
>away from it.
>
>(And since the IETF operates an Informational RFC vanity press ...)
>  
>
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.

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art