From: Paul_Frantz@BayNetworks.COM (Paul Frantz) Reply-To: Paul_Frantz@BayNetworks.COM To: jlarson@fnal.gov, P8021@hepnrc.hep.net Subject: 802.1p/D3 Ballot Response Date: 11 Jun 1996 01:12:54 GMT SUBJECT: P802.1p/D3 - Traffic Class and Dynamic Multicast Filtering Services in Bridged LANs __X___ I disapprove for the following reasons. Paul Frantz ---------------------------------------------------------------------- 1. Technical comments --------------------- General issues: Comment 1: 1. Priority registration for unicast addresses should be removed from 802.1P. This was discussed in Wakefield and consensus was reached. Comment 2: There are several incomplete/TBD sections remaining. Comment 3: I have not repeated AddisonUs ballot comments, which I support. Specific issues: Comment 4: The document needs to be clearer about the handling of a Join All Except Specified Groups PDU when the specified group is not registered. My reading is that as far as the specified group is concerned, if no registration exists in the bridge for the switch, then the operation is a NOP. If that is a correct interpretation, please make it explicit at some appropriate place. Comment 5: 2.6.9.3 P. 16 Line 25. Extend the last sentence of the paragraph to read . . .in the filtering database and instantiation of proxy agents for propagating the registration and priority information to other switches. Comment 6: Line 21 USER_PRIORITY - some clarification is needed. The way I read it, this is the value which gets put into the filtering database. It is the priority to be used in filtering frames only if the Use Input Priority flag on the receive port is false. Is this interpretation correct? Please clarify in the text. (See also comment 11, below) Comment 7: 2.6.9.5 Line 41: TPRIORITYU appears twice in the service name Comment 8: 2.6.9.6 Line 19: T>=T should be T<=T (2 places) Line 24: T>T should be T= START_ADDRESS. This eliminates the need for the kind of strange semantics currently in lines 21-24. Corresponding changes are required in section 6.9.1 to set and read the multiple ranges. Comment 10: 3.7.3 lines 50-51 imply strict priority queueing. Replace item a) with Ra queueing delay while the packet waits to become first in line for transmission on the port according to the bridgeUs priority policy; andS Comment 11: 3.7.3 p. 22 lines 1-16: I interpreted this section as saying that the parameter USE_GARP_PRIORITY determines whether or not GARP-derived priority information gets into the Filtering Database, whereas the Forward With Inbound Priority parameter determines whether the Filtering Database or the inbound priority determines the outbound user priority. If this interpretation is correct, we need a note explicitly pointing this out, as it wasnUt obvious to me how the two paramters interact. (Related to comment 6, above) Comment 12: p. 23 line 6 replace Trationale for the choiceU with Trationale for the recommendationU Comment 13: 3.7.5 The text in lines 41-44 defines the standard requirement and then footnote 2 says you can do something else if you want. This doesnUt make sense. Make one or the other of the following changes: 1) In footnote 2, change Timplementor may choose to provide alternative de-queuing algorithms, that better . . .U to Timplementor may choose to provide, in addition to the default algorithm described above, alternative de-queuing algorithms that better . . .U 2) Replace the sentence which begins on line 41 with TFor a given supported...U with TThe specific queuing algorithm used to prioritize traffic from higher traffic classes ahead of traffic from lower traffic classes is an implementation option. One algorithm which meets the requirement to provide lower-delay service to higher traffic classes is to select frames for transmission from the queue for a particular class of service only if any queues corresponding to numerically higher values of traffic class supported by the Port are empty at the time of selection.U Comment 14: 3.7.6 line 6: The text says the access priority shall be one of the three options given. Clarify whether the implementor has free choice to select amongthe options or whether there are constraints on the choice. Is option c) allowed when the bridge configuration is such that the outgoing user priority is not based on the inbound user priority? Comment 15: 3.9.3.2 and other sections - clarification is needed on the relationship between existence and membership registrations. ItUs stated in 9.1 that registration for membership implies registration for existence. Then things get sloppy. If a client on port A registers for membership, then does the proxy agent on port B register for membership only or for membership and existence? How about if a client on A registers for membership and a client on port C registers for existence. Is the port B proxy agentUs behavior different in this case? It seems the problem is that really there is a single registration and it has two levels: TExistenceU and TExistence + MembershipU. This notion would clarify the behavior of proxy agents: if one or more of the clients they represent was registered TE+MU they would proxy out TE+MU otherwise they would proxy out TEU only. It also would pin down the proper parameter encoding - there would be three legal values - TnoneU, TEU, and TE+MU. This removes the ambiguous case we have now with the question of whether or not the TEU bit is a TdonUt careU whenever the corresponding TMU bit is set in a data structure. Comment 16: p. 28 lines 7-9: Change the text to allow membership registration to be static on some ports and dynamic on others. Comment 17: p. 28 lines 11-12. As above, change the text to allow a mix of dynamic and static entries on a per-port basis. This becomes significant when the static entry is changed so that there no longer is any static registration for existence (or membership). At that point, you really want to have been keeping track of dynamic registrations so there is no service interruption in a mode 2B bridge. Comment 18: 6.7.5.8.2 - The mechanism is unreliable for reading group registration tables which may be having entries added or deleted in between reads. It would be better to say that the output entries are give in increasing MAC order, and the start and stop indices are replaced by start and stop MAC addresses. Comment 19: p. 64 line 51, should read 'conditions are all true' not Tconditions are all falseU. Comment 20: p. 66 line 50 g) In the case of updating an existing entry, the value is unchanged. In the case or creating a new entry, the default priority for traffic through the bridge is used. Comment 21: 9.7.2.3.3 Change to T... held in the Group Registration Entry, the Priority field in the entry either retains its current value or is updated to show the new value in accordance with the rules defined in 9.7.2.3.2. Comment 22: 9.8.3.4/5/6 - What is the use of the Delay paramter? If itUs specUd somewhere I missed it. Comment 23: 9.8.3.11 - Lines 39-40: It says A valid flag octet shall have at least one of the two defined flags set. These flags are meaningless in the TExcept Specific Groups PDU FormatU and should be ignored in that case. Comment 24: 9.9.2 Timer Granularity - The standard needs to mandate a granularity which is at least as fine as that fraction of the minimum supported Leave Time that proper protocol operation, including reasonable spreading out of the randomized timer values, is guaranteed with some margin. Perhaps 1% of the minimum supported leave time? Comment 25: E.2.2.4 - Modify the second paragraph to suggest that configuring the range(s) of addresses eligible for GARP registration is another key part of the migration strategy. Why? - New applications (e.g. multicast video) may be GARP-only, but both old and new stations will share some multicast addresses, e.g. the AppleTalk multicast addresses. The new stations are likely to GARP for all multicast addresses they need, including those like the AppleTalk addresses which are shared with legacy stations. By allowing the administrator to configure GARP to run only on specific address range(s), e.g. the IP multicast range, the migration is considerably simplified. If we wanted to really nail this problem we would allow configuration of two sets of multicast addresses: one set of which is delivered only to GARP-subscribed mode 2B ports (e.g. IP multicast) and another set delivered to GARP-subscribed 2B ports and to 2A ports (e.g. AppleTalk). IUm not sure the complexity to do this is warranted, however. Comment 26: E.3.1 In addition to the processing indicated, the router (or Sniffer) needs to process Leave messages received for addresses in which it is interested. The case of interest is where there is a single client on the shared segment connecting the router to the bridge, and that end station decides to Leave a multicast group. If the router does nothing, the client and the bridge will negotiate to unsubscribe the segment from the group, and the router will get a service interruption until the next Leave All timeout. What is the state and PDU flow which allows: 1) When the last local client issues a Leave but the group is still legitimately registered for existence, say by a sender elsewhere in the network, the router can tell the switch to keep forwarding packets to it, at least until the next Leave All cycle. 2) When the last real client or server (as distinct from Join All clients like the router) Leaves or gets timed out on a Leave All, the registration for existence should go away. There is a problem here that I havenUt found a solution to yet. When a router is receiving group traffic for a registered group as a result of a TJoin AllU PDU, the routerUs desired port state is not really registered and not really unregistered. ItUs TIf somebody else has registered this group for existence, then register me for membership, otherwise donUt register me.U Without this in-between state, you get a choice between having a service interruption to the router when the last client in the routerUs subtree of the network Leaves, or never being able to delete a registration state machine once it has been instantiated - the router will always keep it alive. ItUs almost as if we need another bit combination besides Tregistered for existenceU and Tregistered for membershipU - one for Tregistered to listen if the group existsU. Comment 27: E.3.1 This section describes routers sending Joins, Leaves and Join Alls in response to various packets. It doesnUt say whether these responses are immediate or delayed with a randomized delay value. If they are immediate, we are creating some poor network citizen behavior for systems like FDDI backbones where a single Join or Leave All will generate a simultaneous response from every router on the ring. It would be better to spread them out. Comment 28: H.1.4.3 p. 95 line 53 reads TNote that loss of AUs second Join ...U - there is no second join according to figure 9-5. If the state machine is correct, strike this entire sentence on p. 95. Comment 29: p. 98 lines 49-52: This scenario provides a very slow recovery from one dropped join packet.(have to wait for LeaveAll). This is not an issue for Leaves, but it is unfortunate for Joins. This might be a common scenario after a power-up or topology change. Is there a straightforward way to fix it? Comment 30: p. 119 Issue 14 asks is this what we want? - No. If unicast GARP is supported, then we need a way to make sure that unicast GARP only runs where administrators specifically want it to, and not as a side effect of turning on multicast GARP. 2. NON-BINDING COMMENTS ------------------------------------------ Comment 31: p. 119 Issue 16: per-port priority registration is not important enough to justify the added complexity. Comment 32: p. 119 Issue 17: Configuration should be via an SNMP MIB. Comment 33: Either unicast registration should be removed from the standard entirely, or if it remains, text needs to be added giving guidance about when it is appropriate for an end station to register its unicast address(es), and when itUs better to *not* register unicasts, but to rely on traditional bridge learning. Section F.2 discusses this, but itUs buried in an appendix and it alerts the user to the existence of a problem, but does not go into sufficient depth to drive an intelligent decision about whether or not to use unicast registration. Section F.2 provides a cogent argument against unicast registration. Perhaps we should take out the feature? Comment 34: Figure 9-5 and table 9-2: It seems like in the Very Anxious state the behavior for rjoin and timer expiry should be the same. If you always want two joins after a leave then go to Less Anxious. If one join after a leave is sufficient because you can only get into trouble if both the second join and the subsequent 2nd leave are both lost, then you can go to TInU state. I believe the state machine is functionally acceptable as-is, but it does seem inconsistent.