Hi Eric, On Thu, Nov 7, 2013 at 3:51 PM, Eric Osborne (eosborne) <[email protected]>wrote:
> If you want to get the link state for an entire network there are two ways > to do it: > > 1) the i2rs client fetches each node's link state info from that node, and > plugs them together to make a network, > 2) the i2rs client fetches the entire LSDB from one node. > > IMO either one is OK, and #2 makes the most sense. In any case it's a > read-only thing so it doesn't really matter how it gets done. > I agree that (2) makes sense - but certainly how it gets done does matter. Writing isn't the only complexity. Take another read through draft-swhyte-i2rs-data-collection-system<http://trac.tools.ietf.org/id/draft-swhyte-i2rs-data-collection-system-00.txt> if you think it is :-) For instance, I see (2) as likely being exposed as an information stream that can be subscribed to. Where it gets hairy is when you want to write to the network. The question > that kicked off this thread was along those lines, if I recall. If you > want to get a mutex on the network as a whole you *need* a way to lock all > devices. Perhaps this is best done in the client - acquire a lock on the > config for each node in the network, make your changes, then unlock. If > there were a higher level way to do this with some sort of network API > that's what it would have to do under the covers anyways. And if you have > locking write access to the client then you don't need a network model, > just a router model. > Writing the topology is specifically out of scope. I2RS is certainly not expecting to do things such as lock all devices. Alia
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
