[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review of draft-ietf-radext-vlan-02.txt
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
Since there is some confusion on that point, I think the answer is probably
"yes". I also think there may be more text required to specify exactly
what 802.1D management elements this corresponds to.
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
I think that the correct reference may be Section 7.5.1 ("Regerating User
Priority"). Annex G just provides some general background information.
Table 7.1 specifies the default values of the User Priority Regeneration
Table (no change). Clause 14.6.2 talks about modification of the default
values by management. My assumption is that the User-Priority-Table
attribute sent in an Access-Request would be the default in Table 7.1,
absent changes via management.
Why is it 8 bytes long?
Clause 220.127.116.11.3 specifies the regeneration table as 8 values, each an
integer in the range of 0-7.
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.
Personally, I'm not clear what a RADIUS server would do with it; unless
it's been modified by management it is a known quantity (e.g. the default).
It seems that you need to add a little bit more text to the draft to
explain based on your response.
I think so. This would include:
a. References to specific sections of 802.1D, explaining how this attribute
relates to existing management objects.
b. Discussion of the semantics of inclusion in Access-Request (if this is in
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
As far as I can tell, the regeneration table doesn't assign traffic to a
specific QoS class, it just remaps it. This isn't based on filters, but
just on the incoming markings. Obviously this is not a very sophisticated
Furthermore, you need to add the User-Priority-Table attribute to
Without a description which traffic experiences the QoS treatment the
entire stuff does not make sense.
I think that regeneration is a separate issue from QoS treatment. I agree
that it would not make much sense to do regeneration if you didn't have a
QoS goal in mind, though.
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.
Regeneration is a kind of remapping (though not a sophisticated one).
This raises the question why you cannot just have a generic description
with a set of QoS parameters.
Clearly that would be useful, but I think it is outside the scope of what
the regeneration table is attempting to achieve.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.