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

"Jerome Moisand" <[email protected]>
Newsgroups gmane.ietf.pppext
Message-ID <[email protected]>
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 protected]
https://www1.ietf.org/mailman/listinfo/pppext
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.