Re: How does XML help Network Operators

[Larry Menten <lmenten@lucent.com>]

Bert,

By the way, IMHO we ought to be equally, if not more concerned,
with the needs of the enterprise as a whole and not just
the interests of the network operator.  I can't help but feel
that there ought to be some needs related to user provisioning
on this list, as well.

The main theme of the discussion below is that there is a strong
unification trend underway, spanning the representation, storage,
and manipulation of data, the management of SP/enterprise-wide
security, and remote access to information.  One of our roles
might be to determine how the XML-based evolution of network management
achieves this unification.

The following are some ideas as to how XML and XML-mgt-related
stadnards activity can be applied to address these network
operator needs:

> - dump/save configuration
> - load/restore configuration
0. There is an excellent opportunity for a standards effort to
simplify management of a multi-vendor/multi-product family
network.

Where common models can be identified across the implementations
of many vendors, XML namespaces, XSLT transformations,
and XML-Schema validation, and the native DBMS support for XML
developed by Oracle and others can be employed to:

1. Consolidate both standard elements and vendor extensions
into a single configuration tree.

2. Extract and validate a configuration for a particular type
of device from the combined schema in a data-driven way
(XSL stylesheets and XML-Schema.)

3. This extraction (restore) from the consolidated subtree can be performed
by the device itself, improving the scalability and extensibility
of the scheme and localizing the details of a particular device
to the device itself.

4. If the configuration state can be extracted from the device in
XML form, then the configuration can be presented to a user
using web-based tools such as .Net for viewing and modification.
This is the natural next step in the trend towards web-based
management, and unlike some existing schemes, does not involve
proprietary "glue" in the managed element. (Gores some oxes.)

5. If necessary, the saved state of a device can be stored in,
for example, an Oracle database and used for later state restoration,
even when the management system does not implement a model for all
aspects of a device.

6. A single, concise, request can be made for the entire configuration
state of the device, for the state related to some particular
function, or for any element or subtree of the device configuration.
It is returned in a form in which it can be stored directly into an
Oracle,(etc.)database.

7. The software community has seized upon XML as the representation of choice
for a very wide range of applications.  Adoption across the network management
community is already well along. There has long been a pressing need for a
standard representation of device configuration and dynamic state. 
The industry at large has chosen XML as that representation.  

8. There are many, sophisticated XML representations/technologies/tools
and broad support for XML across the DBMS and broader ISV community.

> - 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
0. Where good models exist, re-expression of these schemes for
XML-management is in order.  Where they do not, coordination
with existing efforts to create them ought to begin.

1. XML is sufficiently expressive to work well as a language for
such transactions.  It would be good to apply what we know about
these scenarios into creating some proposals for a standard
way to implement them.  I, for one, would be interested in
working out some of these in collaboration with one or more
folks who are expert in the end-user need.

2. Many (maybe most) network elements do not properly implement
the validate/commit semantics of SNMP.  This is largely due to
the primitive design of management commmunications within these
devices.  New, more powerful schemes are emerging for implementing
the management plane within NEs.  We have the opportunity to
address the need for a common way to express what a device is capable
of and what is requested from a device in this area.

3. One work item will be to work out the details of how the transactions
for activation, rollback, activation in sync, and rollback in sync might
be implemented in some standard way.  We can do this abstractly, or
provide a recommended syntax for this.  Having the pending configuration
state represented within the device as an XML tree can simplify the
expression and implementation of these features.  For example, the
activation/rollback operations can be related to one or more subtrees
of the configuration state as opposed to the entire configuration
state of the system.  This will reduce the network disruption caused
by such events. Combining all of the configuration elements
for a particular function (both standard and enterprise-specific) into
a single subtree will simplify the expression and implementation
of validation and commit for the associated function.

> - 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
0. In short, adoption is more important here than invention.

1.  Web-based mechanisms for identification, authentication,
and privacy are well developed and already well integrated
with network management environments.  The vendors and operators
of such systems prefer to integrate all security functions
under one umbrella.  Large and  medium-sized enterprises
have already gone a long way towards implementing a common
security mechanism across the enterprise. Transports, such
as SOAP, have security mechanisms that are well integrated
with web-based security schemes.  We ought to complement
this trend.

2. Direct, web-based management of devices, particularly those for the
enterprise market, is very popular.  XML-based management unifies such
mechanisms with the remote EMS/NMS-based management of the device
and presente the opportunity to integrate the security of such access with
SP or enterprise-wide security mechanisms.

3. We ought to validate our understanding of how the network management 
security needs of both SPs and enterprises relate to web-based and enterprise
wide security schemes.  Anecdotes welcome.




/larry menten


Wijnen, Bert (Bert) wrote:
> ...
>    
> So, how does XML (or any new technology for that matter)
> help us address the Operator Requirements.
> I understand they are not yet very well specified,
> but this is at least an initial list that I have
> seen mentioned and that we need to address:
>
> - 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 multiple 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