Current Meeting Report
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 (email@example.com)
Document Editor: Bill Woodcock (firstname.lastname@example.org)
Mailing list: email@example.com
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
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
Scope of document
LISA crowd was interested in applying these recommendations to
$50 mass-market boxes
Three categories of boxes
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
NM/Ops Update: Operator Requirements of Infrastructure Management Methods