To: anil Cc: "100271.522" <100271.522@compuserve.com>, p8021 From: Peter Wang/HQ/3Com Date: 2 Jan 96 19:37:21 EDT Subject: Re: P802.1p/D1 - Although I agree fundamentally that ability to reserve some some bandwidth for low priority traffic is deisrable and useful, I'm not sure that specifying it in the standard at this point is prudent. A hard spec for resource reservation may unnecessarily jack up the cost of low end switches. (I.e. do we really want to force all of the LAN switches to be as complex as ATM switches?) So, I'd think wording the std. to state that a pure priority based queues is the minimal compliant implmentation and that alternative resource reservation schemes are left to implementor's choice may be the suitable solution. - I don't see why 3 priorities are necessary to accomodate differentiation between at least 2 multimedia/safety-critical and "other" traffic. Why does one really need to distinguish among similar multimedia and/or other real-time traffic? In any case, a recommendation for 2 levels of priorities doesn't prevent anyone from implementing a scheme with 3 or more priorities. But if one wants to offer finer grain control, may be some form of bandwidth reservation will be more effective (though probably more costly). - Ports in blocking states DO NOT participate in GARP as its stands in the draft. The intent is to let spanning tree do what it needs before GARP transitions (or force re-establishment of group membership). - The case of a high speed port which can accomodate traffic from all low speed ports and therefore needing only one queue instead of two: isn't this just a case of TDMA in essence? (I.e. since the draft std. is written with output queuing model.)