Date: Mon, 10 Jun 96 09:46:18 CDT From: keen@ncrssd.StPaulMN.ATTGIS.COM (Hal Keen ) To: jlarson@fnal.gov, p8021@hepnrc.hep.net Subject: Disapprove on P802.1p/D3 SUBJECT: P802.1p/D3 - Traffic Class and Dynamic Multicast Filtering Services in Bridged LANs __X__ I disapprove for the following reasons. Hal Keen, NCR ---------------------------------------------------------------------- Comments accompanying vote of Disapprove on P802.1p/D3 Source: Hal Keen, NCR 1. 2.6.9.6, Registration range configuration (p. 18) This section provides for setting a range of valid MAC Addresses for Group registration. However, no generally accepted ordering principle exists for MAC addresses. Interoperability problems arise in regard to both the relative weights given to bit positions in each octet, and the relative weights assigned to the successive octets. While the Token-Ring ordering sequence has significant merit in that it creates separate ranges for the group and individual MAC addresses, converting MAC addresses to Token-Ring values is both inconvenient and non-intuitive for users of addresses in the standard Hexadecimal Representation. It may be most practical simply to drop this provision. Given that any method of specifying a range of addresses will be significantly more difficult for some implementations than others, control of address registration by ranges does not seem a sufficiently general capability for standardization. 2. 9.4, Requirements of the MAC Bridges, note 1 (p. 48, ll. 36-37) The note is inaccurate. Group MAC addresses identify groups of MSAPs, not some sort of "group MSAPs." A single MSAP is not made multiple if it is identified by multiple group MAC addresses. Within the context of a single MSAP, a given LLC address identifies only one LSAP, regardless of the particular MAC address used. (See the MAC Service Definition, ISO/IEC 15802-1.) As an analogous but more familiar case, consider the use of the MAC Broadcast Address in addition to an individual MAC address. At a given station, a given LLC address identifies the same LSAP when used with either of these MAC addresses. Many protocols depend on this characteristic. Where supported, GARP therefore uses the same LSAP as the Spanning Tree protocol at a bridge port. It is nevertheless distinct, because the Protocol Identifiers in BPDUs and GARP PDUs are different; coexistence of the two protocols at the same LSAP is no problem. The function of the differing MAC addresses is to permit GARP to be both recognized and filtered at GARP-capable bridges, but forwarded by bridges which don't implement GARP. 3. The entire design of GARP is suitable for achieving its main goal, the dynamic multicast filtering services. This makes it a very clumsy mechanism for controlling unicast priority. For one thing, significant scaling concerns arise; they are not easily dealt with. For another, the control of priority is all in the wrong place. A destination requesting high-priority service would have to do so for all traffic, regardless of origin. An adequate priority system must be capable of distinguishing between separate flows even between the same pair of MAC addresses. The sender can do so, by indicating user priority; GARP and the filtering database cannot. It should be stated in the standard that GARP conformance is only concerned with group MAC addresses, and that an implementation may explicitly exclude group registration for individual (unicast) MAC addresses. A flat prohibition is not necessary or desirable, since unicast registration would be merely an extension of the existing service beyond the scope of GARP. We need merely make clear that such an extension would be nonstandard, and would not reach through bridges which exclude such registrations. A note referring the reader to the material in F.2 (page 85) should sufficiently discourage such extensions except where they are explicitly desired, for some proprietary purpose. (I'm suggesting this approach partly to retain that cautionary material; F.2 might be revised to give it an even more discouraging tone.) 4. The priority handling for multicast traffic also needs to be reconsidered. 3.7.3, Regenerating User Priority, specifies a default Port setting (p. 22, ll. 21-23) which ignores received user_priority entirely. In many cases, this behavior is unsuitable, and such cases will cease to have anything to do with particular bridge ports as soon as a scheme for conveying user priority over CSMA/CD is adopted. What is needed is a way to perpetuate suitable mappings of user priority, initially indicated by the sender of each frame, all the way through the last bridge; the emphasis is on preserving frame-by-frame choice rather than overriding it with a more general selection. Otherwise, bridges frustrate all attempts to send traffic at multiple priorities between the same two stations. [It is assumed that senders indicating high values of user priority are governed by a bandwidth allocation or reservation technique (e.g., RSVP), which 802.1 considers a higher-layer concern at the moment.] To properly utilize the user priority, both the Filtering Database and the GARP protocol must support an explicit "not specified" value for user priority, allowing filtering entries to be created which do not override the received frame user_priority. This can be introduced in: - 3.9.3.1, Filtering Entries (p. 26, ll. 46-47), - 3.9.3.2, Group Registration Entries (p. 28, ll. 14-15), and - 9.8.3.11, Encoding of Group Operators (p. 74, ll. 31-33), with a specified encoding for use in the protocol. The Forward With Inbound Priority parameter, if retained at all, should default to TRUE. 5. In regard to Bob Watson's comment on Figure 9-2 (p. 45): Bob is pointing out that MAC users need not be assumed to be LLC. However, in this figure, the LLC references are correct. LLC is the data link protocol immediately underlying GARP.