Subject: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model

From: t.petch <[email-masked]>
Date: Thu, 1 May 2014 10:17:35 +0100

Going in a slightly different direction with a change subject line.

Tom Petch

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, May 01, 2014 1:24 AM
> On Thu, Apr 24, 2014 at 01:12:44PM +0200, Martin Bjorklund wrote:
> > > http://www.ietf.org/id/draft-ietf-netmod-routing-cfg-13.txt
> > >
> > > Figure 1 and Figure 2 show.  What YANG does not have is a way of
> > > correlating the two trees
> >
> > See also Lada's reply.
> >
> > What kind of correlation are you looking for?  The point is that
these
> > are *different* structures, with different semantics.  If an entry
> > exists in the operational state, it doesn't imply there is a
> > corresponding entry in the config, and vice versa.  And just b/c a
> > config entry also exists in operational state doesn't mean that it
is
> > *exactly* as configured; some other dynamic mechanism might have
> > changed it.  It all depends on what you model.
>
> As I try to work through my reading of netconf and yang, the use case
we're
> discussing here is the one that troubles me the most.  Let me pick two
> specific examples of injecting i2rs state on top of something that may
have
> coverage within existing yang configuration models: static routes and
BGP.

Jeff

If I2RS updates the routing table, do we expect it to persist for any
length of time?  That is, the routing table is stable, the result of the
convergence of the routing protocols (and configuration) across the
relevant routers in the routing system and is reflected in the
operational state of a router.

A stable system in engineering is one that when perturbs, returns to its
original state.  So make a change in one router and I would expect the
rest of the system to gang up on that router and reinstate the status
quo.  For example, what I have in Adj-RIB-Out comes from someone else
via Adj-RIB-In and if I change Adj-RIB-Out, then sooner or later I will
refresh it from Adj-RIB-In and be back where I started, while if I
change Adj-RIB-In, then the other router will repeat its advertisement -
and I will be back where I started.

If I think of the changes I might want to make, it seems to me that they
have to be changes to what NETCONF/YANG refer to as config and not to
the operational state.  Ephemeral or persistent, which I take to refer
to what happens after a reboot, is then a question of which NETCONF
datastore I update, running or startup or both.

Tom Petch

>
> It would be very convenient for purposes of configuring static routes
in
> i2rs where the semantic is ephemeral configuration to not have to
duplicate
> the existing yang model.  If the model in question was design to use
> groupings, it appears that it would be easy to have one instance for
normal
> configuration and a second one specifically for i2rs.  It would be
even more
> convenient if we had a semantic that was not only "config true", but
> potentially "config true|ephemeral".
>
> The issues then comes back to the ones noted in
> draft-bjorklund-netmod-operational-00: How do we distinguish
operational,
> config or ephemeral config states?  When there are different
precedences
> (ephemeral overrides static, e.g.), how could you do a get that
presents the
> implemented order?
>
> The BGP example to my mind may only go slightly further than this.
For
> some types of i2rs configuration state, I can foresee wanting some
portion
> of it to be based upon non-ephemeral configuration - for example base
BGP
> state that should not be modified by i2rs.  Presuming that base state
> exists, it may be desirable to permit something like BGP peer
configuration
> to re-use the existing BGP yang model for configuration, just in an
> ephemeral context.  Thus, some portions of the configuration are
> instantiated ephemerally and some require underlying non-i2rs config.
>
> > I don't think a separate structure for i2rs routes are needed, b/c
it
> > is supposed to directly modify the operational state.
>
> This is where I think we're getting stuck.  There is some vagueness
between
> operational state that can be modified and ephemeral configuration.
But the
> real issue is when multiple forms exist, how do we operate upon it/see
it in
> a useful fashion?
> -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 May 2014 10:57:48 -0400

On Thu, May 01, 2014 at 07:38:39AM +0200, Juergen Schoenwaelder wrote:
> On Wed, Apr 30, 2014 at 08:24:51PM -0400, Jeffrey Haas wrote:
> > 
> > This is where I think we're getting stuck.  There is some vagueness between
> Are you saying there is a difference between 'writable operational
> state' and 'ephemeral configuration' but the difference is still
> unclear and hence vague?

Yes and no.  I'm still absorbing appropriate terminology from the N/Y RFCs
so please have patience with me.

State that I2RS injects into a system may be intended to be ephemeral.
That state may overlap with state that is otherwise configured in the usual
configuration based datastore.  E.g. static routes.

It is clearly possible to generate yang for I2RS that duplicates as much of
the yang for that configured state (e.g. static routes).  Yang provides
mechanisms to allow for re-use of the yang inputs (e.g. grouping) in another
module, provided that the original module was authored to enable re-use.

My observation is that in cases where there may be significant overlap of
I2RS injected ephemeral state, e.g. static routes, that it might be
desirable to not have to have a separate I2RS yang module unless there are
differences that necessitate a new module.  Effective, if I have my
terminology correct, to permit more than one datastore to be manipulated
using the same module.  I.e. "running configuration" and "I2RS ephemeral".

If such a thing were possible, then it would only compound the issues noted
in draft-bjorklund-netmod-operational since the configuration state for the
overlapping datastores also had related potentialy overlap in the
operational state.

To offer an older analogy for comparison, if I can configure static routes
via CLI and simultaneously by SNMP and both configurations can serve as
inputs to the RIB, the installed static route may come from either of the
candidates and the active entry will be selected by a preference.

In such a scenario, I still need to be able to see my configuration for the
CLI route and the SNMP installed route along with the actual route installed
in the RIB as active.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 May 2014 22:43:57 +0200

> CLI route and the SNMP installed route along with the actual route installed

All fine but the question was whether you see a difference between
'writable operational state' and 'ephemeral configuration'.

You are concerned about YANG module organization, how to maintain
generic reusable parts and stuff that is config or i2rs specific. And
yes, this requires careful engineering and we will not always get it
right (and in particular in the IETF this might happen since WGs run
at different pace). But on the other hand, if I2RS chooses a different
technology, there will likely be no reuse at all (and we could only
hope to at least have consistent underlying information models).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 16 May 2014 20:47:10 +0000

> datastore I update, running or startup or both.

Tom,

Good question, but IMO, I2RS agent should not change tables belonging to dynamic routing protocols. Changes done by I2RS agent should have only device impact, not network impact. If there is desire to change across network, then each I2RS agent on each device should be updated.

Dynamic protocol routing tables should be read only. I2RS agent should create routing tables that can contain the same prefix as in the table belonging to dynamic protocol, so creating custom routing preference is possible. If we really want to allow full manipulation of dynamic protocol routing tables, I think some extensions to routing protocols would be required.

Dean

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 16 May 2014 15:00:07 -0700

Dean, see inline

On Fri, May 16, 2014 at 1:47 PM, Dean Bogdanovic <[email-masked]> wrote:

> Good question, but IMO, I2RS agent should not change tables belonging to
> dynamic routing protocols.

Yes, the I2RS agent should not provide an interface to change a table if
there is no use-case to support it. A dynamic routing protocol's
route-table (e.g. IGP's route-table that it downloads to RIB) has no
use-case to change it by another client. A read-only interface should be
sufficient.

> Changes done by I2RS agent should have only device impact, not network
> impact. If there is desire to change across network, then each I2RS agent
> on each device should be updated.
>

It is not simple to classify a change to a device as having an impact
scoped to just that device. E.g a route that is added to a device with a
different preference can have network-wide traffic impact.

>
> Dynamic protocol routing tables should be read only. I2RS agent should
> create routing tables that can contain the same prefix as in the table
> belonging to dynamic protocol, so creating custom routing preference is
> possible.

The RIB is the table where multiple clients (including multiple dynamic
routing protocols) can create routes in order for it to be downloaded to
the FIB. 'Preference' must be used to add multiple routes for the same
prefix. The clients of the RIB can be dynamic routing protocols or clients
that implement other use-cases. The RIB IM is designed to interface with
all such clients.

> If we really want to allow full manipulation of dynamic protocol routing
> tables, I think some extensions to routing protocols would be required.
>

I am yet to see a use-case that requires direct manipulation of a single
dynamic routing-protocol-instance specific route table by something other
than that protocol. I don't believe there should be any such case.

Sri

>
> Dean
>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 20 May 2014 15:06:34 +0000

Sri,

See inline

On May 16, 2014, at 6:00 PM, Sriganesh Kini <[email-masked]<mailto:[email-masked]>>
 wrote:

Dean, see inline

Changes done by I2RS agent should have only device impact, not network impact. If there is desire to change across network, then each I2RS agent on each device should be updated.

It is not simple to classify a change to a device as having an impact scoped to just that device. E.g a route that is added to a device with a different preference can have network-wide traffic impact.

How can I explain this better. The static route on device will be routed to the next destination, but at the next destination the dynamic protocol will take effect, unless, another static route directs the traffic differently. Makes sense?

Dynamic protocol routing tables should be read only. I2RS agent should create routing tables that can contain the same prefix as in the table belonging to dynamic protocol, so creating custom routing preference is possible.

The RIB is the table where multiple clients (including multiple dynamic routing protocols) can create routes in order for it to be downloaded to the FIB. 'Preference' must be used to add multiple routes for the same prefix. The clients of the RIB can be dynamic routing protocols or clients that implement other use-cases. The RIB IM is designed to interface with all such clients.

thank you for correcting me.

If we really want to allow full manipulation of dynamic protocol routing tables, I think some extensions to routing protocols would be required.

I am yet to see a use-case that requires direct manipulation of a single dynamic routing-protocol-instance specific route table by something other than that protocol. I don't believe there should be any such case.

I completely agree with you.

Sri

Dean

_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 20 May 2014 09:23:13 -0700

On Tue, May 20, 2014 at 8:06 AM, Dean Bogdanovic <[email-masked]> wrote:

>  How can I explain this better. The static route on device will be routed
> to the next destination, but at the next destination the dynamic protocol
> will take effect, unless, another static route directs the traffic
> differently. Makes sense?

I think what you really wanted to say is - An I2RS agent must not interface
with an I2RS agent on another network element. If an I2RS client requires
to interface with I2RS agents on multiple network elements, it must do so
itself without putting requirements on the I2RS agent on one network
element to interface with the I2RS agent on another network element.

Sri