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