[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: the future of SNMP
I've been working with a group putting together a new management
focusing first on network configuration. There is a BOF on monday
at the IETF, and here is the URL for the agenda...
I'm pretty excited about the approach because it addresses many
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
1) it uses "standard" security mechanisms for authentication,
and integrity, leaving authorization to protocol specific
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
mechanisms for authentication, privacy, and integrity are
on the transport connection, not on the channels, so
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
b)there will be a channel to receive notifications (if
that occur while the transport connection is up.
seem trivial, but it allows a management app
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
data such as executables (again, don't need to
use some other
mechanism such as FTP to perform this
d)there will be a channel for control so that the status can
checked on operations that are taking a long
time to be
performed. These and operations that are sending
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
is a little out of balance with its coverage. But, if you tone down
the XML and look at the fundamental differences between this
and other management protocols, I believe you will see that it
the issues which are still with us in existing management
At 12:11 PM 3/3/2003 -0500, Harrington, David wrote:
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.
From: Wes Hardaker
Sent: Friday, February 28, 2003 10:43 AM
To: B. Levin
Cc: Glenn Waters; firstname.lastname@example.org
Subject: Re: the future of SNMP
- >>>>> On Fri, 28 Feb 2003 07:00:45 -0800 (PST),
"B. Levin" <email@example.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
- support. That is hardly what I think needs to be optimized for
- this case (certainly it's impacted, but I'm much more concerned
- the 10000 agents that it's speaking with than the 1 NMS
- Wes Hardaker
- Network Associates Laboratories
/david t. perkins