On Wed, Apr 27, 2011 at 5:52 PM, Stefan Winter
<stefan.winter@restena.lu> wrote:
Hi,
> I skimed the draft and got some comments, see below please.
>
> * "Section 2.2.1.Acct-Traffic-Class-Id attribute" seems to be
> redundant, I perfer to only keep the Name attribute which is STRING
> formatted and defined by BNG (configurable). The traffic classes are
> specified based on the capability of the BNG. No further IANA
> activities are needed in the future.
It's true that any value expressed in -Id could also be formulated in a
string in -Name. However, naming conventions for the string are likely
to differ, so I would prefer to have controlled vocabulary at least for
more common use cases - like DSCP classes or IP versions, as in the draft.
Jacni>: While we opened the door in this way for additional IANA
activities. I have a fear that everytime we will need to request a value for -id,
then give the recommended definition of -name accordingly, and vise versa? ;-)
Another option would be to follow Alan's comment regarding
NAS-Filter-Rule naming. I'm not much of fan of this, because the first
examples which came to my mind: IP versions, DSCP values, don't sit
together in IPFilterRule (which is the basis for NAS-Filter-Rule). Only
IP versions could be expressed as a filter with NAS-Filter-Rule, but
DSCP is a Diameter QoSFilterRule - which can't be expressed in
NAS-Filter-Rule (I'll be happy to be corrected if I'm wrong here).
> * An attribute similar to Type#44 Acct-Session-Id is necessary, since
> this is widely implemented in practice, for example, as an
> identification of user for policy changes initiated by AAA server.
> Name it "Acct-Traffic-Class-Id"? But the value should be a random
> number assigned by BNG. Some other attributes may also need to be
> considered.
The example in the draft only shows a fragment of the entire Accounting
packet. The Accounting packet will be able to contain the
Acct-Session-Id, and then additionally one or more groups of
Accounting-Traffic-Group.
I don't see an issue with that unless one would want to have different
session Id's for different traffic groups in the same accounting ticket
- but I have a hard time thinking of a reason for that; after all all
the counted Octets and Packets belong to the same user session, and can
thus share the same session id.
Jacni>: For example, two clasess v4 and v6, over single access service,
there may be cases that the dynamic QoS or bandwidth policy changes (class-specific)
are requested by users,say, through portal, then initiate/executed by the server side, the
-id is needed.
Cheers,
Jacni
Greetings,
Stefan Winter
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax: +352 422473