[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: the future of SNMP

HI,

I've been working with a group putting together a new management protocol
focusing first on network configuration. There is a BOF on monday morning
at the IETF, and here is the URL for the agenda... http://www.ietf.org/ietf/03mar/netconf.txt

I'm pretty excited about the approach because it addresses many of
the concerns in message from Juergen and in the one below. And it
addresses other high level issues.

There are several key reasons the "netconf" approach is different.

1) it uses "standard" security mechanisms for authentication, privacy,
   and integrity, leaving authorization to protocol specific mechanisms.
2) it uses the network very efficiently (it's a good citizen)
3) it uses a single transport connection over which multiple
   channels are used for specific purposes. (and note, the security
   mechanisms for authentication, privacy, and integrity are done
   on the transport connection, not on the channels, so security
   set up is done only once)
4) a)there will be a channel for operations, such as GET/SET/etc
     The operations can include a bulking response.
   b)there will be a channel to receive notifications (if permitted)
     that occur while the transport connection is up. (this may
     seem trivial, but it allows a management app independence from
     other mechanisms, and doesn't require modification to notification
     distribution configuration like is currently required with SNMPv3)
   c)if needed, there is a channel to upload or download bulk binary
     data such as executables (again, don't need to use some other
     mechanism such as FTP to perform this operation)
   d)there will be a channel for control so that the status can be
     checked on operations that are taking a long time to be
     performed. These and operations that are sending a
     large response can be aborted.

So, I do hope you will be able to come to the BOF and read the I-D
that has been written. One warning.... the technology that is used
to implement this protocol is based on XML, and the current document
is a little out of balance with its coverage. But, if you tone down
the XML and look at the fundamental differences between this proposal
and other management protocols, I believe you will see that it addresses
the issues which are still with us in existing management protocols.

At 12:11 PM 3/3/2003 -0500, Harrington, David wrote:
Hi,
 
I guess this as good a place as any to jump into this thread.
 
#1 For any solution to work effectively, it will need to be supported by both the agent and the manager. Fixing it on one side only is not an option.
 
#2 It isn't enough to deliver a large blob of data to an NMS; the NMS needs to be able to break it out and process it to display and/or convert the raw data into information to make the blob of data meaningful to an operator. Without that step it is not a useful solution.
 
#3 using another protocol to transport gathered data requires defining some mappings to coordinate that usage. It is not as simple as defining a mib and then just saying "send it over FTP". What are the possible error conditions that could occur, and how should they be handled? There have been earlier attempts to send file of gathered data, such as RFC2513, and these have not been widely deployed to my knowledge. I would assume that if this design brought great beneift to the SNMP community, the approach would have been extended for use in other scenrios. Do we know why this never gained much acceptance?
 
#4 As Juergen pointed out, the security mapping between FTP and SNMPv3 will be non-trivial. As a vendor, it is difficult for me to convince a customer they should buy our products because we have SNMPv3-strength security and then suggest they should use a non-secure protocol like FTP to ship bulk data. Even if the file could be transported over SSH or SSL or a VPN or IPSec, no mappings have been proposed about how to do that in a standardized manner, or what rules need to be followed to balance the security between the two. Which security precautions must be follwoed sending bulk responses to a noAuthNoPriv request? which are acceptable for an authPriv response? Can they be mixed into the same buffer?
 
#5 Even if the file can be transported securely using the correct message security level, a file-based transfer does not have user-specific access control like VACM. I haven't read the mib recently; have mechanisms been defined for coexistence with VACM?
 
#6 As Juergen pointed out, adding new protocol additions may require nothing more than a recompile, because many agents and applications use a toolkit and if the toolkit has the extra functionality the agent and manager will get it by default. However, I will point out that #2 still applies. Even if I can add a protocol extension with no work, I still need to modify my code to take advantage of the feature. For an NMS, this will include probing to determine whether the functionality is supported by different agents. If the SNMP stack provides the feature if a developer calls the appropriate API, then the developers need to be educated about the relative benefits of the new solution so they will call the new API rather than just continuing to call the getNext() API for all devices. It is easier to just call the same API for all tables rather than having to test and debug conditional branches of code. I am not convinced that GetBulk has seen wide usage by major NMS vendors yet, for similar reasons.
 
dbh
 
 -----Original Message-----
From: Wes Hardaker [mailto:hardaker@tislabs.com]
Sent: Friday, February 28, 2003 10:43 AM
To: B. Levin
Cc: Glenn Waters; eos@ops.ietf.org
Subject: Re: the future of SNMP
>>>>> On Fri, 28 Feb 2003 07:00:45 -0800 (PST), "B. Levin" <bryan_levin@yahoo.com> said:

B> the MIB solution that I proposed could be implemented
B> (at the NMS side) even on a 10 yr antique NMS.

I'm confused at why there is an argument over what the NMS could
support.  That is hardly what I think needs to be optimized for in
this case (certainly it's impacted, but I'm much more concerned about
the 10000 agents that it's speaking with than the 1 NMS box).

--
Wes Hardaker
Network Associates Laboratories
Regards,
/david t. perkins