[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review of draft-ietf-radext-vlan-02.txt
Hi Bernard,
thanks for the quick response. Please find some comments below:
Bernard Aboba wrote:
The document does not describe the semantic when the
User-Priority-Table attribute is included in the Access-Request.
I was also a bit puzzled by this. Presumably the switch sends the
default configuration, but I am not sure.
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.
The document says that the attribute when included in the Access-Request
is a "hint". So I don't think that there is any provisioning going on
in the Access-Request.
Do you think it would be useful to provide more description of what the
semantic of the User-Priority-Table attribute in the Access-Request or
the Access-Accept means?
I know you as someone that wants to describe the behavior in great detail.
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.
My understanding is that we are only talking about remapping of priority
bits that are already set on inbound, and that this is described in IEEE
802.1D.
What type of remapping of priority bits do you have in mind?
Note that the reference to Annex G in the draft is a bit misleading
since this section of the IEEE 802.1D spec just gives the rational
behind the selection of the traffic classes based on the number of
queues being available.
Why is the length of the value carried in the User-Priority-Table
attribute 10 bytes long?
It isn't. RADIUS includes the type and length fields in the total
length, so it's 8 bytes long.
Why is it 8 bytes long?
You seem to assume that the RADIUS server knows something about the
link specific properties.
The document specifies attributes for use with IEEE 802 networks.
Information on the specific link type is provided in the NAS-Port-Type
attribute.
That's something you might want to mention in the document.
I think you just want to delete the usage of the User-Priority-Table
attribute in the Access-Request.
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?
Since this would be a hint, I presume the server is free to ignore it.
Do you assume that the RADIUS server is able to provide a mapping?
Since it's a hint, I wouldn't think so. The RADIUS server isn't
compelled to include the User-Priority-Table attribute in the
Access-Accept.
Should the RADIUS server fail when it either does not understand the
QoS classes or if it is unable to map them?
It is possible that implementations may not react well to the hint, but
if they do understand the hint, they shouldn't fail because they don't
return a User-Priority-Table in the Access-Accept.
Should the RADIUS client know what the RADIUS server understands?
I think that is only important if RADIUS servers won't react well to the
hint. If servers don't send the attribute, the client probably won't care.
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?
Presumably the attribute will only be sent if the NAS-Port-Type
attribute indicates that it would be useful. 802.16k implements
bridging, but 802.16e does not, so I don't think it would make sense to
send this attribute to a RADIUS client running 802.16e. However, it
appears there is no NAS-Port-Type for 802.16e, 802.16k, 802.20, etc.
There probably should be.
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?
The NAS-Port-Type attribute should provide this information.
How long is the authoriziation decision valid when the
User-Priority-Table attribute in sent in the Access-Request?
Presumably until the expiration of Session-Timeout.
Do you see a need to reflect the QoS decision in the interworking with
accounting or RADIUS prepaid (e.g., cost of the reservation)?
The attributes are not indicated to be sent in Accounting-Request
packets, but perhaps they should be.
It seems that you need to add a little bit more text to the draft to
explain based on your response.
Let me explain what I would do with the description of this specific
attribute:
The User-Priority-Table attribute is only used in the Access-Accept (and
not in the Access-Request). You need to specify which traffic is
assigned to a specific QoS class. Therefore, you need to add the
NAS-Traffic-Rule. You need to add a normative reference to
draft-ietf-radext-filter-rules-00.txt.
Furthermore, you need to add the User-Priority-Table attribute to
Accounting-Request messages.
Without a description which traffic experiences the QoS treatment the
entire stuff does not make sense.
From a semantic point of view this is very similar to a DiffServ
traffic marking. Here the rules for traffic marking is stored at the AAA
server.
This raises the question why you cannot just have a generic description
with a set of QoS parameters. For IEEE 802.16e you would have to go
through the same description just with different QoS parameters. The
same for DiffServ, IntServ CL/GS, Y.1541, etc.
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/>