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

Versions: 00

NETMOD                                                           T. Zhou
Internet-Draft                                                    S. Liu
Intended status: Standards Track                                  Y. Xia
Expires: August 6, 2015                                         S. Jiang
                                            Huawei Technologies Co., Ltd
                                                        February 2, 2015


            YANG Data Models for Intent-based NEtwork MOdel
                    draft-zhou-netmod-intent-nemo-00

Abstract

   This document describes a basic YANG data model for network intent.
   The basic model can be augmented by additional YANG modules defining
   data models for intent related protocols and functions to support
   various network scenarios and applications.  The basic network intent
   data model provides common building blocks for extensions, such as
   specific node and policy information.

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 http://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 August 6, 2015.

Copyright Notice

   Copyright (c) 2015 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
   (http://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



Zhou, et al.             Expires August 6, 2015                 [Page 1]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language and Terminology . . . . . . . . . . . .   3
   3.  NEMO YANG Model Overview  . . . . . . . . . . . . . . . . . .   3
     3.1.  Node Intent Module  . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Design of node intent module  . . . . . . . . . . . .   4
       3.1.2.  Node intent YANG module . . . . . . . . . . . . . . .   5
     3.2.  Link Intent Module  . . . . . . . . . . . . . . . . . . .   6
       3.2.1.  Design of link intent module  . . . . . . . . . . . .   6
       3.2.2.  Link intent YANG module . . . . . . . . . . . . . . .   7
     3.3.  Flow Intent Module  . . . . . . . . . . . . . . . . . . .   8
       3.3.1.  Design of flow intent module  . . . . . . . . . . . .   8
       3.3.2.  Flow intent YANG module . . . . . . . . . . . . . . .   9
     3.4.  Policy Intent Module  . . . . . . . . . . . . . . . . . .  10
       3.4.1.  Design of policy intent module  . . . . . . . . . . .  10
       3.4.2.  Policy intent YANG module . . . . . . . . . . . . . .  11
     3.5.  Intent Batch Module . . . . . . . . . . . . . . . . . . .  12
       3.5.1.  Design of intent batch module . . . . . . . . . . . .  13
       3.5.2.  Intent batch YANG module  . . . . . . . . . . . . . .  13
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   Cloud computing and Software Defined Networking (SDN) are moving the
   IT world from a network-centric view to an application-centric view.
   Intent based North Bound Interface (NBI) provides 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.  The network intent is prescriptive ("go to the store")
   rather than descriptive ("follow this route to the store"), leaving
   the details to the network implementation.

   The NEMO specifications ([I-D.xia-sdnrg-nemo-language] and
   [I-D.xia-sdnrg-service-description-language]) describe a set of
   intent-based primitives to manipulate and manage virtual networks.
   Behind the NEMO language, there is a set of basic network models
   abstracting the network intent from the top down according to the
   service requirement.  The NEMO intent model provides consistent




Zhou, et al.             Expires August 6, 2015                 [Page 2]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


   abstraction for network services while concealing various
   implementation techniques and multi-vendor devices.

   This document introduces YANG [RFC6020] [RFC6021] data models for
   network intent based on NEMO abstraction.  This set of models
   facilitates the standardization for the interface of intent
   networking.  The basic model can be augmented by additional YANG
   modules defining data models for intent related protocols and
   functions to support various different network scenarios and
   applications.  The basic network intent data model provides common
   building blocks for extensions, such as specific node and policy
   information.

2.  Requirements Language and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] when they appear in ALL CAPS.  When these words are not in
   ALL CAPS (such as "should" or "Should"), they have their usual
   English meanings, and are not to be interpreted as [RFC2119] key
   words.

   Intent-based NEtwork MOdel  provides a high level description of
        requirements to network with the abstraction from top down.  It
        conceals complexity to the network implementation but eases the
        application invocation.

3.  NEMO YANG Model Overview

   The 80/20 rule of thumb in network application is that 80% of network
   applications only use 20% of the network capability.  Most of the
   network operation is the combination of 4 basic operations: node,
   link, flow and policy, of which the network intent comprises as shown
   in Figure 1.

     +---------------------------------------------+
     |              network intent                 |
     |                                             |
     | +------+  +-----+   +------+    +--------+  |
     | | node |  |link |   | flow |    | policy |  |
     | +------+  +-----+   +------+    +--------+  |
     +---------------------------------------------+

                                 Figure 1

   o  Node operation includes creation, modification and deletion of a
      network element (NE).



Zhou, et al.             Expires August 6, 2015                 [Page 3]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


   o  Link operation is used for the connectivity among NEs.

   o  Flow operation identities the flow to be operated with flow
      characters matching.

   o  Policy operation controls the behavior of entities (including
      node, link and flow) following the same pattern "with <condition>,
      to execute <action>".

3.1.  Node Intent Module

3.1.1.  Design of node intent module

   The node intent model describes the network elements with the packet
   processing capability.  According to the functionality, various
   specific nodes fall into three classes:

   o  The forwarding node only deals with L2/3 forwarding.

   o  The processing node provides L4-7 network services, and will
      modify the body of packets.

   o  The logical node describes a set of network elements and their
      links exposing properties as one entity.

   A basic node model is shown in Figure 2.

   module: nemo-node
      +--rw node-def
         +--rw tenant-id     yang:uuid
         +--rw node-id       yang:uuid
         +--rw name?         string
         +--rw type          node-type
         +--rw owner         yang:uuid
         +--rw properties

                                 Figure 2

   o  tenant-id: uuid type to globally identify the tenant who owns the
      intent.

   o  node-id: uuid type to globally identify a node instance.

   o  name: defines the name of the node instance.

   o  type: describes the specific type of the node, e.g.  firewall.





Zhou, et al.             Expires August 6, 2015                 [Page 4]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


   o  owner: specifies the parent logical node where this node instance
      located.

   o  properties: can be augmented to describe various specific nodes
      derived from the basic node model abstraction.

3.1.2.  Node intent YANG module

module nemo-node{
   namespace "urn:TBD:params:xml:ns:yang:intent:nemo";
   prefix nemonode;

   import ietf-yang-types {
      prefix yang;
   }

   description "A node is used to specify one resource entity which
                is responsable for one of the following functions:
                forwarding, processing, logical abstraction.";

   revision 2015-02-02{
      description "Initial revision";
   }

   typedef node-type {
      type string {
         pattern "[a-zA-Z][_0-9a-zA-Z]*";
      }
   }

   container node-def{
      leaf tenant-id{
         type yang:uuid;
         mandatory true;
         description "Specify the tenant id who owns this node object.";
      }

      leaf node-id{
         type yang:uuid;
         mandatory true;
         description "Uniquely identifies node object.";
      }

      leaf name{
         type string;
         description "name of the node object";
      }




Zhou, et al.             Expires August 6, 2015                 [Page 5]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


      leaf type{
         type node-type;
         mandatory true;
         description "Specifies the concrete type of the node entity
                      object, there are different properties defination
                      for different type node.";
      }

      leaf owner{
         type yang:uuid;
         mandatory true;
         description "Used to indicate a parent node which contains
                      this node logically.";
      }

      container properties{
         description "property name and value inforamtion for a kind of
                      node.";
      }
   }
}

3.2.  Link Intent Module

3.2.1.  Design of link intent module

   The link intent model describes the connectivity between node
   entities.  The following figure shows the model abstraction.

   module: nemo-link
      +--rw link-def
         +--rw tenant-id     yang:uuid
         +--rw link-id       yang:uuid
         +--rw name?         string
         +--rw type          link-type
         +--rw endnodes
         |  +--rw one-node-id        yang:uuid
         |  +--rw another-node-id    yang:uuid
         +--rw properties

                                 Figure 3

   o  tenant-id: uuid type to globally identify the tenant who owns the
      intent.

   o  link-id: uuid type to globally identify a link instance.

   o  liname: defines the name of the link instance.



Zhou, et al.             Expires August 6, 2015                 [Page 6]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


   o  type: describes the specific type of the link which has different
      dedicated properties.

   o  endnodes: describes the two ends of the link.

   o  properties: can be augmented to describe various specific links
      derived from the basic link model abstraction.

3.2.2.  Link intent YANG module

 module nemo-link{
    namespace "urn:TBD:params:xml:ns:yang:intent:nemo";
    prefix nemolink;

    import ietf-yang-types {
       prefix yang;
    }

    description "A link is used to specify a connection relationship
                 between two node object.";

    revision 2015-02-02{
       description "Initial revision";
    }

    typedef link-type {
       type string {
          pattern "[a-zA-Z][_0-9a-zA-Z]*";
       }
    }

    container link-def{
       leaf tenant-id{
          type yang:uuid;
          mandatory true;
          description "Specify the tenant id who owns the link object.";
       }

       leaf link-id{
          type yang:uuid;
          mandatory true;
          description "Uniquely identifies link object.";
       }

       leaf name{
          type string;
          description "name of the link object.";
       }



Zhou, et al.             Expires August 6, 2015                 [Page 7]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


       leaf type{
          type link-type;
          mandatory true;
          description "Specifies the concrete type of the link entity
                       object, there are different properties defination
                       for different type link";
       }

       container endnodes{
          leaf one-node-id{
             type yang:uuid;
             mandatory true;
             description "Uniquely identifies node entity object which
                          is as the endpoint of the link.";
          }
          leaf another-node-id{
             type yang:uuid;
             mandatory true;
             description "Uniquely identifies node entity object which
                          is as the endpoint of the link.";
          }
       }

       container properties{

       }
    }
 }

3.3.  Flow Intent Module

3.3.1.  Design of flow intent module

   The flow intent model describes a sequence of packets with certain
   common characters, such as source/destination IP address, port, and
   protocol.  From the intent perspective, flow is the special traffic
   with user concern, which may be per device or across many devices.
   So the flow characters also include ingress/egress node, and so on.

   The following figure shows the model abstraction.











Zhou, et al.             Expires August 6, 2015                 [Page 8]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


   module: nemo-flow
      +--rw flow-def
         +--rw tenant-id    yang:uuid
         +--rw flow-id     yang:uuid
         +--rw name?      string
         +--rw match

                                 Figure 4

   o  tenant-id: uuid type to globally identify the tenant who owns the
      intent.

   o  flow-id: uuid type to globally identify a flow instance.

   o  name: defines the name of the flow instance.

   o  match: describes common characters of a flow, such as source/
      destination IP address, port, and protocol.  It's not limited to
      IP based packet headers, but can be augmented to describe various
      high level match items according to the user intent.

3.3.2.  Flow intent YANG module





























Zhou, et al.             Expires August 6, 2015                 [Page 9]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


 module nemo-flow{
    namespace "urn:TBD:params:xml:ns:yang:intent:nemo";
    prefix nemoflow;

    import ietf-yang-types {
       prefix yang;
    }

    description "A flow object represents a kind of service data flow.";

    revision 2015-02-02{
       description "Initial revision";
    }

    container flow-def{
       leaf tenant-id{
          type yang:uuid;
          mandatory true;
          description "Specify the tenant id who owns the flow object.";
       }

       leaf flow-id{
          type yang:uuid;
          mandatory true;
          description "Uniquely identifies flow object.";
       }

       leaf name{
          type string;
          description "name of the flow object";
       }

       container match{
          description "Flow match items.";
       }
    }
 }

3.4.  Policy Intent Module

3.4.1.  Design of policy intent module

   The policy intent controls the behavior of specific entities by APP,
   such as flow policy, node policy.  All the policies follow the same
   pattern "with <condition>, to execute <action>", and can be applied
   to any entity.

   The following figure shows the model abstraction.



Zhou, et al.             Expires August 6, 2015                [Page 10]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


   module: nemo-policy
      +--rw policy-def
         +--rw tenant-id    yang:uuid
         +--rw policy-id    yang:uuid
         +--rw applyto      yang:uuid
         +--rw name?        string
         +--rw priority?    uint32
         +--rw condition
         +--rw actions

                                 Figure 5

   o  tenant-id: uuid type to globally identify the tenant who owns the
      intent.

   o  policy-id: uuid type to globally identify a policy instance.

   o  applyto: indicates the entity to which the policy will be applied.

   o  name: defines the name of the policy instance.

   o  condition: describes the trigger condition to execute the policy.

   o  actions: describes the actions to be executed when the condition
      meets.  This item can be augmented to various specific actions to
      describe the intent.

3.4.2.  Policy intent YANG module

module nemo-policy{
   namespace "urn:TBD:params:xml:ns:yang:intent:nemo";
   prefix nemopolicy;

   import ietf-yang-types {
      prefix yang;
   }

   description "Describes network control policy.";

   revision 2015-02-02{
      description "Initial revision";
   }

   container policy-def{

      leaf tenant-id{
         type yang:uuid;
         mandatory true;



Zhou, et al.             Expires August 6, 2015                [Page 11]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


         description "Specify the tenant id who owns the policy
                      object.";
      }

      leaf policy-id{
         type yang:uuid;
         mandatory true;
         description "Uniquely identifies policy capability entity
                      object.";
      }

      leaf applyto{
         type yang:uuid;
         mandatory true;
         description "Used to indicate the entity object which will be
                      applied policy.";
      }

      leaf name{
         type string;
         description "name of the policy object";
      }

      leaf priority{
         type uint32;
         mandatory false;
         default "0";
         description "A priority is used to specify executive order for
                      policy.";
      }

      container condition{
         description "Used to indicate the policy condition, policy will
                      be carred out just when the expression is true.";
      }

      container actions{
         description "network control action name";
      }
   }
}

3.5.  Intent Batch Module








Zhou, et al.             Expires August 6, 2015                [Page 12]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


3.5.1.  Design of intent batch module

   In addition to submit intent one by one, intents can be submitted as
   a batch with the combination of 4 basic intents.

   The below figure shows how this batch is described.

   module: nemo-intent-batch
      +--rw tenant-id     yang:uuid
      +--rw nodes*        yang:uuid
      +--rw links*        yang:uuid
      +--rw flows*        yang:uuid
      +--rw policies*     yang:uuid
      +--rw properties

                                 Figure 6

3.5.2.  Intent batch YANG module

































Zhou, et al.             Expires August 6, 2015                [Page 13]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


 module nemo-intent-batch{
    namespace "urn:TBD:params:xml:ns:yang:intent:nemo";
       prefix nemointentbatch;

       import ietf-yang-types {
          prefix yang;
       }

       description "A intent batch consists of some nemo model object.";

       revision 2015-02-02{
          description "Initial revision";
       }

       leaf tenant-id{
          type yang:uuid;
          mandatory true;
          description "Specify the tenant id who owns the policy
                       object.";
       }

       leaf-list nodes {
          type yang:uuid;
          description "node entity instance list";
       }

       leaf-list links {
          type yang:uuid;
          description "link entity instance list";
       }

       leaf-list flows {
          type yang:uuid;
          description "flow entity instance list";
       }

       leaf-list policies {
          type yang:uuid;
          description "policy entity instance list";
       }

       container properties{
          description "property name and value information for the whole
                       intent service.";
       }
 }





Zhou, et al.             Expires August 6, 2015                [Page 14]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


4.  Security Considerations

   The YANG module defined in this memo is designed to be accessed via
   the NETCONF protocol [RFC6241].  The lowest NETCONF layer is the
   secure transport layer and the mandatory-to-implement secure
   transport is SSH [RFC6242].  The NETCONF access control model
   [RFC6536] provides the means to restrict access for particular
   NETCONF users to a pre-configured subset of all available NETCONF
   protocol operations and content.

   There are a number of data nodes defined in the YANG module which are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., <edit-config>)
   to these data nodes without proper protection can have a negative
   effect on network operations.

5.  IANA Considerations

   This memo includes no request to IANA.

6.  Acknowledgements

   The authors would like to thanks the valuable comments made by Wei
   Cao, Xiaofei Xu, Fuyou Miao and Wenyang Lei.

   This document was produced using the xml2rfc tool [RFC2629].

7.  Informative References

   [I-D.xia-sdnrg-nemo-language]
              Xia, Y., Jiang, S., Zhou, T., and S. Hares, "NEMO (NEtwork
              MOdeling) Language", draft-xia-sdnrg-nemo-language-01
              (work in progress), October 2014.

   [I-D.xia-sdnrg-service-description-language]
              Xia, Y., Jiang, S., and S. Hares, "Requirements for a
              Service Description Language and Design Considerations",
              draft-xia-sdnrg-service-description-language-01 (work in
              progress), October 2014.

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

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.





Zhou, et al.             Expires August 6, 2015                [Page 15]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


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

   [RFC6021]  Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
              October 2010.

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

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, June 2011.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536, March
              2012.

Authors' Addresses

   Tianran Zhou
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: zhoutianran@huawei.com


   Shixin Liu
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: liushixin@huawei.com


   Yinben Xia
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: xiayinben@huawei.com






Zhou, et al.             Expires August 6, 2015                [Page 16]


Internet-Draft  YANG Model for Intent-based NEtwork MOdel  February 2015


   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: jiangsheng@huawei.com












































Zhou, et al.             Expires August 6, 2015                [Page 17]


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