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

James,

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

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

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 ?

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

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.

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

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.

 
>   - 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 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:  parberg <at> redback.com
 Web:    http://www.redback.com/
--------------------------------------

> 
> -- 
> James Carlson, KISS Network                    
> <james.d.carlson <at> sun.com>
> 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
> Pppext <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/pppext
> 

_______________________________________________
Pppext mailing list
Pppext <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pppext