For the most part, the CLI is still king. And command-line interfaces are, for the most part, proprietary -- different from vendor to vendor and, in some cases, different from product to product, release to release. This is not to say the CLI is bad; it's ASCII and as such is far easier for us mere mortals to understand than are SNMP ASN.1 notations. In fact, we have ASCII to thank for the fact that small variations don't bother us much. We simply adjust. ASCII makes scripting possible. With ASCII, a handful of experts can, without standards, change the configuration of a network to meet a policy goal. And with ASCII and a lack of a standards, variations can exist.
For many, Cisco Systems' interface has become the default CLI standard by virtue of the company's massive installed base. Even Enterasys Networks and Foundry Networks have standardized on the Cisco CLI. But there are problems: Cisco's CLI isn't the same from product to product and version to version. It's plagued by variations in the command structure and a generally clunky updating process. We've become used to these flaws, but a person could get used to banging his head into a wall, too. Juniper Networks and Extreme Networks, meanwhile, have built their CLIs from the ground up. These are hierarchal, well-organized and, most important, the same across all their products.
Don't get the idea that we consider the CLI a panacea. It isn't -- it's just an access method. Speaking of which, Juniper has added an XML interface for configuring its routers; this is a great idea as far as an access method goes but doesn't do anything to help standardize configuration procedures. Nor does XML help in defining and storing the configuration policy.
Bottom line, the practice of accessing the network infrastructure by various methods to change configuration is not only holding back true policy management, it is the completely wrong approach. To be able to manage heterogeneous networks, PBNM (policy-based network management) software must support an ever-widening circle of infrastructure device makes, models and versions. And when PBNM vendors release new software, they need to retrotest all the existing makes, models and versions of devices supported. When an infrastructure device vendor offers a new make, model or version, the coding, testing and retrofitting have to happen all over again. Ouch.
Policy management is about creating applications on a stable network. So while offering QoS (Quality of Service), security and VPNs is touted as the way for service providers to make money, getting a network stable -- and keeping it that way -- is a prerequisite. This is not an easy thing to do without standards.
Other factors to consider: Having standards in place increases the likelihood that it will be economically worthwhile for third-party developers to invest in building network-management tools that users can buy. With standards, these tools can manage a wider range of products over a longer period of time, thereby giving third-party developers a better return on their investments. Furthermore, standards are designed for machine-to-machine communication, as opposed to human-to-machine communication, as is the case with CLIs. These machine-to-machine protocols also make developing PBNM systems easier, and make managing many systems at one time more doable; they scale better.
A separate issue with these new technologies is that there are so many of them. Some complement one another, while others overlap functions significantly. This produces confusion in the vendor and user communities. Vendors do not know what to implement, and customers are not always aware of what to ask for. What often happens is that vendors implement some of each, and customers ask for everything. The problem this produces for the application vendors and for users is that it nearly eliminates the advantages of standards just described.
REPORTS
ANALYTICS
Follow 
