Subject: [radext] Accounting for traffic classes

From: Stefan Winter <[email-masked]>
Date: Mon, 14 Nov 2011 09:46:58 +0100

Hi,

following a discussion I had with Leaf, here are some basic thoughts
about the different approaches.

First off, both of the approaches depend on the radius-extensions-02
draft; they use Integer64 as a data type.

Second, both are backwards compatible in that a IPv4-only network does
not have to use the new drafts for reporting accounting; the "good old"
Acct-Input/Output-Octets/Packets from RFC2866 continue to exist and are
not deprecated.

The main difference is really in the encoding approach:

* draft-yeh "stuffs" complex information into a single attribute (design
2 and 4 on his today's slides); an implementer would need to write a
custom parser for these statistics attributes.
* draft-winter uses the TLV grouping from radius-extensions to encode
content in sub-attributes. An implementor needs a parser for extended
attributes; such a parser is useful for *any* attribute needing TLVs.
That draft is pretty much the same as what Leaf presented as "Design 3"
today.

If a RADIUS device has not implemented TLV attributes yet, both
approaches need an amount of parser writing. Such an implementer would
likely need slightly less code to implement draft-yeh; the nesting of
attributes in a TLV group is *slightly* more complex.

So, if all you care for is these new statistics attributes, it's less
work to do it with draft-yeh. Then again, RADIUS Design Guidelines
(BCP!) say that complex attribute encodings shouldn't be used if a
viable alternative exists. radius-extensions provide such a viable
alternative, it's the TLVs.

So, if you care for re-usable code, it is more advisable to write a
parser for TLVs - then, you can send traffic statistics with
draft-winter *and* can handle any other attribute that uses TLVs. That
way is also in line with the recommendations in the Design guidelines.

Given that no other attribute in use currently uses TLVs, the difference
is not big. I'm trying to "evangelize" other WGs who do RADIUS stuff
though to also make use of TLVs; after reading softwire's 6rd RADIUS
Attributes draft I see that their extremely complex attribute encoding
is something that's crying for TLVs instead.

In summary, I concur with Leaf that *right now*, the advantage is
non-existent. I'm still in favour of TLVs though; their advantage will
play out over time with new attributes that need to encode complex
attributes. That, and that not using them violates RADIUS Design Guidelines.

Greetings,

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 14 Nov 2011 10:20:47 +0100

> The main difference is really in the encoding approach:

  And extensibility.  Using a complex format means it is *impossible* to
add new fields to the accounting attribute.  Using TLVs means that is is
*easy* to add new fields.

> is not big.

  The draft points out that there are many attributes which use TLVs.
WiMAX and 3GPP have used TLVs extensively.  Many NAS manufacturers and
all major RADIUS servers already support TLVs.

> I'm trying to "evangelize" other WGs who do RADIUS stuff

  I agree.

> non-existent.

  I disagree.  The advantage is what you say below.

  The alternative is to make this decision for *every* draft.  "It's not
any more complicated to have a custom format than to use the new
format".  So this argument will be made for *every* draft.  The result
will be that the new format never gets implemented.

  At some point, we have to decide to use the new format.  We might as
well do it now.  I see no benefit to delay, delay, delay, delay.

> I'm still in favour of TLVs though; their advantage will

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 14 Nov 2011 10:20:47 +0100

I agree.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 14 Nov 2011 12:37:35 +0000 (UTC)

> well do it now. I see no benefit to delay, delay, delay, delay.

+1

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 14 Nov 2011 12:37:35 +0000 (UTC)

+1

---

From: Peter Deacon <[email-masked]>
Date: Mon, 14 Nov 2011 06:55:42 -0800 (Pacific Standard Time)

> *easy* to add new fields.

Aside from the complexity arguments what if I want to convey only Octet 
counter(s) or counters for one side of the session?

For example in my implementation for some reason Packets are 
unavailable.  How would this be possible?

One can't just send elements of a fixed format that you have.

Setting the packet count values to zero is not correct either as there are 
not really zero packets in those fields.  The value is undefined meaning 
the elements should not be sent.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Mon, 14 Nov 2011 06:55:42 -0800 (Pacific Standard Time)

regards,
Peter

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Tue, 15 Nov 2011 10:27:12 +0000

<taking my co-chair hat off and speaking as an individual>

+1

If I'm going to have to write a new parser, rather just write one that can be re-used.     

<co-chair hat back on>

Alan,
When did you say you'd have a new version of the extensions draft completed?

-MS

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David B. Nelson
Sent: Monday, November 14, 2011 8:38 PM
To: Alan DeKok
Cc: [email-masked]; Stefan Winter
Subject: Re: [radext] Accounting for traffic classes

+1

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Tue, 15 Nov 2011 10:27:12 +0000

+1

<co-chair hat back on>

Alan,

-MS

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David B. Nelson
Sent: Monday, November 14, 2011 8:38 PM
To: Alan DeKok
Cc: [email-masked]; Stefan Winter
Subject: Re: [radext] Accounting for traffic classes

+1

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Nov 2011 11:48:04 +0100

> When did you say you'd have a new version of the extensions draft completed?

  I just submitted it.

  The IANA section has been extended as per Bernard's comments.  It now
gives detailed instructions for every aspect of attribute allocation.
It references 3575, too.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Nov 2011 11:48:04 +0100

I just submitted it.

  Alan DeKok.