One document matched: draft-hares-ibnemo-overview-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC6541 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6541.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf.xml">
<!ENTITY I-D.xia-sdnrg-service-description-language SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xia-sdnrg-service-description-language.xml">
<!ENTITY I-D.xia-sdnrg-nemo-language SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xia-sdnrg-nemo-language.xml">
<!ENTITY I-D.zhou-netmod-intent-nemo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhou-netmod-intent-nemo.xml">
<!ENTITY I-D.dunbar-i2rs-info-model-service-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-service-topo.xml">
<!ENTITY I-D.karagiannis-supa-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-karagiannis-supa-problem-statement.xml">
<!ENTITY I-D.kini-i2rs-pbr-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-pbr-im.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-ibnemo-overview-01" ipr="trust200902">
<front>
<title abbrev="IBNemo Framework">Intent-Based Nemo Overview </title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<date year="2015" />
<area>Routing Area</area>
<workgroup>IBNemo BOF</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t>
As IP networks grow more complicated, these networks require a new
interaction mechanism between customers and their networks
based on intent rather than detailed specifics.
An intent-based language is need to enable customers
to easily describe their diverse intent for network connectivity
to the network management systems. This document describes the problem
Intent-Based NEtwork Modelling (IB-NEMO) language is trying to solve,
a summary of the use cases that demonstrate this problem,
and a proposed scope of work. Part of the scope is
the validation of the language as a minimal (or reduced) subset.
</t>
<t>The IB-NEMO language consists of commands exchanged between an application
and a network manager/controller. Some would call this boundary between
the application and the network management system as northbound interface (NBI).
</t>
<t> IB-NEMO focuses on creating minimal subset of the total possible Intent-Based commands
to pass across this NBI. By creating a minimal subset (about 20% of the total possible)
of all intent commands, the IB-NEMO can be a simple Intent interface for most applications
(hopefully 80%). Part of validation of this command language is to
to provide test cases where a set of commands are used to convey
information for a use case which result in a particular data model
in the network controller.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> This document describes the problem Intent-Based Network
MOdeling (IB-NEMO) language is trying to solve,
a summary of the use cases and a proposed scope of work.
</t>
<t> IB-NEMO language is a set of commands that allows an
application to express what it wants (its intent)
for a network to the network management system (or network controller).
Some would describe the interface between the application and a network
as the north bound interface (NBI) from the network manager. This
paper will utilize that term to indicate the point the IB-NEMO
commands are exchanged across. Intent simply means the
user tells the network what the user wants, but not how to do it.
Network provisioning can then creatively fulfil the user's desire. The key
challenge is to provide the user with tools to express
what the user wants. </t>
<t>Creating a Intent-Based language with a minimal set of commands
requires boiling down the possible alternative to a minimal subset.
These minimal set of commands will be adapted to different contexts
by providing additional context. For networking, an
example of this additional context may be the name to address mapping for
the nodes an application desires to connect.
</t>
<t>
To test IB-NEMO language exchange, the working group must select
use cases and develop prototypical data models that should occur
when IB-NEMO commands are exchanged.
</t>
<section title="Where to start">
<t> In the spirit of minimalism, this introduction starts with a 5 question
FAQ (frequently asked questions) for those who are familiar with
the concepts of Intent-Based networking to answer "what is Intent-Based NEMO".
If the FAQ answers your questions, jump off to the use cases in this document
or the <xref target="I-D.xia-sdnrg-nemo-language"></xref>
along with its management yang modules
<xref target="I-D.zhou-netmod-intent-nemo"></xref>.
</t>
<t>If you are new to the Intent-Based networking, you'll want to
read through the motivation section before looking at the rest of the document.
</t>
<t> The purpose of this document is simple: to provide
others outside the project with "what, when, where,
how, and why" the IB-NEMO network language should
be standardized in the IETF as part of the larger
Intent-Based network effort. </t>
</section>
<section title="FAQ">
<t>Q1: There are many industry forums working on an
Intent-based policy interface for applications.
Why should the IETF form a Working
Group to examine an Intent-Based language?
</t>
<t>
Over the years industry forums have tried to create a
mosaic of standards groups where each standards group focuses
on it's key role. IETF has focused its efforts on protocols
that communicate across the IP network, and management
protocols to manage these efforts.
</t>
<t>
The Intent-Based Network Modelling (IB-NEMO) language
is communicated between
an application and a network management system that
controls traffic through the network. Different forums may
call this network management different names (E.g. SDN controller or
centralized controller or others).</t>
<t>
IB-NEMO seeks to provide a minimal set of commands
to express the intent from an application to the network management
system which is controlling the networks.
</t>
<t>Q2: Can Intent North Bound Interfaces (NBIs) control more than networks?
</t>
<t>A user may use Intent-based language commands
to control storage or CPU cycles, but an intent-based networking
language focuses on networks. </t>
<t>Telefonica and some of the cable operators
supporting this work want to control virtual networks,
service-based forwarding in networks or
data center networks, home-networks, and mobile networks.
If Intent based networking is successful, then the community
may turn to controlling networks plus storage plus CPU.
The group is starting with what they know.
</t>
<t>The <xref target="I-D.xia-sdnrg-nemo-language"></xref>
focuses on three basic components: logical node,
logical link, and a logical data flow.</t>
<t> Q3: Why focus on creating a minimal set of commands?
How will you control all of the network management devices that control the network? </t>
<t>IBNemo design goals are to create a
simple language with a minimal set of commands
so that most applications can easily use this interface to
establish network connections. Often most application users (say 80%)
using a language utilize only 20% of the operations.
We'll call this within this paper as the 80/20 rule of communication.
</t>
<t>The IB-NEMO commands <xref target="I-D.xia-sdnrg-nemo-language"></xref>
allows groups of applications to simplify the interface by providing the capability to
transfer a data model that can store common information (e.g. names or addresses) for
nodes and links plus rate of data flow (e.g. 10Gbit).
As an example, an application for a home-network on a cable network can simply
load one set of data from a library and pass them to the network management system.
Applications for virtual networks for a company could load a different
set of data from a library and send it to the network management system.
</t>
<t> The goal of this language is not to support all possible Intent
language commands nor all network management systems.
The intent is to work within the 80/20 rule.
</t>
<t> Open-Daylight (ODL) has three Intent-Based Code projects:
<list style="symbols">
<t>Network Intent Composition (NIC)
(https://wiki.opendaylight.org/view/Project_Proposals:Network_Intent_Composition)
(ODL:NIC), </t>
<t> Open Daylight NEMO (ODL NEMO)
https://wiki.opendaylight.org/view/NEMO:Main, and </t>
<t> Group Based Policy (ODL-GBP)
(https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)). </t>
</list></t>
<t>
The ODL-NIC project is creating a Intent based interface whose focus is to
include all necessary intent commands in the interface between the
application and the network management system. The ODL NEMO project
is creating an interface with a minimal set of intent commands.
The ODL-GBP sees Group-based policy as the automation of Intent by creating
contracts between groups of endpoints.
</t>
<t>Q4: Is it time for IETF standardization?
</t>
<t> An Open Source release of the Open Daylight code
for IB-NEMO (ODL NEMO)under the Open Daylight NEMO occurred July of 2015.
Releases from July 2015 will contain versions of the IBNemo language interface.
</t>
<t> The IB-NEMO project team is working
with the OPNFV Movie project (https://wiki.opnfv.org/movie)
to provide use cases that will allow matching the ODL code bases with the OPNFV
deployments. Much of the open source code from ODL and OPNFV open source projects
has moved into the product code bases of vendors.
</t>
<t>
Now is the time for the IETF to begin to
standardize the interoperability of the IB-NEMO commands
as the ODL Nemo code is being distributed in these open source code bases.
</t>
<t>Telefonica, BT and the DOCSIS group see this
as a key way to speed up provisioning by obtaining
their users desires via the Intent Interface.</t>
<t>Q5: What data models will IB-NEMO focus on? </t>
<t> IB-NEMO language when passed to a network management
system should fill in a set of data in a data model.
</t>
<t> IB-NEMO work standardization effort is focused on
providing a suite of test scenario for applications and
network management systems. Each test scenario
will provide the following:
<list style="symbols">
<t>a description of the test's context, </t>
<t>a set of Intent Based commands to be
sent from the application, </t>
<t>yang data model used by the network management system, </t>
<t>a set of information that should loaded
in the network management systems' data model.
</t>
</list>
The purpose is to indicate what service data models
(such as the L3VPN service data model) input
should be filled in by the IBNemo commands.
</t>
<t>IB-NEMO work is not to create the service yang data models,
but to describe how these data models might be filled in by
IB-NEMO commands.
</t>
<t>IB-NEMO work plan does not focus on being an automation
architecture or protocol. ANIMA is working on this in the IETF.
</t>
<t>
<figure>
<artwork>
context library
:
+-----------:-----+
| application |
+-------||--------+
|| http with IB-NEMO
|| commands
+----------------------------------------+
| network ............. +=======+ |
|management : NEMO : | NEMO | |
| system : Intent ===== Models| |
| : Engine : | for | |
| ......|...... |content| |
| :yang models: +=======+ |
| :services : |
+----------------------------------------+
</artwork>
</figure>
</t>
</section>
<section title="Definitions and Acronyms">
<t><list>
<t> ETSI: European Telecommunications Standards Institute </t>
<t>Intent-Based Interface: An interface which tells what
what to do (go to store) rather than how to do it.
(Travel 5 miles down this road to SAMS Club store) </t>
<t> Intent-Based interface: A intent-based command language interface consists of
commands exchanged between an application and the network management system.</t>
<t>NETCONF: The Network Configuration Protocol</t>
<t>NFV: Network Function Virtualization </t>
<t>ODL: Open Daylight project</t>
<t>ODL NIC: ODL Network Intent Composition </t>
<t>ODL NEMO - Open Daylight NEMO</t>
<t>ODL GBP: Open Daylight Group Based Policy project</t>
<t>ONF: Open Network Forum</t>
<t>RESTCONF:REST-like protocol that provides a
programmatic interface over HTTP for accessing data defined in YANG,
using the datastores defined in NETCONF. </t>
</list>
</t>
</section>
</section>
<section title="Motivation for Intent Interfaces">
<t>
The IP networks within Carriers, Data Centers, Cloud provider,
and Enterprises continue to grow in size and complexity.
Simultaneously, the services that are demanded by customers,
particularly the upper layer applications, are becoming more and
more complicated. The users of these services demand that the
services be available to mobile devices (E.g. iPADs, smart phones)
as well as their desktops. New applications that demand these services
have a short life span (months rather than years). The current rigid service
models are lacking the flexibility to meet this combination of
requirements and scenarios.
</t>
<t>
Recent efforts have looked to open source and open APIs for the
IP devices and networks as a way to replace the rigid service models
with fast-paced development. ETSI's NFV group, CableLabs DOCSIS (docsis.org),
and ONF Intent-Based NBI (North-Bound interface) are industry forums
looking at Intent based open APIs. OPNFV Movie project
(https://wiki.opnfv.org/movie) is examining the intent-based use
cases for OPNFV (https://www.opnfv.org/). The use cases
in this document encapsulate many of the use cases discussed
with operators and vendors individually or within these forums.
</t>
<t>
The idea of intent can be summed up in a simple
phrase: “Do not tell me what to do, tell me what you want”.
Traditional networking configures devices, network protocols,
and topologies within a network. It is network-device centric.
Intent-based networking focuses on what an application needs
from the network. It is application-centric.
In Intent-based networking, the network provisioning or network
automation is free to operate in any way it chooses as long as it
provides the application the requested service.
</t>
<t> Intent-based network models present the network
as the application would see it. Intent-Based NEMO utilizes
the application-centric view in its modelling of a
network. These models may hide details the application
does not need to know.
</t>
<section title="Challenges in Intent-Based NEtwork MOdeling">
<t>The challenges in Intent-Based NEMO are:
<list style="numbers">
<t> create a common definition of intent,</t>
<t> create a common architecture for an Interoperable Intent-Based Northbound API,</t>
<t> create a standard and interoperable command language the applications
can use communicate with the network management systems, and </t>
<t>create a way to reduce the complexity that the context
places on the intent engine.</t>
</list>
</t>
<t>The ODL projects, the Distributed Management Task Force (DMTF - www.dmtf.org),
Open Networking Foundation (ONF) Intent-Based Northbound interface(NBI) working group
(ONF Intent NBI WG) (https://www.opennetworking.org/technical-communities/areas/services/1916-northbound-interfaces),
and OpenStack Congress (https://wiki.openstack.org/wiki/Congress)
are working on definitions of Intent.
</t>
<t>ONF Intent NBI WG (http://www.onfsdninterfaces.org/)
and ODL-NIC project are working on common architecture principles
for the Intent-Based Northbound API (https://wiki.opendaylight.org/view/Network_Intent_Composition:Main)
with work to define application end points
(https://wiki.opendaylight.org/view/Network_Intent_Composition:Dynamic_Attributes).
</t>
<t>IB-NEMO seeks to simply apply this evolving work by creating an interoperable
set of commands that application uses to communicate with the network management
system (or network controller). The IB-NEMO language interface seeks to
reduces the number of commands from a full-set of commands in order
by supporting a portion of the commands most often used for key use cases.
</t>
<t> The people on the ODL NEMO project (https://wiki.opendaylight.org/view/NEMO:Main)
have selected a small set of commands and created an open-source prototype.
The IETF work is to review and standardize the set of commands to make sure it provides an
interoperable set for all applications.
</t>
</section>
<section title="Roles and User specific network information">
<t>Authentication, Authorization and Accounting (AAA) protocols such as
Diameter and Radius pass information on the access permissions that
certain users or user programs have to a network or virtual network.
Group based policy suggests that a group of users may share a role
which is associated with a set of policies that determines
the access to the network or a virtual network.
Role-based network access suggests that roles can better summarize what
access the user or user programs have to the network. Since IB-NEMO is
trying to use prototypical use cases to test the ability of the IB-NEMO
command language to create the appropriate data models
in the network management system, it is natural to use the role-based
concepts of summarize these data models.
</t>
<t> The contextual information is the characteristics which make groups of
applications unique when operating over the network. Logically most
of this information may be associated with roles. For example, if you have
a set of users in a home communicating over a home network the
characteristics which are unique is a set names and address for devices, links, and
policy within the home. If it is a virtual network for a company,
the unique information is the names, addresses, links, and bandwidth expected on
the links along with security issues. As these examples demonstrate,
an intent language contains the intent plus contextual information.
</t>
</section>
<section title="What is a simple Intent-Based Protocol?">
<t> What is a simple interface? It is said that 80% of the applications
only use 20% of the commands in any API. This paper calls this the
80/20 rule of networking. A simple Intent-based command language should only supports
these 20% of commands that all applications will need to exchange information
with the network management system. Of course, the challenge in any
simply interface is to select the 20% of commands that are being repeated
used by applications.
</t>
<t>It is also important these commands be similar to a human being's
natural language for
easy debugging.
</t>
<t> The challenge is that different industries may have a different
20% of commands that are commonly used. The NEMO Project teams
in the ODL NEMO project and OPNFV Movie project are seeking
uses cases to determine if there is common set of use cases
that vary just by context. For example,
a global L3VPN for a company with three sites may be similar to a three
site L3VPN across a cable network.
</t>
<t>After getting a set of uses cases, creating a simple interface
is a four step repetitive process:
<list style="numbers">
<t>find use cases, </t>
<t>develop prototype code, </t>
<t>do early testing at proof of concept demonstrations
and hack-a-thons</t>
<t>work with many vendors to clarify language
to make the language small and interoperable, and </t>
<t>go back to step 1 </t>
</list>
</t>
<t> Where is NEMO is this process? </t>
<t> IB-NEMO has gone through steps 1-3. Use cases are listed below,
and the OPNFV project is working on use cases. IB-NEMO's ODL NEMO
project is developing the code for the open source (ETA July release).
IB-NEMO is at a stage where it needs to work in a standards body to create
a small, efficient, interoperable set of commands. </t>
<t>The standardization through an IETF WG will help IB-NEMO to work on
step 4. </t>
</section>
<section title="Intent-Based NBI Open Source is heading toward Products">
<t> The following are Open Daylight Projects:
<list>
<t> Open Daylight Group Based Policy (GBP)
https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)
</t>
<t>OpenDaylight Network Intent Composition (ODL-NIC)
(https://wiki.opendaylight.org/view/Project_Proposals:Network_Intent_Composition),
and </t>
<t> Open Daylight Network Intent Composition: NEMO
https://wiki.opendaylight.org/view/NEMO:Main.</t>
</list>
</t>
<t>
These are open-source coding efforts creating an intent-based northbound interface
for intent-based networking.
</t>
<t> The ODL Group Based Policy (GBP) views policy as a contract between
two endpoints, and sees its work as the automation of Intent. </t>
<t>
ODL-GBP was released in the ODL Lithium release in June of 2015.
</t>
<t>
The ODL-NIC project is creating a Northbound interface (NBI) for
network orchestration systems, SDN applications, and Network operators.
It may be defined as RESTCONF <xref target="I-D.ietf-netconf-restconf"></xref> protocol
and/or Java APIs. This extensible interface will be designed to allow any and
all new intent expressions to be exposed as part of a consistent and integrated
single NBI to SDN applications. The singularity is necessary for the Composition
Function to provide a comprehensive capability to manage network resources and
resolve conflicts across application’s intents. In a sense, the ODL-NIC
project is suggesting a thin waist of a single API at the entrance to the networking layer,
just as the IP protocol presents a thin waist of a single API at network layer.
</t>
<t>ODL NIC project was released in June of 2015. </t>
<t>The ODL NEMO project has created a language with minimal
operational commands. The ODL NEMO command language has 15 operational commands in
three groups. Group 1 describes nodes, links, and flows between nodes. Group 2
deals with operational checks (query, notification, policy, connect, disconnect,
session (start), and commit (end of commands). Group 3 defines the model that provides
the context for nodes, links, flows and policy.
</t>
<t> ODL NEMO project first release in ODL was in July, 2015. </t>
<t> ODL open source code is currently finding its way rapidly into
other sources (E.g. OPNFV code base) and into products that are within 6 months
to a year of release.
</t>
</section>
<section title="IB-NEMO Intent NBI is Synergistic to NETCONF and I2RS ">
<t>
The IETF NETCONF <xref target="RFC6541"></xref> and
RESTCONF <xref target="I-D.ietf-netconf-restconf"></xref> protocols
provide a network interface to the configuration and status information
within IP network devices. The IETF I2RS (Interface to Routing System)
WG is creating a highly dynamic network
interface to the routing system which can inject or retrieve state
regarding routing state, topologies, filters, and
operational state. The PCE Working Group has protocols and methods to pass
routing for calculation. Each of these interfaces and protocols have a
purpose in managing and enhancing IP network infrastructures.
</t>
<t>Intent Based NBI is synergistic to these IETF protocols to the devices.
Synergistic means that sum of Intent Based NEMO commands + NETCONF + RESTCONF +
I2RS + PCE is more than any of the parts alone. Intent Based NEMO command can
signals the application's intent to a network management system which configures,
manages, and monitors network devices through NETCONF, RESTCONF or I2RS protocol. </t>
</section>
<section title="Rest of Document">
<t>Based on this motivation, the next sections discuss:
<list style="symbols">
<t> The Scope should the Intent-Based NBI work</t>
<t> Summary of Use cases for this scope </t>
<t> Gap Analysis and where IB-NEMO fits </t>
<t> Transition from IRTF to IETF </t>
</list></t>
</section>
</section>
<section title="Scope">
<section title="In-Scope">
<t> The initial scope of this IB-NEMO work has focused on:
<list style="numbers">
<t>creating a minimal set of language commands to express intent from
the application to the network management device, </t>
<t> selecting use cases and associating them with prototype applications in
order to determine the subset of commands that needs to be included in IB-NEMO language,
</t>
<t> validating the IB-NEMO language by creating data models (which should exist
in the network management system) for each application use case to
determine if the language can help a network
management system create the right data model </t>
<t> creating a yang data model to manage this Intent-Based
Networking language, and </t>
<t> working with other forums to refine a definition of intent
so that the minimal size language serves a wide range of
use cases (target of 80% of known use cases) with an interoperable
interface. </t>
</list>
</t>
</section>
<section title="Out-of-Scope">
<t> The following things are outside the IB-NEMO scope:
<list style="symbols">
<t> creating yang data models that describe service layers </t>
<t> The creation of a language to communicate from a security network management system to
the network security devices is outside this scope. (Work denoted as I2NSF)
</t>
</list> </t>
</section>
</section>
<section title="Use cases for Intent-Based IB-NEMO">
<t> The following use cases are described in this section:
<list style="numbers">
<t>Virtual WAN</t>
<t>Virtual Data Center </t>
<t>Bandwidth on Demand</t>
<t>Service Chaining</t>
</list>
</t>
<section title="Virtual Wide-Area Network (WAN)">
<t>Description: Enterprises want to set up their own virtual
WAN for more control and optimization.
</t>
<t>User Intent: Create virtual Wide-Area network between offices.</t>
<t>Network management systems do the following:
<list style="numbers">
<t>Deploy virtual routers and links for a customized topology.
</t>
<t>Identify flows.</t>
<t>Steer the traffic flows though different paths.
(E.g. real-time flow to go through a shortest path,
and backup flow to go though a broadband path but may have more hops.)
</t>
</list>
The network management system should have
a data model that captures this information.
IB-NEMO commands are used by the application to pass the user's
intent to set-up connections, the locations, and the type of flows.
</t>
<t>Network operator: Creates web portal for business
customers to request a WAN connecting offices.
Interface request corporate ID, security ID, and a link
to the payment system.</t>
<t>
The sub-cases of this general use are the following.
<list>
<t>Home LAN attached to Corporate Network</t>
<t>parental controls for child travelling outside the home</t>
</list> </t>
<t>Details can be found in (draft-hares-nemo-usecases-00.txt)</t>
<t>
<figure>
<artwork>
==== real time (R1-)
**** broadband
....................
: Virtual LAN :
: (real time path) :
: :
+-------+ : (real time path) : +---------+
| =========================== |
| | : e f : | |
|Beijing|-----R1- - - - - R2---| London |
|office | ***a|* \b c / | d : | office |
+-------+ : | * \ / |****>+---------+
: | * \ / |* :
: | / \* |* :
: | / \* |* :
: | / \*|* :
: R4- - - - R3 :
....................
Figure 5-1:
</artwork>
</figure>
</t>
</section>
<section title="Virtual Data Center">
<t>Description: User (corporate or home)
creates a virtual data center
with network. The virtual data center
has a front-end network of
router to exterior firewall to DMZ LAN to
interior firewall to computing user.</t>
<t>User Intent: A Corporation wants to buy Cloud computing inside
a virtual data center with secure computer cluster.
</t>
<t>Network Service Provider: Sales person
of the provider is given a reduced group of
well-known building blocks (DMZ, protected area, unprotected area)
and that he/she uses these blocks to compose
different kinds of vDC infrastructures for the client.
The sales person has an App on a PAD device that
shows a cloud for the internet and the different building blocks
(Exterior, DMZ, interior) and the user builds vDCs with these building blocks. </t>
<t> The application the sales person is running
queries the network management system
using IB-NEMO commands on existing model components
with the potential vDC functions.
The application expresses the user's desires/intent
via IB-NEMO commands
to the network management system. </t>
<t>Operator automation: Based on the
context with Intent, corporate context,
secure vDC context, the operator automation
series will place the virtual cluster in
a data center, and set-up the vDC and the
Cloud computer clusters. The Corporate
customer IDs that are pushing data to this
vDC will have the vDC defined in the
Corporate culture.
</t>
<t> Specific use cases from this prototypical use case are:
<list style="symbols">
<t>User gets clean mail services with firewall and spam mail cleaner</t>
<t>SMB Manufacturing network with Virtual DataCenter </t>
<t>SMB with Sales-Marketing accounting on Virtual Data Center</t>
</list> </t>
<t> These are described in (draft-hares-nemo-usecases-00.txt)</t>
<t>
<figure>
<artwork>
[The user simply builds this as building blocks on
the application.]
(internet )
|
..........|...................
+-----|------+
| router |
+-----|------+
|
+-----|------+
| firewall |
| exterior |
+-----|------+
|
===============
DMZ |
+-----|-------+
| firewall |
| interior |
+-----|-------+
|
( protected )
( cloud )
Figure 5-2
</artwork>
</figure>
</t>
</section>
<section title="Bandwidth on Demand">
<t>Description: The corporate user wants
to create a virtual link between remote
offices and headquarters that has
bandwidth that can be adjusted based
on time of day. </t>
<t>User Intent:Corporation wants
to connect branch office with
corporate office with 10G of bandwidth for data flow
8am to 6pm, and 1G of bandwidth from 6pm to 8am.
</t>
<t> User interface: A web portal allows him to
login (corporate ID and security IDs) and
indicate this intent
via a graphic picture of his network that allows
him to indicate on-demand bandwidth size and time of day.
</t>
<t>Network Operator:Creates Web portal
for business customers to put in request
with corporate ID and level of security for
entrance into the corporate intent site.
The Web portal allows for prototypical use
case (virtual WAN, Virtual DC, Bandwidth-on-demand
Virtual Private Network (VPN), Service Function
Chaining (SFC). The network operators store
enough application-level topology that the
the users intent is defined.
</t>
<t>Operator automation: Based on the
IB-NEMO queries and commands, the
application will pass the User's Intent to the
the provisioning software which will automatically
allocate bandwidth between
these two sites at the rate indicated.
The access router/switch can optionally
limit at a rate over this value.</t>
<t>Corporate Virtual Data Center information:
includes the IP address, DNS names,
and application addresses (Transport Ports,
application identifiers) of subnet with
application works on, and the applications
transferring data. The corporate data also includes
information on whether L2VPN or
L3VPN is used by the customer.
</t>
<t>
<figure>
<artwork>
==== 8am to 6pm 10GB
**** 6pm to 8am 1BG
....................
: VPN :
: :
+-------+ : daytime : +---------+
| =========================== |
| | : e f : | |
|Branch |-----R1- - - - - R2---| HQ |
|office | ***a|* \b c / | d : | site |
+-------+ : | * \ / |****>+---------+
: | * \ / |* :
: | / \* |* :
: | / \* |* night time
: | / \*|* :
: R4- - - - R3 :
....................
Figure 5-3:
</artwork>
</figure>
</t>
<t>The following use cases are specific examples
of this prototype use case:
<list>
<t>Home Network gaming system </t>
<t>Home Security system zoom-in </t>
<t>Application Big Data or SAP Transfers at night</t>
<t>Database applications contact other database applications</t>
</list>
</t>
</section>
<section title="Service Chaining">
<t>Description: Apply several virtual network functions,
such as firewall, load balancer, WAN optimization between
virtual private cloud and the internet. </t>
<t>User Intent: User has a private cloud
and wants to get a secure interface to the Internet.
</t>
<t>Network Operator network management system
defines the secure access ring of protection around
the private cloud to be
the following virtual network topology:
<list style="symbols">
<t>firewall</t>
<t>load balance</t>
<t> DPI inspection</t>
</list></t>
<t>Network Operator: Has Web portal or Phone App
for business customers to put in request
with corporate ID and level.
</t>
<t>Corporate Information: Corporate context
has the topology of private cloud, and
the access points. The network operator
will access service chaining to through a
virtual access ring.
</t>
<t>Operator automation: Based on the
context of the network topology of
the private cloud's link to the carrier network
and the access points to service chains,
the network automation sets up the traffic flow
so that the traffic to and from the private cloud
flows through a firewall, load balancer, and
DPI inspection. </t>
<t>
<figure>
<artwork>
(internet )
|
..........|...................
+-----|------+
| firewall |
|--| function |--------|
| +-----|------+ |
| | |
| +-----|---------+ |
| | load balancer | |
| | function | |
| +-----|-------|-+ |
| | | |
| +---|-+ +---|--+ |
+----|DPI 1| |DPI 2 |----+
+---|-+ +---|--+
| |
( private Cloud )
( for corporation )
Figure 5-4
</artwork>
</figure>
</t>
<t> The specific use cases for this prototype are:
<list>
<t>Providers access edge box replaced by service chaining for wired and wireless
(LTE and Wifi)</t>
<t>Corporate access edge box replaced by service chaining for wired and wireless </t>
<t>Wifi offload of LTE does service chaining to replace mobile services </t>
</list></t>
</section>
</section>
<section title="Gap Analysis and where IB-NEMO Fits ">
<section title="IETF Working groups Gap Analysis">
<t>No working group is working on an Intent-Based commands.</t>
<t>SUPA proposes to create an information model for
event-condition-action based policy.</t>
<t>NETCONF and NETMOD are not creating an intent-based
interface.</t>
</section>
<section title="ODL Open-Source">
<t>ODL network intent composition (ODL-NIC) is creating
a full intent-based North Bound Interface. ODL NEMO is creating
a set of commands with a minimal set of operations as of the open source project.
The IETF IB-NEMO work will leverage the lessons learned from the
ODL NEMO open source work to create a minimal subset. </t>
<t>OPNFV Movie project (https://wiki.opnfv.org/movie) is defining the use
cases for Intent-Based networking for OPNFV.
IETF IB-NEMO will expand on these use cases for non-OPNFV scenarios in
Cable Networks (MSO).
</t>
</section>
<section title="Open Stack Policy initiatives">
<t> None of the Open Stack Congress work focuses on intent-based command language. </t>
<t> Open Stacks policy includes network, compute, and storage. Its work combines
automation (scheduling of resources, monitoring cloud services, Event-Condition-Action (ECA)
policy, ECA based management), store-related policy, and meta-data policy storage. The
projects are:
<list>
<t>OpenStack has Congress (https://wiki.openstack.org/wiki/Congress) with its
Congress initiative which aims to provide an extensible
open-source framework for governance and regulatory compliance across
any cloud services (e.g. application, network, compute and storage) within a dynamic infrastructure.</t>
<t> SolverScheduler (Nova blueprint): The SolverScheduler
provides an interface for using different constraint solvers to solve placement problems for Nova.
Depending on how it is applied, it could be used for initial provisioning, re-balancing loads, or both.
</t>
<t> Gantt: A scheduler framework for use by different OpenStack components.
Used to be a subgroup of Nova and focused on scheduling VMs based on resource utilization.
Includes plugin framework for making arbitrary metrics available to the scheduler. </t>
<t> Neutron policy group: This group aims to add a policy API to Neutron,
where tenants express policy between groups of networks and ports.
Policy statements are of the form "for every network flow between groups A and B that
satisfies these conditions, apply a constraint on that flow". Constraints are currently
allow or deny, but this may expand. </t>
<t> Open Attestation: This project provides an SDK for verifying host integrity.
It provides some policy-based management capabilities, though documentation is limited.
</t>
<t> Policy-based Scheduling Module (Nova blueprint): This effort aims to schedule Nova resources
per client, per cluster of resources, and per context (e.g. overload, time, etc.). </t>
<t> Tetris: This effort provides condition-action policies (Event-Condition-Action policy).
It is intended to be a generic condition-action engine handling complex actions and optimization. This effort subsumes the Runtime Policies blueprint within Nova. It also appears to subsume the Neat effort.
Tetris and Congress have recently decided to merge because of their highly aligned goals and approaches.
</t>
<t> Convergence Engine (Heat): This effort separates the ideas of desired state and observed state
for the objects Heat manages. The Convergence Engine will detect when the desired state and observed
state differ and take action to eliminate those differences. </t>
<t> Swift Storage Policies: A Swift storage policy describes a virtual storage system that Swift
implements with physical devices. Today each policy dictates how many partitions the storage
system has, how many replicas of each object it should maintain, and the minimum amount of time
before a partition can be moved to a different physical location since the last time it was moved. </t>
<t>Graffiti: Graffiti aims to store and query (hierarchical) meta-data about OpenStack
objects, e.g. tagging a Glance image with the software installed on that image.
Currently, the team is working within other OpenStack projects to add user interfaces
for people to create and query meta-data and to store that meta-data within the project's database.
This project is about creating meta-data, which could be useful for writing business policies,
not about policies over that meta-data. </t>
</list>
</t>
</section>
</section>
<section title="From Open Source and IRTF to IETF ">
<t>As discussed above, the open-source work for ODL-NIC was first released in June, 2015, and
ODL NEMO released its code in July of 2015. The movement of
these code sources to OPNFV (https://www.opnfv.org/) will happen rapidly, aided by the
OPNFV Movie project (https://wiki.opnfv.org/movie) use case work.
In order to get a command language with minimal number of operations that application vendors
and network management devices agree upon, it is important to standardize the
command language in IETF.
</t>
<t> Initial concepts for IB-NEMO have been presented in IRTF's NFVrg and SDNrg to
obtain initial review. </t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft includes no request to IANA.</t>
</section>
<section title="Security Considerations">
<t>The security in a Intent-Based interface may require that
most Intent-Based Networking operate across a secure transport security
with encryption. However, some use cases (in-home only) or some limited
data may allow an unsecured transport.
</t>
</section>
</middle>
<back>
<references title="Informative References">
&RFC6541;
&I-D.ietf-netconf-restconf;
&I-D.xia-sdnrg-nemo-language;
&I-D.xia-sdnrg-service-description-language;
&I-D.zhou-netmod-intent-nemo;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:07:52 |