RE: Deployment Review for Bandwidth Attributes Document

["Bari, Farooq" <farooq.bari@cingular.com>]

I had similar understanding i.e. DSCP/802.1 tags were outside the scope
of this radext draft.

Farooq Bari
Cingular Wireless
Core Network Standards
 
farooq.bari@cingular.com
+1 425 580 5526

> -----Original Message-----
> From: Adrangi, Farid [mailto:farid.adrangi@intel.com]
> Sent: Monday, September 19, 2005 8:44 AM
> To: Bernard Aboba; Mick Seaman
> Cc: Bari, Farooq; radiusext@ops.ietf.org; tony@jeffree.co.uk
> Subject: RE: Deployment Review for Bandwidth Attributes Document
> 
> Yes, I agree.
> 
> WME/802.11e (w/Call Admission Control - CAC) deployments in Enterprise
> networks is now happening.  And, WME/802.11e enabled Public WLAN
hotspot
> deployments are next in order to provide WLAN users real-time services
> w/ QoS over WLAN and also enabling end-2-end QoS.  The draft was
> originally intended to allow the home network to indicate the
Bandwidth
> Authorization (BA) to the WLAN access network for a given user, and
also
> enable the access network to indicate the allocated bandwidth in the
> accounting messages.  Later also profile ID was added. Based on the BA
> information and the profile ID, the access network should be able to
> decide whether it can accept an 80211e/ADDTS request from a user.
> 
> While use of DSCP/802.1 tags over WLAN link and their mappings to
wired
> segments are important, it is outside the scope of this document -
IMHO.
> 
> 
> Thanks,
> Farid
> 
> > -----Original Message-----
> > From: owner-radiusext@ops.ietf.org
> > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> > Sent: Sunday, September 18, 2005 8:52 AM
> > To: Mick Seaman
> > Cc: 'Bari, Farooq'; radiusext@ops.ietf.org; tony@jeffree.co.uk
> > Subject: 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/>
> >

--
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/>