Subject: Some comments on draft-winter-radext-fancyaccounting-00

From: Jacni Qin <[email-masked]>
Date: Wed, 27 Apr 2011 14:18:09 +0800

Dear Stefan & all,

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.

* For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall we
"re-use" the type specified in RFC2866, like 245.1.47, etc.

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

Or, I can propose some text if you want.

Cheers,
Jacni

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Apr 2011 09:01:04 +0200

Jacni Qin wrote:
> * For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall
> we "re-use" the type specified in RFC2866, like 245.1.47, etc.

  I would strongly recommend not doing that.  Re-using the type would
lead people to conclude that the type space for TLVs is the same as the
type space for "normal" RADIUS attributes.  This is not the case.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Stefan Winter <[email-masked]>
Date: Wed, 27 Apr 2011 11:39:28 +0200

Hi,

> type space for "normal" RADIUS attributes.  This is not the case.

Also, the data types used here are actually *different* (64 bit
integer). Giving them the same number as an already existing attribute
with a mismatching data types invites sloppiness errors in implementations.

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

---

From: Stefan Winter <[email-masked]>
Date: Wed, 27 Apr 2011 11:52:40 +0200

Hi,

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

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.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Peter Deacon <[email-masked]>
Date: Wed, 27 Apr 2011 10:34:30 -0700 (Pacific Daylight Time)

There is sometimes confusion (For me anyway) regarding what counters 
actually count.  Traditionally Input/Output octets are protocol agnostic 
and just count low layer bits shuffled between interfaces.

Lets say we run IPv6 over PPP or Ethernet do the byte counts apply only to 
the higher layer IP frames and not a lower layer ethernet or PPP frame?

Alternately if there was a traffic class for even higher layer messages such 
as HTTP..does it count the HTTP layer only or the IP header and possibly 
ethernet/PPP header?

I don't really have an opinion on the behavior only that it would be best 
if all implementations stand a good chance of counting the same way.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 28 Apr 2011 12:30:14 +0200

Peter Deacon wrote:
> Lets say we run IPv6 over PPP or Ethernet do the byte counts apply only
> to the higher layer IP frames and not a lower layer ethernet or PPP frame?

  I'd say it's still bits over the interface, including ethernet or PPP.

> Alternately if there was a traffic class for even higher layer messages
> such as HTTP..does it count the HTTP layer only or the IP header and
> possibly ethernet/PPP header?

  We can define traffic classes for all of that, I think.

> I don't really have an opinion on the behavior only that it would be
> best if all implementations stand a good chance of counting the same way.

  The specification needs to be clear on what is being counted.  It
would help to have specific examples of this in the doc.

  e.g. If the description is "HTTP traffic on port 80", then the data
being counted should be *only* HTTP, not lower-layer TCP, IP, etc.

  Alan DeKok.

---

From: Jacni Qin <[email-masked]>
Date: Sun, 1 May 2011 08:32:42 +0800

Re-,

Ok, I got your point.

Cheers,
Jacni

---

From: Jacni Qin <[email-masked]>
Date: Sun, 1 May 2011 08:36:19 +0800

hi,

Sorry for my late reply,

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

> 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