[RAM] Tunnelling & GigE jumbo frame size

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.

Correction:
	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).

History:
	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
	fragmentation.

Caveats:
	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.

Yours,

Ran
rja@extremenetworks.com

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram