>From your text I think I don't understand it. IMO, we don't need modeling software or hardware, just define architecture, because it is all about that. I think we will have one architecture and framework not many, so one IM
AB On 1/24/13, Nikolay Milovanov <[email protected]> wrote: > 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 > [email protected] > > > 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 >> <[email protected]> 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: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
