OPSAREA Open Meeting Area Directors: Dan Romascanu and Ron Bonica MONDAY, December 3, 2007 1740-1950 Afternoon Session III SALON A 1. Note well, agenda bashing, note takers, blue sheets - 4 min 2. Call for volunteers - IESG scribe - Dan - 1 min Goal: IESG transparency Advantage: direct view of what's happening in the IESG 3. T-MPLS Design Team - Stewart Bryant - 10 min Team between the IETF and ITU-T At IETF69, concerns were raised that by redefining many aspects of the IETF MPLS and PWE3 design, TMPLS would be harmful to the internet. IAB and ISG sent a joint liaison to the ITU-T, available on the liaison page The liaison: MPLS Ethertypes MUST only point to a label defined by the MPLS RFCs. ITU claim disjoin networks but about interoperability Options presented - ITU/IETF work together - completely separate technologies ITU Option 2 code point separation rejected ITU action and liaison statement: sent the liaison to 4 Study Groups Each group has got its own reply to the liaison See the slides for the details The IETF and ITU-T should ensure MPLS/T-MPLS compatibility, consistency, and coherence. Proposal for the joint working team: highlight inconsistency 2. advanced the IETF MPLS spec. if necessary Agreed: IETF spec is the normative reference. OAM is problematic 4. Report from the NMRG workshop in the Netherlands (November 8-9) with the topic of SNMP trace analysis - Dan Romascanu on behalf of Juergen Schoenwaelder - 5 min - NMRG Meeting 08-09 November 2007 Hosted by the University of Twente, Netherlands Seven participants from five different organizations Meeting information and slides: http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2007/enschede/ Minutes: http://www.ibr.cs.tu-bs.de/projects/nmrg/minutes/minutes-023.txt - SNMP traces analysis (common vocabulary for example) and vizualation - Traces analysis: packet arrival times, packet size distributions, message size distributions, message arrival times, message versions, operation distribution, parameter distributions, data type distributions, managed object distribution, data types, notification type distribution, walk arrival times, etc? - Need for common definitions: It would be nice to have common definitions so that we can (i) share some of the tools, (ii) exchange aggregated data for further analysis, and (iii) know precisely what we mean when we use a specific term. Need to define flows, slices, slice types, slice sets, walk, walk types Will be posted as an internet draft - SNMP Trace visualization to show a hierarchy - Conclusions: Meeting was successful in moving work forward Internet-Draft with common definitions is being worked on Expect to see some research papers coming out in 2008 Future work on suitable visualizations needed Additional traces are always welcome. . . Feedback: Sharon: provided feedback at the last IETF about a draft about trace collecting SNMP. However the draft is expired now. Bert: asked to re-shepherd the draft. So ping Juergen a few times Juergen is still developing the document while gaining experience. 5. Reorganization and extension of the OPS Directorate - Ron Bonica Reorganized and retasked The team will receive emails on regular basis: the goal is to review draft from an OPS impact point of view Over time, will review what the OPS requirements Dave Harrington has got a manageability draft. 6. Status of MIB2RDML work - Bob Natale http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd- 00.txt - The problem space: Existing and future SNMP MIBs represent a tremendous source of network management value, both as data models and (when realized via SNMP agents) -- as instrumented management capabilities. So, development of an IETF Standard Methodology for Converting SNMP MIBs to XML Documents via XSD, for XML based application. - During last IETF, Bob was challenged to show the advantages of this method. After some thoughts: Expected Beneficiaries & Benefits * Network Operators: * More unified management solutions from the service layer * Fewer distinct management tools to purchase, integrate, operate, and maintain * Fewer distinct data sources to correlate and validate * Result = More timely, complete, accurate network information enables improved service delivery at reduced cost * Network Users: * Improved service performance at (possibly) lower cost due to benefits realized by Network Operators. * XML-based Management Solution Providers: * More appealing products to offer * No need to reinvent the wheel with respect to SNMP MIB data models or instrumentation * SNMP Managed Equipment Providers: * Broader market for existing products w/o code changes * SNMP Management Solution Providers: * Supply MIB to XML conversion/validation tools * Supply XML/SNMP proxy solution * Eventually supply XML-based instrumentation in existing SNMP-managed equipment Background: * IETF-68/Prague - MIB2RMDL (Natale): * Addressed the full conversion problem: * MIB to XML via XSD * XML to ?Resource Model? (e.g., SML, RMD, etc.) * Gateway to SNMP-based instrumentation * IETF-69/Chicago ? XSDMI (Harrington/Li): * Focused on MIB to XML via XSD * Leveraged pre-existing IETF work * MIB2RMDL effort aligned with XSDMI * IETF-70/Vancouver (combined team): * draft-li-natale-smi-datatypes-in-xsd-00.txt * XML-oriented ?consumer? groups asking for alignment in the March 2008 time frame * MIB to XML via XSD Deliverables: * Documents: * SNMP SMI Datatypes in XSD * RFC 2578 and RFC 1155 * SNMP Textual Conventions in XSD * RFC 2579 and select (TBD) other IETF TCs * Optional: Follow-on additional document(s) to cover select (TBD) non-core TCs * SNMP MIB Structure in XSD * Working from libsmi as a starting point * Tools (Optional): * Downloadable/online MIB to XML conversion utilities * Similar to XML2RFC * Reference implementations * MIB to XML * XML to SNMP Gateway Requirements for SMI to XSD Mapping (Objectives: Fidelity and Parsimon Note: the requirements on which we must have agreement. * R1. All SMI datatypes MUST have a corresponding XSD datatype. * R2. In case of conflicting requirements between SMIv1 and SMIv2, SMIv2 MUST take precedence. * R3. The XSD datatype specified for a given SMI datatype MUST be able to represent all valid values for that SMI datatype, and only those values * R4. The XSD datatype specified for a given SMI datatype MUST represent any special encoding rules associated with that SMI datatype. * R5. The XSD datatype specified for a given SMI datatype MUST include any restrictions on values associated with the SMI datatype. * R6. The XSD datatype specified for a given SMI datatype MUST be the most direct XSD datatype, with the most parsimonious restrictions, which matches the foregoing requirements. * R7. The XML output produced as a result of meeting the foregoing requirements SHOULD be the most direct from the perspective of readability by humans. Proposed SMI Datatypes to XSD Mapping - Recommendations for simpler patterns for 'IpAddress' and 'ObjectIdentifier' which are consistent with the mapping requirements will be enthusiastically welcomed. - Note that the SMIv2 ?BITS? construct remains to be mapped. Feedback: Sharon: division between the SNMP, SMI, and MIB. integer32 and integer64. SNMP could not do 64bits initially. Do we need to have fidelity or can we just say: integer. Bob: looking for fidelity here Dan: what are the next steps? Bob: * Achieve consensus on SMI datatypes to XSD mapping draft: * draft-li-natale-smi-datatypes-in-xsd-00.txt * -01 update to be posted following Vancouver * Identify core set of TCs and publish Core TC to XSD mapping draft: * draft-romascanu-netconf-datatypes-02.txt is a primary source * Define IETF-standard MIB to XML structure and publish mapping draft: * libsmi/smidump XML output tool is a primary source: * draft-li-mib-convert-00.txt * Output from XML option of http://www.ibr.cs.tu-bs.de/projects/libsmi/smidump.html * Refine and publish all drafts as Proposed Standard RFCs Ron, as individual contributor: not data model guru. SMI was not expressive enough for configuration. So any mapping will be lacking any configuration. What guarantee that what we will do (relax NG, yang) will still be compliant Bob: not sure yet. Ron: After this next generation is done, will have to tune it Dave Harrington: to answer Ron. If take SMI and add extra things to it (things in YANG that don't exist in SMI), there is no guarantee ? Yang is done for configuration specifically. For example: state. SNMP doesn't care For example: Netconf needs to know whether this is the startup or running config. SNMP doesn't care SMI has not proved to be very good for configuration. Andy Bierman: limited in scope enough now that it's useful (even if Andy was opposed to it in the past). Andy agrees that fidelity is important. David Harrington: fidelity is an interesting one. TruthValue TC has the value of 1 and 2. Normally, we use 0 and 1. Yang proposes to use 0 and 1. If a new protocol, don't recommend that the truth value from SMI? depending on what needs to be accomplished. while browsing the draft, don't see anything about Ipv6 address. Andy: XML encoding is the key, not XSD. Whether this is XSD or not is irrelevant. Andy: XSD, RelaxNG, Yang has many way to describe the same thing. The XML encoding must be defined. That's critical. Note: draft not posted. http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd- 00.txt 7. XML Schema Usage for NETCONF - Sharon Chisholm http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-07.txt Solution to define content to be exchanged between NETCONF client and NETCONF server, similar to MIB for SNMP. Use XML schema, plus defines appInfo tags (such as minAccess, maxAccess, status, appErrors, eventClass, dataType) to fill in gaps Note that now, relaxNG has got a lot of tools. This was not the case when this job was started. This could be done with relaxNG Modeling Considerations: modularity, data types, elements and attributes, naming implications of using XPATH, proper tag names, granularity of data model, avoid mixed content. Updates in 07: - explain the benefits of the approach - updated notification definition to align with notification ID - clean up examples - deleted the section which outlined specific NETCONF operations against the data model - added an appendix talking about the potential for a mapping to Yang Based on the feedback from this morning, started to compare the XSD, RelaxNG ,Yang. 8. Technical Discussion on the YANG data modeling language - David Partain http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt Technical presentation of Yang. Yang is a SMI for NETCONF: config data, state data, RPCs, and notification Based on SMIng syntax Text based Preserves investment in SNMP MIBs Libsmi translates MIBs to YANG Directly maps to XML content (on the wire) Extensible Add new content to existing data models Add new statement to YANG Very limited scope Based on three proprietary DMLs Running code (www.yang-central.org) Reuse the concept of modules in SMI, but add the notion of submodule Different types in YANG: Leaf: one value, no children, one instance Leaf-list: one value, no children, multiple instances The order is important Container: no value, holds related children, one instance Must: constrain nodes by XPATH expression Has to be fulfilled to be valid List: uniquely identified by keys, holds children Etc? See the slides. YANG gives the syntax, but that's not all: unique, must, keyref, config, default, error-app-tag/error-message, mandatory, presence, ordered-by, notion of derived types, notion of grouping 9. Mailing Lists Status - Dan - 5 min - The metalanguage mailing (modeling language for more complex structure with a set of tools) would be closed due to no activities - Mib2rd mailing list would be kept open for some time - Yang mailing list is just started - ngo (NETCONF goes on) mailing list. Now that NETCONF is rechartered? Sharon would like to keep it, for the people. Juergen Sch.: Thinks that there are to many lists. Dave is worried about the 8 copies of the same messages. Will be discussed again. 10. Open microphone - 30 min Dave Pertain: How many read the YANG draft? A lot more than this morning in the aps area. Dan R.: Meet every IETF or every other IETF. Not many hands, a few more for every IETF. David P. Do if there is content.