Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements

[Juergen Schoenwaelder <[e-mail]>]

On Tue, May 31, 2016 at 03:36:40PM -0400, Jeffrey Haas wrote:
> [Note that I'm answering messages in thread order to the originator of a
> point rather than necessarily to responses.  This is intentional.]
> 
> On Tue, May 31, 2016 at 08:38:42AM +0200, Juergen Schoenwaelder wrote:
> > I read:
> > 
> >    Ephemeral-REQ-05: The ability to augment an object with appropriate
> >    YANG structures that have the property of being ephemeral.  An object
> >    defined as Yang module, schema tree, a schema node, submodule or
> >    components of a submodule (derived types, groupings, data node, RPCs,
> >    actions, and notifications".
> > 
> > I have trouble to parse this since the 1st sentence does not seem to
> > make sense for each element that you consider an object. That said,
> > the real issue here are lifetimes. The lifetime of a config true
> > object is determined by config changes, the lifetime of config false
> > objects is determined by operational state changes. What happens to
> > an ephemeral augmentation of objects if their lifetime expires?
> 
> I agree that your observation covers the general intent.  The requirements
> language above is attempting to be a bit too specific for a given
> implementation detail, namely instantiation of ephemeral behaviors in a data
> tree.
> 
> Could you please supply alternative text?

It is difficult since I am not sure what the original intention
was. There is augmentation at the schema tree level and then there is
augmentation at the data tree level. My understanding (which may be
wrong) is that I2RS primarily looks at data tree level augmentations
of operational state data and not so much at configuration datastore
data. Part of the openconfig inspired discussion is to do away with
the /foo and /foo-state division and that has an impact how the schema
trees are constructed.

> > The revised datastore model I have described in
> > draft-schoenw-netmod-revised-datastores-00 links the ephemeral state
> > only to operational state, not at all to configuration. Does this
> > model not satisfy the I2RS requirements and make things much simpler?
> 
> I've been unable to follow netmod/netconf recently, so thanks for pointing
> out this document.  It does seem to do a nice job in attempting to summarize
> a number of discussions on the various datastore concepts we've been seeing
> the last year.
> 
> There are a few things I find slightly problematic in your hierarchy with
> respect to what I2RS likely needs for ephemeral configuration state, but I
> think it might be solvable.  Here are some observations:
> 
> If ephemeral configuration state were to be treated as a datastore that
> feeds into running, would you expect that the resulting running state should
> be writable?  (I.e. running = candidate, startup + ephemeral?)

I doubt ephemeral feeds into the <running> datastore since running can be
expected to be persistent. draft-schoenw-netmod-revised-datastores-00.txt
actually suggests ephemeral interacts with <operational-state>. The
alternative view I mentioned is that a magic merge (+) takes <applied>
and <ephermeral> as input that feeds into <operational-state>. This is
likely closer to the 'pane of glass' model. The revised datastore model
kind of puts the magic merge function (+) into the operational datastore
itself, essentially treating I2RS ephemeral datastores like any other
control plane interface. (This still allowes a 'paned' implementation
within the <operational-state> but it does not require this.)

Note that draft-schoenw-netmod-revised-datastores-00 came out of a
meeting I had with Martin in Stockholm and there have been a couple of
calls where people where trying to figure out ways to deal with the
openconfig ideas. There is no WG agreement on any of this, its all
just input to discussion.

> It would be helpful to see how an ephemeral datastore is intended to
> interact in this diagram.  A detail that would need to be clarified is what
> happens when there is overlaps in portions of the schemas.

One of the driving forces were attempts to overcome the /foo and
/foo-state distinction we started to make in data models. This might
actually make ephemeral data model extensions easier.

> >  2.  Does Ephemeral-REQ-06 provide the Yang requirements in 
> > > a clear fashion?  Do you have any suggestions for alternative text? 
> > 
> > I think it is clear but broken. In particular the part about
> > indicating secure/non-secure transport.
> 
> The text relating to transport is applied to generally and needs clarifying.
> Let's provide a specific goal:
> 
> For Yang notifications, there may be some desire for the information to be
> sent across alternative transports, potentially with specific encodings.
> draft-ietf-netconf-yang-push covers I2RS use cases wherein the data may be
> sent via alternative transports.  Should we have some sort of markup in the
> Yang language to identify what transports might be utilized?  What about
> security requirements?

The choice of transports and in particular the question whether a
non-secure transport is acceptable is for me primarily a deployment
question and not a data modeling question.

> Obviously we can spell out transport security considerations as part of the
> description clause within a notification.  However, since a significant
> amount of feedback has been given from individuals with a security
> background that many objects we're likely to use in I2RS may be security
> sensitive - but not all! - some way to indicate the sensitivity may be
> required.

It is actually difficult for me to imagine objects that are in all
usage contexts never security sensitive.

> The motivation for this is that for insecure and high speed transports and
> ecodings such as IPFIX (e.g.) it may be fine to expose some data (e.g.
> interface statistics) but the same may not be true for other data and a
> secured transport may be required.

Whether an interface is used or not can be sensitive information. In a
certain deployment, it may still be OK to use an unsecure transport
because the path between the IPFIX exporter and collector is believed
to be reasonably protected. But that is a deployment question, not a
data modeling question.

> > > 3. Do you think any of the Ephemeral-REQ-07 NETCONF Changes 
> > >    are not necessary?   If so, what changes would you leave out?
> > >    Do the "policy-knobs" seem useful to you? 
> > >
> > > 4. Do you think any of the Ephemeral-REQ-08 RESTCONF changes 
> > >    are not necessary?  If so, what changes would you leave out? 
> > >    Do we need all the features (yang module library, call-home, 
> > >    server)? 
> > 
> > I think this needs to be trimmed down. I think it should be avoided to
> > create I2RS specific solutions for things that are already in place
> > (e.g., NETCONF has a mechanism for protocol capability discovery and
> > negotiation, NETCONF already supports multiple (secure) transports).
> > 
> > I think that having a clear architectural view is essential. I am not
> > sure the 'single pane of glass' model is the way to go. I think the
> > decision on the architectural model is key because it impacts many of
> > the other requirements and solutions.
> > 
> > You want both NC and RC to support XML and JSON and SSH and TLS and
> > (plaintext) TCP? Does this maximum of variability and flexibility
> > really help interoperability? Perhaps things should be reorganized
> > into things that are protocol agnostic (and should not be repeated)
> > and things that are protocol specific - if there is indeed a need to
> > work with multiple protocols.
> 
> I agree we're being overly specific here, although as noted above we need
> some discussion about what to do about insecure transports for some
> operations, such as subscriptions.  (I think that's covered by the 
> yang-push doc in particular.)

So lets leave it there and lets not repeat it.

> Item 6 about precedence of local configuration vs. ephemeral configuration
> requires discussion, including in the revised-datastore document if it
> chooses to address ephemeral configuration.
> 
> > I also think that it is not needed to write down requirements to
> > NETCONF for things that are already solved or being worked on.
> 
> I think we're happy to subtract these, or at the least call out the existing
> work in progress.  As noted in some earlier drafts, the goal of the I2RS
> drafts should be to not have drafts in I2RS, but solution space documents in
> netconf and netmod.

Yes!

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>