[Ibnemo] Welcome to the IB-Nemo (Intent Based Network Modeling Language)
"Susan Hares" <shares@ndzh.com> Thu, 22 January 2015 23:38 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: ibnemo@ietfa.amsl.com
Delivered-To: ibnemo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B0F1A0039 for <ibnemo@ietfa.amsl.com>; Thu, 22 Jan 2015 15:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.155
X-Spam-Level:
X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLQeB83Uweg7 for <ibnemo@ietfa.amsl.com>; Thu, 22 Jan 2015 15:38:38 -0800 (PST)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D340F1A0029 for <ibnemo@ietf.org>; Thu, 22 Jan 2015 15:38:37 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=156.39.127.195;
From: Susan Hares <shares@ndzh.com>
To: ibnemo@ietf.org
Date: Thu, 22 Jan 2015 18:38:27 -0500
Message-ID: <021601d0369c$85f44280$91dcc780$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0217_01D03672.9D1F7300"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdA2nIJgMn6JZr6hQtOnjTG5vAmFzQ==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/ibnemo/0R7ukiUkDf6D8DVRhy_CnMxsbw4>
Cc: caowayne@huawei.com, Yunxia Chen <Helen.Chen@huawei.com>, Zhoutianran <zhoutianran@huawei.com>, Xiayinben <xiayinben@huawei.com>, jiangsheng@huawei.com
Subject: [Ibnemo] Welcome to the IB-Nemo (Intent Based Network Modeling Language)
X-BeenThere: ibnemo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." <ibnemo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ibnemo>, <mailto:ibnemo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ibnemo/>
List-Help: <mailto:ibnemo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ibnemo>, <mailto:ibnemo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jan 2015 23:38:42 -0000
Welcome to the IBNemo list This list is to discuss standardizing IB-Nemo (An Intent-Based Network Modeling Language), an intent-oriented NBI (North Bound interface) consisting of an application protocol running over HTTP (RESTful interface) to exchange intent-based primitives /commands between applications and meta-controllers controlling virtual network resources (networks, storage, CPU). Below is a description of IBNemo problem, goals, and the first steps. If you are interested to help us refine a problem statement, use cases and Nemo protocol, this list is for you. If you are interested in useable Intent-Based, IBNemo IETF work will go hand-in-hand with open source projects. We'll announce availability of code on this list. IBNemo is one of the new application protocols whose use may focus on application managing network, storage and compute resources. Expertise is needed a wide-range of IETFers - from applications, operations, storage and routing disciplines. Sue Hares ==================== The problem Nemo's trying to solve - the 80/20 rule The 80/20 rule of thumb in network application is that 80% of network applications only use 20% of the capability of a NBI. Nemo seeks to provide a simple NBI for the key 20% for intent based networks. What is Intent-Based Networking? Software Defined Networking (SDN) and Network Function Virtualization (NFV) are moving the IT world from a network-centric view to an application-centric view. Cloud computing provides virtual compute devices, storage, and networks. Intent based NBI provide applications the ability signal the "intent" (E.g. create a network between 3 applications) to the network layer rather than specify the details of the network. Intent oriented policy is prescriptive ("go to the store") rather than descriptive ("follow this route to the store"), leaving the details to the network. Network projects for SDN or NFV or ONF are experimenting with the use of intent-based policy or intent interfaces. The goal of Intent-Based Nemo mail-list discussion The Nemo-project group seeks to create a simple Intent-Based inter-operable application protocol that forms a simple NorthBound API (NB) for applications on any platform to control the following : a) setup and take down of virtual networks between virtual nodes, b) control transfer of data toward storage, and c) handle compute devices with a the minimal set of intent-based primitives. First Steps - Starting with the Network The first Nemo specifications (draft-xia-sdnrg-nemo-language, and draft-xia-sdnrg-service-description-language) describe a protocol that passes a set of intent-based primitives to between an application client and a Nemo Engine in the network layer. Through these primitives the application request the network create one or more virtual networks comprised of logical nodes with policy-controlled flows. Nemo's language uses 10 commands which include 4 basic network commands (Node, Link, Flow, Policy) and 6 basic controller communication commands (connect, disconnect, transact, commit, notify, query). Nemo sends these 10 commands using the RESTful interface over HTTP to exchange the commands with the controller. These commands operate as transactions allowing the process to have clear checkpoints. Within the controller, a Nemo-language Engine translates the Nemo intent-based commands into a set of commands to control network, storage, or CPU processes. Nemo combines Nemo Modeling information with system policy repositories, system configuration, and system status. The Nemo language processor can interface with multiple intent-based policy repositories (Open-Daylight Group Policy, OpenStack Congress API Datalog Policy) and send actions to multiple SDN controllers (E.g. OpenFlow Switch (OFS), I2RS interface) IB-Nemo Implementations and IB-Nemo Open source projects. The Nemo project group began with a few engineers building a prototype to determine if intent networking made virtual networks more effective. The intent-based paradigm has been possible for virtual WAN and DC networks, Service-chaining, and Application directed networks. These early experiences taught these early developers the value of a tight integration between open-source development and protocol standardization. The IB-Nemo protocol will be linked to an open-source development of the code. An Open-source project details, technical specifications, and details can be found at <http://www.nemo-project.net> www.nemo-project.net. Storage and Compute resources The IB-Nemo NBI/Protocol paradigm needs to be expanded to allow applications to Intent-Based allocation and use of storage and compute resources. The IB-Nemo NBI/Protocol expansion should look a small number of primitives (E.g. 10-15) that signal an applications intent to use storage or compute. The Nemo Engine in the network controller would link to appropriate policy engines to translate this intent to commands to different SDN controllers. One simple translation could be to translate the Nemo-Commands to libvirt commands to establish compute resources. Accounting on Cloud resources. Some network-related organizations (E.g. ATIS) have describe the policy that allows charging for network resources. While this charging feature is important to an Intent-Based Nemo interface, it is important to get the basic allocation functions (network, storage, compute) working first.