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

[Avi Lior <avi@bridgewatersystems.com>]

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

> Hi Avi
> 
> 
> 
> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com] 
> Sent: February 23, 2010 5:03 PM
> To: Suresh Krishnan
> Cc: Maglione Roberta; radiusext@ops.ietf.org; Alan Kavanagh; Varga Balázs
> Subject: Re: New Version Notification for draft-maglione-radext-ipv6-acct-extensions-00
> 
> 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?
>>> 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.
> 
> 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.
> 
>>> 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.
> 
> 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.
> 
>>> 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.

> 
> 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?
> 
>>> 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
> 
>> Hi Avi,
>>  Thanks for your comments.
>> 
>> On 10-02-23 12:38 PM, Avi Lior wrote:
>>> Hi,'
>>> 
>>> 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
> 


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