RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC

["Peter Arberg" <[e-mail]>]

Hi Pekka,

thanks for your comments, I have added some comments inline.
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Pekka Savola
> Sent: 17. februar 2006 23:00
> To: James Carlson
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Pppext] Re: Last Call: 'Accommodating an 
> MTU/MRU greater than1492 in PPPoE' to Informational RFC
> 
> On Fri, 17 Feb 2006, James Carlson wrote:
> > Pekka Savola writes:
> >> This doc seems to define a PPPoE option 'PPP-Max-Payload'. 
>  It talks
> >> of using PPP MRU option.  There is no PPP MTU option that 
> I could see.
> >>
> >> My question here is, should there be a PPP MTU option instead of a
> >> PPPoE option?  This would be a more generic solution to 
> this part of
> >
> > I don't follow.  PPP is symmetric -- there are two MRUs negotiated,
> > one for each direction.  Your peer's MRU is your maximum 
> >(and default) MTU.
> 
> Your peer's MRU is not directly your MTU, because the MTU could be 
> lower as well (e.g., capped by the interface MTU).  But yes -- this 
> was mentioned in the pseudo-code.

right, this is shown in the pseudo-code.


> > How could we need another option for this?  Or how could one help?
> >
> > What's really going on here is negotiation about the existence of a
> > usable path.  Unfortunately, the underlying protocol itself (other
> > than LLDP) doesn't provide a way to do this.  This new 
> > mechanism thus
> > doesn't solve the actual problem, but does at least allow consenting
> > peers to identify each other.  (In other words, I view it as just a
> > boolean.)
> 
> I guess the problem I was having here is that I didn't understand why 
> a PPPoE MTU options would be useful (still don't).  After 
> all, if both PPP endpoins would signal MRU = 2000 (for example), then 
> PPPoE could just use that with no need for an extra option?  Looking back 
> at the archives, it appears others have had related concerns, so I 
> guess this is beating a dead horse..

When we published the first version of the draft, it was actually to do
just so, simply let the PPPoE endpoints negotiate a higher MRU than the 
RFC2516 limitation of 1492.

But during different vendor testing, it unfortunately became clear that
some older PPPoE clients would request 1500 in a MRU negotiation, but not
be able to handle it... sínce PPPoE servers = BRAS have been taking care
of this issue earlier and not allowed more than 1492 even if the client
asked for 1500, it has not been a problem so far.

But now we needed a way to differentiate the "new" clients who can handle
1500 when they ask for it and the "old" clients who can't.  The PPPoE TAG
is the proposal for this, to give better interoperability for higher MRU
negotiation.

This has been discussed on the list back in May-05.


> >> MRU test procedure using MRU-sized Echo-Requests is disabled by
> >> default and to be used for debug purposes only.  I'm questioning
> >> whether this is wise.  The protocol would be much more 
> >> robust against
> >
> > I don't think it is.  But we did discuss that during the document
> > review.
> 
> I reviewed the mailing list archives for the last 6 months, and at 
> least during that period I didn't see this discussed.
> 
> But let me qualify that.  "The protocol would be more robust against 
> ..." instead of "much more".  That is at least an objective 
> statement: 
> as the document specifies that all PPPoE servers MUST support this 
> mechanism, sooner or later someone is going to misconfigure too high 
> MTU usage when jumboframes aren't enabled, or someone is going to 
> disable jumboframes somewhere on the path.  Currently there is no 
> jumboframe spec that I'm aware of, and there is no way to recover or 
> notice these situations that I can think of.

I agree it would be "more robust" following your suggestion, but this
was also discussed back in May-05, and it is a consious choice we made
and say Service Providers knows their network, and as such by disabling 
this functionality by default, 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.

Also we did include based on James suggestion the following warning because 
there is no jumbospec. 

---
   The procedure described in this document do not strictly conform 
   to IEEE standards for Ethernet packet size, but rely on a widely 
   deployed behavior of supporting jumbo frames on Ethernet segments.
---

cheers,
Peter

> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> _______________________________________________
> Pppext mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pppext
> 



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