James,
I don't know of any real-life use case where an AP is in the way, but
the protocol extension *IS* general-purpose, the MTU/MRU testing
mechanism option is there, and can be used. Tuning the default behavior
to the main use cases doesn't preclude to enable the other behavior in
other (yet unforeseen) environments.
Adding an unnecessary round-trip (hence adding latency & burden) is
definitely a protocol issue, not an implementation issue.
I really have troubles to understand why a default setting should not be
tuned with the main use cases as known at the time of writing.
Where I do have sympathy for improving the text is NOT to change the
default setting, but to be more clear that the MTU/MRU test might find
other applications then simple troubleshooting.
Because you are quite correct in pointing out that the unforeseen needs
to be somewhat accommodated. In other words, the 2nd part of the
following sentence is indeed limitative.
<< This capability SHOULD be disabled by default, and SHOULD only be
available for debug, test purpose. >>
Maybe should we change it to:
<< This capability SHOULD be disabled by default, but SHOULD be
available for debug & test purpose, or for topologies where a
dynamically adaptive behavior is required.>>
Is this better? If you have a better wording, please speak up. I do
agree this sentence needs to be improved.
Tx
Jerome
-----Original Message-----
From: James Carlson [mailto:james(_dot_)d(_dot_)carlson(_at_)sun(_dot_)com]
Sent: Thursday, February 23, 2006 11:00 AM
To: Jerome Moisand
Cc: Pekka Savola; pppext(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
iesg(_at_)ietf(_dot_)org
Subject: RE: [Pppext] Re: Last Call: 'Accommodating an
MTU/MRUgreaterthan1492in PPPoE' to Informational RFC
Jerome Moisand writes:
All broadband carriers I know of have very clear plans to use Ethernet
aggregation gear and Ethernet interfaces on both DSLAM and BRAS which
are enabled for jumbo-frames. All corresponding equipment vendors I
know
do support such feature.
If there's just one customer-owned non-jumbo bridge in the way (e.g.,
an 802.11 AP), then your whole day is shot.
So this isn't a fairly arbitrary topology like could be found in an
enterprise environment or a campus environment. It is a very
controlled
environment with strict deployment rules.
That's the part that seems really inappropriate for any sort of
document published via the IETF. History tells us that we have very
little ability to predict the future -- and essentially none at all
when it comes to the distant future.
Designing a protocol that works only in one particular deployment
scenario but falls on its face elsewhere seems tragically short-
sighted to me. (Perhaps it's ultimately a good thing overall, if it
just causes customers to abandon vendors using solutions that fail.
But getting there is tough and unnecessarily hazardous.)
Based on that, enabling such verification by default (with the
additional roundtrip implied) is just a completely unnecessary burden,
and when you have to deal with 20K or 40K PPPoE sessions, including
major peaks when a GE link is restored after failure, this is rather
impactful.
That's still an implementation issue, not a protocol issue. If you
can't handle the load (a decent design should, as this is by far the
least of the duties it might face), then spread it out.
--
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