I think this progress. I would be more than happy to go over the requirements listed there and whatever more for an "stretch" analysis needed for both protocol and model. In other words, some process. A joint draft perhaps.
cheers, jamal On Sat, Apr 19, 2014 at 3:16 PM, Andy Bierman <[email protected]> wrote: > 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 > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
