[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Research Task Force                                K. Sivakumar
Internet-Draft                                           M. Chandramouli
Intended status: Informational                       Cisco Systems, Inc.
Expires: May 1, 2018                                    October 28, 2017

                       Concepts of Network Intent


   This document presents an overview of the concepts of Network Intent
   and provides definitions for some of the nomenclature.  Some
   potential use cases are presented.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 1, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Sivakumar & Chandramouli   Expires May 1, 2018                  [Page 1]

Internet-Draft         Concepts of Network Intent           October 2017

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Hierarchy of Manageability  . . . . . . . . . . . . . . . . .   4
   4.  Network Configuration . . . . . . . . . . . . . . . . . . . .   4
   5.  Network Policy  . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Network Intent  . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  A simple example  . . . . . . . . . . . . . . . . . . . .   7
     7.2.  Disaster Management . . . . . . . . . . . . . . . . . . .   7
   8.  Issues with Intent based networking . . . . . . . . . . . . .   8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Recently, there have been deployments of networks of Service
   Provider, enterprise and data centres in a very large scale.  From a
   network management perspective, the manageability of networks of such
   scale poses new challenges.  The increasing complexity of network
   configuration is an additional challenge for the network
   administrators.  To an extent, for device-level configurations, there
   has been standardization efforts underway in technologies such as
   YANG [RFC6020], and NETCONF [RFC6241].  However, the challenge still
   remains at the network level configuration, orchestration and
   management.  The complexity of the network can lead to potential mis-
   configurations and furthermore, it may be difficult to troubleshoot
   the network failure conditions.

   From a management perspective, it is of paramount importance for the
   network administrator to reduce the complexity of the network
   management.  There are several measures and approaches that have been
   under consideration towards that objective.  One aspect that has
   gained attention is Network Programmability APIs in the management
   plane.  Programmability allows the capabilities of network
   functionality to be modified or extended.  Programmability promises
   to enable the development of a whole new wave of applications that
   provide additional management intelligence.  Programmability enables
   the development of applications whose purpose is to make the networks
   easier to manage, and those applications can be embedded and tightly
   coupled with the network.  The application developers can use the
   Network Programmability APIs that can allow them to add new features
   that can facilitate ease of network management, efficiency and the

Sivakumar & Chandramouli   Expires May 1, 2018                  [Page 2]

Internet-Draft         Concepts of Network Intent           October 2017

   effectiveness with which the network can be provisioned,
   administrated and managed.  Programmability, as provided through SDN,
   provides exciting new opportunities to increase manageability by
   facilitating the development of corresponding applications.  Software
   defined networking (SDN) is an umbrella term for a programmatic
   approach to managing network devices, using software controls to
   replace manual configuration.  Initial motivations for SDN were to
   overcome the the lack of network programmability, and manageability
   in networks.

   SDN technologies allow network-wide visibility and the possibility of
   feedback actions across the network.  The desire to implement higher
   layers of management abstraction such as policy-based management, or
   the desire to extend an application's capabilities with application-
   specific pre-processing that can be delegated to the network.

   Leveraging the Network Programmability APIs opens the possibility to
   introduce an abstraction for the network, which can be used to
   synthesise the overall system behaviour.  In the networking parlance,
   there have been several concepts that have been have been considered
   to simplify the network management - Network Policy, Autonomic
   Networking, Service Models, and Network Configuration.  We introduce
   the concept of Intent Based Networking, by which the network
   administrator can articulate a desired outcome to the network.  The
   Network Intent is translated to appropriate network policies and/or
   network configurations.  With this approach to Network Intent, the
   focus is more on "what" the network should do and less on "how" i.e.,
   the intermediate steps that should be executed.  This level of
   abstraction can be referred to as "Network Intent".  The implicit
   assumption is that for "Network Intent" there might be some
   prerequisite steps that may need to be performed, such as the network
   elements are discovered and controlled, and device capabilities and
   features are identified.

   While there has been investigations of Network Intent, there are some
   still ambiguities in terms of the terminology used.  This initial
   proposal is an attempt to clarify some of the terms and provides a
   brief outline of the goals or the vision intended.  Some use cases
   are presented to illustrate the concepts introduced in this document.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Sivakumar & Chandramouli   Expires May 1, 2018                  [Page 3]

Internet-Draft         Concepts of Network Intent           October 2017

3.  Hierarchy of Manageability

   There is a certain non-physical, logical hierarchy in a network
   management environment, as described in the figure below.  The user
   at the top of the hierarchy can be represented by a "real" user or a
   system that performs actions on behalf of a user, such as a
   management station.

   The "user" establishes an "intent" to be taken on the network as a
   whole and pushes that intent to the second layer of the management
   hierarchy, which consists of the intent engine.

   The next layer of the hierarchy consumes the "intent" and translates
   the intent to desired actions based on the meaning of the intent.

   The bottom layer of the hierarchy consists of the devices on the
   network that consume the configurations and actions issued to them by
   the intent engine.  These devices sit directly on the network and are
   responsible for traffic flowing through the network.

                            |  user   |
                                 | Intent  API
                          +------+-------+             +------+-------+
                          |  SDN         |             |              |
                          +              +-------------+Intent Engine +
                          |  Controller  |             |              |
                          +------+-------+             +------+-------+
                                 | Instruct
                                 | network
              |                  |                  |
         +----+----+        +----+----+        +----+----+
         | Device  |        | Device  |        |  Device |
         +---------+        +---------+        +---------+

                                 Figure 1

4.  Network Configuration

   Network configurations are the most basic atomic operations that can
   be performed on a network device.  A particular feature of the
   network software can be enabled by one or many lines of network

Sivakumar & Chandramouli   Expires May 1, 2018                  [Page 4]

Internet-Draft         Concepts of Network Intent           October 2017

   configurations.  Often the network devices are configured by experts
   with _domain expertise_ and based on the functionality the network
   device has to perform.  Often, network configuration is performed on
   a device by device basis and this is a manual process.  Automation of
   this process is very important step, which can save time and reduce
   the possible number of mis-configurations.

5.  Network Policy

   Policy based network management has been widely discussed in the
   literature [JNSM].  Several proposals for the semantics and structure
   for expressing network policy have been considered.  There are some
   particular implementations and deployments of network policies such
   as Performance Forwarding, QoS profiles etc.

   A network policy can be viewed as a set of rules a network administer
   can use to manage the network resources; for example to provide
   differential treatment for traffic.  Policies can be at a network
   level and can provide a way of consistently managing multiple network
   devices.  The administrator can define policies and specify how the
   network devices should deal with different types of traffic.
   Policies can be defined to be conditional, in the sense, if there is
   a condition A is observed, then a set a network policy can be
   implemented on some network devices.  Policies can be a group of
   network configurations which perform a specific function that can be
   applied to network devices.  In the SDN paradigm, network policies
   can be pushed to the network devices using NETCONF [RFC6020] and
   RESTCONF [RFC8040].

6.  Network Intent

   Network Intent can be considered as a declarative paradigm by which
   the network administrator articulates a desited outcome or the state
   of the network.  In abstraction, the network enables a set of
   services that can be consumed.  In particular, Network Intent is a
   desirable functionality that can be enabled from an SDN Controller.
   There are potential benefits of ease-of-use and operational
   simplicity and the capability of programming the entire network.

   Network Intent need not be prescriptive or expressed explicitly in
   terms of specific actions.  The following are the intended design
   considerations of network intent.

   o  First, there may be several alternative approaches to realise a
      specific Network Intent.

Sivakumar & Chandramouli   Expires May 1, 2018                  [Page 5]

Internet-Draft         Concepts of Network Intent           October 2017

   o  Second, it is conceivable that it may not be possible to realise
      some of the Network Intents due to non-availability of network
      resources or the network may not have functionality.

   o  Third, some new Network Intent can be in conflict with the current
      state of the network or can disrupt the Network Intents expressed
      previously.  It is assumed such a feedback regarding the conflicts
      is provided back to the administrator the originator of the
      Network Intent.  Based on the feedback, it should be possible for
      the network administrator to refine the new Network Intent.

   This proposal or definition of Network Intent can be viewed as
   analogous to the promise theory framework proposed [Promise].  In
   order to realise the Network Intent, it may be useful consider a
   logical functional block - the Intent Engine - that can resolve the
   network intent and render the Network Intent appropriately on to the

   The simplistic method to realise network intent is to consider linear
   one-to-one mapping of Network Intents to actual network policies or
   network configurations.  In a more general framework of Network
   Intent, it should be possible to consider a more general approach
   leveraging artificial intelligence based techniques so that the
   Network Intent can be accurately realised and appropriately rendered
   on the network.  Translating the intent requests to rendering actions
   would require the modelling of network devices and the
   functionalities and configurations.

   In order to realise a Network Intent eventually that should consist
   of network configuration blocks that can be implemented in one or
   more network devices.

   There is a general confusion between policy based network management
   and intent based network management.  An analogy can be drawn between
   intent based network management and the automotive industry.  Though
   cliched, this analogy provides the closest match.  Many cars, if not
   all, have cruise control as a function today.  Cruise control is a
   very simplistic functionality that keeps the car going at a specific
   speed.  It monitors the speed and adjusts it up or down.  This can be
   considered as a policy, to keep the car driving at certain speed,
   until the operator disengages the policy manually.

   An car that can handle intent would, on the other hand, accept a
   request such as "take me from San Francisco to Los Angeles within 6
   hours," plot the appropriate path based on historical data on which
   roads are the best ones to take to achieve the constraint of reaching
   within 6 hours and plots the direction to go in.  Then it would
   constantly monitor the traffic on the path and provide feedback to

Sivakumar & Chandramouli   Expires May 1, 2018                  [Page 6]

Internet-Draft         Concepts of Network Intent           October 2017

   the operator about whether the path chosen will still achieve the
   constraint.  If the constraint cannot be achieved, then it either re-
   plots the path or lets the operator know that the constraint cannot
   be achieved and requests a new constraint.  The operator is removed
   from making the decision about which exact path to take and is
   instead just providing the constraints that need to be achieved.

7.  Use Cases

   This section lists certain use cases that showcase the value of
   intent based network management.  There are a variety of use cases
   where intent based network management is of value but the highest
   value is present in scenarios where a network needs to be
   reprogrammed in a significant manner in the shortest of time frames.
   Such a network reconfiguration should not result in misconfiguration
   that could result in the loss of communication capabilities for the
   users of the network.

   We provide two scenarios where such a reconfiguration of the network
   is required.  There are obviously many more day-to-day scenarios
   where the intent of change or monitoring of a network can be of a
   much lower scale.

7.1.  A simple example

   The network administrator articulates the Network Intent, "Route
   traffic from Node A to Node B with minimum bandwidth of K mbps".  The
   Intent Engine then resolves the intent.  This step involves
   understanding the intent expressed and the second step to resolving
   that intent would require performing routing calculations between
   Node A and Node B.  This is a key step involved in this proposal.

   Once the intent has been resolved, routing calculations are well-
   known and there are standard techniques taking into account the
   network topology between Node A and Node B; the current utilisations
   with minimum guaranteed bandwidth of K Mbps between Node A and Node
   B.  Once the path is determined, that routing and next hop
   configurations are communicated to the respective network nodes.

7.2.  Disaster Management

   Planning for disaster management and sudden reconfiguration of
   infrastructure is common in the "physical" world - ie roads, water
   supply, electricity, etc.  Similar reconfigurations of communication
   networks also is important during a disaster.  During a disaster
   management / recovery, it is important to ensure that emergency
   communication traffic (such as 911 in the USA, 999 in UK and similar
   in other countries) gets more bandwidth and resources than non-

Sivakumar & Chandramouli   Expires May 1, 2018                  [Page 7]

Internet-Draft         Concepts of Network Intent           October 2017

   emergency communication.  It is also important to allow people to
   communicate with their family members inside and outside the disaster
   area, to help in recovery efforts.  For this reason, voice
   communication, including VoIP, should be prioritized over streaming
   video services.

   Such a disaster management is geographically bounded, therefore the
   network changes need to also be appropriately geographically bounded.
   This is very often hard to apply manually in a very large network at
   the moment that the change is needed.  Intent based networks can
   provide an abstraction that use the underlying knowledge of the
   network and policies to achieve an action to provide this ability in
   a finer grained manner.

   As the disaster scenario subsides the applied intent should
   automatically subside as well.  This requires not only action to be
   taken based on policies, but also requires constant monitoring of the
   operational state network.  Such monitoring presents significant
   amounts of data and it is quite hard to build rules and conditions to
   operate on such data while minimizing mistakes.  Machine learning
   based monitoring can provide a mechanism to make applying an intent
   easier, especially in very large networks.  Such machine learning
   based mechanisms can be integrated with physical world monitoring to
   identify when a disaster hits a certain geography and to
   automatically trigger a pre-set intent for that scenario.  With such
   machine learning mechanisms and multiple pre-set intents, it would be
   possible for a management system to automatically trigger a specific
   intent when it detects a particular scenario.  Similar combination of
   operational monitoring and intent based networking mechanism can be
   used to withdraw an intent when the disaster like scenario recedes.

8.  Issues with Intent based networking

   Intent based network management is about creating an abstraction to
   handle the management of a network.  Naturally issues related to any
   abstraction mechanism applies here as well.  Specifically, an
   abstraction like this removes the direct interaction of a user with
   the network for operations management.  While the original creators
   of this intent, and the associated policies, would have understood
   the reasoning behind this intent, and more importantly the fine
   distinction between when to apply and when NOT to apply such an
   intent, later users of the system may not have that clear distinction
   and may apply this intent needlessly.  This problem exists in any
   abstraction mechanism.

Sivakumar & Chandramouli   Expires May 1, 2018                  [Page 8]

Internet-Draft         Concepts of Network Intent           October 2017

9.  Security Considerations

   This draft currently does not impose any security considerations.

10.  IANA Considerations

   This memo has no actions for IANA.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,

11.2.  Informative References

   [JNSM]     Boutaba, R. and I. Aib, "Policy-Based Management: A
              Historical perspective, Journal of Network and Systems
              Management 15 (4), 447-480", 2007.

   [Promise]  Borril, P., Burgess, M., Craw, T., and M. Dvorkin, "A
              Promise Theory Perspective on Data Networks, CoRR,
              abs/1405.2627", September 2014.

Authors' Addresses

Sivakumar & Chandramouli   Expires May 1, 2018                  [Page 9]

Internet-Draft         Concepts of Network Intent           October 2017

   Kaarthik Sivakumar
   Cisco Systems, Inc.
   Sarjapur Outer Ring Road
   Bangalore  560103

   Phone: +91 80 4429 2264
   Email: kasivaku@cisco.com
   URI:   http://www.cisco.com/

   Mouli Chandramouli
   Cisco Systems, Inc.
   Sarjapur Outer Ring Road
   Bangalore  560103

   Phone: +91 80 4429 2409
   Email: moulchan@cisco.com
   URI:   http://www.cisco.com/

Sivakumar & Chandramouli   Expires May 1, 2018                 [Page 10]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/