Re: [i2rs] Operational State

[Andy Bierman]

On Thu, May 1, 2014 at 10:57 AM, Jeffrey Haas <jh...@pfrc.org> wrote:

> Andy,
>
> On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote:
> > This has been done a few times.
> > Most recently April 22:
> > 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".
>

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
> routes to the rib.
>


How many does I2RS need for itself?



>
> (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
> > was also standardized.
>
> 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
>

Andy

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs