RE: Deployment Review for Bandwidth Attributes Document

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

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

> -----Original Message-----
> From: Mick Seaman [mailto:mick_seaman@ieee.org]
> Sent: Friday, September 16, 2005 9:49 PM
> To: Bari, Farooq; 'Congdon, Paul T (ProCurve)'
> Cc: radiusext@ops.ietf.org; 'Bernard Aboba'; tony@jeffree.co.uk
> Subject: RE: Deployment Review for Bandwidth Attributes Document
> 
> 
> Farooq,
> 
> Yes, my comments (and these were necessarily quick because I don't
have much
> time just at the moment) are all to do with the code point choices.
While these may
> not be the most technically important things in the document, getting
most of the
> world lined up on usage will be of tremendous value - and will avoid
having to make
> arbitrary choices about what some important new application areas
should be
> consistent with.
> 
> We have some recent experience with someone writing what was meant to
be a
> harmless example possibility into a document (just a random document
as it turned
> out, not even a standard or pseudo-standard), and the whole world went
off and
> stole a (fortunately unallocated, but unchecked) code point. In that
case it was an
> Ethernet Type allocation, but you get the idea. Examples get treated
as the gold
> standard by those who don't read further.
> 
> I will try and get you some more detailed feedback next week, as it
happens we
> have an 802.1 meeting and I will put some time on the agenda for the
group to
> generate some more considered input/views on the particular scenarios
raised. I
> will also get time to read the document properly for the things I have
missed and
> other casual readers may miss.
> 
> Mick
> 
> -----Original Message-----
> From: Bari, Farooq [mailto:farooq.bari@cingular.com]
> Sent: Friday, September 16, 2005 9:08 PM
> To: mick_seaman@ieee.org; Congdon, Paul T (ProCurve)
> Cc: radiusext@ops.ietf.org; Bernard Aboba
> Subject: RE: Deployment Review for Bandwidth Attributes Document
> 
> 
> Paul, Mick,
> 
> I take it from the comments that they are about diffserv
mapping/marking
> and not regarding section 5.2.1 which is related to radext discussion.
> Also pls note that 3GPP has NOT defined any new diffserv marking /
> mapping but only tried to explain a SAMPLE scenario as to how a system
> could work in the presence mappings / diffserv markings/mappings
already
> defined by other forums (WiFI Alliance, GSM, IEEE....). I would be
happy
> to bring in changes into 3GPP specifications if the sample scenario
> seems incorrect / inconsistent.
> 
> BR,
> 
> Farooq Bari
> 
> > -----Original Message-----
> > From: Mick Seaman [mailto:mick_seaman@ieee.org]
> > Sent: Friday, September 16, 2005 4:26 PM
> > To: 'Congdon, Paul T (ProCurve)'
> > Cc: Bari, Farooq; radiusext@ops.ietf.org; 'Bernard Aboba'
> > Subject: RE: Deployment Review for Bandwidth Attributes Document
> >
> >
> > Paul,
> >
> > You are right these seem to be a fair way out of line which is
> worrying
> > because the mappings advocated in .1Q-REV Annex G were particularly
> chosen
> > (very slightly tweaked from .1D-2004) to maximize interopearability
> with lot
> > of deployed IP stuff, use of MPLS EXP bits etc.. At first glance
> (which is
> > all I have time for) the mappings in the attached {.11e,Wi-Fi, 3GPP}
> > document seem somewhat arbitrary, just carving the available space
> into 4
> > chunks. I would hope that these could be rechosen to fit into the
> maximal
> > interoperability recommendations already in Annex G. Otherwise
someone
> is
> > going to be managing a lot of translation gateways, which is very
much
> not
> > in the spirit we have tried to pursue.
> >
> > Mick
> >
> > -----Original Message-----
> > From: Congdon, Paul T (ProCurve) [mailto:paul.congdon@hp.com]
> > Sent: Friday, September 16, 2005 3:04 PM
> > To: Mick Seaman
> > Subject: FW: Deployment Review for Bandwidth Attributes Document
> >
> >
> >
> > Mick,
> >
> > FYI...  I don't think the traffic class mappings that 802.11e, WMM
> Wi-Fi
> > and 3GPP are recommending here are exactly what 802.1 had in mind -
do
> > you?  There is no provision for network control traffic.
> >
> > Paul
> >
> > -----Original Message-----
> > From: Bari, Farooq [mailto:farooq.bari@cingular.com]
> > Sent: Friday, September 16, 2005 9:39 AM
> > To: Bernard Aboba; Congdon, Paul T (ProCurve); Sabine Demel;
> > radiusext@ops.ietf.org
> > Subject: RE: Deployment Review for Bandwidth Attributes Document
> >
> > It would be useful to take into consideration the intention of other
> > forums/operators about the possible use of such mechanisms. I am
> > attaching an approved document from last week's 3GPP SA2 meeting.
Pls
> > see section 5.2.1 that indicates using such mechanisms in Rel 7
> > timeframe.
> >
> > BR,
> >
> > Farooq Bari
> > Cingular Wireless
> > Core Network Standards
> >
> > farooq.bari@cingular.com
> > +1 425 580 5526
> >
> > > -----Original Message-----
> > > From: owner-radiusext@ops.ietf.org
> > [mailto:owner-radiusext@ops.ietf.org] On
> > > Behalf Of Bernard Aboba
> > > Sent: Friday, September 16, 2005 9:21 AM
> > > To: Congdon, Paul T (ProCurve)
> > > Cc: radiusext@ops.ietf.org
> > > Subject: RE: Deployment Review for Bandwidth Attributes Document
> > >
> > > One way to move forward would be to revise the document in order
to
> > > increase buyin from the individuals who responded to the survey.
> > > In particular, wider buyin from IEEE 802.1 participants would be
> > > desirable.
> > >
> > > With IETF 64 and the  November IEEE 802 plenary occurring in the
> same
> > city
> > > (Vancouver, CA) one week apart, this might be a good opportunity
for
> > > cooperation.
> > >
> > >
> > > On Fri, 16 Sep 2005, Congdon, Paul T (ProCurve) wrote:
> > >
> > > >
> > > > Sounds to me like there is support, especially if we added a
> scheme
> > to
> > > > support the 802 traffic classes.  Avi and I have talked about a
> > simple
> > > > and optional way to do this without crossing the complexity
line.
> > It
> > > > would be good to know if this would satisfy Pat's needs.
> > > >
> > > > Paul
> > >
> > > --
> > > 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/>