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

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

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

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

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

Indeed.

> 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 
fact required)


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

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

> Furthermore, you need to add the User-Priority-Table attribute to 
> Accounting-Request messages.

Probably.

> 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>