draft-arberg-pppoe-mtu-gt1492-00

I have a few questions and comments on this draft:

  - In the scenario identified as "Fig. 3" (PPPoA to PPPoE
    conversion), why wouldn't the device labeled "DSLAM" in that
    picture just alter the LCP negotiation messages in flight, so that
    if the PPPoA side attempts anything over 1492, the MRU is just
    negotiated downwards as necessary?

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

  - Why is the action on failure of Echo-Request just to assume a
    different peer MRU?  I'd expect that a better way to deal with
    this would be to renegotiate LCP, and make sure that the MRU is
    lowered in both directions.  (It may well be the case that only
    one end notices the problem.)

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

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