Hi,
On Sat, Apr 19, 2014 at 8:22 AM, Russ White <[email protected]> wrote: > > > 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. > Can you explain how an off-line representation of the data model can be fast or slow? You mean the YANG compiler takes too long to process a YANG file? You mean the unspecified I2RS protocol will be too slow on the wire if it uses XML or JSON encoding of YANG data structures? > > - 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 (?). > > YANG is a data modeling language. RESTCONF is a protocol. Atomicity is a property of the protocol. Which YANG statements prevent this from being accomplished in the TBD I2RS protocol? > 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. > > It seems to me this WG needs to start asking the right questions about the data modeling language requirements. E.g.: - What are the data types needed? Is this a static set of will it ever change? - What are the high level data modeling constructs needed? - Are user defined types needed? - Are re-usable data definitions needed? - Does the data model need to be modular? How does it grow over time? - Can vendors add data definitions that extend the standard definitions? - How are new definitions added in a way that does not break existing clients? - How is mandatory to implement vs. optional to implement functionality handled? - How is mandatory to use vs. optional to use functionality handled? You are asking about protocol requirements, not data modeling. IMO it would be near-sighted and extremely impractical to choose a language that only supported description on RIB info. I fail to see what is so special about RIB info that would warrant its own DML. :-) > > Russ > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
