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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]