From nobody Thu Jan 22 15:11:23 2015 Return-Path: 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 92AF11A87A5 for ; Thu, 22 Jan 2015 14:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fkMTeu6f_LDw for ; Thu, 22 Jan 2015 14:58:13 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5B51A1B3D for ; Thu, 22 Jan 2015 14:58:13 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=156.39.127.195; From: "Susan Hares" To: Date: Thu, 22 Jan 2015 17:58:09 -0500 Message-ID: <019601d03696$e46e42d0$ad4ac870$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0197_01D0366C.FB9A5DB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA2luAxa0AWAQZjQs+cJkJKrYBdGQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Thu, 22 Jan 2015 15:11:16 -0800 Cc: adrian@olddog.co.uk, barryleiba@computer.org, 'Alia Atlas' Subject: [Ibnemo] Welcome to the IBNemo list 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 22:58:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0197_01D0366C.FB9A5DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Welcome to the IBNemo list This list is to discuss standardizing Nemo (A 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 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 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. ------=_NextPart_000_0197_01D0366C.FB9A5DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Welcome to the IBNemo list

This list is to discuss standardizing Nemo (A = 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

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

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 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.

 

 

 

------=_NextPart_000_0197_01D0366C.FB9A5DB0-- From nobody Thu Jan 22 15:38:45 2015 Return-Path: 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 ; 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 ; 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 ; 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" To: 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: Cc: caowayne@huawei.com, Yunxia Chen , Zhoutianran , Xiayinben , 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 23:38:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0217_01D03672.9D1F7300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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. ------=_NextPart_000_0217_01D03672.9D1F7300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

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 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.

 

 

 

 

------=_NextPart_000_0217_01D03672.9D1F7300--