Re: Reopening jumbo frames in IS-IS

[Curtis Villamizar <curtis at faster-light.net>]

Sorry for the late response.  Been away from email.

In message <015a01c57a75$4e1e7b70$6801a8c0 at stephen>
"Stephen Sprunk" writes:
>  
> Thus spake "Curtis Villamizar" <curtis at faster-light.net>
> > It probably would not hurt to have an informational draft describing
> > jumbo frames, the reason for needing a them, when to use them and
> > importantly when not to use them.
> >
> > Jumbo frames exists only to avoid the performance drop that would
> > otherwise potentially cripple core networks using GbE or 10GbE
> > and aggregating higher MTU links.  Since jumbo frames could
> > otherwise be harmful, it might make sense to ask that equipment be
> > capable of forwarding jumbo frames but originate standard MTU
> > frames (except when verifying MTU such as in ISIS) and that end
> > user devices such as NIC cards never originate jumbo frames.
>  
> That seems excessively restrictive.  There are many environments today using
> jumbo frames (8k-10k MTU) on end hosts without problems.
>  
> This also begs for a definition of what exactly a "jumbo" frame is; does an
> MPLS label (or several) on the front of a 1500-byte Ethernet frame count?
> Does a packet on media with a >1500 byte native MTU count?  Should a host on
> FDDI or a direct HDLC/PPP link be limited to 1500 byte packets -- even
> though its native MTU is 4470 -- because we fear it might need to talk to an
> Ethernet-connected host?

Jumbo frames specificly refers to ethernet.  FDDI, HIPPI, HDLC, PPP,
etc are not affected.  It was these interfaces at end systems with
100baseT, GbE, and 10GbE in provider POPs that created the requirement
for ethernet jumbo frames.

No one in their right mind (note that I this is a qualified "no one")
would bridge a PPP link to an ethernet link.  Standards should
discourage doing incredibly stupid things rather than try to
accomodate people who do them with no good reason for doing so.

TCP and most other modern protocols handle the end system MTU quite
nicely and TCP path MTU discovery is widely implemented and easy
enough to enable though I think it is still disabled by default in
most implementations.

> > It should also be clearly stated that jumbo frames be disabled by
> > default and any equipment supporting them at the very least put
> > harsh warnings in the equipment's user documentation about the
> > feature being non-standard and has a potential to cause
> > interoperability problem if just casually enabled.
>  
> I certainly agree that jumbo frames should be disabled by default, and the
> warning should explicitly note that severe problems will result if hosts on
> the same subnet have different ideas of what the MTU is.  I personally have
> never seen a problem with jumbos when every device on a subnet supports them
> and is configured with the same MTU, but perhaps someone else can offer some
> enlightening anecdotes.
>  
> We might consider adding a means for hosts configured with a "jumbo" MTU to
> determine if all of its neighbors (and intermediate L2 devices) can indeed
> handle such packets.  If such a mechansim existed, we could allow jumbos to
> be on by default since hosts could detect when it was necessary to fall back
> to a non-jumbo MTU.
>  
> S

If used in a SP network, the SP generally knows what is connected much
more so than in an enterprise environment where anyone could connect
anything.

> Stephen Sprunk      "Those people who think they know everything
> CCIE #3723         are a great annoyance to those of us who do."
> K5SSS                                             --Isaac Asimov

Curtis