[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: How does XML help Network Operators
Larry, can you send plain text email as opposed to HTML email?
Inline comments
> -----Original Message-----
> From: Larry Menten [mailto:lmenten@lucent.com]
> Sent: woensdag 25 september 2002 17:54
> To: xmlconf
> Subject: Re: How does XML help Network Operators
>
> 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.
>
Well... since you're new, you may not know about the enormous
effort that Randy and I (together with others) have spend to try
and find the "correct operators" and the "correct enterprises"
Sofar... whichever contacts we have followed, in the end it all
boiled donw to more or less the same requirements.
I am sure there are still folk out there that are not represented.
If you find any... pls tell them to participate and to document
their needs/requirements and submit them... that would be great
input.
For now... we have to deal with those requirements we have gotten.
Unfortunately a lot of that is still verbal requirements.
We rally NEED those to be written down in such terms that we can
get protocol developers to do the right thing.
> 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.
>
In the above I see a lot of "xxxx can be made...."
That sounds great... but I think I;d like to see the concrete proposals
to actually "make it" and then to get discussion going on:
- does the proposed solution indeed address the operator needs
- does the proposed solution seem to be implementable by vendors
(and I mean kind of as easy and/or as quickly as CLI is done today)
- can we all agree that this is the path to go forward.
> 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.
>
This point sounds as "motherhood and appelpy" and "marketing" to me.
> 8. There are many, sophisticated XML representations/technologies/tools
> and broad support for XML across the DBMS and broader ISV community.
>
sure... I have heard that about many other things too
>
> - 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.
>
Here I get sceptical.... I do not yet see why it is not properly done
for SNMP and now with a new technology (which means all existing stuff
needs to be redone) all of sudden things will be done correctly?
Elaborate why you think that this will happen.
Other vendors, pls jump in to support Larry's statement if you feel
he is right? It should be clear that I am not buying it easily.
> 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.
>
Let's have some discussion on this as to what other vendors and operators
feel/think about this.
>
> - 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.
>
I need details here. When I listened to the requirements on security
as expressed by Randy, I sort of got (and indeed expressed during
the recent NMRG meeting): gee Randy we have all those things in]
SNMP... what is good about it and what is bad about it. Not that
I am trying to defend an SNMP solution (here and now... I may do
that at some other place and time :-))... No, I like to understand
the sort of functionality we need. In SNMPv3 we have:
- users (individuals) are identified by a userName
- these users get mapped into groups (groups can be any form, but
for example they could be: supervisors, leadOperators, juniors,
guets, ATMfolk, ...)
- access is controlled per group
- access for each group is further based on
- did user come in with a noAuthenticationNoPrivacy transport?
- did user come in with authenticatedButPrivacy transport?
- did user come in with athenticatedAndPrivacy (i.e. encrypted)
transport
- Access to the management data can be provided at the all
levels of granularity, e.g.
- all of the management data read and write acces
- all of that data just read access
- only to ATM related management info
- only to a subset fo the interfaces
- only to xxx
So what did we do right (in abstract or in functional form) in
this architecture. What did we do wrong.
My experience tells me we went overboard in the granularity of
access to management data.
> 2. Direct, web-based management of devices, particularly those for the
> enterprise market, is very popular.
Bla ?
> 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.
>
Details please?
> 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.
>
Indeed... what is exactly needed.
In terms of architecture or mechanisms describe above
In terms of linkage with existing or desired security infrastrcuture.
Bert
--
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/>