RE: Draft Minutes OPS Area Open Meeting Yokohama

[Ron Bonica <rbonica@mci.net>]

Folks,

A few clarifications:

The minutes show Randy asking me if there was anything about my application
that made XML essential. I think that my response was that there is nothing
about the application that makes XML essential. In fact, we use various
expect-type scripts for devices that do not support XML.

The minutes show Bert asking me if we could have done the same thing with
SNMP. They answer is "probably yes".

The minutes show Ed Kern asking if I poll for this. I forget the context of
this question, but the recorded response has little to do with the question.
Maybe Ed can ask the question again.

The minutes show someone asking me if XML is superior to SNMP for
transferring large data sets. It is certainly superior to SNMPv1. I suspect
that it is slightly easier to use XML than SNMPv2, but I can't back up this
claim because I have never done this using SNMPv2.

But again, the purpose of this discussion is not to weigh the relative
benefits of SNMP versus XML. It is to evaluate the applicability of XML.

                                                  Ron


> -----Original Message-----
> From: owner-ops-area@ops.ietf.org [mailto:owner-ops-area@ops.ietf.org]On
> Behalf Of Wijnen, Bert (Bert)
> Sent: Wednesday, July 17, 2002 11:00 PM
> To: ops-area@ops.ietf.org
> Subject: Draft Minutes OPS Area Open Meeting Yokohama
>
>
> Here are the draft minutes. Thanks to Geoff Huston, great job I think!
> Pls send any comments you may have within the next week or so, so that
> we can finalize and submit these minutes to the secretariat.
>
> Thanks,
> Bert
> --------------------------------------------
> Operations & Management Area Open Meeting
>
> WEDNESDAY, July 17 at 1530-1730
> ================================
>
> CHAIRS:	Randy Bush <randy@psg.com>
>       	Bert Wijnen <bwijnen@lucent.com>
>
> AGENDA:
>
>     - agenda bashing 5 minutes
>
>     - discussion on IAB NM Workshop items
>
> 	- Elise Gerich XML usage in a  product
> 	- Ron Bonica - demo
> 	- Dave Perkins - discussion on above
>
> 	- Margret Wasserman - followup xmlConf BOF
>
>     - open mike any topic
>
> Bert stressed the importance of encourging a dialogue between protocol
> developers and operators in order to ensure that protocols and management
> technologies that are developed are well focussed on actual operator
> requirements.
>
> Elise Gerich presented on one vendor's view of what customers had
> indicated
> that they felt were important as it related to the use of XML within a
> configuration environment.
>
> It was reported that customers indicated a need to archive router
> configurations, provision customers on routers, monitor protocol
> adjancies,
> identify DDOS attacks and manage the network inventory.
>
> The vendor's product allows configurations to be mapped into a management
> relational database. This can then be used to upload back into
> the routers.
> Monitoring involves a periodic report request being passed to the router.
> The DDOS system involves the triggered management of dynamically created
> filters into the router based on rules about traffic profiles. The
> inventory system generates inventories of deployed equipment. These
> products are based on an XML-based script engine.
>
> Ron Bonica reported on the inventory system used in the US vBNS.
> The system
> reports on installed operational hardware, its physical configuration and
> its operational configuration.
>
> Randy: Question: What makes XML essential here for the data?
> Ron: we use various expect-type scripts for devices that do not
> support XML
>
> Bert: Question: Would an SNMP toolkit be capable of producing the
> same data
> Ron Yes, but we were using manual processes
>
> Ed Kern: Do you poll for this?
> Ron: we scripted this as an XML script
>
> Bert: How do you push configs back to the units
> Ron: we use a combination of scripts and manual CLI ingterfaces. We are
> looking at how XML may make this config write easier.
>
> Bert: we haven't seen XML use for config changes.
> Ron: yes
>
> Q: Whats the interface to allow multi-vendors? Are there common schemas?
> Ron: We do need some common schemas, yes.
>
> Q: Is the benefit over SNMP the ability to efficiently pull down
> very large
> data sets?
> Ron: yes
>
> Elise: the purpose here was not to caution against the continued use of
> expect or snmp - the object here is to demonstrate the capability
> of using
> XML as a means of communicating between the managed device and the
> management unit.
>
> Rudinger Volk: How much more can we get using XML that exceeds
> what can be
> easily managed with SNMP and scripts? If the XML is available using a
> predictable and sable schema this would be an improvement over
> the current
> situation of snmp and/or scripts and parsers. Starting from XML
> appears to
> offer more promise.
>
> Eliot: Is XML faster?
> Ron: XML appears to be faster than scripting and parsing, but its not
> obvious regarding SNMP
>
> Comment: XML is faster to implement than SNMP probably becuase
> the data is
> tagged.
>
> Dave Perkins: Presentation
> Network configuration information lives in a large variaty of databases,
> and every provider operates a unique data environment. The
> database content
> should be in a vendor-neutral format so that you can process the database
> in a consistent fashion.
>
> A configuration update starts with a provisioning add/update or delete
> request, which in turn triggers a database update, which in turn
> triggers a
> vendor-specific configuration of the extrated data which is then
> pushed to
> the device.
>
> For example to change the policed bandwidth of a customer interface you
> need to map this to a vendor-specific configuration which is then
> pushed to
> the device.
>
> XML is seen as being portable and allows data malleability. It has
> commercial database support and the transformation via XSLT of
> the data is
> well supported, so that there is a good match of XML data to a
> configuration element.
>
> XML schemas are seens as making the task of data validation easier.
>
> The standardization work appears to need
> - protocol oeprations to create, read, update and delete configration
> elements on network devices
> - name instances of configuration in order to support object management
> - transport operation to allow console as well as network access, and add
> the ability to allow authenticated and encrypted communication.
>
> The items not to standardize include the vendor-specific configuration
> elements. This is contracted to the monitoring operation, which
> is seen to
> be easier to standardize.
>
> The XML approach appears to answer the issues of
> - bulk data transfer,
> - a complete set of base types, transaction models (including
> rollback) and
> - organization and identification of data allows policies via matching of
> instance identifiers.
>
> Pushing and pulling config data is complex:
> - the target for the push (running, next boot, file store),
> - a replace or add operation?
> - on-device management of configurations,
> - the retrieval source and
> - nominating components of a configuration for retrieval.
>
>
> Rudinger: is transation support XML or something else?
> Randy: transactions are at a lowser layer, but they are expressed in XML.
> This is contrasted to SNMP where this cannot be expressed.
>
> Bert: this is not necessarily an SNMP limitation. rollbacks are a box
> function, not necessarily a SNMP limitation.
>
> Randy: the underlying configuration comparison is not XML and
> SNMP but XML
> and vendor-specific CLIs
>
> Dan: Talking about the data format is the keypoint in this
> discussion. I'm
> not convinced that XML can solve the transport problem. XML provides an
> oppotunity for a data format at the application level.
>
> Ed: there was mention of a translator in place, and mention of
> some form of
> semantic about knowing whether the device will accept a configuration
> before iut gets pushed to the device. How?
> Dave: I don't know what the answer may be
>
> Margret Wasserman - XMLConf followup
> Claims that we need more than XML, but a need for a standard
> configuration
> protocol that meets operator requirements. The claim was that XML makes
> meeting some of these requirements a little easier.
>
> XML is interpreted as tagged formatted text for reading and writing text
> configurations.
>
> It is claimed that scraping information from a CLI output can be very
> difficult, and tagged text would make reliable parsing easier.
>
> Writing the config also involves a comnplex set of parses to ensure that
> the managed deive is at the same CLI state as anticipated by the script.
> XML proposes that a config write can be undertaken in a single step.
>
> Proposes to standardize the protocol and the messages. The
> messages may or
> may not be specified using XML schema. Standardizing the schema
> may be seen
> as a valuable exercise.
>
> Options for progress: standardize a protocol transport and the
> messages for
> configuration management AND/OR standardize an XML Schema. It was claimed
> that doing both is even more valuable.
>
> Caution was expressed about reinventing SNMP in XML
>
>
> Andy Bierman: I happen to agree with a lot of what was said and a certain
> level of prob lem is solveable, even without the use of XML. But
> interoperability is commonality of syntax and semantics, and
> commonality of
> syntax is not commonality of semantics. It is claimed that the
> real benefit
> is convergence of semantics to allow operators to undertake
> common tasks in
> a common fashion. For historical reasons we haven't done a good job in
> defining configuration knobs. XML is seen as a good evolution
> path for CLI
> - it allows better organization of data and the introduction of meta data
> (which is not an option for SNMP and CLI).
>
> Randy Preshun: Manipulation of large amounts of data for bulk
> configuration. Yet the SMING session was talking about strong constraints
> about limiting the volume of a transaction. This appears to be
> inconsistency.
> Bert: We had this discussion, yes.
> Andy Bierman: I don't see the problem, becuase with XML you can
> define the
> boundaries of a transaction.
>
> Margret: There is the need to dump and restore the entire
> configuration and
> check and compare snippets. If we are going to try and address
> anything we
> should see how this could be addressed.
>
> Eliot: If we are going to attack the problem this is a reasonable
> approach.
>
> Bert: thinks it is too quick to move to consensus.
>
> Eliot: looking for something less vague for next steps;  Margaret, thinks
> it is premature before the iab report; rob ? is writing an iab report on
> the network mgt workshop; the report will be the offical report - 2nd
> quesiton about protocol operations that need to be defined in a more
> specific way
>
> Dan: What was presented her and on Monday provided no revelations
> concering
> the next steps or missing pieces. Standardizing the transport and
> the data
> model does not assist in interoperability. This crfeates really a problem
> for whats out there.
>
> Margret: we have no clear idea on how to move forward.
>
> Glenn: Confused about the state. Looking at XML as a CLI replacement to
> create greater uniformity in scripting requirements. We have SNMP already
> in place.
>
> Dave: Poll of attendees of management application developers. We are
> missing the people who are writing management aplications.
>
> Bert: What I get from this is that thare are application
> developers but no
> operators.
>
> Ron: A few words in support of Margret's strategy. Standardizing XML
> formatting is a little win - this is good. Standardizing the
> schemas may be
> a large job - standardizing a small proportion of the config space with
> schemas wwhich are constantly used would be a good win.
>
> Geoff: Standardizing an XML as a CLI would be viewed with suspicion. The
> major problem from an operator's perspective is that SNMP is not
> sufficiently reliably implemented, and there is deep suspicion
> that an XML
> CLI would be equally unreliable. The result of unreliable SNMP and an
> unreliable XML CLI is vastly worse than what we have today. So lets
> standardize the message formats, but not standardize an XML CLI. But
> instead of standing in a microphone line for 15 minutes before
> saying this
> he was writing these notes.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>