idnits 2.17.1 draft-shaikh-rtgwg-policy-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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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 5 characters in excess of 72. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 299 has weird spacing: '...et-name str...' == Line 303 has weird spacing: '...h-range str...' == Line 305 has weird spacing: '...et-name str...' == Line 307 has weird spacing: '...address ine...' == Line 309 has weird spacing: '...et-name str...' == (3 more instances...) -- The document date (January 23, 2015) is 3374 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Shaikh 3 Internet-Draft Google 4 Intended status: Informational R. Shakir 5 Expires: July 27, 2015 BT 6 K. D'Souza 7 C. Chase 8 AT&T 9 January 23, 2015 11 Routing Policy Configuration Model for Service Provider Networks 12 draft-shaikh-rtgwg-policy-model-00 14 Abstract 16 This document defines a YANG data model for configuring and managing 17 routing policies in a vendor-neutral way and based on actual 18 operational practice. The model provides a generic policy framework 19 which can be augmented with protocol-specific policy configuration. 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 July 27, 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 1. Introduction 55 This document describes a YANG [RFC6020] data model for routing 56 policy configuration based on operational usage and best practices in 57 a variety of service provider networks. The model is intended to be 58 vendor-neutral, in order to allow operators to manage policy 59 configuration in a consistent, intuitive way in heterogeneous 60 environments with routers supplied by multiple vendors. 62 1.1. Goals and approach 64 This model does not aim to be feature complete -- it is a subset of 65 the policy configuration parameters available in a variety of vendor 66 implementations, but supports widely used constructs for managing how 67 routes are imported, exported, and modified across different routing 68 protocols. The model development approach has been to examine actual 69 policy configurations in use across a number of operator networks. 70 Hence the focus is on enabling policy configuration capabilities and 71 structure that are in wide use. 73 Despite the differences in details of policy expressions and 74 conventions in various vendor implementations, the model reflects the 75 observation that a relatively simple condition- action approach can 76 be readily mapped to several existing vendor implementations, and 77 also gives operators an intuitive and straightforward way to express 78 policy without sacrificing flexibility. A side affect of this design 79 decision is that legacy methods for expressing policies are not 80 considered. Such methods could be added as an augmentation to the 81 model if needed. 83 Consistent with the goal to produce a data model that is vendor 84 neutral, only policy expressions that are deemed to be widely 85 available in existing major implementations are included in the 86 model. Those configuration items that are only available from a 87 single implementation are omitted from the model with the expectation 88 they will be available in separate vendor-provided modules that 89 augment the current model. 91 2. Model overview 93 The routing policy model is defined in two YANG modules, the main 94 policy module, and an auxiliary module providing additional generic 95 types. The model has three main parts: 97 o A generic framework to express policies as sets of related 98 conditions and actions. This includes match sets and actions that 99 are useful across many routing protocols. 101 o A structure that allows routing protocol models to add protocol- 102 specific policy conditions and actions though YANG augmentations. 103 There is a complete example of this for BGP [RFC4271] policies in 104 the proposed vendor-neutral BGP data model [BGP-Model]. 106 o A reusable grouping for attaching import and export rules in the 107 context of routing configuration for different protocols, VRFs, 108 etc. This also enables creation of policy chains and expressing 109 default policy behavior. 111 These modules make use of the standard Internet types, such as IP 112 addresses, autonomous system numbers, etc., defined in RFC 6991 113 [RFC6991]. 115 3. Route policy expression 117 Policies are expressed as a sequence of top-level policy definitions 118 each of which consists of a sequence of policy statements. Policy 119 statements in turn consist of simple condition-action tuples. 120 Conditions may include mutiple match or comparison operations, and 121 similarly, actions may effect multiple changes to route attributes, 122 or indicate a final disposition of accepting or rejecting the route. 123 This structure is shown below. 125 +--rw routing-policy 126 +--rw policy-definition* [name] 127 +--rw name string 128 +--rw statement* [name] 129 +--rw name string 130 +--rw conditions! 131 | ... 132 +--rw actions! 133 ... 135 3.1. Policy conditions 137 Policy statements consist of a set of conditions and actions (either 138 of which may be empty). Conditions are used to match route 139 attributes against a defined set (e.g., a prefix set), or to compare 140 attributes against a specific value. 142 Match conditions may be further modified using the match-set-options 143 configuration which allows operators to change the behavior of a 144 match. Three options are supported: 146 o ALL - match is true only if the given value matches all members of 147 the set. 149 o ANY - match is true if the given value matches any member of the 150 set. 152 o INVERT - match is true if the given value does not match any 153 member of the given set. 155 Comparison conditions may similarly use options to change how route 156 attributes should be tested, e.g., for equality or inequality, 157 against a given value. 159 While most policy conditions will be added by individual routing 160 protocol models via augmentation, this routing policy model includes 161 several generic match conditions and also the ability to test which 162 protocol or mechanism installed a route (e.g., BGP, IGP, static, 163 etc.). The conditions included in the model are shown below. 165 +--rw routing-policy 166 +--rw policy-definition* [name] 167 +--rw statement* [name] 168 +--rw conditions! 169 +--rw call-policy? -> /routing-policy/... 170 +--rw match-prefix-set? -> /routing-policy/... 171 +--rw match-neighbor-set? -> /routing-policy/... 172 +--rw match-tag-set? -> /routing-policy/... 173 +--rw match-set-options? pt:match-set-options-type 174 +--rw install-protocol-eq? identityref 175 +--rw igp-conditions 177 3.2. Policy actions 179 When policy conditions are satisfied, policy actions are used to set 180 various attributes of the route being processed, or to indicate the 181 final disposition of the route, i.e., accept or reject. 183 Similar to policy conditions, the routing policy model includes 184 generic actions in addition to the basic route disposition actions. 185 These are shown below. 187 +--rw routing-policy 188 +--rw policy-definition* [name] 189 +--rw statement* [name] 190 +--rw actions! 191 +--rw accept-route? empty 192 +--rw reject-route? empty 193 +--rw igp-actions 194 +--rw set-tag? pt:tag-type 196 3.3. Policy subroutines 198 Policy 'subroutines' (or nested policies) are supported by allowing 199 policy statement conditions to reference other policy definitions 200 using the call-policy configuration. Called policies apply their 201 conditions and actions before returning to the calling policy 202 statement and resuming evaluation. The outcome of the called policy 203 affects the evaluation of the calling policy. If the called policy 204 results in an accept-route (either explicit or by default), then the 205 subroutine returns an effective boolean true value to the calling 206 policy. For the calling policy, this is equivalent to a condition 207 statement evaluating to a true value and evaluation of the policy 208 continues (see Section 4). Note that the called policy may also 209 modify attributes of the route in its action statements. Similarly, 210 a reject-route action returns false and the calling policy evaluation 211 will be affected accordingly. 213 Note that the called policy may itself call other policies (subject 214 to implementation limitations). The model does not prescribe a 215 nesting depth because this varies among implementations, with some 216 major implementations only supporting a single subroutine, for 217 example. As with any routing policy construction, care must be taken 218 with nested policies to ensure that the effective return value 219 results in the intended behavior. Nested policies are a convenience 220 in many routing policy constructions but creating policies nested 221 beyond a small number of levels (e.g., 2-3) should be discouraged. 223 4. Policy evaluation 225 Evaluation of each policy definition proceeds by evaluating its 226 corresponding individual policy statements in order. When a 227 condition statement in a policy statement is satisfied, the 228 corresponding action statement is executed. If the action statement 229 has either accept-route or reject-route actions, evaluation of the 230 current policy definition stops, and no further policy definitions in 231 the chain are evaluated. 233 If the condition is not satisfied, then evaluation proceeds to the 234 next policy statement. If none of the policy statement conditions 235 are satisfied, then evaluation of the current policy definition 236 stops, and the next policy definition in the chain is evaluated. 237 When the end of the policy chain is reached, the default route 238 disposition action is performed (i.e., reject-route unless an an 239 alternate default action is specified for the chain). 241 5. Applying routing policy 243 Routing policy is applied by defining and attaching policy chains in 244 various routing contexts. Policy chains are sequences of policy 245 definitions (described in Section 3) that have an associated 246 direction (import or export) with respect to the routing context in 247 which they are defined. The routing policy model defines an apply- 248 policy grouping that can be imported and used by other models. As 249 shown below, it allows definition of import and export policy chains, 250 as well as specifying the default route disposition to be used when 251 no policy definition in the chain results in a final decision. 253 +--rw apply-policy 254 +--rw import-policies* -> /rpol:routing-policy/... 255 +--rw default-import-policy? default-policy-type 256 +--rw export-policies* -> /rpol:routing-policy/... 257 +--rw default-export-policy? default-policy-type 259 The default policy defined by the model is to reject the route for 260 both import and export policies. 262 An example of using the apply-policy group in another routing model 263 is shown below for BGP. Here, import and export policies are applied 264 in the context of a particular BGP peer group. Note that the policy 265 chains reference policy definitions by name that are defined in the 266 routing policy model. 268 +--rw peer-group* [group-name] 269 | +--rw group-name string 270 | +--ro bgp-group-common-state 271 | +--rw description? string 272 | +--rw graceful-restart! 273 | | +--rw restart-time? uint16 274 | | +--rw stale-routes-time? decimal64 275 | +--rw apply-policy 276 | | +--rw import-policies* -> /rpol:routing-policy/... 277 | | +--rw default-import-policy? default-policy-type 278 | | +--rw export-policies* -> /rpol:routing-policy/... 279 | | +--rw default-export-policy? default-policy-type 280 ... 282 6. Routing protocol-specific policies 284 Routing models that require the ability to apply routing policy may 285 augment the routing policy model with protocol or other specific 286 policy configuration. The routing policy model assumes that 287 additional defined sets, conditions, and actions may all be added by 288 other models. 290 An example of this is shown below, in which the BGP configuration 291 model in [BGP-Model] adds new defined sets to match on community 292 values or AS paths. The model similarly augments BGP-specific 293 conditions and actions into the corresponding sections of the routing 294 policy model. 296 +--rw routing-policy 297 +--rw defined-sets! 298 | +--rw prefix-set* [prefix-set-name] 299 | | +--rw prefix-set-name string 300 | | +--rw prefix* [address masklength masklength-range] 301 | | +--rw address inet:ip-address 302 | | +--rw masklength uint8 303 | | +--rw masklength-range string 304 | +--rw neighbor-set* [neighbor-set-name] 305 | | +--rw neighbor-set-name string 306 | | +--rw neighbor* [address] 307 | | +--rw address inet:ip-address 308 | +--rw tag-set* [tag-set-name] 309 | | +--rw tag-set-name string 310 | | +--rw tag* [value] 311 | | +--rw value pt:tag-type 312 | +--rw bgp-pol:bgp-defined-sets 313 | +--rw bgp-pol:community-set* [community-set-name] 314 | | +--rw bgp-pol:community-set-name string 315 | | +--rw bgp-pol:community-members* union 316 | +--rw bgp-pol:ext-community-set* [ext-community-set-name] 317 | | +--rw bgp-pol:ext-community-set-name string 318 | | +--rw bgp-pol:ext-community-members* union 319 | +--rw bgp-pol:as-path-set* [as-path-set-name] 320 | +--rw bgp-pol:as-path-set-name string 321 | +--rw bgp-pol:as-path-set-members* string 323 7. Security Considerations 325 Routing policy configuration has a significant impact on network 326 operations, and as such any related model carries potential security 327 risks. 329 YANG data models are generally designed to be used with the NETCONF 330 protocol over an SSH transport. This provides an authenticated and 331 secure channel over which to transfer configuration and operational 332 data. Note that use of alternate transport or data encoding (e.g., 333 JSON over HTTPS) would require similar mechanisms for authenticating 334 and securing access to configuration data. 336 Most of the data elements in the policy model could be considered 337 sensitive from a security standpoint. Unauthorized access or invalid 338 data could cause major disruption. 340 8. IANA Considerations 342 This YANG data model and the component modules currently use a 343 temporary ad-hoc namespace. If and when it is placed on redirected 344 for the standards track, an appropriate namespace URI will be 345 registered in the IETF XML Registry" [RFC3688]. The routing policy 346 YANG modules will be registered in the "YANG Module Names" registry 347 [RFC6020]. 349 9. YANG modules 351 The routing policy model is described by the YANG modules in the 352 sections below. 354 9.1. Routing policy model 356 file routing-policy.yang 357 module routing-policy { 359 yang-version "1"; 361 // namespace 362 namespace "http://openconfig.net/yang/routing-policy"; 364 prefix "rpol"; 366 // import some basic types 367 import ietf-inet-types { prefix inet; } 368 import policy-types {prefix pt; } 370 // meta 371 organization 372 "OpenConfig working group"; 374 contact 375 "OpenConfig working group 376 netopenconfig@googlegroups.com"; 378 description 379 "This module describes a YANG model for routing policy 380 configuration. It is a limited subset of all of the policy 381 configuration parameters available in the variety of vendor 382 implementations, but supports widely used constructs for managing 383 how routes are imported, exported, and modified across different 384 routing protocols. This module is intended to be used in 385 conjunction with routing protocol configuration models (e.g., 386 BGP) defined in other modules. 388 Route policy expression: 390 Policies are expressed as a set of top-level policy definitions, 391 each of which consists of a sequence of policy statements. Policy 392 statements consist of simple condition-action tuples. Conditions 393 may include mutiple match or comparison operations, and similarly 394 actions may be multitude of changes to route attributes or a 395 final disposition of accepting or rejecting the route. 397 Route policy evaluation: 399 Policy definitions are referenced in routing protocol 400 configurations using import and export configuration statements. 401 The arguments are members of an ordered list of named policy 402 definitions which comprise a policy chain, and optionally, an 403 explicit default policy action (i.e., reject or accept). 405 Evaluation of each policy definition proceeds by evaluating its 406 corresponding individual policy statements in order. When a 407 condition statement in a policy statement is satisfied, the 408 corresponding action statement is executed. If the action 409 statement has either accept-route or reject-route actions, policy 410 evaluation of the current policy definition stops, and no further 411 policy definitions in the chain are evaluated. 413 If the condition is not satisfied, then evaluation proceeds to 414 the next policy statement. If none of the policy statement 415 conditions are satisfied, then evaluation of the current policy 416 definition stops, and the next policy definition in the chain is 417 evaluated. When the end of the policy chain is reached, the 418 default route disposition action is performed (i.e., reject-route 419 unless an an alternate default action is specified for the 420 chain). 422 Policy 'subroutines' (or nested policies) are supported by 423 allowing policy statement conditions to reference another policy 424 definition which applies conditions and actions from the 425 referenced policy before returning to the calling policy 426 statement and resuming evaluation. If the called policy 427 results in an accept-route (either explicit or by default), then 428 the subroutine returns an effective true value to the calling 429 policy. Similarly, a reject-route action returns false. If the 430 subroutine returns true, the calling policy continues to evaluate 431 the remaining conditions (using a modified route if the 432 subroutine performed any changes to the route)."; 434 revision "2014-11-30" { 435 description 436 "Initial revision"; 437 reference "TBD"; 438 } 440 // typedef statements 442 typedef default-policy-type { 443 type enumeration { 444 enum ACCEPT-ROUTE { 445 description "default policy to accept the route"; 446 } 447 enum REJECT-ROUTE { 448 description "default policy to reject the route"; 449 } 450 } 451 description "type used to specify default route disposition in 452 a policy chain"; 453 } 455 identity install-protocol-type { 456 description 457 "Base type for protocols which can install prefixes into the 458 RIB"; 459 } 461 identity BGP { 462 base install-protocol-type; 463 description "BGP"; 464 reference "RFC 4271"; 465 } 467 identity ISIS { 468 base install-protocol-type; 469 description "IS-IS"; 470 reference "ISO/IEC 10589"; 472 } 474 identity OSPF { 475 base install-protocol-type; 476 description "OSPFv2"; 477 reference "RFC 2328"; 478 } 480 identity OSPF3 { 481 base install-protocol-type; 482 description "OSPFv3"; 483 reference "RFC 5340"; 484 } 486 identity STATIC { 487 base install-protocol-type; 488 description "Locally-installed static route"; 489 } 491 identity DIRECTLY-CONNECTED { 492 base install-protocol-type; 493 description "A directly connected route"; 494 } 496 // grouping statements 498 grouping generic-defined-sets { 499 description 500 "Data definitions for pre-defined sets of attributes used in 501 policy match conditions. These sets are generic and can 502 be used in matching conditions in different routing 503 protocols."; 505 list prefix-set { 506 key prefix-set-name; 507 description 508 "Definitions for prefix sets"; 510 leaf prefix-set-name { 511 type string; 512 description 513 "name / label of the prefix set -- this is used to 514 reference the set in match conditions"; 515 } 517 list prefix { 518 key "address masklength masklength-range"; 519 description 520 "list of prefix expressions that are part of the set"; 522 leaf address { 523 type inet:ip-address; 524 mandatory true; 525 description 526 "address portion of the prefix"; 527 } 529 leaf masklength { 530 type uint8 { 531 // simple range covers both ipv4 and ipv6 -- 532 // could separate this into different types 533 // for IPv4 and IPv6 prefixes 534 range 0..128; 535 } 536 mandatory true; 537 description 538 "masklength for the prefix specification"; 539 } 541 leaf masklength-range { 542 type string { 543 // pattern modeled after ietf-inet-types 544 pattern '(([0-9])|([1-9][0-9])|(1[0-1][0-9])|' 545 + '(12[0-8]))\.\.' 546 + '(([0-9])|([1-9][0-9])|(1[0-1][0-9])|' 547 + '(12[0-8]))'; 548 } 549 description 550 "Defines an optional range for the masklength. Absence 551 of the masklength-length implies that the prefix has an 552 exact masklength given by the masklength parameter. 553 Example: 10.3.192.0/21 through 10.3.192.0/24 would be 554 expressed as address: 10.3.192.0, masklength: 21, 555 masklength-range: 21..24"; 556 } 557 } 558 } 560 list neighbor-set { 561 key neighbor-set-name; 562 description 563 "Definitions for neighbor sets"; 565 leaf neighbor-set-name { 566 type string; 567 description 568 "name / label of the neighbor set -- this is used to 569 reference the set in match conditions"; 570 } 572 list neighbor { 573 key "address"; 574 description 575 "list of addresses that are part of the neighbor set"; 577 leaf address { 578 type inet:ip-address; 579 description 580 "IP address of the neighbor set member"; 581 } 582 } 583 } 585 list tag-set { 586 key tag-set-name; 587 description 588 "Definitions for tag sets"; 590 leaf tag-set-name { 591 type string; 592 description 593 "name / label of the tag set -- this is used to reference 594 the set in match conditions"; 595 } 597 list tag { 598 key "value"; 599 description 600 "list of tags that are part of the tag set"; 602 leaf value { 603 type pt:tag-type; 604 description 605 "Value of the tag set member"; 606 } 607 } 608 } 609 } 611 grouping local-generic-conditions { 612 description 613 "Condition statement definitions for consideration of a local 614 characteristic of a route"; 616 leaf install-protocol-eq { 617 type identityref { 618 base install-protocol-type; 619 } 620 description 621 "Condition to check the protocol / method used to install 622 which installed the route into the local routing table"; 623 } 624 } 626 grouping match-set-options-group { 627 description 628 "Grouping containing options relating to how a particular set 629 should be matched"; 631 leaf match-set-options { 632 type pt:match-set-options-type; 633 description 634 "Optional parameter that governs the behaviour of the 635 match operation"; 636 } 637 } 639 grouping generic-conditions { 640 description "Condition statement definitions for checking 641 membership in a generic defined set"; 643 container match-prefix-set { 644 presence 645 "The presence of this container indicates that the routes 646 should match the prefix-set referenced."; 648 description 649 "Match a referenced prefix-set according to the logic 650 defined in the match-set-options leaf"; 652 leaf prefix-set { 653 type leafref { 654 path "/routing-policy/defined-sets/prefix-set" + 655 "/prefix-set-name"; 656 require-instance true; 657 } 658 description "References a defined prefix set"; 659 } 660 uses match-set-options-group; 661 } 663 container match-neighbor-set { 664 presence 665 "The presence of this container indicates that the routes 666 should match the neighbour set referenced"; 668 description 669 "Match a referenced neighbor set according to the logic 670 defined in the match-set-options-leaf"; 672 leaf neighbor-set { 673 type leafref { 674 path "/routing-policy/defined-sets/neighbor-set" + 675 "/neighbor-set-name"; 676 require-instance true; 677 } 678 description "References a defined neighbor set"; 679 } 680 uses match-set-options-group; 681 } 683 container match-tag-set { 684 presence 685 "The presence of this container indicates that the routes 686 should match the tag-set referenced"; 688 description 689 "Match a referenced tag set according to the logic defined 690 in the match-options-set leaf"; 692 leaf tag-set { 693 type leafref { 694 path "/routing-policy/defined-sets/tag-set" + 695 "/tag-set-name"; 696 require-instance true; 697 } 698 description "References a defined tag set"; 699 } 700 uses match-set-options-group; 701 } 703 uses local-generic-conditions; 704 } 706 grouping igp-generic-conditions { 707 description "grouping for IGP policy conditions"; 709 } 710 grouping igp-conditions { 711 description "grouping for IGP-specific policy conditions"; 713 container igp-conditions { 714 description "Policy conditions for IGP attributes"; 716 uses igp-generic-conditions; 718 } 719 } 721 grouping generic-actions { 722 description 723 "Definitions for common set of policy action statements that 724 manage the disposition or control flow of the policy"; 726 leaf accept-route { 727 type empty; 728 description "accepts the route into the routing table"; 729 } 731 leaf reject-route { 732 type empty; 733 description "rejects the route"; 734 } 735 } 737 grouping igp-actions { 738 description "grouping for IGP-specific policy actions"; 740 container igp-actions { 741 description "Actions to set IGP route attributes; these actions 742 apply to multiple IGPs"; 744 leaf set-tag { 745 type pt:tag-type; 746 description "set the tag value for OSPF or IS-IS routes"; 747 } 748 } 749 } 751 container routing-policy { 752 description 753 "top-level container for all routing policy configuration"; 755 container defined-sets { 756 presence "Container for sets defined for matching in policy 757 statements"; 758 description 759 "Predefined sets of attributes used in policy match 760 statements"; 762 uses generic-defined-sets; 763 // uses bgp-defined-sets; 764 // don't see a need for IGP-specific defined sets at this point 765 // e.g., for OSPF, IS-IS, etc. 766 } 768 list policy-definition { 770 key name; 771 description 772 "List of top-level policy definitions, keyed by unique 773 name. These policy definitions are expected to be 774 referenced (by name) in policy chains specified in import/ 775 export configuration statements."; 777 leaf name { 778 type string; 779 description 780 "Name of the top-level policy definition -- this name 781 is used in references to the current policy"; 782 } 784 list statement { 785 key name; 786 // TODO: names of policy statements within a policy defn 787 // should be optional, however, YANG requires a unique id 788 // for lists; not sure that a compound key works either; 789 // need to investigate further. 790 ordered-by user; 791 description 792 "Policy statements group conditions and actions within 793 a policy definition. They are evaluated in the order 794 specified (see the description of policy evaluation 795 at the top of this module."; 797 leaf name { 798 type string; 799 description "name of the policy statement"; 800 } 802 container conditions { 803 presence "conditions"; 804 description "Condition statements for this 805 policy statement"; 807 leaf call-policy { 808 type leafref { 809 path "/rpol:routing-policy/rpol:policy-definition/" + 810 "rpol:name"; 811 require-instance true; 812 } 813 description 814 "Applies the statements from the specified policy 815 definition and then returns control the current policy 816 statement. Note that the called policy may itself call 817 other policies (subject to implementation limitations). 818 This is intended to provide a policy 'subroutine' 819 capability. The called policy should contain an 820 explicit or a default route disposition that returns an 821 effective true (accept-route) or false (reject-route), 822 otherwise the behavior may be ambiguous and 823 implementation dependent"; 824 } 825 uses generic-conditions; 826 uses igp-conditions; 827 } 829 container actions { 830 presence "actions"; 831 description "Action statements for this policy 832 statement"; 834 uses generic-actions; 835 uses igp-actions; 836 } 837 } 838 } 839 } 841 grouping apply-policy-group { 842 description 843 "configuration for applying policies"; 845 container apply-policy { 846 description 847 "Anchor point for routing policies in the configuration. 848 Import and export policies are with respect to the local 849 routing table, i.e., export (send) and import (receive), 850 depending on the context."; 852 leaf-list import-policies { 853 type leafref { 854 path "/rpol:routing-policy/rpol:policy-definition" + 855 "/rpol:name"; 856 require-instance true; 857 } 858 ordered-by user; 859 description 860 "list of policy names in sequence to be applied on 861 receiving a routing update in the current context, e.g., 862 for the current peer group, neighbor, address family, 863 etc."; 864 } 866 leaf default-import-policy { 867 type default-policy-type; 868 default REJECT-ROUTE; 869 description 870 "explicitly set a default policy if no policy definition 871 in the import policy chain is satisfied."; 872 } 874 leaf-list export-policies { 875 type leafref { 876 path "/rpol:routing-policy/rpol:policy-definition" + 877 "/rpol:name"; 878 require-instance true; 879 } 880 ordered-by user; 881 description 882 "list of policy names in sequence to be applied on 883 sending a routing update in the current context, e.g., 884 for the current peer group, neighbor, address family, 885 etc."; 886 } 888 leaf default-export-policy { 889 type default-policy-type; 890 default REJECT-ROUTE; 891 description 892 "explicitly set a default policy if no policy definition 893 in the export policy chain is satisfied."; 894 } 895 } 896 } 897 } 898 900 9.2. Routing policy types 902 file policy-types.yang 903 module policy-types { 905 yang-version "1"; 907 // namespace 908 namespace "http://openconfig.net/yang/policy-types"; 910 prefix "ptypes"; 912 // import some basic types 913 import ietf-inet-types { prefix inet; } 914 import ietf-yang-types { prefix yang; } 916 // meta 917 organization 918 "OpenConfig working group"; 920 contact 921 "OpenConfig working group 922 netopenconfig@googlegroups.com"; 924 description 925 "This module contains general data definitions for use in routing 926 policy. It can be imported by modules that contain protocol- 927 specific policy conditions and actions."; 929 revision "2014-11-30" { 930 description 931 "Initial revision"; 932 reference "TBD"; 933 } 935 // identity statements 937 identity attribute-comparison { 938 description 939 "base type for supported comparison operators on route 940 attributes"; 941 } 943 identity attribute-eq { 944 base attribute-comparison; 945 description "== comparison"; 946 } 947 identity attribute-ge { 948 base attribute-comparison; 949 description ">= comparison"; 950 } 952 identity attribute-le { 953 base attribute-comparison; 954 description "<= comparison"; 955 } 957 typedef match-set-options-type { 958 type enumeration { 959 enum ANY { 960 description "match is true if given value matches any member 961 of the defined set"; 962 } 963 enum ALL { 964 description "match is true if given value matches all 965 members of the defined set"; 966 } 967 enum INVERT { 968 description "match is true if given value does not match any 969 member of the defined set"; 970 } 971 } 972 default ANY; 973 description 974 "Options that govern the behavior of a match statement. The 975 default behavior is ANY, i.e., the given value matches any 976 of the members of the defined set"; 977 } 979 grouping attribute-compare-operators { 980 description "common definitions for comparison operations in 981 condition statements"; 983 leaf operator { 984 type identityref { 985 base attribute-comparison; 986 } 987 description 988 "type of comparison to be performed"; 989 } 991 leaf value { 992 type uint32; 993 description 994 "value to compare with the community count"; 996 } 997 } 999 typedef tag-type { 1000 type union { 1001 type uint32; 1002 type yang:hex-string; 1003 } 1004 description "type for expressing route tags on a local system, 1005 including IS-IS and OSPF; may be expressed as either decimal or 1006 hexidecimal integer"; 1007 reference 1008 "RFC 2178 OSPF Version 2 1009 RFC 5130 A Policy Control Mechanism in IS-IS Using 1010 Administrative Tags"; 1012 } 1013 } 1014 1016 10. Policy examples 1018 Below we show an example of XML-encoded configuration data using the 1019 routing policy and BGP models to illustrate both how policies are 1020 defined, and also how they can be applied. 1022 1024 1025 1026 1027
A1
1028 M1 1029 1030 1031
A2
1032 M2 1033 1034 1035
A3
1036 M3 1037 1038 1040 1041 cust-tag1 1042 1043 1045 1046 C1 1047 C2 1048 C3 1049 1050 1051 C5 1052 C6 1053 C7 1054 1056 1057 AS1 1058 AS2 1059 ASx 1060 1062 1064 1068 1069 1070 1071 1072 1073 community-set-A 1074 1075 1076 1077 10 1078 1079 1080 1081 1082 IGP 1083 1084 1085 1086 1087 1088 1089 1090 1095 1096 1097 1098 1099 community-set-B 1100 ALL 1101 1102 1103 as-path-set-A 1104 1105 1106 1107 1108 1109 1110 1112 1117 1118 1119 1120 1121 community-set-A 1122 ALL 1123 1124 1125 1126 1127 1128 1129 1131 1136 1137 1138 1139 OSPFV3 1140 cust-tag1 1141 1142 1143 1144 1145 1146 1148 1150 1151 1152 1153 172.95.25.2 1154 ASY 1155 regional peer ASY 1156 EXTERNAL 1157 true 1158 1159 1160 4 1161 1162 1163 1164 policy 2 1165 policy 3 1166 REJECT-ROUTE 1167 1168 1169 1171 11. References 1173 11.1. Normative references 1175 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1176 Network Configuration Protocol (NETCONF)", RFC 6020, 1177 October 2014. 1179 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1180 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1182 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1183 July 2013. 1185 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 1186 2004. 1188 11.2. Informative references 1190 [BGP-Model] 1191 "BGP Configuration Model for Service Provider Networks", 1192 January 2015, 1193 . 1196 Appendix A. Acknowledgements 1198 The authors are grateful for valuable contributions to this document 1199 and the associated models from: Jim Uttaro, Josh George, Vijay Gill, 1200 Ina Minei, Steve Padgett, Ebben Aires, Eric Osborne, Luyuan Fang, 1201 Carl Moberg, Stephane Litkowski, and Russ White. 1203 Authors' Addresses 1205 Anees Shaikh 1206 Google 1207 1600 Amphitheatre Pkwy 1208 Mountain View, CA 94043 1209 US 1211 Email: aashaikh@google.com 1213 Rob Shakir 1214 BT 1215 pp. C3L, BT Centre 1216 81, Newgate Street 1217 London EC1A 7AJ 1218 UK 1220 Email: rob.shakir@bt.com 1221 URI: http://www.bt.com/ 1222 Kevin D'Souza 1223 AT&T 1224 200 S. Laurel Ave 1225 Middletown, NJ 1226 US 1228 Email: kd6913@att.com 1230 Chris Chase 1231 AT&T 1232 9505 Arboretum Blvd 1233 Austin, TX 1234 US 1236 Email: chase@labs.att.com