Subject: [NGO] data model I-Ds

From: Yoshifumi Atarashi <[email-masked]>
Date: Fri, 02 Mar 2007 11:24:20 +0900

We wrote 3 I-Ds.

First one is diffserv data model for homework of previous data model
meeting.
Second one is VLAN data model which will be standard document in JAPAN.
Last one, we're considering possibility NETCONF systems and coordination
with another systems.

	Title		: A NETCONF Datamodel for Diff-Serv QoS Control Configuration
	Author(s)	: H. Okita, et al.
	Filename	: draft-okita-ngo-diffservdatamodel-00.txt
	Pages		: 22
	Date		: 2007-2-27

	Title		: VLAN data model for NETCONF
	Author(s)	: T. Iijima, et al.
	Filename	: draft-iijima-ngo-vlandatamodel-00.txt
	Pages		: 17
	Date		: 2007-2-27

	Title		: Consideration of NETCONF Architecture
	Author(s)	: R. Atarashi, et al.
	Filename	: draft-atarashi-ngo-consider-architecture-00.txt
	Pages		: 32
	Date		: 2007-2-27

-------
   Yoshifumi Atarashi

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: OKITA Hideki <[email-masked]>
Date: Mon, 19 Mar 2007 00:19:20 +0900 (JST)

Dear NGO members,

  I wrote a draft for the startpoint of NETCONF datamodel discussion.

	Title		: A NETCONF Datamodel for Diff-Serv QoS Control Configuration
	Author(s)	: H. Okita, T. Iijima and Y. Atarashi
	Filename	: draft-okita-ngo-diffservdatamodel-00.txt
	Pages		: 22
	Date		: 2007-2-27

  According to the datamodel discussion in San Diego, I made a NETCONF
Diff-Serv QoS datamodel under the RFC3290 "Informal Diff-Serv management
model" and tried to support the same set of configurable object defined
in RFC3289 "Diff-Serv MIB".  This draft includes an XML Schema and an 
example XML configuration data of the datamodel.

  I attach the XML Schema to this mail.  I hope comments and discussion
in Prague.

  Several points remaining are

- to follow inetAddress module that Andy has revised and posted to NGO ML.
- to support objects defined in RFC3289.
- to add explanation for each element in the draft and the XML Schema.

  And, several comments already stated are

- to make clear the sentence about the standpoint of this draft
- to move RowPointer issue section to the last of the proposal section.
- to fix editorial problem about normative and informative reference.

Regards,

Hideki Okita

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="http://netconfcentral.org/ncx"
	elementFormDefault="qualified" xmlns="http://www.w3.org/2001/XMLSchema"
	xmlns:ncx="http://netconfcentral.org/ncx" xmlns:pref="http://netconfcentral.org/ncx/ncx">

	<import namespace="http://netconfcentral.org/ncx/ncx" schemaLocation="inetAddress.xsd"></import>
	<element name="diffServ" type="ncx:diffServType"></element>

	<complexType name="diffServType">
		<sequence>
			<element name="dataPath" type="ncx:dataPathType"
				maxOccurs="unbounded" minOccurs="1">
			</element>
			<element name="classifier" type="ncx:classifierType"
				maxOccurs="unbounded" minOccurs="0">
			</element>
			<element name="meter" type="ncx:meterType"
				maxOccurs="unbounded" minOccurs="0">
			</element>
			<element name="marker" type="ncx:markerType"
				maxOccurs="unbounded" minOccurs="0">
			</element>
			<element name="scheduler" type="ncx:schedulerType" maxOccurs="unbounded" minOccurs="0"></element>
			<element name="dropper" type="ncx:dropperType" maxOccurs="unbounded" minOccurs="0"></element>
		</sequence>
	</complexType>

	<complexType name="classifierType">
		<sequence>
			<element name="classifierUnit" type="ncx:classifierUnitType"
				maxOccurs="unbounded" minOccurs="1">
			</element>
		</sequence>
		<attribute name="name" type="ID" use="required"></attribute>
	</complexType>

	<complexType name="dataPathType">
		<sequence>
			<element name="ifIndex" type="int" maxOccurs="1"
				minOccurs="1">
			</element>
			<element name="ifDirection" maxOccurs="1" minOccurs="1">
				<simpleType>
					<restriction base="string">
						<enumeration value="in"></enumeration>
						<enumeration value="out"></enumeration>
					</restriction>
				</simpleType>
			</element>
			<element name="startElement" type="IDREF"
				maxOccurs="1" minOccurs="1">
			</element>
		</sequence>
		<attribute name="name" type="ID"></attribute>
	</complexType>

	<complexType name="classifierUnitType">
		<sequence>
			<element name="addrType" type="pref:InetAddressType"
				maxOccurs="1" minOccurs="0">
			</element>
			<element name="SrcAddr" type="pref:InetAddress"
				maxOccurs="1" minOccurs="0">
			</element>
			<element name="SrcPrefixLength"
				type="pref:InetAddressPrefixLength" maxOccurs="1" minOccurs="0">
			</element>
			<element name="DstAddr" type="pref:InetAddress"
				maxOccurs="1" minOccurs="0">
			</element>
			<element name="DstPrefixLength"
				type="pref:InetAddressPrefixLength" maxOccurs="1" minOccurs="0">
			</element>
			<element name="Dscp" maxOccurs="1" minOccurs="0"
				type="ncx:dscpType">
				<annotation>
					<documentation>
						A Differentiated Services Code-Point that may be
						used for marking a traffic stream.
					</documentation>
				</annotation>
			</element>
			<element name="Protocol" maxOccurs="1" minOccurs="0">
				<simpleType>
					<restriction base="string">
						<minLength value="0"></minLength>
						<maxLength value="255"></maxLength>
					</restriction>
				</simpleType>
			</element>
			<element name="DstL4PortMin" maxOccurs="1" minOccurs="0"
				type="pref:InetPortNumber">
			</element>
			<element name="DstL4PortMax" maxOccurs="1" minOccurs="0"
				type="pref:InetPortNumber">
			</element>
			<element name="SrcL4PortMin" type="pref:InetPortNumber"
				maxOccurs="1" minOccurs="0">
			</element>
			<element name="SrcL4PortMax" type="pref:InetPortNumber"
				maxOccurs="1" minOccurs="0">
			</element>
			<element name="nextElement" type="IDREF"
				maxOccurs="1" minOccurs="0">
			</element>
		</sequence>
		<attribute name="name" type="ID"></attribute>
	</complexType>

	<complexType name="markerType">
		<sequence>
			<element name="dscp" type="ncx:dscpType" maxOccurs="1"
				minOccurs="1">
			</element>
			<element name="nextElement" type="IDREF"
				maxOccurs="1" minOccurs="1">
			</element>
		</sequence>
		<attribute name="name" type="ID"></attribute>
	</complexType>

	<complexType name="meterType">
		<sequence>
            <element name="threshold" type="ncx:thresholdType" maxOccurs="unbounded" minOccurs="0"></element>
			<element name="nonConformOutputElement" type="IDREF"
				maxOccurs="1" minOccurs="1">
			</element>
		</sequence>
		<attribute name="name" type="ID"></attribute>
	</complexType>

	<simpleType name="dscpType">
		<restriction base="int">
			<minExclusive value="0"></minExclusive>
			<maxExclusive value="63"></maxExclusive>
		</restriction>
	</simpleType>

	<complexType name="schedulerType">
    	<sequence>
    		<element name="schedulingMethod" maxOccurs="1"
    			minOccurs="1">
    			<simpleType>
    				<restriction base="string">
    					<enumeration value="Priority"></enumeration>
    					<enumeration value="WRR"></enumeration>
    					<enumeration value="WFQ"></enumeration>
    				</restriction>
    			</simpleType>
    		</element>
            <element name="queueDropMethod" maxOccurs="1" minOccurs="1">
    			<simpleType>
    				<restriction base="string">
    					<enumeration value="taildrop"></enumeration>
    					<enumeration value="WRED"></enumeration>
    				</restriction>
    			</simpleType>
    		</element>
            <element name="queue" type="ncx:queueType"
    			maxOccurs="unbounded" minOccurs="1">
    		</element>
    		<element name="endElement" type="IDREF" maxOccurs="1"
    			minOccurs="1">
    		</element>
    	</sequence>
    	<attribute name="name" type="ID"></attribute>
    </complexType>

    <complexType name="queueType">
    	<sequence>
    		<element name="priority" type="int"></element>
    	</sequence>
    	<attribute name="name" type="ID"></attribute>
    </complexType>

    <complexType name="dropperType">
    	<attribute name="name" type="ID"></attribute>
    </complexType>

    <simpleType name="rateType">
    	<restriction base="string">
    		<pattern value="\d+[GMKk]?bps"></pattern>
    	</restriction>
    </simpleType>

    <complexType name="thresholdType">
    	<sequence>
    		<element name="rate" type="ncx:rateType"></element>
    		<element name="nextElement" type="IDREF"></element>
    	</sequence>
    </complexType>
</schema>

---

From: Simon Leinen <[email-masked]>
Date: Mon, 19 Mar 2007 16:49:47 +0100

> 	Title		: A NETCONF Datamodel for Diff-Serv QoS Control Configuration

First of all, thanks! I think that at this point it is very useful to
look at examples like this, because it provides the necessary
"grounding" to discuss the pros and cons of various ways of describing
configurations.

To illustrate this, here is some debate about design decisions in your
particular representation:

1. Flat vs. Deep

At the end of section 3.2.2 (Hierarchical Expression in XML document),
you explain why you decided to use "pointers" (name="foo" attributes
as anchors, and references to these anchors using
e.g. <startElement>foo</startElemend>), as opposed to a "hierarchical"
(or "deep") representation where the referenced tree would just be
included in the place of the reference.

For example, in your "flat" representation you write (abridged example)

       <classifierUnit name='clfu1'>
         <SrcAddr>128.0.1.10</SrcAddr>
         <SrcPrefixLength>16</SrcPrefixLength>
         <nextElement>mkr1</nextElement>
       </classifierUnit>

       <marker name='mkr1'>
         <dscp>46</dscp>
       </marker>

Where a "deep" representation might write this instead:

       <classifierUnit name='clfu1'>
         <SrcAddr>128.0.1.10</SrcAddr>
         <SrcPrefixLength>16</SrcPrefixLength>
         <nextElement>
           <marker>
             <dscp>46</dscp>
           </marker>
         </nextElement>
       </classifierUnit>

You claim that "When parameters of a functional element linked by
multiple elements are changed, operators would meet trouble to change
all elements in the configuration corresponding to the
parameter-changed element respectively."  With XML, I think this is a
particularily weak argument, because there are good (even
standardized) mechanisms for manipulating multiple parts of an XML
document.

There are other arguments for your representation using pointers, for
example:

* It saves space when content is references from multiple places.
* It allows for recursion.  (An excellent first step at making a
  formalism turing-complete :-)

But there are also arguments for "deep" representations

* You don't have to think up names for things that may only be used
  once.
* Everything is placed in the context it is used, which makes it
  easier to understand what a piece of configuration actually does,
  without having to jump around in the configuration "document".

2. Links (pointers) vs. Containers

Related to the flat/deep decision, but a little different:

When you have interconnected elements, you chose a linked
representation, which makes the structure hard to understand (at least
to me).

For example, you write (abridged again):

       <dataPath name='dpth1'>
         <ifIndex>7</ifIndex>
         <ifDirection>in</ifDirection>
         <startElement>clfr1</startElement>
       </dataPath>

       <classifier name='clfr1'>
         <startElement></startElement>
         <classifierUnit name='clfu1'>
           <SrcAddr>128.0.1.10</SrcAddr>
           <SrcPrefixLength>16</SrcPrefixLength>
           <nextElement>mkr1</nextElement>
         </classifierUnit>
       </classifier>

       <marker name='mkr1'>
         <dscp>46</dscp>
       </marker>

Note the startElement pointer from the <dataPath> element to the
<classifier> element, and the nextElement pointer from that
<classifier> to the <marker>.

I claim the structure would be easier to grasp if you wrote

       <dataPath name='dpth1'>
         <ifIndex>7</ifIndex>
         <ifDirection>in</ifDirection>
         <element seq="1">clfr1</element>
         <element seq="2">mkr1</element>
       </dataPath>

       <classifier name='clfr1'>
         <startElement></startElement>
         <classifierUnit name='clfu1'>
           <SrcAddr>128.0.1.10</SrcAddr>
           <SrcPrefixLength>16</SrcPrefixLength>
         </classifierUnit>
       </classifier>

       <marker name='mkr1'>
         <dscp>46</dscp>
       </marker>

This is still flat, but avoids the chain of links.

Of course you can combine this to a deep representation with apparent
structure.  This would be my personal favourite:

       <dataPath>
         <ifIndex>7</ifIndex>
         <ifDirection>in</ifDirection>
         <classifier>
           <classifierUnit>
             <SrcAddr>128.0.1.10</SrcAddr>
             <SrcPrefixLength>16</SrcPrefixLength>
           </classifierUnit>
         </classifier>
         <marker>
           <dscp>46</dscp>
         </marker>
       </dataPath>

(By the way, is the <startElement></startElement> sequence really
necessary in your example?)

In real-world configuration languages we'll probably find all these
variants, plus other smart ways of representing complex
configurations.  That's why I think it is hard to find agreement on
how configuration should be structured.
-- 
Simon.

---

From: OKITA Hideki <[email-masked]>
Date: Tue, 20 Mar 2007 01:20:30 +0900 (JST)

Dear Simon,

Thank you for your review and nice comment.

>          <element seq="2">mkr1</element>

Your suggestion seems easier to read than mine.  For me, it becomes
a good guideline to use containers to link multiple functional
elements in Diff-Serv configuration.

I hope that it also become the guideline for developers to construct
other models that require multiple references between those objects.

Regards,

Hideki Okita

From: Simon Leinen <[email-masked]>
Subject: Re: [NGO] Diff-Serv datamodel for discussion startpoint
Date: Mon, 19 Mar 2007 16:40:20 +0100

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Mar 2007 17:52:23 +0100

Hi Simon,

> standardized) mechanisms for manipulating multiple parts of an XML

But you don't want to have the same information being represented at
multiple places, so I think in most but trivial cases some kind of
cross-referencing is needed. However, one should do it only where
necessary since links introduce other potential inconsistencies such as
missing targets. To this end, it is much easier to allow
cross-references to real objects such as interfaces as opposed to
"made-up" entities that exist only within a particular configuration.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Eduardo Cardona" <[email-masked]>
Date: Mon, 19 Mar 2007 14:20:33 -0600

Okita, Lada, Simon, et All

Let me try to go one level up around this discussion. 

Something probably worth to mention about the  Informational Model for DiffServ described in RFC3290. It directly models DiffServ as a DAG (Directed Connected Acyclic Graph) (section 3.1 RFC 3290). Thus, The DiffServ MIB DataPath (RFC 3289) precisely calls to reuse objects (Okita's elements like Markers) among different diffServ datapaths.

Perhaps the draft indirectly references this issue as it maps the MIB objects from RFC 3289. however the singularity of DAGs could be stated directly in the document to explain why the document ends up with IDREFs pointers all across the XML schema (as SNMP did with RowPointers). 

Or, 

Personally I am not sure if DAG for DiffServ was appropriated in first place. Which ended up being used in the DiffServ MIB in RFC 3289 and now netconf data models.

Specially for externally committed resources (e.g. via COPs, or Netconf itself, or other protocols) for a particular client/session. My concern is that SNMP/NetConf static provisioning model may not be usable by dynamic external assignments due its general complexity of tracking References (RowPointers , or IDREFs), and the ownership of those IDREFs: who creates those IDREFs and when those can be changed, which services, sessions are linked to those references.

Contrary, dynamic external signaled QOS policies, are per session in some network elements, for example, access networks where each access device can be seen as a sub-interface  - Simon's "Deep"  model.

Particularly, NetConf DiffServ data Model should provide status of the difserv "datapaths" from any configuration source. 
Therefore for the specifics of DiffServ for NetConf I would be inclined for a "Deep" model for DiffServ instead of the DAG principle implemented in the SNMP DiffServ MIB - RFC 3289. 

I agree with Lada's comments that References are used in general. Nonetheless, NGO may provide best practices recommendations at some point in the future of when to use references vs. children within an XML element.

Thanks

Eduardo

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Monday, March 19, 2007 10:52 AM
To: [email-masked]
Subject: Re: [NGO] Diff-Serv datamodel for discussion startpoint

Hi Simon,

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 20 Mar 2007 13:47:04 +0100

Hi,

attached are three forms of the RELAX NG schema equivalent to Hideki's
diffserv data model:
1. XML form - diffserv.rng
2. Compact form - diffserv.rnc, transformed from diffserv.rng by trang
3. Cross-linked HTML - diffserv.html, obtained directly 
   from diffserv.rng by a XSLT script that I wrote. This annotation 
   system uses the <a:rest> elements embedded in the schema (it is 
   documented in this technical report: 
   http://www.cesnet.cz/doc/techzpravy/2006/rngrest/)

I fixed one minor thing that IMO is not correct in the XSD schema  - if
the SrcPrefixLength and DstPrefixLength elements (in classifierUnit) are
specified, then the respective SrcAddress nad DstAddress must also be
present.

Another example of a real-world RELAX NG schema intended for netconf is
here:
http://www.flowmon.org/flowmon-probe/devel/config/flowmon-rng/

Lada

---

From: OKITA Hideki <[email-masked]>
Date: Tue, 20 Mar 2007 22:31:32 +0900 (JST)

Dear Lhotka,

Thank you for your effort aginst RelaxNG.  It is a good meterial
to draw a comparison.

At the OPS are meeting in Wednesday, Iijima-san will talk about 
operators/developers' viewpoint to the NETCONF architecture along
this subject. 

> specified, then the respective SrcAddress nad DstAddress must also be

Does it mean that a Src/DstPrefixLength element should be subordinate
to a Src/DstAddress element in a <classifierUnit> element to avoid
independent appearance of a Src/DstPrefixLength element?  If so,
I can agree with you.

However, it is good to change the expression about IP address
to follow the Andy's ipAddress module. The present expression follows
the "DiffServMultiFieldClfrEntry" object defined in the Diff-Serv MIB.
For such basic data types, IMHO, we do not need to follow SMI-style.

Regards,

Hideki Okita

From: Ladislav Lhotka <[email-masked]>
Subject: Re: [NGO] Diff-Serv datamodel for discussion startpoint
Date: Tue, 20 Mar 2007 13:47:04 +0100

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 20 Mar 2007 14:42:50 +0100

> operators/developers' viewpoint to the NETCONF architecture along

Yup, I'll be there.

> independent appearance of a Src/DstPrefixLength element?  If so,

Yes, each address/prefix pair is optional and within it the prefix is
also optional. 

> For such basic data types, IMHO, we do not need to follow SMI-style.

There are few other data modelling details that could be worth
discussing but for the sake of comparing the schema languages these
examples are quite characteristic.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Mar 2007 11:29:17 +0100 (CET)

Hi,

I will point out just one problem with both the XSD and the RelaxNG
versions of this datamodel.  None of them contain any key (or INDEX if
you will) information.  So how is this supposed to work with a NETCONF
<edit-config> operation?  (The problem has been discussed several
times on the list, e.g. in threads
http://ops.ietf.org/lists/netconf/netconf.2006/msg00215.html and 
http://ops.ietf.org/lists/netconf/netconf.2006/msg00054.html)

For XSD, it could have been solved by using a xs:key expression, but
wasn't.  RelaxNG does not have the key concept.

Ok, I'll point out one more problem - the intention *might* have been
that the 'name' attribute is the key.  But the 'name' attribute is of
type xs:ID.  This isn't very scalable since the ID must be unique
within an instance document, which means that if you do a <get/> you
will get the entire datastore, and if you use another ID somewhere
else in the datastore, you might get a collision.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 21 Mar 2007 15:07:29 +0100

Hi Martin,

the key problem (and similar ones) can be solved in RELAX NG by adding
certain "hints" in a separate namespace to the schema. Actually, we use
this approach in the FlowMon schema I mentioned in my previous mail
(http://www.flowmon.org/flowmon-probe/devel/config/flowmon-rng/), look
for the h:key attribute.

You are right about the limitations of the ID/IDREF datatypes, I also
prefer application-specific and more focused links and anchors. Again,
one could use a pair of hints to instruct applications to check
uniqueness of the keys within a certain scope, existence of link targets
etc.

Lada

PS. Note that I don't want to advocate anything in the diffserv schema,
my only ambition was - as I promised during the netconf session on
Monday - to write a RELAX NG equivalent of the original XSD schema.
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 21 Mar 2007 15:12:01 +0100

> (http://www.flowmon.org/flowmon-probe/devel/config/flowmon-rng/), look
Sorry, this ought to be h:role="key".

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C