Subject: [radext] Attribute Design on 'Traffic Statistics'

From: Leaf yeh <[email-masked]>
Date: Thu, 23 Feb 2012 16:10:54 +0000

Dear Radius-Doctors:

I presented the following 6+ attribute design at Radext session of IETF82-Taipei, which can be found in http://www.ietf.org/proceedings/82/slides/radext-2.pptx  (RADIUS Accounting Extensions on Traffic Statistics) against draft-yeh-radext-ext-traffic-statistics.

Here are their Pros & Cons for our further discussion:

Attribute Design – 1a @ traditional type space in flat mode

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    |              Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Value (cont.)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Value (cont.)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros: simple, based on RFC2865 if the traditional type space still open for this case, draft-ietf-radext-radius-extensions sounds intend to deprecate the traditional standard type space.
Cons: 8 new type for (IPv4/IP6) * (Input/Output) * (Octets/Packets)

Attribute Design – 1b @ traditional type space

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    | Traffic-Type  |    Value      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Value (cont.)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Value (cont.)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros: simple, data type sounds the same as the one defined in RFC2868; the design of 'Traffic-Type' can cover the type of change with (IPv4/IPv6) & DSCP(3bits), and even change with (Input/Output) and (Octets/Packets) because it has 8 bits in the field of 'Traffic-Type'. That might mean 1 new type of attribute is enough to work.
Cons: Sounds complex data type

Attribute Design – 2a @ extended type space in flat mode

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    | Extended-Type |     Value     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Value (cont.)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Value (cont.)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros: simple, based on Extended type defined in section 2.1 of draft-ietf-radext-radius-extensions-04, if we'd need to use the extended type space at this time
Cons: 8 new type @ 241.x

Attribute Design – 2b @ extended type space

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    | Extended-Type | Traffic-Type  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Value (cont.)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Value (cont.)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros: Same as Design - 1b if we'd need to use the extended type space at this time
Cons: same as the Design-1b, sounds forbid in draft-ietf-radext-radius-extensions-04

Attribute Design – 3 @ extended type space in nesting-TLV mode

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    | Extended-Type | Traffic-Type  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Traffic-Type(TLV)       |       Input-Octets(TLV)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Input-Octets(TLV)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Input-Octets(TLV)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Output-Octets(TLV)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Output-Octets(TLV)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Output-Octets(TLV)       |       Input-Packets(TLV)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Input-Packets(TLV)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Input-Packets(TLV)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Output-Packets(TLV)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Output-Packets(TLV)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Output-Packets(TLV)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros: used the new basic data type of TLV defined in draft-ietf-radext-radius-extensions-04, has one TLV-container (1 new extended type, 241.x) and 5 sub-TLVs (241.x.1-5). The sub-TLV does not need to appear in the above order, and even some of them are not necessary to appear in the container attribute.
Cons: looks a little complicated, should use the extended-type as per draft-ietf-radext-radius-extensions,

Attribute Design –4a @ traditional type space

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    | Traffic-Type  | Input-Octets  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Input-Octets                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Input-Octets                 | Output-Octets |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Output-Octets                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Output-Octets                 | Input-Packets |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Input-Packets                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Input-Packets                 |Output-Packets |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Output-Packets                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Output-Packets                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-++-+-+-+

Pros: explicit and simplified from the design-3 because each field has the fixed length.
Cons: multi-field design, complex data type (not recommended by RFC6158)

Pls. feel free to comments on the above designs from your professional perspective, then I will update my draft based on your comments.

I supposed each design can work for 'Traffic Statistics', maybe Design 1a, 1b, 2a, 3 could be more acceptable.

I recommend design 1b, because it looks much simple, need much less attributs than design 1a, and we can solve the problem on reporting 'Traffic Statistics' within the standard type space.

If the standard type space is deprecated against this case, then design-2a might be our choice, because we don't have the space limitation issue in the extended type space;

or we could try the new basic data type of nesting-TLV, then 'Acct-Traffic Statistics' could be the 1st attribute in the extended type space with TLV as its basic data type.

But my concern will be that it still needs 3 or more years for the upgrade of the deployed radius system (NASs + servers) to support the solution of the extended type space and its newly-defined attributes.

Best Regards,
Leaf

---

From: Stefan Winter <[email-masked]>
Date: Fri, 24 Feb 2012 08:32:42 +0100

Leaf,

you are trying to re-open an already closed discussion. See the thread 
on the radext list from 14 nov 2011, immediately following IETF-82 Taipei.

Everyone in this thread was *for* extended attributes encoding as per my 
draft. Everybody was *against* your proposed approaches of encoding the 
information in a custom way.

Greetings,

Stefan Winter

> Dear Radius-Doctors:
>
> I presented the following 6+ attribute design at Radext session of
> IETF82-Taipei, which can be found in
> http://www.ietf.org/proceedings/82/slides/radext-2.pptx (RADIUS
> Accounting Extensions on Traffic Statistics) against
> draft-yeh-radext-ext-traffic-statistics.
>
> Pros: simple, based on RFC2865 if the traditional type space still open
> for this case, draft-ietf-radext-radius-extensions sounds intend to
> deprecate the traditional standard type space.
> Pros: simple, data type sounds the same as the one defined in RFC2868;
> the design of 'Traffic-Type' can cover the type of change with
> (IPv4/IPv6) & DSCP(3bits), and even change with (Input/Output) and
> (Octets/Packets) because it has 8 bits in the field of 'Traffic-Type'.
> That might mean 1 new type of attribute is enough to work.
> Pros: simple, based on Extended type defined in section 2.1 of
> draft-ietf-radext-radius-extensions-04, if we'd need to use the extended
> type space at this time
> Cons: 8 new type @ 241.x
>
>
> Pros: used the new basic data type of TLV defined in
> draft-ietf-radext-radius-extensions-04, has one TLV-container (1 new
> extended type, 241.x) and 5 sub-TLVs (241.x.1-5). The sub-TLV does not
> need to appear in the above order, and even some of them are not
> necessary to appear in the container attribute.
> Pls. feel free to comments on the above designs from your professional
> perspective, then I will update my draft based on your comments.
>
>
> I recommend design 1b, because it looks much simple, need much less
> attributs than design 1a, and we can solve the problem on reporting
> 'Traffic Statistics' within the standard type space.
>
> If the standard type space is deprecated against this case, then
> design-2a might be our choice, because we don't have the space
> limitation issue in the extended type space;
>
> or we could try the new basic data type of nesting-TLV, then
> 'Acct-Traffic Statistics' could be the 1st attribute in the extended
> type space with TLV as its basic data type.
>
> But my concern will be that it still needs 3 or more years for the
> upgrade of the deployed radius system (NASs + servers) to support the
> solution of the extended type space and its newly-defined attributes.
>
> Best Regards,
> Leaf
>

-- 
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: Fri, 24 Feb 2012 08:32:42 +0100

Leaf,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Leaf yeh <[email-masked]>
Date: Fri, 24 Feb 2012 09:30:09 +0000

Stefan - you are trying to re-open an already closed discussion. See the thread 
on the radext list from 14 nov 2011, immediately following IETF-82 Taipei.

Yes, I want to trigger a further discussion on this topic, and hear the opinion from other experts in the WG. 

Your opinion and preference was quite clear and are for the Design - 3. 

But as per the section 6.4 of draft-ietf-radext-radius-extensions-04, 

<quote>The "integer64" data type MAY be used in any RADIUS attribute.
The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but
their utility is now evident. </quote>

the above words means the new data type of 'integer64' can be used in both 'standard' and 'extended' type space. So the employment of 'integer64' is not a problem in Design - 1a & 1b.

2ndly, as to the question of re-usable code, I guess design - 1b might reuse the code for the traditional attributes defined in RFC2868, though this format is 'Must Not' in the 'extended' type space as per the section 6.4 of draft-ietf-radext-radius-extensions-04.

<quote>[RFC2866] "tagged" attributes MUST NOT be defined in the
Extended-Type space. The "tlv" data type should be used instead to
group attributes. </quote>

I intended to solicit the expert's judge on this aspect here.

3rdly, if WG decides to employ 'extended' type space right now or especially for this case, then we still have option of design - 2a & 3, right? I am still not quite sure that WG decides to adopt Nesting-TLV for this case if we don't have the limitation on the type space. I mean we could design it as usual.

4thly, if WG prefera to employ Nesting-TLV for the reporting 'Traffic Statistics' in Accounting-Request message, I supposed we still could make some effort on the design -3 (or draft-winter) to meet the requirement from the industry expressed in Section 1 of draft-yeh.

I intended to double-check the doctor's opinion on the Attribute Design on 'Traffic Statistics' again with my concerns on the upgrade on Radius system to support the 'extended' type space and its new Nesting-TLV dictionary, if we still have 30 unassigned codes.

Best Regards
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Winter
Sent: Friday, February 24, 2012 3:33 PM
To: Leaf yeh
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [radext] Attribute Design on 'Traffic Statistics'

Leaf,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Leaf yeh <[email-masked]>
Date: Fri, 24 Feb 2012 09:30:09 +0000

Best Regards
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Winter
Sent: Friday, February 24, 2012 3:33 PM
To: Leaf yeh
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [radext] Attribute Design on 'Traffic Statistics'

Leaf,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Fri, 24 Feb 2012 11:01:01 +0100

> Yes, I want to trigger a further discussion on this topic, and hear the opinion from other experts in the WG. 

  What do you have that is NEW to the discussion?

  The WG has already reached consensus on the topics you brought up.  It
is recorded in the messages Stefan referred to.

  Trying to re-open the same discussion is unproductive.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 24 Feb 2012 11:01:01 +0100

Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 24 Feb 2012 11:09:07 +0100

>    Trying to re-open the same discussion is unproductive.

On that topic: I'll merrily re-submit fancyaccounting and suggest WG 
adoption as soon as the new charter is out and includes an item to work 
on this issue.

Is there any ETA for the new charter?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Fri, 24 Feb 2012 11:09:07 +0100

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Leaf yeh <[email-masked]>
Date: Fri, 24 Feb 2012 10:50:11 +0000

Alan - Trying to re-open the same discussion is unproductive.

Supposed you prefer design -3.

Could we give one more opportunity for the other experts to express their opinion?

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Friday, February 24, 2012 6:01 PM
To: Leaf yeh
Cc: Stefan Winter; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [radext] Attribute Design on 'Traffic Statistics'

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Fri, 24 Feb 2012 10:50:11 +0000

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Friday, February 24, 2012 6:01 PM
To: Leaf yeh
Cc: Stefan Winter; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [radext] Attribute Design on 'Traffic Statistics'

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Fri, 24 Feb 2012 11:03:45 +0000

Design -3 got 2 votes. Is it obvious enough to make a decision in the WG?

I don't really object that Design-3 is on the discussion list, though you and Alan see the obvious advantages over the other alternative options.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Winter
Sent: Friday, February 24, 2012 6:09 PM
To: [email-masked]
Subject: Re: [radext] Attribute Design on 'Traffic Statistics'

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Leaf yeh <[email-masked]>
Date: Fri, 24 Feb 2012 11:03:45 +0000

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Winter
Sent: Friday, February 24, 2012 6:09 PM
To: [email-masked]
Subject: Re: [radext] Attribute Design on 'Traffic Statistics'

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473