RE: comment on draft-arberg-pppoe-mtu-gt1492-02.txt

Hi Tom, Peter,

On Mon, 28 Nov 2005, Tom Mistretta wrote:

>
> The value in this tag was not added just for convenience.
>
> - While I am not going to defend it, it's possible to use jumbo-frames
> larger than 1500 (as opposed to in-between 1492 and 1500).
>
> - Additional negotiations and retries during LCP shouldn't be
> trivialized.

> - PPPoE has had a troubled history, partially due to assumptions 
> that were made by different implementations (MxU, retry behavior 
> etc).  The use of an unqualified flag runs the risk of continuing 
> that trend, either by placing assumptions on values or overloading 
> the flag for other purposes.

The flag would return PPPoE to normal PPP wrt the default and MxU 
negotiation (which would /not/ be needed for 1500 - it'd be the 
default). Anything greater requires LCP negotiation as per normal 
PPP, as does the draft btw.

I think this is an opportunity to /reduce/ divergence of PPPoE from 
PPP. Previous divergence in PPPoE is exactly why this draft is 
required. Introducing yet further divergence seems unwise to me, 
particularly when there appears to be no good protocol reasons for 
it.

The quality of implementation issues seem to be utterly irrelevant to 
me, if an implementation can not get:

if (Max-Payload tag present)
 	initial/default MTU is standard-PPP (1500)
else
 	initial/default MTU is RFC2561 (1492)

right, it has bigger problems, and I'm not sure how you could trust 
that such implementations would describe the value they intend to use 
in Max-Payload correctly.

I can easily imagine an implementation being coded to think that the 
Max-Payload value indicates a /default/ MTU, that it can specify 
values in this field and then /not/ have to do LCP negotiation for 
that value (which the draft requires). That seems quite plausible 
given the concerns regarding ability to implement reliably even just 
the above psuedo-code.

I.e. adding a value just /increases/ the scope for assumptions, imho.

> We are advocates of the specific value.

Well, I've given my feedback. I obviously disagree, but I'll leave it 
at that and defer to experience of implementors.

regards,
-- 
Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
Fortune:
The gent who wakes up and finds himself a success hasn't been asleep.

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