I think we have to be mindful of the primary use case here, and be
actually driven by it.
The primary use case is a DSL scenario, where the aggregation network
behind the DSLAM is Ethernet down to an IP edge router (call it BRAS or
BNG, as you want) which processes PPPoE.
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.
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.
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.
This is the rationale for disabling the mechanism by default, while
allowing to enable it whenever one really needs it (e.g. debugging
purposes; or some new use case nobody thought about so far).
This is admittedly a pragmatic, use-case driven, recommendation.
Tx
Jerome
-----Original Message-----
From: Pekka Savola [mailto:pekkas(_at_)netcore(_dot_)fi]
Sent: Thursday, February 23, 2006 1:26 AM
To: Peter Arberg
Cc: pppext(_at_)ietf(_dot_)org; 'Veera Tubati (vtubati)';
ietf(_at_)ietf(_dot_)org; 'James
Carlson'; iesg(_at_)ietf(_dot_)org
Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU
greaterthan1492in PPPoE' to Informational RFC
On Tue, 21 Feb 2006, Peter Arberg wrote:
It will without a doubt make the solution more robust if the echo test
was performed upon setup, and we could change the recommendation to
not
specific say this capability SHOULD be disabled, so changing it from
---
This capability SHOULD be disabled by default, and SHOULD only be
available for debug, test purpose.
---
to something like this:
---
This capability MAY be disabled by default, but SHOULD be
available for debug, test purpose.
---
if you think that will make it a little better.
Couldn't we say even more than that, simply like:
This capability SHOULD be used by default.
or:
This capability SHOULD be used by default to verify that the
negotiated MTU/MRU actually works.
That would allow anyone to disable it (or not implement it) and still
be compliant with the spec.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Pppext mailing list
Pppext(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/pppext
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf