RE: draft-arberg-pppoe-mtu-gt1492-00

James and al.

1. You made me check, and you are indeed correct about the lack of IEEE
standard for jumbo-frames. This is such a widely supported practice
though and DSL providers have enough control on the access/aggregation
network to easily enforce support for jumbo-frames on each network
segment. 
=> Agreed, you have a point, a disclaimer might be in order.

2. New PPPoE tag: we're in agreement here. I'm going to make a proposal
for including such mechanism in an update to the proposed I-D, after
syncing up with the existing co-authors. 

Please note that this entire discussion applies to tens of millions of
DSL lines worldwide. So this is quite a real-life situation.

Tx
Jerome

-----Original Message-----
From: James Carlson [mailto:[email protected]] 
Sent: Friday, July 01, 2005 1:35 PM
To: Jerome Moisand
Cc: [email protected]
Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00

Jerome Moisand writes:
> ==> This feature is intended as a "safety net" and a troubleshooting
> mechanism, but using it for every PPP session establishment would
> significantly lower call setup performance, while not adding any
> meaningful value to typical broadband environments. Personally, I am
> actually not entirely convinced this feature is worth the trouble!

Performance will be much worse if there's a bridged link in path
between PPPoE client and server that restricts the MTU to the
IEEE-specified maximum.  Worse still, if you have a network with
multiple paths for redundancy (using Spanning Tree), the path you take
during PPPoE/PPP session set-up may be different than the one you take
after a successfully-handled L2 link failure, and you get no
notification that this has happened, and the restrictions on the new
path through the L2 network may differ.

In other words, I remain skeptical that this can actually be deployed
safely without having the IEEE itself redefine the L2 header/payload
split to conform to what this proposal is actually doing.  And I think
it's somewhat outside the bounds of normal IETF activity to have a
published RFC that suggests doing something that isn't supported by
the underlying non-IETF standards.

If the draft authors are going to go ahead anyway with publication as
an Informational document, I'd like to see a disclaimer near the top
of the document stating that the procedure described does not conform
to IEEE standards, isn't endorsed by the IETF/IESG, and may simply
fall apart in some deployments.

> ==> I'd like to propose that we introduce a new PPPoE tag where the
> PPPoE client indicates if the 1492 constraint can be lifted (in its
best
> assessment of its own capabilities and of the network it is connected
> to), and to which extent (up to 1500, possibly more). If such new
option
> isn't included by the client, then the existing behavior must be
> assumed.

I agree.  That fixes the naive-client problem; thanks.

-- 
James Carlson, KISS Network                    <[email protected]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

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