Actually I am not arguing against permanent vs ephemeral states on network element in fact I agree it is needed.
The only worry is that once you talk about two sort of provisioning channels for a given service - perhaps independent from each other - there will always be need for synchronization. Example: I can not modify/add/delete entries in RIB context X if this context X was not yet provisioned .. those classic sort of issues. Thx, R. > On Thu, Mar 14, 2013 at 7:26 PM, Dave Israel <[email protected]> wrote: > > On 03/14/2013 02:02 PM, Robert Raszuk wrote: >> >> Ahhh so you are stating that to provision services on the network in >> vendor neutral way I will not be able to use I2RS by design ? >> >> Is this already agreed point that NETCONF (or any other form of >> configuration) will be required anyway in addition to I2RS for any >> complete service provisioning ? > > > I don't think there are many already agreed points anywhere outside the > charter itself. So don't worry if I think something you don't like; I'm at > least as likely to be wrong as anybody else. > > Still, I am inclined to think that RIB manipulation is separate from > permanent configuration. And while you could run a service by > hand-configuring your RIBs everywhere with I2RS (with either a persistent > I2RB state or reconfiguration on reboot from the controller), it doesn't > seem like the *right* way to do it. It makes more sense to establish your > normal behavior through the existing configuration mechanisms (CLI, NETCONF, > etc), and then use I2RS to manipulate it. > > -Dave > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
