Subject: [i2rs] some thoughts on draft-tp-i2rs-yang-00

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Jul 2014 18:00:08 -0400

Hi Tom,

First, thanks for writing this draft.  I found the summary of what NetConf
and YANG do to be useful - despite having read through many of the relevant
RFCs.
I think it is also pulling out lots of the questions about what does using
NetConf/RestConf and YANG mean; some of been touched on in various email
threads also, of course.

For the discussion of the meaning of terms like configuration state and
operational state,  I come at this from the perspective of implementing a
protocol - and there, I am used to configuration state being data that is
passed to the process from the netmgmt system.  There's learned state from
elsewhere in the network.   There are statistics or measured state.
 There's physical state (say of an interface).  There can be operational
state - which is sometimes derived from a combination of what was
configured and what the physical state is.  The easiest example is probably
an interface state - which can be admin-down, oper-down, or oper-up.

Personally, I am now much more aware of the use of configuration state and
operational state from the network management perspective - but find that
they are in conflict and inadequately descriptive for the protocol/process
perspective.

In Section 5, it says

"It seems likely, to the author, that this logic does not apply to
I2RS operations on operational state, that is the set of data that
I2RS may want to edit will be a subset of the data that is of interest
to I2RS; read-only statistics, for example, will not be in the former
but will be in the latter. From this it follows that while a single,
boolean substatement may be sufficient, and that anything else can be
achieved with filters, it would much simpler and less error-prone for
I2RS to have a further substatement that defines the set of data that
is of interest to I2RS so that such data can be readily retrieved by
an additional NETCONF RPC, get-i2rs perhaps (NETCONF, like YANG, is
extensible).

Such substatements would, like config, apply to all nodes in the
subtree unless overridden.  By analogy with the config substatement,
it would seem likely that an 'edit-data true' node should not appear
under an 'edit-data false' node (although quite why is not clear to
the author)."

I quite agree that the set of data that I2RS will want to edit will be
a subset of the data that is of interest to I2RS.  Rather than trying
for a subtree approach where the editable aspect applies to the whole
subtree, I'd pictured more of a read/write/modify attribute so that
logically grouped information doesn't have to be repeated or separated
in the models.

I don't see the same need to pull i2rs state in the same way that
config state is acquired.

In Sec 6, the draft asks:

"Will I2RS, having made changes to the operational state of a box,
want to copy those changes to somewhere else, perhaps so that they can
be re-applied at a later time, such as after a reboot, or is the
underlying assumption of I2RS that such changes should be lost at a
reboot?  Will such a copy be required as an audit trail, a check on
what actually happened, given that the changes that I2RS make are
likely to be of higher risk to the integrity of the routing system
than those made via configuration and NETCONF?"

My personal opinion for the first question is no - that the changes
made via I2RS are coming from network-oriented applications which will
reimpose the appropriate operations after a reboot or when necessary.

For an audit trail or a check on what actually happened, I can see
wanting to know which client asked for what operation at what time.  I
think of this as an event flow that an auditor/troubleshooting system
could listen to.  I can also see it being provided via syslog; I
suspect that Wes George and Joe Clarke problably have more refined
opinions on how to do this, but I don't see it coming from reading the
compressed set of most recent changes done.

In Sec 6, the draft asks:
"Will I2RS also want to create a set of changes on the box, like a
candidate configuration datastore, so that they can be reviewed,
validity checked by YANG logical statements, before they are applied?"

I'd be interested in others thoughts, but I really don't think so.

Regards,
Alia