Subject: [IPFIX] Should the IPFIX MIB be writeable?

From: "Thomas Dietz" <[email-masked]>
Date: Thu, 19 Oct 2006 04:19:05 +0200

Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define the
row status and how it must be set and what each setting means. Furthermore
we need to carefully elaborate the conformance section and need to discuss
every writeable object in the security considerations. So it is a really big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is really
useful to have the MIB (especially the EXPORTER MIB) writeable than we would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

-- 
Thomas Dietz                       E-mail: [email-masked]
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 19 Oct 2006 07:32:22 +0200

My opinion as a contributor is that write operations should be allowed
in this case. The analogy is the MIB objects that allow the control of
destination and filtering of the SNMP notifications. The SNMP framework
does allow for controls on these, the are several MIB modules that
include such objects and there is enough documentation and operational
experience in the SNMP world to show how this needs to be done. 

Dan

> -----Original Message-----
> From: Thomas Dietz [mailto:[email-masked]] 
> Sent: Thursday, October 19, 2006 4:19 AM
> To: [email-masked]
> Subject: [IPFIX] Should the IPFIX MIB be writeable?
> 
> I want to summarize 2 points that arose in the current 
> discussion of the IPFIX MIB and poll the list for comments 
> how we should proceed with it.
> 
> It is a fundamental decision if we should allow the IPFIX 
> devices to be configured via SNMP. For the collector there is 
> not much to configure but for the exporter there are many 
> things that could be set-up, changed and deleted.
> 
> Making the MIB writeable would have the consequence that we 
> need to carefully review the status for each variable and 
> table. We must define the row status and how it must be set 
> and what each setting means. Furthermore we need to carefully 
> elaborate the conformance section and need to discuss every 
> writeable object in the security considerations. So it is a 
> really big effort to make the MIB writeable so that it is 
> secure to use it.
> 
> Nevertheless, if the majority on the list has the opinion 
> that it is really useful to have the MIB (especially the 
> EXPORTER MIB) writeable than we would take that effort.
> 
> Please keep in mind that the decision we take here would also 
> affect the PSAMP MIB accordingly.
> 
> Awaiting your comments,
> 
> Thomas
> 
> --

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 19 Oct 2006 07:32:22 +0200

Dan

---

From: "Zseby, Tanja" <[email-masked]>
Date: Thu, 19 Oct 2006 11:46:19 +0200

Hi Thomas,

in my opinion it would be extremely useful to have a writeable MIB that
would allow exporter configuration by SNMP.

Kind regards,
Tanja

---

Date: Thu, 19 Oct 2006 12:17:51 +0200

Message-D7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k

------=_NextPart_000_0051_01C6F379.3724F880--

--===============2143201437==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============2143201437==--

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 20 Oct 2006 15:03:02 +0200

If we believe that a writeable MIB will not be used, than better let us
not define it at all. 
 
However, if something else will be used for configuration, it will need
a standard definition for interoperability, and some of the aspects of
this discussion cannot be eluded completely. 
 
Dan

  _____  

	From: Benoit Claise [mailto:[email-masked]] 
	Sent: Friday, October 20, 2006 2:33 PM
	To: Thomas Dietz
	Cc: [email-masked]
	Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?

	Dear all,
	
	If the question is: "would you like to have a writable MIB",
the answer will probably be: "sure, it's useful/nice-to-have!"
	It's a logical answer when you offer the choice of a solution
with more features compared to a solution with less features.
	
	While I don't want to restart a discussion on SNMPset ("SNMPSet:
can it be saved?
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introductio
n),  let me ask the question differently: will this read-write MIB be
practical and useful? 
	
	Let me concentrate on the Exporter MIB, as the Collector MIB
should be read-only (what can we configure on the collector side?)
	Even if the information related to the IPFIX exporting process
(such as where to export, which transport protocol, which port, backup
or not, template retransmission timeout, etc...) is somehow pretty
static in networks, this type of configuration via SNMP might be useful.
	However, I'm not sure about the configuration of everything that
relates to metering process as it's getting pretty complex.
	For example, is it practical to specify via SNMP all the
possible the template definition from Flexible NetFlow?
	     Flexible NetFlow =
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd80
4be091.shtml
	This would require the ipfixTemplateTable to have the following
indexes: 
	    the transport session source IP address
	    the transport session destination IP address
	    the transport session source port
	    the transport session destination port
	    the observation domain Id
	    the template Id
	    the information element position
	A table with 7 indexes. Sure, it's possible but this starts to
be quite a complex MIB
	Some more remarks that will add to the complexity:
	- In ipfixTemplateTable, we still need to find a way via SNMP to
express whether a specific I.E. is a flow key or not
	- We have the choice of template versus options template. So an
extra table for options template is required. In this table, as we can
have multiple scope information elements, we need a way to express
whether an I.E. is a scope or not (similar to flow key in
ipfixTemplateTable)
	- This implies that Template Ids are assigned by the collector
if the collector creates new templates.
	- The collector configures the template Ids. 
	  Note: remember that the template Id are unique per observation
domain and per transport session. 
	  So now, if the SCTP association goes down, what should the
collector do?
	    1. erase all the templates on the exporter, and reconfigure
them? This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process
	    2. wait for the template retransmission? What if the
metering process went down and the template id allocation changed. Shall
the collector update his MIB?
	    3. something else?
	- As Thomas mentioned: "We must define the row status and how it
must be set and what each setting means."
	
	To summarize, my views are:
	Even if this might be an interesting little challenge to write
this MIB, I'm questioning this practicality/complexity... and as a
consequence its chances to be implemented if everything is read-write 
	However, I agree with the configuration of the exporting process
information
	Finally I agree that a way to configure the templates is needed,
I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
	
	Potential solution:
	Could we have specify the full exporter MIB as writable, but
limit the metering part to read-only in the "Units of Conformance"?
	That way, the end customers will decide by pushing or not the
vendor: SNMP versus NETCONF versus CLI
	
	Regards, Benoit.

		I want to summarize 2 points that arose in the current
discussion of the
		IPFIX MIB and poll the list for comments how we should
proceed with it.
		
		It is a fundamental decision if we should allow the
IPFIX devices to be
		configured via SNMP. For the collector there is not much
to configure but
		for the exporter there are many things that could be
set-up, changed and
		deleted.
		
		Making the MIB writeable would have the consequence that
we need to
		carefully review the status for each variable and table.
We must define the
		row status and how it must be set and what each setting
means. Furthermore
		we need to carefully elaborate the conformance section
and need to discuss
		every writeable object in the security considerations.
So it is a really big
		effort to make the MIB writeable so that it is secure to
use it.
		
		Nevertheless, if the majority on the list has the
opinion that it is really
		useful to have the MIB (especially the EXPORTER MIB)
writeable than we would
		take that effort.
		
		Please keep in mind that the decision we take here would
also affect the
		PSAMP MIB accordingly.
		
		Awaiting your comments,
		
		Thomas

  _____

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 20 Oct 2006 15:03:02 +0200

Dan

  _____  

	Dear all,

	

	Potential solution:
	
	Regards, Benoit.

		

		
		
		Awaiting your comments,
		
		Thomas

  _____

---

From: Juergen Quittek <[email-masked]>
Date: Sat, 21 Oct 2006 02:05:01 +0200

Dear all,

Please let's not spend too much time on discussing whether or
not SMIv2 is a good language for defining device configuration
interfaces.

As contributors have said before, there is no strict reason for
constraining the MIB modules to be read-only. (However, we will
give implementers the option to build them read-only.)

So let's focus on the open issue.  The next version will be
posted on Monday and it probably will not yet be affected by
this discussion.  It will still be an individual draft.

Based on this draft, I would like the authors to post a concrete
suggestion on this list stating which parts of the two MIB modules
should be writeable.

Please post your suggestion in the week before the IETF meeting.
Then we can start the discussion on the list and try to get close
to a consensus during our session in San Diego.  After the San
Diego meeting the results of our discussion should be reflected
by an update of the MIB modules to be posted as WG draft.

Thanks,

    Juergen

--On 20.10.2006 16:10 Uhr +0200 David Harrington wrote:

>
> Hi,
>
> The question that was originally proposed was "should the IPFIX MIB be writable?"
> I believe there would be benefit to making IPFIX manageable.
> Since you have defined a MIB module to perform management, it seems a simple extension to make some of the objects writable, rather than requring a whole extra protocol be supported to configure ipfix parameters.
>
> Has anybody argued that every aspect of IPFIX should be configurable using the MIB module? I haven't seen anybody make such an argument, and I am not making such an argument. Deciding that none of the objects CAN be used by an application to modify the
> configuration of IPFIX may make it difficiult to configure ipfix functionality.
>
> Some of the questions below deal with anomalies, such as SCTP going down. The question is not about SNMP, it is about interoperable IPFIX behavior and should be addressed regardless of the management protocol being used to do configuration.
> If a collector uses Netconf to configure the templates, and SCTP goes down, what should the collector do? delete the templates and reconfigure them from scratch? wait for the template retransmission? something else? What if CLI is used? The fact that
> some of the config is done using SNMP should not be the telling factor; the appropriate behavior should be specified regardless of config protocol.
>
>
> Even if template management were to be addressed, there are ways to reduce the complexity of configuration.
>
> The question that should be asked is "which aspects of ipfix should be made manageable, and how?". Such a discussion should consider issues of persistence, fate-sharing, static vs. dynamic aspects of ipfix, and so on. And thsi discussion should happen
> whether the MIB module is made writable or not.
>
>
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
>
>
>
>
> __________________________________________________
> If the question is: "would you like to have a writable MIB",  the answer will probably be: "sure, it's useful/nice-to-have!"
> It's a logical answer when you offer the choice of a solution with more features compared to a solution with less features.
>
> While I don't want to restart a discussion on SNMPset ("SNMPSet: can it be saved? http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction),  let me ask the question differently: will this read-write MIB be practical and useful?
>
> Let me concentrate on the Exporter MIB, as the Collector MIB should be read-only (what can we configure on the collector side?)
> Even if the information related to the IPFIX exporting process (such as where to export, which transport protocol, which port, backup or not, template retransmission timeout, etc...) is somehow pretty static in networks, this type of configuration via
> SNMP might be useful.
> However, I'm not sure about the configuration of everything that relates to metering process as it's getting pretty complex.
> For example, is it practical to specify via SNMP all the possible the template definition from Flexible NetFlow?
>      Flexible NetFlow = http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
> This would require the ipfixTemplateTable to have the following indexes:
> A table with 7 indexes. Sure, it's possible but this starts to be quite a complex MIB
> - In ipfixTemplateTable, we still need to find a way via SNMP to express whether a specific I.E. is a flow key or not
> - We have the choice of template versus options template. So an extra table for options template is required. In this table, as we can have multiple scope information elements, we need a way to express whether an I.E. is a scope or not (similar to flow
> key in ipfixTemplateTable)
> - This implies that Template Ids are assigned by the collector if the collector creates new templates.
>   Note: remember that the template Id are unique per observation domain and per transport session.
>   So now, if the SCTP association goes down, what should the collector do?
>     1. erase all the templates on the exporter, and reconfigure them? This implies that if only the connection is down, not the metering process, then this action basically stopped the metering process
>     2. wait for the template retransmission? What if the metering process went down and the template id allocation changed. Shall the collector update his MIB?
>     3. something else?
> - As Thomas mentioned: "We must define the row status and how it must be set and what each setting means."
>
> Even if this might be an interesting little challenge to write this MIB, I'm questioning this practicality/complexity... and as a consequence its chances to be implemented if everything is read-write
> However, I agree with the configuration of the exporting process information
> Finally I agree that a way to configure the templates is needed, I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
>
> Potential solution:
> Could we have specify the full exporter MIB as writable, but limit the metering part to read-only in the "Units of Conformance"?
> That way, the end customers will decide by pushing or not the vendor: SNMP versus NETCONF versus CLI
>
> Regards, Benoit.
>
>
>
> __________________________________________________
>

---

From: Juergen Quittek <[email-masked]>
Date: Sat, 21 Oct 2006 02:05:01 +0200

Dear all,

Thanks,

    Juergen