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
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
