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
