idnits 2.17.00 (12 Aug 2021) /tmp/idnits4275/draft-bw-supa-declarative-policy-data-model-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 447 has weird spacing: '...ment-id condi...' == Line 473 has weird spacing: '...ment-id const...' == Line 519 has weird spacing: '...w value int...' == Line 520 has weird spacing: '...w order uin...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 9, 2015) is 2348 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-03 -- 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: 1 error (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUPA T. Zhou 3 Internet-Draft Y. Xia 4 Intended status: Standards Track Huawei Technologies Co., Ltd 5 Expires: June 11, 2016 B. Wijnen, Ed. 6 Consultant 7 December 9, 2015 9 A YANG Data Model for Declarative Policy 10 draft-bw-supa-declarative-policy-data-model-00 12 Abstract 14 This document describes a base YANG data model for declarative 15 policies that can be used within the SUPA (Simplified Use of Policy 16 Abstractions) framework. The base model can be augmented by 17 additional YANG modules defining data models for intent related 18 policies and functions to support various network scenarios and 19 applications. The base declarative policy data model provides common 20 building blocks for extensions. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 11, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language and Terminology . . . . . . . . . . . . 3 58 3. Design of The Declarative Policy Module . . . . . . . . . . . 3 59 3.1. Design of The Operation . . . . . . . . . . . . . . . . . 5 60 3.2. Design of The Result . . . . . . . . . . . . . . . . . . 7 61 4. Declarative Policy Base YANG Data Model . . . . . . . . . . . 9 62 4.1. Declarative Policy Data Model Hierarchy . . . . . . . . . 9 63 4.2. Declarative Policy Base Data Model in YANG Module . . . . 12 64 5. Declarative Policy Data Model Examples . . . . . . . . . . . 31 65 5.1. Link utilization optimization . . . . . . . . . . . . . . 31 66 5.2. Policy Based Bandwidth on Demand . . . . . . . . . . . . 32 67 5.3. Service function chaining . . . . . . . . . . . . . . . . 33 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 71 9. Informative References . . . . . . . . . . . . . . . . . . . 34 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 74 1. Introduction 76 Cloud computing and Software Defined Networking (SDN) are moving the 77 IT world from a network-centric view to an application-centric view. 78 Intent based North Bound Interface (NBI) provides applications the 79 ability signal the "intent" (E.g. create a network between 3 80 applications) to the network layer rather than specify the details of 81 the network. The network intent is declarative ("go to the store") 82 rather than imperative ("follow this route to the store"), leaving 83 the details to the network implementation. 85 In the SUPA proposition [I-D.klyus-supa-proposition], the declarative 86 policy is introdued as a higher level abstraction for service 87 management. The NEMO language specifications 88 [I-D.xia-sdnrg-nemo-language] describe a set of declarative 89 primitives to manipulate and manage virtual networks, where the 90 declarative policy model is a very import part. The declarative 91 policy base model is also the shared part that can be used in working 92 groups within IETF and also in other organizations. It provides a 93 consistent abstraction for a higher level policy based network 94 management system while concealing various implementation techniques 95 and multi-vendor devices. 97 This document introduces YANG [RFC6020][RFC6021]data models for the 98 declarative policy. This set of models facilitates the 99 standardization for a more abstracted policy configuration interface 100 for SUPA. The basic model can be augmented by additional YANG 101 modules defining data models for intent related protocols and 102 functions to support various different network scenarios and 103 applications. The base declarative policy data model provides common 104 building blocks for extensions, such as specific operation and 105 result. 107 2. Requirements Language and Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in 112 [RFC2119] when they appear in ALL CAPS. When these words are not in 113 ALL CAPS (such as "should" or "Should"), they have their usual 114 English meanings, and are not to be interpreted as [RFC2119] key 115 words. 117 3. Design of The Declarative Policy Module 119 Declarative policies that can apply to services and/or resources 120 describe what to do, but not how to do it. This section gives an 121 overview of the declarative policy module as shown in Figure 1 123 Similar to other kinds of policies [I-D.chen-supa-eca-data-model], 124 there will be a policy header which contains general policy 125 information such as: 127 o policy-id: is the globally unique identifier for a policy 128 instance. 130 o policy-name: is an easy to recognize and refer sting for policy 131 instance naming. 133 o policy-priority: indicates the priority of the policy instance. 134 Higher priority policy instance will get the prior order to 135 execute. 137 o policy-validity-period: controls the life cycle of the policy 138 instance with the start/end time or period. 140 o policy-rule-deploy-status: describes the deployment status of the 141 policy rule. 143 o policy-rule-exec-status: describes the execution status of the 144 policy rule. 146 The declarative policy expression need to contain a target-object, 147 such as a VPN, a flow, a link and so on, to which the policy instance 148 will apply. The target-object also defines the governance scope of 149 the policy application. The target-object is a data model definition 150 to be provided by other WGs in a separate module and is not part of 151 the declarative policy module itself. For example, in the policy, 152 guarantee the the utilization of a link below a threshold, the 153 dedicated link instance modeled by the policy user must be described 154 in certain place. So that the policy model can refer the target 155 object with an object-id. 157 The policy can also apply to a collection of objects, e.g., a group 158 of links with the same policy requirements. In this case, the 159 collection as a whole should be considered as an object with an 160 unique object-id. 162 The intent of the policy is described with a list of policy rules 163 which include declarative statements. In general, there are two ways 164 to express the intent without touching the implementation details. 166 One type of declarative statement is to express key operations that 167 the user wants to execute, with the semantic "I want to do some 168 thing". We use the operation item to describe this kind of 169 statement. The underlying policy resolver engine can extend the 170 operation and generate a complete action list from the requests. The 171 translation and the fulfillment is implementation related but user 172 agnostic. 174 The other type of declarative statement is to express the final 175 result or desired state, with the semantic "I want to achieve a 176 certain state". In this case, a user may only need to describe the 177 result without defining how to realize it. For example, require 178 secure communication between two sites. The policy engine will 179 monitor the required state, and do the adjustment automatically with 180 pre-defined logic. 182 module: supa-declarative-policy 183 | ... 184 +--rw declarative-policy 185 +--rw policy-id policy-id 186 +--rw policy-name policy-name 187 +--rw priority? uint8 188 +--rw policy-validity-period 189 | +--rw start? yang:date-and-time 190 | +--rw end? yang:date-and-time 191 | +--rw duration? uint32 192 | +--rw periodicity? enumeration 193 +--rw policy-rule-deploy-status? enumeration 194 +--rw policy-rule-exec-status? enumeration 195 +--rw target-object object-id 196 +--rw declarative-policy-rule 197 +--rw operation 198 | | .... 199 +--rw result 200 | | .... 202 Figure 1: Figure 1 Top level design of the base declarative policy 203 data model 205 3.1. Design of The Operation 207 Operation refers to some specific actions in order to achieve the 208 goal. An operation must contain one or more actions. We can use the 209 semantic "on condition, do action, with constraint". However, 210 condition and constraint can be optionally defined in operations. It 211 depends on specific scenario and users' requirement. Once a 212 condition is involved in operation, actions will not be executed 213 until condition is true. For example, "do load balancing when the 214 utilization of a link exceeds 80%". In this example, "utilization of 215 a link > 80%" is the trigger, and "do load balancing" is the action. 217 Condition must be modeled on top of events. In contrast to an event 218 in Event-Condition-Action (ECA) policy model, a condition is state- 219 based and therefore temporal constrained. It is triggered by some 220 initializing event and ended by another event or after a certain time 221 span. 223 In the declarative statement, an action will not be detailed 224 configurations in devices, but high-level and abstracted functions 225 which can be later translated into configurations by the policy 226 engine. For example, the action "do load balancing" is device 227 independent, and may configure a load balancer pool depending on 228 specific devices. 230 Constraint restricts action itself or the scope of action. 232 The Condition-Action-Constraint (CAC) model used in operation 233 expression is essentially different from the ECA policy model. 234 Firstly, the event and condition in ECA model quite depend on the 235 underlying implementation, while the declarative operation only care 236 about the condition to execute the action. Secondly, the ECA model 237 does not have a constraint description, while the declarative 238 operation does not care about the implementation of the action but 239 does care about the constraint to the action. 241 +--rw condition-parameter-definitions 242 | +--rw condition-parameter-definition* [parameter-name] 243 | +--rw parameter-name parameter-name 244 | +--rw parameter-value-type? enumeration 245 | +--rw parameter-match-patterns 246 | +--rw parameter-match-pattern* enumeration 247 +--rw constraint-parameter-definitions 248 | +--rw constraint-parameter-definition* [parameter-name] 249 | +--rw parameter-name parameter-name 250 | +--rw parameter-value-type? enumeration 251 | +--rw parameter-match-patterns 252 | +--rw parameter-match-pattern* enumeration 253 +--rw action-definitions 254 | +--rw action-definition* [action-name] 255 | +--rw action-name action-name 256 | +--rw parameter-value-type? enumeration 257 +--rw declarative-policy 258 | ... 259 +--rw declarative-policy-rule 260 | ... 261 +--rw operation 262 +--rw condition 263 | +--rw condition-segment* [condition-segment-id] 264 | +--rw condition-segment-id condition-segment-id 265 | +--rw condition-para-name? condition-parameter-name 266 | +--rw condition-para-match-pattern? enumeration 267 | +--rw condition-para-target-value 268 | | +--rw string-value? string 269 | | +--rw int-value? int64 270 | | +--rw range-value 271 | | +--rw min int64 272 | | +--rw max int64 273 | +--rw precursor-relation-operator? enumeration 274 | +--rw order? uint32 275 +--rw action* [action-name] 276 | +--rw action-name action-name 277 | +--rw parameter-values 278 | | +--rw string-value* [value order] 279 | | | +--rw value string 280 | | | +--rw order uint32 281 | | +--rw int-value* [value order] 282 | | | +--rw value int64 283 | | | +--rw order uint32 284 | | +--rw range-value 285 | | +--rw min int64 286 | | +--rw max int64 287 | +--rw order? uint32 288 +--rw constraint 289 +--rw constraint-segment* [constraint-segment-id] 290 +--rw constraint-segment-id constraint-segment-id 291 +--rw constraint-para-name? constraint-parameter-name 292 +--rw constraint-para-match-pattern? enumeration 293 +--rw constraint-para-target-value 294 | +--rw string-value? string 295 | +--rw int-value? int64 296 | +--rw range-value 297 | +--rw min int64 298 | +--rw max int64 299 +--rw precursor-relation-operator? enumeration 300 +--rw order? uint32 302 Figure 2 The snippet of operation 304 3.2. Design of The Result 306 The result statement describes the final state of objects without 307 caring about how to achieve it. For example, a result could be that 308 the company accesses any sites on the Internet safely. It just 309 defines a result that ignores technology details, such as, firewall, 310 ACL, and so on. 312 Result refers to desired state which is expected or ito be avoided. 313 For example, a user may express an intent that the link utilization 314 must be lower than 80%, which describes an expected state. The same 315 intent can also be expressed as the link utilization should not 316 exceed 80%, which describes an state to avoid. The result expression 317 model should be flexible for users so they can describe iit in either 318 way. 320 As shown in Figure 2, the result can be described as an expression 321 with left, right operands and standard relational operators. 323 +--rw result 324 +--rw left-value 325 | +--rw (value-type)? 326 | +--:(string) 327 | | +--rw single-string-value? string 328 | +--:(string-list) 329 | | +--rw string-value* [value order] 330 | | +--rw value string 331 | | +--rw order uint32 332 | +--:(int) 333 | | +--rw single-int-value? int64 334 | +--:(int-list) 335 | | +--rw int-value* [value order] 336 | | +--rw value int64 337 | | +--rw order uint32 338 | +--:(variable) 339 | | +--rw variable-name? string 340 | +--:(calculation-expression) 341 | +--rw calculation-operator? enumeration 342 | +--rw calculation-leaf-value? string 343 | +--rw calculation-right-value? string 344 +--rw relational-operator 345 | +--rw relational-operator? enumeration 346 +--rw right-value 347 +--rw (value-type)? 348 +--:(string) 349 | +--rw single-string-value? string 350 +--:(string-list) 351 | +--rw string-value* [value order] 352 | +--rw value string 353 | +--rw order uint32 354 +--:(int) 355 | +--rw single-int-value? int64 356 +--:(int-list) 357 | +--rw int-value* [value order] 358 | +--rw value int64 359 | +--rw order uint32 360 +--:(variable) 361 | +--rw variable-name? string 362 +--:(calculation-expression) 363 +--rw calculation-operator? enumeration 364 +--rw calculation-leaf-value? string 365 +--rw calculation-right-value? string 367 Figure 2: Figure 3 The snippet of result 369 The relational operator is an enumeration type including at least: 371 eq: Checks if the values of two operands are equal or not, if yes 372 then the result of the expression becomes true. 374 ne: Checks if the values of two operands are equal or not, if 375 values are not equal then the result of the expression becomes 376 true. 378 gt: Checks if the value of left operand is greater than the value 379 of right operand, if yes then the result of the expression becomes 380 true. 382 ge: Checks if the value of left operand is greater than or equal 383 to the value of right operand, if yes then the result of the 384 expression becomes true. 386 lt: Checks if the value of left operand is less than the value of 387 right operand, if yes then the result of the expression becomes 388 true. 390 le: Checks if the value of left operand is less than or equal to 391 the value of right operand, if yes then the result of the 392 expression becomes true. 394 bl: Checks if the left set belongs to the right set, if yes then 395 the result of the expression becomes true. 397 nb: Checks if the left set belongs to the right set, if no then 398 the result of the expression becomes true. 400 The left and right operands can be a set or a single value or the 401 expression with calculation operators. For example, a policy rule 402 could be, the marketing network and the sales network do not belong 403 to the internal network. Typical calculation operators include: 404 add/minus/multiply/division, max/min/average, intersection/union/ 405 complement, and/or/not, any/all, etc. 407 4. Declarative Policy Base YANG Data Model 409 4.1. Declarative Policy Data Model Hierarchy 411 Figure 3 shows the structure of base data model for the declarative 412 policy module. 414 module: supa-declarative-policy 415 +--rw condition-parameter-definitions 416 | +--rw condition-parameter-definition* [parameter-name] 417 | +--rw parameter-name parameter-name 418 | +--rw parameter-value-type? enumeration 419 | +--rw parameter-match-patterns 420 | +--rw parameter-match-pattern* enumeration 421 +--rw constraint-parameter-definitions 422 | +--rw constraint-parameter-definition* [parameter-name] 423 | +--rw parameter-name parameter-name 424 | +--rw parameter-value-type? enumeration 425 | +--rw parameter-match-patterns 426 | +--rw parameter-match-pattern* enumeration 427 +--rw action-definitions 428 | +--rw action-definition* [action-name] 429 | +--rw action-name action-name 430 | +--rw parameter-value-type? enumeration 431 +--rw declarative-policy 432 +--rw policy-id policy-id 433 +--rw policy-name policy-name 434 +--rw priority? uint8 435 +--rw policy-validity-period 436 | +--rw start? yang:date-and-time 437 | +--rw end? yang:date-and-time 438 | +--rw duration? uint32 439 | +--rw periodicity? enumeration 440 +--rw policy-rule-deploy-status? enumeration 441 +--rw policy-rule-exec-status? enumeration 442 +--rw target-object object-id 443 +--rw declarative-policy-rule 444 +--rw operation 445 | +--rw condition 446 | | +--rw condition-segment* [condition-segment-id] 447 | | +--rw condition-segment-id condition-segment-id 448 | | +--rw condition-para-name? condition-parameter-name 449 | | +--rw condition-para-match-pattern? enumeration 450 | | +--rw condition-para-target-value 451 | | | +--rw string-value? string 452 | | | +--rw int-value? int64 453 | | | +--rw range-value 454 | | | +--rw min int64 455 | | | +--rw max int64 456 | | +--rw precursor-relation-operator? enumeration 457 | | +--rw order? uint32 458 | +--rw action* [action-name] 459 | | +--rw action-name action-name 460 | | +--rw parameter-values 461 | | | +--rw string-value* [value order] 462 | | | | +--rw value string 463 | | | | +--rw order uint32 464 | | | +--rw int-value* [value order] 465 | | | | +--rw value int64 466 | | | | +--rw order uint32 467 | | | +--rw range-value 468 | | | +--rw min int64 469 | | | +--rw max int64 470 | | +--rw order? uint32 471 | +--rw constraint 472 | +--rw constraint-segment* [constraint-segment-id] 473 | +--rw constraint-segment-id constraint-segment-id 474 | +--rw constraint-para-name? constraint-parameter-name 475 | +--rw constraint-para-match-pattern? enumeration 476 | +--rw constraint-para-target-value 477 | | +--rw string-value? string 478 | | +--rw int-value? int64 479 | | +--rw range-value 480 | | +--rw min int64 481 | | +--rw max int64 482 | +--rw precursor-relation-operator? enumeration 483 | +--rw order? uint32 484 +--rw result 485 +--rw left-value 486 | +--rw (value-type)? 487 | +--:(string) 488 | | +--rw single-string-value? string 489 | +--:(string-list) 490 | | +--rw string-value* [value order] 491 | | +--rw value string 492 | | +--rw order uint32 493 | +--:(int) 494 | | +--rw single-int-value? int64 495 | +--:(int-list) 496 | | +--rw int-value* [value order] 497 | | +--rw value int64 498 | | +--rw order uint32 499 | +--:(variable) 500 | | +--rw variable-name? string 501 | +--:(calculation-expression) 502 | +--rw calculation-operator? enumeration 503 | +--rw calculation-leaf-value? string 504 | +--rw calculation-right-value? string 505 +--rw relational-operator 506 | +--rw relational-operator? enumeration 507 +--rw right-value 508 +--rw (value-type)? 509 +--:(string) 510 | +--rw single-string-value? string 511 +--:(string-list) 512 | +--rw string-value* [value order] 513 | +--rw value string 514 | +--rw order uint32 515 +--:(int) 516 | +--rw single-int-value? int64 517 +--:(int-list) 518 | +--rw int-value* [value order] 519 | +--rw value int64 520 | +--rw order uint32 521 +--:(variable) 522 | +--rw variable-name? string 523 +--:(calculation-expression) 524 +--rw calculation-operator? enumeration 525 +--rw calculation-leaf-value? string 526 +--rw calculation-right-value? string 528 Figure 3: Figure 4 structure of the declarative policy module 530 4.2. Declarative Policy Base Data Model in YANG Module 532 file "ietf-declarative-policy@2015-12-09.yang" 534 module ietf-declarative-policy { 536 yang-version 1; 538 namespace "urn:ietf:params:xml:ns:yang:ietf-declarative-policy"; 540 prefix "dpolicy"; 542 import ietf-yang-types { 543 prefix yang; 544 } 546 organization 547 "Individual I-D as input to SUPA WG"; 549 contact 550 "Editor: Bert Wijnen 551 553 Author: Tianran Zhou 554 556 Author: Yinben Xia 557 558 "; 560 description 561 "This YANG module defines essential components for the 562 management of declarative policies. 564 Copyright (c) 2015 IETF Trust and the persons identified as 565 authors of the code. All rights reserved. 567 Redistribution and use in source and binary forms, with or 568 without modification, is permitted pursuant to, and subject 569 to the license terms contained in, the Simplified BSD License 570 set forth in Section 4.c of the IETF Trust's Legal Provisions 571 Relating to IETF Documents 572 (http://trustee.ietf.org/license-info). 574 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 575 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 576 'OPTIONAL' in the module text are to be interpreted as 577 described in RFC 2119 (http://tools.ietf.org/html/rfc2119). 579 This version of this YANG module is part of RFC XXXX 580 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 581 full legal notices."; 583 revision "2015-12-09" { 584 description 585 "Initial revision."; 586 reference 587 "RFC XXXX: A YANG Data Model for Delcarative Policy."; 588 } 590 typedef uuid { 591 type string { 592 pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-' + 593 '[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; 594 } 595 description 596 "A Universally Unique Identifier in the string 597 representation defined in RFC 4122. The canonical 598 representation uses lower case characters. 600 The following is an example of a UUID in string 601 representation: 602 f81d4fae-7dec-11d0-a765-00a0c91e6bf6"; 603 reference 604 "RFC 4122: A Universally Unique IDentifier (UUID) URN 605 Namespace"; 606 } 608 typedef unique-id { 609 type uuid; 610 description 611 "A globally unique identifier."; 613 } 615 typedef name { 616 type string { 617 length "1..256"; 618 pattern '[a-zA-Z]([a-zA-Z0-9\-_.])*'; 619 } 620 description 621 "A generic string name type. Must start with a 622 letter"; 623 } 625 typedef parameter-name { 626 type name; 627 description 628 "A name for a parameter."; 629 } 631 typedef action-name { 632 type name; 633 description 634 "A name for an action."; 635 } 637 typedef condition-segment-id { 638 type unique-id; 639 description 640 "A unique ID for a segment of the condition in an 641 operation."; 642 } 644 typedef constraint-segment-id { 645 type unique-id; 646 description 647 "A unique ID for a segment of the constraint in 648 an operation."; 649 } 651 typedef condition-parameter-name { 652 type name; 653 description 654 "A name for a parameter of condition."; 655 } 657 typedef constraint-parameter-name { 658 type name; 659 description 660 "A name for a parameter of constraint."; 662 } 664 typedef policy-id { 665 type unique-id; 666 description 667 "A unique ID for a policy."; 668 } 670 typedef policy-name { 671 type string; 672 description 673 "A name for a policy."; 674 } 676 typedef object-id { 677 type unique-id; 678 description 679 "A unique ID for a parameterized object."; 680 } 682 typedef match-pattern-operator { 683 type enumeration { 684 enum less-than { 685 description "less than"; 686 } 687 enum not-less-than { 688 description "not less than"; 689 } 690 enum equal { 691 description "equal"; 692 } 693 enum not-equal { 694 description "not equal"; 695 } 696 enum greater-than { 697 description "greater than"; 698 } 699 enum not-greater-than { 700 description "not greater than"; 701 } 702 enum between { 703 description "between"; 704 } 705 enum periodical { 706 description "periodical"; 707 } 708 } 709 description "pattern matching operators"; 711 } 713 container top_declarative_policy { 714 description "Top level declarative policy container"; 716 container condition-parameter-definitions { 717 description "List of condition parameters"; 718 list condition-parameter-definition { 719 key "parameter-name"; 720 description 721 "Defines the condition parameter with its 722 metadata."; 723 leaf parameter-name { 724 type parameter-name; 725 mandatory true; 726 description 727 "A name for the condition parameter."; 728 } 730 leaf parameter-value-type { 731 type enumeration { 732 enum string { 733 description 734 "A string-valued parameter."; 735 } 736 enum int { 737 description 738 "An integer-valued parameter."; 739 } 740 enum range { 741 description 742 "An integer-range parameter."; 743 } 744 } 745 description 746 "A type of value for the condition 747 parameter."; 748 } 750 container parameter-match-patterns { 751 description 752 "Defines the match patterns of the condition 753 parameter."; 755 leaf-list parameter-match-pattern { 756 type match-pattern-operator; 757 description 758 "pattern matching operator"; 760 } 761 } 762 } 763 } 765 container constraint-parameter-definitions { 766 description "Parameter definitions fro constraints"; 767 list constraint-parameter-definition { 768 key "parameter-name"; 769 description 770 "Defines the constraint parameter with its 771 metadata."; 773 leaf parameter-name { 774 type parameter-name; 775 mandatory true; 776 description 777 "A name for the constraint parameter."; 778 } 780 leaf parameter-value-type { 781 type enumeration { 782 enum string { 783 description 784 "A string-valued parameter."; 785 } 786 enum int { 787 description 788 "An integer-valued parameter."; 789 } 790 enum range { 791 description 792 "An integer-range parameter."; 793 } 794 } 795 description 796 "A type of value for the constraint 797 parameter."; 798 } 800 container parameter-match-patterns { 801 description 802 "Defines the match patterns of the constraint 803 parameter."; 805 leaf-list parameter-match-pattern { 806 type match-pattern-operator; 807 description 808 "pattern matching operator"; 809 } 810 } 811 } 812 } 814 container action-definitions { 815 description "Action definitions"; 816 list action-definition { 817 key "action-name"; 818 description 819 "Defines the actions which will be supported."; 821 leaf action-name { 822 type action-name; 823 mandatory true; 824 description 825 "A name for the action definition."; 826 } 828 leaf parameter-value-type { 829 type enumeration { 830 enum string { 831 description 832 "A string-valued parameter."; 833 } 834 enum int { 835 description 836 "An integer-valued parameter."; 837 } 838 enum range { 839 description 840 "An integer-range parameter."; 841 } 842 } 843 default string; 844 description 845 "The type of the action parameter."; 846 } 847 } 848 } 850 grouping condition-instance { 851 description 852 "Specific a instance of condition whose metadata has 853 been filled in."; 855 list condition-segment { 856 key "condition-segment-id"; 857 description 858 "The segment entities will be composed into a 859 whole condition entity. Each segment will be 860 a sub expression of the condition."; 862 leaf condition-segment-id { 863 type condition-segment-id; 864 mandatory true; 865 description 866 "A unique ID for a condition segment."; 867 } 869 leaf condition-parameter-name { 870 type condition-parameter-name; 871 description 872 "A name for a condition parameter."; 873 } 875 leaf condition-parameter-match-pattern { 876 type match-pattern-operator; 877 description 878 "The operator for the condition parameter 879 and it's target value."; 880 } 882 container condition-parameter-target-value { 883 description 884 "The target value of condition parameter."; 886 leaf string-value { 887 type string; 888 description "The value is of type 'string'"; 889 } 891 leaf int-value { 892 type int64; 893 description "The value is of type 'int64'"; 894 } 896 container range-value { 897 description 898 "The min/max of a range."; 899 leaf min { 900 type int64; 901 mandatory true; 902 description "minimum value of the range"; 904 } 906 leaf max { 907 type int64; 908 mandatory true; 909 description "maximum value of the range"; 910 } 911 } 912 } 914 leaf precursor-relation-operator { 915 type enumeration { 916 enum none { 917 description 918 "no precursor-relation-operator"; 919 } 920 enum and { 921 description 922 "'and' precursor-relation-operator"; 923 } 924 enum or { 925 description 926 "'or' precursor-relation-operator"; 927 } 928 enum not { 929 description 930 "'not' precursor-relation-operator"; 931 } 932 } 933 description "the pre-cursor relation operation."; 934 } 936 leaf order { 937 type uint32; 938 description 939 "The order of the segment in the whole 940 condition entity."; 941 } 942 } 943 } 945 grouping constraint-instance { 946 description 947 "Specific a instance of constraint whose metadata 948 has been filled in."; 950 list constraint-segment { 951 key "constraint-segment-id"; 952 description 953 "The segment entities will be composed into a 954 whole constraint entity. Each segment will be 955 a sub expression of the constraint."; 957 leaf constraint-segment-id { 958 type constraint-segment-id; 959 mandatory true; 960 description 961 "A unique ID for a constraint segment."; 962 } 964 leaf constraint-parameter-name { 965 type constraint-parameter-name; 966 description 967 "A name for a constraint parameter."; 968 } 970 leaf constraint-parameter-match-pattern { 971 type match-pattern-operator; 972 description 973 "The operator for the constraint parameter 974 and it's target value."; 975 } 977 container constraint-parameter-target-value { 978 description 979 "The target value of constraint parameter."; 981 leaf string-value { 982 type string; 983 description "the string value."; 984 } 986 leaf int-value { 987 type int64; 988 description "the int64 value."; 989 } 991 container range-value { 992 description "a range of values."; 993 leaf min { 994 type int64; 995 mandatory true; 996 description "the min value in the range."; 997 } 998 leaf max { 999 type int64; 1000 mandatory true; 1001 description "the max value in the range."; 1002 } 1004 } 1005 } 1007 leaf precursor-relation-operator { 1008 type enumeration { 1009 enum none { 1010 description "no relational operation."; 1011 } 1012 enum and { 1013 description "'and' relational operation."; 1014 } 1015 enum or { 1016 description "'or' relational operation."; 1017 } 1018 enum not { 1019 description "'not' relational operation."; 1020 } 1021 } 1022 description 1023 "The logical operator between current segment 1024 and the next segment."; 1025 } 1027 leaf order { 1028 type uint32; 1029 description 1030 "The order of the segment in the whole 1031 constraint entity."; 1032 } 1033 } 1034 } 1036 grouping action-instance { 1037 description 1038 "Specific a action instance whose metadata has 1039 been filled in."; 1041 leaf action-name { 1042 type action-name; 1043 mandatory true; 1044 description 1045 "A name for a action instance."; 1046 } 1048 container parameter-values { 1049 description 1050 "The parameter value list of an action."; 1052 list string-value { 1053 key "value order"; 1054 description "list of string values."; 1055 leaf value { 1056 type string; 1057 description "The string value."; 1058 } 1060 leaf order { 1061 type uint32; 1062 description "The order of the value in the 1063 list."; 1064 } 1065 } 1067 list int-value { 1068 key "value order"; 1069 description "list of integer values."; 1070 leaf value { 1071 type int64; 1072 description "The int64 value."; 1073 } 1075 leaf order { 1076 type uint32; 1077 description "The order of the value in the 1078 list."; 1079 } 1080 } 1082 container range-value { 1083 description "a value range."; 1084 leaf min { 1085 type int64; 1086 mandatory true; 1087 description "The min value in the range."; 1088 } 1090 leaf max { 1091 type int64; 1092 mandatory true; 1093 description "The max value in the range."; 1094 } 1095 } 1096 } 1097 } 1099 grouping operation { 1100 description "Defines an operation."; 1101 container condition { 1102 uses condition-instance; 1103 description "Defines a condition"; 1104 } 1106 list action { 1107 key "action-name"; 1108 uses action-instance; 1109 min-elements 1; 1110 description 1111 "The action list for the operation instance."; 1112 leaf order { 1113 type uint32; 1114 description 1115 "The order of an action instance in 1116 execution sequence."; 1117 } 1118 } 1120 container constraint{ 1121 uses constraint-instance; 1122 description "The constraint definition."; 1123 } 1124 } 1126 grouping relational-expression-value { 1127 description "The relational expression."; 1128 choice value-type { 1130 description 1131 "The value of the relation expression can be 1132 different type."; 1133 case string{ 1134 leaf single-string-value { 1135 type string; 1136 description "The string value of the 1137 variable."; 1138 } 1139 } 1140 case string-list { 1141 list string-value { 1142 key "value order"; 1143 description "List of string values."; 1144 leaf value { 1145 type string; 1146 description "The string value of the 1147 variable."; 1148 } 1149 leaf order { 1150 type uint32; 1151 description "the order in the list."; 1152 } 1153 } 1154 } 1155 case int { 1156 leaf single-int-value { 1157 type int64; 1158 description "The value of the int64 1159 variable."; 1160 } 1161 } 1162 case int-list { 1163 list int-value { 1164 key "value order"; 1165 description "List of integer values."; 1166 leaf value { 1167 type int64; 1168 description "the value of the int64 1169 variable."; 1170 } 1172 leaf order { 1173 type uint32; 1174 description "the order in the list."; 1175 } 1176 } 1177 } 1178 case variable { 1179 leaf variable-name { 1180 type string; 1181 description "the name of the variable."; 1182 } 1183 } 1185 case calculation-expression { 1187 leaf calculation-operator{ 1188 type enumeration { 1189 enum add { 1190 description "'add' operator"; 1191 } 1192 enum minus { 1193 description "'subtract' operator"; 1194 } 1195 enum multiply { 1196 description "'multiply' operator"; 1197 } 1198 enum divide { 1199 description "'divide' operator"; 1200 } 1201 enum any { 1202 description "'any' operator"; 1203 } 1204 enum all { 1205 description "'all' operator"; 1206 } 1207 enum max { 1208 description "'max' operator"; 1209 } 1210 enum min { 1211 description "'min' operator"; 1212 } 1213 enum average { 1214 description "'avg' operator"; 1215 } 1216 enum sum { 1217 description "'sum' operator"; 1218 } 1219 enum count { 1220 description "'count' operator"; 1221 } 1222 enum and { 1223 description "'and' operator"; 1224 } 1225 enum or { 1226 description "'or' operator"; 1227 } 1228 enum not { 1229 description "'not' operator"; 1230 } 1231 enum intersection { 1232 description "'intersetion' 1233 operator"; 1234 } 1235 enum union { 1236 description "'union' operator"; 1238 } 1239 enum complement { 1240 description "'complement' operator"; 1241 } 1242 } 1243 description 1244 "The calculation to be performed"; 1245 } 1247 leaf calculation-leaf-value { 1248 type string; 1249 description 1250 "The content of the leaf value for a 1251 calculation expression is an instance 1252 of relational-expression-value."; 1253 } 1255 leaf calculation-right-value { 1256 type string; 1257 description 1258 "The content of the right value for a 1259 calculation expression is an instance 1260 of relational-expression-value."; 1261 } 1262 } 1263 } 1264 } 1266 grouping result { 1267 description "The result."; 1268 container left-value { 1269 description "The 'left' value for the relational 1270 operation."; 1271 uses relational-expression-value; 1272 } 1274 container relational-operator { 1275 description 1276 "The relational operation to be performed"; 1277 leaf relational-operator { 1278 type enumeration { 1279 enum eq { 1280 description "'equal' operator."; 1281 } 1282 enum ne { 1283 description "'not equal' operator."; 1284 } 1285 enum gt { 1286 description "'greater than' operator."; 1287 } 1288 enum ge { 1289 description "greater than or equal' 1290 operator."; 1291 } 1292 enum lt { 1293 description "'less than' operator."; 1294 } 1295 enum le { 1296 description "'less than or equal' 1297 operator."; 1298 } 1299 enum bl { 1300 description "'belongs to' or 1301 'is an element of' 1302 operator."; 1303 } 1304 enum nb { 1305 description "'does not belong to' or 1306 'is not an element of' 1307 operator."; 1308 } 1309 } 1310 description "the relational operation to be 1311 performed."; 1312 } 1313 } 1314 container right-value { 1315 description "The 'right' value for the relational 1316 operation."; 1317 uses relational-expression-value; 1318 } 1319 } 1321 container declarative-policy { 1322 description 1323 "Aarative policy definition"; 1325 leaf policy-id { 1326 type policy-id; 1327 mandatory true; 1328 description 1329 "A unique ID for a policy."; 1330 } 1332 leaf policy-name { 1333 type policy-name; 1334 mandatory true; 1335 description 1336 "A user-visible and unique name for a policy."; 1337 } 1339 leaf priority { 1340 type uint8; 1341 default 0; 1342 description 1343 "Defines the priority of a operation instance."; 1344 } 1346 container policy-validity-period { 1347 description 1348 "The valid time of the policy. E.g., the policy 1349 will be valid 9am-9am daily"; 1350 leaf start { 1351 type yang:date-and-time; 1352 description "date and time to start the policy"; 1353 } 1354 leaf end { 1355 type yang:date-and-time; 1356 description "date and time to end the policy"; 1357 } 1358 leaf duration { 1359 type uint32; 1360 description "duration of the policy"; 1361 } 1362 leaf periodicity { 1363 type enumeration { 1364 enum daily { 1365 value 0; 1366 description 1367 "The policy is repeated daily"; 1368 } 1369 enum monthly { 1370 value 1; 1371 description 1372 "The policy is repeated monthly"; 1373 } 1374 } 1375 description "How the policy is repeated"; 1376 } 1377 } 1379 leaf policy-rule-deploy-status { 1380 type enumeration { 1381 enum undefined { 1382 description "undefined"; 1383 } 1384 enum deployed_and_enabled { 1385 description "deployed and enabled"; 1386 } 1387 enum deployed_and_testing { 1388 description "deployed and in test"; 1389 } 1390 enum deployed_and_disabled { 1391 description "deployed but not enabled"; 1392 } 1393 enum ready_to_be_deployed { 1394 description "ready to be deployed"; 1395 } 1396 enum not_deployed { 1397 description "not deployed"; 1398 } 1399 } 1400 description 1401 "The deploy status of the policy."; 1402 } 1404 leaf policy-rule-exec-status { 1405 type enumeration { 1406 enum undefined { 1407 description "undefined"; 1408 } 1409 enum executed_and_succeeded{ 1410 description 1411 "executed and SUCEEDED (operational mode)"; 1412 } 1413 enum executed_and_failed{ 1414 description 1415 "executed and FAILED (operational mode)"; 1416 } 1417 enum executing { 1418 description 1419 "currently executing (operational mode)"; 1420 } 1421 enum tested_and_succeeded { 1422 description 1423 "executed and SUCEEDED (test mode)"; 1424 } 1425 enum tested_and_failed { 1426 description 1427 "executed and FAILED (test mode)"; 1428 } 1429 enum testing { 1430 description 1431 "currently executing (test mode)"; 1432 } 1433 } 1434 description 1435 "The executing status of the policy."; 1436 } 1438 leaf target-object { 1439 type object-id; 1440 mandatory true; 1441 description 1442 "The target object which the operation instanc 1443 will apply to."; 1444 } 1446 container declarative-policy-rule { 1447 description "declarative policy rules."; 1448 container operation { 1449 uses operation; 1450 description 1451 "An operation based declarative policy rule"; 1452 } 1453 container result { 1454 uses result; 1455 description 1456 "A result based declarative policy rule"; 1457 } 1458 } 1459 } 1460 } 1461 } 1462 1464 5. Declarative Policy Data Model Examples 1466 5.1. Link utilization optimization 1468 For the link utilization optimization, there will be many kinds of 1469 policy requirements and expressions. For example: 1471 Policy 1: In one set of links, keep all link utilization below 70%. 1473 Policy 2: In one set of links, minimize the average link utilization. 1475 Both of the policies are target to a set of links, which could 1476 include the following attributes: 1478 uti: link bandwidth utility. 1480 bandwidth: bandwidth of the link. 1482 For the policy 1, we can use the result to express the declarative 1483 rule statement. 1485 result: 1487 left: uti 1489 operator: lt 1491 right: 70 1493 ult: 1495 For policy 2, we can in alternative use the operation to express the 1496 declarative rule statement. 1498 operation: 1500 action: minimize the average link utilization. 1502 5.2. Policy Based Bandwidth on Demand 1504 There are branch and headquarter sites connected via a WAN 1505 connection. The bandwidth of the connection can be adjusted to 1000M 1506 during daytime and 100M at night. 1508 This automatic bandwidth adjustment requirement can be expressed by 1509 policies target to the connection object. And we can use the 1510 operation to express the declarative rule statement. 1512 one operation is: 1514 condition: time = day 1516 action: set the bandwidth to 1000M 1518 the other operation is: 1520 condition: time = night 1522 action: set the bandwidth to 100M 1524 5.3. Service function chaining 1526 We can also use declarative policies to describe the SFC requirement 1527 to simplify the expression. 1529 For example, the gold service user traffic go through the firewall 1530 and load balancer services. The policy user do not need to care 1531 about the exact function instance to use, but focus on the service 1532 intent expression. 1534 This policy is targeted to a flow object, which could include the 1535 following attributes: 1537 srcip,destip: the source and destination IP address of the flow. 1539 userlevel: the user's service level of the flow, it can be gold or 1540 normal. 1542 The operation rule is: 1544 action: go through, and with parameters: firewall, load balancer. 1546 6. Security Considerations 1548 The YANG module defined in this memo is designed to be accessed via 1549 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1550 secure transport layer and the mandatory-to-implement secure 1551 transport is SSH [RFC6242]. The NETCONF access control model 1552 [RFC6536] provides the means to restrict access for particular 1553 NETCONF users to a pre-configured subset of all available NETCONF 1554 protocol operations and content. 1556 There are a number of data nodes defined in the YANG module which are 1557 writable/creatable/deletable (i.e., config true, which is the 1558 default). These data nodes may be considered sensitive or vulnerable 1559 in some network environments. Write operations (e.g., ) 1560 to these data nodes without proper protection can have a negative 1561 effect on network operations. 1563 7. IANA Considerations 1565 This memo includes no request to IANA. 1567 8. Acknowledgements 1569 The authors would like to thanks the valuable comments made by:. 1571 This document was produced using the xml2rfc tool [RFC2629]. 1573 9. Informative References 1575 [I-D.chen-supa-eca-data-model] 1576 Chen, M., Contreras, L., Hayashi, M., and T. Tsou, "ECA 1577 Policy YANG Data Model", draft-chen-supa-eca-data-model-05 1578 (work in progress), October 2015. 1580 [I-D.klyus-supa-proposition] 1581 Klyus, M. and J. Strassner, "SUPA Value Proposition", 1582 draft-klyus-supa-proposition-02 (work in progress), July 1583 2015. 1585 [I-D.xia-sdnrg-nemo-language] 1586 Xia, Y., Jiang, S., Zhou, T., and S. Hares, "NEMO (NEtwork 1587 MOdeling) Language", draft-xia-sdnrg-nemo-language-03 1588 (work in progress), October 2015. 1590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1591 Requirement Levels", BCP 14, RFC 2119, 1592 DOI 10.17487/RFC2119, March 1997, 1593 . 1595 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1596 DOI 10.17487/RFC2629, June 1999, 1597 . 1599 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1600 the Network Configuration Protocol (NETCONF)", RFC 6020, 1601 DOI 10.17487/RFC6020, October 2010, 1602 . 1604 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 1605 RFC 6021, DOI 10.17487/RFC6021, October 2010, 1606 . 1608 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1609 and A. Bierman, Ed., "Network Configuration Protocol 1610 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1611 . 1613 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1614 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1615 . 1617 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1618 Protocol (NETCONF) Access Control Model", RFC 6536, 1619 DOI 10.17487/RFC6536, March 2012, 1620 . 1622 Authors' Addresses 1624 Tianran Zhou 1625 Huawei Technologies Co., Ltd 1626 Q14, Huawei Campus, No.156 Beiqing Road 1627 Hai-Dian District, Beijing, 100095 1628 P.R. China 1630 Email: zhoutianran@huawei.com 1632 Yinben Xia 1633 Huawei Technologies Co., Ltd 1634 Q14, Huawei Campus, No.156 Beiqing Road 1635 Hai-Dian District, Beijing, 100095 1636 P.R. China 1638 Email: xiayinben@huawei.com 1640 Bert Wijnen (editor) 1641 Consultant 1642 Schagen 33 1643 3461 GL Linschoten 1644 The Netherlands 1646 Email: bertietf@bwijnen.net