To: p8021@nic.hep.net
Subject: VLAN progress, tagging, SDE etc. - just HOLD IT please
Date: Wed, 22 Nov 1995 17:48:28 -0800
From: Mick Seaman <mjs@NSD.3Com.COM>


At the last and the Denver interim meeting we made considerable
progress towards everyone understanding and respecting the
requirements and desires of others in the group.

We can lose this understanding and respect pretty quickly if any
faction tries to end run the process. Standards wars are not pretty,
and by the way they take forever. Let's not do this to ourselves
please. If anyone thinks this is a quick way to get what they want
they haven't looked at the history of 802.

Here is where I believe we are, in terms of consensus.

   1. There will be different devices and techniques (tagging,
      address based or "implicit", port based, possibly port switched,
      ...)

   2. We respect the fact that for a variety of economic benefits,
      real or perceived, that we will need to address this variety -
      certainly it will make it a lot easier to get a standard that
      consistently gets enough support not to be derailed.

   3. It is a good goal to have the techniques play together in terms
      of delivering the whole VLAN picture. Some of us feel (as per
      Keith's presentation in Montreal) that this is actually
      achievable. Certainly if we can do it it well help us to make
      progress together.

   4. We do not all agree as to the merits of tagging or encapsulation
      versus implicit schemes, and certainly do not agree on what
      the relative scaling limits are.

We can go forward from here by figuring out:

   A. What information we need to share or framework we need to define
      to make any or all of the interoperable. Some of this is needed
      within techniques of like type (does VLAN 39 mean the same to
      everyone).

   B. How this information can get carried around, stuck on the front
      of frames or not.

   C. For each technique what the scaling limits are (using B above),
      what topologies are supported by each different way of
      doing things and what the side effects (good or bad are).

   D. What the requirements on the protocols are, for control, for
      tagging etc., including considerations of high speed processing.

   E. And finally what the packet formats are.

I'll guarantee that starting with E and just getting in each others
faces and asserting that X is better than Y without looking at
the engineering considerations behind each of the ideas will not get
us any place fast. If this was all completely obvious we wouldn't be
disagreeing in the first place. Righteous conviction on anyone's part
never made good engineering.

For anyone who is naive enough to think that defining packet formats
is a good way to design a protocol I would refer them to the whole
mucky history behind 802.1H and the Ethernet and Appletalk across FDDI
problem. May be we will end up with something that has a 32 bit VLAN
ID field, may be 802.10 is the very best frame format for this - at
least we'll have a good idea what the fields mean and we won't have
left anything out.

If we just go through this from the top and get our assumptions and
data shared without trying to cheat the process we'll all get where we
are going a lot quicker.


Mick