[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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