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

From: James Carlson <[email-masked]>
Date: Mon, 16 May 2005 09:33:02 -0400

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

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

---

From: "Peter Arberg" <[email-masked]>
Date: Wed, 18 May 2005 22:39:35 -0400

James,

Thanks for your interest in the internet-draft, I have tried
to answer your questions inline in the email.

>     negotiated downwards as necessary?

The intention discussed in DSL Forum at the moment is that the DSLAM
only initiate the PPPoE session, and not alter the actual PPP or LCP
packets.

I guess that it would be doable for the DSLAM to alter the LCP packets 
in flight, but if the main concern here is that some existing PPPoA
client will not accept a smaller MRU than 1500 bytes, then the fact
that the DSLAM will downsize the MRU, will leave a PPP session with
2 end-points having a wrong view of the other end-points MRU, and as such
this will either result in no connection, or the DSLAM having to perform
PPP packet fragmentation, as I see it ?

>     this feature, but why would that necessarily be the default?)

The reason for disabling this functionality by default, is because
the PPPoE client and server must work in a backward compatible 
setup by default, and as such it is anticipated that an active
configuration of both the RG client and the BRAS PPPoE server is
needed for them to suggest and accept a MRU greater than 1492.

When such an active configuration is needed to make PPPoE MRU higher
than 1492, it is expected that Service Providers know their network
well enough to only turn on this functionality when the intermediate
systems support Ethernet MTU higher than 1500 bytes.

By disabling this functionality, we are saying that PPP session setup
time is more important than a per session setup security check, BUT 
at the same time we agree that a troubleshooting functionality is needed 
in case end-to-end connectivity can not be established.

>     one end notices the problem.)

That is a good suggestion, so do you suggest that it still test the
link with 1492 byte packets before initiate a MRU renegotiation ?

Our concern was the danger of PPP client implementations might have
trouble with renegotiation of one or more layers, but you are right
in the scenario where only end notice the problem, then our suggestion
will not correct this, so initiating a new LCP negotiation for MRU 1492
will be the right thing.

>     some mitigating feature is included by default.)

I expect that there already are systems out there that will try and
initiate a 1500 byte MRU, but I do not know of any production code
doing so.

By testing some existing RG PPPoE clients and some BRAS PPPoE Servers,
it has shown different behavior from NAK greater MRU to silently
ignoring it, but so far with the limited test we have done, we have
not seen any catastrophic behavior.

cheers,
Peter

--------------------------------------
 Peter Arberg
 Redback Networks
 office: 1 (408)750 5423
 email:  [email-masked]
 Web:    http://www.redback.com/
--------------------------------------

---

From: Frank Cusack <[email-masked]>
Date: Sat, 21 May 2005 14:53:37 -0700

Just chiming in ...

> PPP packet fragmentation, as I see it ?

And how would the DSLAM be able to fragment?  (It couldn't, AFAIK, in a pass-
through scenario.)

If the two peers had an incorrect idea of the other's actual MRU, this doesn't
matter because the incorrect MRU would be *smaller* than the actual MRU and so
all transmitted packets would be acceptable.

Is it broken for PPPoA clients to not accept small MRUs?

/fc