[131859] in North American Network Operators' Group
Re: RINA - scott whaps at the nanog hornets nest :-)
daemon@ATHENA.MIT.EDU (Matthew Petach)
Sat Nov 6 17:34:51 2010
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C7D8@RWC-EX1.corp.seven.com>
Date: Sat, 6 Nov 2010 14:34:44 -0700
From: Matthew Petach <mpetach@netflight.com>
To: George Bonser <gbonser@seven.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sat, Nov 6, 2010 at 2:21 PM, George Bonser <gbonser@seven.com> wrote:
>
...
> As for the configuration differences between units, how does that change
> from the way things are now? =A0A person configuring a Juniper for 1500
> byte packets already must know the difference as that quirk of including
> the headers is just as true at 1500 bytes as it is at 9000 bytes. =A0Does
> the operator suddenly become less competent with their gear when they
> use a different value? =A0Also, a 9000 byte MTU would be a happy value
> that practically everyone supports these days, including ethernet
> adaptors on host machines.
While I think 9k for exchange points is an excellent target, I'll reiterate
that there's a *lot* of SONET interfaces out there that won't be going
away any time soon, so practically speaking, you won't really get more
than 4400 end-to-end, even if you set your hosts to 9k as well.
And yes, I agree with ras; having routers able to adjust on a per-session
basis would be crucial; otherwise, we'd have to ask the peeringdb folks to
add a field that lists each participant's interface MTU at each exchange,
and part of peermaker would be a check that could warn you,
"sorry, you can't peer with network X, your MTU is too small." ;-P
(though that would make for an interesting deepering notice..."sorry, we
will be unable to peer with networks who cannot support large MTUs
at exchange point X after this date.")
Matt
