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

["Bernard Aboba" <bernard_aboba@hotmail.com>]

> 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).

> 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).

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



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