On Tue, Apr 22, 2014 at 5:36 PM, Susan Hares <[email protected]> wrote:
> Andy: > > > > Catching up. A few questions: > > > > 1) Why do you think that only the RIB matters in the long run (Short > run = RIB + BGP) > Why do you think I said that? I don't see anything special about I2RS at all. Editing operational state would probably work the same for other data. > 2) Your modeling questions are important .. so let me ask a > meta-question and then go a level deeper... > > > > Why does netmod never really publish an informational model? > > > NETMOD publishes YANG modules. I suppose it is perceived an unnecessary. Andy > Here's a bunch of answers/question to you great modeling questino > > > > - What are the data types needed? Is this a static set of will it ever > change? > > a) Yes. Right now no Data types in > > This static set is likely to continually expand if it is used for I2RS, > and have vendor specific > > > > - What are the high level data modeling constructs needed? > > [Sue] Yes. But we will talk a lot about what is high-level data model > constructs? > > Do you consider next-hop as defined in the RIB a high-level? > > > > - Are user defined types needed? > > [Sue" If you mean, will vendors or specific end users need it? I do not > see how we can go without it. > > > > - 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 definition? > > - How are new definitions added in a way that does not break existing > clients? > > > > [Sue]: Answer yes to all. Re-usable, modular, growing, vendor > extensible, user-defined. > > Do not plan to break if add new, > > > > - How is mandatory to implement vs. optional to implement functionality > handled? > > - How is mandatory to use vs. optional to use functionality handled? > > [Sue]: Need the profiling variables that Yang is using > > [Note: Forces has an equivalent to all of this] > > > Sue > > > > > > *From:* i2rs [mailto:[email protected]] *On Behalf Of *Andy Bierman > *Sent:* Saturday, April 19, 2014 1:46 PM > *To:* Russ White > *Cc:* [email protected]; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; > Jan Medved (jmedved); Joel M. Halpern > *Subject:* Re: [i2rs] consensus on I2RS protocol and model > > > > 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
