Brian,
Thank you for your questions. They are very thought-provoking.
First, a bit of background.
The ASSL concept and associated development environment was part of the
PhD research of Emil Vassev, who was supervised by Dr. Joey Paquet.
This work was completed in 2008.
The goals of the present work were focused on two problems: what (in
detail) is intent, and is it possible translate from "intents in
English" to "intents in some mechanically-processible form"?
With this background, we can answer the questions:
Is ASSL in active use? No, unless you count Solmaz' use of the
development environment to produce the present results.
Java seems old-fashioned. Yes, but our concern was not how to translate
from ASSL to running code. A different target is likely to be needed in
a future version of the environment. One such target would be to create
a run-time environment based on ASAs and GRASP, as standardized in the
ANIMA RFCs.
What kinds of code can be automatically generated? In the current
implementation, the only code that can be generated is Java. However,
the target model lends itself very easily to a distributed execution
model, as everything is implemented as threads. For example, the
messaging/channels/protocols are implemented as a set of queues that
imply a message passing medium, which could easily be translated to any
other real-life messaging infrastructure. Same idea for the managed
elements, fluents, metrics, etc. Each metric has its own threaded
monitor, and the fluents receive communication about events through a
mechanism akin to signals, which can also then somehow easily be
translated into a distributed model.
Did you think about automatic YANG <===> ASSL translation? No, for the
reason indicated above.
Bill Atwood
Joey Paquet
Solmaz Jaberi
On 3/23/2023 5:07 PM, Brian E Carpenter wrote:
Attention This email originates from outside the concordia.ca domain. //
Ce courriel provient de l'extérieur du domaine de concordia.ca
Hi Bill,
Interesting work. A few questions:
1) Is ASSL in active use? A quick search suggests it has been fairly
quiet in recent years.
2) Java as the target language seems distinctly old-fashioned. I quickly
found a Java to Python converter
(https://www.javainuse.com/java2py Have you considered generating Python instead - at least getting the class definitions in Python would seem useful.
3) Apart from class definitions, what sort of code can be automatically
generated?
4) Did you think about automatic YANG <==> ASSL translation?
Regards
Brian Carpenter
On 22-Mar-23 06:12, William Atwood wrote:
Dear NMRG and ANIMA people,
One of my students, Solmaz Jaberi, has explored the issue of how to map
a set of Intent Examples (written in English) into an intermediate form
that can (eventually) be interpreted by the objects (switches, routers,
hosts) in an Intent-Based Network.
RFC 9315 provides a definition of Intent, but this is too abstract to
serve as a basis for demonstrating that a particular intermediate form
can express all of the characteristics of Intent. Solmaz has therefore
formulated a list of "Intent Objectives", based on ideas from RFC 9216,
RFC 7575, and other documents.
RFC 9316 provides several Intent Classification criteria. It also
provides a rich set of Intent Examples.
Solmaz has chosen 11 of these Intent Examples, ensuring that her set of
examples covers all of the mandatory Intent Objectives, and as many of
the Intent Classes as possible.
In choosing a target intermediate form, we found only two specification
languages that permitted the expression of a wide range of Intents:
NEtwork MOdelling (NEMO), and Autonomic System Specification Language
(ASSL). The documentation for NEMO was too sparse to permit an
evaluation, so we chose to use ASSL, which was designed for the
specification and verification of autonomous systems.
Solmaz has transformed the English expression of the 11 Intent Examples
into ASSL. She has demonstrated that all of the Intent Examples can be
expressed in ASSL, in a methodical way. She has shown that ASSL can
meet almost all of the Intent Objectives.
The virtue of ASSL is that the ASSL development environment provides an
excellent validation of the semantic correctness of any specified
autonomic system (or network).
We have found that the principal problem with ASSL is that it cannot
express dynamism; this makes it impossible to model the addition or
removal of network components. A secondary problem is that the present
implementation of the ASSL compiler produces a single large Java
program, which make it impossible to distribute the generated code over
multiple real devices.
The first problem can be resolved through improvements in the design of
ASSL; the second is simply a matter of altering the compiler so that the
resulting code is generated as distributed modules. Clearly, a
candidate framework for the distributed modules is the Autonomic Service
Agents defined by the ANIMA RFCs, supplemented by GRASP as the
communication protocol.
A paper describing this work has been submitted to WIN 2023. If anyone
would like a copy of the submission (or of the full thesis), please send
me an email.
Solmaz was co-supervised by Dr. Joey Paquet.
Bill Atwood
--
Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046
Distinguished Professor Emeritus fax: +1 (514) 848-2830
Department of Computer Science
and Software Engineering
Concordia University ER 1234 email:[email protected]
1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
