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

From: "Jerome Moisand" <[email-masked]>
Date: Thu, 23 Feb 2006 11:44:38 -0500

James,

I don't know of any real-life use case where an AP is in the way, but
the protocol extension *IS* general-purpose, the MTU/MRU testing
mechanism option is there, and can be used. Tuning the default behavior
to the main use cases doesn't preclude to enable the other behavior in
other (yet unforeseen) environments. 

Adding an unnecessary round-trip (hence adding latency & burden) is
definitely a protocol issue, not an implementation issue.

I really have troubles to understand why a default setting should not be
tuned with the main use cases as known at the time of writing.

Where I do have sympathy for improving the text is NOT to change the
default setting, but to be more clear that the MTU/MRU test might find
other applications then simple troubleshooting. 

Because you are quite correct in pointing out that the unforeseen needs
to be somewhat accommodated. In other words, the 2nd part of the
following sentence is indeed limitative.

<< This capability SHOULD be disabled by default, and SHOULD only be
   available for debug, test purpose. >>

Maybe should we change it to:

<< This capability SHOULD be disabled by default, but SHOULD be
   available for debug & test purpose, or for topologies where a
   dynamically adaptive behavior is required.>>

Is this better? If you have a better wording, please speak up. I do
agree this sentence needs to be improved.

Tx
Jerome

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Thursday, February 23, 2006 11:00 AM
To: Jerome Moisand
Cc: Pekka Savola; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Pppext] Re: Last Call: 'Accommodating an
MTU/MRUgreaterthan1492in PPPoE' to Informational RFC

Jerome Moisand writes:
> 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.

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.

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

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

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

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

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 24 Feb 2006 08:48:59 +0200 (EET)

> tuned with the main use cases as known at the time of writing.

AFAIK, we're breaking IEEE Ethernet specifications by using jumbo 
frames (or, at the very least, using an unspecified features).  To me, 
that should imply it might be wise to err to the side of caution.

Note: it might be possible to do away with an extra roundtrip if 
that's issue, by adding some padding to the PPP/PPPoE messages 
themselves, instead of using separate PPP echo req/response.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings