Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt> (A YANG Data Model for Interface Management) to Proposed Standard

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 1 May 2013 08:45:32 +0000

Hi,

See in-line. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Martin Bjorklund
> 
> > -  what should an NM application or operator do if the YANG
> > oper-status
> > -  and the IF-MIB operStatus differ?
> 
> I need help also with this one.  I do not understand the problem, so I
> cannot suggest a solution :(
> 
[[DR]] The problem is that if both NETCONF and SNMP implementations exist on the device and the operator reads both, he needs an indication about what takes precedence in case of inconsistency.

> > - persistence
> 
> I don't think this document is the right place to describe the
> persistency model for SNMP vs. NETCONF - if we do it here we probably
> have to do it in all other data-model specific documents as well...
> 

[[DR]]this is not an SNMP vs. NETCONF discussion, this is a specific data-model specification to understand what objects in the specific data model must be kept persistent. And yes, all data-model documents should specify this, if they do not the assumption is that all is lost on reboot (if this is not written some place it should be IMO)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 May 2013 11:06:23 +0200

> [[DR]] The problem is that if both NETCONF and SNMP implementations exist on the device and the operator reads both, he needs an indication about what takes precedence in case of inconsistency.

We can only recommend to file a bug report to the vendor in this case.

SNMP and NETCONF are both protocol to access the state of the
interface (as does the CLI, the Web UI, or even IPFIX for some data
objects). If things are not consistent, then there is a bug in the way
these interfaces access the instrumentation. I think it is difficult
to standardize which access methos is right if such a bug exists.

/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, 1 May 2013 07:55:20 -0700

On Wed, May 1, 2013 at 2:06 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > [[DR]] The problem is that if both NETCONF and SNMP implementations
> exist on the device and the operator reads both, he needs an indication
> about what takes precedence in case of inconsistency.
>
+1
Apply to comments about IF-MIB counter deltas not matching as well.

/js

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 1 May 2013 17:48:10 +0200

> to standardize which access methos is right if such a bug exists.

Perhaps what's really needed is to properly model the state of the interface, hence operational state. And since nothing more clever has been invented yet, I think it is necessary to face the duplication and have separate subtrees for operational state and config. The former would be managed by the device and the latter by the client (as a sort of recipe for changing the operational state). In particular, a list of interfaces would be present in either subtree.

The mapping of any MIB objects would then aim exclusively at the operational state subtree.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 May 2013 18:39:48 +0200

> The mapping of any MIB objects would then aim exclusively at the operational state subtree.

We are talking about a config false object here. It has the same
enumeration as the MIB object. I do not understand your comment.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 2 May 2013 08:01:52 +0200

> enumeration as the MIB object. I do not understand your comment.

Some operational state data for an interface should be present even without any configuration. In the current model, the operational state data are not present unless the corresponding entry in the "interface" list is *configured*. So, what I have in mind is a data tree like this:

   +--rw configuration
   |  +--rw if:interfaces
   |     +--rw if:interface [name]
   |        +--rw if:name                         string
   |        +--rw if:description?                 string
   |        +--rw if:type?                        ianaift:iana-if-type
   |        +--rw if:enabled?                     boolean
   |        +--rw if:link-up-down-trap-enabled?   boolean
   +--ro operational-state
      +--ro if:interfaces
         +--ro if:interface [name]
            +--ro if:name                         string
            +--ro if:description?                 string
            +--ro if:type                         ianaift:iana-if-type
            +--ro if:location?                    string
            +--ro if:oper-status                  enumeration
            +--ro if:last-change                  yang:date-and-time
            +--ro if:if-index                     int32
            +--ro if:link-up-down-trap-enabled    boolean
            +--ro if:phys-address                 yang:phys-address
            +--ro if:higher-layer-if*             interface-ref
            +--ro if:lower-layer-if*              interface-ref
            +--ro if:speed                        yang:gauge64
            +--ro if:statistics
               +--ro if:discontinuity-time    yang:date-and-time
               +--ro if:in-octets             yang:counter64
               +--ro if:in-unicast-pkts       yang:counter64
               +--ro if:in-broadcast-pkts     yang:counter64
               +--ro if:in-multicast-pkts     yang:counter64
               +--ro if:in-discards           yang:counter32
               +--ro if:in-errors             yang:counter32
               +--ro if:in-unknown-protos     yang:counter32
               +--ro if:out-octets            yang:counter64
               +--ro if:out-unicast-pkts      yang:counter64
               +--ro if:out-broadcast-pkts    yang:counter64
               +--ro if:out-multicast-pkts    yang:counter64
               +--ro if:out-discards          yang:counter32
               +--ro if:out-errors            yang:counter32

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 May 2013 08:40:40 +0200 (CEST)

"ietfdbh" <[email-masked]> wrote:
> [[DR]]this is not an SNMP vs. NETCONF discussion, this is a specific
> data-model specification to understand what objects in the specific data
> model must be kept persistent. And yes, all data-model documents should
> specify this, if they do not the assumption is that all is lost on reboot
> (if this is not written some place it should be IMO)
> 
>   
> [dbh>] I think the data model should specify the persistence of the data
> objects in this model, most notably the config objects. Does each config
> object persist across system reboots? Do some objects persist but
> not all?

In NETCONF, the persistency of the configuration nodes are not a
property of the node itself, but a property of the datastore in which
the node exists.

So it would be wrong to state that e.g., 'description' MUST be
persistently stored across reboots - this is not true for 'running' on
a device that supports 'startup'; but it is true for 'startup'.

> Is each YANG counter reinitialized on reboot, or are they expected to
> persist across reboots? 

This is already specified in the document.

/martin

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 1 May 2013 16:51:41 -0400

Hi,

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Martin Bjorklund
> 
[[DR]] The problem is that if both NETCONF and SNMP implementations exist on
the device and the operator reads both, he needs an indication about what
takes precedence in case of inconsistency.
[dbh>] I think that "what takes precedence?" is not something we can answer
in the data model; that will be implementation dependent.
I think what is needed is an "operational consideration" that says "the
status and counters in SNMP and the status and counters in NETCONF might be
different."
It could be good to explain that SNMP and NETCONF and CLI counters are
typically just front-ends for hardware or OS status/counters (as in
Juergen's email explanation).
But there is no MUST that says these counters MUST simply be front-ends for
hardware/OS counters. For example, as Juergen points out, SNMP counters are
sometimes cached.
SNMP counters are sometimes cached; CLI counters typically are not; Is it an
implementation decision whether NETCONF counters match other counter
interfaces? Let's say that someplace.

[dbh>] I think the data model should specify the persistence of the data
objects in this model, most notably the config objects. Does each config
object persist across system reboots? Do some objects persist but not all?
Is each YANG counter reinitialized on reboot, or are they expected to
persist across reboots? 
Some of the YANG counters include a reference to IF-MIB counters. Do the
YANG counters match the persistence specified in the corresponding MIB
objects?
If not, why not? (If this is an SNMP vs NETCONF difference, then is this
documented in a NETCONF document someplace?)

Having worked for a hardware vendor that also produced NM software, I am
aware that sometimes a hardware counter is added to match a MIB standard
required by customers.
Whether that hardware counter persists often depends on what the standard
requires.
So if you will develop any YANG counters that are not mirrors of SNMP
counters, how does the hardware designer know whether to make it persistent
or not?
This affects cross-vendor/cross-product interoperability.

David Harrington
[email-masked]
+1-603-828-1401

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 May 2013 10:09:42 +0200

> status and counters in SNMP and the status and counters in NETCONF might be

No, the counters as they are defined are the same. And note, some of
them also exist in IPFIX. Multiple protocols to access the counters
are a long time reality, even multiple standards track protocols. I do
not recall having read IPFIX operational considerations discussing why
some information elements might have a different accuracy as what you
might get form an SNMP implementation.

> Juergen's email explanation).

OK

> hardware/OS counters. For example, as Juergen points out, SNMP counters are

The cache does not change the semantics of the counters or introduce
new counters. The cache and the way the SNMP protocol works adds
sometimes surprising timing delays. So it boils down to:

  Network management protocols such as SNMP, IPFIX, NETCONF, or
  command line interfaces may differ in the time granularity in which
  they provide access to the counters.

Are we now going to add this to all future SNMP, IPFIX, NETCONF data
model documents?

> documented in a NETCONF document someplace?)

Section 5.1 of RFC 6241 defines the <running> configuration datastore
and Section 8.7 of RFC 6241 defines the <startup> configuration
datastore and how they are synced.
 
> This affects cross-vendor/cross-product interoperability.

Counters are typically config false objects and thus not
persistent. See also the definition of the counter datatypes in RFC
6021.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 May 2013 09:07:57 +0000

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Thursday, May 02, 2013 9:41 AM
> To: [email-masked]
> Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-
> 10.txt> (A YANG Data Model for Interface Management) to Proposed
> Standard
> 
> > > persistency model for SNMP vs. NETCONF - if we do it here we
> > > probably have to do it in all other data-model specific documents as
> well...
> > >
> >
> > data-model specification to understand what objects in the specific
> > data model must be kept persistent. And yes, all data-model documents
> > should specify this, if they do not the assumption is that all is lost
> > on reboot (if this is not written some place it should be IMO)
> >
> >
> > [dbh>] I think the data model should specify the persistence of the
> > data objects in this model, most notably the config objects. Does each
> > config object persist across system reboots? Do some objects persist
> > but not all?
> 

[[DR]] Why would this be different than for SNMP/SMI? The persistency information in the MIB modules determines the persistency characteristics of the data store. If operational considerations require some objects (configuration nodes) states must be kept in persistent memory. If there is no such objects there may be no need for a persistent datastore at all. 

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 May 2013 09:10:02 +0000

I agree with all that David says here. My wording ' he needs an indication about what takes precedence in case of inconsistency' was negligent (sorry!), but I think we reached the right conclusion about what operational considerations information needs to be inserted here. 

Thanks and Regards,

Dan

> From: ietfdbh [mailto:[email-masked]]
> Sent: Wednesday, May 01, 2013 11:52 PM
> To: Romascanu, Dan (Dan); 'Martin Bjorklund'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-
> [dbh>] I think that "what takes precedence?" is not something we can
> answer in the data model; that will be implementation dependent.
> status and counters in SNMP and the status and counters in NETCONF might
> be different."
> But there is no MUST that says these counters MUST simply be front-ends
> for hardware/OS counters. For example, as Juergen points out, SNMP
> counters are sometimes cached.
> SNMP counters are sometimes cached; CLI counters typically are not; Is
> it an implementation decision whether NETCONF counters match other
> counter interfaces? Let's say that someplace.
> 
> > > - persistence
> >
> specify this, if they do not the assumption is that all is lost on
> reboot (if this is not written some place it should be IMO)
> 
> 
> Whether that hardware counter persists often depends on what the
> standard requires.
> counters, how does the hardware designer know whether to make it
> persistent or not?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 May 2013 11:21:05 +0200

> [[DR]] Why would this be different than for SNMP/SMI? The persistency information in the MIB modules determines the persistency characteristics of the data store. If operational considerations requ…

NETCONF is not SNMP. NETCONF has configuration data stores and the
data stores have persistency properties for configuration data.

/js

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 2 May 2013 08:26:16 -0400

Hi,

js> NETCONF is not SNMP. NETCONF has configuration data stores and the data
stores have persistency properties for configuration data.

[dbh>] You're right that NETCONF is not SNMP. The MIB has different
persistence rules than NETCONF datastores.
There has long been a problem about whether SNMP SETs were automatically
captured in the startup config (e.g., NVRAM) or not.
Some implementations did not do this automatically; others did.
Some values, such as ifAlias, need to persist across reboots to be useful.
>From RFC2863: " the ifAlias name is non-volatile, and thus an interface must
retain its assigned ifAlias value across reboots"

So what happens if an operator uses NETCONF to configure 'description'
(which MAY map to ifAlias)?
I presume that, indirectly, NETCONF is being used to SET ifAlias in the
IF-MIB, by configuring the underlying instrumentation.
In a system that supports both running and startup, is the 'description'
value configured in 'running' automatically mirrored to startup?
Or does the operator need to send a command to set the value into the
startup config as well? 

This is not explained, and since 'description' uses a reference to ifAlias,
operators could interoperate this inconsistently.
That would affect interoperability.

What if the system only supports the 'running' config, but also supports the
MIB? Then what?
Does ifAlias become non-persistent across reboots if configured via NETCONF,
but persistent if configured using SNMP?
Should we warn the operators about that?

The YANG Interfaces config uses ifIndex.
ifAlias was provided in rfc2863 at least partly because ifIndex semantics
changed to accommodate operational realities.
ifAlias provides a way to recognize an interface, even if the ifIndex
corresponding to an interface changes across a reboot.
NM applications can use this to correlate the database of interface
operational state they acquired before reboot with the interface operational
state they acquire after a reboot.
This is important for tracking trends, and being able to study pre-reboot
states, to do casual analysis for fault/performance problems after a reboot.
With this module, you are now making it possible to acquire the same
operational state, but doing so using NETCONF instead of SNMP.
If ifAlias is non-persistent if configured by NETCONF, how should
operators/applications correlate ifIndexes across reboots for operational
state they have already read from the device using NETCONF?
Or, on a reboot, should they throw away all historic/trending information
they have previously acquired through NETCONF, and start over from scratch
on any trending analysis?

-- 
David Harrington
[email-masked]
+1-603-828-1401

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 May 2013 15:02:26 +0200 (CEST)

Hi,

> retain its assigned ifAlias value across reboots"

So pre-netconf devices with running and startup that implement ifAlias
faithfully probably store it in running, and do an implicit save to
nvram.

> value configured in 'running' automatically mirrored to startup?

No, and it has nothing to do with 'description' - the persistence is a
property of the data store.

> Or does the operator need to send a command to set the value into the

Yes.

> This is not explained

It is explained in RFC 6241.

> and since 'description' uses a reference to ifAlias,

You are right, this is a problem that noone thought about.

I see two options:

1)  Drop the mapping between ifAlias and description.
    (implementations that do this mapping anyway are on their own -
    just like they are today in their cli)

2)  Explain that if description is mapped to ifAlias, it MUST map to
    the persistently stored description; i.e., in startup if it is
    present, and running otherwise.

> What if the system only supports the 'running' config, but also supports the

This case is easy, b/c running is persistent if there is no startup.

> but persistent if configured using SNMP?

I don't think we should change the semantics of ifAlias.

> on any trending analysis?

They would probably just use the name of the interface if they are
using this module.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 2 May 2013 15:18:44 +0200

>    present, and running otherwise.

Or 3) map ifAlias to something else, perhaps a new node.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 May 2013 15:22:59 +0200 (CEST)

> Or 3) map ifAlias to something else, perhaps a new node.

But then you'll just push the same problem to this new node.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 2 May 2013 15:42:15 +0200

> But then you'll just push the same problem to this new node.

I understand Dave's concern was that the relationship between ifAlias and description is casual (MAY). So if the new leaf ("alias") is defined as THE equivalent of if ifAlias, it has to work the same for all implementations.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 May 2013 15:50:49 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> I understand Dave's concern was that the relationship between ifAlias
> and description is casual (MAY). So if the new leaf ("alias") is
> defined as THE equivalent of if ifAlias, it has to work the same for
> all implementations.

The problem as I see it is that ifAlias MUST be stored persistently.
This means that if a device supports both startup and running, and a
NETCONF client writes a new value for 'description' into running, this
new value should not be reported for ifAlias over SNMP.  When running
has been copied to startup, the new value should be reported.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 2 May 2013 16:08:03 +0200

> has been copied to startup, the new value should be reported.

This problem is not specific to ifAlias, it will be the same for many other parameters. If both NETCONF and SNMP (or any other mechanism, for that matter) attempt to set the same parameter, there have to be some arbitration rules, and the result will become the operational state value for that parameter (which all management interfaces should be able to discover). I think it would be very problematic (locks etc.) if the device was supposed to change something in a NETCONF datastore because it was changed via SNMP.

Lada

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 2 May 2013 12:37:08 -0400

Hi,

Comments inline.

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 

I understand Dave's concern was that the relationship between ifAlias and
description is casual (MAY). So if the new leaf ("alias") is defined as THE
equivalent of if ifAlias, it has to work the same for all implementations.
[dbh>] 
[dbh>] 
Actually, I think I have four concerns.
1) the relationship is casual. This means it is not standardized. On some
implementations, 'description' == ifAlias; on others it is not. ifAlias was
defined in RFC2863 for a reason, and some applications depend on it being
there to help interpret ifIndex correctly after a reboot. 

IF-MIB's ifAlias does not have to have a value, so applications cannot
always rely on it for this purpose, but 1) where the value is set, the value
should be able to be relied upon consistently across reboots, and 2) that
behavior should be able to be relied upon consistently across
implementations. Neither of these assumptions appear to be supported by the
YANG definition.

2) the semantic requirements of 'description' and ifAlias are different,
even when they are mapped, especially the persistence issue. The coexistence
of SNMP and NETCONF might be worthy of its own discussion, because it will
impact any MIB object declared in the MIB to be persistent that is mirrored
in a YANG data model, where persistence is different. It has become an IETF
requirement that persistence be discussed in MIB objects. At a minimum, any
YANG data object that tries to access the same underlying data object as a
MIB object (especially an IETF standard MIB object) that specifies
persistence constraints should probably discuss whether the MIB-described
persistence applies or not, to warn operators that they cannot expect the
same semantics across the two data models. It might be possible to note this
in the definition of counters in YANG-types, but it gets trickier for other
types, such as configured text strings like ifAlias. (and not all MIB
counters are persistent, so I think it really is an object-by-object issue.)

3) even if the ifAlias mapping is supported, the type/value constraints are
casual. 'description' MAY or MAY not restrict the type/character set so that
the values are consistent regardless of whether accessed through NETCONF or
SNMP. And there is no discussion of what should happen if the IF-MIB is
supported but not its ifAlias restrictions, and 'description' is set with a
value that doesn't meet the IF-MIB requirements; so if the underlying
instrumentation for ifAlias is configured with a value that is illegal for
ifAlias, what happens when SNMP tries to access this underlying
instrumentation and finds it contains an invalid value? Should the SNMP
agent somehow translate the value into a valid syntax? Report an error? I
think we cannot say "that's an SNMP problem", when the problem is caused by
this YANG module's definitions of a casual relationship between the two. If
'description' is mapped to ifAlias, then it has to have the same semantics
for all implementations that support the mapping.

4) The YANG module allows casual mapping relationships between its objects
and existing standard objects, and casual relationships between the
syntactic and semantic constraints of the data models, but there are no
indicators in the YANG model to query what is or is not supported in the
YANG implementation. And there is no discussion within the YANG model of the
operational considerations of these non-standardized YANG implementation
decisions. So is an NMS expected to test each implementation by configuring
a MIB-illegal test value into the YANG 'description' and then checking to
see what effect it has on an SNMP GET of ifAlias?

If the IETF published a standard YANG module, and subsequently published a
standard MIB module that defined a read-write object mapped to a config-true
YANG object, and chose to change the semantics of the underlying
instrumentation mapped to the MIB object and the YANG object, and did so in
a way that would be illegal for a subsequent YANG module to make, don't you
think it would be appropriate to at least point this out in the MIB module
that it is basically obsoleting/updating the semantics of the YANG object
and/or its underlying instrumentation? (and I think it would be appropriate
for IESG to say "wait a minute ...").

David Harrington
[email-masked]
+1-603-828-1401

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 May 2013 19:06:03 +0200

> counters are persistent, so I think it really is an object-by-object issue.)

David,

can you point me to an example of an IETF standards-track SNMP counter
that is persistent? I understand you are talking about this in a
broader scope but since this counter argument continues to pop up, I
like to know an example where this would matter.

Thanks,

/js

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 2 May 2013 14:51:59 -0400

Hi Juergen,

Hmmm. Thanks for asking me this question.
I think all counters, being read-only, reset on reboot since reboot is a
fundamental discontinuity.
So counters would be off the table in these discussions of reboot
persistence.

Thanks for narrowing the scope.

It's the read-write MIB objects that can be SET by an operator/application
that might require persistence across reboots.
And it's only config-true YANG objects that map to persistent MIB objects
that are a real concern here.
So we can narrow the scope of discussion even further.

I think there are not that many MIB objects that MUST persist, but they do
pop up here and there.
So I think we will need to deal with them whenever there is a config-true
YANG object mapping to one of these persistent MIB objects.
NM interfaces that don't modify managed objects, such as IPFIX and Syslog ,
would avoid this issue.
CLI isn't IETF-standardized so we can't address this very well.
So, for our purposes, I think we only need to talk about YANG and read-write
MIB model (or NETCONF/XML and MIB) co-existence.

(I'm a bit concerned about new efforts, such as SACM, that might try to
write their own config data models in XML or something, but that's a
discussion for a different forum.)

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, May 02, 2013 1:06 PM
To: ietfdbh
Cc: [email-masked]
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt>
(A YANG Data Model for Interface Management) to Proposed Standard

On Thu, May 02, 2013 at 12:37:08PM -0400, ietfdbh wrote:
 
> 2) the semantic requirements of 'description' and ifAlias are 
> different, even when they are mapped, especially the persistence 
> issue. The coexistence of SNMP and NETCONF might be worthy of its own 
> discussion, because it will impact any MIB object declared in the MIB 
> to be persistent that is mirrored in a YANG data model, where 
> persistence is different. It has become an IETF requirement that 
> persistence be discussed in MIB objects. At a minimum, any YANG data 
> object that tries to access the same underlying data object as a MIB 
> object (especially an IETF standard MIB object) that specifies 
> persistence constraints should probably discuss whether the 
> MIB-described persistence applies or not, to warn operators that they 
> cannot expect the same semantics across the two data models. It might 
> be possible to note this in the definition of counters in YANG-types, 
> but it gets trickier for other types, such as configured text strings 
> like ifAlias. (and not all MIB counters are persistent, so I think it 
> really is an object-by-object issue.)

David,

can you point me to an example of an IETF standards-track SNMP counter that
is persistent? I understand you are talking about this in a broader scope
but since this counter argument continues to pop up, I like to know an
example where this would matter.

Thanks,

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 May 2013 12:30:56 -0700

> MIB model (or NETCONF/XML and MIB) co-existence.
Looking over the RowStatus and StorageType TCs, it seems to
be implied that the "mirror" model for NV-storage is used.
Unless explicitly stated otherwise, when a row is activated
and intended to persist, it is assumed to be saved automatically.

NETCONF servers using the :startup capability do not follow this
persistence model.  So we narrow the scope further to NETCONF
servers running without an explicit startup config.

IMO, if the semantics of a MIB object call for something
different, then it is an implementation detail to make sure
the NETCONF/YANG version is correct.

I think the YANG Usage Guidelines (RFC 6087) is the proper
document to put guidelines for implementing YANG datastore
objects for optimal coexistence with SNMP agents.

Andy

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 2 May 2013 18:20:13 -0400

Hi,

From: Andy Bierman [mailto:[email-masked]] 

[dbh>] 

I think both cases are in scope, but have different solutions.

For implementations with :startup, we should advise operators that they are
responsible to provide persistence by explicitly writing to :startup.

For :startup-less implementations, we need to specify the persistence of the
relevant  :running config objects.

[dbh>] If the YANG module documentation doesn't require specific semantics,
then why would any implementation choice be incorrect?

i.e., any implementation choice would be correct for YANG, even if it
wouldn't be correct for the MIB object implementation.

Without specification, it becomes a matter of implementer
choice/interpretation, which could lead to non-interoperability.

Not a good thing for a standard.

[dbh>] Well, that's one place to provide general guidelines.

But when an operator is dealing with inconsistent values/behaviors across NM
interfaces, they are likely to look up the definitions of the relevant
objects, not the YANG Usage Guidelines.

[dbh>] Maybe we could just add an additional reference to each relevant
object (config-true,MIB persistent), pointing to the co-existence section in
YANG Usage Guidelines.

[dbh>] I'm not quite sure what you think should be put into such a section.

David Harrington

[email-masked]

+1-603-828-1401

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 May 2013 15:44:22 -0700

On Thu, May 2, 2013 at 3:20 PM, ietfdbh <[email-masked]> wrote:

> Hi,****
>
> ** **
>
> *From:* Andy Bierman [mailto:[email-masked]]
>
> ****
>
> Looking over the RowStatus and StorageType TCs, it seems to****
>
> be implied that the "mirror" model for NV-storage is used.****
>
> Unless explicitly stated otherwise, when a row is activated****
>
> and intended to persist, it is assumed to be saved automatically.****
>
> ** **
>
> NETCONF servers using the :startup capability do not follow this****
>
> persistence model.  So we narrow the scope further to NETCONF****
>
> servers running without an explicit startup config.****
>
> *[dbh>] *
>
> *I think both cases are in scope, but have different solutions.*
>
> *For implementations with :startup, we should advise operators that they
> are responsible to provide persistence by explicitly writing to :startup.*
>
> *For :startup-less implementations, we need to specify the persistence of
> the relevant  :running config objects.*
>
> **
>

There is nothing extra to say in the YANG object definitions.
NETCONF defines when the running configuration is saved
to NV-storage.

> **
>
> IMO, if the semantics of a MIB object call for something****
>
> different, then it is an implementation detail to make sure****
>
> the NETCONF/YANG version is correct.****
>
> *[dbh>] If the YANG module documentation doesn’t require specific
> semantics, then why would any implementation choice be incorrect?*
>
> *i.e., any implementation choice would be correct for YANG, even if it
> wouldn’t be correct for the MIB object implementation.*
>
> *Without specification, it becomes a matter of implementer
> choice/interpretation, which could lead to non-interoperability.*
>
> *Not a good thing for a standard.*****
>
> **
>

If SNMP and SMIv2 are silent about when/how active objects are
saved to NV-storage, then SNMP implementations are free to do
whatever they want.

I think the YANG module applies to NETCONF only.
RFC 6241 says how to save config=true data nodes.

I don't see why the YANG definition should couple together
the NETCONF and SNMP persistence models.  Since SNMP
has no way to access what is in the startup config it is hard
to see how it can get out of synch with NETCONF.

Maybe if you could provide some OLD and NEW text for
a YANG leaf that needs to be changed, your concerns would
be more clear.

Andy

> **
>
> I think the YANG Usage Guidelines (RFC 6087) is the proper****
>
> document to put guidelines for implementing YANG datastore****
>
> objects for optimal coexistence with SNMP agents.****
>
> *[dbh>] Well, that’s one place to provide general guidelines.*
>
> *But when an operator is dealing with inconsistent values/behaviors
> across NM interfaces, they are likely to look up the definitions of the
> relevant objects, not the YANG Usage Guidelines.*****
>
> *[dbh>] *Maybe we could just add an additional reference to each relevant
> object (config-true,MIB persistent), pointing to the co-existence section
> in YANG Usage Guidelines.****
>
> *[dbh>] I’m not quite sure what you think should be put into such a
> section.*****
>
> ** **
>
> David Harrington****
>
> [email-masked]****
>
> +1-603-828-1401****
>
> ** **
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 03 May 2013 10:32:00 +0200

> might get form an SNMP implementation.
IPFIX is not supposed to be replacing SNMP, while NETCONF could be 
replacing SNMP. Or at least used in parallel.

ingressInterface, http://www.iana.org/assignments/ipfix/ipfix.xml

    The index of the IP interface where packets of this Flow
    are being received.  The value matches the value of managed
    object 'ifIndex' as defined in [RFC2863].
    Note that ifIndex values are not assigned statically to an
    interface and that the interfaces may be renumbered every
    time the device's management system is re-initialized, as
    specified in [RFC2863].

Regards, Benoit

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 3 May 2013 11:28:04 +0200

On May 3, 2013, at 12:44 AM, Andy Bierman <[email-masked]> wrote:

> For implementations with :startup, we should advise operators that they are responsible to provide persistence by explicitly writing to :startup.
> 
> For :startup-less implementations, we need to specify the persistence of the relevant  :running config objects.
> 
>  
> 
> 
> [dbh>] If the YANG module documentation doesn’t require specific semantics, then why would any implementation choice be incorrect?
> 
> i.e., any implementation choice would be correct for YANG, even if it wouldn’t be correct for the MIB object implementation.
> 
> Without specification, it becomes a matter of implementer choice/interpretation, which could lead to non-interoperability.
> 

I agree. IMO we have to accept that, at boot time, the NV memory used by SNMP and NETCONF's startup datastore may contain different values for the same parameter. It is up to an admin to arrange things so that the system operates predictably.

Lada
 
> [dbh>] Well, that’s one place to provide general guidelines.
> 
> But when an operator is dealing with inconsistent values/behaviors across NM interfaces, they are likely to look up the definitions of the relevant objects, not the YANG Usage Guidelines.
> 
> [dbh>] Maybe we could just add an additional reference to each relevant object (config-true,MIB persistent), pointing to the co-existence section in YANG Usage Guidelines.
> 
> [dbh>] I’m not quite sure what you think should be put into such a section.
> 
>  
> 
> David Harrington
> 
> [email-masked]
> 
> +1-603-828-1401
> 
>  
> 
>

---

From: t.petch <[email-masked]>
Date: Fri, 3 May 2013 14:42:18 +0100

----- Original Message -----
From: "ietfdbh" <[email-masked]>
To: "'Juergen Schoenwaelder'" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 02, 2013 7:51 PM
> So counters would be off the table in these discussions of reboot

My head hurts (too many balls bouncing around).

I had thought that Netconf split configuration from state data.

And I thought that state data is the additional data on a system that is
not
   configuration data such as read-only status information and collected
   statistics.

And I thought that we were discussing interface configuration.

Therefore I thought that this discussion became ultra vires a few
hundred posts ago.

Where have I gone wrong?

Not that the persistence of statistics is not an important subject but I
think that there are far bigger gorillas in the room that are being
ignored.

Tom Petch

ps Sorry David, nothing to to with dbh, just the e-mail at which I gave
up.
> From: Juergen Schoenwaelder
[mailto:[email-masked]]
> Subject: Re: [netmod] Last Call:
<draft-ietf-netmod-interfaces-cfg-10.txt>
> can you point me to an example of an IETF standards-track SNMP counter
that

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 May 2013 16:06:12 +0200

> Therefore I thought that this discussion became ultra vires a few

Check the document we are discussing. There are config false counters.
(And yes, likely any other SNMP counters, they are not persistent.)

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 May 2013 07:28:54 -0700

....

> I agree. IMO we have to accept that, at boot time, the NV memory used by
> SNMP and NETCONF's startup datastore may contain different values for the
> same parameter. It is up to an admin to arrange things so that the system
> operates predictably.
>
>
There is some assumption here that SNMP and NETCONF get their
config at boot-time from different sources.  That does not seem likely.
Without :startup, it seems a correct implementation should be in sync.
There are no issues for the standard.

With :startup, there seems to be a "contract violation" possible.
If SNMP does in fact specify "save to NV-storage right now"
and NETCONF :startup of course only writes to NV-storage
via the copy-config operation from the client, then who wins?
The server cannot honor both the MIB object and YANG object
semantics.

If SNMP/SMI is silent on NV-storage behavior, then
NETCONF/YANG wins (there is no SNMP contract
to break).

Lada
Andy

---

From: t.petch <[email-masked]>
Date: Fri, 3 May 2013 18:05:10 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "ietfdbh" <[email-masked]>; <[email-masked]>
Sent: Friday, May 03, 2013 3:06 PM

> (And yes, likely any other SNMP counters, they are not persistent.)

Juergen

Yes, I know that really (they got added in -06 and increased the size of
the document considerably:-).

But read sections one and two and three and four and I can see no
mention of this state data, you stumble across it only when you plough
into the detail later.  I think that this is an omission that needs
rectifying.  Netconf is very strong on the separation of configuration
and state and here we are, producing a basic module and bundling them up
together again  I think that that needs an explanation (which should
probably touch on persistent storage).

Tom Petch

---

From: t.petch <[email-masked]>
Date: Fri, 3 May 2013 17:58:01 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Ladislav Lhotka" <[email-masked]>
Cc: "ietfdbh" <[email-masked]>; <[email-masked]>
Sent: Friday, May 03, 2013 3:28 PM
.

Andy

One of my gorillas is this difference in the model underlying SMI and
Netconf.

SMI got round to being very specific as to whether or not an object is
in persistent storage (grep StorageType).

Netconf focusses on startup and writing to a configuration datastore but
does not go into persistence.  Look at RFC6241 with an innocent eye and
it really does not talk about persistence in the way that SMI came to
do.  I think this an omission which needs rectifying, this as one of the
differences in the underlying model (which I expect to catch people
out).

Tom Petch

> Andy

------------------------------------------------------------------------
--------

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 May 2013 10:29:17 -0700

> in persistent storage (grep StorageType).
I am familiar with the StorageType TC.
It says that an entry can be expected to persist.
It does not say when the NV-copy is updated by the agent.

In NETCONF all config=true nodes are expected to persist.
If the :startup capability is present then this is a manual process.
If not, it is automatic (same as SNMP) and it is an implementation detail
how the server makes sure the value persists across a reboot.

> differences in the underlying model (which I expect to catch people

I've read RFC 6241 quite a few times, but you are right that there is no
explicit
section on the persistence model if :startup is not advertised.  It is
implied
in sec. 8.7.1 that the server automatically maintains the NV-storage
unless :startup is present.

It could be more clear in RFC 6241 that it is an implementation detail
how a server automatically retains configuration data across a reboot.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 May 2013 20:46:21 +0200

> probably touch on persistent storage).

Perhaps there is a need to better document NETCONF's persistency
model. I do not think this belongs into some arbitrary data model.

If you think something is missing in the introduction because there
are some counters, how about proposing some text?

/js

---

From: t.petch <[email-masked]>
Date: Fri, 3 May 2013 20:57:13 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "ietfdbh" <[email-masked]>; <[email-masked]>
Sent: Friday, May 03, 2013 7:46 PM
> are some counters, how about proposing some text?

Abstract
NEW
**The model includes both configuration data and counters for the
collection of statistics.

Introduction at end
NEW
**The model includes both configuration data and counters for the
collection of statistics.

Objectives at end
NEW
   o  the data model should include (read-only) counters in order to
gather statistics for octets, packets and errors, sent and received

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 4 May 2013 07:46:08 +0200

> probably touch on persistent storage).

I agree that configuration and state data should be separated. In fact, as it is now, the state data (statistics) are not present unless the corresponding (config=true) entry in the interface list is created.
IMO some state data for physical interfaces should be present even before any configuration has been written.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 4 May 2013 07:53:08 +0200

> collection of statistics.

It is not only statistics. I believe there has to be a way for the server to publish the OS-level names of all physical interfaces, their physical addresses, duplex settings etc. as state data.

Analogically for the ietf-ip module: there should be a way for the client to learn IP addresses that are in operational use - and these needn't be the same as manually configured addresses.

Lada

---

From: Xiang Li <[email-masked]>
Date: Sat, 04 May 2013 08:39:12 -0500

Hi Lada,

On page 29 the draft says:

...The main routing table is operationally connected to all
routing protocols for which a connected routing table
has not been explicitly configured.

Can the "main-routing-table" be thought as the default connected routing 
table "used" by
all routing protocols which do not have a connected-routing-table 
explicitly configured
for this router? In other words is the "main routing table" a kind of 
"default routing
table"? If yes I think it's better to use “default-routing-table” or 
another better term.
If that is not the case, but even if there are connected-routing-tables 
explicitly
configured the “main-routing-table” is still in play. Then how exactly 
this “main-routing-
table” is used? I have read this draft several times but still don't 
think I really get it.
I find it is rather difficult to understand its exact meaning and feel 
some additional texts are needed to explain it clearly. I am no routing 
expert but I think it's likely many folks will
stumble on this one ...

Thanks
--Xiang Li

---

From: t.petch <[email-masked]>
Date: Sat, 4 May 2013 18:10:00 +0100

---- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Juergen Schoenwaelder" <[email-masked]>;
<[email-masked]>
Sent: Saturday, May 04, 2013 6:53 AM

> collection of statistics.

It is not only statistics. I believe there has to be a way for the
server to publish the OS-level names of all physical interfaces, their
physical addresses, duplex settings etc. as state data.

<tp>
yes, trying to strike a balance between keeping it simple and being
embracingly accurate.

Perhaps
NEW
The model includes both configuration data and state data (such as
counters for the collection of statistics and operational status).

in each of the three cases.

Tom Petch

Analogically for the ietf-ip module: there should be a way for the
client to learn IP addresses that are in operational use - and these
needn't be the same as manually configured addresses.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 5 May 2013 08:54:11 +0200

> counters for the collection of statistics and operational status).

Yes, this looks good.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 5 May 2013 09:29:02 +0200

Hi,

On May 4, 2013, at 3:39 PM, Xiang Li <[email-masked]> wrote:

> Can the "main-routing-table" be thought as the default connected routing table "used" by
> all routing protocols which do not have a connected-routing-table explicitly configured
> for this router? In other words is the "main routing table" a kind of "default routing

Yes, this is correct. It is explained in sec. 4.4:

   A routing table is connected to a routing protocol instance by
   creating a corresponding entry in the "connected-routing-table" list.
   If such an entry is not configured for an address family, then the
   main routing table MUST be used as the connected routing table for
   this address family.

> table"? If yes I think it's better to use “default-routing-table” or another better term.

Well, this is certainly possible, although the term "default" has a specific meaning in YANG.

> If that is not the case, but even if there are connected-routing-tables explicitly
> configured the “main-routing-table” is still in play. Then how exactly this “main-routing-
> table” is used? I have read this draft several times but still don't think I really get it.
> I find it is rather difficult to understand its exact meaning and feel some additional texts are needed to explain it clearly. I am no routing expert but I think it's likely many folks will
> stumble on this one …

Yes, it is important that the text be clear and understandable. One change that might clarify the role and omnipresence of the main routing table would be to make it part of the operational state so that this table needn't be configured. This has to do with the parallel discussion about config versus operational state.

Thanks, Lada

---

From: Xiang Li <[email-masked]>
Date: Sun, 05 May 2013 09:30:38 -0500

On 5/5/2013 2:29 AM, Ladislav Lhotka wrote:
> Well, this is certainly possible,

Well, I think the term "default-routing-table" is way  better than 
"main-routing-table".
It precisely tells me what it is.

>   although the term "default" has a specific meaning in YANG.

I don't think how folks can confuse this the YANG's 'default'. Actually 
I don't think
YANG changes the meaning of the word 'default'.

> Yes, it is important that the text be clear and understandable.

IMO It's a VERY important. Otherwise it may give readers the impression 
the module is
convoluted...but in fact this module may be very cleverly designed.

>   One change that might clarify the role and omnipresence of the main routing table would be to make it part of the operational state so that this table needn't be configured. This has to do with the parallel discussion about config versus operational state.

Yes That should help.

-Xiang

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 5 May 2013 17:11:37 +0200

On May 5, 2013, at 4:30 PM, Xiang Li <[email-masked]> wrote:

> Well, I think the term "default-routing-table" is way  better than "main-routing-table".

Fair enough. What do others think of this change?

> I don't think how folks can confuse this the YANG's 'default'. Actually I don't think
> IMO It's a VERY important. Otherwise it may give readers the impression the module is

OK, but I'd prefer if the WG agrees on a unified solution for all core modules.

Lada

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 5 May 2013 22:20:45 -0700

Hi -

> Sent: Friday, May 03, 2013 10:29 AM
> Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt> (A YANG Data Model for Interface Management) to
Proposed Standard
...
> It does not say when the NV-copy is updated by the agent.

But to conform to the TC specification, it must guarantee that the
non-volatile storage will have been properly updated before
the processor is rebooted.  If the device has a hard reset button
or the like, this effectively requires NV updates to be completed
before the SNMP response to the SetRequest is transmitted.  If the
device only has soft reset and power failure detection with "last
gasp" handling (i.e. some number of cycles of processing after
an interruption in the power has been detected before the
CPU has to be safely halted / put to sleep), caching is possible,
but it would seem to me to be worth the implementation pain only
if the NV hardware were severely limited in the number of
write cycles it could handle.

I think the real issue goes back to how netconf's locks, both explicit
and implied, interact with other software capable of modifying "the
same" underlying datastore.  Consider, for example, the use of
SNMP contexts to provide access to startup configuration data.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 May 2013 07:57:05 +0200 (CEST)

Hi Randy,

> SNMP contexts to provide access to startup configuration data.

This is an interesting idea, and it would be great if we somehow could
use it.  But how would StorageType interact with such a context;
e.g. what happens if the manager SETs it to 'volatile' in the startup
context or maybe more problematic to 'nonVolatile' in the running
(default maybe?) context?   Can we make some recommentations for how
to implement both SNMP and NETCONF on the same device, by using
contexts?

/martin

---

From: t.petch <[email-masked]>
Date: Fri, 10 May 2013 12:35:15 +0100

The comments on this I-D triggered some more general thoughts in me
about netmod modules, which I tried to turn into an I-D; that has not
worked terribly well, but this section comes close to what I was
thinking

4.  Persistence

   SNMP developed the concept of persistent data and embodied it in a
   Textual Convention, StorageType [RFC2579] .  This means that the
   persistence or otherwise of the data is integral with definition of
   the data model.

   Netconf took a different approach, defining datastores, of which the
   one mandatory one is :running, although most devices will also have a
   :startup datastore.  Netconf says nothing about the persistency of
   the datastores.  :startup is used at boot time and so by implication
   is in a storage type that persists across shutdowns.  Again, by
   implication, :running is ephemeral since "Operations that affect the
   running configuration will not be automatically copied to the startup
   configuration " [RFC6241].  So making data persistent with Netconf
   requires a successful protocol operation, with SNMP, it is integral
   with the data definition.

   The impact of this could be far-reaching.

Not a criticism, rather a reflection of what is to be.

Tom Petch

p.s. the rest is at

http://www.ietf.org/internet-drafts/draft-petch-netconf-surprises-00.txt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 May 2013 14:36:41 +0200

> Not a criticism, rather a reflection of what is to be.

My understanding was that on systems that only have <running>, the
<running> configuration data store is persistent.

/js

---

From: t.petch <[email-masked]>
Date: Fri, 10 May 2013 17:43:09 +0100

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "Martin Bjorklund" <[email-masked]>;
<[email-masked]>
Sent: Friday, May 10, 2013 1:36 PM
> <running> configuration data store is persistent.

That is an interesting idea.  I had not thought of or seen any reference
to that in the RFC/I-D but it would make sense.  The devices I know of I
would expect to have <startup> so the idea of a device without one is
rather strange to me.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 May 2013 21:20:29 +0200

> would expect to have <startup> so the idea of a device without one is

My home router is a device that does not claim to have a separate
startup on its web interface. Every config change immediately persists
- I assume this is rather common on these kind of devices.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 May 2013 12:47:22 -0700

> - I assume this is rather common on these kind of devices.
Perhaps there is some confusion over the Distinct Startup capability
as defined in RFC 6241, sec. 8.7?

All NETCONF devices have persistent storage of the running configuration.
Devices with a distinct startup require the client to ask for the NV-storage
to be updated (e,g, CLI: write mem). A client can send <get-config>
requests for the startup datastore and the value may be different
than the running datastore.  The startup datastore does not exist
on NETCONF devices that do not advertise :startup.

NETCONF persistence tends to mirror the CLI persistence model
for the device.  SNMP is generally for monitoring, but the writable
objects I've implemented in routers (RMON, RMON2, etc.) followed
whatever the CLI did, not what SNMP said to do.

/js
Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 12 May 2013 07:15:03 +0000

So which one of these two statements is true?

(Juergen) My understanding was that on systems that only have <running>, the <running> configuration data store is persistent.

(Andy) My understanding was that on systems that only have <running>, the <running> configuration data store is persistent.

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, May 10, 2013 10:47 PM
To: Juergen Schoenwaelder; t.petch; Martin Bjorklund; [email-masked]
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt> (A YANG Data Model for Interface Management) to Proposed Standard

On Fri, May 10, 2013 at 12:20 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

/js

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 12 May 2013 07:18:57 +0000

Sorry,  I meant:

which one of these two statements is true?

(Andy) All NETCONF devices have persistent storage of the running configuration.

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Sunday, May 12, 2013 10:15 AM
To: Andy Bierman; Juergen Schoenwaelder; t.petch; Martin Bjorklund; [email-masked]
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt> (A YANG Data Model for Interface Management) to Proposed Standard

Dan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, May 10, 2013 10:47 PM
To: Juergen Schoenwaelder; t.petch; Martin Bjorklund; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt> (A YANG Data Model for Interface Management) to Proposed Standard

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 12 May 2013 14:00:18 +0200

> (Andy) All NETCONF devices have persistent storage of the running configuration.

Both statement can both be true. ;-) The problem is to find the
relevant pieces of text in the RFCs that talk about persistence since
apparently this is where some people are confused.

RFC 6241 says for example:

   o  configuration datastore: The datastore holding the complete set of
      configuration data that is required to get a device from its
      initial default state into a desired operational state.

While this does not say 'persist', one might argue that persistence is
kind of implied in order to "get a device from its initial default
state into a desired operational state". And the startup datastore
really is a special feature:

   o  startup configuration datastore: The configuration datastore
      holding the configuration loaded by the device when it boots.
      Only present on devices that separate the startup configuration
      datastore from the running configuration datastore.

Even without a startup, your running datastore still persists since it
is a configuration datastore.

   o  running configuration datastore: A configuration datastore holding
      the complete configuration currently active on the device.  The
      running configuration datastore always exists.

NETCONF was designed to modify configuration data and configuration
data usually persists (otherwise we would simply talk about writable
operational state, the stuff i2rs people are working on).

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 12 May 2013 13:24:09 +0000

> Sent: Sunday, May 12, 2013 3:00 PM
> To: Romascanu, Dan (Dan)
> Cc: Andy Bierman; t.petch; Martin Bjorklund; [email-masked]
> > (Juergen) My understanding was that on systems that only have
> <running>, the <running> configuration data store is persistent.
> >
> Both statement can both be true. ;-) The problem is to find the relevant
> pieces of text in the RFCs that talk about persistence since apparently
> this is where some people are confused.
> 
> kind of implied in order to "get a device from its initial default state
> into a desired operational state". And the startup datastore really is a
> special feature:
> 
> NETCONF was designed to modify configuration data and configuration data
> usually persists (otherwise we would simply talk about writable

[[DR]] So the practical way to formulate the requirement would be: 

Any device that supports NETCONF MUST implement the running configuration datastore in persistent memory. 

This is an important requirement from the point of view of developers implementing NETCONF on devices. I believe it should be stated directly and clearly, in a way that does not leave the way open to other implementations. 

Regards,

Dan

---

From: Andy Bierman <[email-masked]>
Date: Sun, 12 May 2013 07:00:48 -0700

On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan) <[email-masked]>wrote:

> This is an important requirement from the point of view of developers
> implementing NETCONF on devices. I believe it should be stated directly and
> clearly, in a way that does not leave the way open to other implementations.
>
>
Not sure why this is an issue.
Is anybody selling a NETCONF server that tosses all edits on the next
reboot?
Has anyone seen any evidence at all that the persistence of the running
config
is not implemented in NETCONF servers?

Clarifications are fine, but I don't think developers are confused on this
point.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 12 May 2013 14:08:48 +0000

From: Andy Bierman [mailto:[email-masked]]
Sent: Sunday, May 12, 2013 5:01 PM
To: Romascanu, Dan (Dan)
Cc: Juergen Schoenwaelder; t.petch; Martin Bjorklund; [email-masked]
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt> (A YANG Data Model for Interface Management) to Proposed Standard

On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-<mailto:j.schoenwaelder@jacobs->
> university.de<http://university.de>]
> Cc: Andy Bierman; t.petch; Martin Bjorklund; [email-masked]<mailto:[email-masked]>

Not sure why this is an issue.
Is anybody selling a NETCONF server that tosses all edits on the next reboot?
Has anyone seen any evidence at all that the persistence of the running config
is not implemented in NETCONF servers?

Clarifications are fine, but I don't think developers are confused on this point.

 [[DR]] I believe that this discussion proves that the text is not clear. If everybody agrees and clarifications are fine, let us put them in text.

Regards,

Dan

---

From: Andy Bierman <[email-masked]>
Date: Sun, 12 May 2013 07:26:48 -0700

On Sun, May 12, 2013 at 7:08 AM, Romascanu, Dan (Dan) <[email-masked]>wrote:

> *Sent:* Sunday, May 12, 2013 5:01 PM
> *To:* Romascanu, Dan (Dan)
> *Cc:* Juergen Schoenwaelder; t.petch; Martin Bjorklund; [email-masked]
> *Subject:* Re: [netmod] Last Call:
> <draft-ietf-netmod-interfaces-cfg-10.txt> (A YANG Data Model for Interface
> Management) to Proposed Standard****
>
> ** **
>
> ** **
>
> On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan) <[email-masked]>
> wrote:****
>
>
>
>
>
> Not sure why this is an issue.****
>
> reboot?****
> config****
> is not implemented in NETCONF servers?****
>
> ** **
>
> point.****
>  [[DR]] I believe that this discussion proves that the text is not clear.
> If everybody agrees and clarifications are fine, let us put them in text.
> ****
>
> **
>

OK -- the clarifications would be to the candidate and writable-running
capabilities.
Remember that a "default" NETCONF server is not required to implement any
writable objects.  It is not required to advertise :candidate or
:writable-running.
It is not required to implement <edit-config> or <copy-config> unless 1 of
these
capabilities is advertised.

**
> Regards,****
> Dan****

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 12 May 2013 22:54:59 +0200 (CEST)

"Romascanu, Dan (Dan)" <[email-masked]> wrote:
> Subject: Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt> (A
> YANG Data Model for Interface Management) to Proposed Standard
> 
> 
> On Sun, May 12, 2013 at 6:24 AM, Romascanu, Dan (Dan)
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> 
> 
> 
> > [mailto:j.schoenwaelder@jacobs-<mailto:j.schoenwaelder@jacobs->

I would say:

  The startup datastore MUST be persistent.

  If startup is implemented, running MUST NOT be persistent.
  If startup is not implemented, running MUST be persitent.

  The candidate datastore MUST be persitent.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 12 May 2013 14:48:01 -0700

On Sun, May 12, 2013 at 1:54 PM, Martin Bjorklund <[email-masked]> wrote:

> <draft-ietf-netmod-interfaces-cfg-10.txt> (A
> relevant
> state
> data

This does not quite describe the NETCONF persistence model.
When the server starts, the contents of running config get loaded
from some persistent storage.  The contents of candidate,
if it exists, are loaded from running at the same time.

Andy

---

From: t.petch <[email-masked]>
Date: Tue, 14 May 2013 11:40:40 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Sunday, May 12, 2013 9:54 PM
> > > > (Andy) All NETCONF devices have persistent storage of the
running
> > > configuration.
relevant
state
> > Any device that supports NETCONF MUST implement the running
configuration
> > datastore in persistent memory.
>
> I would say:
>

Martin

Yes, that looks very plausible, but is not what I see in the RFC/I-D:-(

My thoughts were triggered by the comments on persistence, notably that
SNMP and netmod are always going to be different, so I tried to write
down what the differences are, found I knew less than I thought, went
back to RFC/I-D and ended with what I put in my I-D.

It may be obvious to developers what they should implement, but I think
that users need a clearer statement, be it yours, Dan's or whoever's.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Thu, 16 May 2013 12:00:10 +0100

I see this as important to clarify but fear it will fade away only to be
resurrected some months later, not the first such occurrence on this
list:-(

I see Martin's position as very reasonable,

>   The candidate datastore MUST be persitent.

just that it is not what the RFC say.  Rather, I see

:running not writable
not very interesting

:running :writable-running
edits can be made to :running [8.2.1]
how the rest of it got there is undefined
what happens when the device shuts down is undefined

:startup :running :writable-running
edits can be made to :running these will be lost on shutdown [8.7.1]
the initial state of :running is taken from :startup [8.7.1]
:startup cannot be edited but can be replaced by a copy from
:running[8.7.1]

:candidate :startup :running :writable-running
edits can be made to :running these will be lost on shutdown [8.7.1]
the initial state of :running is taken from :startup [8.7.1]
:startup cannot be edited but can be replaced by a copy from
:running[8.7.1]
edits can be made to :candidate [8.3.5.1]
:candidate can be committed to :running [8.3.4.1]
:candidate can be copied to :startup [8.3.5.1]
:startup can be copied to :candidate [8.7.5.1]
:candidate persistence across shutdowns is undefined

I believe that this should be resolved, agreed and documented, as it
affects interoperability.

Tom Petch

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;

> > > Subject: Re: [netmod] Last Call:
<draft-ietf-netmod-interfaces-cfg-
running
relevant
state
configuration

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 May 2013 14:08:23 +0200

> affects interoperability.

I agree.

Also, the idea of sharing some persistent data between NETCONF and SNMP leads to the question whether the server is allowed to write to any config datastore and, if yes, under what circumstances and rules. It should certainly observe locks, but there can be other problems. For instance, if the server modifies candidate on its own, it could happen that a low-privileged client won't be able to perform a commit.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 May 2013 14:18:00 +0200

> Also, the idea of sharing some persistent data between NETCONF and SNMP leads to the question whether the server is allowed to write to any config datastore and, if yes, under what circumstances an…

With 'server' you mean 'SNMP agent'? If so, I would assume that the
SNMP agent simply acts like any other NETCONF client. Implementations
may use short-cuts as long as they lead to the same behaviour.

That said, I think this whole discussion belongs to the NETCONF
working group more than the NETMOD working group.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 May 2013 14:43:10 +0200

> With 'server' you mean 'SNMP agent'? If so, I would assume that the

I mean general rules for changes in any configuration datastore that take place outside a client's session.

> may use short-cuts as long as they lead to the same behaviour.

Sure, if this was the rule and no other changes were allowed, then it would be fine. It could still expose the known problems with shared candidate though.

> working group more than the NETMOD working group.

Oh yes, I didn't notice it was in NETCONF.

Lada