idnits 2.17.1 draft-zhou-netmod-intent-nemo-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 119 has weird spacing: '...k MOdel provi...' == Line 276 has weird spacing: '...node-id yan...' == Line 379 has weird spacing: '...nant-id yan...' == Line 450 has weird spacing: '...nant-id yan...' == Line 451 has weird spacing: '...licy-id yan...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 2, 2015) is 3342 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-xia-sdnrg-nemo-language-01 == Outdated reference: A later version (-02) exists of draft-xia-sdnrg-service-description-language-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 6021 (Obsoleted by RFC 6991) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD T. Zhou 3 Internet-Draft S. Liu 4 Intended status: Standards Track Y. Xia 5 Expires: August 6, 2015 S. Jiang 6 Huawei Technologies Co., Ltd 7 February 2, 2015 9 YANG Data Models for Intent-based NEtwork MOdel 10 draft-zhou-netmod-intent-nemo-00 12 Abstract 14 This document describes a basic YANG data model for network intent. 15 The basic model can be augmented by additional YANG modules defining 16 data models for intent related protocols and functions to support 17 various network scenarios and applications. The basic network intent 18 data model provides common building blocks for extensions, such as 19 specific node and policy information. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 6, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language and Terminology . . . . . . . . . . . . 3 57 3. NEMO YANG Model Overview . . . . . . . . . . . . . . . . . . 3 58 3.1. Node Intent Module . . . . . . . . . . . . . . . . . . . 4 59 3.1.1. Design of node intent module . . . . . . . . . . . . 4 60 3.1.2. Node intent YANG module . . . . . . . . . . . . . . . 5 61 3.2. Link Intent Module . . . . . . . . . . . . . . . . . . . 6 62 3.2.1. Design of link intent module . . . . . . . . . . . . 6 63 3.2.2. Link intent YANG module . . . . . . . . . . . . . . . 7 64 3.3. Flow Intent Module . . . . . . . . . . . . . . . . . . . 8 65 3.3.1. Design of flow intent module . . . . . . . . . . . . 8 66 3.3.2. Flow intent YANG module . . . . . . . . . . . . . . . 9 67 3.4. Policy Intent Module . . . . . . . . . . . . . . . . . . 10 68 3.4.1. Design of policy intent module . . . . . . . . . . . 10 69 3.4.2. Policy intent YANG module . . . . . . . . . . . . . . 11 70 3.5. Intent Batch Module . . . . . . . . . . . . . . . . . . . 12 71 3.5.1. Design of intent batch module . . . . . . . . . . . . 13 72 3.5.2. Intent batch YANG module . . . . . . . . . . . . . . 13 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 76 7. Informative References . . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 Cloud computing and Software Defined Networking (SDN) are moving the 82 IT world from a network-centric view to an application-centric view. 83 Intent based North Bound Interface (NBI) provides applications the 84 ability signal the "intent" (E.g. create a network between 3 85 applications) to the network layer rather than specify the details of 86 the network. The network intent is prescriptive ("go to the store") 87 rather than descriptive ("follow this route to the store"), leaving 88 the details to the network implementation. 90 The NEMO specifications ([I-D.xia-sdnrg-nemo-language] and 91 [I-D.xia-sdnrg-service-description-language]) describe a set of 92 intent-based primitives to manipulate and manage virtual networks. 93 Behind the NEMO language, there is a set of basic network models 94 abstracting the network intent from the top down according to the 95 service requirement. The NEMO intent model provides consistent 96 abstraction for network services while concealing various 97 implementation techniques and multi-vendor devices. 99 This document introduces YANG [RFC6020] [RFC6021] data models for 100 network intent based on NEMO abstraction. This set of models 101 facilitates the standardization for the interface of intent 102 networking. The basic model can be augmented by additional YANG 103 modules defining data models for intent related protocols and 104 functions to support various different network scenarios and 105 applications. The basic network intent data model provides common 106 building blocks for extensions, such as specific node and policy 107 information. 109 2. Requirements Language and Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 [RFC2119] when they appear in ALL CAPS. When these words are not in 115 ALL CAPS (such as "should" or "Should"), they have their usual 116 English meanings, and are not to be interpreted as [RFC2119] key 117 words. 119 Intent-based NEtwork MOdel provides a high level description of 120 requirements to network with the abstraction from top down. It 121 conceals complexity to the network implementation but eases the 122 application invocation. 124 3. NEMO YANG Model Overview 126 The 80/20 rule of thumb in network application is that 80% of network 127 applications only use 20% of the network capability. Most of the 128 network operation is the combination of 4 basic operations: node, 129 link, flow and policy, of which the network intent comprises as shown 130 in Figure 1. 132 +---------------------------------------------+ 133 | network intent | 134 | | 135 | +------+ +-----+ +------+ +--------+ | 136 | | node | |link | | flow | | policy | | 137 | +------+ +-----+ +------+ +--------+ | 138 +---------------------------------------------+ 140 Figure 1 142 o Node operation includes creation, modification and deletion of a 143 network element (NE). 145 o Link operation is used for the connectivity among NEs. 147 o Flow operation identities the flow to be operated with flow 148 characters matching. 150 o Policy operation controls the behavior of entities (including 151 node, link and flow) following the same pattern "with , 152 to execute ". 154 3.1. Node Intent Module 156 3.1.1. Design of node intent module 158 The node intent model describes the network elements with the packet 159 processing capability. According to the functionality, various 160 specific nodes fall into three classes: 162 o The forwarding node only deals with L2/3 forwarding. 164 o The processing node provides L4-7 network services, and will 165 modify the body of packets. 167 o The logical node describes a set of network elements and their 168 links exposing properties as one entity. 170 A basic node model is shown in Figure 2. 172 module: nemo-node 173 +--rw node-def 174 +--rw tenant-id yang:uuid 175 +--rw node-id yang:uuid 176 +--rw name? string 177 +--rw type node-type 178 +--rw owner yang:uuid 179 +--rw properties 181 Figure 2 183 o tenant-id: uuid type to globally identify the tenant who owns the 184 intent. 186 o node-id: uuid type to globally identify a node instance. 188 o name: defines the name of the node instance. 190 o type: describes the specific type of the node, e.g. firewall. 192 o owner: specifies the parent logical node where this node instance 193 located. 195 o properties: can be augmented to describe various specific nodes 196 derived from the basic node model abstraction. 198 3.1.2. Node intent YANG module 200 module nemo-node{ 201 namespace "urn:TBD:params:xml:ns:yang:intent:nemo"; 202 prefix nemonode; 204 import ietf-yang-types { 205 prefix yang; 206 } 208 description "A node is used to specify one resource entity which 209 is responsable for one of the following functions: 210 forwarding, processing, logical abstraction."; 212 revision 2015-02-02{ 213 description "Initial revision"; 214 } 216 typedef node-type { 217 type string { 218 pattern "[a-zA-Z][_0-9a-zA-Z]*"; 219 } 220 } 222 container node-def{ 223 leaf tenant-id{ 224 type yang:uuid; 225 mandatory true; 226 description "Specify the tenant id who owns this node object."; 227 } 229 leaf node-id{ 230 type yang:uuid; 231 mandatory true; 232 description "Uniquely identifies node object."; 233 } 235 leaf name{ 236 type string; 237 description "name of the node object"; 238 } 239 leaf type{ 240 type node-type; 241 mandatory true; 242 description "Specifies the concrete type of the node entity 243 object, there are different properties defination 244 for different type node."; 245 } 247 leaf owner{ 248 type yang:uuid; 249 mandatory true; 250 description "Used to indicate a parent node which contains 251 this node logically."; 252 } 254 container properties{ 255 description "property name and value inforamtion for a kind of 256 node."; 257 } 258 } 259 } 261 3.2. Link Intent Module 263 3.2.1. Design of link intent module 265 The link intent model describes the connectivity between node 266 entities. The following figure shows the model abstraction. 268 module: nemo-link 269 +--rw link-def 270 +--rw tenant-id yang:uuid 271 +--rw link-id yang:uuid 272 +--rw name? string 273 +--rw type link-type 274 +--rw endnodes 275 | +--rw one-node-id yang:uuid 276 | +--rw another-node-id yang:uuid 277 +--rw properties 279 Figure 3 281 o tenant-id: uuid type to globally identify the tenant who owns the 282 intent. 284 o link-id: uuid type to globally identify a link instance. 286 o liname: defines the name of the link instance. 288 o type: describes the specific type of the link which has different 289 dedicated properties. 291 o endnodes: describes the two ends of the link. 293 o properties: can be augmented to describe various specific links 294 derived from the basic link model abstraction. 296 3.2.2. Link intent YANG module 298 module nemo-link{ 299 namespace "urn:TBD:params:xml:ns:yang:intent:nemo"; 300 prefix nemolink; 302 import ietf-yang-types { 303 prefix yang; 304 } 306 description "A link is used to specify a connection relationship 307 between two node object."; 309 revision 2015-02-02{ 310 description "Initial revision"; 311 } 313 typedef link-type { 314 type string { 315 pattern "[a-zA-Z][_0-9a-zA-Z]*"; 316 } 317 } 319 container link-def{ 320 leaf tenant-id{ 321 type yang:uuid; 322 mandatory true; 323 description "Specify the tenant id who owns the link object."; 324 } 326 leaf link-id{ 327 type yang:uuid; 328 mandatory true; 329 description "Uniquely identifies link object."; 330 } 332 leaf name{ 333 type string; 334 description "name of the link object."; 335 } 336 leaf type{ 337 type link-type; 338 mandatory true; 339 description "Specifies the concrete type of the link entity 340 object, there are different properties defination 341 for different type link"; 342 } 344 container endnodes{ 345 leaf one-node-id{ 346 type yang:uuid; 347 mandatory true; 348 description "Uniquely identifies node entity object which 349 is as the endpoint of the link."; 350 } 351 leaf another-node-id{ 352 type yang:uuid; 353 mandatory true; 354 description "Uniquely identifies node entity object which 355 is as the endpoint of the link."; 356 } 357 } 359 container properties{ 361 } 362 } 363 } 365 3.3. Flow Intent Module 367 3.3.1. Design of flow intent module 369 The flow intent model describes a sequence of packets with certain 370 common characters, such as source/destination IP address, port, and 371 protocol. From the intent perspective, flow is the special traffic 372 with user concern, which may be per device or across many devices. 373 So the flow characters also include ingress/egress node, and so on. 375 The following figure shows the model abstraction. 377 module: nemo-flow 378 +--rw flow-def 379 +--rw tenant-id yang:uuid 380 +--rw flow-id yang:uuid 381 +--rw name? string 382 +--rw match 384 Figure 4 386 o tenant-id: uuid type to globally identify the tenant who owns the 387 intent. 389 o flow-id: uuid type to globally identify a flow instance. 391 o name: defines the name of the flow instance. 393 o match: describes common characters of a flow, such as source/ 394 destination IP address, port, and protocol. It's not limited to 395 IP based packet headers, but can be augmented to describe various 396 high level match items according to the user intent. 398 3.3.2. Flow intent YANG module 399 module nemo-flow{ 400 namespace "urn:TBD:params:xml:ns:yang:intent:nemo"; 401 prefix nemoflow; 403 import ietf-yang-types { 404 prefix yang; 405 } 407 description "A flow object represents a kind of service data flow."; 409 revision 2015-02-02{ 410 description "Initial revision"; 411 } 413 container flow-def{ 414 leaf tenant-id{ 415 type yang:uuid; 416 mandatory true; 417 description "Specify the tenant id who owns the flow object."; 418 } 420 leaf flow-id{ 421 type yang:uuid; 422 mandatory true; 423 description "Uniquely identifies flow object."; 424 } 426 leaf name{ 427 type string; 428 description "name of the flow object"; 429 } 431 container match{ 432 description "Flow match items."; 433 } 434 } 435 } 437 3.4. Policy Intent Module 439 3.4.1. Design of policy intent module 441 The policy intent controls the behavior of specific entities by APP, 442 such as flow policy, node policy. All the policies follow the same 443 pattern "with , to execute ", and can be applied 444 to any entity. 446 The following figure shows the model abstraction. 448 module: nemo-policy 449 +--rw policy-def 450 +--rw tenant-id yang:uuid 451 +--rw policy-id yang:uuid 452 +--rw applyto yang:uuid 453 +--rw name? string 454 +--rw priority? uint32 455 +--rw condition 456 +--rw actions 458 Figure 5 460 o tenant-id: uuid type to globally identify the tenant who owns the 461 intent. 463 o policy-id: uuid type to globally identify a policy instance. 465 o applyto: indicates the entity to which the policy will be applied. 467 o name: defines the name of the policy instance. 469 o condition: describes the trigger condition to execute the policy. 471 o actions: describes the actions to be executed when the condition 472 meets. This item can be augmented to various specific actions to 473 describe the intent. 475 3.4.2. Policy intent YANG module 477 module nemo-policy{ 478 namespace "urn:TBD:params:xml:ns:yang:intent:nemo"; 479 prefix nemopolicy; 481 import ietf-yang-types { 482 prefix yang; 483 } 485 description "Describes network control policy."; 487 revision 2015-02-02{ 488 description "Initial revision"; 489 } 491 container policy-def{ 493 leaf tenant-id{ 494 type yang:uuid; 495 mandatory true; 496 description "Specify the tenant id who owns the policy 497 object."; 498 } 500 leaf policy-id{ 501 type yang:uuid; 502 mandatory true; 503 description "Uniquely identifies policy capability entity 504 object."; 505 } 507 leaf applyto{ 508 type yang:uuid; 509 mandatory true; 510 description "Used to indicate the entity object which will be 511 applied policy."; 512 } 514 leaf name{ 515 type string; 516 description "name of the policy object"; 517 } 519 leaf priority{ 520 type uint32; 521 mandatory false; 522 default "0"; 523 description "A priority is used to specify executive order for 524 policy."; 525 } 527 container condition{ 528 description "Used to indicate the policy condition, policy will 529 be carred out just when the expression is true."; 530 } 532 container actions{ 533 description "network control action name"; 534 } 535 } 536 } 538 3.5. Intent Batch Module 539 3.5.1. Design of intent batch module 541 In addition to submit intent one by one, intents can be submitted as 542 a batch with the combination of 4 basic intents. 544 The below figure shows how this batch is described. 546 module: nemo-intent-batch 547 +--rw tenant-id yang:uuid 548 +--rw nodes* yang:uuid 549 +--rw links* yang:uuid 550 +--rw flows* yang:uuid 551 +--rw policies* yang:uuid 552 +--rw properties 554 Figure 6 556 3.5.2. Intent batch YANG module 557 module nemo-intent-batch{ 558 namespace "urn:TBD:params:xml:ns:yang:intent:nemo"; 559 prefix nemointentbatch; 561 import ietf-yang-types { 562 prefix yang; 563 } 565 description "A intent batch consists of some nemo model object."; 567 revision 2015-02-02{ 568 description "Initial revision"; 569 } 571 leaf tenant-id{ 572 type yang:uuid; 573 mandatory true; 574 description "Specify the tenant id who owns the policy 575 object."; 576 } 578 leaf-list nodes { 579 type yang:uuid; 580 description "node entity instance list"; 581 } 583 leaf-list links { 584 type yang:uuid; 585 description "link entity instance list"; 586 } 588 leaf-list flows { 589 type yang:uuid; 590 description "flow entity instance list"; 591 } 593 leaf-list policies { 594 type yang:uuid; 595 description "policy entity instance list"; 596 } 598 container properties{ 599 description "property name and value information for the whole 600 intent service."; 601 } 602 } 604 4. Security Considerations 606 The YANG module defined in this memo is designed to be accessed via 607 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 608 secure transport layer and the mandatory-to-implement secure 609 transport is SSH [RFC6242]. The NETCONF access control model 610 [RFC6536] provides the means to restrict access for particular 611 NETCONF users to a pre-configured subset of all available NETCONF 612 protocol operations and content. 614 There are a number of data nodes defined in the YANG module which are 615 writable/creatable/deletable (i.e., config true, which is the 616 default). These data nodes may be considered sensitive or vulnerable 617 in some network environments. Write operations (e.g., ) 618 to these data nodes without proper protection can have a negative 619 effect on network operations. 621 5. IANA Considerations 623 This memo includes no request to IANA. 625 6. Acknowledgements 627 The authors would like to thanks the valuable comments made by Wei 628 Cao, Xiaofei Xu, Fuyou Miao and Wenyang Lei. 630 This document was produced using the xml2rfc tool [RFC2629]. 632 7. Informative References 634 [I-D.xia-sdnrg-nemo-language] 635 Xia, Y., Jiang, S., Zhou, T., and S. Hares, "NEMO (NEtwork 636 MOdeling) Language", draft-xia-sdnrg-nemo-language-01 637 (work in progress), October 2014. 639 [I-D.xia-sdnrg-service-description-language] 640 Xia, Y., Jiang, S., and S. Hares, "Requirements for a 641 Service Description Language and Design Considerations", 642 draft-xia-sdnrg-service-description-language-01 (work in 643 progress), October 2014. 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, March 1997. 648 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 649 June 1999. 651 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 652 Network Configuration Protocol (NETCONF)", RFC 6020, 653 October 2010. 655 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 656 October 2010. 658 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 659 Bierman, "Network Configuration Protocol (NETCONF)", RFC 660 6241, June 2011. 662 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 663 Shell (SSH)", RFC 6242, June 2011. 665 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 666 Protocol (NETCONF) Access Control Model", RFC 6536, March 667 2012. 669 Authors' Addresses 671 Tianran Zhou 672 Huawei Technologies Co., Ltd 673 Q14, Huawei Campus, No.156 Beiqing Road 674 Hai-Dian District, Beijing, 100095 675 P.R. China 677 Email: zhoutianran@huawei.com 679 Shixin Liu 680 Huawei Technologies Co., Ltd 681 Q14, Huawei Campus, No.156 Beiqing Road 682 Hai-Dian District, Beijing, 100095 683 P.R. China 685 Email: liushixin@huawei.com 687 Yinben Xia 688 Huawei Technologies Co., Ltd 689 Q14, Huawei Campus, No.156 Beiqing Road 690 Hai-Dian District, Beijing, 100095 691 P.R. China 693 Email: xiayinben@huawei.com 694 Sheng Jiang 695 Huawei Technologies Co., Ltd 696 Q14, Huawei Campus, No.156 Beiqing Road 697 Hai-Dian District, Beijing, 100095 698 P.R. China 700 Email: jiangsheng@huawei.com