Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt

From: Alan DeKok <[email-masked]>
Date: Tue, 01 Nov 2011 10:30:16 +0100

Leaf yeh wrote:
> Dear Group,
> 
> 1. draft-yeh-radext-ext-traffic-statistics-01 is ready for your comment on whether it deserves a WG item at RADEXT. 
> 
> 2. It defined 8 new attributes of traffic statistics for the separate IPv4 & IPv6 stack (queue or counter), and employed the new date type of integer64, but the format of new attributes might be still a question now. It has 2 options now:  a. the traditional format defined in [RFC2865];  b. the new extended format defined in [draft-ietf-radext-radius-extensions-02].

  Looking at the names of the new attributes:

      Acct-Input-IPv4-Octets
      Acct-Output-IPv4-Octets
      Acct-Input-IPv4-Packets
      Acct-Output-IPv4-Packets
      Acct-Input-IPv6-Octets
      Acct-Output-IPv6-Octets
      Acct-Input-IPv6-Packets
      Acct-Output-IPv6-Packets

  They're of the form:

	Acct- Input/Output - IPv4/IPv6 - Packets/Octets

  This looks like a good case for grouping by type, which means TLVs.
If you use the new format, TLVs would be preferred to using a "flat"
name space, and allocating 8 attributes from that space.

  One option would be to define two attributes: "Acct-Input-Stats" and
Acct-Output-Stats".  They could be > 252 octets long, and contain TLVs.
 They could share the same set of sub-TLVs.

  The sub-TLVs could be:

	Acct-IPv4-Stats	for IPv4 data
	Acct-IPv6-Stats	for IPv6 data

  Those sub-TLVs in turn could contain:

	Acct-Packet-Stats
	Acct-Octet-Stats

  The Acct-Input-IPv4-Octets attribute you define would then map to:

	Acct-Input-Stats ( Acct-IP4-Stats ( Acct-Packet-Stats (value)))

  This uses more space in the packet, but is more general.  Other
specifications could add TCP stats, UDP stats, etc.

  You mention draft-winter-radext-fancyaccounting-00.  I haven't
compared the two documents in detail, but I'd like to know what overlap
(if any) exists between them.  Having the WG converge on one proposal
would be a good thing.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 01 Nov 2011 10:30:16 +0100

Acct-Input-IPv4-Octets
      Acct-Output-IPv4-Octets
      Acct-Input-IPv4-Packets
      Acct-Output-IPv4-Packets
      Acct-Input-IPv6-Octets
      Acct-Output-IPv6-Octets
      Acct-Input-IPv6-Packets
      Acct-Output-IPv6-Packets

  They're of the form:

  The sub-TLVs could be:

	Acct-Packet-Stats
	Acct-Octet-Stats

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

---

From: Stefan Winter <[email-masked]>
Date: Thu, 03 Nov 2011 11:23:31 +0100

Hi,

> name space, and allocating 8 attributes from that space.

That's exactly what my draft-winter-radext-fancyaccounting uses. The
grouping comes very natural here; compared to that, introducing numerous
attributes in flat space looks like a waste of attribute resources.

> (if any) exists between them.  Having the WG converge on one proposal

AFAICT, fancyaccounting's capabilities are a superset of this
document's. It defines a generic TLV container for traffic classes. Two
such classes could be "IPv4" and "IPv6", but arbitrary other traffic
classes are possible. E.g. if accounting should be done for different
DSCP classes (separate billing levels), it would be easy to add that to
fancyaccounting without allocating new attributes *again*. With the
ext-traffic-stats document, every new traffic class would require as
much as 4 new attributes.

It is also not easily possible to combine criteria; e.g. if you want to
have per-DSCP stats per-IP version, this cannot be expressed.
Hard-wiring attribute names for one specific class of traffic does not
sound prudent to me.

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: Thu, 03 Nov 2011 11:23:31 +0100

Hi,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Leaf yeh <[email-masked]>
Date: Thu, 10 Nov 2011 04:13:43 +0000

Alan - This looks like a good case for grouping by type, which means TLVs.

Thanks to draft-ietf-radext-radius-extensions-02, we've got the alternative method to define the new attribute.

But the arguments could be:

1.      The type-space of the attribute has extended much after adopted the Extended type (241-244), the unassigned type space turn to be 1003=191-144 + 4*(240-1). We can use it just directly in flat mode.

2.      The above map of ‘Acct-Input-Stats ( Acct-IP4-Stats ( Acct-Packet-Stats (value)))’ sound TLV nesting, but I guess TLV grouping (container mode) sounds better though it is a little more complex than the flat mode .

That might means

    Input-Octets (10x octets, TLV)

    Output-Octets (10x octets, TLV)

    Input-Packets (10x octets, TLV)

    Output-Packets (10x octets, TLV)

could be the sub-attributes.

If one more ‘Traffic-Type’(sub-attribute, 3x octets, TLV) could be included into the container ‘Acct-traffic-statistics’, referred to the draft-winter-radex-fancyaccounting-00, then the container would get the extensibility for various kinds (eg. IPv4, IPv6) of traffic statistics per the ‘Traffic-Type’, and even for some demands (eg. DSCP mentioned in the above draft, or TCP, UDP mentioned below) in the future.

In this design, the length of the container will never excess 252 octets, then the container ‘Acct-traffic-statistics’ could use the format of Extended-Type (241).

3.      Do we already have any container attribute defined in RFC? I can’t find this kind of attribute in IANA web page. (http://www.iana.org/assignments/radius-types/radius-types.xml). I wonder the Radius community & WG would like this complexity of interpretation against 1-2 more levels of nesting and combination.

4.      As to the code assignment for this new type of container attribute proposed for IANA consideration, it might be

241.1 for the the container ‘Acct-traffic-statistics’

241.1.1 for the sub-attribute ‘Traffic-Type’

241.1.2 for the sub-attribute ‘Input-Octets’

241.1.3 for the sub-attribute ‘Output-Octets’

241.1.4 for the sub-attribute ‘Input-Packets’

241.1.5 for the sub-attribute ‘Output-Packets’

I wonder the space of 241.1.x (rather than 241.x) is ready for IANA to assign out.

Any more comments?

Best Regards,

Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Tuesday, November 01, 2011 5:30 PM
To: Leaf yeh
Cc: [email-masked]
Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt

      Acct-Input-IPv4-Octets

      Acct-Output-IPv4-Octets

      Acct-Input-IPv4-Packets

      Acct-Output-IPv4-Packets

      Acct-Input-IPv6-Octets

      Acct-Output-IPv6-Octets

      Acct-Input-IPv6-Packets

      Acct-Output-IPv6-Packets

  They're of the form:

  The sub-TLVs could be:

         Acct-Packet-Stats

         Acct-Octet-Stats

would be a good thing.

  Alan DeKok.

radext mailing list

[email-masked]

---

From: Leaf yeh <[email-masked]>
Date: Thu, 10 Nov 2011 04:13:43 +0000

That might means

Any more comments?

Best Regards,

Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Tuesday, November 01, 2011 5:30 PM
To: Leaf yeh
Cc: [email-masked]
Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt

      Acct-Input-IPv4-Octets

      Acct-Output-IPv4-Octets

      Acct-Input-IPv4-Packets

      Acct-Output-IPv4-Packets

      Acct-Input-IPv6-Octets

      Acct-Output-IPv6-Octets

      Acct-Input-IPv6-Packets

      Acct-Output-IPv6-Packets

  They're of the form:

  The sub-TLVs could be:

         Acct-Packet-Stats

         Acct-Octet-Stats

would be a good thing.

  Alan DeKok.

radext mailing list

[email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Nov 2011 07:50:33 +0100

Leaf yeh wrote:
> 1.      The type-space of the attribute has extended much after adopted
> the Extended type (241-244), the unassigned type space turn to be
> 1003=191-144 + 4*(240-1). We can use it just directly in flat mode.

  Hmm... the purpose of adding TLVs is to group similar attributes, and
to allow later extensions of the same group.  My response showed how
that could be done.  Using a flat mode means that the attributes have no
logical relationship, and cannot be meaningfully extended.

> If one more ‘Traffic-Type’(sub-attribute, 3x octets, TLV) could be
> included into the container ‘Acct-traffic-statistics’, referred to the
> draft-winter-radex-fancyaccounting-00, then the container would get the
> extensibility for various kinds (eg. IPv4, IPv6) of traffic statistics
> per the ‘Traffic-Type’, and even for some demands (eg. DSCP mentioned in
> the above draft, or TCP, UDP mentioned below) in the future.

  I think so.

> 3.      Do we already have any container attribute defined in RFC? I
> can’t find this kind of attribute in IANA web page.
> (http://www.iana.org/assignments/radius-types/radius-types.xml). I
> wonder the Radius community & WG would like this complexity of
> interpretation against 1-2 more levels of nesting and combination.

  Stefan's "fancy accounting" draft had positive feedback in this WG.

> 4.      As to the code assignment for this new type of container
> attribute proposed for IANA consideration, it might be

  Code assignment is done by IANA.  The exact values for the numbers
don't matter, and aren't up for discussion.

> I wonder the space of 241.1.x (rather than 241.x) is ready for IANA to

  The extended attributes draft explains in great detail how IANA
assigns attributes, including new TLVs.  Please read it.

  The numbers are not ready for IANA to assign, because the draft has
not been published.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Nov 2011 07:50:33 +0100

I think so.

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 10 Nov 2011 07:21:15 +0000

Alan - Stefan's "fancy accounting" draft had positive feedback in this WG.

FYI - http://www.ietf.org/proceedings/81/minutes/radext.txt 
Pls. read the minutes on the No.4-RADIUS accounting for traffic classes.

Alan - Code assignment is done by IANA. The exact values for the numbers don't matter.

Per section 9.1 of draft-ietf-radext-radius-extensions-02, the proposal shown as an example of code assignment could be a possible (or compliant) case. Right?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Thursday, November 10, 2011 2:51 PM
To: Leaf yeh
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt

  I think so.

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 10 Nov 2011 07:21:15 +0000

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Thursday, November 10, 2011 2:51 PM
To: Leaf yeh
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt

  I think so.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Nov 2011 08:30:05 +0100

> Pls. read the minutes on the No.4-RADIUS accounting for traffic classes.

  Please read the mailing list archives.  Look for "fancy accounting".

> Per section 9.1 of draft-ietf-radext-radius-extensions-02, the proposal shown as an example of code assignment could be a possible (or compliant) case. Right?

  That isn't a response to my statement.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Nov 2011 08:30:05 +0100

Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 10 Nov 2011 08:21:07 +0000

Alan - That isn't a response to my statement.

Repeat the question: 

The proposed shown below as a possible example of code assignment is a compliant case per the recommendations described in the section 9.3 of draft-ietf-radext-radius-extensions-02. 

241.x for the the container ‘Acct-traffic-statistics’
241.x.1 for the sub-attribute ‘Traffic-Type’
241.x.2 for the sub-attribute ‘Input-Octets’
241.x.3 for the sub-attribute ‘Output-Octets’
241.x.4 for the sub-attribute ‘Input-Packets’
241.x.5 for the sub-attribute ‘Output-Packets’

Right?

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Thursday, November 10, 2011 3:30 PM
To: Leaf yeh
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 10 Nov 2011 08:21:07 +0000

Repeat the question: 

Right?

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Thursday, November 10, 2011 3:30 PM
To: Leaf yeh
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Nov 2011 12:51:26 +0100

> The proposed shown below as a possible example of code assignment is a compliant case per the recommendations described in the section 9.3 of draft-ietf-radext-radius-extensions-02. 

  It's an example.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Nov 2011 12:51:26 +0100

It's an example.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 11 Nov 2011 22:08:11 +0100

Hello,

> Pls. read the minutes on the No.4-RADIUS accounting for traffic classes.

I started the draft because *you* presented an urgent need for 
IPv6-specific accounting the meeting before that one.

I wrote the draft, and got positive remarks on the mailing list.

On the next meeting, I gauged interest for prioritisation of my 
workload. You were in the room, and (all of a sudden) had no interest 
any more.

Now you've put forward your own draft to solve the exact same problem.

Are you a) interested or b) not interested in solving the IPv6-Acct 
problem? The signals you send are contradicting.

In any case, I would like to have a short presentation on the 
fancyaccounting draft, now that interest is apparently above 0 again.

Stefan

>> wonder the Radius community&  WG would like this complexity of

---

From: Stefan Winter <[email-masked]>
Date: Fri, 11 Nov 2011 22:08:11 +0100

Hello,

Stefan