Subject: [Isis-wg] forwarded message from [email-masked]

From: Tony Li <[email-masked]>
Date: Thu, 5 Jul 2001 10:39:13 -0700

Folks,

Please note the revised ID on Extended Frame Support.

Could we please get comments by 5:00PM PDT July 13?  Again the proposal is
to ask to have this published as an Informational RFC.

Thanks,
Tony

Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ext-eth-01.txt
From: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Date: Thu, 05 Jul 2001 06:52:33 -0400
List-Id: <isis-wg-external.mailist.procket.com>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

	Title		: Extended Ethernet Frame Size Support
	Author(s)	: J. Kaplan et al.
	Filename	: draft-ietf-isis-ext-eth-01.txt
	Pages		: 
	Date		: 03-Jul-01
	
This document presents an extension to current Ethernet Frame 
specifications for hardware and frame format to support payloads 
greater than 1500 Bytes for Type interpretation and Length 
interpretation frames. This is useful for Gigabit Ethernet
technology, providing a means to carry large MTU packets without
fragmentation over a high-speed broadcast network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-eth-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-isis-ext-eth-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-isis-ext-eth-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 05 Jul 2001 16:14:14 -0400

All,

	Proposed new revised text for Section 7 is below.  This does
not change the basic conclusion, though it does add some additional
text describing the current deployed reality.  Specifically the
revised text does attempt to discourage the use of any MTU other
than 1518, 4470, or 9180/9200.

	If this change is accepted, the rest of the document is
fine with me.

Ran
[email-masked]

=================================================================
7. Default MTU

        The motivation for this draft was support of FDDI frames
        across the end-to-end Internet without intermediate fragmentation.

	 According to RFC-1188, the IP MTU over FDDI is 4352 bytes,
        which is roughly 4470 bytes after including standard framing.
        RFC-1188 notes that the FDDI frame size as specified by
        ANSI is actually 4500 bytes, not 4470 bytes.  Deployed IP/FDDI 
        implementations are known to have adhered to RFC-1188.

        Supporting MPLS over Ethernet without fragmentation 
	 requires 4 or 8 additional bytes beyond Ethernet MTU.

	 Supporting Ethernet-layer precedence ("IEEE 802.1p") or
        Ethernet Virtual LANs ("IEEE 802.1q") require a few bytes
        beyond the normal Ethernet MTU of 1518 bytes.

        Many, but not all, deployed servers with Gigabit Ethernet
        support an IP MTU of 9180.  Server throughput is generally
        related closely to the per-packet processing costs,
        rather than the per-byte processing costs.  So many servers
        have much better throughput with a larger MTU size.  Many, 
        but not all, deployed Gigabit Ethernet switch/router products 
        support an Ethernet MTU of 9200 bytes today.  An IP MTU
        of 9180 bytes is equivalent to an Ethernet MTU of 9200 bytes,
        considering Ethernet-layer framing overhead, etc.

	 Additionally, RFC-1209 specifies an IP MTU of 9180 bytes over
	 SMDS.  RFC-1626 specifies an IP MTU of 9180 for IP over
        ATM AAL5.  Some equipment providers claim significant cost 
        to support the 9180 IP MTU, while other equipment providers 
        claim that there is no significant change in cost to support 
        9180 versus 4470 as the IP MTU.  Some, but not all, deployed 
        very large backbone routers have support for the 9180 IP MTU 
        over Gigabit Ethernet.

	 A majority of currently deployed PPP over SONET interfaces 
        support a default IP MTU of 4470 bytes.  This 4470 MTU is 
        believed to be nearly universal in deployed POS links today, 
        though the POS MTU is theoretically configurable.

        An MTU of 4470 bytes for IS-IS PDUs over Gigabit Ethernet
        is recommended when the larger MTU value of 9180 is not needed,
        because use of the widespread POS MTU (i.e. 4470) greatly reduces 
        the chance of intermediate fragmentation across the end-to-end 
        Internet.  If an Ethernet MTU larger than 4470 bytes is needed, 
        then an Ethernet MTU of 9200 bytes is recommended.  Use of any 
        Ethernet MTU other than 1518, 4470, or 9200 bytes is specifically
        discouraged in order to avoid increasing MTU entropy.  

        Varying MTU sizes across the end-to-end Internet path can cause 
        packet loss as part of normal operation of Path MTU Discovery 
        or can cause intermediate fragmentation of IPv4 datagrams.  
        Intermediate fragmentation of IPv4 datagrams is widely believed 
        to be very undesirable.  Early implementations of Path MTU
        Discovery did not always work well.  At present, there are 
        mixed reports about the quality of deployed PMTU Discovery 
        implementations.
============================================================================

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Henk Smit <[email-masked]>
Date: Thu, 5 Jul 2001 14:05:43 -0700 (PDT)

> text describing the current deployed reality.

  Just curious, how many ISIS implementations are out there today that
 send IIHs larger than 1500 bytes over GigE ? Zero ? One ? Two ? More
 than two ?

     henk.

---

From: Tony Li <[email-masked]>
Date: Thu, 5 Jul 2001 15:45:22 -0700

Some comments on Ran's proposal.

 | 7. Default MTU
 | 
 |         The motivation for this draft was support of FDDI frames
 |         across the end-to-end Internet without intermediate fragmentation.

More accurately: the MTU of much of the deployed core of the Internet was
(and is) >= 4000 bytes.

 | 	 According to RFC-1188, the IP MTU over FDDI is 4352 bytes,
 |         which is roughly 4470 bytes after including standard framing.
 |         RFC-1188 notes that the FDDI frame size as specified by
 |         ANSI is actually 4500 bytes, not 4470 bytes.  Deployed IP/FDDI 
 |         implementations are known to have adhered to RFC-1188.

Very early FDDI implementations used an MTU of 4470 bytes.  This was then
propagated into early POS implementations.  Somewhere in between RFC 1188
dropped the FDDI MTU to 4352.  I'm unaware of any implementations that
followed suit.

 |         Supporting MPLS over Ethernet without fragmentation 
 | 	 requires 4 or 8 additional bytes beyond Ethernet MTU.

More generally: Support for one level of of MPLS label will require 4 bytes
of link layer frame above the IP MTU.  Similarly two labels will require 8
bytes.

 | 	 Supporting Ethernet-layer precedence ("IEEE 802.1p") or
 |         Ethernet Virtual LANs ("IEEE 802.1q") require a few bytes
 |         beyond the normal Ethernet MTU of 1518 bytes.

I think many people will find "normal Ethernet MTU" and "1518 bytes"
confusing.

 |         Many, but not all, deployed servers with Gigabit Ethernet
 |         support an IP MTU of 9180.  Server throughput is generally
 |         related closely to the per-packet processing costs,
 |         rather than the per-byte processing costs.  So many servers
 |         have much better throughput with a larger MTU size.  Many, 
 |         but not all, deployed Gigabit Ethernet switch/router products 
 |         support an Ethernet MTU of 9200 bytes today.  An IP MTU
 |         of 9180 bytes is equivalent to an Ethernet MTU of 9200 bytes,
 |         considering Ethernet-layer framing overhead, etc.

Specifically, that allows for 20 bytes outside of the IP packet.  Certain
amounts of overhead are necessary:

	DA (6 bytes)
	SA (6 bytes)
	Type (2 bytes)
	CRC (4 bytes)

This would leave 2 bytes for optional additions.  Unfortunately, the common
options that I can think of are:

	VLAN tag (4 bytes)
	MPLS label (4 bytes)
	MPLS 2 labels (8 bytes)

It appears as if an IP MTU of 9180 is still too large.

 | 	 Additionally, RFC-1209 specifies an IP MTU of 9180 bytes over
 | 	 SMDS.  

I believe that the SMDS experiment is conclucded.  ;-)

 |         RFC-1626 specifies an IP MTU of 9180 for IP over
 |         ATM AAL5.  Some equipment providers claim significant cost 
 |         to support the 9180 IP MTU, while other equipment providers 
 |         claim that there is no significant change in cost to support 
 |         9180 versus 4470 as the IP MTU.  Some, but not all, deployed 
 |         very large backbone routers have support for the 9180 IP MTU 
 |         over Gigabit Ethernet.
 | 
 | 	 A majority of currently deployed PPP over SONET interfaces 
 |         support a default IP MTU of 4470 bytes.  This 4470 MTU is 
 |         believed to be nearly universal in deployed POS links today, 
 |         though the POS MTU is theoretically configurable.
 | 
 |         An MTU of 4470 bytes for IS-IS PDUs over Gigabit Ethernet
 |         is recommended when the larger MTU value of 9180 is not needed,
 |         because use of the widespread POS MTU (i.e. 4470) greatly reduces 
 |         the chance of intermediate fragmentation across the end-to-end 
 |         Internet.  If an Ethernet MTU larger than 4470 bytes is needed, 
 |         then an Ethernet MTU of 9200 bytes is recommended.  Use of any 
 |         Ethernet MTU other than 1518, 4470, or 9200 bytes is specifically
 |         discouraged in order to avoid increasing MTU entropy.  

I would add one more line in here: The default IP MTU for Gigabit Ethernet
should be 4470 bytes.

While I appreciate the additional discussion, we must not appear to be
ambiguous.

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 05 Jul 2001 20:34:33 -0400

>More accurately: the MTU of much of the deployed core of the Internet was

        Please take that level of re-write up with the original
authors.  I didn't want to edit their assertion of motivation
that severely. 

>dropped the FDDI MTU to 4352.  I'm unaware of any implementations that

        I'd be interested in Dave Katz's inputs since he wrote that
RFC and was involved in the earliest implementations.

        When you say "MTU", do you mean link MTU or IP MTU ?
If you mean link MTU, that's consistent with what I've said above.
The as-deployed-for-IP link MTU was 4470 not 4500 bytes, according
to RFC-1188.

>of link layer frame above the IP MTU.  Similarly two labels will require 8

        No objection.  The quoted text came from the original draft.

>I think many people will find "normal Ethernet MTU" and "1518 bytes"

        A specific edit proposal would be helpful.

>It appears as if an IP MTU of 9180 is still too large.

        Actually, you've just constructed a case that 9220 is too small
when one or more of those options are present.  The 9180 number
is actually deployed pretty widely (e.g. in servers, switches,
routers), hence is hard to change at this point.

ASIDE:
        If you do the same math, by the way, for IP over IEEE standard
Ethernet, you'll discover that IEEE has 2 link MTUs for standard
Ethernet (the original one & an IEEE jumbo frame which increases
the max Ethernet frame size by 4 bytes -- for a single VLAN tag).

>I believe that the SMDS experiment is conclucded.  ;-)

        It is relevant in the same manner that FDDI is relevant,
to provide historical context.  FDDI is basically gone also
at this point.  I don't even think FDDI chipsets are in active
production any longer, for example.  (This caused some panic
in parts of the US Navy, whose ships have been using FDDI for 
many years now as their shipboard backbone).

>While I appreciate the additional discussion, we must not appear to be

        That is OK, we will have a whole draft on IP/GigE elsewhere. :-)

        How IP is encapsulated over anything is WAY outside the charter 
of this WG, whereas how IS-IS is carried anywhere is reasonably
within charter for this WG.
  
        If you feel compelled to put IP in here specifically, it ought 
to be phrased as it was by the original authors for IS-IS:

        An MTU of 4470 bytes for IP packets or IS-IS PDUs 
        over Gigabit Ethernet is recommended when the 
        larger MTU of 9180 is not needed. [remaining text
        roughly as proposed earlier]

Cheers,

Ran
[email-masked]