Dean, see inline
On Fri, May 16, 2014 at 1:47 PM, Dean Bogdanovic <[email protected]> wrote: > > On May 1, 2014, at 5:17 AM, t.petch <[email protected]> wrote: > > > > > Jeff > > > > If I2RS updates the routing table, do we expect it to persist for any > > length of time? That is, the routing table is stable, the result of the > > convergence of the routing protocols (and configuration) across the > > relevant routers in the routing system and is reflected in the > > operational state of a router. > > > > A stable system in engineering is one that when perturbs, returns to its > > original state. So make a change in one router and I would expect the > > rest of the system to gang up on that router and reinstate the status > > quo. For example, what I have in Adj-RIB-Out comes from someone else > > via Adj-RIB-In and if I change Adj-RIB-Out, then sooner or later I will > > refresh it from Adj-RIB-In and be back where I started, while if I > > change Adj-RIB-In, then the other router will repeat its advertisement - > > and I will be back where I started. > > > > If I think of the changes I might want to make, it seems to me that they > > have to be changes to what NETCONF/YANG refer to as config and not to > > the operational state. Ephemeral or persistent, which I take to refer > > to what happens after a reboot, is then a question of which NETCONF > > datastore I update, running or startup or both. > > > > Tom Petch > > Tom, > > Good question, but IMO, I2RS agent should not change tables belonging to > dynamic routing protocols. Yes, the I2RS agent should not provide an interface to change a table if there is no use-case to support it. A dynamic routing protocol's route-table (e.g. IGP's route-table that it downloads to RIB) has no use-case to change it by another client. A read-only interface should be sufficient. > Changes done by I2RS agent should have only device impact, not network > impact. If there is desire to change across network, then each I2RS agent > on each device should be updated. > It is not simple to classify a change to a device as having an impact scoped to just that device. E.g a route that is added to a device with a different preference can have network-wide traffic impact. > > Dynamic protocol routing tables should be read only. I2RS agent should > create routing tables that can contain the same prefix as in the table > belonging to dynamic protocol, so creating custom routing preference is > possible. The RIB is the table where multiple clients (including multiple dynamic routing protocols) can create routes in order for it to be downloaded to the FIB. 'Preference' must be used to add multiple routes for the same prefix. The clients of the RIB can be dynamic routing protocols or clients that implement other use-cases. The RIB IM is designed to interface with all such clients. > If we really want to allow full manipulation of dynamic protocol routing > tables, I think some extensions to routing protocols would be required. > I am yet to see a use-case that requires direct manipulation of a single dynamic routing-protocol-instance specific route table by something other than that protocol. I don't believe there should be any such case. Sri > > Dean > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
