Current Meeting Report
Slides


2.3.20 OPS-NM Configuration Management Requirements (ops-nm) Bof

Current Meeting Report

OPS-NM BOF: December 10, 2001 1300-1500

Chair: Steve Feldman (feldman@twincreeks.net)
Document Editor: Bill Woodcock (woody@pch.net)
Mailing list: ops-nm@ops.ietf.org

Current draft is not on IETF site (sorry)

Eliot Lear presented summary of outreach meeting at LISA last week
LISA is part of USENIX, attended by many systems administrators

Most sysadmins use ASCII data representations and Perl for configuration management
Don't want intermediate tools in between script and device
Didn't like UDP transport (unreliable)
Don't want XML data representation
Craft interface not mandatory, but specific recommendations for how to implement it
Translate MIBs into ASCII representation of SMI to make use of existing work

Questions:

Questioner: Did you make a distinction between managing services and network devices?

Eliot: Discussion was about device configuration
Bill Woodcock: Discussion was explicitly only about device configuration

Brian Carpenter: Who was represented at the meeting? We see large sites that want features like XML and a GUI, very high level policy tools

Eliot: Expectations for interface were very low, e.g. no menus
Skeptical that standards process can help
No standard CLI, let vendors differentiate themselves with CLI interface

Bill: They wanted a small baseline CLI with open extensibility

Eliot: There were a large number of University admins, some ISPs and a few corporations

Bill: Govt, Military, and Universities

Eliot: They expected to write their own tools over whatever basic interface was provided. They're Perl junkies

Ran Atkinson: There are tools for using SNMP from Perl

Bill: They all were doing this and they all hated it. It was impossible to debug.

Questioner: If there's no point in standardizing an interface, there's no work to do here (at least in the IETF)

Questioner: SNMP defines a configuration model very well. Parsing ASN.1 on the management station was a nightmare

Eliot: Some MIBs are really cryptic too. Not all are good

Eliot : Alva Couch at Tufts said CLI interfaces are self-documenting, the commands are suggestive of what they do. SNMP OIDs do not have this property at all.

---------------

Bill Woodcock presented the current draft status

Throwing out MIBs is a bad idea, they should be translated into a new ASCII-based protocol and used independently of the existing SNMP transport protocol and ASN.1/BER representation.

Draft -01 is at http://www.pch.net/documents/papers/internet-drafts
Draft -02 will be posted to the mailing list soon after the meeting

Bill presented a summary of the draft points

Outstanding issues:
Scope of document
LISA crowd was interested in applying these recommendations to
$50 mass-market boxes
Three categories of boxes
Infrastructural devices
Centrally managed CPE
User managed CPE

Don't try to issue user managed CPE

Divergence between human and machine interfaces
Split the two only as late as possible

Humans prefer tables, machines prefer pair-value lists

Obvious split is when output can't be parsed without reference to previous lines

Questioner: Problem is understanding semantics of output without reference to other lines, not just parsability of output

Eliot: LISA folks were much more concerned about syntax of output than IETFers

Bill: Draft -02 needs an organizational edit, will hopefully go to last-call before needing another BOF

-------------------

Peter Lothberg: Underlying assumption that only smart people are talking to boxes. Large networks have dumb people talking to boxes too Middleware can help protect the boxes from the dumb people

Bill: This is a really difficult problem

Questioner: We need to be careful about how the draft is `labeled'. There is often a difference between what people say they want and what they actually need. The draft should be `reported desires' rather than `requirements'

Bill: We've spent a lot of effort trying to identify real requirement, by asking what people are willing to pay for.

Randy Bush: And what features they actually use

Questioner: Translating reported desires into requirements is outside the scope of a standards body. The draft as it stands is not an adequate set of design requirements

Questioner: Scope of management framework envisioned by the document is too narrow. There must be room for middleware management systems

Bill: The draft only attempts to represent the requirements of a segment of the potential market for networking devices

Questioner: Even though LISA users said they don't care about a standard CLI, they really do and will complain if they don't have it

Bert Wijnen: LISA operators want some standardization of CLI, just don't need everything covered by the standard.

Eliot: Management interface needs to work in the worst case, not just in the near-best case
Autoconfiguration shouldn't be prohibited, and maybe some basic level should be mandated
Device autoconfigures enough to support in-band management

Randy: The draft is appropriately called `requirements'

We have not been able to find any community that uses SNMP for configuration management

There are some devices that cannot dump a config, and be reconfigured by uploading an edited version. This is what we are trying to fix

Ran: There is a decoupling between the operators and management software developers. This arose from the developers translating operator comments inappropriately. Developers need to listen to what operators say they actually need.

Questioner: Some requirements in the draft are too specific. Numeric result codes are not really necessary, but well-defined identifiers are. The draft could be improved by extracting the underlying requirements from more specific recommendations

Randy: The discussion should be limited to configuration, and exclude monitoring

Bill: Some correspondence between configuration and monitoring interfaces would be good. Using commands with similar syntax for configuration and monitoring.

Brian Carpenter: There is a need for standards at the level of policy mechanisms. Not everyone writes Perl scripts for a living.

Bill: This is something that can be layered on top of the desired configuration mechanism. Operators

Questioner: -01 draft is different from current slide presentation If -02 draft is structured around slides, then it is a step in the right direction. The -01 draft is not ready for last-call

Bill: The -02 draft will be like the slide presentation

Randy: The purpose of this effort was to help the developers understand how operators are actually using existing management tools

Questioner: Did you ask about RPSL work during the outreach meetings?

Randy: RPSL tools are used to generate configuration info which is then sent to devices. It can be layered on top of the configuration interface described by the draft.

Questioner: Do people want a standard CLI?

Peter: Devices don't need a standard CLI, but numerical result codes and a reliable way to pull configurations off a box and put them back is needed.

Questioner: I don't need a standard CLI, but I need an abstract representation that will spit out device-specific configuration commands.

Bill: Then you want middleware, you don't want to use the raw configuration interface, and this is outside the scope of the document

Randy: The real source of pain isn't the command syntax, but getting it in and out of the devices

Questioner: Our job should be to specify an abstract hierarchy for configuration management, not config syntax specifics

Bill: So at 2AM your box is broken, and you only know the abstract configuration syntax not how to talk to the box itself. Operators need to cope with this type of crisis situation.

Steve: Does anyone think a standardized least-common denominator CLI is a bad idea

Eliot: This may not be achievable

There are portions of the document that require standardization, such as the command return codes. I don't want to be involved in the standardization of these codes

Bill: The document is only requirements, and doesn't cover implementation. Anything that vendors can agree upon that meets the requirements is good

Questioner: What is the problem with SNMP? If the problem is only designing an acceptable presentation layer, then this is a tractable problem

Bill: As long as it is all in the box, then it meets the requirements. The presentation on the craft port must be acceptable, not just on a management station over the net

Eliot: We should go back to outreach groups and present the final draft to make sure we have described what they really want.

Wes Hardaker: Having multiple different management interfaces is a problem. A standard CLI interface could be implemented in any management software outside the box. The internal representation shouldn't matter

Bill: We don't want any intermediate software, hosts, etc. that are required to manage the box. If the presentation

Randy: This shouldn't be construed to define how configuration management should be done for the indefinite future. The goal is to get past the near term configuration management problems faced by operators today.

We need to get something simple out the door, and then revisit the question about what the next generation of management software standards should be like.

Questioner: The draft language specifies a particular solution

Steve: The language will be changed in the -02 draft

Steve called for consensus that the draft is moving in the right direction no one dissented

The bullet points from Bill's presentation will be posted to the mailing list for discussion

Questioner: After the draft is updated there is no more work to be done in this group

Randy: No, the group will not do any additional work

Slides

NM/Ops Update: Operator Requirements of Infrastructure Management Methods