[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Deployment Review for Bandwidth Attributes Document



From a technical point of view,  the Bandwidth Attributes and 
VLAN/Priority documents were chartered in RADEXT WG for the purpose of 
satisfying requests originating in the IEEE 802 community.  The BW 
Attributes request came from WFA (marketing arm of IEEE 802.11), and the 
VLAN/Priority document came out of IEEE 802.1. 

While it is ok (good, in fact) if those documents satisfy other 
constituencies as well, at the end of the day, these documents MUST meet 
the needs of the groups making the original request. 


On Sat, 17 Sep 2005, Mick Seaman wrote:

> 
> Farooq,
> 
> Given that a lot of bridges are deployed in environments were keeping
> management to a minimum is a practical necessity, and that there are very
> widespread deployments which use fairly well known values what you say is
> legalistically correct but can only give rise to conflict. One of the future
> items of working that is being proposed in 802.1 is the use of Ethernet for
> residential home entertainment applications including a variety of music and
> video applications. The notion that a home owner is going to make a
> management decision abut his or her network and then manage a lot of
> different equipment with different natural backgrounds will kill ease of
> use, or prevent equipment that departs far from usual practice being
> successful. 
> 
> So my legalistic response here is that we are talking about 802.1D/.1Q
> priorities here, whose aim is to support Diffserv and does provide a lot of
> flexibility but also whose aim is to provide as much usual guidance as
> possible an advocate the default use of mappings that seem to provide
> maximal interoperability with minimum management. A lot of effort has been
> put into that so far, and the notion that all might be discarded and revised
> to a new set that requires further management because "anything is possible"
> is not something that should happen without examination.
> 
> Goals that are impossible to achieve fully  can still yield substantial
> benefit to many people if 80% achieved. There is no reason to suppose that
> in the absence of perfection we should advocate anarchy.
> 
> Mick
> 
> -----Original Message-----
> From: Bari, Farooq [mailto:farooq.bari@cingular.com]
> Sent: Saturday, September 17, 2005 8:49 AM
> To: mick_seaman@ieee.org; Congdon, Paul T (ProCurve)
> Cc: radiusext@ops.ietf.org; Bernard Aboba; tony@jeffree.co.uk
> Subject: RE: Deployment Review for Bandwidth Attributes Document
> 
> Hi Mick,
> 
> I look forward to hearing from you. I do want to float my understanding
> of DSCP usage and understand if other folks disagree (although this
> topic does not have much to do with radext). 
> My understanding is that interpretation and usage of DSCP within a
> network is whatever the owner of the network decides to have i.e. it can
> choose to ignore them, overwrite/remark them, use them to prioritize
> traffic the way it decides etc. The importance of standard
> interpretation/marking of these settings is typically at the boundaries
> of networks. However this standard interpretation is dependent upon on
> the SLAs that the networks have amongst themselves i.e. the
> interpretation is not global but limited to SLA. SLAs between networks
> can vary significantly based on network technologies and the type of
> traffic that they carry. Also I am not aware of any forum in the world
> that can standardize this for all the networks in the world. So if I
> understood the comments correctly, although the goals seem noble they
> may be quite hard to get (if not impossible).....
> 
> BR,
> 
> Farooq Bari

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>