Andy:
You are right about the graphics. I've started a thread to the RFC Editor and the ISE Editor who are working on the graphics. There is a UML to SVC project that I am looking into to see if we can do this. I just did the tree structures because they actually are a short step away from the UML diagrams. This may allow us to expand the yang trees to be a poor-man's uml while we wait for the graphics. Would you look at the tree to see if I got the yang tree right for config? The RBNF did not take care of the ro status, so I need to create this for the yang modules. This is one reason the RBNF is so poor rather than the UML. If these tree structures are ok, I think I can quickly turn this into a full yang definition. I'll do that once you respond and we can get the full yang module definition up and running. I'd love to work with you on a draft regarding the yang module definition as you are the expert. Sue From: Andy Bierman [mailto:[email protected]] Sent: Wednesday, April 23, 2014 11:03 AM To: Susan Hares Cc: [email protected]; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ White; Jan Medved (jmedved); Joel M. Halpern; Adrian Farrel; Alia Atlas; Nitin Bahadur; Jeffrey Haas Subject: Re: [i2rs] consensus on I2RS protocol and model 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 <http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13#ref-YANG-IF> ] | | | | | | ip | ietf-ip | [YANG-IP <http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13#ref-YANG-IP> ] | | | | | | rt | ietf-routing | [routing] | | | | | | v4ur | ietf-ipv4-unicast-routing | [routing] | | | | | | v6ur | ietf-ipv6-unicast-routing | [routing | | | | | | yang | ietf-yang-types | [RFC6991 <http://tools.ietf.org/html/rfc6991> ] | | | | | | inet | ietf-inet-types | [RFC6991 <http://tools.ietf.org/html/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
