|
Netconf Data Model BOF (netmod)
Wednesday, August 4 at 0900-1130 ================================ CHAIRS: Sharon Chisholm (schishol@nortelnetworks.com) Randy Presuhn (randy_presuhn@mindspring.com) Web page (which has a reference to the mailing list, archives, papers and presentations with proposed solutions): http://standards.nortelnetworks.com/netconf/ AGENDA: 1) Preliminaries - 15 minutes 2) Problem Statement/Scope Overview - 15 minutes 3) Framework for Netconf Data Models - Sharon Chisholm - 15 min http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-00.txt 4) Netconf Data Model - Sandeep Adwanker, 20 minutes http://www.ietf.org/internet-drafts/draft-adwankar-netconf-datamodel-01.txt 5) Getting to a Netconf Data Model - Andrea Westerinen - 15 minutes http://standards.nortelnetworks.com/netconf/docs/GettingToANetConfDataModel.txt 6) Netconf Architecture Model - Ray Atarashi 10 minutes http://www.ietf.org/internet-drafts/draft-atarashi-netconfmodel-architecture-00.txt 7) General Discussion - 20 minutes 8) Charter Discussion and Wrap-up - 15 minutes Additional Recommended Reading: 1) Netconf Configuration Protocol http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-03.txt 2) "On the Difference between Information Models and Data Models", RFC 3444 http://www.ietf.org/rfc/rfc3444.txt Minutes ====== Minutes by Sharon Chisholm, Eliot Lear and Dan Romascanu The Netconf Data Model (netmod) BOF met for 2.5 hours at the IETF 60 meeting on Wednesday August 4, 2004. The session was co-chaired by Sharon Chisholm and Randy Presuhn and was part of the Operations and Management Area, with a shepherding area director of Bert Wijnen. It discussed potential methods for creating the content for use with the Network Configuration (netconf) protocol to maximize interoperability, ease of use and other desirable characteristics. In addition, the possible creation of a working group to address this area was also discussed. 1) Preliminaries Sharon and Randy went through some preliminaries of find minute takers, distributing blue sheets, agenda bashing discussing background, websites and mailing lists. etc. netconfmodel@lyris.nortelnetworks.com. Subscribe lyris@lists.nortelnetworks.com with the words subscribe netconfmodel Mail archives: http://standards.nortelnetworks.com/archives/netconfmodel.html Sharon noted there had been an informal meeting people interested in Netconf Data Model topics during meeting in Seoul. There has been a mailing list since March and there are three individual drafts and one discussion paper. Additional reading includes the Netconf protocol I-D and RFC 3444 2) Problem Statement/Scope Overview Sharon Chisholm presented a review of Netconf layering, the netmod problem statement, building blocks for content, potential strategy for netmod, thoughts on requirements and CLRs and finally discussed deliverables that have been suggested. Problem statement - netconf built an architecture independent of the data model, need to start talking about data models in more concrete terms. Are there any implications between the two that we're not seeing? How do we do access control within the model? Building blocks for content - "SMI for Netconf", Netconf data types, Meta-model / information models. Note that with meta-model or information model "even if you don't define these things, they're there". Strategy - applicable to all content - IETF and proprietary, leverage existing technology, priority on developing a 'Framework' document Requirements vs. CLRs Proposal - capture needs being meet by each introduced portion of netconf data model along with the solution Discussed Deliverables: data types, Syntax, Meta modeling - framework, solutions, mappings to other solutions like SNMP Andy: observation, last bullet should be mapping to SMIv2 Sharon: correct. 3) Framework for Netconf Data Models Sharon Chisholm quickly review the netconf layering, building blocks for content and potentials strategy for netmod. She then began reviewing the considerations for interoperability, extensibility, parsability and usability from draft-chisholm-netconf-model-00.txt Discussions included data modeling language and XML schema, conformance, versioning, well-formed XML. It was noted that additional editors were required. Randy: do you see this as a deliverable when the group is chartered or something that gets added later? Sharon: Now, if people feel comfortable with this Dan: targeted towards the framework? Sharon: yes Andy Bierman: how data models relate to different netconf attributes? How they relate to netconf protocol commands is something I'm really interested in. How to identify things for example. Sharon: agree Ladislav: use of name spaces, should be tackled sooner rather than later Andy - ran into issues with parsing namespace. The version is now elsewhere. Will include major and minor versions in instance document 4) Netconf Data Model Sandeep Adwanker presented his idea of a data model for netconf. He discussed why we needed a data model, whether we needed an information model, provided a survey of some information models, why XML Schema, discussed objectives of data model design, talked about a data model design and schema, naming, access control lists, compliance and key constraint.draft-adwankar-netconf-datamodel-00.txt -Do we need information model? - relations, aggregation, abstraction layer - XML schema provides it -Are graphical design methods important - number of tools existing -Transformation tools exist - XSLT -Survey of data models - SMI, SPPI, CIM, etc. -Why XML schema? -Data model design objectives - simple, lightweight, provide interoperability, evolutionary model, standardized migration, path, minimize dependence on NetConf, minimal, extend beyond configuration -Data model design -Data model schema -SysDescr example -Naming - locate managed objects -ACL - list of entries, example Sandeep's toolsets generate diagrams from schema, not the other way around. Showed some sample code, discussed keys for unique object identification, and showed an example using ACLs. Sharon->generating diagrams from schema? Does this not provide too fine Sharon->a level of granularity to get the big picture from? Or is this able to do higher level translations? what is the role of tools? Sandeep-> It is a literal translation. Tools to visualize what was designed, not to do design Andy -> While of course we want to reuse MIBs, we don't need someone to convert SMI to xsds. Going the other way might be interesting. Design should start from XSD structure, not from SMI. We need to model not convert to XML Want to reuse the semantics though. Had chosen entity and interface. Access control -> needs more thought- not simple mapping to operations. Some things like lock don't even apply to the data model. Needs more thought. Dan -> can you clarify why one goal is to extend beyond configuration Sandeep: monitoring does need to be considered. Shouldn't just focus on configuration. cannot really separate concerned about such a broader scope. We were careful about scope in the protocol work. It may cause confusion. Randy->I found the material on access control to be interesting. Xpath. Randy->Any comments on access control stuff being handled as a configuration? Use of meta-constructs in ACL Answer -> <didn't catch> Randy-> One thing one wants to configure is the access control list. Sharon-> some examples concerning mapping to MIBs would be interesting. Perhaps not in the framework? 5) Getting to a Netconf Data Model Andrea Westerinen presented a view of what should be considered getting to a Netconf Data Model. She discussed model development, model considerations, element versus environment, other modeling questions, modeling goals and conclusions. http://standards.nortelnetworks.com/netconf/docs/GettingToANetConfDataModel.txt -What should be considered - Scope and Coverage. -Modeling concepts and principles: One model? Many models? Any model? No model but translations? -Semantics versus rendering Get the semantics right; and don't focus on rendering -Elements - business operates at a high level -Element or environment? Configurations may span many elements - The model needs to fit into a bigger picture than just an element. Yes, you need to be able to configure the element, but outside of the bigger picture the method has limited benefit. Consider a change in the context of a service where a group of changes will be made. It should all fit together. LA Office / Chicago Office failover example. There are subtle differences between elements. Should they understand the bigger business goal? Yes. -Config and/or general management - You don't do only configuration. You need monitoring data, and perhaps the results of root cause analysis due to a failure. -Relationships. Containment is not the only relationship, and relationships are important. -Also about operations. Is this data or operations? Think operations that are specific to a domain, such as 'create or modify a storage pool'. to add knobs, use subclassing. -Fit together into single conceptual model - Other modeling questions - general management, relationship, design for evolution, is it desirable to fit all pieces into a single conceptual model to form the big picture. Broad abstractions exist - DMTF's CIM -Predictable - where do I find statistics? - stable semantics that can be specialized and extended -Stable -Business operate against normalized semantics -Model pieces must not contradict -Acceptable to define the model in pieces, but the pieces should not contradict each other - Build on existing semantics Eliot-> Function examples in CIM, were you able to abstract things out or was it a list of operations Andrea: both. Depends on what is done tried - create instance - delete instance - invoke query -for expediency or ease - createOrModifyStoragePool - macros - if operation is long running one. Need return code. Want to monitor, kill job. These scenarios get people to want to put been able to generate basic operations examples, for very general abstractions easier to let vendor create macros Eliot-> how much is in the base? Andrea-> invoke a method Brian -> We know there is a lots of running code based on CIM. Upper layers on CIM. When we have to do translation of netconf, will it be straightforward, or would it need 'artificial intelligence'? Andrea-> hard to answer. We don't know what will be this solution. Should be one to one ideally. Data model not known, if designed right should not be AI Brian - if at top level -> make my network work better then dive down and make my router work better. As close to translations Randy -> mapping between models. Why is the operation generalized. In some cases you can distribute as high level, in other case translate you must translate to low level. May need complex operations Andrea-> if we fit into a big picture, should be a easy translation Brian -> have to ignore semantics versus rendering. Andy->high level access and low level. like that. Templates. There were concerns about access control in the design team about this sort of thing. Is this an operational concern or a SDO. One model versus many. vendor creates things, bring back. I think these we the best standards. XML needs to be able to experiment . one model not possible. Andrea-> One model, predictable semantics. Not that it has everything. Andrea-> Is there a way to do statistics, for example. Dependencies? Standards evolve. You have the structure. If vendor has an interface they know where to put it. If vendors with stuff that can't be plugged in, can evolve. Base classes. Access control -> don't think the DMTF has solved everything. Steve -> Slide about environment as appose to elements. Question: can't see ways to screw this up? Andrea- My feeling is yes. If every vendor has its own model and there are no standard semantics, that is screwing up. Push problem to operators. what data I publish versus others. Can't eve bring them together. Sometimes people publish data because it is there. Sharon -> we could screw up by not creating the standard. But if we do the work, can we screw up? with a lot of silos. 6) Netconf Architecture Model Ray Atarashi presented a summary of her draft of an Netconf Architecture. She discussed motivation, netconf architecture model and goal. draft-atarashi-netconfmodel-architecture-00.txt Motivation - netconf deals with a lot of stuff. Propose architecture model XML High Level SNMP Low Level Understand relationship to netconf protocol. Sharon-> do you see as XML as intrinsically high level and SNMP as intrinsically low level, or is this just from your example architecture? Ray-> No, this was just in our case 7) General Discussion Dan -> Two comments 1. observation -> see lack of consistency with approach of netconf protocol. How the data model plays into place. Clarify. Told in netconf - focus on configuration. If data model. provide scope. Sharon -> focus on config, but don't preclude other operation Dan 2. Missing from contribution and charter -> workable example, useful example. This could help us when we build this model. Speaking from the perspective of a vendor. Randy - Some companies have been using this. If these people can bring forward some modelling experience. Sharon -> Its not in the milestones, but it is in the body of the text (referring back to Dan's question) Brian -> comment on Dan's first question. Confusion greater than we think. Being discussed everywhere (DMTF, ITU-T, etc). We need finite scope in finite time. Do not exclude the bigger picture. Needs to be considered. Phil - SNMP Models were not <something> People would be using the CLI. How does address complexity? Andrea - its not that MIBs are not available. Vendor specific. Do in pieces. Be aware of big picture. Use constructs to model things. More predictable. They should all merger together into a model. I've mailed an example. This is a prototype. Wes - Fairly well understood. Operators used CLI because things were not available. Could not do everything. time delay between feature and standard. Were not willing to redeploy Randy - should have include IAB workshop in listed of reading material for this meeting. Andy - Where is the low handling fruit? Compare two proprietary models and get a standard model. What is the agreed scope? Framework first, content later? Sharon-> there are a lot of existing content for models that we can discuss. There will always be non-standard things, but the question is whether you can relate them back to the core. Randy -> Schema for abstract. generate vendor specific and standard specific things. Could have multiple levels. Casting it in XML makes this possible. Bert - any objections to XML-based <no objections> Bert - I've seen too many BOFs where people ask if there is any objection. That doesn't sound like they are enthusiastic for the work. 1. Who in this room has read the documents <reasonable amount> Yes, but there are more than that here. 2. Who has read all the netconf documents <even larger amount>. 3. how are we going to follow all the other organizations dealing with standardization of data models? Do we agree we want to keep the work at minimalist, to limit to configuration versus other SDO stuff - or just netconf data model. Brian - protest the question. Need to ensure it can fit into larger picture. We should be aware about the other models, while focusing Andy - we don't all share view of a larger picture Bert - worry about how much effort it will take to follow and understand. guess which will win. There may still be multiple larger pictures. Need to worry about how it all fits together. Brian - I don't think that is what I was saying. Well understood semantics. algorithmic. Don't know what the layers will be. Andrea - if you look at the big picture. Things overlap. Don't care how you describe it. I think there is convergence. Some core concepts. Even in the MIBs. CIM physical model, and Entity MIB are similar Wes -> I have talked to people who don't want to do XML because of its verbosity. Wes -> If you remember San Francisco, had slides for the stuff to do to be successful. Concept that we only did configuration was there. Need to minimize the protocols. Need to take into consideration is lot harder to get the data model right. Requiring a different protocol to do monitoring is bad. Designing for one purpose is bad Randy -> Just want to do mappings for existing models for transport to netconf? Andy -> Very subjective what minimalist is. Tow camps. Application developers and operators. Those two groups will never converge on the same group of tools. The fact that I have tools to produce stub code isn't all that compelling. Descriptive text versus something more formal. Disparate operational requirements between perl writers and telcos remain and aren't going away. Eliot - Want to agree with Andy and Wes. Seems like a great way to scope work. If two people are going to use existing information models. If they are modelled the same. looks the same. beg, borrow or steal. Look at DMTF and what they have done and see what they can do. 8) Charter Discussion and Wrap-up Sharon presented the proposed charter and next steps for discussion. Brian - seems to be a view that will be XML-based. It doesn't say it is defined in this working group. Randy - If it is defined elsewhere, I'm fine with that. Dave - Doesn't say explicitly it shouldn't impact forward progress of netconf work group. Randy - intent but no guarantees. If we hit a brick wall ... - model for configuration -> to the examples. Should be there (slide 18) -> relation with the edit config command. Brian - think "consider" is too week for netconf protocol work and the W3C XML Schema. Need a stronger verb. Interoperability is the goal. Wes -> should not be incompatible Bert -> if we evaluate these other models. This is unbounded. Rather see an explicit list in the charter. Want action plan and deadline where we can consider that work done. Want it to be aggressive deadline. Don't want to go forever. Randy - Ok to be aggressive. Lots of work as already been done. Andy - Concerns of being compatibility. As part of the charter. If the items in the list is already not compatible. Randy - stronger for the first two bullets. Consider is the right strength for the third (about existing information models). Randy - another question on deliverables. Ray talked about architecture document. Is that in the list? Andy - should be considered as a use case. Other tools. Info was tight approach. Note sure how it relates to normative list. Include use cases as informational Andrea - like Andy's idea of use case. Explicit list. Start with Sandeep's list. Missed a few things, but we can fill that in. Q - The last presenter is going into architecture. Applications are to be added, like QoS Randy - there has not been any decision. If we add it, it would be informational document. People think it could be useful as a source of use cases. Individual from France Telecom - Two doubts about this. First, analysis of existing data models - gap analysis - and pertinence of writing a new one Second - write a requirements document. Randy - Propose that we add requirements document Sharon - I previously suggested we role in the requirements with the framework to keep it more focused Andrea - Might want to role my stuff into framework draft as well. Randy: good suggestion Ray - Architecture Draft. Happy to contribute use cases. Sharon - Do you think this is an area worth working on? <mostly yes. One no from Simon> Simon - I'm an operator. I'm very sceptical about this larger area of common schemas and models. Don't want to go into details. Schemas for config are not low hanging fruit. Not easy to standardize. Want to get netconf done. As co-chair of Netconf, I think it is useful even without data models. Don't think this can be done in a timely manner and still get complexity. Think it's hopeless. Bit worried about defocus from protocol work. Don't have great hopes.. It's an illusion that features be standardized in timely manner from vendors. Ladislav - Don't think these two approaches are mutually exclusive. Cover what is easily achievable. Start with netconf and then work on XML representation. Some will require AI. Still hope it can be done. It won't stop netconf. Dan - Netconf is useless without a standard data model. I think this could have started earlier. If this is not being taken forward, then netconf was just an interesting exercise. Wes - netconf is minimally useful without the data model. Different things on difference boxes. Switch statement with proper version. It will be the same from with XML. Sharon - Are you personally willing to invest time providing content, editing, reviewing, etc? <20-30 hands indicating yes> Send mail to Sharon Sharon - Should we charter a working group with this charter? <20 or so indicated yes; 1 no - Simon; 2 defers> Next Steps - work on charter - people could start progressing documents - > more specific People interested in working on this should email Sharon (schishol@nortelnetworks.com) to let her know what you'd like to do. |