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

[Andy Bierman <[e-mail]>]

On Wed, Jun 1, 2016 at 2:10 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> 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.
>
>
This REQ-05 doesn't give any reason why data nodes need to be tagged as
ephemeral
in the schema tree, or what it means to be tagged as ephemeral.

My intention for suggesting an "i2rs:ephemeral" YANG extension was to
identify
the I2RS conformance requirements for a server claiming to implement I2RS
for a specific YANG module.

A node tagged as ephemeral MUST be accessible in the ephemeral datastore
using I2RS if the module (or feature) is supported. An untagged node MAY be
accessible.

An I2RS data model could define read-only nodes.  These nodes could
be considered ephemeral operational state.  Should these nodes live in
this datastore or an "operational" datastore?  I don't know.
That's why we probably need your draft.



Andy



> > > 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/>
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>