Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00

From: "Jerome Moisand" <[email-masked]>
Date: Fri, 1 Jul 2005 13:14:56 -0400

Reacting to some James Carlson questions:
 
  - Why is the "recommended" Echo-Request probing mechanism -- the
    only thing other than LLDP that can deal with L2 MTU issues --
    disabled by default?  Isn't that just asking for trouble?  (I can
    see why an implementation might want to have an option to disable
    this feature, but why would that necessarily be the default?)
 
==> 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!
 
  - What does the interoperability picture look like?  Are there
    deployed implementations that attempt to negotiate an MRU of 1500,
    and is this commonly ignored on PPPoE links?  (I suspect that the
    answers here are "yes" and "yes" -- meaning that changing the
    behavior of MRU negotiation on PPPoE, which previously had a hard
    cap at 1492, will likely break existing implementations, unless
    some mitigating feature is included by default.)

==> I share the concern. There will be situations with a mix of legacy
or newer PPPoE clients, and given the pretty diverse (to be polite)
behaviors of some PPPoE clients and the legacy of home LANs not
supporting mini-jumbo Ethernet frames, it doesn't seem safe to do
anything not strictly upward-compatible.

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

Tx

Jerome Moisand

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

---

From: James Carlson <[email-masked]>
Date: Fri, 1 Jul 2005 13:34:50 -0400

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

> isn't included by the client, then the existing behavior must be

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

-- 
James Carlson, KISS Network                    <[email-masked]>
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