Date: Mon, 10 Jun 1996 18:38:20 -0700 To: Jo Ann Larson From: Larry Birenbaum 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. Larry Birenbaum ---------------------------------------------------------------------- 1) Explicit Unicast Address Registration is Unworkable. -- I agree with Norm's Wakefield presentations demonstrating that unicast registration has serious problems in terms of scaling and compatibility with higher layer protocols. The unicast address registration part of the standard should be removed. 2) Implicit (Algorithmic) Address Priorities are not Interoperable. -- As currently written, the draft standard provides a priority queuing mechanism (traffic classes) that is independent of the manner in which frames are priority-differentiated. In addition to explicit address registration, implicit schemes in which frames are prioritized algorithmically is also allowed. Indeed, Norm's presentation made a compelling arguement that implicit, two level prioritization based on the U/L bit in the source address is the only practical method and thereby virtually mandated by the draft standard. In any case, the draft standard appears to condone implicit frame prioritization, presumably at the vendor's discretion, yet is silent as to any specific algorithm. Allowing algorithmic prioritization without specifying an algorithm is inherently non-interoperable. The standard must either specify a common, priority-determining algorithm or prohibit algorithmic (implicit) priorities altogether. 3) "Recommending" Two Priority Levels is Inconsistent with Allowing Eight. -- With the accomodation of two to eight priority levels, the natural interpretation would be that two is merely the minimum number and, indeed, that the more levels implemented, the better. However, on page 22 the draft standard actually "recommends" that two be implemented, in effect specifying that "only" two be implemented. Since implementing two levels are obviously easier than eight, and since the draft standard recommends two, why would eight levels be allowed? The standard should either eliminate this recommendation, positioning two levels merely as the minimum, or provide for only two levels. 4) A Minimum of Two Priority Levels is Insufficient for Imminent Multimedia Protocols. -- As indicated in the ISSLL and Pratt presentations, RSVP requires two priority levels for optimal operation which, along with the underlying Best Efforts service for traditional data applications, suggests that a minimum of three priority levels would be beneficial. Presumably, other multimedia protocols could make similar cases. Furthermore, there is an additional perceived need for a separate priority for management traffic. One arguement in favor of a two level minimum would be facilitating low cost implementations, but is implementing three queues much more costly than implementing two? Also, there are currently no two level priority standards or installed base which must be grandfathered. This new standard should "do it right" and set a minimum of three priority levels. 5) Priorities May Be Better Served in 802.1q. -- Besides the difficulties noted above, Keith's presentation argued for decoupling of address and priority, e.g., showing that address-based priorities necessitated supplemental traffic that was problematic. John Wkerly's presentation also argued that the end-station tagging required by 802.1q could be leveraged for priority setting and that associating priority with the Ethertype/VLAN tags of 802.1q might be very compelling. Perhaps the committee should focus 802.1p on multicast pruning, something that appears to have universal endorsement, leaving priorities for 802.1q. _________________________________ Larry Birenbaum WBU/DCD Engineering (formerly Grand Junction Networks) (408)526-8312; FAX:(510)252-0915 larryb@cisco.com