RE: Deployment Review for Bandwidth Attributes Document

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

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