Subject: Re: [i2rs] Why do we need a datastore?

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Oct 2014 13:39:54 +0000

Hi Alia,

today networking devices can be managed in three ways:

1. CLI - is the UI we all know and use it quite heavily. In order for the device to boot in a known state a set of CLI commands have to be saved somewhere on the device. For that you have a data store. That data store can be a flat file or a database. The datastore is then read by network device daemons which change their state based on it.

Before the APIs were exposed, TCL/Expect and Perl ruled the automation world and everything was based on screen scraping. In order to make machine to machine communication easier, NETCONF was created as a standard protocol to communicate with the devices.

2. via APIs - there are several type of APIs, but most widely available ones are providing functionalities same as CLI. The difference is that CLI is human intended and APIs are machine intended. One of the example is Junos XML APIs, where (almost) each CLI command is represented by XML API. It still requires knowing how to configure device via CLI and the result of the application written with such APIs is stored in the data store from which daemon read how to change their state. 
There are some vendors that provide APIs that allow communication with daemons directly, bypassing management infrastructure, but those are highly proprietary mechanisms.
The APIs that were released by vendors, were not standardized and each vendor had different configuration models, so although communication with devices was standardized, there was no easy way to communicate semantics, which led to YANG, as standard language that all vendors would understand and now standardizing configuration and operational model, so same configuration statement can be sent to all supporting devices and be done (instead of writing same desired functionality in several configuration statements) 

At the end it really doesn't matter how you are communicating with the devices, it really boils down to that you want the device to boot into a known state. This was done by having a local data store that was containing set of instructions what state the device should be after reading it.

It really doesn't matter which mechanism is used (from above 2), configuration data has to be provided. Historically, data was on the device, as the connection between device and the network management was slow. Today (like in MSDC), devices don't have local configuration, those devices when boot look for provisioning system and get configuration from a remote location and then change the state of the device based on it. This has led that

3. some vendors use Linux, allow management via pseudo file system (/proc)

where the state of the device is changed directly without having a need for data store on the device. You have to keep in mind that only Linux allows changing the state of non-processes data through /proc. *BSD flavors don't allow that.

So today, most network operators (by this I mean any entity that operates a network, either enterprise or carrier), need to simplify network management, make it more efficient and that devices will behave very predictably, so that network is in a known state. Because of the legacy, this is easiest done by having a local datastore on a device, through which the state of the device is changed.

Hope this helps

Dean

On Oct 1, 2014, at 12:25 AM, Alia Atlas <[email-masked]> wrote:

> Hi,
> 
> I'd like to really understand why I2RS needs a datastore and what that actually means.
> In my initial conception of what an I2RS agent would do for, say, writing a route in the RIB
> model, is that  the I2RS agent would simply parse a received request from a standard format 
> and model into the internal and pass that to a RIB Manager - just as an OSPF implementation 
> might install a route to the RIB manager.  An I2RS agent could also query the RIB Manager to 
> read routes and there'd be events coming out.
> 
> With the introduction of priorities to handle multi-headed writers and collision errors, the I2RS agent would need to store what was written by which client.
> 
> What benefits and rationale does a YANG datastore add?  Why does using one need to be
> standardized?
> 
> I apologize if this seems a naive question, but it's been quite a while since I read up on YANG and NetConf/RestConf.  
> 
> Regards,
> no-hats  Alia
> 
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Alia Atlas <[email-masked]>
Date: Wed, 1 Oct 2014 09:54:12 -0400

Hi Dean,

Thanks for the explanation.  It matches with what I understand for
configuration.
Where I am confused is why I2RS - which is doing ephemeral only and matches
closer to the direct proprietary APIs directly to
the routing processes - is being tied up in this.

Regards,
Alia

On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic <[email-masked]> wrote:

> 1. CLI - is the UI we all know and use it quite heavily. In order for the
> device to boot in a known state a set of CLI commands have to be saved
> somewhere on the device. For that you have a data store. That data store
> can be a flat file or a database. The datastore is then read by network
> device daemons which change their state based on it.
>
> Before the APIs were exposed, TCL/Expect and Perl ruled the automation
> world and everything was based on screen scraping. In order to make machine
> to machine communication easier, NETCONF was created as a standard protocol
> to communicate with the devices.
>
> 2. via APIs - there are several type of APIs, but most widely available
> ones are providing functionalities same as CLI. The difference is that CLI
> is human intended and APIs are machine intended. One of the example is
> Junos XML APIs, where (almost) each CLI command is represented by XML API.
> It still requires knowing how to configure device via CLI and the result of
> the application written with such APIs is stored in the data store from
> which daemon read how to change their state.
> There are some vendors that provide APIs that allow communication with
> daemons directly, bypassing management infrastructure, but those are highly
> proprietary mechanisms.
> The APIs that were released by vendors, were not standardized and each
> vendor had different configuration models, so although communication with
> devices was standardized, there was no easy way to communicate semantics,
> which led to YANG, as standard language that all vendors would understand
> and now standardizing configuration and operational model, so same
> configuration statement can be sent to all supporting devices and be done
> (instead of writing same desired functionality in several configuration
> statements)
>
> At the end it really doesn't matter how you are communicating with the
> devices, it really boils down to that you want the device to boot into a
> known state. This was done by having a local data store that was containing
> set of instructions what state the device should be after reading it.
>
> It really doesn't matter which mechanism is used (from above 2),
> configuration data has to be provided. Historically, data was on the
> device, as the connection between device and the network management was
> slow. Today (like in MSDC), devices don't have local configuration, those
> devices when boot look for provisioning system and get configuration from a
> remote location and then change the state of the device based on it. This
> has led that
>
> where the state of the device is changed directly without having a need
> for data store on the device. You have to keep in mind that only Linux
> allows changing the state of non-processes data through /proc. *BSD flavors
> don't allow that.
>
> So today, most network operators (by this I mean any entity that operates
> a network, either enterprise or carrier), need to simplify network
> management, make it more efficient and that devices will behave very
> predictably, so that network is in a known state. Because of the legacy,
> this is easiest done by having a local datastore on a device, through which
> the state of the device is changed.
>
> Hope this helps
>
> Dean
>
>
> > With the introduction of priorities to handle multi-headed writers and
> collision errors, the I2RS agent would need to store what was written by
> which client.
> >
> > I apologize if this seems a naive question, but it's been quite a while
> since I read up on YANG and NetConf/RestConf.
> >
> > Regards,
> > no-hats  Alia
> >

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Oct 2014 14:12:59 +0000

On Oct 1, 2014, at 9:54 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Dean,

Thanks for the explanation.  It matches with what I understand for configuration.
Where I am confused is why I2RS - which is doing ephemeral only and matches closer to the direct proprietary APIs directly to
the routing processes - is being tied up in this.

Today there is no standard protocol to expose writing to the daemons directly, except through a datastore. If you would compare routing daemon in Junos and routing daemon in IOS or NX-OS, the data models are very different. You need a standard API to communicate to all of them.

Here is a reason why a local datastore comes handy

routing daemon crashes and the state is gone. The routing state has to be reinstated.

1. replay config data from the local data store(s) and reactivate the configuration
2. replay config data from the local data store (single data store) and request all I2RS clients to replay their data again

Now if some I2RS client, during the crash, tried to execute routing changes, with local store, those can be executed and put into wait state until daemon recovers. I2RS clients can be informed that their changes are pending.

Both approaches have pluses and minuses.

Another issue is  with config statements. If you go directly to the daemons, only few very basic things can be exposed (like interfaces, routes, stateless fw filters). If you want to expose more complex statements like L3VPN, then you have to create a logic that will communicate to multiple daemons to create such state on the device. You are doubling such logic on the device.

I want to allow network administrators to decide by them self what is exposed through I2RS, not us (vendors, SDOs).

Dean

Regards,
Alia

On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Hope this helps

Dean

On Oct 1, 2014, at 12:25 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Oct 2014 10:13:50 -0400

> the routing processes - is being tied up in this.

The annoying fact is that we have to reconcile what we want to do with the
semantics of existing netconf/yang.

The property of being able to override some bit of local config with
ephemeral config implies at least another data store in those semantics.
Otherwise you'd have to redefine the existing semantic as "a given writer
may SET a value of a higher visibility priorty and it's allowed to go away
and reveal the original value of lower visibility priority".

This makes sense as a merge/patch operation, but less so with a single
object store.

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 01 Oct 2014 10:53:48 -0400

I had assumed that the YANG "datastore" was the repository in which the 
I2RS agent stored all of the operations it had applied, who had applied 
them, etc.

This actually does lead to a related question.
How does an I2RS client delte the state it has created.  (Note that said 
state might actually include a deletion from the underlying data.)
The client is not required to have the knowledge of what the config / 
I2RS state was before it performed its operation.  And even if it were, 
having an I2RS client set it to a specific value is not the same as 
removing the I2RS state (because of priority.)
I don't think we have been explicit about the need to express this, but 
it is implicit in the architecture.

Yours,
Joel

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Oct 2014 15:03:44 +0000

On Oct 1, 2014, at 10:53 AM, Joel M. Halpern <[email-masked]> wrote:

> I had assumed that the YANG "datastore" was the repository in which the I2RS agent stored all of the operations it had applied, who had applied them, etc.
> 
> How does an I2RS client delte the state it has created.  (Note that said state might actually include a deletion from the underlying data.)

How, if the client writes only into ephemeral store? 

> The client is not required to have the knowledge of what the config / I2RS state was before it performed its operation.  And even if it were, having an I2RS client set it to a specific value is not the same as removing the I2RS state (because of priority.)
> I don't think we have been explicit about the need to express this, but it is implicit in the architecture.
> 
> Yours,
> Joel
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 01 Oct 2014 11:08:00 -0400

In line:

> On Oct 1, 2014, at 10:53 AM, Joel M. Halpern <[email-masked]>
...
>> This actually does lead to a related question. How does an I2RS
>> client delte the state it has created.  (Note that said state might
>> actually include a deletion from the underlying data.)
>

There is nothing in the I2RS work that says that the only requests that 
the I2RS client can make are creation or modify operations.  It seems 
perfectly legitimate for an I2RS client to decide that the what needs to 
be done is to remove some static route or policy statement, because 
circumstances have temporarily changed.

Yours,
Joel

PS: THe same question still applied even if it can not delte, since 
having the I2RS client write new values is not the same as removing the 
data.  And having an I2RS client issue a delete operation for something 
it has created does not seem to mean the same thing as "return this to 
its previous value" which is the required I2RS semantics.

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Oct 2014 15:14:23 +0000

On Oct 1, 2014, at 11:08 AM, Joel Halpern Direct <[email-masked]> wrote:

> There is nothing in the I2RS work that says that the only requests that the I2RS client can make are creation or modify operations.  It seems perfectly legitimate for an I2RS client to decide that the what needs to be done is to remove some static route or policy statement, because circumstances have temporarily changed.

That is opening a can of worms. You can not allow deletion of data that is not owned by the client. That can create instability of the system and the network. Using your example, I2RS client should enter a new static route or policy statement that would nullify the existing one.
> 
> Yours,
> Joel
> 
> PS: THe same question still applied even if it can not delte, since having the I2RS client write new values is not the same as removing the data.  And having an I2RS client issue a delete operation for something it has created does not seem to mean the same thing as "return this to its previous value" which is the required I2RS semantics.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 01 Oct 2014 11:19:10 -0400

Continuing in line, although this may get too deep:

On 10/1/14, 11:14 AM, Dean Bogdanovic wrote:
>>>> This actually does lead to a related question. How does an
>>>> I2RS client delte the state it has created.  (Note that said
>> There is nothing in the I2RS work that says that the only requests
>> that the I2RS client can make are creation or modify operations.
>> It seems perfectly legitimate for an I2RS client to decide that the
>> what needs to be done is to remove some static route or policy
>> statement, because circumstances have temporarily changed.
>
> That is opening a can of worms. You can not allow deletion of data
> that is not owned by the client. That can create instability of the
> system and the network. Using your example, I2RS client should enter
> a new static route or policy statement that would nullify the
> existing one.

One can argue that all of I2RS is a can of worms.  But I don't think 
that is reasoanble.

Your proposal would mean that if the goal of the I2RS client was to 
cause a specific route, that had been pinned by the operator, to follow 
dynamic routing instead, then the I2RS client would ahve to monitor the 
rib for any non-applied changes, mirror the rib manager logic, and 
manually update the static route with the answer the rib manager would 
have produced if the static route were not there?

Seems rather complex and error prone for a reasonable policy hammer.
One of the agreements reached in teh I2RS work early on is that if the 
operator wants to shoot his foot using I2RS and produce a really painful 
configuration, then he is free to do so.

Yours,
Joel

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Oct 2014 15:28:59 +0000

Deleting some of older emails
On Oct 1, 2014, at 11:19 AM, Joel M. Halpern <[email-masked]> wrote:

> One can argue that all of I2RS is a can of worms.  But I don't think that is reasoanble.
> 
> Your proposal would mean that if the goal of the I2RS client was to cause a specific route, that had been pinned by the operator, to follow dynamic routing instead, then the I2RS client would ahve to monitor the rib for any non-applied changes, mirror the rib manager logic, and manually update the static route with the answer the rib manager would have produced if the static route were not there?
Please keep in mind that we are proposing only a single data store for I2RS. If I2RS client has to read/write/delete from a different store, use different mechanism to do so.

> One of the agreements reached in teh I2RS work early on is that if the operator wants to shoot his foot using I2RS and produce a really painful configuration, then he is free to do so.
Yes, you are fully right on this topic and I agree with it.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Oct 2014 11:59:42 -0400

On Wed, Oct 01, 2014 at 10:53:48AM -0400, Joel M. Halpern wrote:
> How does an I2RS client delte the state it has created.  (Note that
> said state might actually include a deletion from the underlying
> data.)

This was briefly discussed at the netmod interim.

With the idea that the "creator" is metadata that is part of the
configuration, it becomes possible to craft new operations (rpc? extensions
to netconf?) that effectively become "purge datastore (by createor-id)"

The place this sort of "by creator-id" operation becomes messy is if two
different clients of differing priorities have written to overlapping 
state - either from a schema perspective or from a dependency perspective.
In such a case, deleting the higher-priority client state may lead to
inconsistent configuration from what remains of the prior lower priority
client state.

The I2RS architecture basically says "send a notification this has happened
and let the clients sort it out".

-- Jeff

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 1 Oct 2014 17:31:43 +0000

Alia,

Your question makes sense if I2RS is limited to routing data manipulation.
In this case it could be thought of as an additional routing protocol.After all OSPF does not need any data store to install its routes,
What if I2RS client want to configure other things?

Igor
________________________________________
From: i2rs [[email-masked]] on behalf of Alia Atlas [[email-masked]]
Sent: Wednesday, October 1, 2014 9:54 AM
To: Dean Bogdanovic
Cc: [email-masked]
Subject: Re: [i2rs] Why do we need a datastore?

Hi Dean,

Regards,
Alia

Hope this helps

Dean

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 1 Oct 2014 10:33:06 -0700

> What if I2RS client want to configure other things?

	Then just use Netconf or RestConf.

	--Tom

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Oct 2014 17:43:11 +0000

Tom,

On Oct 1, 2014, at 1:33 PM, Thomas D. Nadeau <[email-masked]<mailto:[email-masked]>> wrote:

On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin <[email-masked]<mailto:[email-masked]>> wrote:

Alia,

Isn't this contradictory to your statement made in http://www.ietf.org/mail-archive/web/i2rs/current/msg02061.html

Dean

--Tom

Igor
________________________________________
From: i2rs [[email-masked]<mailto:[email-masked]>] on behalf of Alia Atlas [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 1, 2014 9:54 AM
To: Dean Bogdanovic
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] Why do we need a datastore?

Hi Dean,

Regards,
Alia

On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:
Hi Alia,

Hope this helps

Dean

On Oct 1, 2014, at 12:25 AM, Alia Atlas <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Hi,

Regards,
no-hats  Alia

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

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 1 Oct 2014 17:45:49 +0000

What if these things must not survive reboots?
________________________________________
From: Thomas D. Nadeau [[email-masked]]
Sent: Wednesday, October 1, 2014 1:33 PM
To: Igor Bryskin
Cc: Alia Atlas; Dean Bogdanovic; [email-masked]
Subject: Re: [i2rs] Why do we need a datastore?

        --Tom

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Oct 2014 17:52:46 +0000

> What if these things must not survive reboots?

There are plenty of mechanisms how this can be achieved. I2RS is not the only way to create such non persistent configuration changes.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Oct 2014 11:15:40 -0700

> since I read up on YANG and NetConf/RestConf.
It is a great question because the datastore is used for 3 reasons in
NETCONF/YANG.

  1) conceptual container for top-level YANG data nodes
        1a) source parameter for retrieval; target parameter for editing
  2) conceptual container for YANG validation rules for the running
datastore
  3) conceptual container for access control model

I don't agree that multiple ephemeral datastores are needed. Support for
multiple clients
within 1 datastore is needed.

YANG validation rules for the ephemeral datastore are not interesting, just
the "active"
config (running + ephemeral). The access control model for I2RS is
different than NETCONF.

Recent discussion has me confused:

   A) Are the YANG modules exactly the same for the running and ephemeral
datastores?
   (Interim decided yes)

   B) How are the same instances of the same data model related in the
running and ephemeral
        datastores?

I thought "phase 1" was supposed to be simple and the I2RS client would
just inject and remove
RIB data to override the running config.  So, answer to (B) is: datastores
have independent
instances. If ephemeral instance exists, it is used. If deleted, then the
instance from the
running config (if any) becomes active.  As long as the ephemeral instance
exists, the running config
instance is ignored.

Is this consistent with the architecture document?
Which solution best fits the agreed upon architecture?

Regards,
> no-hats  Alia
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 01 Oct 2014 21:19:28 +0200 (CEST)

"Joel M. Halpern" <[email-masked]> wrote:
> I had assumed that the YANG "datastore" was the repository in which the I2RS
> agent stored all of the operations it had applied, who had applied them, etc.

Yes.

> How does an I2RS client delte the state it has created.

(Jeff replied to this)

> (Note that said state
> might actually include a deletion from the underlying data.)

Right, we also discussed this at the interim.  The idea we discussed
was the ability to tag a subtree with an operation, which could be
"merge", "replace" or "delete" (with "merge" being the default).

> The client is not required to have the knowledge of what the config / I2RS
> state was before it performed its operation.

In this case it probably should use the "replace" operation - this
ensures that the data in the "active" config is exactly what's in the
ephemeral store, regardless of what was in the local config.

/martin

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 1 Oct 2014 12:23:41 -0700

On Oct 1, 2014:11:15 AM, at 11:15 AM, Andy Bierman <[email-masked]> wrote:

> It is a great question because the datastore is used for 3 reasons in NETCONF/YANG.
> 
>   2) conceptual container for YANG validation rules for the running datastore
> I don't agree that multiple ephemeral datastores are needed. Support for multiple clients

	That is precisely the point I've been making. We've been making this discussion far too complex.  

> YANG validation rules for the ephemeral datastore are not interesting, just the "active"
> config (running + ephemeral). The access control model for I2RS is different than NETCONF.
> 
>    A) Are the YANG modules exactly the same for the running and ephemeral datastores?
>    (Interim decided yes)

	Lets hope so, or we've gone off into the woods...

>    B) How are the same instances of the same data model related in the running and ephemeral
>         datastores?
> 
> I thought "phase 1" was supposed to be simple and the I2RS client would just inject and remove
> RIB data to override the running config.  So, answer to (B) is: datastores have independent
> instances. If ephemeral instance exists, it is used. If deleted, then the instance from the
> running config (if any) becomes active.  As long as the ephemeral instance exists, the running config
> instance is ignored.
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 1 Oct 2014 12:25:12 -0700

This is where the "copy to running config" discussion has arrived at. We either need a special i2rs "operation" or just a "write to config" object that can be set and triggers the action.  But by default, the changes are ephemeral and thus do not survive reboots.

	--Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 01 Oct 2014 16:35:00 -0400

Actually, in most OSPF implementations, there are two relevant data 
stores.  OSPF often has one data store internally, and routes get 
installed into a common RIB, managed by a RIB manager, which is clearly 
a datastore.

It seems to me that "datastore" is just a descriptive term for the set 
of manipulable state information.  It has been clear from the outset 
that I2RS had to store the operations it applied in some meaningful 
fashion.  Otherwise it could not do collision detection, or operation 
removal.

Yours,
Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Oct 2014 00:05:46 +0200

On Wed, Oct 01, 2014 at 11:15:40AM -0700, Andy Bierman wrote:
> multiple clients within 1 datastore is needed.
> 

We can punt this but I believe we will be back discussing this again
in a couple of years. If multiple clients inject state (in an
uncoordinated way), certain things will go wrong. If we have no way to
separate multipe uncoordinated I2RS clients (e.g., by controlling the
priorities of different ephemeral datastores), then we will need hacks
with metadata to work around this.

Perhaps it is OK to ignore multiple ephemeral datastores now in order
to make progress. But I believe we are better off if things are
designed such that there can be multiple ephemeral datastores when
they are useful, that is we should not do anything to prevent having
multiple ephemeral datastores.

/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: Andy Bierman <[email-masked]>
Date: Wed, 1 Oct 2014 15:18:51 -0700

> with metadata to work around this.
There are different priorities for clients.
The collision management and cleanup are basically the same either way,
because the agent is not required to remember state that got bumped.
It that were true, then a separate datastore per client would be a feature
instead of an implementation detail.

> multiple ephemeral datastores.

It's hard enough to agree on 1 ;-)

IMO the ephemeral config always overrides the running config.
That means in order to remove a static entry from the active config
(but not the running config), there needs to be an operation
for creating a "data instance deleted" entry in the ephemeral datastore.
(Not a way to have I2RS actually delete entries from the running config).

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 2 Oct 2014 10:08:23 -0400

Andy,

> exists, the running config

I believe this to be the case.  Discussion has suggested people aren't quite
convinced in all cases.  Working through the cases will hopefully push us to
agreement.

> Which solution best fits the agreed upon architecture?

The architecture basically says state and user priority and client priority.
It's abstract because we were requested to not argue architecture within the
context of an underlying modeling language or protocol.  Now that we've
selected those, we have to figure out what reality we can live with.

Much like any software engineering, architecture documents don't fully
survive implementation. :-)

-- Jeff

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Oct 2014 16:40:26 -0400

Hi Dean,

Sorry for the delay in responding.  Telechats do that to one.

On Wed, Oct 1, 2014 at 10:12 AM, Dean Bogdanovic <[email-masked]> wrote:

>
>  On Oct 1, 2014, at 9:54 AM, Alia Atlas <[email-masked]>
>  wrote:
>
>  Hi Dean,
>
> Where I am confused is why I2RS - which is doing ephemeral only and
> matches closer to the direct proprietary APIs directly to
>  Today there is no standard protocol to expose writing to the daemons
> directly, except through a datastore. If you would compare routing daemon
> in Junos and routing daemon in IOS or NX-OS, the data models are very
> different. You need a standard API to communicate to all of them.
>

Right - but that's what I2RS is asking and trying to do.  I'm sure I didn't
just hear you say that we can't do it because it doesn't exist yet.

> 2. replay config data from the local data store (single data store) and
> request all I2RS clients to replay their data again
>
>  Now if some I2RS client, during the crash, tried to execute routing
> changes, with local store, those can be executed and put into wait state
> until daemon recovers. I2RS clients can be informed that their changes are
> pending.
>

I do understand that a datastore is useful for config.  For I2RS, if the
relevant routing crashes, then the I2RS clients are just notified that
their state is gone.  If an I2RS client tries to request a change and the
routing daemon isn't up, then the change fails!  This is part  of being in
a dynamic and distributed system.

>  Another issue is  with config statements. If you go directly to the
> daemons, only few very basic things can be exposed (like interfaces,
> routes, stateless fw filters). If you want to expose more complex
> statements like L3VPN, then you have to create a logic that will
> communicate to multiple daemons to create such state on the device. You are
> doubling such logic on the device.
>

Right - but here I have to pull our attention back to the charter.  We can
do:
   RIB, topology (read only), BGP, DDOS mitigation, hub-and-spoke routing
improvement, and traffic exit point optimization.

If there are proprietary mechanism for everything else, that's ok.  Let's
get this designed correctly - given the WG agreement on the architecture
and the charter constraints on the use-cases.

 I want to allow network administrators to decide by them self what is
> exposed through I2RS, not us (vendors, SDOs).
>

Then we boil the ocean, claim everything is safe, try and solve all the
hard problems instead of taking reasonable efforts with the simple parts
first.

Let's get something done that can be implemented.

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Oct 2014 17:18:59 -0400

On Wed, Oct 1, 2014 at 10:13 AM, Jeffrey Haas <[email-masked]> wrote:

> matches

We do?  I agree that NetConf/RestConf/YANG are the bases that the WG wants
to use
to build I2RS.  I don't think that anyone has the idea that they match
perfectly or
wouldn't need modification for this use.

> and reveal the original value of lower visibility priority".

We had that semantic initially (I forget which draft) - and there was
serious WG
pushback that it was too complicated.

I think that a LOT of this simplifies if you make one of two assumptions.
Either
the CLI/NetConf-for-config overrides I2RS or I2RS overrides the
CLI/NetConf-for-config.

If I2RS is lower priority than CLI/NetConf, then when config comes in, any
I2RS
state is preempted and the appropriate I2RS client is notified.  If I2RS
overrides,
then when I2RS state comes in, the associated CLI state is deleted.  I
grant that
the latter case is more complicated - and I'd be really surprised to see
implementations
that were comfortable going there yet.

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Oct 2014 17:22:50 -0400

Hi Igor,

On Wed, Oct 1, 2014 at 1:31 PM, Igor Bryskin <[email-masked]>
wrote:

> In this case it could be thought of as an additional routing
> protocol.After all OSPF does not need any data store to install its routes,
>

Exactly - and that is what I2RS is chartered to do.

> What if I2RS client want to configure other things?

I'd like to see us crawl and get the basics right instead of trying to do
everything.
Different mechanisms may apply and be relevant.

Regards,
Alia

Igor

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Oct 2014 17:31:34 -0400

>         1a) source parameter for retrieval; target parameter for editing

Since I2RS is based on single operations - sort of like what I understand
is the case
for RestConf - I don't see this applying to I2RS.  Am I missing something?

>   2) conceptual container for YANG validation rules for the running

Again, I don't think that I2RS really is doing YANG validation.  I guess
this is a detail
that isn't really discussed in the architecture, but my assumptions have
been that
it would negatively impact the desired speed and throughput of operations
in I2RS.

>   3) conceptual container for access control model

And as you say below, this is different for I2RS.

So again - why does I2RS need a datastore?

>    A) Are the YANG modules exactly the same for the running and ephemeral

I understand that the NETMOD interim decided it'd be nice.  But I'm not yet
convinced or hearing reasons that convince me that it is the case for
I2RS.  For instance, the type of events or functionality and abstractions
that make sense in I2RS may be quite different.   Certainly,
what we have for a RIB model is not what you'd see for a static routes
configuration model.

> exists, the running config

It depends on the priorities between the config and I2RS.

> Which solution best fits the agreed upon architecture?

The architecture lets the implementation determine what priority the
CLI/NetConf-config
is at compared to any I2RS client.  If it is better, the the I2RS client
would have its state
rejected in case of an overlap.

Cheers,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Oct 2014 17:36:39 -0400

> discussion far too complex.

Yes - this does not need to be as complex.

> Lets hope so, or we've gone off into the woods...

That is my concern.   I've seen no reasoning beyond wishful thinking and a
desire to allow anything to be done quickly and ephemerally.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Oct 2014 17:38:38 -0400

On Wed, Oct 1, 2014 at 3:25 PM, Thomas D. Nadeau <[email-masked]>
wrote:

>
>         This is where the "copy to running config" discussion has arrived
> at. We either need a special i2rs "operation" or just a "write to config"
> object that can be set and triggers the action.  But by default, the
> changes are ephemeral and thus do not survive reboots.
>

The initial I2RS framework went down this path of allowing permanent as
well as ephemeral - as you well know - and the WG consensus  was to take it
out as too complex.

Frankly, we're almost 2 years since the BoF and don't have anything that is
implementable.  I think we need to stay simple.

Regards,
Alia

> >> 1. CLI - is the UI we all know and use it quite heavily. In order for
> the device to boot in a known state a set of CLI commands have to be saved
> >> So today, most network operators (by this I mean any entity that
> operates a network, either enterprise or carrier), need to simplify network
> >>> I apologize if this seems a naive question, but it's been quite a
> while since I read up on YANG and NetConf/RestConf.
> >>>
> >>> Regards,
> >>> no-hats  Alia
> >>>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Oct 2014 17:43:27 -0400

> (Not a way to have I2RS actually delete entries from the running config).

To quote the I2RS Architecture,

"6.3.  Interactions with Local Config

   Changes may originate from either Local Config or from I2RS.  The
   modifications and data stored by I2RS are separate from the local
   device configuration, but conflicts between the two must be resolved

   in a deterministic manner that respects operator-applied policy.
   That policy can determine whether Local Config overrides a particular
   I2RS client's request or vice versa.  To achieve this end, either by
   default Local Config always wins or, optionally, a routing element
   may permit a priority to be configured on the device for the Local
   Config mechanism.  The policy mechanism in the later case is
   comparing the I2RS client's priority with that priority assigned to
   the Local Config.

   When the Local Config always wins, some communication between that
   subsystem and the I2RS Agent is still necessary.  That communication
   contains the details of each specific device configuration change
   that the I2RS Agent is permitted to modify.  In addition, when the
   system determines, that a client's I2RS state is preempted, the I2RS
   agent must notify the affected I2RS clients; how the system
   determines this is implementation-dependent.

   It is critical that policy based upon the source is used because the
   resolution cannot be time-based.  Simply allowing the most recent
   state to prevail could cause race conditions where the final state is
   not repeatably deterministic."

Now - if we have to decide that the CLI always wins, that is one option.
I, personally, would be quite opposed to the idea that I2RS would always
win.  That does not give recovery mechanisms to the operators when and
if something goes wrong.

Regards,
Alia

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 3 Oct 2014 22:05:32 +0000

On Oct 3, 2014, at 4:40 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dean,

On Wed, Oct 1, 2014 at 10:12 AM, Dean Bogdanovic <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dean,

Right - but that's what I2RS is asking and trying to do.  I'm sure I didn't just hear you say that we can't do it because it doesn't exist yet.

I didn't say it is not possible. Every vendor will have to create an I2RS agent that will be directly connected to daemons and create a translation from internal to external APIs. Essentially create a parallel control/management plane to existing ones.

I do understand that a datastore is useful for config.  For I2RS, if the relevant routing crashes, then the I2RS clients are just notified that their state is gone.  If an I2RS client tries to request a change and the routing daemon isn't up, then the change fails!  This is part  of being in a dynamic and distributed system.

agree with this.

Right - but here I have to pull our attention back to the charter.  We can do:
   RIB, topology (read only), BGP, DDOS mitigation, hub-and-spoke routing improvement, and traffic exit point optimization.

two questions are coming out:
how do you plan to do DDoS mitigation: stateless or statefull? And you have to get more details about traffic exit point optimization. If any of the constructs require more then one daemon involvement, it complicates the case.

If there are proprietary mechanism for everything else, that's ok.  Let's get this designed correctly - given the WG agreement on the architecture and the charter constraints on the use-cases.

Then we boil the ocean, claim everything is safe, try and solve all the hard problems instead of taking reasonable efforts with the simple parts first.

I disagree with you to certain extent, but am fine with your statement. In case WG changes its mind later, it might not be easy to achieve those goals.

Regards,
Alia

Dean

Regards,
Alia

Hope this helps

Dean

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 6 Oct 2014 09:32:03 -0400

> win.  That does not give recovery mechanisms to the operators when and

So, what is your proposal to allow CLI/local config to win over ephemeral
state?  If not something comparable to "option 4", what then?

-- Jeff

---

From: Alia Atlas <[email-masked]>
Date: Mon, 6 Oct 2014 11:01:40 -0400

> state?  If not something comparable to "option 4", what then?

Jeff,

It's a good question.  I have been sweeping it under
"implementation-specific"
since it is up to an implementation to decide what collides.  If we were
talking about
vendor-specific CLI vs. YANG models for I2RS, how would it work?  At the
end of
the day, there has to be understanding of what internally is impacted.

I can picture different abstractions or subsets being exposed for I2RS
rather than
CLI or NetConf-for-config.  I do go more towards Russ's idea of I2RS as a
routing
protocol that cooperates with the other routing protocols rather than just
another name
for a management protocol.

Regards,
Alia

---

From: "Osborne, Eric" <[email-masked]>
Date: Mon, 6 Oct 2014 15:32:02 +0000

Inline with EO#

From: i2rs [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Monday, October 06, 2014 11:02 AM
To: Jeffrey Haas
Cc: [email-masked]; Juergen Schoenwaelder; Andy Bierman
Subject: Re: [i2rs] Why do we need a datastore?

On Mon, Oct 6, 2014 at 9:32 AM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

Jeff,

It's a good question.  I have been sweeping it under "implementation-specific"
since it is up to an implementation to decide what collides.  If we were talking about
vendor-specific CLI vs. YANG models for I2RS, how would it work?  At the end of
the day, there has to be understanding of what internally is impacted.

EO#  If there isn’t some commonality or some way to control this then it becomes a nightmare for operators.  I have to teach my tools that different platforms need different care and feeding upon restart.  Can we at least have some 2119-style MUSTs for default and a well-structured flag for any config which deviates from that default?

I can picture different abstractions or subsets being exposed for I2RS rather than
CLI or NetConf-for-config.  I do go more towards Russ's idea of I2RS as a routing
protocol that cooperates with the other routing protocols rather than just another name
for a management protocol.

Regards,
Alia

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Mon, 6 Oct 2014 08:36:04 -0700

> the day, there has to be understanding of what internally is impacted.
If an I2RS client needs to monitor system state, local config changes,
and also know the proprietary CLI in order to function, it will be too
complicated
to implement. If the CLI or local config has disabled I2RS for some or all
clients,
then the requests will get rejected by the agent. Proprietary data models
and
CLI should be out of scope.

> for a management protocol.

I was surprised at the interim that every config=true schema node could
apply
to running config or ephemeral data, and it is always an operator decision
as to
which instances go in which datastore.  This seems like a vendor decision
first.

I also figured I2RS would ignore local config and just attempt to inject
routing state.
It is up to the agent to resolve local config with ephemeral config to
produce
operational state.  I can see local CLI disabling I2RS, but not competing
with
it to insert data, so I don't understand the "CLI wins over I2RS" use-case.

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 6 Oct 2014 12:55:56 -0400

On Mon, Oct 06, 2014 at 08:36:04AM -0700, Andy Bierman wrote:
> apply to running config or ephemeral data, and it is always an operator
> decision as to which instances go in which datastore.  This seems like a
> vendor decision first.

As I keep mentioning, fully disjoint data models from local config are
likely.  That case is easy.

Models that augment or use information in local/running config have been
proposed and defining their semantics are where we spent a lot of time.

If the WG can't manage to converge on the details of such interaction, it
may be simpler to say we're going to refuse to solve it and simple declare
such interactions out of scope.  This would leave us with *only* disjoint
models, although with the possibility of using elements from config models,
e.g. groupings.

-- Jeff