netconf@conference.ietf.jabber.com - 2003/03/17
[08:52] %% jaltman has arrived.
[09:15] %% mark.ellison has arrived.
[09:15] %% mark.ellison has left.
[09:46] %% mrose has arrived.
[09:51] %% mls has arrived.
[09:51] %% hildjj has arrived.
[10:00] %% paf has arrived.
[10:03] %% sleinen has arrived.
[10:05] %% Bill has arrived.
[10:09] %% pgmillard has arrived.
[10:11] %% mark.ellison has arrived.
[10:11] * mrose has changed the subject to: netconf bof / 56th ietf // xmlconf[-request]@ops.ietf.org
[10:11] * mrose has changed the subject to: netconf bof / 56th ietf / xmlconf[-request]@ops.ietf.org
[10:12] %% carlalf has arrived.
[10:12] %% jaltman has left.
[10:17] <mrose> ...and, we're off... andy bierman has called the room to order!
[10:17] <mrose> oops, jumped the gun... waiting for the co-chair... 4 minutes to go...
[10:18] <mrose> bert is in the house
[10:18] %% dblacka has arrived.
[10:19] <mrose> randy has arrived.
[10:20] <mrose> andy is calling the meeting to order.
[10:22] <mrose> agenda: bashing 5 minutes / open remarks 10 minutes / scope presentation 15 minutes / scope discussion 15 minutes / i-d presentation 35 minutes / i-d discussion 40 minutes / next steps 30 minutes
[10:22] <mrose> andy: the slides are not online...
[10:23] <mrose> randy: first, some questions.
[10:24] <mrose> randy: how many folks have built configuration tools? lots.
[10:24] <mrose> randy: how many folks have built numbers? lots.
[10:24] %% carlalf has left.
[10:24] <mrose> (people are raising their hands)
[10:24] <mrose> randy: how many people here have read the main draft? 50ish.
[10:25] <mrose> randy: this is the current stage of a trip that's 2.5 years long... "it's the cli, stupid!"
[10:26] <mrose> randy: since that time, operators have decided that typing configurations into routers isn't the best way, and software developers have started to think in terms of networks and textual descriptions. so, we're getting closer.
[10:26] <mrose> andy: network mgmt roadmap --
[10:27] <mrose> andy: goals: achidve standards-based management, phase out proprietary screen-scraping, management networks (not just network devices)
[10:27] %% jaltman has arrived.
[10:27] %% mls has left.
[10:27] %% pgmillard has left.
[10:28] <mrose> andy: first develop and deploy the management protocol (1 year) -- decoupled from data model, allow for data retrieval and notifications but focus on configuration tasks, start with a lightweight protocol and proprietary data models to gain operational experience
[10:28] %% mls has arrived.
[10:28] <mrose> andy: then develop a standard data model (2-5 years) -- bulid on existing MIB and SMI experience, gradually replace proprietary data models with standard data models developed in protocol WGs (similar to MIB process)
[10:29] %% pgmillard has arrived.
[10:29] %% carlalf has arrived.
[10:31] <mrose> andy: 2-5 years may be optimistic...
[10:31] <mrose> andy: operator requirements --
[10:32] <paf> We want margaret in apps area meeting in Continental 5. She is to do a presentation, and wanted to be first on the agenda...
[10:32] <mrose> andy: ops area has been researching NM requirements for almost 2 years: 4/2001-5/2002 ops-nm road show visits operators at ripe/nanog/lisa, 06/2002 iab workshop on network mgmt
[10:33] <mrose> paf -- i'll let her know
[10:33] <mrose> paf -- she's on her way
[10:34] <mrose> andy: several drafts have been written on the subject: operator rquiremetns, overvoew of iab workshop, concepts and requirements for xml configuration
[10:34] <mrose> andy: netconf problem statement: need a standard protocol to management network configuration, something that:
[10:35] <mrose> operators want to use, vendors can implement on a wide variety of platforms, uses a human-readable encoding that is easy to generate and debug, provides useful high-level operations pspcialized for configuration management, accounts for different opreatoinal models in use today, provides baseline features that can be extended (based on the capabilities of the network device), ...and... integrates well with existing widely available toolsets
[10:37] <mrose> andy: primary use cases--
[10:38] <mrose> andy: need to provide a standard programmatic interface to replace scripts which interact with proprietary cli interfaces: cli is intended for human uses, cli us not usually stable enough to be a useful api, cli does not have standardized high-level operations for managing device configuration
[10:39] <mrose> andy: need to provide device level support for network-wide configuration operations: configuration locking, checkpointing and rollback, separate validation and commit phases
[10:39] <mrose> andy: netconf protocol layers--
[10:39] <mrose> andy: content over protocol operaitons over remote procedure call over transport (synchronous messages divided into 4 independent layers)
[10:40] %% gk has arrived.
[10:40] <mrose> andy: content layer--
[10:40] %% take-s has arrived.
[10:41] <mrose> andy: configuraiton data: mixture of standard and proprietary data models, payload for protocol operations such as edit-config or get-config
[10:41] <mrose> andy: standard data model not a part of working group scope
[10:41] <mrose> andy: protocol operatoins layer--
[10:41] <mrose> andy: focus of netconf protocol work: define operations for configuration management, define ... (sorry missed it)
[10:42] <mrose> andy: rpc and transport layers--
[10:42] <mrose> andy: select or define rpc protocol: requirements/define mappings to different rpc protocols as needed
[10:42] <mrose> andy: select transport protocol(s): define transport requirements, define security requirements, define mappings to different transport protocols, as needed
[10:42] <mrose> andy: why use xml?
[10:43] <mrose> andy: human an dmachine readable format.
[10:43] %% randy has arrived.
[10:43] <mrose> andy: standards-based, widespread tool support
[10:43] %% pgmillard has left.
[10:44] <mrose> andy: why standardize xmlconf?
[10:45] <mrose> andy: focuses on opreatoinal requirements: appropriate layering and separation of effort
[10:45] %% itojun has arrived.
[10:45] %% shep has arrived.
[10:45] <mrose> andy: low risk factors: no new technologies is being introduced, the ietf has already spent almost 2 years collecting operator requirements
[10:46] <mrose> fred: you said you'd prefer to use transport-layer security... it seems that the issue there deals with threats that you're trying to address
[10:47] %% pgmillard has arrived.
[10:48] <mrose> fred: in the case of conf mgmt, a huge problem is mis-configurations, so, knowing who's making changes would help sorting that out...
[10:48] %% carlalf has left.
[10:48] %% kibozer has arrived.
[10:48] <mrose> eliot: we need to seperate authorization & auditing...
[10:49] <mrose> eliot: we currently don't address the auditing issue
[10:49] <mrose> fred: but that's a security concern.
[10:50] <mrose> perry: speaking as a security geek... what fred is getting at is the threat models... you really want to think about what you *don't* want to defend against... if you don't do that, things will be much more complex
[10:51] %% carlalf has arrived.
[10:52] <mrose> eric: i desire a sync point... is this like the dmtf efforts (a data model)
[10:52] <mrose> andy: no.
[10:52] <mrose> randy: (to fred) the reason you have the tools is to minimize human errors
[10:52] %% mls has left.
[10:52] %% carlalf has left.
[10:53] <mrose> eric: is it replacing snmp in any way? if so, what aspects?
[10:53] <mrose> randy: it's not replacing snmp with respect to configuration management (no operator uses snmp for configuration)
[10:53] %% pgmillard has left.
[10:53] %% itojun has left.
[10:54] <mrose> eric: snmp is very consumptive of bandwidth, will this be less bandwidth-intensitive?
[10:54] <mrose> randy: not particularly, we're not about saving ram.
[10:54] <mrose> eric: wireless networks have different requirements though.
[10:55] <mrose> randy: bandwidth is going up.
[10:55] <mrose> eric: not true for many kinds of wireless networks (e.g., manet?)
[10:55] %% brunod has arrived.
[10:56] %% gk has left.
[10:56] <mrose> fay: regarding the scope, what kind of notification traffic are we talking about?
[10:56] <mrose> randy: we're not trying to replace snmp as a monitoring tool
[10:56] <mrose> andy: the proposal suggests rfc3195 for notification messages, but only wrt to configuration issues
[10:57] %% randy has left.
[10:57] %% mls has arrived.
[10:57] <mrose> randy: and we're talking about configuring networks, not just devices (so we're talking about transactions)
[10:58] <mrose> fay: wrt authentication, how do i provide in-band management on a new box without a default?
[10:59] <mrose> andy: a hard problem, zeroconf looked at it
[10:59] <mrose> eliot: that's out of scope
[11:03] <mrose> unk: what kind of scalability are we talking about? can we find out if new nodes get updated, or are made availability
[11:03] <mrose> randy: we're not talking about replacing snmp monitoring
[11:03] <mrose> unk: i have a need for a single interface
[11:05] <mrose> andy: xmlconf isn't intended to replace programs that do a lot of snmp polling... it will do a small amount as a part of the configuration management process
[11:05] <mrose> unk: what i'm worried about that netconf will be a partial solution
[11:05] <mrose> quick question to the jabber room, who's physically here?
[11:06] <mrose> randy: that's a good issue for the mailing list...
[11:06] <mrose> unk: regarding rpc & transport, take a look at wsdl.
[11:07] <mark.ellison> I'm physically here!
[11:08] <mrose> dave: regarding notifications- it's good that configuration/notifications are together
[11:10] %% gbourdon has arrived.
[11:10] <mrose> unk2: what about cops-pr, etc.?
[11:10] <mrose> randy: it's got to be text
[11:11] %% falk has arrived.
[11:12] <mrose> fay: regarding lo-bandwidth management channel requirement on ...? just just the transport?
[11:12] <mrose> [GK spelling Marshall - typing not so good]
[11:12] <mrose> Fay: Unstable links, must build robustness into the protocol
[11:13] <mrose> floor: use layering
[11:13] <mrose> fay: just noting the requirement
[11:14] <mrose> randy: we all agree that ... subtext of configusring *networks* not *devices*
[11:14] <mrose> george: i'm concerned that, as an operator, i'm still going to have to do cli stuff in addition to xmlconf
[11:16] <mrose> andy: there are tools that convert snmp mibs to xml schema if you like that. but, the console port will never go away (for firefighting, etc.)
[11:16] <mrose> george: sure, i just hope that 5 years down the road, we don't have to deal with three interfaces
[11:16] %% gk has arrived.
[11:18] %% falk has left.
[11:19] <mrose> (the next speaker is configuring his laptop)
[11:21] %% dblacka has left.
[11:22] <mrose> andy: we're having technical difficulties... time for more questions
[11:23] <mrose> jonathon: are software upgrades in scope?
[11:23] <mrose> answer: nothing prevents you from shipping images using this (beep does mime)?
[11:24] <mrose> jonathon: it seems to me that software upgrades/patches are first-class things, not just another kind of configuration management
[11:24] <mrose> answer: true, but a big netconf thing is doing stuff that we're doing now via other mechanisms
[11:25] <mrose> jonathon: is it in scope? i'm getting different signals here...
[11:26] <mrose> andy: it needs to be worked out as a part of the effort, is it part of the data model or is it just a series of operations?
[11:26] <mrose> andy: i don't think it's out of scope, but i don't know if "special" commands are really required
[11:26] <mrose> unk: what if the upgrade breaks your ability to tlak to the box for configuration?
[11:27] <mrose> randy: possibly folks could look at the document to see that it talks about timeouts and rollbacks...
[11:28] <mrose> rob enz is at the mic.
[11:28] <mrose> rob: the xmlconf draft....
[11:28] %% mls has left.
[11:29] <mrose> rob: what is xmlconf? it's trying to replace the expect/perl scripts that talk to proprietary cli
[11:29] <mrose> rob: the history is... (mrose: just scroll back to andy's talk)
[11:30] <mrose> rob: strategy-- create a standard operational framework for configuration (allow for monitoring and notifications, but focus on configuration)
[11:30] <mrose> rob: allow implementation to mirror native capabilities of device (text-based xml makes that easier, no feature lag between xmlconf and cli)
[11:31] <mrose> rob: protocol layering: xmlconf over beep over tcp over ip.
[11:31] <mrose> rob: would also like to do things like ssh too
[11:32] <mrose> rob: protocol layering (functional): xml content / protocol operations / rpc / session (beep) / security (sasl/tls) / transport (tcp) / network (ip)
[11:33] <mrose> rob: there's a management channel for session controk, abort, kill sessions; operationals channel, and notifications channel
[11:33] <mrose> rob: rpc mechanism: <rpc/> <rpc-reply/> <rpc-progress> <rpc-abort>
[11:33] <mrose> rob: error-reporting: <rpc-error/> <ok/>
[11:34] <mrose> rob: capabilities exchange: base protocol + operational capabilities
[11:34] <mrose> rob: each peer sends capabilities summary during session startup, capabilities defined as URIs (allowing both standard and vendor-specific capabilities)
[11:35] <mrose> rob: capabilities list: base -- set, get, and copy configuration + get ssystem state
[11:35] %% hildjj has left.
[11:35] <mrose> rob: optional capabilities: notification, scratchpad configuration, lock configuration, candidate configuration, configuration validation, separate startup (nvram) configuration, named configurations
[11:36] <mrose> rob: we think that the base+optional capabilities model let's us model pretty much everything we know about
[11:36] <mrose> unk: is there a capability to ask the device to execute something and return a result?
[11:37] <mrose> rob: the base protocol doesn't have it, but you can define it
[11:37] <mrose> unk: at a minimum, we need a way of doing something like that...
[11:38] <mrose> rob: a device contains one or more configuration datastores, some have special semantics (candidate, running, and startup)
[11:39] <mrose> rob: typical model is candidate to running to startup (but just one of many approaches)
[11:40] <mrose> rob: named configs: a simple text/XML file, identified by file: url
[11:40] <mrose> rob: low-level standard commands: base (get-config, edit-config, copy-config, delete-config, get-state, kill-session)
[11:43] <mrose> rob: note that we follow the recommendations of the canonical xml spec (rfc 3076)
[11:44] <mrose> rob: use of xpath is controversial 'cause it's complicated and we're not sure how to subset?
[11:44] <mrose> unk: your use of the xml namespace is slightly different than what the xml specs say
[11:45] <mrose> rob is showing examples, which i'm not scribing here... only interesting points and q&a
[11:46] <mrose> rob: edit-config let's you do fine-graining tuning, whilst copy-config is the big hammer
[11:46] %% falk has arrived.
[11:47] <mrose> rob: may define a set-state operation (to set operational state) in addition to existing get-state operation
[11:48] <mrose> rob: lock/unlock - used to prevent any other session from writing to a specification configuration (applies to all access mechanisms, not just xmlconf)
[11:48] <mrose> rob: hence the need for kill-session
[11:49] <mrose> unk: is it envisioned that there's varying levels of authorization? the spec explicitly doesn't talk about that...
[11:49] <mrose> eliot: yep, because authorization tends to be tied to the data model.
[11:50] <mrose> rob: validate is used to check configuration commands before applying the running configuration
[11:50] <mrose> unk2: what kind of experiences with respect to one-to-one changes v. one-to-many changes?
[11:51] <mrose> rob: there's one vendor that has something that looks like this, and that's why we have things like lock/unlock, but it's still peer-to-peer not multicast...
[11:52] %% sleinen has left.
[11:52] %% sleinen has arrived.
[11:52] <mrose> unk4: say you're configuring a device in-band, won't you be breaking things half way through? can you do something like "do this 5 minutes in the future"
[11:53] <mrose> rob: you can add an extension for that
[11:53] <mrose> eliot: w/o the extension, we continue to recommend you use out-of-band techniques
[11:53] <mrose> rob: <rpc-error/> has a lot of info coming back
[11:54] <mrose> rob: you can use netconf's rpc model to define your own high-level operations
[11:54] <mrose> andy: you can also use that for things like ping & traceroute
[11:54] <mrose> rob: notifications: uses rfc3195 (reliable syslog)
[11:55] <mrose> rob: a minimal standard schema will be put in the draft to support the get-status
[11:55] <mrose> rob: so why did you do your own rpc, but not do soap?
[11:56] <mrose> unk: what about a notification rpc?
[11:56] <mrose> rob: one can define a new format besides rfc3195 as an extension
[11:56] <mrose> unk: i'm interested in reliable notifications, hence the need for a round-trip
[11:56] <mrose> rob: yes, we can talk about that.
[11:57] <mrose> rob: we wanted a simple rpc to base on multiple transports
[11:57] <mrose> rob: xmlconf's rpc is low-overhead, easy understand, to implement and debug
[11:57] <mrose> rob: honestly, it's hard to find the content of a soap message, it's scary
[11:57] %% jaltman has left.
[11:58] <mrose> rob: folks want soap for interoperability, but that's all about soap over http
[11:58] <mrose> rob: we really want xmlconf over beep, ssh, console
[11:58] %% Bill has left.
[11:58] <mrose> unk5: well, a lot of the open source stuff does work over stuff besides http, but i agree that soap is complex
[11:59] <mrose> graham: we need to look at the soap issue.
[11:59] <mrose> graham: the xml community really doesn't like canonical xml
[11:59] <mrose> graham: they don't like the notion of subsetting xml
[11:59] %% sleinen has left.
[12:00] <mrose> graham: in particular, if you're using tools to generate xml, you may not be able to get it to do the subset
[12:00] <mrose> rob: why beep? connection-oriented, multi-channel, simple/robust framing, and let's us initiate connections from either end
[12:01] <mrose> rob: summarizing: common operational format, focus on features needed for configuration (e.g., locking & rollback), supports for simple ctransactions
[12:01] <mrose> rob: leverages existing standards, etc...
[12:02] %% gih has arrived.
[12:03] %% gih has left.
[12:03] <mrose> fay: in today's world, trying to figure out the error returns (e.g., with expect) is hard
[12:03] <mrose> andy: the key thing is that a lot comes back in the same structure with xmlconf
[12:03] %% gih has arrived.
[12:03] <mrose> unk: what about a redundant control model?
[12:04] <mrose> andy: isn't that part of the data model, what kind of special operations are needed?
[12:04] %% mjh has arrived.
[12:05] <mrose> sorry, missed a question, had to get power...
[12:05] %% senthil has arrived.
[12:06] <mrose> ... eliot: xmlconf doesn't talk about stuff that you'll need to deal with zeroconf issues...
[12:07] <mrose> eliot: we should be very explicit about the operating models
[12:08] <mrose> jonathon: yes, the nat stuff gives us some requirements to deal with
[12:09] <mrose> eliot: there may be circumstances where it's not possible to tie an originating ip address to a certificate due to nat traversal.
[12:09] <mrose> rob: it's q&a time!
[12:09] <mrose> 1: regarding the kill operation, how prejudicial is it?
[12:10] <mrose> rob: you need to be sure you really want to kill something, cause it will take care of the session, locks, etc...
[12:11] <mrose> anahm: about rpc-error: are there going to be two sets of error-codes, one for the operational result, and the other for the action
[12:11] <mrose> andy: yes
[12:11] <mrose> dave: we do some configuration operations that may result in a success, but later notifications tell you about bad things that happened as a result.
[12:13] <mrose> ben: what i want to be able to do is store a large number of named configurations on a box and then select them accordingly.
[12:13] <mrose> andy: we need to get that into the draft
[12:14] <mrose> andy: other issues? no. now time to talk about next steps.
[12:14] <mrose> randy: so, do we want a wg?
[12:16] %% falk has left.
[12:16] <mrose> andy: do the people in the room think that the scope is defined correctly?
[12:17] %% gbourdon has left.
[12:18] <mrose> randy p: i think the scope is good as far as it goes, but i'm concerned about: access control policy, identifying named configuration for smaller subsets
[12:18] <mrose> randy p: in other words, the scope isn't quite large enough to address fundamental opreator concerns
[12:19] <mrose> andy: perhaps those might be addressed, but some of these things can be dealt with only if you deal with the data model.
[12:20] <mrose> randy p: the issue is really about the structure of the meta-schema
[12:20] <mrose> andy: yes, but that's part of the scope that i've delegated to the second proposed wg
[12:21] <mrose> rob: we need a work item about a mib for this, and for someone to examine the security aspects of all this
[12:22] <mrose> dave: we need to flesh out the data model portion... what would you have if every vendor had their own data model?
[12:23] <mrose> andy: this is the ongoing debate about the ability of the ietf to define standardized mibs for configuration...
[12:23] <mrose> andy: i think this is useful w/o a complete data model
[12:24] <mrose> andy: we're always going to live in a world where vendors have proprietary aspects to their data model
[12:24] <mrose> dave: can the operators tell us what the 90/10 rule is (e.g., 90% of my snmp gets are to standard mib objects)?
[12:25] <mrose> andy: but why after 15 years do we have so many monitoring mibs and no configuration mibs?
[12:25] <mrose> margaret: the operators have said that unless a large threshold of configuration information is common, it's not useable
[12:26] <mrose> unk: this is great stuff, but it needs to be more network-oriented (it's still device-oriented)
[12:27] <mrose> eliot: network configuration means a lot of things to a lot of different people
[12:28] <mrose> eliot: what i was looking for are building blocks upon which to build more powerful tools to control your network
[12:28] %% gk has left.
[12:29] %% kibozer has left.
[12:30] %% mls has arrived.
[12:31] <mrose> andy: we need a mechanism to confirm the action on N-devices at once
[12:31] <mrose> sorry, i lost the thread for a while...
[12:31] %% brunod has left.
[12:31] <mrose> eric: this is exciting, but i'm worried about individual working groups to address the schemas for their areas.
[12:32] <mrose> eric: with mibs and pibs, sometimes similar things get defined in very different ways by different wgs.
[12:33] <mrose> andy: we need it to be easier for individuals to develop the data model in a consistent way, but for someone doing a particular mib, you need domain experts to create the domain model
[12:33] %% takamiya has arrived.
[12:34] <mrose> eric: one way of doing network configurations is via templates, in that context it's very important to have a system-wide viewpoint to make it work.
[12:34] %% takamiya has left.
[12:34] %% mls has left.
[12:34] <mrose> andy: things like that would be in scope, although the data model is a concern
[12:35] <mrose> randy: a concern about biting off more than we can chew
[12:35] <mrose> eric: yeah, that was great in the 60's...
[12:36] <mrose> margaret: we're trying to solve enough of the problem to get folks to implement it, but we're not able to solve the *whole* problem...
[12:37] <mrose> dan: what isn't clear is how the new data model incorporates mibs/pibs/etc.
[12:37] <mrose> andy: i think that's a data model issue, mapping smi formatted data into xml.
[12:38] %% take-s has left.
[12:38] <mrose> dan: we need to be able to convert the data from one form to another
[12:38] <mrose> andy: there's different kinds of data that you want to convert to xml, but does it need to be this wg?
[12:39] %% shep has left.
[12:39] %% shep has arrived.
[12:39] %% shep has left.
[12:40] <mrose> andy: 2 minute warning
[12:40] <mrose> randy: can i see a charter?
[12:40] <mrose> andy is there interest in doing this work? lots-of-hands up
[12:41] <mrose> randy: do operators think this is the right track? many hands
[12:41] <mrose> randy: do operators think this is the wrong track? no hands
[12:41] <mrose> randy: do operators want to work on this
[12:41] %% paf has left.
[12:43] <mrose> unk: is there anything that tells us as to why config management didn't work in snmp?
[12:43] <mrose> randy: refer to the minutes of the ops meeting back in minneapolis and the iab report
[12:43] <mrose> unk: but it doesn't say what exactly failed?
[12:44] <mrose> andy: i wrote a draft that talked a bit about it.
[12:44] <mrose> andy: it came down to development dollars (cli cheaper than snmp)
[12:44] <mrose> bert: how many operators will serious review documents? some
[12:45] <mrose> andy: adjourn.
[12:45] %% gih has left.
[12:47] %% mark.ellison has left.
[12:47] %% senthil has left.
[12:54] %% mjh has left.
[12:57] %% mrose has left.
[14:34] %% gbourdon has arrived.
[14:35] %% gbourdon has left.
[14:40] %% kibozer has arrived.
[15:05] %% kibozer has left.
[15:07] %% kibozer has arrived.
[15:13] %% kibozer has left.
[15:13] %% kibozer has arrived.
[16:39] %% kibozer has left.
[16:52] %% kibozer has arrived.
[18:26] %% smf has arrived.
[18:27] %% smf has left.
[18:43] %% kibozer has left.
[18:43] %% kibozer has arrived.
[18:59] %% kibozer has left.