rja at inet.org
Thu May 31 21:40:50 UTC 2001
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.
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,...
More information about the NANOG