Subject: Re: [i2rs] Operational State

From: t.petch <[email-masked]>
Date: Thu, 1 May 2014 10:01:38 +0100

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 01, 2014 1:34 AM
> On Fri, Mar 28, 2014 at 10:48:13AM +0000, t.petch wrote:
> > This tri-partite split has been the norm for Ops Area for many years
> > now.
> > It may or may not be appropriate for I2RS but I do think that I2RS
> > should
> > at least take cognizance of this in deciding what terms to use
>
> I think this is one of the clearest description of one of our
problems - and
> thus requirements - that I've seen thus far. :-)

Yeah, problems are my speciality - I then look to Andy, Juergen, Lada
and Martin for solutions:-)

But, Jeff, you then say, in a parallel post

"The issues then comes back to the ones noted in
draft-bjorklund-netmod-operational-00: How do we distinguish
operational,
config or ephemeral config states? "

whereas I see operational state, config and read-only statistics, with
state (unqualified) referring to the first and last collectively!
'ephemeral' does not appear in Martin's I-D, nor would I expect it to -
I don't see it as a concept in YANG/NETCONF.

There is a separate issue of persistent and ephemeral in YANG, or,
arguably, in NETCONF, which is also not documented AFAICS.  This is
probably of less interest to I2RS at this time.

If there is one running datastore, then, presumably, it is persistent
(across reboots) - the documents appear not to say.  If there is running
and startup, presumably startup is persistent and running is not.  But
if you have running and acme-special datastores, then which is
persistent?  This is one of several issues, like operational state, that
have surfaced from time to time and, for me, have not got nailed down as
well as I would like, and so - surface from time to time.

Tom Petch

> -- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 May 2014 07:14:35 -0700

> probably of less interest to I2RS at this time.
N/Y treats config=true data nodes as special.
Collectively these data nodes form a configuration datastore.
This is only important for validation purposes -- determining
what is a "valid" running configuration.

> well as I would like, and so - surface from time to time.

There is no "acme-special" sort of datastore.
There are only the standard datastores.

If the server supports the "startup" datastore, then
all configuration changes are saved manually to NV-storage.
If the client does not save changes, they are lost at the next reboot.

If the server does not support the "startup" datastore then
the NV-storage must mirror the running configuration. All
config changes are saved automatically and immediately.

Operational state is different than config because only config
is validated according the the YANG constraints.  The operational
datastore may need some validation (e.g. field syntax check)
but it is not in anyway considered when validating the running datastore.

IMO the difference between ephemeral config and operational state
is not the NV-storage, but the validation procedure that accepts or rejects
the write request.

Tom Petch
> > -- Jeff
Andy

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 May 2014 10:46:14 -0400

Tom,

> I don't see it as a concept in YANG/NETCONF.

I agree it is not currently part of Netconf/Yang.  This is part of why I
raise the question.

> probably of less interest to I2RS at this time.

I actually think it's one of our bigger sticking points - or at least
something we need a clear answer on if N/Y is to be considered for i2rs use.
I2RS state is intended to be ephemeral. (See architecture document.)

> well as I would like, and so - surface from time to time.

This covers my point.  Moving this particular bit of discussion to Juergen's
response to me in another thread.

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 May 2014 08:02:17 -0700

> I2RS state is intended to be ephemeral. (See architecture document.)
I think this has been explained several times already,
starting in the IETF 89 slides.

I don't think anybody has said NC/RC/YANG could be used
as the I2RS protocol without a single change.  People has said
it is the best starting point for I2RS.  There seemed to be an overwhelming
consensus in the London meeting and on this mailing list to
use NC or RC + YANG as the I2RS starting point.

IMO, there needs to be a new datastore in the architecture that
contains I2RS data. The I2RS protocol will define how this data is accessed.
It's really not that complicated.

There are many implementations using NC/RC + YANG, and many of
these vendors have stated that they believe this approach can
be made to work for I2RS.

> > well as I would like, and so - surface from time to time.
I2RS does not have any interaction with the "local config" except maybe
to read it.  The NETCONF configuration datastores (candidate, running,
startup) are
not going to be used by I2RS.  Nothing I2RS does is going to even slightly
alter the definition of any NETCONF configuration procedures.

Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 1 May 2014 11:23:30 -0400

> be made to work for I2RS.

	I agree. I am not sure why we keep going round and round about these issues. Its been clear from the start that while yang/netconf
is a modeling language and protocol that can be used as a solid basis to solve the problems here, both need some minor modifications. 
In the case of yang, we've gone over many of the mods needed recently. NetMod is *currently* working on yang 1.1 which are minor 
changes that are probably a good vehicle to catch those changes, but waiting for another 9 months while we debate using the other
9 options will miss that window.  As for NetConf, we need to be able to relax the commit sequence/locking/back-out operations
so we have a "cut through" mechanism for fast programming. It is that simple. This has all been discussed at length over a year ago. 
We cannot wait forever for this WG to debate things ad infinitum.  When can we get to producing some relevant solutions?

	--Tom

> to read it.  The NETCONF configuration datastores (candidate, running, startup) are

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 May 2014 11:23:36 -0400

Andy,

> use NC or RC + YANG as the I2RS starting point.

Since we've not been very good about getting requirements explicitly listed,
part of the point of my questions is to tease out those details.

> It's really not that complicated.

And thus, "we need a new data store".  How it interacts with similarly
configured objects in other datastores is another detail I'm trying to tease
out as a requirement.

> alter the definition of any NETCONF configuration procedures.

Consider my BGP example noted elsewhere.  If I want to say "create a BGP
peer" as an I2RS operation and some of that behavior relies on other
underlying configuration (autonomous system, security policies, etc.) my
choices appear to be either to have some amount of shadowed configuration
objects on top of an existing BGP module or have a somewhat parallel module
(perhaps inheriting configuration objects from the main BGP module).

Which would you do?

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 May 2014 11:30:39 -0400

> is a modeling language and protocol that can be used as a solid basis to solve the problems here, both need some minor modifications. 

[grumpily]
Then if someone would please edit the wiki page to enumerate them and thus
to help tie-back to the requirements, I can stop asking my leading questions.

> We cannot wait forever for this WG to debate things ad infinitum.  When can we get to producing some relevant solutions?

Perhaps when the damned things are written down and work chartered to do
them.  If you have time to complain about the debate, you have time to
generate a short enumerated list.

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 May 2014 09:03:07 -0700

> configured objects in other datastores is another detail I'm trying to
OK -- I hope this ASCII art helps.

       NC/RC                 I2RS
           |                         |
          V                        V
    +-------------------+  +----------------+
     |  local config  |   | i2rs-config |
    +-------------------+  +----------------+
               |                     |
              V                    V
    +-------------------------------------------+
     |      operational state              |
    +-------------------------------------------+

The operational state contains a data-model dependent mix
of local and i2rs configuration, + learned data from protocols.
The "i2rs-config" datastore is like a "fastpath" config (as Tom described).
The operations on the local-config datastore use different rules and the 2
only
mix in the operational state.

> (perhaps inheriting configuration objects from the main BGP module).
I would start by making sure the management of the local config and
the I2RS config were fully aligned, because it is inevitable (if not
obvious)
that definitions in all 3 boxes above need to share data naming, data types,
and even data nodes.  A YANG grouping would be the starting point for
sharing objects. (Not sure if any tweaks needed to support I2RS uses-stmt).

-- Jeff

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 May 2014 12:09:52 -0400

Andy,

> OK -- I hope this ASCII art helps.

Fully parallel, which was the detail I was trying to get to. Thanks.

[...]

> sharing objects. (Not sure if any tweaks needed to support I2RS uses-stmt).

I'm not sure this fully answers my question.

In the case they are congruent, would you ever want to have I2RS simply
share the yang config (obviously needing some syntax changes that permits such
overlap) or would you prefer that they be simply use language inheritance
features across modules?

Perhaps that is a better way to ask it: Within the same module or using two
modules?

If within the same module, there is the implication of a requirement for
changes to the language to permit them to do so harmoniously.

If across different modules, there is the suggestion but not requirement
that as Working Groups provide yang modules for managing their components
that they are structured in such a way to permit I2RS re-use in our modules.

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 May 2014 09:44:35 -0700

> changes to the language to permit them to do so harmoniously.
I prefer 1 module, but it is not that simple. The user-defined typedefs and
identities (for identityref data type) can be shared (e.g. imported from
a common-types module). Even if the data nodes are separate, the
definitions can share YANG semantics in various ways.

New YANG statements (or extensions) to identify data affected by I2RS
will allow the data models to be mixed in the same module, augment across
modules, etc.

> that they are structured in such a way to permit I2RS re-use in our
I think it would be most efficient if a WG considered complete management
of a new protocol feature, and chartered configuration, I2RS, monitoring,
and notification support at the same time.

The IETF approach for the last 2 decades has been to leave most
of the management to the vendor CLI. The problem with this approach
is that over-laying monitoring systems (vendor + standard)
is easy, but not true for APIs that change the system.  Once the vendor API
is in
place, it is very difficult to overlay an incompatible standard API.

-- Jeff

Andy

---

From: t.petch <[email-masked]>
Date: Thu, 1 May 2014 17:56:52 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Jeffrey Haas" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 01, 2014 3:14 PM

Andy

I was being sloppy in my use of the terminology.  I was referring to the
capability of NETCONF to copy to from one entire datastore to another
where either or both may be urls.  In that looser sense, there could be
one or more of user-defined datastores somewhere, alongside the running.
I would expect the persistence of running to be unaltered by this but
... I don't know

I do see the persistence of 'config true' data as an important feature
thereof, as important as the validity checking that you highlight above;
and while I have seen consensus on the netconf WG list about
persistence, I have not seen the details make it into an I-D, so while
you and others (and I) may know it, those on this list with just the
documents to go on may have a few gaps; so I think it worth
re-iterating, as I started to do and you have followed up on.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Thu, 1 May 2014 18:07:36 +0100

----- Original Message -----
From: "Thomas Nadeau" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: "Jeffrey Haas" <[email-masked]>; <[email-masked]>; "t.petch"
<[email-masked]>
Sent: Thursday, May 01, 2014 4:23 PM
On May 1, 2014:11:02 AM, at 11:02 AM, Andy Bierman <[email-masked]>
> On Thu, May 01, 2014 at 10:01:38AM +0100, t.petch wrote:
<snip>
> be made to work for I2RS.

I agree. I am not sure why we keep going round and round about these
issues. Its been clear from the start that while yang/netconf
is a modeling language and protocol that can be used as a solid basis to
solve the problems here, both need some minor modifications.
In the case of yang, we've gone over many of the mods needed recently.
NetMod is *currently* working on yang 1.1 which are minor
changes that are probably a good vehicle to catch those changes, but
waiting for another 9 months while we debate using the other
9 options will miss that window.  As for NetConf, we need to be able to
relax the commit sequence/locking/back-out operations
so we have a "cut through" mechanism for fast programming. It is that
simple. This has all been discussed at length over a year ago.
We cannot wait forever for this WG to debate things ad infinitum.  When
can we get to producing some relevant solutions?

<tp>
Tom

I agree that we have gone over the modifications we need at a high level
but we then need someone in some working group to write the I-D,
fleshing out the details, outlining what is needed.  I have thought
about
'operational true'
as Andy suggested at IETF89, and find I have too many open issues to try
and write anything (and this has driven much of my posting to this list
in the past six weeks).

Of course, there are others better equipped than I on this list; it just
needs someone to start.

Tom Petch

--Tom

startup) are

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 May 2014 13:14:42 -0400

> will allow the data models to be mixed in the same module, augment across

Enumerating those changes would be helpful.

> and notification support at the same time.

That was a likely outcome.  Since other WGs aren't (to my knowledge) heavily
focused on building their protocol management in yang yet, this suggests a
significant amount of coordination with the related WGs if we want to define
I2RS functionality impacting them.  In effect, they might get their yang
written for free. :-)

This does, obviously, have charter impact.

> place, it is very difficult to overlay an incompatible standard API.

Been there, done that and had it... "shape" my opinion of SNMP.
I'll leave it at that.

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 May 2014 10:47:29 -0700

> Enumerating those changes would be helpful.

This has been done a few times.
Most recently April 22:
http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html

> Been there, done that and had it... "shape" my opinion of SNMP.

I don't see how standard I2RS data could use local config data unless it
was also standardized.

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 May 2014 13:57:41 -0400

Andy,

> http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html

I should respond there, but this was one of the messages that prompted my
question about data (operational state) vs. ephemeral config.

I don't believe we want to say "this is the module for monitoring the rib
and now you can write to it".

IMO, I think we want multiple data stores for configuration for adding
routes to the rib.

(I also thought the notification example was clear and didn't need further
comment.)

> I don't see how standard I2RS data could use local config data unless it

Basically, we want to make sure there is WG coordination on modules.
If WG has a module and it makes sense for I2RS to use it/extend it, that's
great when it makes sense.  Similarly, if we find the need to create an I2RS
module for work covered by another WG, we want to make sure we leave
as much re-usable infra for them as we can.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 May 2014 13:59:47 -0400

[followup to myself since I hit send too quickly]

> IMO, I think we want multiple data stores for configuration for adding

Unless the implication is that the i2rs ephemeral data store is simply using
the operational state model to implement "edit-data".  If that was implied,
I missed it first time around.

-- Jeff

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 1 May 2014 14:04:43 -0400

> (I also thought the notification example was clear and didn't need further

	There was another important point in Andy's post: that its possible to model that with Yang.

> as much re-usable infra for them as we can.

	For sure, but again, the point is that it is possible - and this could be a good starting point to move forward with rather than debating the theory of other models/etc... 

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 May 2014 11:10:11 -0700

> and now you can write to it".

that is not what the "edit-data" extension does.
It is a sub-statement that identifies I2RS editable data no matter what
YANG module is used to define the data.  The YANG config=true statement
identifies a data node as part of the configuration datastore. The edit-data
extension cannot be used on a config=true node, only non-configuration.

module foo {
   ...
   import i2rs { prefix i2rs; }

   container config-data {
       // NETCONF definitions here
    }

    container i2rs-data {
       config false;
       i2rs:edit-data;
    }

    container oper-data {
      config false;
       // plain read-only data
    }
}

Nesting is also possible -- up to the data modeler to decide what to use:

   1) i2rs-data inside config-data
   2) i2rs-data inside oper-data
   3) oper-data inside i2rs-data

> IMO, I think we want multiple data stores for configuration for adding

How many does I2RS need for itself?

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 May 2014 14:17:06 -0400

Andy,

>        // NETCONF definitions here

You're crystal clear to me now. Thank you.  This was not permitting I2RS to
be able to interact with/overlay part of config-data (per your example) as I
had hoped.

>    3) oper-data inside i2rs-data

What I had been hoping was for config-data to permit elements that
were effectively config true,i2rs.

(Or s/i2rs/ephemeral/ as per previous messagees.)

> How many does I2RS need for itself?

To clarify, a config-data data store, an i2rs-data datastore where
the i2rs portion may overlap.

Since I'm apparently not making my point well, I'll see if I can mockup my
understanding in a netconf like transaction.  (For Dean, I haven't caught up
in my reading to restconf, else I'd do that.)

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 01 May 2014 14:28:41 -0400

Jeff, I think the problem is subtler.
Even if I2RS wants to manipulate data represented in the config-true 
(CLI equivalent) tree, the I2RS data is still actually separate.  If you 
ask what the CLI has set, you get one answer.  If you ask what I2rS has 
set you get a different answer.  And if you ask what is actually 
operating you get the result of the arbitration.
At least that is what the architecture describes.

This clearly can be modeled in YANG.  It may take a little more effort.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 May 2014 12:08:15 -0700

On Thu, May 1, 2014 at 11:28 AM, Joel M. Halpern <[email-masked]>wrote:

> Even if I2RS wants to manipulate data represented in the config-true (CLI
> equivalent) tree, the I2RS data is still actually separate.  If you ask
> what the CLI has set, you get one answer.  If you ask what I2rS has set you
> get a different answer.  And if you ask what is actually operating you get
> the result of the arbitration.
I didn't think the I2RS charter covered writing to the local configuration,
that is maintained by NETCONF.  I hope not.

But if there is some intent to support a "copy-to-local-config" option
in the I2RS protocol, then a mapping from the I2RS data to the
local config data would be needed.

Yours,

Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 1 May 2014 15:10:38 -0400

On May 1, 2014:3:08 PM, at 3:08 PM, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Thu, May 1, 2014 at 11:28 AM, Joel M. Halpern <[email-masked]> wrote:
> Even if I2RS wants to manipulate data represented in the config-true (CLI equivalent) tree, the I2RS data is still actually separate.  If you ask what the CLI has set, you get one answer.  If you ask what I2rS has set you get a different answer.  And if you ask what is actually operating you get the result of the arbitration.

	Right. The thinking was to include some option in the protocol extensions to trigger a copy-to-local-config "later" either of the entire running config, or parts of it. But the normal operation was only (and as quickly as possible) to the running config/rib/system.

	--Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 01 May 2014 15:27:57 -0400

For clarity, I was trying to make sure we understood that they need to 
be separate stores.  As far as I can tell there is no need for 
'copy-to-local'.
Yours,
Joel

On 5/1/14, 3:08 PM, Andy Bierman wrote:
>
>
>
> On Thu, May 1, 2014 at 11:28 AM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     (CLI equivalent) tree, the I2RS data is still actually separate.  If
>     you ask what the CLI has set, you get one answer.  If you ask what
>     I2rS has set you get a different answer.  And if you ask what is
>     actually operating you get the result of the arbitration.
>         _________________________________________________
>         i2rs mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/i2rs
>         <https://www.ietf.org/mailman/listinfo/i2rs>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 02 May 2014 10:52:43 +0200

> There are only the standard datastores.

Hmm, RFC 6241 says in sec. 5.1: "Additional configuration datastores MAY be defined by capabilities."

I think Tom's points are valid. It's been my impression that the NETCONF spec remained somewhat underspecified in order to be able to accommodate different logics and data organizations of existing CLIs. Maybe it's time to set stricter rules because now it seems we will soon be dealing with different protocols accessing and changing the same data.

Lada 

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 02 May 2014 11:09:50 +0200

> OK -- I hope this ASCII art helps.

Right, but then some rules have to be stated for dealing with the operational state so that NC/RC and I2RS (or another protocol, for that matter) don't step on each other's toes.

> sharing objects. (Not sure if any tweaks needed to support I2RS uses-stmt).

This needn't necessarily be true - I think the common denominator really is the operational state. I can imagine different configuration protocols/systems speaking completely different languages.

Just an example: OpenWRT defines a UCI format for configuring a firewall that is quite different from the standard configuration of iptables, although under the hood OpenWRT uses iptables as well.

Lada

---

From: t.petch <[email-masked]>
Date: Fri, 2 May 2014 10:29:40 +0100

---- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Jeffrey Haas" <[email-masked]>
Cc: "t.petch" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 01, 2014 7:10 PM
>    3) oper-data inside i2rs-data

Andy, Jeff

I wonder if edit-data on its own will be enough.

'config true' in base YANG allows the data to be written, but it also
makes it very easy for NETCONF to read what it wants to, with a
get-config RPC.  Strictly such a function is unnecessary, it could all
be done with filters, which would be a nightmare and error-prone.  So we
have get-config that gets the 'config  true' subset of leafs etc.  And,
with no apparent downside, there is just the one substatement, 'config
true', the two sets are identical.

With I2RS, we need writable operational state so we need an edit-data
substatement added to YANG but what about getting the data that I2RS
wants to see?  Do we need an i2rs-data substatement so that we can
readily tag the parts of the model that i2rs wants to get, e.g. with a
new 'get-i2rs' RPC?

I think that we will, that is the set of YANG leafs etc that I2RS will
want to edit and the sets of leafs that I2RS will want to get in a
straightforward manne will not be the same (eg the latter will include
read-only statistics and 'config true').  And yes, it could all be done
with filters, which could be a nightmare.

Tom Petch

p.s. this is one of the issues that I have been wrestling with that I
alluded to in my response to Tom Narten

> > great when it makes sense.  Similarly, if we find the need to create
an
> > I2RS

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 May 2014 08:29:00 -0700

> readily tag the parts of the model that i2rs wants to get, e.g. with a

If definitions are combined in the same module(s), then there is
no way to prevent NETCONF from skipping over these special config=false
nodes.  I doubt that is a problem.

I picture the operational state as the mixing bowl for the 2 config sources
and data learned from protocols and system events.  It seems
both NETCONF and I2RS would be able to pick the data is cares about
out of that.

This is a weakness in YANG that may get improved in YANG 1.1.
Since it is officially just for NETCONF, there are no mechanisms
(other than vendor extensions) to tag the data as specific to
some subset of protocols.

> with filters, which could be a nightmare.
Examples of read-only data that only I2RS would want to get would help.

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 2 May 2014 11:40:36 -0400

> both NETCONF and I2RS would be able to pick the data is cares about

I think this is what I'd like to see personally.

> some subset of protocols.

As I mentioned elsewhere, I'm hoping we don't go down the path of "editable
operational state", instead configuration semantics for our purposes.

> Examples of read-only data that only I2RS would want to get would help.

I believe that it would largely overlap config false state desired for
normal module purposes in many cases.  For example, interface statistics
would likely be part of the standard interface module.  Where things get
interesting are specific augmentations that tie different information
domains together - interface stats correlated against routing, for example.
(For prefix X, traffic is seen - similar to IPFIX exports.)

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 May 2014 09:00:08 -0700

> operational state", instead configuration semantics for our purposes.
I guess I agree, because when trying to figure out some corner-cases,
I changed the datastore name to "i2rs-config".

IMO this makes it easier to conceptualize the underlying system as
the result of the priority-based arbitration between local-config and
i2rs-config.
It is easier to see that the system is going to have to re-install an entry
from local-config when an I2RS client removes a higher-priority
entry from i2rs-config (e.g., your BGP peer example).  Both configs
exist in parallel, and the oper-state has the entry that is higher priority.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 May 2014 18:09:42 +0200

> operational state", instead configuration semantics for our purposes.

At some point in time, we need to get the terminology sorted out. NC
has well defined configuration datastores and YANG has a well defined
concept of configuration data (config true). NC kind of assumes that
data in configuration datastores has an associated concept of
persistence (e.g., changes to <running/> persist unless you have an
explicit <startup/>, <candidate/> is a temporary scratch pad).

We are talking about another writable datastore (or potentially
multiple of them). Some call the data in this writable datastore
configuration, others prefer to use a different term to avoid a clash
with what NC and YANG consider configuration. If we could find a good
name for such writable datastores, I likely make communication much
simpler.

And yes, I think the model that the contents of the configuration
datastore, the writable datastore(s) as well as the information
learned dynamically from various control plane protocols all lead to
the final operational state. (In fact, one could consider a model
where control plane protocols all conceptually come into the system
via additional control protocol specific writable datastores.)

So, can we find a name for these 'other writable datastores' and then
use that term instead of 'writable operational state', 'ephemeral
config', 'i2rs datastore', etc.?

/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: Fri, 2 May 2014 09:26:23 -0700

> config', 'i2rs datastore', etc.?
I imagine I2RS will be completely separate from NETCONF and it should
have its own datastore -- so "i2rs-config" is appropriate because I2RS is
the
only protocol using that datastore. The combined "operational state"
is not editable.

It is tempting to generalize the problem so the solution works for any
protocol (not specifically I2RS) and any data (not specifically RIB data).
But that would be out of scope.  Understanding the interaction between
local-config and i2rs-config is certainly in scope. There is lots of work
left to be done there, so if it seems fuzzy to you, that's probably why ;-)

Andy

---

From: t.petch <[email-masked]>
Date: Fri, 2 May 2014 17:36:31 +0100

- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: "t.petch" <[email-masked]>; "Jeffrey Haas" <[email-masked]>;
<[email-masked]>
Sent: Friday, May 02, 2014 4:40 PM
> (For prefix X, traffic is seen - similar to IPFIX exports.)

Using my usual terminology, of read only statistics as being the part of
state (YANG leafs etc with a substatement of 'config false') that is not
operational state, and turning to the I2RS use case documents, I see:

in -keyupdate

"   There are a variety of statistics related to the operation of BGP
   that are invaluable to network operators.  These statistics generally
   help operators, and developers, understand the present state and
   future scalability of BGP."

or in draft-white

"   o  The ability to interact with traffic flow and other network
      traffic level measurement protocols and systems, in order to
      determine path performance, top talkers, and other information
      required to make an informed path decision based on locally
      configured policy."

or in -mbb

"  The I2RS architecture (client-agent) should solve the two problems
   mentioned above naturally by enabling the use of centralized
   controllers, which control and manage the entire network's devices
   and store the whole routing and service information directly.
   Meanwhile, the outages and traffic congestion or discards can be
   detected real-time with I2RS Client(s) connected to the I2RS agents
   in each node which provide real-time status via notification service.
   An I2RS client with this ability will allow the I2RS clients to keep
   optimal state dynamically all the time."

while I would expect it to be required for anything to do with ECMP/SRLG
etc so yes, I see a need for I2RS to access read-only statistics.

Tom Petch

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 2 May 2014 13:10:33 -0400

On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> have its own datastore -- so "i2rs-config" is appropriate because I2RS is the

	Yes, that makes sense. Then if at some point in time you want to save 
the running config (i2rs), the system has to explicitly copy it over. But until then,
its separate.  The only question is: what is the complete running config represented as?
And what if Netconf wants to modify the running config (i.e.: and the RIB in particular)?

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 May 2014 10:33:37 -0700

> And what if Netconf wants to modify the running config (i.e.: and the RIB
That copy-to-local-config feature would be extra, outside the scope of the
i2rs-config.
IMO, the i2rs-config datastore has these properties:
   - editable with I2RS using the I2RS owner-priority access control model
   - only field validation; YANG datastore validation is ignored,
     except for mandatory=true|false and min/max-elements
   - data is never saved across a reboot; never saved to NV-storage like
NETCONF config
   - data does not time out; The system or external I2RS client must remove
any data
     to cleanup
   - the system uses the priority values to determine if local-config or
i2rs-config
     wins wrt/ operational values; the system must install the correct
config if
     priorities change

--Tom

Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 2 May 2014 14:07:08 -0400

On May 2, 2014:1:33 PM, at 1:33 PM, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Fri, May 2, 2014 at 10:10 AM, Thomas Nadeau <[email-masked]> wrote:
> 
> That copy-to-local-config feature would be extra, outside the scope of the i2rs-config.

>    - data is never saved across a reboot; never saved to NV-storage like NETCONF config
>    - data does not time out; The system or external I2RS client must remove any data
>      to cleanup
>    - the system uses the priority values to determine if local-config or i2rs-config
>      wins wrt/ operational values; the system must install the correct config if
>      priorities change

	Right. If we take that approach we need to have a way of the i2rs "protocol" to signal that the config 
needs to be saved "soon".  That is, its not done in real time, but rather as a background process. 
Its probably. This can either be through a single keyword that is added under the i2rs-config section, or
per element or even per-element, if we decide to be more granular. 

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 May 2014 11:49:21 -0700

> per element or even per-element, if we decide to be more granular.
You seem to be suggesting that the I2RS behavior of forgetting all injected
state
if the router happens to reboot is not that useful, and therefore it needs
to be
saved in the background (best-effort).

I think it is up to all the I2RS clients to always be around to receive some
sort of agent-reboot event, and re-install any required I2RS config.
I can't imagine any use cases where the operator thinks "I only need to
install this RIB data until that router accidentally reboots".

--Tom
Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 2 May 2014 16:51:11 -0400

On May 2, 2014:2:49 PM, at 2:49 PM, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Fri, May 2, 2014 at 11:07 AM, Thomas Nadeau <[email-masked]> wrote:
> 
> You seem to be suggesting that the I2RS behavior of forgetting all injected state
> if the router happens to reboot is not that useful, and therefore it needs to be
	
	Not necessarily. I am just saying that its an option that someone might want to use. 

> install this RIB data until that router accidentally reboots".

	Yes, exactly. I didn't mean to imply it was mandatory to eventually save the running config; just that if you want to, 
we should bake this capability in.

	--Tom

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 3 May 2014 11:23:03 +0200

On Fri, May 02, 2014 at 10:33:37AM -0700, Andy Bierman wrote:

> > I imagine I2RS will be completely separate from NETCONF and it
> > should have its own datastore -- so "i2rs-config" is appropriate
> > because I2RS is the only protocol using that datastore. The
> > combined "operational state" is not editable.

Separate datastore, yes. Is it a config datastore? I thought no. The
name "i2rs-config" seems to imply that so I am confused. Perhaps you
should simply call it "i2rs" datastore.

>      wins wrt/ operational values; the system must install the correct

With all this, I am not sure how copy to local config will work. You
will then likely get all the validation errors and there may be
interesting access control issues with it. I also do not know what the
"I2RS owner-priority access control model" really is. Where are the
priority values that control whether the running configuration
datastore or the i2rs datastore value is taken? May I presume that
this is configured in the configuration datastore (e.g. there is going
to be a YANG data model to configure the priority rules)?

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 3 May 2014 03:16:27 -0700

> to be a YANG data model to configure the priority rules)?
I was not defining something out of scope for I2RS.
That is up to the vendor implementing this extension.
Obviously the YANG validation rules are not ignored for config=true nodes.

I2RS uses its own access control, not NACM.
You ask about minor details of a protocol that has not been written yet.
The priorities are set somehow.  (I am not convinced the trivial I2RS
priority
scheme will actually work -- using 1 numeric value for all of local-config.
It seems like the priority could be data-dependent.)

/js
Andy

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 7 May 2014 06:56:41 -0400

Andy:

Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom Nadeau: 

<snip> 

I imagine I2RS will be completely separate from NETCONF and it should have
its own datastore -- so "i2rs-config" is appropriate because I2RS is the
only protocol using that datastore. The combined "operational state" is not
editable.

Yes, that makes sense. Then if at some point in time you want to save  the
running config (i2rs), the system has to explicitly copy it over. But until
then, its separate.  The only question is: what is the complete running
config represented as? And what if Netconf wants to modify the running
config (i.e.: and the RIB in particular)?

</snip>

-----

Why only is the copy-to-local-config feature out of scope for the
I2rs-config?   How can the work be interoperable if this feature (required
or optional) does not work the same in different vendor's boxes?  If the
implementations are different, this is great (differentiated products =
good); but IMHO this feature actions has to be interoperable. that is give
the same effective response in the different vendors.   

Can you explain further? 

<snip> 

Right. If we take that approach we need to have a way of the i2rs "protocol"
to signal that the config 

needs to be saved "soon".  That is, its not done in real time, but rather as
a background process. 

Its probably. This can either be through a single keyword that is added
under the i2rs-config section, or

</snip> 

IMHO it is important to know when the write to local-config is done even if
done in background.   Are you indicating there is no
write-config/ack-complete-write config interaction? 

<snip> 

</snip> 

If you re-install any required I2RS config, are you sure this is what the
I2RS client wants? 

Sue

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 7 May 2014 06:58:47 -0400

Comment 2 
   And this:
Jeff: 

Do you consider the question from Ken's original post below to be answered? 

<snip> 
<Ken's text> 

       "In contrast, although multiple I2RS clients may need to
        supply data into the same list (e.g. a prefix or filter
        list), this is not considered an error and must be
        correctly handled.  The nuances so that writers do not
        normally collide should be handled in the information
        models."

      Do you mean data model?  Can you provide an example for how
      this can be handled in an info/data model?  - are lists
      expected to be sorted-by-system to prevent shadowing

This a logical description  and not a model description.
</ken text>
</snip> 
----------
Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Friday, May 02, 2014 11:41 AM
To: Andy Bierman
Cc: Jeffrey Haas; [email-masked]; t.petch
Subject: Re: [i2rs] edit-data substatement Re: Operational State

On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
> I picture the operational state as the mixing bowl for the 2 config 
> sources and data learned from protocols and system events.  It seems 

> (other than vendor extensions) to tag the data as specific to some 
> subset of protocols.

> > I think that we will, that is the set of YANG leafs etc that I2RS 
> > will want to edit and the sets of leafs that I2RS will want to get 
> > in a straightforward manne will not be the same (eg the latter will 
> > include read-only statistics and 'config true').  And yes, it could 
> > all be done with filters, which could be a nightmare.
> >
> >

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 May 2014 08:42:43 -0700

On Wed, May 7, 2014 at 3:56 AM, Susan Hares <[email-masked]> wrote:

> its own datastore -- so "i2rs-config" is appropriate because I2RS is the only
> protocol using that datastore. The combined "operational state" is not
> editable.
>
>
>
> good); but IMHO this feature actions has to be interoperable... that is give

Writing to the local config is the charter of the NETCONF WG, not I2RS.
In order to copy from the I2RS data model to the configuration data model,
a detailed mapping is required.  Since the local-config is out of scope,
the config data corresponding to the I2RS data is not required to exist.
If it does exist, it can be vendor-specific, right? So the mapping is
vendor specific.

I would agree with you if I2RS was planning on standardizing data models
for configuration and RIB editing.  It that were the case, then I would
re-ask
the question Ron Bonica raised in London -- why would we want to write
config data models with 1 language and I2RS data models with a different
language?

> IMHO it is important to know when the write to local-config is done even
> if done in background.   Are you indicating there is no

> If you re-install any required I2RS config, are you sure this is what the

The protocol request would indicate what the client wants (e,g,
copy-to-local config flag set).
Since notifications are unreliable, a client will poll the 'agent-boots'
counter frequently to
see if needs to re-install lost state.  This design does not scale well and
introduces significant
latency.  It is much more convenient to have the agent deal with
reinstall-after-reboot.

Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 7 May 2014 13:08:49 -0400

On May 7, 2014:6:56 AM, at 6:56 AM, Susan Hares <[email-masked]> wrote:

> I imagine I2RS will be completely separate from NETCONF and it should have its own datastore -- so "i2rs-config" is appropriate because I2RS is the only protocol using that datastore. The combined "operational state" is not editable.
>  
> Yes, that makes sense. Then if at some point in time you want to save  the running config (i2rs), the system has to explicitly copy it over. But until then, its separate.  The only question is: what is the complete running config represented as? And what if Netconf wants to modify the running config (i.e.: and the RIB in particular)?
>  
> Why only is the copy-to-local-config feature out of scope for the I2rs-config?   How can the work be interoperable if this feature (required or optional) does not work the same in different vendor’s boxes?  If the implementations are different, this is great (differentiated products = good); but IMHO this feature actions has to be interoperable… that is give the same effective response in the different vendors.  
>  
> Can you explain further?
>  
> 
> <snip>
>  
> IMHO it is important to know when the write to local-config is done even if done in background.   Are you indicating there is no write-config/ack-complete-write config interaction?

	There needs to be some sort of confirmation mechanism. Whether this is an async notification, the state of a variable changed that the writer can check (or both) is up for debate. 

	--Tom

> If you re-install any required I2RS config, are you sure this is what the I2RS client wants?
>  
> Sue

---

From: t.petch <[email-masked]>
Date: Thu, 8 May 2014 18:45:34 +0100

Sue

I am afraid I cannot parse this e-mail to see where the text is yours
and where it is something earlier and where the questions are
unanswered:-(

Datastores in NETCONF/YANG are a NETCONF construct and define a set of
configuration information.  YANG has no concept of where data is or its
persistence except to a limited extent when it is applying validation
logic, as in RFC6020 s7.5.3 (which probably does not make much sense in
isolation - my I-D might help).

So a datastore is a set of 'config true' data nodes stored somewhere.
Move away from configuration and there is no other concept, apart from
everything else, all the statistics, routing tables and so on.  Hence my
suggestion that I2RS will need a YANG substatement to mark out the data
of interest to I2RS, perhaps with a name attached so that there can be
multiple sets of I2RS data, to read, to write, to copy and so on as a
meaningful unit; it would probably be a mistake to call that a datastore
given the more specific meaning that that term has acquired in NETCONF,
of  a unit of configuration data.

Tom Petch

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'Andy Bierman'" <[email-masked]>; "'Thomas Nadeau'"
<[email-masked]>
Cc: "'Jeffrey Haas'" <[email-masked]>; <[email-masked]>; "'Juergen
Schoenwaelder'" <[email-masked]>; "'t. petch'"
<[email-masked]>
Sent: Wednesday, May 07, 2014 11:56 AM

> I imagine I2RS will be completely separate from NETCONF and it should
have
> only protocol using that datastore. The combined "operational state"
is not
the

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 May 2014 21:17:33 +0200

Tom,

RFC 6241 says:

   o  datastore: A conceptual place to store and access information.  A
      datastore might be implemented, for example, using files, a
      database, flash memory locations, or combinations thereof.

   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.

Note the distinction between a datastore and a configuration
datastore.

/js

---

From: [email-masked]
Date: Fri, 9 May 2014 08:54:01 +0800

I have raised a issue about this in netmod WG,
see:  http://www.ietf.org/mail-archive/web/netmod/current/msg09716.html
/frank

> > If you re-install any required I2RS config, are you sure this is what

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 9 May 2014 00:52:40 -0400

Tom: 

Thank you for your note of your preference email reading, and I've also read
earlier of your need for html compliant i2rs notes rather than a pdf form.
Please let me know if your format issues regarding email have been addressed
by the format of this email. Thank you for your comments on yang. 

My questions were:  1) Why only is the copy-to-local-config feature out of
scope for the  I2rs-config?  2)  Are you indicating that there is no
write-config/ack and complete-write config interactions?   My questions did
not have to do with Yang's functionality, but with your
statements/assumptions with I2RS.  If you answered these questions, please
send email clip (private/public).  

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Thursday, May 08, 2014 1:46 PM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]
Subject: Re: [i2rs] edit-data substatement Re: Operational State

Sue

I am afraid I cannot parse this e-mail to see where the text is yours and
where it is something earlier and where the questions are unanswered:-(

Datastores in NETCONF/YANG are a NETCONF construct and define a set of
configuration information.  YANG has no concept of where data is or its
persistence except to a limited extent when it is applying validation logic,
as in RFC6020 s7.5.3 (which probably does not make much sense in isolation -
my I-D might help).

So a datastore is a set of 'config true' data nodes stored somewhere.
Move away from configuration and there is no other concept, apart from
everything else, all the statistics, routing tables and so on.  Hence my
suggestion that I2RS will need a YANG substatement to mark out the data of
interest to I2RS, perhaps with a name attached so that there can be multiple
sets of I2RS data, to read, to write, to copy and so on as a meaningful
unit; it would probably be a mistake to call that a datastore given the more
specific meaning that that term has acquired in NETCONF, of  a unit of
configuration data.

Tom Petch

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'Andy Bierman'" <[email-masked]>; "'Thomas Nadeau'"

have
is not
the

---

From: t.petch <[email-masked]>
Date: Fri, 9 May 2014 11:16:21 +0100

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t. petch" <[email-masked]>
Cc: "Susan Hares" <[email-masked]>; "'Jeffrey Haas'" <[email-masked]>;
<[email-masked]>
Sent: Thursday, May 08, 2014 8:17 PM
> Note the distinction between a datastore and a configuration

Juergen

Thanks for the correction. I note that the YANG RFC does not draw the
distinction and that all NETCONF RPC refer to configuration datastores
so while we could use datastore unqualified to mean something different,
such as a set of I2RS data, I would rather avoid that usage.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Fri, 9 May 2014 11:13:13 +0100

---- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'t.petch'" <[email-masked]>
Cc: "'Jeffrey Haas'" <[email-masked]>; <[email-masked]>
Sent: Friday, May 09, 2014 5:52 AM
> send email clip (private/public).

I think that we are in uncharted territory.

My thanks to Juergen for correcting my terminology.  The NETCONF RFC
does define datastore as distinct from configuration datastore but then
defines all its operations in terms of configuration datastores while
the YANG RFC uses datastore without qualification but clearly means
configuration ones.  Um.

So configuration datastores
only contain 'config true' nodes and contain a complete set thereof, in
accordance with a schema tree.

<running/> is one such datastore, along with <startup/> and user-defined
ones; these can be copied in their entirety and the nature of them means
that I see it as practical for a device to lock them against any changes
during a copy - the copy is atomic, no acknowledgements needed.  The
rest of the data in the device, state, is not a datastore, cannot be
edited, cannot be copied can only be (selectively) gotten, NETCONF get
RPC, and is not <running/> because that is a term with a special
meaning, of a specific configuration datastore.  Likewise 'config' is a
term with special meaning of what goes into a configuration datastore
(so I am uncertain what is meant by config or running in the context of
I2RS).

So that is the model at the back of my mind, which I find hard to let go
of.

If I2RS wants to edit state (eg the RIB entries learnt from BGP), which
the use-cases clearly describe, then that is a new ballgame, needing, if
YANG is used, a new substatement to mark those data nodes and a new
protocol, perhaps a NETCONF extension, to write to them.  Or else we do
not use the existing data models as a base, and create new ones with
only data nodes of interest to I2RS in them in whatever language we
choose, perhaps a new protocol (quite easily done).

If I2RS wants to operate on sets of data (I would avoid the term
datastores because I still see it as a
a technical term with a special meaning in Ops Area), and I am uncertain
whether or not it should - the use cases seem silent on this - well that
is another new ballgame.  There is nothing in NETCONF or YANG to guide
us here, we would need to tag (e.g. YANG substatement) the data nodes
that form such a dataset, or datasets, and define new protocols, perhaps
extensions to NETCONF, to copy those datasets from somewhere to
somewhere.  This could be fraught on a  practical level.

My experience of routers is that the storage used for state, eg the full
BGP table, is greater than that used for (NETCONF type) config
(typically semi-permanent storage), so there might be nowhere for the
state to be copied to on the device, nowhere that survives a restart.
Likewise, in a parallel context, one trick I play is an SNMP get-next on
RMON tables - it never ends, because new entries are being added to the
tables faster than the get-next can retrieve them!  Would an attempt to
copy the full BGP table meet the same fate?  I do not know, but it is
these practical thoughts that colour my thinking which is perhaps why I
think that I2RS does not want a copy function because it would be a
challenge to implement - but I would be happy to be corrected by
manufacturers of high-end routers.

Um.

Tom Petch

> I am afraid I cannot parse this e-mail to see where the text is yours
and
> persistence except to a limited extent when it is applying validation
logic,
should
> > running config (i2rs), the system has to explicitly copy it over.
But
> until
> > That copy-to-local-config feature would be extra, outside the scope
of
> > implementations are different, this is great (differentiated
products
> =
> > good); but IMHO this feature actions has to be interoperable. that
is
> give
> > If you re-install any required I2RS config, are you sure this is
what

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 May 2014 13:17:56 +0200

> such as a set of I2RS data, I would rather avoid that usage.

All I can tell is that N/Y documents try to make a distinction between
the concept of a datastore and a configuration datastore. The word
datastore shows up 13 times in RFC 6020 and in a number of the
occurances the context is rather clear whether a configuration
datastore or a general datastore is meant I think. But yes, the YANG
RFC might not have gotton the wording right everywhere.

That said, I believe at least one widely deployed commercial
implementation supports the notion of non-configuration datastores.
But your mileage might vary.

/js

---

From: t.petch <[email-masked]>
Date: Fri, 9 May 2014 19:20:00 +0100

----- Original Message -----
From: <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "i2rs" <[email-masked]>; "'Jeffrey Haas'"
<[email-masked]>; "Susan Hares" <[email-masked]>
Sent: Friday, May 09, 2014 1:54 AM
Subject: Re: [i2rs] edit-data substatement Re: Operational State

> see:
http://www.ietf.org/mail-archive/web/netmod/current/msg09716.html
> /frank

I see.

I have speculated on something similar for I2RS, to be able to group
meaningful sets of data, into datasets, perhaps with an optional name
assuming that once we move away from the 'config true'
dataset/datastore, then the floodgates are open and we are likely to
want many such datasets.

But I disagree that YANG should get into datastores of any kind; where
this logical collection of data is copied to and from currently rests
with NETCONF and that seems right, that the copy function, not the
schema tree, specifies the two localities as part of the protocol, the
schema tree specifies what the data set is.

There are other issues, about how much sense it makes to have this set
of data.  The 'config true' dataset does make sense, it is a logical
whole, what it takes to get a box up and running, in a way that no other
dataset I can think of does. It may make sense to have an easy to read
set of data for I2RS, so perhaps a new YANG substatement for data nodes
to identify this and a get-i2rs function to go with it, but writing it
back seems fraught with potential pitfalls.  So underneath this, I
wonder if a copy function makes any sense for I2RS because there is no
meaningful set of data.

Use cases would help (have you got any?).  I have yet to see anyhing in
the current I-Ds that requires a copy function.

Tom Petch

should
> > have
> > > its own datastore -- so "i2rs-config" is appropriate because I2RS
is
But
> > > That copy-to-local-config feature would be extra, outside the
scope of
> > > or optional) does not work the same in different vendor's boxes?
If
products
is
> > > IMHO it is important to know when the write to local-config is
done
> > even if
> > > if the router happens to reboot is not that useful, and therefore
it
> > needs
> > > I can't imagine any use cases where the operator thinks "I only
need
> > to
what
> ZTE Information Security Notice: The information contained in this
mail (and any attachment transmitted herewith) is privileged and
confidential and is intended for the exclusive use of the addressee(s).
If you are not an intended recipient, any disclosure, reproduction,
distribution or other dissemination or use of the information contained
is strictly prohibited.  If you have received this mail in error, please
delete it and notify us immediately.