Re: I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt

> From: Bo Berry <[email protected]>

> Agree with the interoperability concerns brought forth
> by J. Carlson.  This is a real problem.  Also performance
> gain from 1492 to 1500 in the scheme of things is negligible.

except when the PPPoE link is not directly connected to the sending host
and you get the problems of IP fragmentation

or except when path MTU discovery is used and something doesn't
generate or filters ICMP messages, and you get intermittent blackholes


> If you are really set on gaining 8-bytes, consider defining
> optional tags to negotiate the extended/longer MTU.  This
> method would be backward compatible. 

What is an "optional tag"?  I kind of understand various PPP
Configure-Request options, but they are not what I'd call tags.  As
James Carlson wrote, the IETF seems an unlikely forum for modifying
IEEE standards.

Is there no way to use the LCP MR option to negotiate an effective MTU
of 1500 on media that differs from classic IEE 802.3 by having a data
size of 1508 or larger?  Why can't an advanced PPPoE box offer an MRU
of 1508 or ask for an MTU of 1508 using a Configure-Nak?

The PPPoE 8 byte overhead hassle is far from unique in the PPP world.
MP (multilink) and CCP (compression) are two common examples.  For
that matter, why couldn't advanced PPPoE boxes use PPP MP fragmentation
much as other PPP boxes handle the CCP and MP headers?


>                                       Another suggestion
> is to publish as an Informational RFC.

Whether the proposal RFC is Informational or on the standards track 
would not affect the interoperability problems.


Vernon Schryver    [email protected]

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