On Wed, Oct 1, 2014 at 3:25 PM, Thomas D. Nadeau <[email protected]> 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 > --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 > > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
