RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greaterthan1492in PPPoE' to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx] 
Sent: Thursday, February 23, 2006 1:26 AM
To: Peter Arberg
Cc: pppext@xxxxxxxx; 'Veera Tubati (vtubati)'; ietf@xxxxxxxx; 'James
Carlson'; iesg@xxxxxxxx
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]