----- Original Message -----
From: "Jeffrey Haas" <[email protected]>
To: "t.petch" <[email protected]>
Cc: "Jeffrey Haas" <[email protected]>; <[email protected]>
Sent: Tuesday, June 10, 2014 7:07 PM
Tom,
[retaining lots of content for context]
now elided as it is not so much about references to extracts of the
architecture I-D
On Tue, Jun 10, 2014 at 04:25:53PM +0100, t.petch wrote:
---- Original Message -----
From: "Jeffrey Haas" <[email protected]>
To: "t.petch" <[email protected]>
Cc: "Jeffrey Haas" <[email protected]>; <[email protected]>
Sent: Tuesday, June 10, 2014 2:41 PM
Tom,
<snip>
This is much of what I had suggested about the semantics of
introducing
ephemeral config into netconf. Our requirement is that these things
are
ephemeral. (Although Tom Nadeau presents some nice cases as to why we
may
want the equivalent of "write running-config" to permit persistence.)
At this point, overlapping ephemeral configuration isn't something
that
netconf supports. If you scan mail from the last month or so, you'll
also
see some back and forth between Juergen and Andy and I about how we go
about
representing such a thing in the yang model/modules. (And we never
fully
converged.)
From the config perspective, this ephemeral state wasn't something
that I
believe was part of the config semantics of netconf/yang; it's an I2RS
requirement. Admittedly, once we have such a think then clearly
applications other than I2RS can make use of it. :-)
Choosing a solution space will be the next challenge we have:
- Overlapping modules with i2rs context?
- Parallel modules?
- How to ensure maximum re-use of the yang modules for config in an
i2rs
context if they are determined to have heavy overlap?
Jeff
Yes, I saw the thread - I think I started it and ended it!
Leaving aside the question of just what objects I2RS wants to edit that
NETCONF cannot (perhaps none:-), the rest of that thread seems clear to
me.
The architecture I-D talks of data store which I think unclear; I think
that it should be datastore, as used in Ops Area (e.g. by NETCONF).
The view that has evolved, and is reflected in the thread, is that
NETCONF 'config true' is not really the configuration. The real
configuration is the operational state, part learnt from protocols and
hardware and part derived from 'config true'; but 'config true' is only
what the operator would like to happen, the operational state is the
reality.
Currently we only have 'config true' written by NETCONF in a
configuration datastore (with operational state not being part of any
datastore, just part of state, using that term in the Ops Area sense).
What I2RS then adds is an I2RS datastore, may be one, may be several,
which is another expression of hope as to what the box will do;
operational state, as ever, tells us what actually happens. The rules
of persistence for I2RS are whatever I2RS wants them to be with no
impact on NETCONF.
So I suggest that it is wrong, as I and others have said in the past, to
talk of editing operational state; the writing of the basic NETMOD
models have shown that that does not work. The model that has evolved
is what I call twin trees, one of 'config true' - an aspiration of the
operator - and the other of 'config false' - operational state, the
reality. You can see signs of this in the NETMOD models of
interfaces-cfg, routing-cfg, system-cfg and so on.
I2RS then adds a third tree to the model, of what it would like the box
to do. I2RS would also need to specify how to resolve conflicts between
NETCONF and I2RS should they specify different values for the same
object. This is already an issue, IMO not fully resolved, when the user
and the system have different views of what should happen - look for
user-controlled and system-controlled in interfaces-cfg.
So one module, three trees, an additional YANG substatement for a leaf
that is writable by I2RS.
Tom Petch
6.4.2" o writing policy information such as interface attributes
that
are
specific to the routing protocol or BGP policy that may
indirectly
manipulate attributes of routes carried in BGP.
o writing routes or prefixes to be advertised via the protocol"
I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but
the
I-D goes on to say
" direct modification of the link-state database MUST NOT be
allowed"
(which I have seen on the list w.r.t. the BGP RIB).
or
8" The interaction of state installed via the I2RS and via a
router's
configuration needs to be clearly defined."
which again implies that I2RS and C/N/S are writing to the same
data.
*Maybe.*
In some cases, the overlap with config state will be quite obvious and
your
observation will strongly hold.
In other cases, I think a better perspective is that I2RS injected
state is
effectively like that of another routing protocol.
If you'd like to argue that BGP is effectively the same as C/N/S...
well, if
we're talking Flowspec I might agree. :-)
The examples of data that can be changed are few, such as
"For example, the interaction with OSPF might include modifying the
local routing element's link metrics, announcing a
locally-attached
prefix, .."
which leaves me wondering, do you expect an OSPF YANG model to be
unable
to change a link metric:-)
Sure. In a highly dynamic fashion? With a fallback to a default
config when
the application is done?
By comparison to some vendor specific features, it's somewhat the
difference
between a policy database (config) and the dynamic policy API that
doesn't
require a system reconfiguration event. If you want to point out that
the
relationship is strong and that the defining differences are shallow -
you
could very well be right in those contexts.
Again, we don't expect I2RS work to supplant netconf/yang. We expect
to
leverage the work.
If I2RS were aiming at a higher level, say specifying policy and
have
the system translate that into actual config changes I would
understand
that, but I do not see I2RS going that far, rather when I2RS says
policy, I think it means changing a community (config again) or some
such ie more of an implementation detail than a high level strategy.
I hesitate to frame it this way, but one example application is a form
of
SDN. The front end says "provision this VPN" to a data model for that
purpose. The fact that it may go behind the covers via client->agent
and
eventually install ephemeral netconf state is an implementation
detail.
If you want to argue that such a higher level model is simply netconf,
then
perhaps we should de-charter and do all of the work in that group. I
was,
however, under the impression that work for various models was being
pushed
to be done in appropriate working groups. :-)
-- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
