Re: Review of draft-ietf-radext-vlan-02.txt

[Hannes Tschofenig <Hannes.Tschofenig@gmx.net>]

Hi Mauricio,

After the discussion I had with Bernard I thought that I understood the 
purpose and it was reasonable to me.

Here is a short summary of our discussion:

The User-Priority-Table is sent the Access-Accept and provides the 
mapping of the user priorities for each class. Semantically it provides 
something similar to DSCP remarking. The User-Priority-Table therefore 
does not need to be associated with data traffic (e.g., a particular 5 
tuple). It just maps one priority value to another one and that's fine.

The User-Priority-Table attribute relates to a particular port and since 
there is a one-to-one relationship between a port and a user it also 
relates to the user. This is the reason why this attribute is carried in 
RADIUS in the first place.

Ciao
Hannes

 Sanchez, Mauricio (ProCurve) wrote:
> I'm not sure what you're getting at here. User-Priority-Table does only
> affect the port-based priority settings and is not enforced on a
> per-user or per-session basis.
>
> MS
>
>
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> > Sent: Wednesday, April 05, 2006 1:07 AM
> > To: Hannes Tschofenig
> > Cc: Sanchez, Mauricio (ProCurve); Bernard Aboba; 
> > radiusext@ops.ietf.org
> > Subject: Re: Review of draft-ietf-radext-vlan-02.txt
> >
> > Hi Mauricio,
> >
> > another issue that came to my mind again was raised during 
> > the discussion with Bernard is that the User-Priority-Table 
> > is used for remapping of user priorities only according to 
> > the User Priority Regeneration table. The conclusion of our 
> > discussion was that your draft does not aim to attemp to 
> > associate the actual data traffic with the QoS classes.
> >
> > Ciao
> > Hannes
> >
> > Hannes Tschofenig wrote:
> >
> > > Hi Mauricio,
> > >
> > > thanks for responding to this issue. Please find my response below:
> > >
> > >
> > > > > > your new text proposal looks much better.
> > > > > >
> > > > > > You need to modify Section 3 as well:
> > > > > >
> > > > > > "
> > > > > > Access-   Access-  Access-  Access-    CoA-
> > > > > >  Request   Accept   Reject   Challenge  Req    #   Attribute
> > > > > >    0        0-1      0        0         0-1   TBD  
> > > > >
> > > > >
> > > > > User-Priority-Table
> > > > >
> > > > >
> > > > > > "
> > > > >
> > > > >
> > > > > Got it.   BTW, do you think that *any* of the attributes are 
> > > > > appropriate for inclusion in an Accounting-Request?
> > > >
> > > >
> > > >
> > > > An argument to allow these attributes in an 
> >
> > Accounting-Request is for
> >
> > > > forensic purposes.  The accounting server is already aggregating a
> > > > number of session characteristics (packet/byte counts) and allowing
> > > > attributes from the vlan draft would shed additional light 
> >
> > on the what
> >
> > > > specific services the user was consuming/using at a given 
> >
> > point in time.
> >
> > > Assume that you carry the User-Priority-Table within 
> >
> > Accounting-Request 
> >
> > > messages. Do you think that it provides information how 
> >
> > many packets are 
> >
> > > carried for each individual QoS class? Where is the 
> >
> > information that 
> >
> > > offers me the following info:
> > > - # packets/bytes for user priority 0
> > > ....
> > > - # packets/bytes for user priority 7
> > >
> > > Ciao
> > > Hannes
> > >
> > >
> > > > Cheers,
> > > > MS


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