To: jlarson , P8021 Subject: 802.1p/D3 Ballot Date: Mon, 10 Jun 1996 17:45:53 -0700 From: Mick Seaman SUBJECT: P802.1p/D3 - Traffic Class and Dynamic Multicast Filtering Services in Bridged LANs __X___ I abstain for the following reasons: __X___ Lack of Time _______Mick Seaman______ ---------------------------------------------------------------------- 1. General: Use of "Services" We have not yet found the right language to refer to the idea that a user may manage a service which he is using. This is not a problem confined to this standard. I would not advocate its solution by sprinkling the words "management" and "management primitives" through the text. However the distinction between the MAC Service provided and the services (or really controls) available to the user so that the user can change the way the service is supported is getting blurred. I suggest a few places where text might be changed in more detail comments below. And, in the absence of a better phrase suggest that we use "controls" when we are referring to the primitive actions provided to the user to facilitate tweaking of MAC Service Support. 2. pg 9, l 18-20, 24, 26. E. b) needs relating to c) and e), at present it looks like a non-sequitur. Perhaps the right approach is to expand b) just enough so we know that the bridges do the filtering for traffic containment to particular LANs. Then c) and d) make sense. 3. pg 10, l 16, 17, mE. members do not exist on the Ports of a Bridge, they are "reached through the Ports of a Bridge". Stick to consistent terminology for these relationships. I think 1D is "reached through", otherwise establish consistent terminology. 4. pg 11, T. see General comment 1. Leave section 2 title as Support of the MAC Service. 5. pg 11, l 15, T. Replace " Support of .. to end stations" with "Provision of .. to end stations". A service is not supported to someone/something, it is provided to them. "Support" discusses the internal mechanisms used to provide the result. 6. pg 11, l 38, mE. Replace "Since not all MAC types are able to signal user priority" with "Since not all MAC types (<802.3>, <802.5>, , <802.12>) are able to signal the user priority associated with a frame". Rationale for first change - it is unclear from the context what a "MAC type" is here, add references in parantheses to provide examples. Rationale for second - this is specifically what is lacking, not any other agreement about signalling priority. 7. pg 12, ME. See General comment 1, above. I suggest retitling 2.6 "Filtering Controls in Bridged LANs" or "Controlling Filtering in Bridged LANs". This should largely avoid the need for the clarification on line 7. Replace "Filtering services" with "Filtering controls" throughout section 2. 8. pg 12, l 9, mE. Suggest "MAC Service User or an administrator .." 9. pg 14, l 24, mE. Since if one sub mode can be configured (on/off) by management action the other one can too, I was bemused by this statement. Now I see it. A is the default. All of course (?) can be configured by management action. Put this text either on line 14, or as a separate para after the description of the two submodes. 10. pg 14, l 14-24, E. Suggest you call the submodes 2A and 2B throughout. 11. pg 14, l 31 mE. Suggest "MAC Service User or an administrator .." 12. pg 15, l 10, mE. Who is the "may" for here, is this implementation freedom, or just something that can happen (use "can"). Is there any implied difference between a non-existent filter and one which permits all forwarding. 13. pg 15, l 22, T. Why "ADDRESSES" and not "ADDRESS", is there a benefit to specifying multiple addresses with a single primitive or is this not just a PDU packing issue. A problem I have with the generality introduced here is that it seems to suggest a one-to-many relationship between Groups and Group Addresses, and further that an additional "name" for a group is required. Somewhere we need to establish the one-to-one mapping between Groups and discussed in .1p and Group Addresses. Earlier than pg 15. 14. pg 15, l 34, mT. "may" or "can"?, at whose option? See also pg 16, l 1. 15. pg 16, l 48, T. Need to be clear whether the sub-mode affects behavior of frames going in thru a Port, or out, or between Ports (AND or OR modes to give filtering rule?). 16. pg 18, 2.6.9.6, MT. I'd like to se the need for these ranges discussed more. How many ranges? 17. pg 21, l 20, MT. It's time we had the C code, too much scope for confusion otherwise. 18. pg 23, l 50-52, T. This text pretends to be normative. It should either be promoted to full text, and the range of behavior explicitly permitted, or struck. 19. pg 24, l 6-11, mE. "either/or" is correct English usage for a choice of two, the choice of three here deamnds some other construct. (An old comment on 1D, not mine originally, but one I should represent). 20. pg 26, 3.9.3 Filtering Database Entry Types, ME. I was quite confused by this section. It would have helped a lot if the main outline of the section had been presented around line 14, before section 3.9.3.1. i.e.: there are Filtering Entries which are what are are currently in .1D, and these support Basic Filtering, and there are new Group Registration Entries which support new Extended Filtering, and these provide everything that the old entries did, plus the new stuff. 21. pg 27, l 49-51, T. At whose option? 22. pg 28, 3.9.4 Updating Filtering Database Entries, E. A state diagram might help a great deal here. I'm not sure I see what is going on. 23. pg 30, l 31, T. We should be operating timer settings in centiseconds, not seconds, to allow for fast reconfiguration in new environments. 24. pg 30, l 46, E, T. "Sub-mode" is a very inexpressive term. It would seem to be convenient if the configuration of the Bridge and Port Entities could be made orthogonal (for modelling of management at least). In this case we could have Bridge Filtering Mode and Port Filtering Mode. Of course Port Filtering Mode would have no effect when Bridge Filtering Mode was 1. Would this work throughout? 25. pg 33, 34, 6.6.5.1.3, 6.6.5.2.2. T. Listing the inputs and outputs of the traffic class tables in this way would seem to allow the end case of many priorities to dominate. It would also seem to have more flexibility than truly desired.The value would seem to be that the data structures called up are of fixed extent. An alternative would be to specify the highest priority assigned to Traffic Class 0, then (if required) the highest assigned to Traffic Class 1 etc. 26. pg 41, MT. Question on Management Protocol. We should do the SNMP objects in 802.1 (opinion). 27. pg 43, Fig 9-1, E. I suggest we show the case of a LAN with two systems on it, one a member of group M and one not. Could use one of the branches on the leftmost bridge. 28. pg 44, l 35 -, operation of GARP, MT. We should explore the collapsing or the combination of the GARP machines for the Proxy Applicant with the aim of reducing both the number of PDUs sent and the number of effective timers. The one obstacle to doing this trivially (a bit or two for timer values associated with Group Registration Entries) is timer accuracy requirements. Because of that I believe we need to explain this collapsing/scaling explicitly. This is not to say that we should replace the text found at this point in the document. There are significant advantages to explaining individual nachines separately before acting on them together. 29. pg 46, Fig 9-3 Multiple State Machine Instances Within Applicant and Registrar Functions, ME. We need a diagram, similar to Fig 9-1, showing LANs and member systems around the bridge of Fig 9-2 to make this properly intelligible to the degree to which the user can use that description of the network and Fig 9-3 to check his understanding. 30. pg 48, l 13, T. I would have thought there was a case for GARP protocol through ports in the Learning State. We should discuss, if only to record rejecting the idea. 31. pg 48, l 36, MT. The note is quite misleading, GARP PDUs should be distinguished from Spanning Tree BPDUs by the protocol id which follows the LSAP (strictly after LSAP, LSAP, UI). While it is true that GARP PDUs could be pragmatically sorted from BPDUs by group destination address this is not the means of protocol identification, and does not mean the LSAP is distinct. Much argument about this over .1D as to whether that needed an LSAP at all. Having made the choice we did we should stick to it consistently. 32. pg 51, 9.6 State Machine Descriptions, l 44 -, E. Looking at the use of the abbreviations for timers and their timeout vales in the subsequent diagrams (Figs 9-5, 9-6, 9-7) it seems that we are getting very little value from the compressed mnemonics. I suggest that we replace: jt with jointimer T with joiningtime JointTime with JoinTime (no change) lt with leavetimer Tl with leavingtime LeaveTime with LeaveTime (no change) lat with leavealltimer Tla with leavingalltime LeaveAllPeriod with LeaveAllTime as an alternative for the last set, I'd be happy with replacing lat with leavealltimer Tla with leavingallperiod LeaveAllPeriod with LeaveAllPeriod 33. pg 52, 9.6 State Machine Descriptions, l 44 -, mE. It seems that the * no longer has a real role to play in the notation. Suggest simply remove it. 34. pg 53, Fig 9-5, E. Tidy up the notation on the diagram, e.g. "Timer Expired" is not a defined event, but jt expired would have been. Define expired, stop, start, restart (restart has identical results to start) and use consistently. No need to show "=" and "start" so just use "start". 35. pg 54, Table 9-2, E. Use formal events and actions throughout, inserting references to defining clauses (e.g. "ReqJoin (9.7.1.2.1)"), and use space freed up to get the Table on one page. Define "Ignore" formally for the sake of completeness and accurate reflection of table in working model.