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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf