Re: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 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.

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

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

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf