Subject: [radext] RADEXT @ IETF84: Meeting notes posted

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 5 Sep 2012 18:59:01 +0000

RADEXT community,
Meeting notes have finally been posted for IETF 84.  Thanks go out to Nancy C. for great note taking.

http://www.ietf.org/proceedings/84/minutes/minutes-84-radext

Any corrections/modifications welcome.

-MS

---

From: Leaf yeh <[email-masked]>
Date: Thu, 6 Sep 2012 09:25:46 +0000

Thanks for the posted Meeting notes. Though I am not there in the discussion session, I still can see your fair comments. 

I am trying to catch the following technical points related to the topic of 7.

<quote>7. RADIUS traffic accounting work, Stefan Winter

- http://tools.ietf.org/id/draft-winter-radext-fancyaccounting 
- http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics 

-Status: 2 drafts to speak of the same thing: to extend existing accounting drafts.
-What to do with 2 drafts?  WG needs to discuss if the accounting should be extensible or focus on (hardcoding) IPv6 vs. IPv4?
-Draft-winter-radext-fancyaccounting uses classes by string label which should be a URN pointing to the exact definition of what is being accounted for. 
-Draft-yeh-radext-ext-statistics only addresses IPv6 vs. IPv4; DSCP was added does the accounting by enumerated integer labels.

-Alan: believes they are both very similar, the winter draft is simpler and more clear; has comments on how to clean up with filter rules.  If there are complicated rules, then you may not want to send these in the packet; so using the old style filter rule may not be good to use; identifiers are better. But don't have strong intelligent suggestion to address URN.
-Alan: clarifies that there's 2 things needed: to define the traffic class (getting sent to the NAS as it may not be in RADIUS) and then providing the traffic class information itself.
-Marc B: draft-yeh seems to be fairly straight forward as it only focuses on the IPv6 traffic as it doesn't bring other stuff to the table.  As a quick browse on the winter draft, while itÂ¹s a nice architecture it may be bringing a bigger picture to solve a little problem (e.g. IPv6)
-Alan: Avi has done a lot of 3GPP and other similar work to what's been proposed in the winter draft; e.g. bringing flexibility and classifiers to accounting.  
-Jouni: mentions yes some work has been done in the diameter space.
-Mauricio: we could take a narrower scope in the yeh draft, but Stefan raises good point that if new work comes then they'd have to define a new classifier so would be good to discuss that too.  So may need a combination of both drafts and encourages them to converge to a new draft. But question is whether we take a tactical approach vs. flexible approach.
</quote>

I brought the specific requirement on reporting the traffic statistics in dual-stack scenario and some possible attribute designs for the RADIUS accounting extension to this WG from 2011, Mar., and believe some of design (such as the traditional one in flat mode, not employed in the extended type space) or both of the above 2 approaches (in the extended type space) can solved the existing problem. The main difference between the above 2 approaches is that, one use the existing data type, enumerated integer, for the traffic type and solve the problem within the existing protocol framework; while the other (draft-winter) proposed the new fashion data type of 'String in URN format' for the traffic type.

I prefer the idea to take a narrower scope in the draft, not too divergent to solve the undefined problem, and combine the above 2 drafts for the same design target discussed before.

I am still & also not quite sure about the requirement to report the traffic statistics in other protocols, including IPFIX, Syslog and SNMP-MIB, for some kind of accounting in AAA or BOSS systems.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sanchez, Mauricio (HP Networking)
Sent: Thursday, September 06, 2012 2:59 AM
To: [email-masked]
Subject: [radext] RADEXT @ IETF84: Meeting notes posted

RADEXT community,

-MS

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