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 , to execute ". 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 , to execute ", 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., ) 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]