To: P8021 , jlarson From: John Hart/HQ/3Com Date: 9 Jun 96 11:52:17 EDT 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. John Hart ---------------------------------------------------------------------- 1. General Comments I focused my comments on general high level areas that I believe need to be addressed. Comment 1: The relationship between 802.1p and 802.1Q should be determined and identified in the document as part of the standard. My current view on this is the following 802.1p 802.1p is a general registration protocol that controls the span of domains across a bridged LAN configuration (we only want to have one of these protocols!). Each domain is explicitly identified by a value of a field in the MAC header of its intra-domain frames. The field, its associated value, and the span of domain are defined to the bridges across a bridged LAN configuration using 802.1p GARP protocol. These domains can have attributes. To date, we have only discussed one potential attribute, priority, but others can and I believe will arise (e.g., authentication of ES participation, end-to-end 802.10 encryption, etc.). Currently, the following two types of domains have been identified and I believe there are likely to be others (e.g., CIF?). Type 1 Domain - Multicast Domains These domains are identified by a layer 2 multicast address value. Currently, it has a priority attribute that will converge to the highest defined priority requested unless statistically defined. Type 1 aware ESs use GARP to automatically have bridges filter/forward multicast frames as required (i.e., they join multicast domains in which they are interested). Some multicast domains (e.g., IGMP related) need to operated at high priorities than others. Type 2 Domain - VLAN Tag Domains These domains are identified by a MAC header VLAN Tag value defined by 802.1Q. We can use the GARP protocol to restrict the flow of tagged broadcast, multicast, unknown destination unicast frames to within their respective tagged domains. For known destination unicast frames, we could verify that the ES is a member of the VLAN domain (i.e., had joined the tagged domain) before forwarding the frame on to its port. We could also tag Type 1 Domain frames and thus get rid of Type 1 (However, at a minimum, I believe that Type 1 domains are likely to remain useful as a general purpose multicast pruning protocol). Note that a Type 1 Domain can naturally overlap several Type 2 Domains or vice versa. The former may be useful in avoiding the issue of having a bridge transmit a multicast twice on the same port (i.e., once to VLAN 1 and once to VLAN 2). Instead, it transmits it once to the ESs associated with the multicast domain (i.e., to VLAN 1 and VLAN 2 ESs that are also members of the Multicast Domain). Of course, as mentioned above, the Multicast Domain could be tagged as VLAN 3 to accomplish the same thing. 802.1Q 802.1Q defines how VLAN tags are encoded into MAC headers, how they are is translated, etc. Should all of 802.1p and 802.1Q get rolled into one document with the 802.1Q becoming domain dependent section(s), like 802.1D has MAC dependent sections? Also, we should define the 802.1Q VLAN ID mapping function, otherwise, it could become a big interoperability issue? Comment 2 Is priority a domain attribute (i.e., there is one priority of traffic within a domain) or a frame attribute (i.e., there are several priorities within one domain)? If you adopt an internal perspective (e.g., VLAN tag per subnet) then priority as a frame attribute feels natural. If you adapt an external service perspective of these domains (e.g., the CNN domain, video conference domain) then priority as a domain attribute feels natural. The external and internal perspective may be some what converged by having one domain per required internal priority (e.g., 2-8 VLAN tags/IP subnet). However, it is dangerous to assume that reserving VLAN tag bits for priority helps this convergence (i.e., the bits can not be viewed by one bridge as priority bits and another as part of the VLAN ID). Also, if there are other domain attributes that need to be examined on a frame by frame basis, then encoding priority in VLAN tag bits may become less important (i.e. the switch always has these other attributes to examine anyway). Of course, we can always reserve more of the VLAN ID bits for future attributes (just kidding!). Comment 3 A protocol will need to be defined for requesting/obtaining the Domain identifiers and attributes (e.g., VLAN tag). At a minimum, we should to define our requirements for this protocol. However, if we don't define the protocol then one or more will be defined for us and we will end up supporting all of them. Comment 4 We need to pay attention to the scaling properties of 802.1p, it will likely be used as a general purpose multicast and VLAN distribution/pruning protocol. How many domains do we expect it to support efficiently?