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 <james.d.carlson@xxxxxxx>
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
Pppext@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
| 
