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

[James Carlson <[e-mail]>]

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.

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

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

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.

-- 
James Carlson, KISS Network                    <[e-mail]>
Sun Microsystems / 1 Network Drive         71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]

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