On Thu, Apr 24, 2014 at 3:17 AM, Jamal Hadi Salim <[email protected]> wrote:
> Sorry, was there something i missed here that Andy is awesom-ing? > What graphics? > > No -- just progress on the info model. Once we have an info model, it can be mapped into both YANG and ForCES so they can be compared side-by-side, using the actual model that this WG wants to standardize. Andy > 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
