Date: Sun, 09 Jun 96 16:56:59 IST From: "Gideon Prat" To: P8021@HEPNRC.HEP.NET, jlarson@fnal.gov, gideon@ilccm1.iil.intel.com, yavatkar@ibeam.jf.intel.com Subject: Re: 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. _____Gideon Prat________ (Name) ---------------------------------------------------------------- Commments: reason for disapproval - Comment #1 - as many others, the Unicast Registration issue. (see other's comments on this) Comment #2 - I beleive that the standard should not RECOMMEND the use of two priorities. I beleive that useful numbers could be 2,3,4... and 8 since it is part of previous standards. The /D3 text, section 3.7.4, page 22 line 52-53 and page 23 should allow 2,4 or 8 priorities (to keep it binary). Table 3-2 would show the following recommended mapping: +----------+-------+-------+-------+ | User | 2 | 4 | 8 | | Priority | levels| levels| levels| +----------+-------+-------+-------+ | 0-1 | 0 | 0 | | | 2-3 | 0 | 1 | equal | | 4-5 | 1 | 2 | to | | 6-7 | 1 | 3 | Prior | +----------+-------+-------+-------+ Comment #3 - I am not absolutely sure how to do this, but I feel that there should be a way to alter the order presented by 3.7.3, page 22 lines 5-15. While in some cases, in make sense to have the pre-configured, filtering database user priority override the incoming priority, in other cases it may make sense to do the inverse. e.g: - RSVP uses the same addresses for control and data. - Layered Video flows that use the same MC address for their different streams (I beleive they don't as of yet) In short, when the simplistic by-address priority in the filtering database should be modulated by more relevant in-packet priority info. Any simple ideas how to do this and keep it simple? Thx Gideon