Re: [i2rs] format for information models

Nikolay Milovanov <n.milovanov@gmail.com> Thu, 24 January 2013 23:01 UTC

Return-Path: <n.milovanov@gmail.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6AB21F853D for <i2rs@ietfa.amsl.com>; Thu, 24 Jan 2013 15:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fw27oRqh8wp for <i2rs@ietfa.amsl.com>; Thu, 24 Jan 2013 15:01:52 -0800 (PST)
Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by ietfa.amsl.com (Postfix) with ESMTP id ADEBF21F84D7 for <i2rs@ietf.org>; Thu, 24 Jan 2013 15:01:47 -0800 (PST)
Received: by mail-bk0-f53.google.com with SMTP id j10so593988bkw.12 for <i2rs@ietf.org>; Thu, 24 Jan 2013 15:01:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=R6IyVifY9K07DeEfw0Kj/fDecTCYVsga6D2YOj6Uxec=; b=wzKjYnbV4r9w5lhY4ba1qaFJkCz1SknwwZmRUDlUhdKnyF0Pdj5Obj19qGEo0gXj5y 5YEjPhtfIZkK1T9lhbCel9W6C37rl4F2ooClsNAcF/pfQDnuZTAfw653R+rjud2LriZr DZ75tZG2/RmV0VgY7XCN+ihqtLcvFqNrSVjwGZkuGvdkCZX+n4vFiGlfQhb5x5IWcL45 9TgLFVbMxn+/gmnrF+wRwt9atwvMBb+by+HAanV0X0lBS1kVzjEdnSfDWFZcmnMLRPIP Td1oip/SebFzfteeDX8DTgVCOi+Ij2/K+UxNruWCkIE0hVAQBRx2wuMK1iKtpBppQ1Tf pvHA==
X-Received: by 10.204.148.145 with SMTP id p17mr1303987bkv.136.1359068506490; Thu, 24 Jan 2013 15:01:46 -0800 (PST)
Received: from [192.168.2.34] ([93.155.231.113]) by mx.google.com with ESMTPS id ho6sm2776411bkc.0.2013.01.24.15.01.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 15:01:44 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E8E50F76-C0A2-42A7-BBF4-F0C3C1734795"
From: Nikolay Milovanov <n.milovanov@gmail.com>
In-Reply-To: <CAG4d1rcKVsRg_bmbL0kZk=oVdZF7jrc8dCC-BTY7w9mBpAVVpw@mail.gmail.com>
Date: Fri, 25 Jan 2013 01:02:17 +0200
Message-Id: <16EC14A1-7738-4892-925E-0AEB06C19D1B@gmail.com>
References: <CAG4d1rfi7xYdje_XVR+93gkkMUh6rb9hNSf7qPKARHo3Rz_ZUg@mail.gmail.com> <00ab01cdfa32$7e73a7b0$7b5af710$@olddog.co.uk> <20130124160050.GA53459@elstar.local> <CAG4d1rd3r_OeX70d2LSomEjpcqfu+GW220NHBy1KWda4VPcAUg@mail.gmail.com> <20130124162607.GA53528@elstar.local> <CACKN6JFnXwbXZg-pv-kgjUmuuS5S0hYdtDsu=Aw120nNxZrvGw@mail.gmail.com> <AD046ED7-0C72-4EBA-9E95-AD3DDBF29E08@gmail.com> <CAG4d1rcKVsRg_bmbL0kZk=oVdZF7jrc8dCC-BTY7w9mBpAVVpw@mail.gmail.com>
To: Alia Atlas <akatlas@gmail.com>
X-Mailer: Apple Mail (2.1283)
Cc: i2rs@ietf.org
Subject: Re: [i2rs] format for information models
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/i2rs>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jan 2013 23:01:52 -0000

Hi Alia, 

Regarding the abstraction and formality. I guess when somebody defines an architecture of something in general one of the difficulties is to determine the level of abstraction. Regarding formality it is good but comes on a price. Usually that price is complexity. 

In my initial post I have used incorrectly the term AML. It is better to change it with Architecture Description Languages (ADLs). So some time ago I was exposed to an ADL called ACME. 
ACME is a language and a also a tool defined by prof. David Garlan (and by his Phd students) from CMU. I guess this is one of the initial publications regarding ACME. http://www.cs.cmu.edu/afs/cs/project/able/ftp/acme-fcbs/acme-fcbs.pdf

So ACME allows you to define a component and connector models of different systems.  It was done for defining software architecture not for defining network architecture. However one of the good definitions of Software Architecture is "A software architecture of computing system is the set of structures needed to reason about the system, which comprise elements, relationships among them and properties of both" [*Documenting Software Architecture: Views and Beyond, 2nd Ed. Clements et al. 2010.] To me this sounds like a network isn't it... 

As a visiting faculty member in CMU I spent some months with David's group and start wondering where are the differences between Network and Software Architecture and can't we (I still consider myself more of a network engineer than a software one) use also languages as ACME. What I found in particular interesting is the fact that  ADLs allows you to create a style. A good definition of a style is "An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style."  

This sounds fancy but in fact an architectural style in software is the same as in building architecture. When you see certain building somehow in your mind comes that this follows that style. For example when you see Guggenheim museum in New york and some other building of Frank Lloyd Wright you will instantly recognize the style. 
As a good reading on those I consider Roy T. Fielding dissertation. http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm  

In ACME the style is expressed as a family. The family allows you to instantiate a number of similar systems that comply to the style e.g comply with constrains.

So having those in my head and reading the initial discussions on i2rs I wondered won't something like this be useful also here. For example we might put some models in the framework but also to define certain constrains on how it should be used and implemented. 

Just to finish for ACME I did a relatively simple model of a 3 host network (2 end hosts and a router). To highlight the approach I also defined a simple family. My system complies to my family. 

I have attached the sources. The constraints are expressed as rules in IPfamily. Attached is also a screenshot from ACME.  




Finally as PROS:
I would say that it is formal. It allows integration between the information model and constraints. It is good for dynamic perspective of the systems (e.g systems or network that are up and running). In particular I liked the idea behind the styles and constraints.  

As a CONS:
Information/data model relates more to a static perspective/view of the system/network and a YANG or UML class diagram will be better. Also from UML or YANG might be easier to generate an exact data model. An example is TM-FORUM SID model used widely in OSS/BSS industry [http://www.tmforum.org/InformationFramework/1684/home.html]. 
I would say that it is definitely not popular among networking society. 
It is not that easy to get used to it and get it working. In fact software society is using much more UML which is considered as semi-formal. 
However I guess despite that  ACME  is not common for regular developers but it has influenced many scientists including people such a Roy Fiedling and the people that has invented UML. 


Nikolay   

PS: Congrats for the i2rs  working group initiation!  

On Jan 24, 2013, at 9:42 PM, Alia Atlas wrote:

> Hi Nikolay,
> 
> I wouldn't describe the difference between an IM and a DM as simply formality, but also details and potentially
> abstraction layer.
> 
> It sounds like you have a few different ideas from YANG and UML.  Can you write-up something giving more
> insight into the pros & cons of each?  And pointers to them so we can learn more independently.
> 
> I don't think we are trying for behavior modeling here.  Nor do I think we're looking for excessive formality,
> but something that can be less ambiguously understood and easily turned into a data-model (or derived from
> one as has been suggested) and is consistent would be good.
> 
> Alia
> 
> On Thu, Jan 24, 2013 at 2:00 PM, Nikolay Milovanov <n.milovanov@gmail.com> 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 
> n.milovanov@gmail.com 
> 
> 
> 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 <j.schoenwaelder@jacobs-university.de> 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
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>> 
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
> 
>