> May be I2RS clients need to get ‘permission’ from an orchestrator or > “an I2RS-coordinator” before issuing ‘set’ operations to I2RS agent?
Backing up a little in the thread --this, specifically, is what we want to avoid. We don't want a "lock/release," or a transaction oriented protocol to ensure referential integrity across all devices in the I2RS domain. Maybe an illustration would help: Does the OSPF to RIB interface ensure referential integrity among all the routers within a single OSPF flooding domain? No... the forwarding plane on each device counts on OSPF to ensure integrity (and, BTW, OSPF doesn't ensure perfect real time integrity -- take a look at the work going on in fast reroute and ordered FIB as examples of narrowing the window of time during which the link state topology and the real world topology are not congruent). In the same way, the integrity or loopfreeness of the routes calculated by the control plane -- some process residing on the client -- is not something the interface between the client and the agent can, or should, handle. It's up to the creator of the protocol running in that process to ensure things are being forwarded correctly, etc. If you're trying to prevent order of operation issues, again this is no different than the problem of microloops in any link state protocol, or the BGP hunt convergence, or BGP flipping back and forth between two different routes. The protocols can be fixed to stop this sort of stuff, but that's a protocol level problem, not a problem to be addressed by making all BGP processes check with a central process before installing a route in a local RIB. So no, there's protection against such things with the I2RS charter, or any of the drafts (that I know of) so far. And I, for one, would actually object to such a thing -- because it adds a level of complexity into I2RS that should rightfully live someplace else in the system -- specifically within the control plane(s) driving I2RS. HTH :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
