Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

F E A T U R E

No Standards, No Policy, No Management

January 21, 2002
By Bruce Boardman


	Print Full Article Print This Page Download the PDF E-Mail This URL

When it comes to policy-based management, standards have not yet taken hold. It's not that standards bodies don't exist -- they do, and they've been on the case for a number of years. But just recently these groups have begun to address the problems of managing larger and more complex networks.

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.