Subject: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt

From: Stefan Winter <[email-masked]>
Date: Thu, 12 Jul 2012 10:19:31 +0200

Hello,

since the interest on the topic of RADIUS Accounting for subsets of the
total traffic has risen again, I have revived my old, expired -00
version of "fancyaccounting". The major change to -00 is that I drop the
enumerated integer as a means to express which traffic is counted, and
use only the string type instead.

Realising that a known vocabulary of traffic classes is useful for
inter-op between ISPs, I introduced an - optional - fixed syntax for
specific accounting traffic classes by using URNs. Among those is, of
course, IPv6, as this was the original trigger for the accounting
traffic class discussion.

The advantage of the URN/freetext model is that it can be expanded
arbitrarily and yet have a defined meaning; while still allowing a local
admin to count "whatever" by choosing not to use a URN. I would like to
thank Klaas Wierenga for his inspiration in that regard!

The other changes are cleanups (move of Integer64 to radius-extensions)
and tighter semenatic requirements of when to send what; including a way
to express which bytes exactly to count - a suggestion I got some 2
years ago when discussing -00.

This is an individual submission which is in sort of a competition with
draft-yeh-radext-ext-traffic-statistics. This is the consequence of
Leaf's decision to first suggest numerous other, inferior, approaches,
and then, when these were repelled, copying the approach from my -00
with slightly different wording with his name as the author;
unsurprisingly, the two drafts are now very close to each other. I
believe my draft is more thorough and thought-out in many aspects. The
only difference is that his draft has an integer enumerator for traffic
classes, while my draft uses a string. The string can do the same
well-defined enumeration of known traffic classes that the integer can
also do, and more.

If the re-charter with an explicit mention of "RADIUS Accounting
Extensions for Traffic Statistics" gets adopted, I would like to suggest
adopting my draft for that topic.

Greetings,

Stefan Winter

-------- Original Message --------
Subject: New Version Notification for
draft-winter-radext-fancyaccounting-01.txt
Date: Thu, 12 Jul 2012 01:16:54 -0700
From: [email-masked]
To: [email-masked]

A new version of I-D, draft-winter-radext-fancyaccounting-01.txt
has been successfully submitted by Stefan Winter and posted to the
IETF repository.

Filename:	 draft-winter-radext-fancyaccounting
Revision:	 01
Title:		 RADIUS Accounting for traffic classes
Creation date:	 2012-07-12
WG ID:		 Individual Submission
Number of pages: 9
URL:
http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting-01.txt
Status:
http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting
Htmlized:
http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01
Diff:
http://tools.ietf.org/rfcdiff?url2=draft-winter-radext-fancyaccounting-01

Abstract:
   This document specifies new attributes for RADIUS Accounting to
   enable NAS reporting of subsets of the total traffic in a user
   session.

The IETF Secretariat

---

From: Stefan Winter <[email-masked]>
Date: Thu, 12 Jul 2012 10:19:31 +0200

Hello,

Greetings,

Stefan Winter

-------- Original Message --------

Abstract:

The IETF Secretariat

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Peter Deacon <[email-masked]>
Date: Thu, 12 Jul 2012 02:38:53 -0700 (Pacific Daylight Time)

> traffic class discussion.

I like the new accounting draft -- simple and flexible.

Some thoughts..

There might be cases where not all Packet and Octet information is known 
or provided.  For example counting bytes over a serial line or higher 
layer where packet counts may no longer be known, applicable or 
accessible.

Suggest changing 'exactly once' to zero or one for Packets and Octets 
fields.
--

If you can count it people are going to want to enforce it.  Using interim 
accounting and dynamic auth is a practical option however leakage is 
unavoidable.

Perhaps a separate container group to signal limits via Access-Accept 
enforced by NAS:

Limit-Traffic-Class
Limit-Traffic-Class-Name
Limit-Traffic-Class-Input-Octets
Limit-Traffic-Class-Output-Octets

'd volunteer text if theres interest and this is not too much scope creep.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Thu, 12 Jul 2012 02:38:53 -0700 (Pacific Daylight Time)

Some thoughts..

Limit-Traffic-Class
Limit-Traffic-Class-Name

regards,
Peter

---

From: Leaf yeh <[email-masked]>
Date: Thu, 12 Jul 2012 11:42:56 +0000

Stefan - This is an individual submission which is in sort of a competition with draft-yeh-radext-ext-traffic-statistics. 

Welcome debate or competition on the same topic: RADIUS Accounting Extensions for Traffic Statistics. Hope the WG could figure out the solution on this topic soon. The problem looks not so difficult.

Stefan - This is the consequence of Leaf's decision to first suggest numerous other, inferior, approaches, and then, when these were repelled, copying the approach from my -00 with slightly different wording with his name as the author; unsurprisingly, the two drafts are now very close to each other. 

History on this topic in my memory for your correction:
1.  draft-yeh-radext-dual-stack-access-00 (2011-3-7) put forward the topic & 1st solution of RADIUS Accounting Extensions for Traffic Statistics for dual stack, and presented in IETF80;
2.  After IETF80 Radext session, draft-winter-radext-fancyaccounting-00 (2011-3-31) put forward the 2nd solution of TLV with extended-type space;
3.  draft-yeh-radext-dual-stack-access-02 expired in 2011-09-30
4.  draft-winter-radext-fancyaccounting-00 expired in 2011-10-02
5.  The IETF82 presentation (http://www.ietf.org/proceedings/82/slides/radext-2.pdf ) with draft-yeh-radext-ext-traffic-statistics-01 re-triggered the discussion on the attribute design of Acct-Traffic-Statistics;
6.  After got the hint in the meeting minutes of Radext IETF82 (http://www.ietf.org/mail-archive/web/radext/current/msg07489.html ), I asked for the cooperation with Stefan on this topic several times, but it looks to bump;
7.  After the discussion on the mailing list of Radext, draft-yeh-radext-ext-traffic-statistics-02 adopted the date type of nesting-TLV;
8.  Around more than 1 week before I submitted draft-yeh-radext-ext-traffic-statistics-03, I asked Stefan for his revision and cooperation on my draft again, but failed.

Stefan - I believe my draft is more thorough and thought-out in many aspects. The only difference is that his draft has an integer enumerator for traffic classes, while my draft uses a string. 

The above 2 statements sounds contradictory.

Stefan - The string can do the same well-defined enumeration of known traffic classes that the integer can also do, and more.

This sounds something real on the aspect of technology or Radius attribute design, which asks for the discussion within the WG.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Winter
Sent: Thursday, July 12, 2012 4:20 PM
To: [email-masked]
Subject: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt

Hello,

since the interest on the topic of RADIUS Accounting for subsets of the total traffic has risen again, I have revived my old, expired -00 version of "fancyaccounting". The major change to -00 is that I drop the enumerated integer as a means to express which traffic is counted, and use only the string type instead.

Realising that a known vocabulary of traffic classes is useful for inter-op between ISPs, I introduced an - optional - fixed syntax for specific accounting traffic classes by using URNs. Among those is, of course, IPv6, as this was the original trigger for the accounting traffic class discussion.

The advantage of the URN/freetext model is that it can be expanded arbitrarily and yet have a defined meaning; while still allowing a local admin to count "whatever" by choosing not to use a URN. I would like to thank Klaas Wierenga for his inspiration in that regard!

The other changes are cleanups (move of Integer64 to radius-extensions) and tighter semenatic requirements of when to send what; including a way to express which bytes exactly to count - a suggestion I got some 2 years ago when discussing -00.

This is an individual submission which is in sort of a competition with draft-yeh-radext-ext-traffic-statistics. This is the consequence of Leaf's decision to first suggest numerous other, inferior, approaches, and then, when these were repelled, copying the approach from my -00 with slightly different wording with his name as the author; unsurprisingly, the two drafts are now very close to each other. I believe my draft is more thorough and thought-out in many aspects. The only difference is that his draft has an integer enumerator for traffic classes, while my draft uses a string. The string can do the same well-defined enumeration of known traffic classes that the integer can also do, and more.

If the re-charter with an explicit mention of "RADIUS Accounting Extensions for Traffic Statistics" gets adopted, I would like to suggest adopting my draft for that topic.

Greetings,

Stefan Winter

-------- Original Message --------

A new version of I-D, draft-winter-radext-fancyaccounting-01.txt
has been successfully submitted by Stefan Winter and posted to the IETF repository.

Abstract:

The IETF Secretariat

---

From: Leaf yeh <[email-masked]>
Date: Thu, 12 Jul 2012 11:42:56 +0000

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Winter
Sent: Thursday, July 12, 2012 4:20 PM
To: [email-masked]
Subject: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt

Hello,

Greetings,

Stefan Winter

-------- Original Message --------

Abstract:

The IETF Secretariat

---

From: Stefan Winter <[email-masked]>
Date: Thu, 12 Jul 2012 15:32:03 +0200

> Welcome debate or competition on the same topic: RADIUS Accounting Extensions for Traffic Statistics. Hope the WG could figure out the solution on this topic soon. The problem looks not so difficul…

Indeed. The main question seems to be: should the format be extensible
to support arbitrary accounting needs? Or should it be limited to a few
fixed values, centrally managed by the IETF?

I argue for the first, you for the second.

> 8.  Around more than 1 week before I submitted draft-yeh-radext-ext-traffic-statistics-03, I asked Stefan for his revision and cooperation on my draft again, but failed.

Thanks for this timeline - it perfectly proves my point. The TLV
structure was first introduced in your point 2 by me. It reappeared in
point 7. - This time, the author was you, while the concept was the same.

The fact that you repeatedly put up slides in the time between 2 and 7
which were calling the TLV approach "design 3" does not mean it was your
idea and design. The draft, idea and structure were there long before
you did that.

In that light, isn't it understandable that I don't fancy becoming a
co-author of "your" draft with you as an editor?

If that's not a sufficient justification for me being upset, here's
another one: following IETF80, I created fancyaccounting-00 because I
was trying to *help* you - you presented a good problem statement, and I
had an easy solution in my mind. And yet, when I uploaded it *and* got
positive feedback from the WG, you indicated that you are not interested
in the topic in a subsequent meeting, making it all stall. That is not nice.

That's my only reply on that topic. Spending time uselessly arguing on
off-topic aspects doesn't contribute to a solution.

> The above 2 statements sounds contradictory.

Not at all. My previous mail contained reasons and argument why I did
it, and it enumerated why it is a good idea.

Your reply conveniently cuts out these, and doesn't present
counter-arguments against them. You just state you don't like it. Too bad.

> This sounds something real on the aspect of technology or Radius attribute design, which asks for the discussion within the WG.

Indeed.

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: Thu, 12 Jul 2012 15:32:03 +0200

Indeed.

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Thu, 12 Jul 2012 15:49:52 +0200

Hi,

> I like the new accounting draft -- simple and flexible.

Thanks :-)

> layer where packet counts may no longer be known, applicable or accessible.
> 

That's a good point. I'll change the text accordingly.

One Q about "no longer be known" - I don't know any usage patterns that
would lead to a value getting "lost" during a session.

A concern of mine was that a NAS might send a value in an
Interim-Update, but then not report the same type of data in the Stop
packet.

I considered that a very bad thing, as it leaves the RADIUS server with
the open question on what happened to this type of traffic since the
last update. That's why I added text in the occurence table that
requires once-sent values to be sent in the final Stop ticket, too.

If values stop being known mid-session, is that then an unreasonable
requirement?

> If you can count it people are going to want to enforce it.  Using
> interim accounting and dynamic auth is a practical option however
> leakage is unavoidable.
> 

This part I'm not so comfortable with - at least in the scope of the
current draft. I see Accounting as a one-way flow from the NAS to the
RADIUS server to report about the current reality of a user session.

Undoubtedly, being able to send Time or Data limits from the RADIUS
server to the NAS is also useful, but it's a different topic IMHO, worth
its own draft.

However, if the WG thinks that this should be in the scope of this
document, I'll be happy to add your text.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Thu, 12 Jul 2012 15:49:52 +0200

Hi,

Thanks :-)

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Peter Deacon <[email-masked]>
Date: Thu, 12 Jul 2012 10:35:44 -0700 (Pacific Daylight Time)

> If values stop being known mid-session, is that then an unreasonable

Agree.  I think at point where a class or any sub-attribute of the class 
appears in an interim it should be required to be sent in all subsequent 
interims and stop record.  Forgetting should not be an option.

Allowing any counter data to disappear or reset is ambiguous as to how the 
lack of information is interpreted.  Especially difficult for backend 
systems providing near realtime costing of usage.

> document, I'll be happy to add your text.

Pretty please WG :)

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Thu, 12 Jul 2012 10:35:44 -0700 (Pacific Daylight Time)

Pretty please WG :)

regards,
Peter

---

From: Leaf yeh <[email-masked]>
Date: Fri, 13 Jul 2012 04:17:53 +0000

> Stefan - The string can do the same well-defined enumeration of known traffic classes that the integer can also do, and more.

<quote>Section 2.1.1 - Option 1: Acct-Traffic-Class-Name string starting with the substring
"urn:". Usage of this option implies that the traffic name is in the
form of a URN and requires that a public specification of this URN
exists. That specification must include the type of traffic being
counted with this traffic class, and the exact definition of where in
the network packets the byte-count starts and ends. </quote>

The sub-attribute, Acct-Traffic-Class-Name, here sounds create a new data type of string with additional specification. And the method of 'URN' does not really get advantages over the enumeration codes defined in  sub-attributes of the draft-yeh-radext-ext-traffic-statistics-03. I mean the enumeration problem of traffic type is still there, but introduced a more new type of string parser for this specified data type. Then the question will be why we need this kind of complexity to solve the same problem.

<quote>Option 2: Acct-Traffic-Class-Name string not starting with "urn:".
This option is for local use of special-purpose accounting as defined
by the NAS administrator, where no defined URN matches the meaning of
the traffic to be counted. The meaning of the content needs to be
communicated out-of-band between the NAS and RADIUS Server operator.
Example: Acct-Traffic-Class-Name = "UDP traffic to AS2606". </quote>

The 'non-urn' string sounds opaque or un-readable to the machine as the usual string. Right?
What kind of the out-of-band means will be needed for the data interpretation in the string? This also sounds new complexities.

Stefan - The main question seems to be: should the format be extensible
to support arbitrary accounting needs? Or should it be limited to a few
fixed values, centrally managed by the IETF?

a. Nesting-TVL with its sub-attributes does not mean that it can't be extensible in the future to define new sub-attribute for the necessary provisioning scenario. 
b. Fixed and extensible. To make a proposed standard managed by IETF is why we come here. Right?

Stefan - Spending time uselessly arguing on
off-topic aspects doesn't contribute to a solution.

Agreed. I suggest to ask the chairs to solve the argument between us. OK?

Best Regards,
Leaf

________________________________________
From: [email-masked] [[email-masked]] on behalf of Stefan Winter [[email-masked]]
Sent: Thursday, July 12, 2012 21:32
To: [email-masked]
Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt

Indeed.

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Leaf yeh <[email-masked]>
Date: Fri, 13 Jul 2012 04:17:53 +0000

Best Regards,
Leaf

Indeed.

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Fri, 13 Jul 2012 18:09:34 +0200

Hi,

> The sub-attribute, Acct-Traffic-Class-Name, here sounds create a new data type of string with additional specification. And the method of 'URN' does not really get advantages over the enumeration codes defined in  sub-attributes of the draft-yeh-radext-ext-traffic-statistics-03.

It's very obvious advantage is flexibility.

Your integer is limited to IETF actions if new values are to be
assigned. That is at least my guess, your draft does not say anything
about how new values in this enum are assigned. I.e. your draft is
underspecified in that aspect.
Even in your own draft, the shortcomings of that approach are obvious:
for DSCP, you created a whole new attribute!

With the string, there is indeed one space of controlled vocabulary,
it's the "urn:ietf:radius-accounting:" prefix. But: if vendors have
their own NASes with more fine-grained reporting abilities than just "IP
version" or "DSCP value", they can define these in their own URN tree
and merrily use them - without any intervention of the IETF required.

This is the exact same approach that is used for RADIUS attributes in
general: there are IETF attributes, and there are Vendor-Specific ones.

The analogy should be pretty obvious to see. I hope you are not going to
argue about the usefulness of VSAs; they have done a lot of good in the
last decades. Following that path sounds rather logical to me.

> I mean the enumeration problem of traffic type is still there, but introduced a more new type of string parser for this specified data type. Then the question will be why we need this kind of complexity to solve the same problem.

What extra parser are you talking about? It's a string, and it has a
value. A NAS can act very simply with that: if it is supposed to report
on IPv6 volumes, it puts the literal string

"urn:ietf:radius-accounting:ip:6"

into the attribute. A RADIUS server which is curious whether it got any
IPv6 volume statistics makes a simple equality check on incoming
Acct-Traffic-Class-Name attributes:

if ( Acct-Traffic-Class-Name == "urn:ietf:radius-accounting:ip:6" ) {
	do fancy stuff with IPv6 data;
}

An equality check is just about the simplest parser I can imagine. You
draft would need to compare integers, too.

> The 'non-urn' string sounds opaque or un-readable to the machine as the usual string. Right?

That's right. A RADIUS server can still be configured by the admin to
log them in a defined way if he so wants, using the same equality checks
as above.

> What kind of the out-of-band means will be needed for the data interpretation in the string? This also sounds new complexities.

In small environments, the NAS admin is also the RADIUS Server admin.
There is no complexity.

In larger environments, human communication between NAS admin and RADIUS
admin by a communication means of your choice needs to take place. For
example an e-mail

"
From: NAS Admin
To: RAIDUS Server admin
Subject: traffic counter installed!

Dear RADIUS Server admin,

you asked me to configure our NASes to report on the amount of UDP
traffic sent to AS2602, to find out who the guy is who swamps our
backbone with source-address-faked UDP packets. Just to let you know, I
configured that 5 minutes ago; the NASes will use the
Acct-Traffic-Class-Name label "UDP->AS2602" in their accounting records.
Hope you'll catch him!

Best regards,

Your NAS Admin"

Or Jabber. Or POTS. Or whatever you like.

Of course this does not scale; it's not very useful beyond enterprise
borders. For these, a proper definition and - guess what - a URN value
would be used to formalise things.

If that approach is seen as too liberal (I can sort of understand that),
the draft can be changed to limit itself to option 1 only (urn: prefix
MUST be used).

That would still allow non-IETF groups to define their own filters. What
I don't like about it is that some people *will* ignore the requirement
and send arbitrary strings anyway - so why not spell out that
possibility explicitly. It is certainly the most painless way for little
enterprises which couldn't be bothered to make their own URN registry.

> b. Fixed and extensible. To make a proposed standard managed by IETF is why we come here. Right?

Again, you prove my point with your own draft.

As per your draft, "extensible" means that a new RFC needs to be
written, a new attribute defined, new ENUM values specified. For
*everything*. One example is DSCP. Funny thing is, I don't care much
about DSCP. I only used it as an example of something people *might
want*. Your reaction is that the draft needs a new attribute to carry
the DSCP values.

Whereas as per my draft, "extensible" means that if an organisation or
individual has its own idea about what it wants to get stats about, it
can just carry on and do it. And if that thing to report about proves to
be interesting enough for the IETF to care, *then* can it be blessed by
putting it into the IETF URN tree. Again, very similar to VSAs.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Fri, 13 Jul 2012 18:09:34 +0200

Hi,

"
From: NAS Admin
To: RAIDUS Server admin

Best regards,

Your NAS Admin"

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Dave Nelson <[email-masked]>
Date: Fri, 13 Jul 2012 15:05:23 -0400

I haven't read the (competing?) drafts in a while, but one issue in your
most recent mail caught my attention.

What's the fundamental difference between a string type encoding using an
(unregistered) user-private URN namespace and a Vendor Specific Enumeration
for an integer type?  The latter is an officially discouraged technique, in
the RADIUS Design Guidelines, as I recall.

Flexibility for small users, who can't be bothered with managed namespaces
and codepoints is all well and good, but it seems to me that the purpose of
doing work in the IETF is to guarantee a high level
multi-vendor interoperability by formally defining such things.  No?

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Dave Nelson <[email-masked]>
Date: Fri, 13 Jul 2012 15:05:23 -0400

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Alan DeKok <[email-masked]>
Date: Fri, 13 Jul 2012 22:47:07 -0400

> use only the string type instead.

  I have concerns with that.

> traffic class discussion.

  RFC 4849 defines the NAS-Filter-Rule attribute. It's based on the
RFC3588 IPFilterRule, which is in turn largely FreeBSD firewall rules.

  Why not just leverage that?  There's no need to have a new registry
(string or integer) for traffic classes.  Instead, just describe the
traffic by the filter rules it matches.

  That allowss for nearly unlimited flexibility, without creating any
new standard or registry.

> adopting my draft for that topic.

  I would like a discussion around the definition of traffic classes.
But the document is largely OK for me.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 13 Jul 2012 22:47:07 -0400

Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 Jul 2012 08:12:40 -0400

>> Interim-Update, but then not report the same type of data in the Stop

  Such NASes should be burned with fire.

> interims and stop record.  Forgetting should not be an option.

  I agree.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 Jul 2012 08:12:40 -0400

I agree.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 Jul 2012 08:17:52 -0400

> RADIUS server to report about the current reality of a user session.

  While I agree it's useful, I think it should be out of scope of the
accounting document.

  I agree.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 Jul 2012 08:17:52 -0400

I agree.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sat, 14 Jul 2012 22:52:31 -0700 (Pacific Daylight Time)

> new standard or registry.

Rules for production of accounting class data are configured OOB from 
RADIUS.  It is not known what the NAS will choose as the basis for 
classification.  It may choose to count non-IP flows or high level 
protocol exchanges.  Either of which are impossible to describe using NAS 
filter rules.

More importantly abstraction to set a named label in the NAS correlating 
to a counting goal in the accounting system is an important feature 
operationally as each NAS could have different filters to implement the 
same overall goal which may not be understood by accounting.

For example I want to operate a roaming network using fancy accounting to 
count local traffic separately from traffic sent over the WAN.  Each 
operator of each NAS defines what is local to itself.  Two classes of 
attributes are sent "local" and "network".

If you were to simply upload classes with filter rules the accounting 
systems of participants would be clueless to interpret what any of the 
filter definitions actually do as they only have meaning within the 
administrative domain of each NAS operator.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Sat, 14 Jul 2012 22:52:31 -0700 (Pacific Daylight Time)

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Sun, 15 Jul 2012 17:41:15 -0400

Peter Deacon wrote:
> classification.

  Then how can the accounting data be interpreted?

>  It may choose to count non-IP flows or high level
> protocol exchanges.  Either of which are impossible to describe using
> NAS filter rules.

  Both of those use-cases have a much smaller deployment than simple IP
accounting.

> For example I want to operate a roaming network using fancy accounting
> to count local traffic separately from traffic sent over the WAN.  Each

  How are these classes communicated to the other parties in the network?

> administrative domain of each NAS operator.

  Really?  "tcp port 80" ?

  Or "ignore 10/8, 192.168/16, everything else is external, and billed
as such".

  There are *some* cases where NAS filter definitions should be kept
locally.    There are *more* cases where they can be shared, and can be
understood by other parties.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 15 Jul 2012 17:41:15 -0400

Really?  "tcp port 80" ?

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sun, 15 Jul 2012 17:47:51 -0700 (Pacific Daylight Time)

>  Then how can the accounting data be interpreted?

The same way it was configured at the NAS in the first place - by out of 
band agreement.

Only difference a label rather than the entire configuration subject to 
arbitrary change by manual or automatic means must also be duplicated in 
accounting.

>  Both of those use-cases have a much smaller deployment than simple IP

Plenty of folk using RADIUS for CLI, SIP, Email..etc.  No sense excluding 
anyone.

>  How are these classes communicated to the other parties in the network?

See above.  In this example likely by convention agreed by all 
participants.

>  Or "ignore 10/8, 192.168/16, everything else is external, and billed

What happens when RFC 1918/ULA addresses are not used?  What happens when 
local means within an IGP or attachment to named interfaces?  Can this 
even be defined using filter syntax?  Classes derived from PBR or 
exclusions for local CDN traffic?

This does not seem like an unfair or academic question to me.  Plenty of 
NASes have global addresses.  With IPv6 deployment plenty more will.

Expecting accounting systems to have access to configurations of the 
network to interpret the intention of filter gooblygook even in the case 
those systems are within the same administrative domain is not realistic.

> understood by other parties.

I disagree. Everything can be accomplished with the use of labels.  The 
same is not true where filter definitions lacking comments are used.

It was already configured once or perhaps thousand of different times by 
separate configurations in each NAS in the system.  Why is it a good idea 
to also have to duplicate and manage those details in accounting rather 
than providing a pointer to them with the use of labels?

This reminds me of taking a router full of ACLs, removing all comments and 
then trying to stump the network guy by asking why a random ACL in the 
list is there.

Sure anyone can tell you what it does but knowing what it is for is a 
different matter entirely... this is precisely the question accounting is 
being asked to answer.

The cost of requiring an accounting system to have to reverse engineer the 
*intent* of an ACL is nontrivial.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Sun, 15 Jul 2012 17:47:51 -0700 (Pacific Daylight Time)

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Sun, 15 Jul 2012 21:06:10 -0400

> The same way it was configured at the NAS in the first place - by out of

  Having worked in roaming consortium, that's hard.  Having a
computer-readable format is very useful

> Plenty of folk using RADIUS for CLI, SIP, Email..etc.  No sense
> excluding anyone.

  People do accounting for data to/from the CLI of a NAS?  Really?

  And SIP, Email, etc. can all be describe with the NAS filter rule syntax.

> What happens when RFC 1918/ULA addresses are not used?  What happens
> when local means within an IGP or attachment to named interfaces?  Can
> this even be defined using filter syntax?  Classes derived from PBR or

  I'm not looking for a perfect solution.  I'm looking for a *useful*
solution.

> NASes have global addresses.  With IPv6 deployment plenty more will.

  How much user traffic is sent to/from a NAS?  i.e. to the IP address
of a NAS, as opposed to using it as a DSLAM or router?

  Arguably "none".  So the "NASes having global address" issue is
irrelevant.

> those systems are within the same administrative domain is not realistic.

  The RADIUS system doesn't have access to the routing table for the
local system?

> same is not true where filter definitions lacking comments are used.

  Sure, everything can be accomplished with opaque labels.  That doesn't
help interoperability or usability.

  If the goal is *perfect* usability, then we should just label filters
with arbitrary opaque binary names.  Nothing else will be as general.
Other solutions will be much more practical.

> separate configurations in each NAS in the system.  Why is it a good
> idea to also have to duplicate and manage those details in accounting
> rather than providing a pointer to them with the use of labels?

  Wow... if you're manually managing the configuration of thousands of
rules in NASes, you're doing something wrong.  Much of that can be
automated via widely available tools.

  My idea was to have a *central* management system.  This system
already exists: it's called RADIUS.  It can dynamically provision
accounting rules on NASes.

> This reminds me of taking a router full of ACLs, removing all comments
> and then trying to stump the network guy by asking why a random ACL in
> the list is there.

  Or, the router could have ACLs taken from RADIUS Access-Accepts, and
tied to a specific user session.  These ACLs are documented in one
place: on the RADIUS server.  That's a boatload better than duplicating
them thousands of times on different NASes.

  i.e. a straw-man argument can be countered with another such example

> The cost of requiring an accounting system to have to reverse engineer
> the *intent* of an ACL is nontrivial.

  Where did that requirement come from?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 15 Jul 2012 21:06:10 -0400

Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sun, 15 Jul 2012 21:03:49 -0700 (Pacific Daylight Time)

>> The same way it was configured at the NAS in the first place - by out of

Your origional response mentioned only class labels be replaced with 
filter rules.  Nothing was said about configuring those rules in the NAS 
by pushing parameters via Access-Accept.  I think this configuration would 
be useful.

However to use filter rules as the analogy we still have and use 
Filter-Id.  If anything I would prefer to see both options made avaliable 
enabling people to choose the solution which best fits their needs.

Not all problems can be or are best solved by pushing filters as syntax is 
limited.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Sun, 15 Jul 2012 21:03:49 -0700 (Pacific Daylight Time)

regards,
Peter

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Jul 2012 08:00:33 +0200

Hi,

>> interims and stop record.  Forgetting should not be an option.

At least in this part of the thread, there seems to be violent agreement :-)

I'm updating the source of the draft with more explicit wording that
forgetting is not an option.

If my time permits, I could upload a new rev just before the cut-off.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Jul 2012 08:00:33 +0200

Hi,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Jul 2012 08:30:15 +0200

Hello,

> What's the fundamental difference between a string type encoding using
> an (unregistered) user-private URN namespace and a Vendor
> Specific Enumeration for an integer type?  The latter is
> an officially discouraged technique, in the RADIUS Design Guidelines, as
> I recall.

There is no vendor-specific enumeration in the other draft at all. That
draft is very specific about sending IPv6 and/or IPv4 counter values, so
there are exactly three defined enum values for those two traffic classes.

The attribute is Acct-Traffic-Statistics.Stack-Type - the name suggests
that it is not meant to be extensible to carry more meaning than the IP
stack version.

When discussing DSCP traffic classes as something people might want to
count, the author introduced an entire new attribute for that,
Acct-Traffic-Statistics.DSCP-Type.

It is only meant to be used in conjunction with the IP stack one, to
report on the intersecting set of these two orthogonal properties.

All other values in these two attributes are reserved, suggesting that
IETF Action is necessary to add new values.

IOW, there is *no* extensibility in that draft. Assuming that people out
there will at some point want to count other conditions in their
accounting records, this forces them to hijack one of the reserved
numbers, therewith breaking semantics of these attributes and hampering
interop.

> Flexibility for small users, who can't be bothered with managed
> namespaces and codepoints is all well and good, but it seems to me that
> the purpose of doing work in the IETF is to guarantee a high level

Sure: that's why the URN namespace option is devised to carry labels
with defined and published meanings, which ensures interop.

The non-URN strings are only meant for local use. They don't guarantee
any interoperability - if the accounting data is to be shared across
enterprises, they need to define a "proper" URN one and use that.

As I wrote earlier, I don't care much about that use case, I could also
live with dropping that option 2. It's just that I believe openness in
this aspect doesn't hurt; the strings are compared char-by-char to find
the one with a specific meaning anyway and it technically makes no
difference at all whether it starts with "urn:" or not.

And if we forbid that kind of use, my gut feeling from above applies
here at well: if people want to use it in a non-URN way, they will. So
if it doesn't hurt protocol-wise to provide a local-use loophole, and
might help some people, we can just as well do it.

(I am talking of local use as in the current IAB draft about protocol
extensions: http://tools.ietf.org/html/draft-iab-extension-recs-17,
Section 3.2.2; it might be useful to point to that reference in a later rev)

Greetings,

Stefan Winter

> 
> Regards,
> 
> Dave
> 
> David B. Nelson
> Director of Technology
> Elbrys Networks, Inc.
> www.elbrys.com <http://www.elbrys.com>
> +1.603.570.2636
> 
> 

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Jul 2012 08:30:15 +0200

Hello,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Jul 2012 08:47:05 +0200

Hello,

> new standard or registry.

I took a look at IPFilterRule some time ago. I realised that it's not
entirely flexible when I saw that the fictional use case of "traffic
with a specific DSCP value" isn't covered by that attribute.

Looking further, I checked RFC5777 - The FilterRule AVP with its
numerous Classifiers (which include, but are not limited to IP
addresses) looks like better suited *if* we really choose to go in the
direction of using the axact filter definition in the accounting data as
opposed to a semantic label.

I, in turn, have concerns with that ;-) I'll go into details of this in
another reply in the thread.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Jul 2012 08:47:05 +0200

Hello,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Jul 2012 09:02:49 +0200

Hi,

> by pushing parameters via Access-Accept.  I think this configuration
> would be useful.

That certainly sounds useful indeed (but is again nothing I would put
into this *accounting* draft).

> Filter-Id.  If anything I would prefer to see both options made
> avaliable enabling people to choose the solution which best fits their
> needs.
> 
> Not all problems can be or are best solved by pushing filters as syntax
> is limited.

That's right - and my main concern with restricting the traffic
descriptor to the exact syntax used. Here is one use case which is
(almost) taken from real life, and hopefully shows that pushing the
exact syntax over and over again in every accounting packet may be less
than practical.

Our network is a science network, interconnected with other national
science networks over a common backbone ("GEANT"). Since users sometimes
use resources outside the scienitfic networks ("the internet"), there is
also an outlet on that common backbone to peer with the world at large,
called the Dante World Service (DWS).

Intra-GEANT traffic is subsidised, DWS is not. A science network *might*
want to find out which of their connected entities cause which fraction
of traffic on DWS, to send a bill about that traffic - but not the GEANT
one.

(Disclaimer: the wish to send bills for that is entirely fictional and
only made up here for argument purposes; the rest of the example is real
life though)

The classification "GEANT or DWS" is not simple - there are some 50 ASes
in the GEANT backbone, most of which have multiple IP prefixes in their
announcement.

A NAS would thus need to know a three-digit amount of IP prefixes to
classify traffic. Getting the list to the NAS alone is a daunting task,
but luckily it needs to be done just one time.

Sending the exact filter definition with hundreds of prefixes in *every
accounting packet* sounds extremely impractical to me! If I had a
traffic label called "urn:geant:dws-traffic" - I would be a lot happier
than with receiving a huge blob of IP filter rules all the time.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Jul 2012 09:02:49 +0200

Hi,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Jul 2012 10:18:00 -0400

> by pushing parameters via Access-Accept.  I think this configuration

  OK.

> avaliable enabling people to choose the solution which best fits their

  Yes.

> Not all problems can be or are best solved by pushing filters as syntax

  Yes.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Jul 2012 10:18:00 -0400

OK.

  Yes.

  Yes.

  Alan DeKok.