RE: draft-arberg-pppoe-mtu-gt1492-00
James Carlson <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
Jerome Moisand writes: > ==> This feature is intended as a "safety net" and a troubleshooting > mechanism, but using it for every PPP session establishment would > significantly lower call setup performance, while not adding any > meaningful value to typical broadband environments. Personally, I am > actually not entirely convinced this feature is worth the trouble! Performance will be much worse if there's a bridged link in path between PPPoE client and server that restricts the MTU to the IEEE-specified maximum. Worse still, if you have a network with multiple paths for redundancy (using Spanning Tree), the path you take during PPPoE/PPP session set-up may be different than the one you take after a successfully-handled L2 link failure, and you get no notification that this has happened, and the restrictions on the new path through the L2 network may differ. In other words, I remain skeptical that this can actually be deployed safely without having the IEEE itself redefine the L2 header/payload split to conform to what this proposal is actually doing. And I think it's somewhat outside the bounds of normal IETF activity to have a published RFC that suggests doing something that isn't supported by the underlying non-IETF standards. If the draft authors are going to go ahead anyway with publication as an Informational document, I'd like to see a disclaimer near the top of the document stating that the procedure described does not conform to IEEE standards, isn't endorsed by the IETF/IESG, and may simply fall apart in some deployments. > ==> I'd like to propose that we introduce a new PPPoE tag where the > PPPoE client indicates if the 1492 constraint can be lifted (in its best > assessment of its own capabilities and of the network it is connected > to), and to which extent (up to 1500, possibly more). If such new option > isn't included by the client, then the existing behavior must be > assumed. I agree. That fixes the naive-client problem; thanks. -- James Carlson, KISS Network <[email protected]> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pppext