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

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

Hi Bernard,

Bernard Aboba wrote:
> > Section 14.6.2 also mentiones that the User Priority Regeneration Table
> > is for a specific port. Hence, I guess you have to send one User
> > Priority Regeneration Table for each port and the User-Priority-Table 
> > attribute then has to appear more than once (and has to refer to the
> > respective port) in the Access-Accept.
>
>
> I'd assume that the User-Priority-Table attribute implicitly refers to 
> the NAS-Port attribute included in the Access-Request.  I don't think it 
> is appropriate for the RADIUS server to attempt to set the 
> User-Priority-Table attribute for another port (since that port might 
> not even be in use by a user within the RADIUS server's home realm).

That's a very good point.

I hope that it was indeed the intention to have this table per-port and 
also per-user. Section 14.6.2 does not give me this impression. 
Shouldn't Section 14.6.2 also mentions this aspect as well.

> > I think you just want to delete the usage of the  User-Priority-Table
> > attribute in the Access-Request.
>
>
> Unless someone can describe why this would be useful, you're probably 
> right.
>
> > It seems that you need to add a little bit more text to the draft to 
> > explain based on your response.
>
>
> A few paragraphs explaining the 802.1D model and how it would be applied 
> definitely seems in order.
>
> > I went throught the spec in more detail and I came to the following 
> > (probably tentative) conclusion.
> >
> > Section 6.3.9 (Frame Priority) gave some additional information:
> >
> > "The ability to signal user priority in IEEE 802 LANs allows user 
> > priority to be carried with end-to-end significance across a Bridged 
> > Local Area Network. This, coupled with a consistent approach to the 
> > mapping of user priority to traffic classes and of user priority to 
> > access_priority, allows consistent use of priority information, 
> > according to the capabilities of the Bridges and MACs in the 
> > transmission path."
> >
> > As such, the User Priority Regeneration Table has an impact to the QoS 
> > classes since they are essentially mapped to the traffic classes.
> >
> > However, a subsequent paragraph in the same section says:
> >
> > "Under normal circumstances, user priority is not modified in transit 
> > through the relay function of a Bridge; however, network management 
> > can control how user priority is propagated. Table 7-1 provides the 
> > ability to map incoming user priority values on a per-Port basis. By 
> > default, the regenerated user priority is identical to the incoming 
> > user priority."
> >
> > From my reading of the specification I wasn't quite sure what the big 
> > value of the User Priority Regeneration Table actually is, given the 
> > fact that you ideally do not want to modify the user priority values 
> > anyway.
>
>
> One potential usage might be to remap priorities of traffic sent at an 
> exchange point (e.g. unless ISP A has an arrangement with ISP B, then 
> ISP B's high priority traffic will be remapped to "best efforts" at the 
> exchange point).

Sounds good but does it fit a per-user specific remapping policy?

> > My previous understanding was wrong and hence I think that including 
> > the User-Priority-Table attribute to Accounting-Request messages does 
> > not make sense.
>
>
> OK.
>
> > There is an indirect relationship. Mapping a high user priority value 
> > of an incoming frame to a low user priority value obviously impacts 
> > the QoS treatement.
>
>
> Yes.

Ciao
Hannes

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