Hi,
On Sat, Apr 19, 2014 at 12:08 PM, Joel M. Halpern <[email protected]>wrote: > I actually expect that YANG can be extended to do what is needed. I also > expect that ForCES protocol can be extended to do what is needed on the > protocol side. > > But that is not the same as saying that either item "as is" meets the > needs as stated. > > It would seem appropriate to at least describe what extensions will be > needed to YANG before we decide to say "yes, we will use YANG and we will > extend it to address the needs." > > I did that already. See the I2RS slides from IETF #89. On the ForCES side, I believe Jamal did include that information in his > presentation. Is there a similar list for YANG that I have misplaced? > > Yours, > Joel > > On 4/19/14, 3:02 PM, Andy Bierman wrote: > >> >> >> >> On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern <[email protected] >> <mailto:[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]> >> <mailto:[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
