Date: Fri, 7 Jun 1996 12:40:47 -0700 (PDT) To: Jo Ann Larson From: jfw@fore.com (John Wakerly) Subject: Re: 802.1p/D3 Ballot >SUBJECT: P802.1p/D3 - Traffic Class and Dynamic Multicast Filtering > Services in Bridged LANs > >__X__ I disapprove for the following reasons. > > > _______ John Wakerly ______ -------------------------------------------------------------------- TECHNICAL COMMENTS -------------------------------------------------------------------- Comment 1: As per discussions in the June Interim meeting, it is inadvisable to allow registration of priority for individual addresses, and registration of such addresses for the main purpose of 802.1p (multicast pruning) would serve no purpose. Therefore, references to registration of individual (unicast) addresses should be deleted, except for additions to the text to specifically limit the use of registration to multicast addresses only. In my reading of the text, I found the following references to unicast addresses; there may be others (in particular, I read very little of Clause 9 due to printing problems with the postscript file). p. 10. Delete parentetical remark on lines 12-13 and change two instances of "MAC address" to "group MAC address". p. 12 line 26. Delete "individual and" There are many places in the descriptions of service primitives where the "MAC_ADDRESS" or "MAC_ADDRESSES" parameter could/should be replaced with a "GROUP_MAC_ADDRESS" or "GROUP_MAC_ADDRESSES" parameter and corresponding restrictive text. There may be other editorial ways to achieve the objective of limiting group registration services to group addresses. I believe this is a matter for editorial discussion and/or fiat. p. 27 lines 53-54. Delete "individual addresses,". Also, this looks like a good place to specifically prohibit unicast addresses. p. 28 lines 50-52. Delete (c), since Dynamic Filtering Entries can exist only for individual addresses, and group Registration can be performed only for group addresses. p. 28 line 53. Bullet (d) not needed? (since multicast source addresses are never learned) p. 85 Sec F.2. Delete. If individual-address registration is retained, insert strong warning that no standard exists for allocating multiple unicast addresses to a station. p. 87 Sec G.1.1. Restrict (a) to traffic directed to group addresses. Possibly add a non-goal of expedited data transmission of traffic directed to individual addresses. p. 87 Sec G.1.2. Add a non-goal of "Provision of an allocation mechanism for group addresses." If individual-address registration is retained, add a non-goal of "Provision of an allocation mechanism for multiple individual addresses associated with a single station." p. 103 Comment 6, p 118 Issue 2. Finally resolved. "GARP" lives! p. 119 Issue 14. Resolved. -------------------------------------------------------------------- Comment 2: p. 15 Sec 2.6.9.1 and 2.6.9.2. What happens when the user-priority specified by an ES_REGISTER_GROUP_MEMBER command is inconsistent with that specified by a previously issued set by an ES_REGISTER_GROUP command or vice versa? Maybe it's specified somewhere (in GARP?), but I couldn't find it. -------------------------------------------------------------------- Comment 3: p. 15 Sec 2.6.9.1. I read or heard somewhere that registering a group member implicitly registers the group, but I couldn't find it here. -------------------------------------------------------------------- Comment 4: p. 16 Sec 2.6.9.4 The default-default filtering mode and submode, that is, the mode if a MANAGER_DEFINE_DEFAULT_FILTERING_MODE command was never received, is apparently as specified in Sec. 2.6.6 (p. 14 lines 7 and 16). It would be desirable to specify the default-default here in Sec 2.6.9.4; otherwise one has to hunt. p. 17 Sec 2.6.9.5 The default-default value for each of the parameters, as far as I can tell, is not specified anywhere. This needs to be pinned down here, or the reader needs to be alerted that the default-default value is an implementation choice. -------------------------------------------------------------------- Comment 5: p. 17 lines 17-19. Not clear whether Forward with Inbound Priority, as a per-Port value, is configured with respect to the receiving Port or the transmitting Port. I thinks it's the receiving Port. In line 18, "FALSE" --> "FALSE on a receiving [transmitting?] Port" -------------------------------------------------------------------- Comment 6: p. 18 Sec 2.6.9.6. Does 802.1 have well-defined semantics for associating well-defined (unsigned???) numerical values with address patterns? Where do the U/L and I/G bits fit in these semantics, especially given their position in a "canonical" address? The use of "backwards" address ranges to signify exclusion of an address range is clever but hokey. Why not just an include/exclude parameter? Does issuing a second MANAGER_DEFINE_REGISTRATION_RANGE command nullify or add to the effects of a previous command? If the latter, what number of ranges must be supported? -------------------------------------------------------------------- Comment 7: p. 22 line 16. I did not see a service primitive anywhere to set Outbound User Priority. Is this described in other 802 standards? If so, a ref would be helpful; if missing, it must be added! p. 22 line 16. Outbound Access Priority. Same comment. -------------------------------------------------------------------- Comment 8: p. 23 lines 9-36. Should we specifically prohibit removing frames from lower-priority queues in order to accommodate more frames in higher-priority queues, or should we remain silent on this and other queueing tweaks? -------------------------------------------------------------------- Comment 9: p. 32 Sec 6.6.3.4.3. I assume that the output parameter is the NEW value (the one just set), please clarify. In any case, I suggest providing both the OLD and the NEW values of the value as outputs, so you can tell if you changed the value. p. 33 Sec 6.6.4.4.3. ditto for all output parameters. -------------------------------------------------------------------- Comment 10: p. 33 Sec 6.6.4.3.2 line 9. The Port-number parameter appears to be unnecessary. -------------------------------------------------------------------- Comment 11: p. 34 Sec 6.6.5.2. Is this remapping capability required or optional? I think it should be optional. In any case, our decision (required or optional) should be stated in this section or else in some other appropriate place. -------------------------------------------------------------------- Comment 12: p. 35 line 12. Reporting the number of Group Registration Entries should be REQUIRED if the Filtering Database supports such entries. -------------------------------------------------------------------- Comment 13: EDITORIAL SUGGESTIONS (to remove ambiguities, etc.) p. 14 line 18. "the corresponding addesses" --> "frames with the corresponding destination addesses" p. 14 line 22. "(individual and) group MAC addesses" --> "frames with (individual and) group MAC destination addesses" p. 14 line 46. "invoked" --> "invoked for a given unicast MAC address". "MAC frame" --> "MAC frame having that address as its source address" p. 22 line 19. "provided," --> "or if management has not set this parameter for a particular port," ? p. 25 line 23. If unicast registration capability is retained, delete "multicast". p. 26 line 20. "shall contain" --> "be capable of containing" ? p. 42 line 48.5. Garbled. p. 43 line 5. Insert at beginning, "for each Group," p. 81 line 26.5. "to switch" --> "switches" ? (parsing difficulty) p. 90 line 1. "it's" --> "its" (just had to nit on that one!)