Subject: [netmod] Charter proposal for netmod wg

From: David Kessens <[email-masked]>
Date: Tue, 5 Oct 2010 15:38:57 -0700

Working Group,

As agreed during our last working group session in Maastricht, a new
proposed charter for the netmod working group would be formulated to be
discussed on the mailing list.

Please see below for the current version of the proposed charter.

This is not a formal Last Call yet, we would first like to see a bit more
discussion on the list whether the current proposal is at least somewhat in
line with the current thinking of most participants. We would especially
welcome some more input on making the individual work items a bit more
specific on what should be included/excluded in the various proposed core
models.

At the same time, we do want to converge quickly to a new charter as our
Area Director has made it clear that he would like to have a new charter in
place before the next IETF meeting.

Please let us know what you think about the proposal and whether there are
any specific issues that need to be addressed before we move to a formal Last
Call.

In addition, we would very much like to hear commitments from volunteers who
are willing to do actual work on the proposed charter items. Obviously, the
best way to show us such a commitment is by submitting a first draft!

Thanks!

David & David
---

NETCONF Data Modeling Language (netmod)
-----------------------------
Last Modified: 2010-10-05

Current Status: Active Working Group

Chairs: 
David Partain <[email-masked]>
David Kessens <[email-masked]>

Area Director: 
Dan Romascanu <[email-masked]>

Mailing List
Address:	[email-masked]
To Subscribe:	[email-masked]
Archive:	http://www.ietf.org/mail-archive/web/netmod/

Description:

The NETCONF Working Group has completed a base protocol to be used for
configuration management. However, the NETCONF protocol does not include
a modeling language or accompanying rules that can be used to model the
management information that is to be configured using NETCONF. The
NETMOD working group has defined the data modeling language YANG but no
IETF models exist yet. The purpose of the NETMOD working group is to
support the ongoing deployment of YANG by developing a set of core YANG
data models and other activities that will allow network operators to
use YANG for configuration and management of network elements.

The NETMOD Working Group will initially work on the following items:

1. Core system data model
2. Core interface data model
3. Core routing data model that can be augmented with routing
   protocol specifics. This requires appropriate active editorial
   participation from routing experts.
4. SMIv2 translation to YANG

The NETMOD Working Group will not work on another version of YANG. It
will also not serve as a review team for YANG modules developed by other
working groups.

The WG will consult with the NETCONF working group to ensure that
NETMOD's decision do not conflict with planned work in NETCONF.

Goals and Milestones:

  Oct 2010 Submission of individual draft(s) of System data model draft
  Oct 2010 Submission of individual draft(s) of Interface data model
  Oct 2010 Submission of individual draft(s) of Routing data model
  Oct 2010 Submission of individual draft(s) of SMIv2 translation to YANG
  Dec 2010 Submit first working group draft of System data model draft
  Dec 2010 Submit first working group draft of Interface data model
  Dec 2010 Submit first working group draft of Routing data model
  Dec 2010 Submit first working group draft of SMIv2 translation to YANG
  Apr 2011 Submit SMIv2 to YANG translation to the IESG (proposed standard)
  Apr 2011 Submit System data model to the IESG (proposed standard)
  Aug 2011 Submit Interface data model to the IESG (proposed standard)
  Aug 2011 Submit Routing data model to the IESG (proposed standard) 

----

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Oct 2010 17:21:37 +0200

> best way to show us such a commitment is by submitting a first draft!

Concerning the SMIv2 to YANG translation, I have not updated the
meanwhile expired ID, but instead I have rewritten the implementation
that is part of libsmi. I am not sure whether I manage to update the
ID before the cutoff, but I do have issues to discuss, most
importantly whether we should make to 'config true' at all. Doing so
has a number of problems because of the unclear delineation of config
from operational state in the SNMP world and the lack of a generic
NETCONF operations for modifying operational state.

Bottom line: there is some progress on this workitem but currently
more running code than written words.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Oct 2010 09:29:25 -0700

Hi,

The issue of config property as boolean vs. multi-value enum was discussed and
dismissed many times.  The NETMOD WG was sure the config property is a boolean.
This is fundamental to YANG and NETCONF operation.  Saying that we don't know
what config is, or what state is, sends the completely wrong message to the IETF community
about the stability of NETCONF/YANG.

There are some very minor (but visible) corner cases such as duplex-mode='auto',
but that does not mean config=true/false makes NETCONF/YANG unusable or even slightly
broken.  Not every possible data modeling behavior has a machine-readable statement.
Sometimes we will have to use description-stmt.  In the future (2+ years) we should
revisit YANG to see if there are more machine-readable stmts that are needed.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, October 06, 2010 8:22 AM
To: David Kessens
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] Charter proposal for netmod wg

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Oct 2010 19:34:58 +0200 (CEST)

> NETCONF operations for modifying operational state.

This is a real issue when you try to map from SMIv2 to YANG.  In order
to do this properly, some kind of annotation to the MIB objects is
needed, so that the translation process can decide if a certain
read-write or read-create object should be translated to config true
or false.  Because of this, I think we should stick to config false,
i.e. make the resulting YANG module pure config false.

> more running code than written words.

Assuming this is in the libsmi svn, I'll check it out.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Oct 2010 12:33:29 -0700

Hi,

NETCONF has no support at all for read-write (as opposed to read-create).
The protocol designers were well aware of this fact during development.
Anything marked config=false is not writable.

NETCONF cannot support read-write, or accessible-for-notify, or not-accessible.
It only supports read-create (config=true) and read-only (config=false).
NETCONF servers ignore not-accessible (typically used for keys) because it
is meaningless in NETCONF.

This shows some of the flaws in the chartering logic for this document.
There seems to be some assumption that SNMP behavior is somehow going to be mapped
into NETCONF and complete SMIv2 semantics preserved.  IMO, this is a low priority,
and any NETCONF protocol changes to support SMIv2 are probably unacceptable.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Wednesday, October 06, 2010 10:35 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] Charter proposal for netmod wg

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 6 Oct 2010 15:25:16 -0400

>Anything marked config=false is not writable.

Just to be clea:  NETCONF can do anything it pleases, since there's
no limit on data models.  "config=false" is a YANG mechanism, not
NETCONF.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Oct 2010 13:10:15 -0700

OK - point taken.
But we are chartering the mapping of SMIv2 to YANG, not SNMP to NETCONF.
YANG is very specific about how it applies to NETCONF operations.
A server which advertises a YANG module (by adding ?module=foo&amp;revision=bar
to the namespace URI in the <capability>) has to follow the rules specified by YANG.

We have already blurred the line between protocol and data modeling language,
exposing the myth that the 2 layers were ever independent, because we define
YANG extensions that change NETCONF protocol behavior (e.g., the extension in
4741bis that patches in the 'select' and 'type' attributes for the <filter> element.)
YANG extensions for SMIv2 mapping to YANG which change NETCONF operation behavior
are possible, but (IMO) a bad idea.  The YANG marketing blurb claimed that
YANG extensions only provided 'extra' information, and did not harm
basic protocol interoperability at all.  An application that ignored an extension
could still use the 'basic' YANG definitions to utilize NETCONF.
This is not the case at all for most YANG extensions, including any that would
change the meaning of config-stmt.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Shafer
Sent: Wednesday, October 06, 2010 12:25 PM
To: Andy Bierman
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] Charter proposal for netmod wg

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Oct 2010 22:15:53 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> The YANG marketing blurb claimed that

I disagree that its not true for "most YANG extensions", and also I do
not think anyone has proposed an extension that would change the
meaning of the config stmt, _for this particular reason_!

*if* we wanted to map also read-write operational data into YANG, it
could be done with something like:

   config false;
   xxx:writable-operational true;

which would not change the meaning of config false.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Oct 2010 13:24:21 -0700

Hi,

The server is not going to allow any config=false node to be written.
Adding an extension to allow exceptions certainly changes the meaning
of config false;  The server MUST understand the extension in order to
allow <edit-config> to operate on config=false nodes.

However, if the <acme:my-edit-config-is-better-than-the-standard> operation
is used instead of <edit-config>, I think this is probably OK.  
Not a useful standard, but technically not violating the 4741bis or YANG specs.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Wednesday, October 06, 2010 1:16 PM
To: Andy Bierman
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] Charter proposal for netmod wg

   config false;

/martin

---

From: David Kessens <[email-masked]>
Date: Wed, 6 Oct 2010 13:57:16 -0700

I would like to remind everybody that we would like to issue a formal Last
Call on the proposed charter as soon as possible.

In order to this, we really need concrete statements on whether you believe
it is headed in the right direction and what changes are still needed.

Thanks!

David Kessens
speaking as one of the cochairs
---

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Oct 2010 17:23:39 -0700

Hi,

I think there needs to be text added that none of the new NETMOD work
can enhance/modify/alter 4741bis or RFC 6020 (YANG).
All new charter items MUST be fully interoperable with implementations
of 4741bis and/or YANG.  No YANG extensions will be introduced which
require a 4741bis server to be aware of the extension to achieve the
correct behavior. 

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Kessens
Sent: Tuesday, October 05, 2010 3:39 PM
To: [email-masked]
Cc: [email-masked]
Subject: [netmod] Charter proposal for netmod wg

Working Group,

Thanks!

David & David
---

Chairs: 

Area Director: 

Mailing List
Address:	[email-masked]

Description:

Goals and Milestones:

----

---

From: Phil Shafer <[email-masked]>
Date: Thu, 7 Oct 2010 11:40:44 -0400

>allow <edit-config> to operate on config=false nodes.

Given that the server must have advertised the module containing
the extension (or a module that uses it) in the hello message, the
client will know that the server does understand the extension.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Oct 2010 09:43:14 -0700

On 10/07/2010 08:40 AM, Phil Shafer wrote:
>> allow<edit-config>  to operate on config=false nodes.
>

You are right.
But I really don't like defining protocol behavior in the YANG language,
whether it's an extension or not.

Changes to NETCONF behavior should only be done in the protocol
document or in a 'capability' extension document.

Looking at the bigger picture, do we really want to inherit the SNMP access
enumerations from SMIv2? What about RowStatus? That is part of the SNMP
database model as well.

Does this charter item include adding the SNMP database model to the NETCONF model
in some bolt-on manner?  What is the plan to deal with the SNMP-only aspects of SMIv2?
Does it include NETCONF protocol behavior changes or not?  If so, then the NETCONF
charter needs to be updated to reflect this work-in-progress, assuming there is
consensus.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Oct 2010 19:46:11 +0200

On Thu, Oct 07, 2010 at 06:43:14PM +0200, Andy Bierman wrote:
 
> Does this charter item include adding the SNMP database model to the
> NETCONF model in some bolt-on manner?  What is the plan to deal with
> the SNMP-only aspects of SMIv2?  Does it include NETCONF protocol
> behavior changes or not?  If so, then the NETCONF charter needs to
> be updated to reflect this work-in-progress, assuming there is
> consensus.

A likely starting point for this work is:

   http://tools.ietf.org/html/draft-schoenw-netmod-smi-yang-00

Perhaps it gets easier for me to understand your concerns if you can
tell me whether you see specific problems with this. As indicated
earlier, the config true translation still in this ID likely needs to
be dropped, so things would be kind of read-only.

/js

---

From: Phil Shafer <[email-masked]>
Date: Thu, 7 Oct 2010 14:00:10 -0400

>enumerations from SMIv2? What about RowStatus? That is part of the SNMP

No, I agree.  We don't want magic data.  Everytime I've made magic
data, I've lived to regret it.  Data is innert.  RPCs should be
used to instruct the server to perform an action.

For example, if a device supports a value that says "the next time
you boot, use this device", that value might look like data, but
it's not config data (since it's discarded on reboot).  But instead
of making it writable non-config data, the modeler should instead
make an RPC that sets that data value.

    <rpc>
        <set-boot-device>
            <device>usb</device>
        </set-boot-device>
    </rpc>

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Oct 2010 11:36:17 -0700

Hi,

I would like the charter to say that the SMIv2 translation will
focus on operational data and notifications, since this is the
easiest to complete and has the most MIB objects defined.
Support for writable objects may be attempted in a separate document
in a future work item, but not now.

Andy

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, October 07, 2010 10:46 AM
To: Andy Bierman
Cc: Phil Shafer; Andy Bierman; [email-masked]; [email-masked]
Subject: Re: [netmod] Charter proposal for netmod wg

/js

---

From: Jon Saperia <[email-masked]>
Date: Thu, 7 Oct 2010 14:42:48 -0400

Seems to me the focus should be on getting NETCONF/YANG to the point where useful modules for configuration work.  If that can be successfully achieved and adopted by a larger community then other extensions dealing with 'operational' data might be in order.  I would not try too hard to bold NETCONF with SNMP.  The management applications that deal with configuration and other data have been dealing with associations between the two for some time.  
/jon

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Oct 2010 11:55:44 -0700

Hi Jon,

Looks like we all agree on writable objects if not readable ones.
NETCONF <get> of SNMP data is something some NMS developers have asked for,
and I prefer to have 1 standard solution than every vendor do it differently
(what we have now).

Andy

---

From: Jon Saperia <[email-masked]>
Date: Thu, 7 Oct 2010 15:06:07 -0400

Hi,

Which NMS developers have asked for this? The SNMP stuff is standard - if not the objects themselves - NETCONF will have the same issue with regard to 'standard objects' even more so for configuration data.  It is not the conveyance of the information that is or has been at issue.  This would just be a convenience without the bang for the buck.

I still think focus should be on a standard way we can get the configuration problem solved.  

/jon

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Oct 2010 12:14:52 -0700

Hi Jon,

Well, developers at my company have asked recently (for example).
I want to see Juergen's draft standardized, and then use smidump -fyang
to bring almost any MIB object into the XML subtree with read-only access,
in a consistent and useful way.  XPath and subtree filtering provides the NMS
with powerful server-side filtering that is easy to use.  Lower complexity.
Less code.  There are reasons to do this if you are already writing NETCONF
applications anyway.

It is not the highest priority by a mile, but it is on the list.

Andy

-----Original Message-----
From: Jon Saperia [mailto:[email-masked]] 
Sent: Thursday, October 07, 2010 12:06 PM
To: Andy Bierman
Cc: Juergen Schoenwaelder; Andy Bierman; [email-masked]; [email-masked]
Subject: Re: [netmod] Charter proposal for netmod wg

Hi,

/jon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Oct 2010 21:18:26 +0200

> in a future work item, but not now.

Can you please clarify your statement?

Are you suggesting (i) that read-write or read-create data is not
translated at all or are you suggesting (ii) that read-write or
read-create data is translated to 'config false' data, leaving it for
further study whether/how such data can be modified via NETCONF?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Oct 2010 21:34:54 +0200

On Thu, Oct 07, 2010 at 09:06:07PM +0200, Jon Saperia wrote:
 
> Which NMS developers have asked for this? The SNMP stuff is standard
> - if not the objects themselves - NETCONF will have the same issue
> with regard to 'standard objects' even more so for configuration
> data.  It is not the conveyance of the information that is or has
> been at issue.  This would just be a convenience without the bang
> for the buck.

During the IAB Network Management Workshop [RFC3535], it was noted
that SNMP shows relatively poor performance for bulk data transfers
and filtering capabilities are limited to what has been built into the
MIB design.

At the workshop, operators reported that they sometimes script CLIs to
get scalable access to data instead of using SNMP. Allowing operators
to move from scripted proprietary CLIs to standardized NETCONF access
to operational data may not just be a matter of convenience.

/js

---

From: Jon Saperia <[email-masked]>
Date: Thu, 7 Oct 2010 15:44:00 -0400

That is a pretty old data point and not the one I asked about that Andy has already responded to.

I asked which application developers were requesting the access to SNMP-based data via NETCONF mechanisms.  I still do not see any compelling reason to spend cycles on this topic when the original problem, configuration that was to have been addressed by this technology is still open.  That is, we still do not have standard configuration modules much less a range of cross vendor management systems that use it.

/jon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Oct 2010 21:50:03 +0200

> Andy has already responded to.

Perhaps old, but still relevant, perhaps not for you.

/js

---

From: Jon Saperia <[email-masked]>
Date: Thu, 7 Oct 2010 16:21:51 -0400

I did not say it was irrelevant.   It was however not what I asked about.
/jon

---

From: Phil Shafer <[email-masked]>
Date: Thu, 7 Oct 2010 16:54:26 -0400

>to operational data may not just be a matter of convenience.

Moving from screen scraping to an API is definitely a Good Thing,
but even this would be behind the times.  When statistics gathering
is externally driven, the times you most need to data (when your
network is thrashing) is the time that you are least likely to get
it (because your network is thrashing).

In JUNOS we record statistics data (as instructed by config) on
local storage (hard drive) in CSV/XML format and transfer it
(compressed) at time or size thresholds.  You also access this data
(via NETCONF RPC) with filters (time range or content) to get XML
data that you can transform (via XSLT) into something you can show
in your browser (lika SVG).

So no one's going to oh and ah over simpler access, but giving
them richer, more accurate data is something that will.

Thanks,
 Phil

---

From: Jon Saperia <[email-masked]>
Date: Thu, 7 Oct 2010 17:26:29 -0400

To carry your point one step further, there are some cases where it would be very helpful to the management application not to have to initiate a 'poll' or get-conf like action.  The ability for the managed device to send information at 'scheduled' times or under certain conditions would be helpful - and others have done this.  But this is not something that is accomplished just by  changing how the data are described. As you point out there are configuration elements in the managed device and management applications would need work to deal with this.

My point is, finish the initial work first (getting a standard configuration mechanism with standard configuration objects) which will take the least amount of time.  Let the market absorb that, then add other elements based on what does or does not happen.
/jon

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Oct 2010 14:27:27 -0700

Hi Phil,

There are many use-cases, not just 1.
(Your solution sounds less complicated than IPFIX by a mile.)

XPath is pretty good at needle-in-a-haystack data searches.
It doesn't matter how good your bulk transfer is if N is large enough.
You have to leave the haystack where it is at a certain point.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Shafer
Sent: Thursday, October 07, 2010 1:54 PM
To: Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] Charter proposal for netmod wg

Thanks,
 Phil

---

From: Jon Saperia <[email-masked]>
Date: Thu, 7 Oct 2010 17:51:55 -0400

Fair point, another reason though why in some conditions, some local intelligence (to the managed element) is helpful so that the managed element sends what it has been configured to 'know' is needed.  There is nothing that picks up performance like minimizing the movement of data.  

The protocols/data definitions, even in large networks have seldom been the bottleneck in a large distributed management suite in my experience (tuning is needed for sure).  The performance problem is having so much data that serialization to/from the database becomes an issue no matter how well constructed.  

I hope that any new work related to data collection of non-configuration information would do some deep thinking about these issues and see what can been helped by data definitions and protocol operations.  
/jon

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Oct 2010 23:59:55 +0200 (CEST)

Hi,

> Please see below for the current version of the proposed charter.

[...]
> 4. SMIv2 translation to YANG

I think the most interesting work ahead of us is starting to write
models both for the device and for the network, as we discussed in
Maastricht.  Since network-wide config is not part of this charter,
does that mean that we must finish this before we start to work on
network-wide config?  I think the design of device data models (2 and
3 above) may be impacted by the larger picture with network data
models.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Oct 2010 00:03:05 +0200 (CEST)

Hi,

> require a 4741bis server to be aware of the extension to achieve the

I don't think we should add this to the charter.  That does not mean
that I think that we should end up with YANG extensions, but if we do
need them we should not be limited by this charter.  Also the term
"correct behavior" can be interpreted in many ways...

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Oct 2010 00:10:06 +0200 (CEST)

>    http://tools.ietf.org/html/draft-schoenw-netmod-smi-yang-00

If we do this mapping, does that mean that all current SMIv2 modules
are magically available for normal YANG modules to use, or do we
require the translated modules to be published as RFCs?

If they are available w/o publication, can people start to import them
so they get typedefs from them?  Is this something we want to recommend?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Oct 2010 19:39:33 -0700

On 10/07/2010 02:59 PM, Martin Bjorklund wrote:
> Hi,
>
> David Kessens<[email-masked]>  wrote:

I agree. (1) and (2) above would be the best to have first,
even if just a minimal set of mandatory-to-implement objects were defined.
It would be good to have a standard solution for interface naming,
like you showed me at the last IETF, something like:

   leaf name {
      description "interface name (key)";
      type string;

   }

   leaf name-format {
       description
         "expression describing ../name string syntax and providing leafref pointers to
          the associated leaf objects represented in the name string.";

       type "if-name-format-type";
       //  value example:
       //    "%1/%2/%3:/chassis/my-switch-id:/chassis/my-slot-id:/chassis/my-port-id"
       // (The actual syntax is different, but you get the idea.)
       config false;
    }

(Hoping somebody will write an interface module.)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Oct 2010 19:51:14 -0700

> further study whether/how such data can be modified via NETCONF?

(ii).

Sort of a forced MIN-ACCESS read-only.

My biggest concern will all of this new work is that it needs to be done much faster
than the usual IETF pace.  Rather than spend an extra 12 - 18 months defining
the last 20% of features, we need to just stop and publish the low-hanging 80% ASAP.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Oct 2010 20:02:02 -0700

On 10/07/2010 03:03 PM, Martin Bjorklund wrote:
> Hi,
>
> Andy Bierman<[email-masked]>  wrote:

OK -- if the SMIv2 translation is limited to read-only then I am not worried
about changing the NETCONF protocol at all.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 7 Oct 2010 23:25:27 -0400

>There are many use-cases, not just 1.

Absolutely.

>(Your solution sounds less complicated than IPFIX by a mile.)

Yup, and that's a good thing.

>You have to leave the haystack where it is at a certain point.

You lost me in the haystack metaphor, but I guess my underlaying
message is this:

If we're suddenly turning our efforts to replicating 20 years of
SNMP cruft in YANG, then I'm going to be extremely disappointed.

This isn't about just having a better way to describe data, it's
about what can be done when we can stop thinking about minor data
encoding issues and start thinking about the data we are encoding,
what it contains, and how to make that data more accurate, more
timely, and more important.

If NETCONF/YANG is just a new wineskin for the old wine, we've
wasted an awful lot of time.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Oct 2010 22:43:13 -0700

Hi,

I think Juergen will do a good job on the translation draft,
and the starting point draft is good enough to get done quickly.

I think a system.yang module would get done quickly, if that draft existed.

The problem is interfaces.yang.
How to support ifStackTable sort of layering?
How to name interfaces?
What standard knobs to interfaces have?
What standard operational data do interfaces have?
What new features to support?

IMO, ignoring all the standards work that has been done for SNMP
would be a big mistake.  I don't know who has the energy or desire
to rewrite lots of MIB modules for operational data.

I would be happy with just an interfaces framework that didn't define
any knobs, just naming and a 'home' for augmenting the generic interface
with TBD standard and vendor objects.

I am not talking about replicating SNMP interfaces data structures verbatim.
I agree with you that a new interfaces model is needed, but many details
are already defined in MIBs from all kinds of organizations.

Andy

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Thursday, October 07, 2010 8:25 PM
To: Andy Bierman
Cc: Juergen Schoenwaelder; [email-masked]; [email-masked]
Subject: Re: [netmod] Charter proposal for netmod wg 

Absolutely.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Oct 2010 08:36:33 +0200

> require the translated modules to be published as RFCs?

Once there is an agreed algorithm, I think it would be pointless to
republish the translations. YANG can be translated to YIN and RNG and
we stopped publishing the translations. So we should be able to do the
same here.

Having a repository where people can pick up already translated
modules may be convenient, but that should not require complicated
IETF actions.

> so they get typedefs from them?  Is this something we want to recommend?

I assume the number of typedefs you can use in a straight-forward
manner for configuration modules is somewhat limited since some SMIv2
TCs do carry SNMP semantics or SNMP restrictions or they lack a
canonical textual representation etc. I believe what we did with the
core YANG data types in RFC 6021, namely creating YANG versions of
common data types and being explicit about equivalent SMIv2 data types
(where they exist) is likely a good workable approach of reuse for
configuration modules.

That said, the policy question you are raising, namely whether it is
_allowed_ to import from a translated SMIv2 module which never got
published in YANG format as an RFC, can be debated. I would argue this
should be allowed if the translation is allocating namespaces that are
properly registered etc. so that there can't be any bad side effects
caused by name clashes or usage of not properly registered namespace
identifiers. (But that is a solvable problem.)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Oct 2010 10:34:45 +0200 (CEST)

Hi,

I would like to understand the use case for the result of this work
item a bit better.

Assuming we do this mapping, what signals does it send and what is the
intended use case for the resulting YANG modules?

Who is the NETCONF client in this case, and what is required from him?
As an example, if we do a straight-forward translation of the data
models, an OBJECT IDENTIFIER will probably be translated into
yang:object-identifier-128, and OCTET STRING into binary.  This means
that the data will have to be processed by the client before it is
presented to the user, just like a SNMP manager does.  With
RowPointers etc it also needs to be aware of if INDEXes are IMPLIED or
not in order to correctly present the data.  So is the use case really
that we get a better transport than SNMP between an SNMP manager and a
device?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Oct 2010 11:06:42 +0200

On Fri, Oct 08, 2010 at 10:34:45AM +0200, Martin Bjorklund wrote:
 
> presented to the user, just like a SNMP manager does.  

You get the raw data in an XML document. The elements in the XML
document are not OIDs but descriptors. There are several products out
there today that do provide XML access to SNMP instrumentation because
apparently there is a market for getting more efficient access to
large amounts of data sitting in existing SNMP instrumentations. The
representation of SNMP data in XML, however, is not defined and as
such there is no interoperability. Making a NETCONF server access SNMP
instrumentation is not a big development effort and I am sure this
will be done.  The question is whether we want to have one way of
doing this (and then this is the right time to define it) or we are
fine with having several different ways of doing it.

To get back to your question: OID _values_ are relatively rare in MIB
modules and a textual representation of OIDs in dotted format is not
uncommon, (unfortunately) even in many SNMP applications. The
translation of OCTET STRINGs might depend on DISPLAY-HINTs - they
might not all be binary.

> With RowPointers etc it also needs to be aware of if INDEXes are
> IMPLIED or not in order to correctly present the data.

Correct. It is still SNMP instrumentation and there is in my view no
good way to beautify things without causing trouble. Thats why a
config false translation makes sense, you do not want to carry SNMP
limitations into configuration models. The config true thing generally
does not work since SNMP has no notion of configuration data stores
and no robust distinction between state and configuration objects.

> So is the use case really that we get a better transport than SNMP
> between an SNMP manager and a device?

A better transport is a use case. Access to SNMP instrumentation in a
_common_ XML format is another value on its own. Reuse of existing
instrumentation isn't a bad idea either. There likely is also a
long-term value in being able to access all information using one
protocol with a single security / access control framework.

If we do not define the translation now, I am sure we will end up with
a collection of different translations soon and then agreeing on a
common way will be much harder, if feasible at all. So we either work
out a common translation now or we pretend that we rewrite all data
models from scratch incorporating translations manually as needed, or
we decide that a common way to access our legacy SNMP instrumentation
is not a problem to warrants a common solution.

Pick your choice. I have already taken mine. ;-)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 08 Oct 2010 13:15:54 +0200

> 3 above) may be impacted by the larger picture with network data

+1

I am now looking at RPSL, which in fact is close to my understanding of
network-wide configuration. It might be a useful exercise to try to
express it in YANG.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Oct 2010 09:55:16 -0700

Hi,

We need to have a data modeling framework and an intuitive understanding
of the data organization and meta-structure.  We need to understand how
IETF WGs are going to define data structures within this framework.

The ipfix-psamp.yang module clearly shows the need to reference
existing data structures in SMIv2.  I do not think we can ignore
ifIndex, entLogicalIndex, entPhysicalIndex, etc. in NETCONF data models.

There is a need to easily correlate the operational data associated
with specific configuration settings.  If you set the port-profile
to have loss-less service for COS '3', then which operational data nodes
indicate the dropped frame counters for that port?

How is the existing instrumentation going to be reused?

When we agree on what we want to do with existing SNMP data, then we might
also agree on the solution-space.  But we have not defined the problem-space.

Why are we focusing on translating SMIv2 to YANG, when the bigger problem
is the complete absence of an SNMP co-existence strategy?  We should
understand the coexistence framework first, and then the mechanics of the translation
will seem less arbitrary.

Andy

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, October 08, 2010 2:07 AM
To: Martin Bjorklund
Cc: [email-masked]; [email-masked]; Andy Bierman; [email-masked]
Subject: Re: [netmod] Charter proposal for netmod wg

/js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 8 Oct 2010 15:22:15 -0400

Hi,

I don't have time to personally get involved in long debates about an
snmp/netconf coexistence architecture.
My thoughts on the most effective netconf/netmod direction:

1) there is already lots of SNMP infrastructure, and I think operators
are fine with SNMP/MIBs for monitoring the network devices.

2) SNMP configuration falls down on three major points 
	a) SETs are not supported widely, because SNMPv1 was not
secure and SNMPv3/USM/VACM is complex 
	b) SETs do not align well with CLI-style configuration
	c) writing proprietary CLI-scripts is way way faster than
standardizing MIB modules (MIBs are OBE)

3) Netconf configuration holds promise because:
	a) Netconf is secure using existing security infrstructure,
hence less additional work than SNMPv3/USM
	b) Netconf is designed to align well with CLI-scripting
configuration

4) Netconf will still face these issues:
	a) writing proprietary CLI-scripts is way way faster than
standardizing YANG modules
	b) vendors have been clear they have no desire to standardize
the CLI
	c) vendors need the ability to extend any configuration
interface to support new proprietary features
	d) operators will need to monitor changes to operational state
they have caused using Netconf.

So I think YANG modules have a large barrier to adoption, just as SNMP
SETs have.

My suggestion going forward is to not reinvent the SNMP/MIB wheel. The
MIB data models and SNMP already exist, and are widely deployed. For
now, consider that problem solved; being able to read MIB data,
whether read-only or read-write or read-create, using Netconf is
simply not the highest priority.

Focus on what has NOT been solved - getting some acceptable
standardized data modeling for configuration. 
Focus on developing data models in YANG that align well with
CLI-scripting configuration, and utilize the full feature set of YANG.
You do not want to constrain yourselves to doing YANG models that
align with SNMP models. The alignment with CLI-style configuration is
far more important to get right.

In the YANG model documentation, you can have a "Manageability
Considerations" section that points out the need to be able to monitor
the changes to operational state, and this can be done using
appropriate management interfaces for monitoring, ***such as*** SNMP
and existing MIB modules associated with the content of the YANG
module. My recommendation is to name the associated MIB modules and
possibly how specific MIB tables/objects relate to the specific YANG
model structures. 

Many technologies, especially those from other SDOs like IEEE 802,
have standard configurable properties, and it is expected that the
vendor will write a CLI interface or configuration files or whatever
to configure those properties. and then they define MIB modules to
examine/monitor operational state. For years we have dealt with the
fact that configuration tools and monitoring tools are separate. Many
MIB modules monitor the operational state that results from
configuration done using CLI interfaces. 

If the underlying technology has changed significantly from when it
was modeled using MIB, then a YANG module to configure it might model
it in quite a different manner than an existing MIB model of the
technology, and you could write new MIB modules, or YANG monitoring
modules, to monitor the updated technology. 

YANG modules should help define standard configurable properties of
the underlying technologies, which would certainly include some things
already modeled in MIBs, such as ifIndex. But think of ifIndex as
being an abstract configurable property of the interfaces being
managed, not just as a MIB object.

my $.02
dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Friday, October 08, 2010 12:55 PM
> To: Juergen Schoenwaelder; MartinBjorklund
> We need to have a data modeling framework and an intuitive 
> understanding of the data organization and meta-structure.  
> We need to understand how IETF WGs are going to define data 
> structures within this framework.
> 
> The ipfix-psamp.yang module clearly shows the need to 
> reference existing data structures in SMIv2.  I do not think 
> we can ignore ifIndex, entLogicalIndex, entPhysicalIndex, 
> etc. in NETCONF data models.
> 
> There is a need to easily correlate the operational data 
> associated with specific configuration settings.  If you set 
> the port-profile to have loss-less service for COS '3', then 
> which operational data nodes indicate the dropped frame 
> counters for that port?
> 
> When we agree on what we want to do with existing SNMP data, 
> then we might also agree on the solution-space.  But we have 
> not defined the problem-space.
> 
> Why are we focusing on translating SMIv2 to YANG, when the 
> bigger problem is the complete absence of an SNMP 
> co-existence strategy?  We should understand the coexistence 
> framework first, and then the mechanics of the translation 
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

> You get the raw data in an XML document. The elements in the 
> XML document are not OIDs but descriptors. There are several 
> products out there today that do provide XML access to SNMP 
> instrumentation because apparently there is a market for 
> getting more efficient access to large amounts of data 
> sitting in existing SNMP instrumentations. The representation 
> of SNMP data in XML, however, is not defined and as such 
> there is no interoperability. Making a NETCONF server access 
> SNMP instrumentation is not a big development effort and I am 
> sure this will be done.  The question is whether we want to 
> have one way of doing this (and then this is the right time 
> to define it) or we are fine with having several different 
> ways of doing it.
> 
> To get back to your question: OID _values_ are relatively 
> rare in MIB modules and a textual representation of OIDs in 
> dotted format is not uncommon, (unfortunately) even in many 
> SNMP applications. The translation of OCTET STRINGs might 
> depend on DISPLAY-HINTs - they might not all be binary.
> 
> Correct. It is still SNMP instrumentation and there is in my 
> view no good way to beautify things without causing trouble. 
> Thats why a config false translation makes sense, you do not 
> want to carry SNMP limitations into configuration models. The 
> config true thing generally does not work since SNMP has no 
> notion of configuration data stores and no robust distinction 
> between state and configuration objects.
> 

> A better transport is a use case. Access to SNMP 
> instrumentation in a _common_ XML format is another value on 
> its own. Reuse of existing instrumentation isn't a bad idea 
> either. There likely is also a long-term value in being able 
> to access all information using one protocol with a single 
> security / access control framework.
> 
> If we do not define the translation now, I am sure we will 
> end up with a collection of different translations soon and 
> then agreeing on a common way will be much harder, if 
> feasible at all. So we either work out a common translation 
> now or we pretend that we rewrite all data models from 
> scratch incorporating translations manually as needed, or we 
> decide that a common way to access our legacy SNMP 
> instrumentation is not a problem to warrants a common solution.
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Oct 2010 12:58:39 -0700

Hi,

OK to avoiding long debates on coexistence frameworks, and the question
"why are we doing this?" should be clear.  You make many good points
though.

Looking at a concrete example like the ipfix-psamp YANG module,
there is a YANG object that contains an ifIndex value. Nothing more.
  
   1) Is this the level of SNMP data structure coupling we want?

   2) Does inclusion of such an object mandate or just imply that
      SNMP can be used to retrieve the ifEntry, etc. for that ifIndex?

   3) What if NETCONF application programmers do not want/need SNMP, but
      want small amounts of SNMP data during provisioning, etc.?
      (Another reason -- simplified security: NETCONF uses the same
       AAA as CLI).

IMO, the best approach would be:

 A) Make new framework objects 
     Do not use exact 'ifEntry', 'entPhysicalEntry', etc.; 
     Create new scaffolding and naming

 B) Combine any 'old' leafs with any 'new' leafs that may be needed.  
    If a translated SMIv2 leaf is suitable for both configuration and 
    state (dual-mode), then complete reuse makes sense.

 C) Separate SMIv2 -> YANG naming translation from model translation

 D) Support 'object relation' meta-data with YANG extensions, such as
    the smi:oid extension defined in Juergen's draft.

 E) Support 'object relocation' functionality as an optional server capability;
    YANG data structures that represent the 'same' semantics and leaf-level syntax
    as the SMIv2 definition. (Not clear if 100% fidelity is possible or needed)

    - should be configurable
    - should be algorithmic (e.g., Juergen's smidump -fyang)

At a minimum, we need a standard way to know where to find ifInOctets.1 in NETCONF operational
data, and a standard way to know if /interface[name='eth0']/in-octets is really
the same as ifInOctets.1.

Andy

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Friday, October 08, 2010 12:22 PM
To: Andy Bierman; 'Juergen Schoenwaelder'; 'MartinBjorklund'
Cc: [email-masked]; [email-masked]
Subject: RE: [netmod] Charter proposal for netmod wg

Hi,

my $.02
dbh

---

From: Jon Saperia <[email-masked]>
Date: Fri, 8 Oct 2010 17:29:25 -0400

I think with Dave's note and Andy's reply two approaches are defined.  One from my read uses the SNMP infrastructure for monitoring while the other moves away by supporting it with new mechanisms and/or mapping.

My view is that focus should be on solving the original problem first, configuration.  Management applications that are concerned with both [configuration and monitoring] have dealt with the issue of configuration and monitoring data in different formats and name spaces for a long time.

NETCONF could help move the field forward by making configuration data/formats and name spaces more standard.  Management applications will still have to have device specific knowledge from vendor, model, hardware/firmware, software revision before they can manage configuration effectively. Some of the NETCONF/YANG mechanisms already defined help.

This is not a function of how the data are defined for the individual device or even how it is carried to/from managed elements.  The hard problem will remain in the NMS.

/jon