Sorry, was there something i missed here that Andy is awesom-ing? What graphics?
Sounds to me like an information model in plain english (the openstack people do this) would have been a reasonable start as well, no? cheers, jamal On Wed, Apr 23, 2014 at 11:03 AM, Andy Bierman <[email protected]> wrote: > > > > On Wed, Apr 23, 2014 at 7:41 AM, Susan Hares <[email protected]> wrote: >> >> Andy: >> >> >> >> I started using UML to do the information models because Adrian Farrel and >> Alia Atlas encouraged it to replace RBNF. I think that the yang/netconf >> models are still mining the existing SNMP/Configuration structures. For new >> development, I suspect UML may help us root out redundancy. Why? Because I >> think I've found lots of redundancy in the RIB_INFO model. I've attached >> slides that may convince you, and an alternate drafts. >> >> > > > > I do not have any objections to using UML. > They are painful to read and write in ASCII art. > Maybe that's why we tend to describe the model in introductory text. > We also try to avoid duplicating normative text, and try to keep as much > normative text in the YANG modules themselves (since they tend to get > extracted and the RFC tossed ;-). > > This is an awesome step forwards. Thanks! > I was going to translate the next info-model draft to YANG so we > can compare YANG and ForCES using the same data definitions. > Looks like you already did that, but I just see the YANG tree diagram in the > draft, > not the YANG module. > > It is still enough to see how YANG features would be defined, based on > protocols. > Clearly, not every I2RS router is going to implement the exact same set of > protocols. > Not every conceivable piece of data is going to be mandatory to implement. > Data organization and modularity are really important aspects to get right > the first time. > > > Andy > > >> >> I've assumed in the information model that yang models as defined below >> >> +--------+---------------------------+-----------+ >> >> | Prefix | YANG module | Reference | >> >> +--------+---------------------------+-----------+ >> >> | if | ietf-interfaces | [YANG-IF] | >> >> | | | | >> >> | ip | ietf-ip | [YANG-IP] | >> >> | | | | >> >> | rt | ietf-routing | [routing] | >> >> | | | | >> >> | v4ur | ietf-ipv4-unicast-routing | [routing] | >> >> | | | | >> >> | v6ur | ietf-ipv6-unicast-routing | [routing | >> >> | | | | >> >> | yang | ietf-yang-types | [RFC6991] | >> >> | | | | >> >> | inet | ietf-inet-types | [RFC6991] | >> >> +--------+---------------------------+-----------+ >> >> >> >> I've attached a revision of the RIB-info-model draft that provides: >> >> 1) Revised RIB Grammar in RBNF (section 6.1) >> >> 2) (section 6.2) Spot for the pdf graphic attached as >> draf-thares-i2rs-info-rib-only-v7.pdf >> >> 3) (section 6.3) Yang tree structure (per yang documents) >> >> 4) Revised Usage - using simplified grammar >> >> >> >> Basically the complex RBNF grammar boils down to very few simply >> statement. The Yang Tree does not provide an easy way to design/debug >> redundancy. I think that the use of the UML tools that create the Yang >> modules/Yang Tree structures could speed time to market on the designs. For >> example, all the I2RS RIB is simply 5 power-point slides, that then can be >> generated into Yang module. This seems the normal progression of the >> process you started with the Yang-modules. >> >> >> >> CAVEATS: >> >> 1) For all mistakes on the UML and diagrams blame me - this first >> pass at UMLs, and it will need revising >> >> 2) Some of the redundancies could have been fixed in other ways >> >> 3) I did Yang modules to demonstrate proof of concept >> >> 4) I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. >> FoRCES Data model can do the same >> >> >> >> Sue Hares >> >> >> >> From: i2rs [mailto:[email protected]] On Behalf Of Andy Bierman >> Sent: Tuesday, April 22, 2014 8:46 PM >> To: Susan Hares >> Cc: [email protected]; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ >> White; Jan Medved (jmedved); Joel M. Halpern >> Subject: Re: [i2rs] consensus on I2RS protocol and model >> >> <..snip> >> >> 1) Why do you think that only the RIB matters in the long run (Short >> run = RIB + BGP) - >> >> [Andy] 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. >> >> [Sue]: Agree! >> >> >> >> 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. >> >> [Sue]: Other designers on lists stated they suggested they considered IM >> in their design of YANG. I think the graphical finds redundancies >> >> <snip) >> >> >> >> 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
