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

["Susan Hares" <[e-mail]>]

Jeff and others: 

To make progress, can we please comment based on the
draft-ietf-i2rs-ephemeral-09.txt.   We will be using this text for
discussion. 

The following changes have been made in that document: 

1) Ephemeral-REQ-01 has new text 
2) Ephemeral-REQ-05 was added, and sequences renumbered 
3) ephemeral-REQ-06 (old Ephemeral-REQ-05) has  new text. 
4) Ephemeral-REQ-07 and Ephemeral-REQ-08 have new text [NETCONF/RESTCONF] to
clarify based on Juergen's comments. 

On Jeff's comments, 

1) why do you think the insecure transport was covered by the yang push
document? 
2) on draft-schoenw-netmod-revised-datastores-00 
>I think converging on the concept of an conceptional operational datastore
would address many of these >considerations.  (Note that I believe you'll
want either additional filtering capabilities to select whether the
>configuration state in the operational store originates in local
configuration or ephemeral configuration.  This >was in an earlier version
of the ephemeral state requirements draft.)

Why do you think the data model as it states covers the resolution of
nexthops that I2RS RIB Data model requires?  Why does the ephemeral not have
the simple case:  Ephemeral config / Ephemeral opstate? 

Sue 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Jeffrey Haas
Sent: Tuesday, May 31, 2016 3:37 PM
To: Susan Hares; [e-mail]; 'Alia Atlas'
Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am
- Topic: Ephemeral State Requirements

[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?

> 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?)

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.

>  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?

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.

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.

>  
> > 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.)

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.

> > 5. Do you think the pub/sub requirements are sufficient? 
> > 
> >     (PUB-SUB-REQ-01, PUB-SUB-REQ-02)
>  
> I would hope that draft-ietf-i2rs-pub-sub-requirements-09 covers 
> everything that is needed. Again, this is linked to architectural 
> question. The text, for example, assumes that there is an 'operational 
> data stores'. As of today, this is not really the case. See
> draft-schoenw-netmod-revised-datastores-00 for more details.

I think converging on the concept of an conceptional operational datastore
would address many of these considerations.  (Note that I believe you'll
want either additional filtering capabilities to select whether the
configuration state in the operational store originates in local
configuration or ephemeral configuration.  This was in an earlier version of
the ephemeral state requirements draft.)

I believe the remainder of the configuration state considerations are
covered by the yang-push draft in the on-change behavior.

-- Jeff

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs