Re: Whitepaper on XML-based Network Management

[Michael MacFaden <mrm@riverstonenet.com>]

At 03:46 PM 7/30/2001 -0700, R.P. Aditya wrote:
>at the risk of pulling the discussion into yet another direction, managing
>N-different vendor specific MIBs is IMO more difficult than managing
>N-different DTDs. For collecting "bulk" amounts of data from a network device,
>SNMP has problems due to the udp transport that would be nice to get away
>from.

But it solves the multi-manager issue, has hundreds of standard mib modules
so one doesn't necessarily have to learn so many vendor mib modules unless
one buys a device that does not implement them, it solves fine grain user 
level control, has built in security, and it works when the network is in worse 
shape and doesn't give up like TCP,  is integrated with the monitoring and 
debug side, has over ten years of great interoperability and so on. 

It isn't such a simple trade-off, this is indeed an iceberg of a problem.


>> yes.  there are said to be O(10^5) isps out here.  probably O(10^1) do
>> automated configuration.
>
>We're hoping that more isps will do automated configuration if they are given
>better tools and UI's. I also hope that the O(10^1) that do automated config
>are the ones pressing the vendors for these changes...

Keeping things simple, easy to implement and debug are paramount.
I doubt switching to xml will solve the configuration problem any better
than it is currently done today. The problems inherent in configuring IP networks
are not in text vs binary or in SMI vs XML format. That is low hanging fruit that
could be solved the existing management framework today if we so choose to.

The problem with configuration is huge.

1) in the undocumented side-effects of changes and in 
the dependency (implicit or explicit) that go with configuration in complex networks of
multiple devices, multiple versions of software (from one vendor or others)
and in the topology itself. 
2) That which is being changed was often designed
without thought for configuration much like security issues (BGP or MPLS session
maintenance when switching between software versions/headless upgrade)
Do we really want to state redundancy at the TCP session level or shouldn't the protocol
support the notion of the operation?). Then there is simple operator error.

CLI/SNMP/...will still have these issues:

3) have to negate the former if it exists
4) knows what the default value is if the command is removed/added
  (which can change between releases of a given vendors code)
5) does the change commit immediately or after some "commit" command
6) can the change be rolled back or coordinated across a set of devices.
7) will this change blow up the connection from the remote mgmt station?
8) how often can a given change be made?
9) how many instances of a given change can be made?

While I think XML is great and can be integrated into the
Internet Standard Management Framework, it will need alot of work
to make it interoperable and to be able to express the features we take
for granted (that work) today. 

SNMP is being used for configuration, just not IP routed backbone networks
but they are in HFC networks and MAN/L2 networks where automation is
*mandatory* since there are more devices than in those large backbone 
networks and *easier*  to automate since the devices/topology are often simpler.

Sadly the MIB modules for routing to date have been well, lacking major 
functionality. BGP MIB hasn't even have confederations till the new drafts now.
CLI's as I've seen are better, but also very buggy too. XML won't solve
any buggyness issues magically.

10) Another problem is that for any given technology, expect the vendors to only
half implement it. I'm not aware of too many vendors that publish their
AGENT-CAPABILITIES mib modules (you can find one on www.nmops.org though)

Lastly, some discussion of the configuration process itself can be found in: 
http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-05.txt

Regards,
Mike MacFaden

PS - So Randy,  yes, bring that sledge but bring it to EOS or SMING 
as I don't see any proposal that fixes the simple text thing.