Date: Thu, 16 Nov 1995 08:47:18 -0500
From: Paul Langille <langille@nexen.com>
To: p8021@nic.hep.net
Subject: Partitioning of VLAN Tasks


	Greetings. I heard, many times over the course of the Montreal
meeting, that no one was offering any contributions on VLANs. There
are probably many reasons for this. I believe one reason is that the
VLAN problem is just too big for one person to embrace. No one has the
spare time needed for this commitment. Another reason is that it is
hard for one person to lead a group this size to consensus. So what
can we do? Well, rather than dwell on the reasons, I propose we do the
following. Divide the problem into smaller (somewhat) manageable
pieces. Put together small study groups, made up of 2-5 individuals,
to work separately, in parallel, on the smaller pieces. This work
would probably be done via Email or phone conversations. These small
study groups would then present at the January interim meeting (or
before via the mail exploder). Breaking up into smaller groups will
reduce the duplication of effort and help move some of the foundation
work forward. I feel this is important since there is not a lot of
time between now and the January interim meeting.

	This concept is basically the same thing we did in Denver. I
am merely proposing we continue to do this off line in a more
streamline fashion. I also don't feel that individuals are required to
`join' one of the study groups. Actually it would probably be better
if the groups were kept small so there could be consensus within the
study group. (Remember all the information gets presented in
January.)

	Here are my `current thoughts' on how to partition the various
VLAN tasks. Have a look and let me know what you think. (Do we need
more groups? Is the whole idea junk? etc.)


Partitioning of VLAN Tasks:  

1) VLAN methodologies or mechanisms - Generate a complete list of VLAN
methodologies (port based, MAC based etc.). Include any definition of
terms needed for clarification. (Most of this is a consolidation of
information from previous meetings.) Include pros and cons in this
list. If possible list requirements and features.

2) Tagging architecture - Generate a complete definition of terms. Some
of this was done in Denver and Montreal so this information just needs
to be consolidated into a single document. Continue the definitions to
include the types of tagging. Make this a complete list and (attempt
to) list pros and cons. This could be expanded to include a list
requirements and features. The next step is to take a network view of
tagging (translations etc.).

3) Spanning tree - List requirements, features and definition of
terms. Investigate all configurations (single, multiple,
overlapped). List pros and cons of each. It is important when
investigating the pros and cons to note the level of complexity and
any related problems.

4) VLAN Management - define membership, auto-configuration, (adds, moves
and changes).


	Keep in mind that I still feel that we need to follow Mick's
suggestion and develop the user view paradigm. (Maybe this could be
another study group.) I did not include it because the user view is
more of a horizontal view and I am proposing vertical ones.

	I feel the way to proceed is to first agree on the
partitioning and then look for volunteers for each of the
groups. Remember that most of the work done by the study groups
between now and the interim meeting will probably be to consolidate
what has been done so far. I believe there is a lot of `stuff' that we
agree on but it is not formally documented. At least getting this done
is a good first step. Another key thing to note is that this
partitioning is not meant to imply `acceptance' into a VLAN
standard. For example, we may (as a group) decide not to include
multiple spanning trees or tagging in the standard. Let's gather the
information and then make the decision.

		Paul Langille
		Ascom Nexion
		langille@nexen.com