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

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

Hi all,

I reviewed the draft and I came across a number of questions. I am 
referring only to the User-Priority-Table attribute.

The document defines a QoS provisioning and authorization solution based 
on traffic classes. These classes are defined in IEEE 802.1D.

The document does not describe the semantic when the User-Priority-Table 
attribute is included in the Access-Request. Section 1.3 talks about the 
provisioning semantic when included in the Access-Accept. I think it is 
necessary to describe the semantical difference between these two 
approaches.

How is the data traffic mapped to the QoS class? Which attribute carries 
this flow identifier? I think it is necessary to provide a description.

Why is the length of the value carried in the User-Priority-Table 
attribute 10 bytes long? (We are talking about 8 QoS classes, as I read 
from Annex G.) Why is the data type a string?

You seem to assume that the RADIUS server knows something about the link 
specific properties. I got the feedback that this is not appreciated for 
QoS. Here are two examples:

1) What happens if the RADIUS server receives the User-Priority-Table 
attribute in the Access-Request but it has only Y.1541 QoS classes 
stored in the user's profile? Do you assume that the RADIUS server is 
able to provide a mapping? Should the RADIUS server fail when it either 
does not understand the QoS classes or if it is unable to map them? 
Should the RADIUS client know what the RADIUS server understands?

2) Is the an applicability problem with provisioning in a roaming 
environment when the RADIUS server of my home network sends the 
User-Priority-Table attribute to the visited network which might be a 
IEEE 802.16e network? According to your description the RADIUS client 
would fail according to the description in Section 1.3.
Would it be necessary for the RADIUS client to indicate that it is 
attached to a IEEE 802.1D network with support for the QoS classes in 
order to allow the Access-Accept message to be meaningful?

How long is the authoriziation decision valid when the 
User-Priority-Table attribute in sent in the Access-Request?

Do you see a need to reflect the QoS decision in the interworking with 
accounting or RADIUS prepaid (e.g., cost of the reservation)?

Ciao
Hannes

PS: It might be good to find a few QoS experts for review of this 
document. I could try to find someone, if you want.


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