Re: [i2rs] format for information models

[Nikolay Milovanov <[e-mail]>]

Hi, 

I also agree with Edward's position. If I understood correctly the goal is architecture of a framework for application based forwarding plane control of routing systems. In that sense there will be some work to model the hierarchical structure of the devices but also most likely there might be a need to model the topology of the network or even the topology on different network layers. 

Obviously there is a difference between data and information model and if I understood correctly the difference is in the formality of the model. I would like to make a bridge between the network architecture modeling and software architecture modeling. 
So in Software Architecture there could be quite formal architecture modeling languages (for example ACME, ALLOY,WRIGHT), semi-formal (Like UML) and informal for example visio drawings. 
From those ACME might be interesting for topology based modeling. It based on the idea that the topology consists of components and connectors and each component has ports and each connector roles. Acme is also good for modeling the properties of different components, connectors, ports and roles. I find it good compared to other languages including UML because it allows definition of families of systems and more importantly putting constrains on them. For example connector X, with roles Y can't go in Component Z with Port H. I find ACME quite nice for modeling systems and even system of systems. The good part of it is that it also comes with a tool that is handy for modeling. 

ALLOW and WRIGHT are AMLs(Architecture Modeling Languages) that are good for modeling the behavior of the certain software intensive systems. I am not sure is behavior modeling among the i2rs goals so won't comment on that. 

Regarding UML what about the typical OSS/BSS based modeling based on the TMForm SID model? SID is quite common in telecom industry. It is based on UML class diagrams and already contains classes that model network resources and network services. Personally (as a network engineer) I find SID and UML a bit horrible but this is personal opinion (for example the developers from my team find it nice and easy to understand). 

The last sentence reminds me also that there might be different stakeholders that will benefit from i2rs results (e.g engineers from software community and network engineers) and it might be good if the working group produces views of the models  that will allow different stakeholders to reason about them. 

BR, 
Nikolay Milovanov 
New Bulgarian University 
[e-mail] 


On Jan 24, 2013, at 8:28 PM, Edward Crabbe wrote:

> +1 here.  If the relationships are hierarchical / acyclic then YANG would be a good choice /but/  we also have draft-amante-irs-topology-use-cases-0 on the table, and potentially some related documents incoming;  if these efforts move forward (ie: modelling inter layer relationships and the physical plant) we may want to look at other alternatives. 
> 
> I think this is an interesting discussion to have; it's a bit premature to settle on a solution given the current uncertainty in the use case set, *but* it's almost never too early to start experimenting.  
> 
> 
> On Thu, Jan 24, 2013 at 8:26 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> On Thu, Jan 24, 2013 at 11:13:44AM -0500, Alia Atlas wrote:
> > Juergen,
> >
> > What would you recommend for an information model for i2rs?
> >
> 
> Frankly, I do not know. I am still unsure what the scope/complexity of
> i2rs really is. To find out, I guess people just have to pick
> something and get started. YANG tree diagrams are fine to get a quick
> overview of YANG data models, they likely won't be the right tool if
> many of data model items with more complex interrelationships are
> involved - then you need additional diagrams.
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
> 
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs