Subject: [I2nsf] Intent-Based Language DSL for Virtual Networks

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 06:49:54 -0500

To following up on John, Bob and Diego comments on an Intent Based Service
API, there is an Intent based Service API called Nemo with running demo
code, and an OPNFV project that is putting this code in open-source.  An
Intent API is possible.  See the description below, 

Sue 

------------

I2NSF group: 

An intent based security looks to signal intent rather than the full
descriptive language.  IMHO there is an 80/20 rule for intent based
languages where 80% of the applications will use 20% of the commands. Intent
based application fit the customer based interfaces this list has discussed.
A Domain specific language (DSL) provides a language that focuses on
providing those for the user.  A more extensive general language can provide
the 20% of highly functional use cases.  An example of a Domain Specific use
case for virtual networks Is Intent-Based Nemo (ibnemo) found at: 

 http://tools.ietf.org/html/draft-xia-sdnrg-nemo-language-01

It has 3 types of commands (Entity, Capability, and model definition). 

.         Entities in virtual networks are nodes, links and data flows.  

.         Capabilities involve Policy, Query (of values), notification
(publication) and stream handling (Commit/withdraw (policies) and
Connect/disconnect interface).   

.         Model definition includes the definition of: Nodes, links, and
actions within policies. 

The Entities in Nemo are application level network entities.  

The Intent-Based Nemo API operates across a RESTful interface where the
commands are sent across. The application sends the simple commands across
the service interface to a controller.  Within the controller the Nemo
Engine translates the Nemo language to the Controller commands (E.g. I2RS
commands or OpenFlow commands).  

Nemo's code is currently a project proposal in OPNFV and the code has been
demoed at BAR BOFs at IETF91.  Flashes of the demo can be downloaded from at
www.nemo-project.net.  It is a project at
<https://wiki.opnfv.org/requirements_projects/nemo>
https://wiki.opnfv.org/requirements_projects/nemo.  

  What does this mean for I2SNF?  

Diego's description of the customer in draft-pastor-i2nsf-access-usecases-00
is a description of a minimal subset of interfaces.   The same capabilities
may be possible for I2NSF by simply added the key word Tenant, and providing
network security actions.  Let me give two examples for a single home node,
but this could be a group of nodes

.         Tenant my_son 

.         Node  home_router 

.         Node Biz-router1

.         Node biz-router2

.         Policy internet-policy Appliesto home_router Tenant my_son
condition {time 8:30 to 20:00} action forwardto Internet action scan 

.         Policy corporate Appliesto home_routers Tenant: father condition
corporate traffic action gothrough biz-router1 action
privacy-confidentiality 

.         Policy corporate Appliesto home_routers Tenant: mother condition
corporate traffic action gothrough biz-router2

.         Policy basic-parental-control Applies to home_router Tenant my son
condition time 0:00-24:00 action gothrough parental-filters

.         Policy school-filter-controls applies to home_router Tenant my_son
condition time 07:00-18:00 action gothrough school-filters 

.         Policy email-filters applies to home_router Condition goesthrough
{home_router}  action {Scan malware} 

.         Policy facebook applies to home_router Condition forwardto
{facebook} Action {remove tracking}

A sequence of these commands could be entered as a transaction with
transaction. commands commit. The query commands can query tenant, node,
policy.  

the language (except the Tenant addition) is at: 

(http://tools.ietf.org/html/draft-xia-sdnrg-nemo-language-01

I believe that the simple example of the tenant string above may provide
expanded into the following 

 <tenant> <initiator_group> <service_group> <action><track> <condition>