Tom, On Oct 1, 2014, at 1:33 PM, Thomas D. Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>> wrote:
On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin <ibrys...@advaoptical.com<mailto:ibrys...@advaoptical.com>> 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. 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 [i2rs-boun...@ietf.org<mailto:i2rs-boun...@ietf.org>] on behalf of Alia Atlas [akat...@gmail.com<mailto:akat...@gmail.com>] Sent: Wednesday, October 1, 2014 9:54 AM To: Dean Bogdanovic Cc: i2rs@ietf.org<mailto:i2rs@ietf.org> 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 <de...@juniper.net<mailto:de...@juniper.net><mailto:de...@juniper.net>> 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 <akat...@gmail.com<mailto:akat...@gmail.com><mailto:akat...@gmail.com>> 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 i2rs@ietf.org<mailto:i2rs@ietf.org><mailto:i2rs@ietf.org> https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org<mailto:i2rs@ietf.org> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
