IEEE 802.1 Interim Meeting
Summary of Tagging-Format Subgroup Discussions of 1/24/96
(Presented on 1/25/96 by John Wakerly, Alantec Corp.)

The goal of this one-hour discussion was to raise questions and
issues related to tag format in explicitly tagged VLAN frames

The following points were raised.  Conclusions are indicated in
cases where there appeared to be strong consensus.

 o  MTU limitations -- two aspects
    1.  "Small increase/violation" from adding tag
    2.  "Large increase/violation" from encapsulating 802.5/FDDI frames

 o  Designation of "VLAN type" within a tag -- should it use ethertype
    or 802.2 LLC?
    -- 802.2 LLC ==> max tagged frame = 1537 bytes (XNS ethertype = 600h)
    -- 802.3 full-duplex group will attempt to legitimatize ethertype
       at next plenary -- we should support (and use?)

 o  Nested tagging (multiple tags) -- strong sentiment to forbid

 o  Should a single MAC SAP be able to appear in multiple VLANs?  Yes!

 o  Should a single frame's VLAN tag be able to indicate membership in
    multiple VLANs?  Thorny question.

 o  32-bit alignment of untagged payload within a tagged frame
    is a good goal, but secondary if it would mean sacrificing
    maximum tag length due to MTU limits.

 o  Need to balance extensibility of tag information (spare fields,
    etc.) vs. overall tag length.

 o  Need to balance extensibility of tag information vs. silicon
    complexity and stability.

 o  What is the overall overhead / efficiency for tagged frames?
    At 1500, 576, 64, or even 20 bytes?  (Bandwidth is not free.)

 o  Fixed- or variable-length tags?  Strong sentiment for fixed length.

 o  Perhaps tags need a version bit or other escape to a larger or
    different tag format.

 o  Should tag have QoS / Priority field?
    -- QoS etc. not part of our goals
    -- But priority is present in 802.12 and 802.5 which may be
       encapsulated in a VLAN

 o  Source-route fields within the tag?  Uh, ummm, maybe an SRT flag
    to give an escape for source routing?

 o  Extended features -- hop count, etc. -- No

 o  Should the tag provide an escape for longer frames for full-duplex,
    higher speed networks, etc.?

 o  802.10 compatibility?  two aspects:
    1.  Format -- adopt it?
    2.  Security -- needed in VLAN tag?

 o  Servers -- do they need to efficiently generate and understand
    taggged frames?

 o  How important, really, is it for a tagged frame to preserve the
    integrity of the original CRC?

 o  Is a "one-size fits all" approach too expensive for low-end
    switches?

 o  Should a "simple" solution (which may be disjoint from a later
    solution) be standardized?  (E.g., is it really necessary to have
    address fields in the tag?)