On Thu, May 1, 2014 at 8:23 AM, Jeffrey Haas <[email protected]> wrote:
> Andy,
>
> On Thu, May 01, 2014 at 08:02:17AM -0700, Andy Bierman wrote:
> > 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.
>
> 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.
>
> > 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.
>
> 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.
>
>
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.
> 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.
>
> 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?
>
>
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
