[RAM] Tunnelling & GigE jumbo frame size

RJ Atkinson <rja@extremenetworks.com> Wed, 12 September 2007 14:24 UTC

Return-path: <ram-bounces@iab.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT9F-0003yP-Bv; Wed, 12 Sep 2007 10:24:57 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT9D-0003y8-UD for ram@iab.org; Wed, 12 Sep 2007 10:24:55 -0400
Received: from smtp1.extremenetworks.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVT9C-00009Q-Kb for ram@iab.org; Wed, 12 Sep 2007 10:24:55 -0400
Received: from [] (unknown []) by smtp1.extremenetworks.com (Postfix) with ESMTP id A91757947 for <ram@iab.org>; Wed, 12 Sep 2007 07:24:53 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: ram@iab.org
From: RJ Atkinson <rja@extremenetworks.com>
Date: Wed, 12 Sep 2007 10:24:52 -0400
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Subject: [RAM] Tunnelling & GigE jumbo frame size
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

Dino's notes all sound correct, with one exception.

The exception is a detail and does not alter his main point,
which is that by using Jumbo Ethernet, tunnelling
of 1518 byte Ethernet frames ought not create any
fragmentation issues.  However, just to be crystal clear
to anyone who isn't tracking Ethernet closely, here
is the summary analysis.

	Just as "4K" MTU really means 4470 bytes, Jumbo Ethernet
	sizes of "9K" really mean an IP MTU of 9180 bytes.  This
	means the link MTU for Jumbo Ethernet is really:
            (9180 + sizeof(Ethernet header) + sizeof(VLAN tag))

	Implementers who want to be more widely deployable will
	have a "9K" link MTU that allows for at least 2 VLAN tags
	(considering the widespread use of Q-in-Q encapsulation)
	or 1 VLAN tag plus 2 Ethernet MAC headers (for MAC-in-MAC
	encapsulation).   Both Q-in-Q and MAC-in-MAC encapsulations
	are commonly used in Metro Service Provider deployments
	of Ethernet (e.g. in Japan, Korea, Sweden, and in the US).

	The Jumbo Ethernet 9K frame size was demanded by Ethernet
	users who were transitioning away from ATM/AAL5.  So they
	wanted Jumbo Ethernet to support existing IP packet lengths
	for IP/ATM AAL5 [see RFC-1626] *without* any risk of IP

	Jumbo Ethernet is explicitly not conformant to IEEE 802.3
	standards.  So all implementations that I'm aware of have
	a default MTU (i.e. out of the box) that is IEEE 802.3
	compliant.  Normally, users must explicitly configure the
	larger MTU size on each interface before it is enabled.

	1 GigE standards permit deployment with CSMA/CD, although
	I am not personally aware of any such deployments.  A GigE
	CSMA/CD deployment is likely not to work properly with
	an Ethernet frame size above that permitted by IEEE 802.3
	standards.  Switched Ethernet should be fine, however,
	and all actual 1 GigE deployments that I am aware of are
	switched and do not use CSMA/CD.



RAM mailing list