> And the basic premise of I2RS is that there are requirements for the work > that were not addressed properly by the existing configuration protocols. > Otherwise the WG would not even need to discuss protocol modifications. > So the fact that NetConf / YANG works for device configuration does not > seem to be evidence that it works for what I2RS wants to do.
Precisely. Otherwise, we could have just looked at the problem, and said, "let's use YANG." But I think we're starting to confuse the problem set because we started by trying to boil the ocean. Once you actually get to town, it's hard to keep in focus that you're just there for a new pitchfork handle -- that game of checkers over there on the porch of the hotel looks so interesting, and the hardware store has so much other stuff than just pitchfork handles, after all. So, given we are _supposed_ to be focused on the RIB interface, and not protocol, configuration, device, etc., etc., what specific points have the use cases brought out that either NETCONF/YANG or FORCES not fulfill? One of the primary points was timing -- are these other systems fast enough? >From my perspective, these two systems don't fulfill the I2RS mandate on the RIB side for various reasons: - I'm not convinced on the speed side. YANG feels a bit heavy weigh for what we want here. The flexibility is there, but so is the cost of that flexibility. - I'm not convinced YANG has handled the atomicity issues in a way that makes sense for the application environment we have in mind. RESTCONF seems to go that direction, but I'm not certain it's a complete solution (?). So, IMHO, I think we need to either consider FORCES, or "something new." But we're going to have a hard time determining if this is true if we can't make a solid requirements list. For me, these are: - Atomic operations at the RIB level - Speed that's comparable to a local routing process installing routes in the RIB - An immediate feedback system within the RESTful mold that tells the installing process what happened, and why, with the route it just tried to install in the RIB So, it seems to me that we need to return to the use cases -- there are two in the charter. If we want to discuss adding others, that's fine, but we need to gain some focus, and stop trying to boil the ocean, if we want to make any progress. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
