RE: jumbo frames

[RJ Atkinson <rja () inet org>]

At 16:47 31/05/01, Lane Patterson wrote:
> I have been tracking jumbo frame support trends for a while, and
> am reasonably disappointed by lack of standards and vendor willingness
> to support jumbos (yes there are very REAL h/w design considerations, 
> so until operators demand jumbo support and folks test it in realistic
> environments, it's not going to happen).  

I believe most GigE switch vendors currently support ~9180 IP MTU
over GigE interfaces.  IEEE 802 committee has repeatedly and 
deliberately declined to make that an official standard however.

A number of the host vendors (e.g. Sun) appear to be listening
to customer requests for support of that IP MTU size also.

> Unfortunately, many of the folks most adamant about maintaining 4470
> in their core are therefore sticking with POS everywhere, so their 
> requirement is not making it to the ether vendors.

        POS could be configured at various MTUs, right ?
        4470 is just a historical choice equal to FDDI, right ?
        Folks could engineer their POS links to use ~9180, I think,
        if they wanted to do so.

> There are different reasons to use several different sizing parameters:
>
>        "Mini-jumbo": say 1518, 1540, etc.  the idea here is that you
>                can handle stacked tunnels and LAN encapsulations, such
>                as stacked headers of 802.1Q, MPLS, IP/GRE tunnels, etc.
>                while still preserving "1500 for the edge"
>
>                Applicability:  802.1Q, VPN, MPLS, and other encap-based 
>                        or tunnel-based applications

I believe at least 802.1q support is quite commonplace these days.

>        "Mid-jumbo": say 4470: the idea is to make sure a backbone can
>                preserve its MTU across both ethernet, ATM, and POS links
>                within its diameter, and conceivably between networks via
>                IX's that support jumbos.  This in fact may be critical
>                for folks running large ISIS implementations that need 
>                to ration # of LSPs:

        This number derives from FDDI MTU, which was formerly
commonly used as the basis for many an exchange point.

> http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-02.txt

        I believe IEEE 802 committee officially opposes the above draft,
though I could be misinformed.


>        "Real jumbo": not standardized, 

        Kindly see RFC-1626, which is where this number and
rationale came from.  The correct number, btw, is 9180 bytes 
as an IP MTU.

>                but somewhere between 8100-9100B,...