Subject: FW: New Version Notification for draft-maglione-radext-ipv6-acct-extensions-00

From: Maglione Roberta <[email-masked]>
Date: Tue, 23 Feb 2010 15:31:49 +0100

Hi All,
     we have just posted a new draft about RADIUS attributes for IPv6 statistics:
http://tools.ietf.org/html/draft-maglione-radext-ipv6-acct-extensions-00
Your comments are welcome.

Thanks,
Regards,
Roberta

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tuesday, February 23, 2010 11:43 AM
To: Maglione Roberta
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-maglione-radext-ipv6-acct-extensions-00

A new version of I-D, draft-maglione-radext-ipv6-acct-extensions-00.txt has been successfuly submitted by Roberta Maglione and posted to the IETF repository.

Filename:        draft-maglione-radext-ipv6-acct-extensions
Revision:        00
Title:           RADIUS Accounting Extensions for IPv6
Creation_date:   2010-02-23
WG ID:           Independent Submission
Number_of_pages: 10

Abstract:
This document describes additional RADIUS attributes to be used for
collecting IPv6 statistics in RADIUS Accounting messages.

The IETF Secretariat.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

--
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: Avi Lior <[email-masked]>
Date: Tue, 23 Feb 2010 12:38:18 -0500

Hi,'

What makes you say that the existing accounting attributes for octet/packet counts are for IPv4 ?

Wouldn't the IP address contained in the IP session be sufficient to create the context for the accounting message?

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 23 Feb 2010 15:38:42 -0500

Hi Avi,
   Thanks for your comments.

> What makes you say that the existing accounting attributes for octet/packet counts are for IPv4 ?

You are right. They are not. They are not protocol specific. We are 
looking to define separate counters for IPv6. We will change the wording 
in the draft to correspond to this.

> Wouldn't the IP address contained in the IP session be sufficient to create the context for the accounting message?

This will require us to send two different messages (one for IPv6 only 
and one for all protocols combined together).

Thanks
Suresh

---

From: Avi Lior <[email-masked]>
Date: Tue, 23 Feb 2010 17:03:25 -0500

Why do you need separate counters for IPv6?

Is it because you want to have different counters for different IP technology at the same time in the accounting stream?

If yes there are other problems with that approach.  Accounting is used for both volume and time accounting.  While having distinct volume counters for one technology may solve the volume aspect it does not address the time aspect.  Consider the fact that even if you have both IPv4 and IPv6 enabled one may start at a different time then the other and one may stop at a different time then the other.

There are other information elements that are accounted for that may be specific to a particular IP technology and not the other.

As well, a user may have multiple IPv4 addresses and multiple IPv6 addresses.

So I am concerned that you are not really addressing all the issues.  

Separate accounting streams per IP session solves these problems.

What is the problem with having separate accounting streams per IP session?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 24 Feb 2010 22:21:36 +0100

> Your comments are welcome.

   [RFC2866]and [RFC2869] specify RADIUS attributes to be used for
   carrying statistics regarding how many packets/octets/Gigawords have
   been sent/received over a port while delivering the service.  These
   attributes are IPv4 specific.

 That isn't correct.  RFC 2866 has *no* references to IPv4.  I suggest
deleting it.

   With the introduction of the IPv6 in
   broadband environment there is a need to be able to collect IPv4 and
   IPv6 statistics separately, thus new RADIUS attribute have to be
   defined.

 That might be true, and is a better problem statement than the previous
sentence.

  However, there is a LOT of information that could potentially be
carried in RADIUS accounting.  There have been requests to track data
down to specific applications and/or ports.  These suggestions have a
number of problems in practice.  (Which I won't go into here.)

4. Operation
...

  This section repeats existing definitions of RADIUS accounting.  I
suggest deleting it.

5.
...
   This section defines six new RADIUS attributes for IPv6 statistics.
   These attributes correspond to the attributes Acct-Input-Octets,
   Acct-Output-Octets,Acct-Input-Packets, Acct-Output-Packets, Acct-
   Input-Gigawords and Acct-Output-Gigawords as defined in
   [RFC2866][RFC2869] that are defined for collecting combined
   statistics for IPv4 and IPv6 traffic.

  This last sentence directly contradicts the sentence in the
introduction.  It would be good to have the document internally consistent.

   Since service providers may
   like to collect statistics for IPv6 traffic separately from IPv4
   traffic, separate counters for IPv6 traffic are needed.

  Repetition of the justification is unnecessary, and can be deleted.

  It would be good to add a sentence or two on how these attributes
interact with the existing counters.  e.g. how IPv4-specific counters
can be derived.

  Alan DeKok.

---

From: Maglione Roberta <[email-masked]>
Date: Thu, 25 Feb 2010 09:41:04 +0100

Hello Alan,
    thanks for your comments.

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Wednesday, February 24, 2010 10:22 PM
To: Maglione Roberta
Cc: [email-masked]; Alan Kavanagh; Suresh Krishnan; Varga Balázs
Subject: Re: FW: New Version Notification for draft-maglione-radext-ipv6-acct-extensions-00

[RM] ok, we will delete it

[RM] This is the main intent of document

4. Operation
...

5.
...

[RM] We will re-word this sentence to make it consistent

[RM] ok we will add it

Thanks,
Roberta

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Thu, 25 Feb 2010 15:01:55 -0500

On 23-02-2010, at 20:40 , Alan Kavanagh wrote:

> Hi Avi
> From: Avi Lior [mailto:[email-masked]] 
> Sent: February 23, 2010 5:03 PM
> To: Suresh Krishnan
> Cc: Maglione Roberta; [email-masked]; Alan Kavanagh; Varga Balázs
> Subject: Re: New Version Notification for draft-maglione-radext-ipv6-acct-extensions-00
> 
>>> A.K.--> it may be that you have some sessions that are IPv4 only as we have today, some sessions that are IPv6 only and some sessions for dual stack hosts where the SP wants to count the traffic volume seperately for IPv4 and IPv6 for stats purposes as one example. Also, in the dual stack host case, if the AAA assigns both IPv4/v6 Addresses, there are some cases that the IPv4 address does not get assigned down to the end host until some speficied time x and as such we still want to count the IPv6 packets for an ongoing current session.
> 
>>> A.K.--> Agree as I noted above we agree on this and the intention of the draft is primarily for volume based accounting.
Avi: Here I have an issue.  You can't solve the problem only for Volume Based and even for volume based you are not solving the problem in general.  You are only assuming that the device is getting one IPv4 and one IPv6 address - that is not the case always.  The current model already supports Volume Based and Time Based and other things.  The current model is to send an accounting packet for each IP session.
>>> A.K.--> Can you expand on this a little more, are you siting a prefix as oppsoed to a 128-bit address?
Avi:  Regarding multiple IP addresses.  I am not talking about a prefix vs 128-bit addresses.  That can always be true.  What I am talking about is a given session can be assigned multiple IPv4 addresses only, multiple IPv6 addresses only or any combination of multiple IPv4 and multiple IPv6 addresses.  Your proposed solution can only handle the case where a single IPv4 and/or Single IPv6 address is assigned.

>>> A.K.--> nothing prevents you from doing that, but you still require to count IPv6 packets when you have a dual stack session that are logically combined at the NAS.
But I don't need to have distinct IPv6 counters.  You can do what you want to achieve without creation of distinct IPv6 counters.  My argument is that you can do a better (better = more general flexible solution) job with the current approach.

> //Alan
>> looking to define separate counters for IPv6. We will change the 
>> wording in the draft to correspond to this.
>> 
>>>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 26 Feb 2010 10:30:15 +0100

> Wouldn't the IP address contained in the IP session be sufficient to create the context for the accounting message?

  I suppose you could distinguish traffic IPv4/v6 for a session by
simply sending two different accounting streams.  e.g. one with an IPv4
address, and another with an IPv6 address.  The Acct-Multi-Session-Id
attribute would be good for this.

  e.g. for IPv4, send:

Framed-IP-Address = ...
Acct-Session-Id = 1234
Acct-Multi-Session-Id = foo
(octets / packet counters)

  For IPv6, send:

Framed-IPv6-Address = ... (presuming draft-lourdelet is standardized)
Acct-Session-Id = 5678
Acct-Multi-Session-Id = foo
(octets / packet counters)

  IIRC, this functionality is already used to track different kinds of
user traffic in certain environments.  It's not widely supported in the
ISP / dial-up environment, but it shouldn't be hard to add.

  Leveraging the existing functionality of RADIUS would mean that this
document is unnecessary.

  Alan DeKok.

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 26 Feb 2010 16:00:51 +0100

Hi Alan,

> attribute would be good for this.

I'm not sure we could use the Acct-Multi-Session-Id for this purpose because according to the definition in RFC 2866, Acct-Multi-Session-Id links together multiple sessions with different Acct-Session-Id

"5.11  This attribute is a unique Accounting ID to make it easy to link
      together multiple related sessions in a log file.  Each session
      linked together would have a unique Acct-Session-Id but the same
      Acct-Multi-Session-Id."

While in the described scenario there is a single session that carries multiple traffic flows: IPv4 and IPv6.

In addition I see an operational issue in terms of efficiency in doubling the number of Accounting streams, because we usually have around 20-30 thousand active subscribers in a single NAS thus  sending the Accounting stream twice may affect the performance of the NAS.

Regards,
Roberta

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Friday, February 26, 2010 10:30 AM
To: Avi Lior
Cc: Maglione Roberta; [email-masked]; Alan Kavanagh; Suresh Krishnan; Varga Balázs
Subject: Re: New Version Notification for draft-maglione-radext-ipv6-acct-extensions-00

  e.g. for IPv4, send:

Framed-IP-Address = ...
Acct-Session-Id = 1234

  For IPv6, send:

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 26 Feb 2010 16:35:03 +0100

> While in the described scenario there is a single session that carries multiple traffic flows: IPv4 and IPv6.

  Yes, I understood that.  I still proposed the solution because:

(a) it works
(b) it's not actually forbidden by the RFCs
(c) it seems to be a practical use-case for Acct-Multi-Session-Id

> In addition I see an operational issue in terms of efficiency in doubling the number of Accounting streams, because we usually have around 20-30 thousand active subscribers in a single NAS thus  se…

  RADIUS isn't perfect.  You have to make trade-offs somewhere.   The
choice is between more traffic for the NAS (but with well-defined
semantics), or more attributes in the standard space.

  Alan DeKok.