Subject: RE: [ipfix-arch] Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

From: <[email-masked]>
Date: Mon, 11 Feb 2002 11:18:52 -0500

Hello,
 
Your point is well taken, but making a protocol to do  some configuration does not make the protocol a burden.
 If you prefer to have out-of band mechanism that's fine. I think  we are not mandating any thing.   It is nice if one  protocol  provides
 both configuration and management.

Regards
Ramg

-----Original Message-----
From: ext Will Eatherton [mailto:[email-masked]]
Sent: Monday, February 11, 2002 10:24 AM
To: Reinaldo Penno; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [ipfix-arch] Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Group,
 
Cisco's interest in IPFIX  was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner).  If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo,  it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol.  Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX.  It seems time for an official call on what is in/out of scope for IPFIX.  As has been mentioned here multiple times we would like to hear :  
- the exporter configuration is out of the scope of this document   (the exporter configuration out of band)

- no transport negotiation (which transport)

 - no capability negotiation

Will

:So lets have a protocol which is more flexible as NetFlow version 
:1-7, 

I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it.

:but not much more complicated, in order to be successfully 
:accepted by hardware vendors and application programmers. 

ohh, please...Then Netflow is just right? 

Reinaldo

---

From: "Reinaldo Penno"<[email-masked]>
Date: Mon, 11 Feb 2002 21:20:24 -0800

Hello K.C.,
 
I think we are talking about slightly different things...One of the points
against Capability Negotiation raised by Ganesh was that a sys admin could
do that. So, this is always true, you can always pay someone to do
"everything", but it's hardly an argument against CN (Capability
Negotiation) or any protocol.
 
So, capability negotiation and a lot of other things will never be
"necessary" from a point of view of somone who is willing to pay a sys admin
to do all that work. So IMO the best question to ask is the one I proposed
in the previous email, i.e., "do you think it should be on the doc and with
which level of compliance?"
 
As for last email I didn't quite understand the question. Are you asking me
what the capability negotiation protocol would be?
 
regards,
 
Reinaldo

-----Original Message-----
From: K.C. Norseth [mailto:[email-masked]]
Sent: Monday, February 11, 2002 9:11 PM
To: Penno, Reinaldo [SC9:T327:EXCH]; [email-masked]; [email-masked]
Subject: Re: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments
on the Architecture Draft)

Hi Reinaldo,
 
Althoug it is a dream of all operators to have a common CLI, IPFIX would
never happen if we wait for it to happen. Would the configuration be XML,
Text, SNMP,COPS,?
 
K.C.

----- Original Message ----- 
From: Reinaldo Penno <mailto:[email-masked]>  
To: K.C. Norseth <mailto:[email-masked]>  ; [email-masked]
<mailto:[email-masked]>  ; [email-masked]
<mailto:[email-masked]>  
Sent: Monday, February 11, 2002 9:57 PM
Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments
on the Architecture Draft)

Hello Norseth,
 
I think the right question to answer is not if it is "necessary", since you
can always pay somebody to be some sort of CLI configuration master and do
everything by hand.  
I think the right question is if it should be on the architecture document
or not and with whihch level of compliance. 
 
I think it should be on the arch document and maybe putting it with a SHOULD
instead of a MUST will make (most) people happy.
 
cheers,
 
Reinaldo

 -----Original Message-----
From: K.C. Norseth [mailto:[email-masked]]
Sent: Monday, February 11, 2002 8:25 PM
To: [email-masked]; [email-masked]
Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on
the Architecture Draft)

Will,
 
I agree. Let's go for the wg concensus.  What do people say?
 
| - the exporter configuration is out of the scope of this document   (the
exporter configuration out of band)
 
Configuration I think is out of scope, unless we hook it to an existing mib
or something.  I so, we can refer to that mib or process.

|- no transport negotiation (which transport)

we need to define the action of each transport type.

| - no capability negotiation

Nice, but necessary?  

K.C.

----- Original Message ----- 
From: Will Eatherton <mailto:[email-masked]>  
To: Reinaldo Penno <mailto:[email-masked]>  ;
[email-masked] <mailto:[email-masked]>  ;
[email-masked]
<mailto:[email-masked]>  
Cc: [email-masked] <mailto:[email-masked]>  ;
[email-masked] <mailto:[email-masked]>  ;
[email-masked] <mailto:[email-masked]>  
Sent: Monday, February 11, 2002 8:24 AM
Subject: Scope of IPFIX (was Answer to the recent comments on the
Architecture Draft)

Group,
 
Cisco's interest in IPFIX  was to help establish a non-proprietary protocol
similar to netflow but more flexible allowing us to add value to our
customers (and do so in a timely manner).  If IPFIX goes down a path along
the lines as being advocated recent threads by Reinaldo,  it is unclear if
the added burden of the protocol will be make it worth the benefits of a
non-proprietary protocol.  Given it seems I have seen roughly the same
conversation occur 3 times in past several day, It is unclear if further
email discussion on this topic will resolve the underlying question as to
the scope of IPFIX.  It seems time for an official call on what is in/out of
scope for IPFIX.  As has been mentioned here multiple times we would like to
hear :  
- the exporter configuration is out of the scope of this document   (the
exporter configuration out of band)

Will

I will not comment on that too much...Basically we are not here to
reverse-engineer Netflow, but to incorporate some good ideas from it.

Reinaldo

---

From: "Reinaldo Penno"<[email-masked]>
Date: Mon, 11 Feb 2002 21:59:35 -0800

inline...

-----Original Message-----
From: Will Eatherton [mailto:[email-masked]]
Sent: Monday, February 11, 2002 9:37 PM
To: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; [email-masked]
Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments

Lets be more clear cut then this. I dont want to have a major architectural
SHOULD on something we believe is fundamentally flawed  
 
I didn't hear any solid arguments saying why it's flawed. I heard 
 
"the sys admin can do it", 
"it's negotiation, not advertisement", 
"For the application of router export to a collector we are saying that
allowing UDP without required capability negotiation (as an option) is
important"
 
 and will occupy signficant group time to spec if it is left in.   
 
not true.
 
 We need a clear decision to move forward.  A spec that includes SHOULDS for
all proposed features is weak. 
 
huh ? No spec include SHOULDs for **all proposed features** as you said, and
IPfix is not doing this either.
 
Reinaldo
 
WIll

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf Of
Reinaldo Penno
Sent: Monday, February 11, 2002 8:57 PM
To: K.C. Norseth; [email-masked]; [email-masked]
Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments
on the Architecture Draft)

Hello Norseth,

 
cheers,
 
Reinaldo

 -----Original Message-----
From: K.C. Norseth [mailto:[email-masked]]
Sent: Monday, February 11, 2002 8:25 PM
To: [email-masked]; [email-masked]
Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on
the Architecture Draft)

Will,

 

Nice, but necessary?  

K.C.

----- Original Message ----- 
From: Will Eatherton <mailto:[email-masked]>  
To: Reinaldo Penno <mailto:[email-masked]>  ;

Group,

Will

Reinaldo

---

From: "Norseth, KC" <[email-masked]>
Date: Tue, 12 Feb 2002 09:50:20 -0500

Hi Mike.

A mib was not in our charter, but it would be useful to have.  We'll see
what the chairs have to say about that.  Nevil was going to write a section
about the relationship to RTFM, but that doesn't do what you suggest.

K.C.

|-----Original Message-----
|From: MacFaden, Mike 
|Sent: Tuesday, February 12, 2002 1:48 AM
|To: [email-masked]
|Subject: Re: [ipfix] Re: Scope of IPFIX (was Answer to the 
|recent comments on the Architecture Draft)
|
|
|On Mon, Feb 11, 2002 at 09:25:23PM -0700, K.C. Norseth wrote:
|>Answer to the recent comments on the Architecture DraftWill,
|>
|>I agree. Let's go for the wg concensus.  What do people say?
|>
|>| - the exporter configuration is out of the scope of this 
|document   (the exporter configuration out of band)
|
|
|Inband configuration makes the protocol more complex 
|as well as being prone to additional security risks.
|
|So I'd prefer in-band configuration not be part of the scope of the 
|current effort. 
|
|That said, I would not wan to rule out experimentation 
|or future ability to add such a feature in a way that
|can be cleanly discovered in a mixed envionment. 
|
|An SNMP MIB module should be made available to monitor
|the various components and to define, if any, standard 
|configuration objects.
|
|Mike MacFaden
|
|
|
|--
|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: Fred True <[email-masked]>
Date: Wed, 20 Feb 2002 03:15:01 -0500 (EST)

Folks,

A colleague of mine pointed me to the current discussion on expanding the
Cisco netflow protocol to allow better management of export configuration,
and I thought I'd add my $0.02.  I've read over most of the threads I
could find, but please let me know if I'm missing the gist of what has
been proposed, or forgive me if I'm not aware of the full context of the
discussion.

First, on a related note, I presume people are aware of the forthcoming v9
netflow export format.  This is the format they should have started with
(as opposed to v1, v5, v7 etc.), as it is self-describing (e.g. it
contains in-stream metadata telling client applications how to decode it)
and can handle arbitrary export fields.  They plan to use this for future
versions of netflow, packet header sampling, etc.

On the point of managing netflow data collection, I gather that the
proposal is to modify the netflow export protocol to be bi-directional, so
that a collector can send configuration messages to the routers rather
than relying on the current CLI commands.  I don't understand the point of
this.  Aside from requiring a whole lot of new development on the IOS
side, I don't think any of us who manage routers really want a new
paradigm for speaking to them, complete with requirements for reliability,
low overhead, security, etc.

What we've asked for in the past (and have not yet convinced them to
implement) is to have a netflow configuration MIB.  Everyone can deal with
SNMP, it's reliable and allows authentication, it allows you to read or
write configuration info, and it's easy to create lightweight SNMP clients
on the collector (or management workstation) side to control the
configuration, even in near-real-time (so, for example, you could tune
your sampling rate based on observed data).  It seems to me that leaving
the plans for v9 netflow export alone and using SNMP for dynamic netflow
configuration would be the most expedient and architecturally sound
solution.

-fred

--
Fred True				"My name is Ozymandias, King of Kings:
Internet and Network Systems Research	 Look on my works, ye Mighty,
AT&T Labs-Research, Florham Park, NJ	 and despair!"
[email-masked]					-P. B. Shelley

--
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: "Norseth, KC" <[email-masked]>
Date: Wed, 20 Feb 2002 08:42:21 -0500

|-----Original Message-----
|From: Fred True [mailto:[email-masked]] 
|Sent: Wednesday, February 20, 2002 1:15 AM
|To: ipfix
|Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent 
|comments on the Architecture Draft)
|
|
|Folks,
|
|A colleague of mine pointed me to the current discussion on 
|expanding the Cisco netflow protocol to allow better 
|management of export configuration, and I thought I'd add my 
|$0.02.  I've read over most of the threads I could find, but 
|please let me know if I'm missing the gist of what has been 
|proposed, or forgive me if I'm not aware of the full context 
|of the discussion.
|
|First, on a related note, I presume people are aware of the 
|forthcoming v9 netflow export format.  This is the format they 
|should have started with (as opposed to v1, v5, v7 etc.), as 
|it is self-describing (e.g. it contains in-stream metadata 
|telling client applications how to decode it) and can handle 
|arbitrary export fields.  They plan to use this for future 
|versions of netflow, packet header sampling, etc.

NetFlow v9 is only a possibilitry for IPFIX.  It is far from being decided.

|On the point of managing netflow data collection, I gather 
|that the proposal is to modify the netflow export protocol to 
|be bi-directional, so that a collector can send configuration 
|messages to the routers rather than relying on the current CLI 
|commands.  I don't understand the point of this.  Aside from 
|requiring a whole lot of new development on the IOS side, I 
|don't think any of us who manage routers really want a new 
|paradigm for speaking to them, complete with requirements for 
|reliability, low overhead, security, etc.

Bi-directional is only a MAY.  IPFIX is a lot more than that.  IPFIX will
hopefully contain the fixes to the procedure that NetFlow v5-v8 lack.

|What we've asked for in the past (and have not yet convinced them to
|implement) is to have a netflow configuration MIB.  Everyone 
|can deal with SNMP, it's reliable and allows authentication, 
|it allows you to read or write configuration info, and it's 
|easy to create lightweight SNMP clients on the collector (or 
|management workstation) side to control the configuration, 
|even in near-real-time (so, for example, you could tune your 
|sampling rate based on observed data).  It seems to me that 
|leaving the plans for v9 netflow export alone and using SNMP 
|for dynamic netflow configuration would be the most expedient 
|and architecturally sound solution.

A MIB would be wonderful.  Currently it is not in the scope of the charter,
but it is not left out yet.

Whether IPFIX adopts NetFlow, LFAP,DIAMETER, CRANE or whatever, I want it to
be a more complete,robust solution than what is currently in use.

PS. New documents coming out shortly.

K.C.

|-fred
|
|--
|Fred True				"My name is Ozymandias, 
|King of Kings:
|Internet and Network Systems Research	 Look on my works, ye Mighty,
|AT&T Labs-Research, Florham Park, NJ	 and despair!"
[email-masked]					-P. B. Shelley
|
|
|--
|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: "Norseth, KC" <[email-masked]>
Date: Wed, 20 Feb 2002 10:42:12 -0500

|-----Original Message-----
|From: Randy Bush [mailto:[email-masked]] 
|Sent: Wednesday, February 20, 2002 8:32 AM
|To: Norseth, KC
|Cc: 'Fred True'; ipfix
|Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the 
|recent comments on the Architecture Draft)
|
|
|> A MIB would be wonderful.  Currently it is not in the scope of the 
|> charter,

There is an unwritten rule that every group needs a mib.  In the case of
NetFlow (v5-v8), there has been a great cry for a mib by customers of some
kind. We recognize this void. What will these mibs do?  How do they relate
to RTFM? Will they become part of the charter? That is still in the air.  We
just have not closed our minds to the idea.

|but inventing a new configuration protocol is?

We have not said we are inventing a new protocol. What we are doing is
trying to select from existing protocols, the best protocol.  To say that
NetFlow v9 is it without doing a valid selection process would be wrong.

K.C.

|randy
|

---

From: Dave Plonka <[email-masked]>
Date: Wed, 20 Feb 2002 11:14:12 -0600

Please note the following reminder from our AD (which I'm forwarding
because it bounced to the list admin)...

----- Forwarded message from [email-masked] -----

From: Randy Bush <[email-masked]>
References: <[email-masked]>
Message-Id: <[email-masked]>
Sender: Randy Bush <[email-masked]>
Date: Wed, 20 Feb 2002 07:31:54 -0800

> A MIB would be wonderful.  Currently it is not in the scope of the

but inventing a new configuration protocol is?

randy

----- End forwarded message -----

Randy - this got bounced to me because of our subscriber-only list
policy...  let me know if you'd prefer to be subscribed by this email
address (or both).

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

---

From: Benoit Claise <[email-masked]>
Date: Thu, 21 Feb 2002 13:09:59 +0100

Hi Fred,

Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments
on the Architecture Draft)

From: Fred True ([email-masked])

Date: Wed Feb 20 2002 - 02:15:01 CST

Folks,

A colleague of mine pointed me to the current discussion on expanding
the

and I thought I'd add my $0.02.  I've read over most of the threads
I

could find, but please let me know if I'm missing the gist of what
has

been proposed, or forgive me if I'm not aware of the full context of
the

discussion.

First, on a related note, I presume people are aware of the forthcoming
v9

netflow export format.  This is the format they should have started
with

contains in-stream metadata telling client applications how to decode
it)

and can handle arbitrary export fields.  They plan to use this
for future

proposal is to modify the netflow export protocol to be bi-directional,
so

than relying on the current CLI commands.

No we don't want to have a bidirectional protocol.

From http://ipfx.doit.wisc.edu/list/ipfix/archive/0705.html:

-  Configuration.  Not in charter, at this stage we need
to

document what current flow export systems do. (other 'not-in-charter'

things include 'what's not done well in existing flow
export systems')

Regards, Benoit

I don't understand the point of

this.  Aside from requiring a whole lot of new development on
the IOS

implement) is to have a netflow configuration MIB.  Everyone can
deal with

SNMP, it's reliable and allows authentication, it allows you to read
or

write configuration info, and it's easy to create lightweight SNMP
clients

your sampling rate based on observed data).  It seems to me that
leaving

solution.

-fred

--

Fred True
"My name is Ozymandias, King of Kings:

Internet and Network Systems Research    Look on my
works, ye Mighty,

AT&T Labs-Research, Florham Park, NJ     and
despair!"

[email-masked]
-P. B. Shelley