Subject: RE: [ipfix] Some ideas on IPFIX-architecture

From: "Gopal Ram (NRC/Boston)" <[email-masked]>
Date: Wed, 12 Dec 2001 08:54:09 -0500

Hello all,

(1) Archicture should identify key elements which are going to
participate in the IPFIX protocol.
(2) We should keep in mind that IPFIX is not going existing on its own
its has relations with Diameter,
Intrusion Detection subsystem
(3) Should defines these external dependency and internal interfaces
between different sub systems.
(4) Any precondition and out of scope should be state here as well as in
the requirements.
(5) Should come up with sample scenarios or explaining with a reference
model.

Regards
Ramg

>-----Original Message-----
>From: ext Kevin Zhang [mailto:[email-masked]]
>Sent: Tuesday, December 11, 2001 12:18 AM
>To: [email-masked]
>Subject: [ipfix] Some ideas on IPFIX-architecture
>
>
>Hi All,
>
>As we are getting started to work on the IPFIX architecture, I 
>would like to offer few ideas to assist the discussion.  
>Hopefully, we can touch on these issues at our Wed. session.
>
>1.  General Scope of IPFIX architecture.
>
>The IPFIX architecture should describe the major functions 
>performed by a IPFIX system.  We need to answer the following 
>questions -
>1.1  What is the IPFIX system and what are the key functions 
>performed by such a system? 
>1.2  What are the major functional elements (e.g. data 
>exporter, data collector, etc.) within the IPFIX system? 
>1.3  How to assign key IPFIX functions to various IPFIX 
>elements? What are the interfaces and supported protocols? 
>Reference models should be specified.
>
>2. IPFIX Scenarios
>
>2.1 The exporter and the collector are connected over LAN or 
>dedicated links. This scenario maybe suitable for handling 
>high volume data export and may use unreliable transport protocol.
>2.2 The exporter and the collector are connected over WAN. 
>This scenario may require higher level of processing at the 
>exporter (such as aggregation), and should use a reliable 
>transport protocol with congestion control and avoidance capability. 
>2.3 Highly reliable IPFIX configuration.  This scenario should 
>describe how to support reliability of data export as well as 
>redundant configurations.
>
>3. Data transport Semantics
>
>We need to specify the required control information exchange 
>between the layers and between the end points.  This would set 
>up the correct context for export IP flow information to meet 
>various application (billing, traffic profiling, etc.) requirement. 
>
>
>éi(tm)¨¥¶?sZSÝ¢j'z×hSÜ"±Ç¹©Ý±¬¡zZbzg¬±¨n?rR{.nÇ+?·¦j)m¢f£¢·hs?Þ
>µÚ"·¬qçnjwlk+§²æìr¸>z*_<§(tm)ë,j>¡ÜEURÈb½èm¶YÿS-âÅÚ"·¬qçnýªÜ?+Þ
>

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 12 Dec 2001 12:12:22 -0800

>Intrusion Detection subsystem

I do not see any required relation to Diameter as of today
other than at some point in the possible future that the 
protocol is best fitted for the IPFIX requirements.

IPFIX work is standardizing *existing practice* 
that has been deployed for years.

Mike

---

From: Jc Martin <[email-masked]>
Date: Wed, 12 Dec 2001 12:56:25 -0800

Michael

> protocol is best fitted for the IPFIX requirements.

Well, there should be a relation, maybe not with Diameter, but at
least with AAA. The name space and attributes should/must be identical.

> that has been deployed for years.

Then why a requirement document ? Why not just a description of
the current practice ?

JC.

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 12 Dec 2001 13:27:08 -0800

>Then why a requirement document ? Why not just a description of

We need the requirement document to culling 
current practice into something we can work with to base 
our work on what will eventually be the IPFIX protocol.

Now if there is a requirement that can't be substantiated
in a current practice with the defacto IP flow protocls
(NetFlow, LFAP, etc) then, I'd think we'd be treading 
on unstable ground.

Mike