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

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

Hi Bernard,

thanks for your quick feedback. Please find some comments below:

Bernard Aboba wrote:
> > 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.

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.


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

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.

Maybe someone else knows the use cases better. I couldn't find it in the 
specification.

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

My previous understanding was wrong and hence I think that including the
User-Priority-Table attribute to Accounting-Request messages does not
make sense.

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

>  I 
> agree that it would not make much sense to do regeneration if you didn't 
> have a QoS goal in mind, though.
Also my opinion.

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

> > 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.
That's again my observation as well.

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