Operator requirements

[Phil Shafer <phil@juniper.net>]

"Wijnen, Bert (Bert)" writes:
>So, how does XML (or any new technology for that matter)
>help us address the Operator Requirements.

The main theme behind many of the requirements I get is to allow more
junior NOC folks to do more with less training, allowing providers to
get better mileage out of their people.  "Take the heroics out of
network management", as one customer put it.  Providers are getting
nailed with employee costs, employee turnover, network fragility, and
the dearth of good configuration/provisioning tools.  Junior employees
need to be safely confined in applications that limit their ability to
damage the network. These applications take the operator's changes and
propagate them throughout the network using locking, transactions, and
automatic recovery and rollback.  Lack of automation and lack of
automation support constitute large barriers to both tool vendors and
in-house tool maintainers.

Most (if not all) configuration tools in use in provider networks
are expect based, which makes them both fragile (if something
changes) and expensive (when something changes). I don't see the
question as being xml .vs. snmp, but xml
.vs. expect. The question of snmp .vs. expect seems to have already
been fought. The use of expect seems to have been driven by:

- need for immediate access to emerging features
  - before vendor implements proprietary mibs
  - before standard mibs are defined
- need for complete information
  - full use of 'extensive' output
- need for exact control over the mapping from abstraction to
  implementation 
  - loss of information in abstract models
  - complexity and transparency

In reaching for expect, the provider or tool maker is giving up vendor
independence for exact control. This seems like a reasonable tradeoff
to me, but the maintenance costs for expect can be large.

In this light, XML gives you a number of features:

- good match between hierarchy of the data and the 
  hierarchical capabilities of XML
- full access to operational and configuration input and output
  - vendor/platform/version-specific content
- fully specified content
  - defined in XML Schemas
- well supported technology
  - content is easily parsed with any XML parser
  - content is easily manipulated with XML tools
- content can evolve
  - new tags are ignored
  - old tags can be emitted while being deprecated

Most of all, XML is live data. Data can be retrieved from a device,
stored in a database, run through an XSLT script, and rendered in text
(CSS), graphics (SVG), or PDF (via XSL-FO). The data can be parsed in
its XML form to libraries that do these manipulations using standard
APIs (SAX and DOM) without inspection or pre-processing.

>but this is at least an initial list that I have
>seen mentioned and that we need to addres:

The shocking bit about this list is the primitive nature of the
required operations. Operators are not asking for the moon here; they
simply want to be able to get full and partial datasets on and off the
box in a precise and dependable manner. Obliging these simple
requirements should not be difficult in any technology.

>- dump/save configuration
>- load/restore configuration
>- activate a new configuration at time X or at reboot
>- rollback a configuration
>- network level configuration, as in the following points
>  - mutli-device transactions (e.g. activate a specific
>    configuration at mutliple devices in sync
>  - rollback at multiple devices in sync
>- who can do what on which devices, as in the
>  following points
>  - what are the identities of who can do what
>  - how can they be grouped
>  - how do we do access control fo such groups
>- transport security
>  - how is the transport properly secured

The key seems to lie in how these primatives will be used. While
configuration archival and restoration is the immediate goal, we need
to look ahead toward an environment of increased automation and
provisioning. 

The most common usage I see is translating databases that describe the
provider's network into configuration and getting that configuration
onto the devices. For automation to prove valuable, the provider (and
their tools) must have one or more databases that describe the
configuration they want to automate. Then the issue is how to deploy a
set of (possibly multi-device) configuration changes. This involves
both turning the vendor-neutral database into vendor-specific syntax
and passing it to the device, using multi-device transactions.

XML is an ideal technology to solve this since data can be retrieved
from the database in XML form, translated using XSLT scripts (that can
be easily customized for the provider's network), and passed to the
device using any of the XML RPC technologies.

Thanks,
 Phil

--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>