Subject: [Netconf] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Sep 2014 17:05:46 -0400

[BCC: netconf]

The netmod interim in New York City last week was a productive discussion for
I2RS, although it was frustrating in its conclusions.  (Those conclusions
mostly being, "There's mostly no work needed here, go talk to netconf!")
However, given the large overlap of WG membership between netmod and
netconf, it should hopefully make the next form of this meeting somewhat
easier to have.

Thanks to Cisco for providing the venue for the interim.

This writeup is presented to document my perception of our discussion and
provide the seed to start further discussion in i2rs.  No specific requests
are being made to netconf at this point - and to reduce accidental noise as
we try to converge on our discussion points, I have placed them in the BCC
field.  We can make more formal requests once the i2rs discussion of the
netmod interim has gotten some traction.

Juergen has placed the full netmod minutes here:
http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt

A small excerpt from those minutes:
: Conclusion: We do not need any changes for YANG 1.1 (hurray) but
: instead we need a document that introduces ephemeral datastores and
: clarifies what validation means with ephemeral datastores. In
: addition, the NETCONF WG needs to do work to define suitable
: protocol operations and RESTCONF needs to make sure it is prepared
: to support ephemeral datastores. There is also NETCONF work to be
: done to improve notification handling. The only YANG 1.1 homework is
: to make sure that the language in the YANG 1.1 specification is
: flexible enough to enable the introduction of ephemeral datastores.

Background:

The seed for the discussion at this interim was the somewhat hastily
authored document:
https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00

-----

Ephemeral state:

The I2RS portion of the discussion was kicked off by talking about the
ephemeral state that I2RS wants to have and why it is important that it is
ephemeral.  The three options from section 2.1 were presented and discussed
at length.  The points about the advantages of a separate datastore (easy
cleanup, clear segregation of state) were compared against the desire of
other non-I2RS users wanting ephemeral state.  A point that was raised early
was, "why can't we simply let the operators choose whether something is
ephemeral or not?"

This lead to a discussion regarding the nature of "priority" and what its
impact was with regard to how ephemeral state was kept.  One thing that
became apparent during this discussion is the I2RS Architecture draft is
potentially not clear enough about the distinction of I2RS state priority
vs. Local Config priority (section 6.3 of the Architecture draft) and client
priority (section 7.8); the word priority is overloaded.

Clarifying client priority vs. state priority lead further into where such
data is kept and how it is used.  Room discussion eventually went to
identity and how it was associated with priority.  An observation was made
that this information is effectively meta-state being kept on the
configuration nodes.  Such information, not being yang specific, was
suggested as a point for netconf.  It was observed that the identity may be
useful information for general users and may not be i2rs specific.  The
analogy was made to "git blame" (and other similar source-control annotation
mechanisms).

The "where is the ephemeral state kept" conversation began to converge
around a possible fourth option - one that apparently had some discussion
much earlier in the i2rs working group's life, apparently.  Here's my
attempt to describe the conclusions of that discussion:

- There is a new ephemeral datastore.
- It may be used by my many applications, including I2RS.
- It has the property that the schema of config state is "visible" in it
  from a read-only perspective.
- It has the property that writes to it may either create new state that is
  disjoint from the config data store state or it may cause changes to
  information that is/was visible from the config state.  Such changes may
  be merge, override, delete, e.g.
- This "shadowing" behavior avoids issues in the existing yang by not
  requiring additional language semantics that would require mechanisms to
  cross-reference between datastores.  (One might observe this is somewhat
  similar to Object Oriented programming where the configuration state
  serves as a "base class" with ephemeral configuration extending that
  base.  A different analogy is the union filesystem semantic.)

Issues that came up with this model under discussion:

- Validation is a problem with this design.  (And was likely even more
  complicated in the original 3 discussion points.  This was one of the
  elements that drove us to this fourth option.)
- It is possible to refer to config state from ephemeral state for
  conditions (must, when), but not vice-versa.
- We (i2rs) must decide what happens when ephemeral state has conditions
  that are invalidated by a change to the underlying config state.  In such
  a case, the config state may validate, but i2rs may not.  Does the
  operation succeed or fail?
- Such constraints and their validation impact may negatively impact the
  desired speed properties of i2rs.  However, it was also observed this is
  only the case when such references exist and that "fast" i2rs operations
  could simply be modeled with no dependencies on config state.

- Ephemeral state priority vs. Local Config priority is difficult to fully
  support in such a model.  In the above discussion, ephemeral state always
  has priority over Local Config.  
- Providing for Local Config to have lower priority may be possible, but
  introduces some unusual semantics.
- Does I2RS have clear use cases for Local Config winning?  The example of
  "configuration of last resort" was offered but is potentially a weak case.

In summary, the fourth option was strongly driven by the arguments of "what
keeps things simple".  The original three options were apparently not simple
enough and there's some doubt about the impacts of the fourth.

Possible yang 1.1 implications:  If the above model works, the discussed
configuration semantic may be the previously discussed
"config (false|true|ephemeral);"

------

Mutual authentication was also discussed.  As noted on list conversation
after draft-haas-* was published, while restconf doesn't currently require
it, it is suspected that it will have such a requirement before working
through IESG.

I suggest that I2RS requirements are addressed for this point.

-----

Identity requirements for the primary identity are covered by authentication
requirements for the existing protocols.  The "secondary identity"
requirement is a netconf issues and we should talk to them about the
implications.  Since the primary requirement for this feature is for
auditing, this may simply be meta-data that is kept on configuration state.
(See commentary above.)

It is noted, however, that introducing something like a secondary identity
would require changes to SSH and/or TLS and may be somewhat difficult to
make the case to the owning working groups.

Per-client priority effectively becomes the ability to say "you can't write
to this if the state exists and has an owner with a higher priority".
Further discussion on this point is needed in light of the fourth option we
were presented.

------

Persistance of subscriptions.  Effectively we were told "go talk to netconf,
it's out of scope for yang 1.1".

Some discussion was given to the filtering considerations.  Extending the
filtering options of the ietf-inet-types module may be appropriate.
[Juergen, is this an action item for yang 1.1?]

-----

Hopefully this is clear enough to kick off discussion.

-- Jeff

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 23 Sep 2014 09:50:38 +0200

[bcc to i2rs and netmod];

I propose to discuss the netconf aspects of this on the netconf mailing list.
However, for i2rs "consensus" on the specific netconf requirements, I think
it MUSR be dealth with on i2rs list.

Thanks Jeff, this is good for netconf participants to be aware of.

And to discuss/comment on.

Bert

On 22/09/14 23:05, Jeffrey Haas wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>