Subject: [OPS-AREA] minutes

From: Ron Bonica <[email-masked]>
Date: Mon, 10 Dec 2007 15:38:56 -0500

Folks,

The attached are propsed minutes from the OPS AREA meeting. Please send
corrections to this list by Friday, Dec 14. Thanks to Benoit Claise for
taking such good notes!

                                     Ron and Dan

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 raisd 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 liasion 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:
work together 
different technology
ITU action and liaison statement: sent the liaison to 4 Stugy 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	

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 hiearchy
- 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-sheperd the draft. So ping Juergen a few times
        Juergen is still developping the document while gaining experience.

5. Reorganization and extension of the OPS Directorate - Ron Bonica
Reorganized and retasked
The team will received 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
Network Working Group                                        Y. Li, Ed.
Internet-Draft                                      Huawei Technologies
Intended status: Standards Track                         B. Natale, Ed.
Expires: May 31, 2008                                             MITRE
                                                      November 28, 2007

    Expressing SNMP SMI Datatypes in XML Schema Definition Language
              draft-li-natale-smi-datatypes-in-xsd-00.txt

Abstract
  This memo defines the IETF standard expression of Simple Network
  Management Protocol (SNMP) Structure of Management Information (SMI)
  datatypes in eXtensible Markup Language (XML) Schema Definition (XSD)
  language.

- 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
Don, 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. 
Don: 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. “truth” TC values 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 recommand that the truth value from SMI… depending on what’s need 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.
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 

Network Working Group                                  S. Chisholm, Ed.
Internet-Draft                                                   Nortel
Intended status: Standards Track                      November 18, 2007
Expires: May 21, 2008

               Using XML Schema to define NETCONF Content
                  draft-chisholm-netconf-model-07.txt

Abstract
   This memo defines a framework for defining content for NETCONF using
   XML Schema.  It defines requirements to enable interoperability,
   extensibility, easy parsing, usability and predictable modelling.

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
- delected 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 

Network Working Group                                 M. Bjorklund, Ed.
Internet-Draft                                           Tail-f Systems
Intended status: Standards Track                       November 7, 2007
Expires: May 10, 2008

              YANG - A data modeling language for NETCONF
                    draft-bjorklund-netconf-yang-00

Abstract

   YANG is a data modeling language used to model configuration and
   state data manipulated by the NETCONF protocol, NETCONF remote
   procedure calls, and NETCONF notifications.

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 identifed 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 (modelling 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. 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.

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area