RE: Some Comments on: draft-kaplan-isis-ext-eth-02.txt
Jim,
You state that the topic has never been brought forward in 802.3. This is
not exactly correct. There was a presentation from SGI to an interim of the
802.3z task force proposing an increase to the frame size. There was
discussion on the presentation though I don't recall any vote being taken.
Your response points out the difficulty with legacy equipment, but there is
also a significant problem of compatability with the standard. It is
relatively easy to design a bridge or a NIC for a larger frame size, but
this is not the case for repeaters.
Repeaters have an elasticity buffer to adapt for difference between the
repeater's clock and the received data rate. To meet round trip delay and
inerpacket gap shrinkage requirements, the delay from start of receive to
start of transmit is tightly spec'ed. Also, the maximum number of bits added
to the received preamble is tightly spec'ed because this number also impacts
IPG shrinkage. It is not possible to comply with these two specs and buffer
enough bits to accomodate the difference in data rate between a repeater
running at the slowest allowed data rate and a source running at the fastest
allowed data rate if the packet size is increased to something over 3 K.
Therefore, jumbo frames are inherently incompatible with 802.3 compliant
repeaters.
The RFC provides no hint of the limitations of jumbo frames.
Regards,
Pat
-----Original Message-----
From: Jim Carlo [mailto:jcarlo@ti.com]
Sent: Thursday, August 17, 2000 11:38 AM
To: IEEE802
Subject: Some Comments on: draft-kaplan-isis-ext-eth-02.txt
I will send the following to Scott at the end of this week.
+++++++++++++++++++++++
Scott, it has been difficult to get a consensus response from IEEE 802 on
this work, since many people are on vacation, and this is a contentious
issue, although most responses I have received from individuals to-date have
been negative. The two key people, organizationally, would be Tony Jeffree
(chair of 802.1) and Geoff Thompson (chair of 802.3). I ask Geoff and Tony
to further submit comments to Scott if they feel warranted.
I would like to invite the proponents of this RFC (regardless of what
decision IETF takes) to the November IEEE 802 plenary meeting and give a
tutorial on this topic and participate in 802.1. This will serve to
disseminate this information into IEEE 802 so that appropriate projects,
actions or non-actions can be taken.
Summarizing various individual comments and notes on this topic:
1) The choice of frame size for Ethernet packets is really the domain of
802.3 (CSMA/CD) and 802.1 (Bridging, VLANs). The last time the frame size
was modified to increase by four bytes due to VLANs, 802.1 initiated this
work and 802.3 also modified the Ethernet standard to include these extra
bytes. The people with the experience dealing with this sort of thing attend
IEEE 802. It's easy to define a new ethertype, but it's not too easy to
figure out what happens when these frames get (sometimes) forwarded by
bridges. I would expect discussions of this type to take place in 802.1.
2) This issue has come up several times in 802.3. It has significant
problems in terms of compatibility with the installed base. This topic has
been discussed in the back halls of 802.3, but not brought forward. The
problem is that it is very easy to do in the standard and hard to do in the
world. It is just like changing the gauge on railroad tracks. All you have
to do is change one line in the standard, never mind all of the rails you
have to move. For this project to be done in 802.3, there would need to be a
consensus, and this may be difficult. This draft is just meant for carrying
IS-IS routing protocol frames (the IS-IS working group is the intended
sponsor of this draft) yet this appears to be a way to get the fox into the
chicken coop. Those vendors supporting the larger frame will support this,
those vendors not supporting the larger frame will not support this.
3) One suggestion is a Recommended Practice, along the lines of 802.1H,
dealing with protocol encoding of Ethernet Type II frames over arbitrary
length media.
4) Most of the gear produced today would be intolerant of greatly longer
frames. There is no way proposed to distinguish between frame types in the
network. Bridges and repeaters would drop or truncate (and cause errors
doing so) frames right and left for uncharacterized reasons. It would be a
mess. It's all okay for small carefully characterized networks. It would be
very difficult to do across the standard.
Jim Carlo(jcarlo@ti.com) Cellular:1-214-693-1776 Voice&Fax:1-214-853-5274
TI Fellow, Networking Standards at Texas Instruments
Chair, ISO/IEC JTC1/SC6 Telecom and Info Exchange Between Systems
Chair, IEEE802 LAN/MAN Standards Committee
>-----Original Message-----
>From: Scott Bradner [mailto:sob@harvard.edu]
>Sent: Saturday, August 12, 2000 3:47 PM
>To: jcarlo@ti.com
>Subject: draft-kaplan-isis-ext-eth-02.txt
>
>
>
>Jim,
> What is the status of teh IEEE looking at
>draft-kaplan-isis-ext-eth-02.txt? The IESG has bene asked to publish
>the Internet draft as an Informational RFC. If the IEEE has
>comments the IESG needs to get them in the next week or so (we have a
>teleconference on 8/24 during which we will authorize publication
>unless the IEEE gives us reason not to.
>
>Scott