[i2rs] Structure for I2RS communication information models (was Re: format for information models)

[Abdussalam Baryun <[e-mail]>]

Hi Ali,

IMHO, I will amend to my understandning
The information models are to describe what needs to be modeled in terms of
data that can be specified by i2rs procedures, read by the i2rs client
and servers, notifications of the i2rs. Thoes are all related to the
i2rs

The i2rs architecture and framework are about the interactions,
service, role and functions i2rs. The information model can be
designed after completing that, because it is serving that purpose.

I never compare between archeticture model and IM, they are both for
i2rs,because IM is language of communication within the i2rs
architecture model,

AB

On 1/24/13, Alia Atlas <[e-mail]> wrote:
> The information models are to describe what needs to be modeled in terms of
> data
> that can be specified, read, notifications, etc.
>
> The architecture and framework are about the role and functionality of i2rs
> - so a bit
> different.
>
> Alia
>
> On Thu, Jan 24, 2013 at 2:09 PM, Abdussalam Baryun <
> [e-mail]> wrote:
>
>> 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
>> >
>> >
>>
>