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
On Oct 1, 2014:10:45 AM, at 10:45 AM, Igor Bryskin <[email protected]>
wrote:
> What if these things must not survive reboots?
> ________________________________________
> From: Thomas D. Nadeau [[email protected]]
> Sent: Wednesday, October 1, 2014 1:33 PM
> To: Igor Bryskin
> Cc: Alia Atlas; Dean Bogdanovic; [email protected]
> Subject: Re: [i2rs] Why do we need a datastore?
>
> On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin <[email protected]>
> wrote:
>
>> 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?
>
> Then just use Netconf or RestConf.
>
> --Tom
>
>>
>> Igor
>> ________________________________________
>> From: i2rs [[email protected]] on behalf of Alia Atlas
>> [[email protected]]
>> Sent: Wednesday, October 1, 2014 9:54 AM
>> To: Dean Bogdanovic
>> Cc: [email protected]
>> Subject: Re: [i2rs] Why do we need a datastore?
>>
>> 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 protected]<mailto:[email protected]>> wrote:
>> 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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
