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

From: "Jerome Moisand" <[email-masked]>
Date: Thu, 23 Feb 2006 10:41:14 -0500

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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: James Carlson <[email-masked]>
Date: Thu, 23 Feb 2006 11:00:10 -0500

> are enabled for jumbo-frames. All corresponding equipment vendors I know

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.

> 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.)

> major peaks when a GE link is restored after failure, this is rather

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                    <[email-masked]>
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