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.d.carlson@xxxxxxx] Sent: Thursday, February 23, 2006 11:00 AM To: Jerome Moisand Cc: Pekka Savola; pppext@xxxxxxxx; ietf@xxxxxxxx; iesg@xxxxxxxx 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.d.carlson@xxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf