Subject: [NGO] DM alignment

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Nov 2006 14:28:42 -0800

Hi,

Although it is not clear what objectives actually will
be worked on, one of my objectives is to find the right
balance of SMI reuse, CLI friendliness, and OOA/SOA usability.

For example, the SMIv2 range clause cannot be represented in RelaxNG or XSD.
IMPORTS and tables are much simpler in SMIv2.
Augmentation, lifecycle, access control, conformance, and
documentation mechanisms are much better in SMIv2 than anything else.

There are obviously many more things that RelaxNG and XSD can do
that SMIv2 cannot, like attributes (metadata) attached to data,
arbitrarily complex nested data, comprehensive extension and restriction
mechanisms, appinfo, etc.

I think the point of the "DIFFSERV Info Model Challenge" is to compare
how we would model something complicated in RelaxNG (and XSD?),
using NETCONF verbs, to compare it to the DIFFSERV MIB and source info
model.
IMO, this will require more DIFFSERV domain knowledge
than NETMOD domain knowledge to execute, but we'll see.

The reason the SMIv2 standard MIB modules cannot be ignored
is a matter of domain WG priority -- if a WG has spent a lot of time
already to agree on the MIB to manage their protocol, that WG
will not be highly motivated to start over and agree on the
standard knobs all over again to create a NETCONF
data model, regardless of the DM language we use.

IMO, a phased approach (independent of the DM language we use) is needed:

0) Create a standard XSD for SMIv2 data types and core TCs

1) Automatic translation at the PDU layer
    Special RPC (e.g., snmp-getnext) provides peek/poke varbind-based API

2) Direct, automatic data model translation
    Algorithmically convert SMIv2 to XSD and access the converted MIB
    with any NETCONF RPC method.  Access SMIv2 XML separately from 'new'
    and 'vendor' XML (e.g., separate namespace or separate branch
    in data org tree).  Not clear if full edit-config is possible or
even needed.

3) Creation of new modules, or manual conversion of existing SMIv2 modules,
    into 'deep models' (i.e., uses the full DM feature set)
    These models may include new RPC methods, config data, monitoring data,
    notifications, etc.

Step (1) and (2) can be done at the same time as (3), or skipped entirely.
It's not clear to me what the IETF wants to do here.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 23 Nov 2006 15:15:26 +0100 (CET)

> IMO, a phased approach (independent of the DM language we use) is needed:

I agree with this.

> 0) Create a standard XSD for SMIv2 data types and core TCs

Yes.  While waiting for this, we have done that and put the result
into our own namespace.  It would of course be much better if a
standard IETF namespace is used.  RFC4001 TCs are very useful of
course.  I think I have seen at least two other XSD versions of
RFC4001.

>     Special RPC (e.g., snmp-getnext) provides peek/poke varbind-based API

I don't understand why this is needed?

>     in data org tree).

We have done this as well.  One objective has been to be able to reuse
existing data models, and another to reuse existing instrumentation
code.  There are a couple of issues, e.g. how to handle StorageType.

Again it would be better to have a standard mapping.

> Not clear if full edit-config is possible or even needed.

I don't think it matters for the SMI -> XML mapping if edit-config is
used in implementations.   The important step is to get a common
mapping.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Nov 2006 15:47:09 +0100

> used in implementations.   The important step is to get a common

Can you tell us how you did the mapping? Or precisely, how much your
mapping differs from what 'smidump -f xsd' produces today?

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 23 Nov 2006 16:16:59 +0100 (CET)

> mapping differs from what 'smidump -f xsd' produces today?

As you might know, we are in fact using the excellent smidump :) with
a new tool, called dump-cs.  (cs is the name of our DM).  The biggest
difference in the structure is that the INDEXes are xml elements in
our case, not attributes.  Depending on usage, we also do not use
RowStatus.  Then there are lots of small details...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Nov 2006 07:40:49 -0800

> I don't understand why this is needed?

It may not be needed by all implementations.
However, many agents do not store the descriptor names
for all the MIB objects -- you need the OID instead.
Many SNMP agents store data in SNMP format, in lexinext order,
and the NETCONF tree-based PDUs may be difficult to support.
An "SNMP gateway RPC" allows an SNMP PDU to be redirected
internally to the SNMP agent for processing.

On the NMS side, there is the "can't get there from here" problem.
The future NETCONF application developer, who may need a small amount
of SNMP data, does not want to support SNMP just for a few counters.
A hack like this gateway RPC can save a lot of extra NMS work.

> Again it would be better to have a standard mapping.

Yes. Maybe you, Juergen, and Dan should write a draft, and then
implementors can align to it, while standards-makers decide
what to do with it.

> used in implementations.   The important step is to get a common

The operations are important as well.
For interoperability, you need a standard verb and standard data.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 28 Nov 2006 17:59:32 +0100

Hello,
Here are some topics beside modeling that are also interesting for Ericsson:
- Addressing of managed objects possibly based on filters (part of modeling)
- A more precise description on how <edit-config> works
- Granular locking (including making the today's <lock> non-mandatory)
- Sub-agent architecture
- Explicit transaction handling over multiple operations without a Candidate configuration
- Call-Home for notifications

Anyone interested in these ?

Generally it would be nice to here what other people would need from Netconf? Modeling is 
naturally a very important issue but there might be other topics as well.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Nov 2006 16:26:06 -0800

> Anyone interested in these ?

IMO, not so much.

I think we need some standard data models that actually configure
and monitor something in a standard way, before we refine the
agent architecture with sub-agents and partial locking, etc.

The core data types, data organization framework, namespace usage,
table indexing, conformance, variance, modularity, vendor and standard extension
mechanisms, module lifecycle, access control model, and many more data
modeling topics are still "TBD".  IMO, these problems need to be
addressed, and solutions need to be determined, before we can
make any more progress in the standardization of NETCONF.

> 
> Generally it would be nice to here what other people would need from 
> Netconf? Modeling is naturally a very important issue but there might be 
> other topics as well.
> 
> Balazs
> 

Andy