Min Qiu wrote on 04/15/2005 02:26 PM:
> This may bring us back to the previous modeling discussion...
> Since the goal is automation, the NMS will be the system
> talk to the device via CLI, SNMP or API.
Well, in the cases I've seen, the vendor's $$$ NMS is the only system
that is able to do transactions, so I think we're back to the
discussion of vendor systems versus a vendor-neutral central system.
> The 3 phase commits can be in the NMS or router, it does not
> matter. Of cause, implement it in NMS will make it more genernal(a
> modeling topic)
If we're still talking vendor NMS here, the problem is that they
generally only support a limited subset of the router capabilities --
usually just simple tasks like subscriber management or service
management (adding an LSP, etc.).
I've yet to be able to usefully integrate with a vendor NMS. They all
talk about open "northbound APIs", but in practice, this is usually
more like, "here's our schema; good luck," or, "we use undocumented
EJBs (version 1.1 on proprietary app-server)."
So, beyond the cost of these add-on systems, I'd generally prefer to
just deal with the routers themselves, rather than trying to figure
out how to interface with the vendor NMS; how to cram their idea of a
network model into my own; and how to deal with the lag between router
OS upgrades and NMS version upgrades that can control the new features.
--kirby
References:
|
|
