Date: Mon, 10 Jun 1996 22:03:48 -0500 From: lidinsky@hep.net (Bill Lidinsky) To: 100271.522@compuserve.com, p8021@hepnet.hep.net Subject: 802.1p/D3 Ballot SUBJECT: P802.1p/D3 - Traffic Class and Dynamic Multicast Filtering Services in Bridged LANs __XX_ I disapprove for the following reasons. William P. Lidinsky ---------------------------------------------------------------------- COMMENTS FOR 802.1P/D3 BALLOT FROM BILL LIDINSKY, 9 JUNE 1996 Below are a few items that I feel need considering in the next version of 802.1p. They are sufficient to cause me to vote "no". General Comments ---------------- The 802.1p/D3 document is, in many places incomplete. This represents a document that is not yet near completion. Consequently useful comments can be made either the more complete sections or at a high level on overall approaches. High Level General Comments --------------------------- As discussed at the Wakefield meeting, there are relationships between 802.1p and 802.1Q. Presently these relationships are sometimes not in concert. It is and will be hard to consider 802.1p without considering 802.1Q. For instance, in 802.1Q discussions tags are explicit while in 802.1p/D3 tags are implicit. A single approach to tagging should be considered. Alternately if the implicit/explicit arrangement prevails, both p and Q need to deal with their mutual interoperability. There seems to be strong argument for U/L source address bit being the only workable priority scheme. Unicast address registration should probably be deleted since unicast registration has serious problems in terms of scaling and compatibility with higher layer protocols per Norm Finn at Wakefield. After thinking about it, I agree with Norm Finn on this. It is important to get the GARP part of 802.1p out as fast as possible. Other parts of 802.1p might be better merged with 802.1Q or visa versa. Page 9 ------ This Overview, while properly discussion 802.1D and 802.1d, makes no mention of 802.1Q. It became clear at the Wakefield interim 802.1 meeting that relations exist between 802.1p and 802.1Q. These relationships need to be determined and refered to both in the Overview and elsewhere as necessary. page 22, Sec. 3.7.4, lines 39-42 and 52-53: ------------------------------------------ In lies 39-42 8 traffic classes are "supported", while in lines 52-53 2 traffic classes are "recommended". This is very confusing. I suggest that in this unusual case, one size should fit all.