On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern <[email protected]>wrote:
> There are a number of modeling and protocol expectations (I think they can > be reasonable called requirements, and I think they have been agreed by the > working group) in the architecture draft. Some of them are a stretch for > YANG. Some of them are a stretch for ForCES. > > I assume you mean sec. 6.4.5? I did not find anything in there that YANG does not already support or could not support with a YANG extension statement. Since I2RS can define its own YANG extensions, YANG is ready today to meet all the requirements. Can you be more specific about the stretch items? Yours, > Joel > > Andy > On 4/19/14, 1:46 PM, Andy Bierman wrote: > >> Hi, >> >> >> On Sat, Apr 19, 2014 at 8:22 AM, Russ White <[email protected] >> <mailto:[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
