Draft Minutes OPS Area Open Meeting Yokohama

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

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.