Pekka Savola writes:
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..
I think it is. What's really needed is some end-to-end mechanism
within 802 itself for making sure that the MTU on the path is
correct. That mechanism doesn't really exist.
There are several problems here. First of all, there are several
PPPoE implementations that will assume a fixed limit of 1492 (based on
requirements of the 802 the standards), no matter what PPP attempts to
negotiate. So merely having the LCP MRU option show something larger
won't help -- the peer already "knows" that the path can't possibly be
that wide.
Now, it'd be reasonable to have LCP negotiate an MRU > 1492, and then
use LCP Echo-Request (in parallel with IPCP start-up) to verify that
the path really supports packets that large. If it doesn't, then
restart LCP and negotiate a fixed 1492. That wouldn't require any
protocol changes at all.
I think something like that is what you're suggesting. It seems
reasonable to me, except that I think the draft authors wanted
explicit signaling between the peers to enable the new mode of
operation.
--
James Carlson, KISS Network
<james(_dot_)d(_dot_)carlson(_at_)sun(_dot_)com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf