To: P8021@hepnrc.hep.net, jlarson@fnal.gov Cc: 100271.522@CompuServe.COM, r.tasker@dl.ac.uk Subject: 802.1p/D3 Ballot Response Date: Fri, 31 May 96 15:12:31 +0100 From: "Robin Tasker" SUBJECT: P802.1p/D3 - Traffic Class and Dynamic Multicast Filtering Services in Bridged LANs __X__ I disapprove for the following reasons. Robin Tasker Technical ********* Page 12 Line 35/36 Replace "traffic" in item (b) by "frames". A Note is also required here to say that such operation is dependent on the active participation of end stations, and where this is not possible the service is unavailable. Indeed Section 2.6.5 last paragraph spells out that it is optional. Page 14 Line 48 Not convinced "Topology Enforcement" is the correct description. I believe "Static Filtering Services" better describe the process outlined in 2.6.8.2 Page 52 Line 24 onwards This paragraph spells out for the first time that an end station (or application running on it) is able to modify priority which will have an effect across the entire bridged LAN, i.e. the operational control and management of the bridged LAN has been abandoned to the whims of the user community. Is this really what is wanted and expected of this Standard. Also what happens in 2.6.9.1 when different MAC service users specify different priority values for the same Group. In 2.6.9.2 a user priority is specified when a set of addresses is provided for which registration is required. How is conflict resolved when the user priority specified in the Registration request is different from that specified here. Page 19 Line 36/37 Text says "in order to expedite transmission of frames generated by critical or time-sensitive services" but in reality it is true regardless of how the frames were generated and depends solely on the value of the priority parameter specified. Page 20 Line 23 "enforce topology restrictions" sounds altogether too grand - the detail given in 3.7.1 shows frame discard to meet the requirements of the Spanning Tree and support of the maximum service data unit size supported. I would be far happier if these reasons for frame discard were enumerated together with those reasons shown in 3.7.2 under a general heading of Frame Discard. This would also tied in with Figure 3-7 which I suspect people generally understand. Page 21 Line 52 - 54 My understanding of access delay on frame transmission is that delay experienced until the medium is available. I can't therefore see how it can be managed by the use of user_priority. Page 22 Line 34 - 38 This paragraph sounds exactly like the description of an implementation. I would be happier if it were described in a more general sense so as not to constrain an implementor. Page 23 Line 40 - 44 The second sentence of this paragraph implies that frames of a lower traffic class may never be transmitted for the reasons described in 3.7.4. I wonder whether this really is a desirable characteristic to introduce into a Standard. Page 23 Line 49 - 52 Note 2 is an extremely dangerous subject to include here. It encourages implementors to provide algorithms to meet particular (i.e. specific) needs which may not interoperate with MAC bridges from other manufacturers. This will lead to an inconsistent service across the bridged LAN. The Note must be removed. Page 25 Line 27 and 47 Both lines mention "by local or private means" in a discussion of management. This may be true but surely a Standard should consider only standardised ways of providing management access. Both should be deleted. Page 28 Line 7 and 11 The definitions here should state that they are optional just as the definition of user_priority does at Line 14. Page 37 Line 23 and 25 Page 38 Lines 8 - 16 In 6.7.5.5.2 (6.7.5.7.3) the inputs (outputs) are described with items as optional. This conflicts with 3.9.3.2 which says that where the MAC address has been statically configured these items are mandatory. Page 41 Line 1 The management protocol should be defined as gdmo additions to 802.1j Page 47 Line 34 In item (h) "The latency involved ...... will be small......" What does this mean? Compared to what? Page 50 Line 16 - 20 The paragraph deals with the use of Leave PDUs for groups. The mechanism described means that all Groups, regardless of how recently created, will all be expired together. Is there benefit from having per Group LeaveTime so that Groups are dealt with separately so avoiding the point described above and also spreading the load of this procedure. Page 60 Line 30 In the Action of Table 9-5 does the order of events matter, i.e. should the actions occur before the timer is restarted? Page 70 Line 49 This paragraph introduces a set of terms and provides a short description of their use. However whilst "tag" is introduced it is not described. Page 74 Line 45 This Section describes timer relationships but I found it incredibly difficult to follow, in particular the wording of the third sentence of item (a). In addition it would appear that all timer relationships are based upon LeaveTime which is NOT described here. LeaveTime would appear to be a variable value on a LAN segment, in item (a) there is "the smallest value of LeaveTime..." and also the value in Delay field set as "0.4*LeaveTime" whilst in (b) there is "the largest value of LeaveTime...". It appears therefore that 3 separate values of LeaveTime are required in order to set the other GARP timer values to ensure the correct operation of the protocol. This detail needs to be explained together with how this is co-ordinated across the LAN segment - otherwise the correct operation of GARP must be in doubt. I think item (a) defines 2*JoinTime < LeaveTime(min) Delay field = 0.4*LeaveTime item (b) defines LeaveAllPeriod > 2*LeaveTime(max) item (c) defines PriorityResolutionPeriod > LeaveAllPeriod Page 83 Line 40 - 43 I'm not convinced that item (a) is a good or likely category. It discusses safety critical operations using priority on a shared media. This seems highly unlikely - if something is that vital it would never be implemented on a shared network in the first place! Page 84 Line 11 - 19 Item (a) would read better as follows, "The majority of current LAN installations carry either non-time critical traffic or a combination of time critical and non-time critical traffic;" The underlying assumptions and rationale for item (b) are not explained to support the statement "will deliver significant benefits in terms of the QoS required, and in terms of the number of time critical channels that can be carried..." In the final paragraph of this section in says "The choice of two traffic classes as the recommended value is therefore considered..." but I have read nothing to support this view. This section gets to the heart of the issues surrounding the use of different priority levels across the bridged LAN. We have already had an extensive email discussion on this matter and from that it is clear that on a well (almost ideally) resourced network with brilliant management and a very well controlled user community the use of priority has some (limited) benefits. On all three counts the real world is very different and whilst the use of priority may have some benefit it is likely that the problems introduced will be far greater. It comes down to the fact that the choice of priority class is in the hands on the end user (applications etc) and at a stroke the correct operation of the network has been devolved in an anarchic manner to the entire user community. Page 85 Line 13 This discussion suggests the use of multiple unicast addresses, one for each priority level. Such a scheme will have a knock-on effect where, for example, the applications are IP based. Each MAC address will need to associated with an IP address for correct resolution, so the total number of IP addresses allocated will increase by between 2 and 7-fold. IP addresses are a scarce resource! The section concludes that such operation should used with caution, but how can this be controlled? Page 87 Line 19 Goal (a) and Non-Goal (a) are mutually exclusive! As a goal it says that "provision of expedited data transmission ... in order to satisfy the QoS requirements ..." yet as a non-goal "the provision of guaranteed QoS levels for expedited traffic classes". So which one is it? *********************************************************************************** *********************************************************************************** Editorial ********* Throughout Use either "end station" or "end system" but not both! Page 12 Line 12 Delete item (a), its covered by item (b) Page 12 Line 27 Replace "may not be" with "are not" otherwise what's the point of establishing an administrative boundary Page 12 Line 45 - 50 Replace this sentence with "The filtering services provided in Bridged LANs offer a set of capabilities that may be used in order to:" In item (a) replace "they will be using" with "will be used" Page 13 Line 8 - 12 Delete first sentence, "Client and server systems" and replace "client and servers" in the second sentence with "two or more end stations". Delete item (c) as it is not relevant Page 13 Line 28/29 Items (1) and (2) need to reference the appropriate Section where they are explained etc. Page 13 Line 44 - 49 Delete from "This configuration ....." to end of paragraph as the subject is discussed in detail in the remainder of the Section. Page 14 Line 14 - 24 The sub-modes discussed as items (c) and (d) are in reality sub clauses of item (b) and should be numbered as such. Page 14 Line 29 Delete "(server systems and end stations)" as unnecessary. Page 24 Line 6 - 11 Replace "shall be either" with "shall be one of". Either implies a binary choice and the text shows three options. The "or" at the end of items (a) and (b) should be deleted. Page 24 Line 18 Change "Note that the ..." to "Note: The ......" Page 24 Line 53 "provides a means whereby time critical traffic..." This statement is true but what has been described provides a generalised way of providing levels of priority the operation of which is beyond the control of these devices. Page 25 Line 15 - 16 Convert both items (a) and (b) into two single sentences by replacing the ". This " with ", which " in both cases. This aids reading. Page 25 Line 23 Item (d) covers "multicast addresses" but is this function restricted solely to multicasts. Page 25 Line 29, Page 26 Line 19 Replace "any timeout mechanism" by "any ageing mechanism" for consistency elsewhere in the document. Page 26/27 Line 40 onwards The item delineators require attention, i.e. items (d) and (e) should be reset to (a) and (b) as should (f) and (g). Page 27 Line 14 In the sentence beginning "The timeout value, or Ageing..." delete "timeout value," so it reads "The Ageing Time after which a ....." for clarity. The concept of Ageing Time is already well understood. At Lines 22 and 23 "timeout value" and "timeout" should be similarly replaced. Page 27 Line 36 - 37 The use of "only", "only" or "both" in this sentence was a bit confusing - was the sentence really necessary. Page 28 Line 20 - 33 The item delineators would read more naturally from (a) through (d) instead of (f) though (i). In item (f) it says "the entry shall contain a registration_permitted_on_port_set and a registered_for_existence_on_port_set". However these two port_sets are optional so the text reads somewhat inconsistently. Page 35 Line 9 "dATABASE" needs attention! Page 42 Line 49 "registration/tergiversation" needs attention! Page 43 Line 1 Replace " along with pointer information" by "along with additional information". The use of pointer sounds a little implementation specific. Page 44 Line 21 - 25 This paragraph should be a Note: as it provides interesting through not strictly necessary information. Page 45 Line 3 - 8 For clarity please restructure item (d) by breaking the first and subsequent sentences as follows, ".......the Filtering Database. This function also ensures that ...... Spanning Tree topology changes and also ensures that ......" Page 45 Line 17 Replace "at any moment in time" by "at any time" as a moment is indeed at any time! Page 46 Line 1 Move the closing clause so the sentence reads "...Ports A, C and D will, assuming that all Ports are in Forwarding, issue....." to make the sentence more readable. Page 47 Line 12 "The requirements include ......., backwards compatibility, ...". But backwards compatibility with what? Page 47 Line 19, 21 and 48 Restructure items (c) and (d) to be more readable so that both sentences finish "...... the set of Groups to which the Applicants they represent wish to be members;" Similarly the final sentence of item (l) should change to read "...of Groups to which Applicants on that LAN wish to maintain membership." Page 47 Line 27 Item (f) replace "strip out" with "remove" Page 62 Line 20/21 This Note should be moved to the start of 9.7.12, Protocol Event Definitions as it is relevant throughout this Section. Page 72 Line 3 The encoding of "tag" is described but no purpose is provided. Compare this to the other items, e.g. encoding of "count" where both are provided. Page 78 Line 14 - 23 To aid readability, this paragraph should be split into two separate ones at the end of the second sentence, with the (new) second paragraph modified to read, "With the current and future focus on hub architectures incorporating both multi-Port Bridges and switching technology, it is appropriate to include in the Standard examples of such topologies. This is particularly important given, that in order to derive the full benefit of the dynamic multicast filtering capability, it will be necessary to employ just such LAN topologies. The following diagram therefore presents a more representative Spanning Tree topology, including both shared media elements and hub architectures." Page 79 Line 26 - 35 To aid readability, break first sentence of paragraph at the end of the second line and make the following modifications, "......in terms of traffic segregation. However such benefit will also depend ..... and GARP-unaware end stations (see E.2.2). In general .... have registered members on all Ports and the Bridge will therefore .... little Group traffic. Placing a Legacy Bridge at a similar location in the ... on adjacent LAN segments. Conversely ... on each Port and Enhanced Filtering Mode will therefore be of more value." Page 79 Line 37 -39 This Note should be deleted - its interesting stuff but not particularly relevant to the discussion. Page 79 Line 45 - 49 Replace this paragraph with "As Legacy Bridges are transparent to GARP the placement of end stations on segments served by such devices is of little interest to this discussion." Page 80 Line 1 and 3 Change "station" to "end station"! Page 80 Line 9 - 19 For clarity split this paragraph into three separate ones at the end of the second sentence and the end of the third sentence. In addition the (new) second paragraph should be split into two sentences as follows, "An alternative ... on its segments. However, the network administrator ... for this to work." Page 81 Line 16 Replace "to any addresses" with "to any of the addresses"! Page 85 Line 23 Change "at any moment in time" to "at any moment"! Page 90 Line 22 Replace "essentially uninteresting" with "not relevant to this discussion"