t.petch <[email protected]> wrote: > Is it, though, the right approach for I2RS? I see the rationale of I2RS > as being able to take a holistic view of the routing system, not one > based on where the information is coming from (a view that may make > sense when building boxes or installing them). > > Rather, I am minded of problems I have been called upon to resolve which > are the result of misconfiguration, misconfiguration which is not > apparent because the integrated view of what is controlling the box is > not available. For example, a static route is inserted to circumvent a > quirk of topology, the quirk is fixed but the static route is not > removed, the topology changes again and that static route becomes a > liability. Being able to see everything at once makes the problem > apparent, looking for a configuration error or a BGP error separately is > fruitless. > > My sense is that I2RS needs an integrated view whereas NETCONF/YANG > focus on the configuration (as their RFC explicitly state). YANG is a > good start, but as Andy said at IETF89, not enough.
I am not sure I what you mean by "integrated view". One reason for separating config from operational state is to make sure the view of operational state is exactly what is really currently in use. So if a static route has been configured, and it really is in use, it will show up in the operational state (marked as being a static route). Isn't the "integrated view" the complete operational state? If not, how is it different? /martin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
