Re: [i2rs] format for information models

[Abdussalam Baryun <[e-mail]>]

>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 <[e-mail]> 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
> [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
>
>