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

Not exactly sure what non-IEEE-compliant mechanism you are referring to?

Using a PPP MRU of 1500 over PPPoE clearly implies the use of an
Ethernet frame size larger than 1500 bytes, but IEEE standards now
support such technology (aka jumbo-frames, mini jumbo frames, etc).

So if all network segments between the PPPoE "newer" client and the
PPPoE server support such larger frame as a deployment rule, then we
have no issue, and this seems to me as being fully IEEE compliant.
Practically speaking, the DSL topologies that we have in mind would
indeed have such property.

Yet we need the mitigation mechanism to deal with legacy cases, and
notably home LANs limited to 1500 Ethernet frames.

Am I missing something?

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