idnits 2.17.1 draft-ietf-rtgwg-policy-model-01.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 are 2 instances of too long lines in the document, the longest one being 54 characters in excess of 72. == There are 4 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 190 has weird spacing: '...et-name str...' == Line 193 has weird spacing: '...h-range str...' == Line 196 has weird spacing: '...et-name str...' == Line 198 has weird spacing: '...address ine...' == Line 201 has weird spacing: '...et-name str...' == (1 more instance...) -- The document date (April 6, 2016) is 2943 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.openconfig-netmod-opstate' is defined on line 1853, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-01 Summary: 1 error (**), 0 flaws (~~), 10 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: October 8, 2016 Jive Communications 6 K. D'Souza 7 C. Chase 8 AT&T 9 April 6, 2016 11 Routing Policy Configuration Model for Service Provider Networks 12 draft-ietf-rtgwg-policy-model-01 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 October 8, 2016. 38 Copyright Notice 40 Copyright (c) 2016 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 1.1. Goals and approach . . . . . . . . . . . . . . . . . . . 2 57 2. Model overview . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Route policy expression . . . . . . . . . . . . . . . . . . . 4 59 3.1. Defined sets for policy matching . . . . . . . . . . . . 4 60 3.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 7 63 4. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Applying routing policy . . . . . . . . . . . . . . . . . . . 8 65 6. Routing protocol-specific policies . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 9. YANG modules . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Routing policy model . . . . . . . . . . . . . . . . . . 11 70 9.2. Routing policy types . . . . . . . . . . . . . . . . . . 34 71 10. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 38 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 73 11.1. Normative references . . . . . . . . . . . . . . . . . . 39 74 11.2. Informative references . . . . . . . . . . . . . . . . . 40 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40 76 Appendix B. Change summary . . . . . . . . . . . . . . . . . . . 40 77 B.1. Changes between revisions -00 and -01 . . . . . . . . . . 40 78 B.2. Changes between revisions draft-shaikh-rtgwg-policy-model 79 and -00 . . . . . . . . . . . . . . . . . . . . . . . . . 40 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 82 1. Introduction 84 This document describes a YANG [RFC6020] data model for routing 85 policy configuration based on operational usage and best practices in 86 a variety of service provider networks. The model is intended to be 87 vendor-neutral, in order to allow operators to manage policy 88 configuration in a consistent, intuitive way in heterogeneous 89 environments with routers supplied by multiple vendors. 91 1.1. Goals and approach 93 This model does not aim to be feature complete -- it is a subset of 94 the policy configuration parameters available in a variety of vendor 95 implementations, but supports widely used constructs for managing how 96 routes are imported, exported, and modified across different routing 97 protocols. The model development approach has been to examine actual 98 policy configurations in use across a number of operator networks. 99 Hence the focus is on enabling policy configuration capabilities and 100 structure that are in wide use. 102 Despite the differences in details of policy expressions and 103 conventions in various vendor implementations, the model reflects the 104 observation that a relatively simple condition- action approach can 105 be readily mapped to several existing vendor implementations, and 106 also gives operators an intuitive and straightforward way to express 107 policy without sacrificing flexibility. A side affect of this design 108 decision is that legacy methods for expressing policies are not 109 considered. Such methods could be added as an augmentation to the 110 model if needed. 112 Consistent with the goal to produce a data model that is vendor 113 neutral, only policy expressions that are deemed to be widely 114 available in existing major implementations are included in the 115 model. Those configuration items that are only available from a 116 single implementation are omitted from the model with the expectation 117 they will be available in separate vendor-provided modules that 118 augment the current model. 120 2. Model overview 122 The routing policy model is defined in two YANG modules, the main 123 policy module, and an auxiliary module providing additional generic 124 types. The model has three main parts: 126 o A generic framework to express policies as sets of related 127 conditions and actions. This includes match sets and actions that 128 are useful across many routing protocols. 130 o A structure that allows routing protocol models to add protocol- 131 specific policy conditions and actions though YANG augmentations. 132 There is a complete example of this for BGP [RFC4271] policies in 133 the proposed vendor-neutral BGP data model 134 [I-D.ietf-idr-bgp-model]. 136 o A reusable grouping for attaching import and export rules in the 137 context of routing configuration for different protocols, VRFs, 138 etc. This also enables creation of policy chains and expressing 139 default policy behavior. 141 These modules make use of the standard Internet types, such as IP 142 addresses, autonomous system numbers, etc., defined in RFC 6991 143 [RFC6991]. 145 3. Route policy expression 147 Policies are expressed as a sequence of top-level policy definitions 148 each of which consists of a sequence of policy statements. Policy 149 statements in turn consist of simple condition-action tuples. 150 Conditions may include multiple match or comparison operations, and 151 similarly, actions may effect multiple changes to route attributes, 152 or indicate a final disposition of accepting or rejecting the route. 153 This structure is shown below. 155 +--rw routing-policy 156 +--rw policy-definitions 157 +--rw policy-definition* [name] 158 +--rw name string 159 +--rw statements 160 +--rw statement* [name] 161 +--rw name string 162 +--rw conditions 163 | ... 164 +--rw actions 165 ... 167 3.1. Defined sets for policy matching 169 The models provides a set of generic sets that can be used for 170 matching in policy conditions. These sets are applicable across 171 multiple routing protocols, and may be further augmented by protocol- 172 specific models which have their own defined sets. The supported 173 defined sets include: 175 o prefix sets - define a set of IP prefixes, each with an associated 176 CIDR netmask range (or exact length) 178 o neighbor sets - define a set of neighboring nodes by their IP 179 addresses 181 o tag set - define a set of generic tag values that can be used in 182 matches for filtering routes 184 The model structure for defined sets is shown below. 186 +--rw routing-policy 187 +--rw defined-sets 188 +--rw prefix-sets 189 | +--rw prefix-set* [prefix-set-name] 190 | +--rw prefix-set-name string 191 | +--rw prefix* [ip-prefix masklength-range] 192 | +--rw ip-prefix inet:ip-prefix 193 | +--rw masklength-range string 194 +--rw neighbor-sets 195 | +--rw neighbor-set* [neighbor-set-name] 196 | +--rw neighbor-set-name string 197 | +--rw neighbor* [address] 198 | +--rw address inet:ip-address 199 +--rw tag-sets 200 +--rw tag-set* [tag-set-name] 201 +--rw tag-set-name string 202 +--rw tag* [value] 203 +--rw value pt:tag-type 205 3.2. Policy conditions 207 Policy statements consist of a set of conditions and actions (either 208 of which may be empty). Conditions are used to match route 209 attributes against a defined set (e.g., a prefix set), or to compare 210 attributes against a specific value. 212 Match conditions may be further modified using the match-set-options 213 configuration which allows operators to change the behavior of a 214 match. Three options are supported: 216 o ALL - match is true only if the given value matches all members of 217 the set. 219 o ANY - match is true if the given value matches any member of the 220 set. 222 o INVERT - match is true if the given value does not match any 223 member of the given set. 225 Not all options are appropriate for matching against all defined sets 226 (e.g., match ALL in a prefix set does not make sense). In the model, 227 a restricted set of match options is used where applicable. 229 Comparison conditions may similarly use options to change how route 230 attributes should be tested, e.g., for equality or inequality, 231 against a given value. 233 While most policy conditions will be added by individual routing 234 protocol models via augmentation, this routing policy model includes 235 several generic match conditions and also the ability to test which 236 protocol or mechanism installed a route (e.g., BGP, IGP, static, 237 etc.). The conditions included in the model are shown below. 239 +--rw routing-policy 240 +--rw policy-definitions 241 +--rw policy-definition* [name] 242 +--rw statements 243 +--rw statement* [name] 244 +--rw conditions 245 +--rw call-policy? 246 +--rw match-interface? 247 +--rw match-prefix-set! 248 | +--rw prefix-set? 249 | +--rw match-set-options? 250 +--rw match-neighbor-set! 251 | +--rw neighbor-set? 252 | +--rw match-set-options? 253 +--rw match-tag-set! 254 | +--rw tag-set? 255 | +--rw match-set-options? 256 +--rw install-protocol-eq? 257 +--rw igp-conditions 259 3.3. Policy actions 261 When policy conditions are satisfied, policy actions are used to set 262 various attributes of the route being processed, or to indicate the 263 final disposition of the route, i.e., accept or reject. 265 Similar to policy conditions, the routing policy model includes 266 generic actions in addition to the basic route disposition actions. 267 These are shown below. 269 +--rw routing-policy 270 +--rw policy-definitions 271 +--rw policy-definition* [name] 272 +--rw statements 273 +--rw statement* [name] 274 +--rw actions 275 +--rw (route-disposition)? 276 | +--:(accept-route) 277 | | +--rw accept-route? empty 278 | +--:(reject-route) 279 | +--rw reject-route? empty 280 +--rw igp-actions 281 +--rw set-tag? pt:tag-type 283 3.4. Policy subroutines 285 Policy 'subroutines' (or nested policies) are supported by allowing 286 policy statement conditions to reference other policy definitions 287 using the call-policy configuration. Called policies apply their 288 conditions and actions before returning to the calling policy 289 statement and resuming evaluation. The outcome of the called policy 290 affects the evaluation of the calling policy. If the called policy 291 results in an accept-route (either explicit or by default), then the 292 subroutine returns an effective boolean true value to the calling 293 policy. For the calling policy, this is equivalent to a condition 294 statement evaluating to a true value and evaluation of the policy 295 continues (see Section 4). Note that the called policy may also 296 modify attributes of the route in its action statements. Similarly, 297 a reject-route action returns false and the calling policy evaluation 298 will be affected accordingly. 300 Note that the called policy may itself call other policies (subject 301 to implementation limitations). The model does not prescribe a 302 nesting depth because this varies among implementations, with some 303 major implementations only supporting a single subroutine, for 304 example. As with any routing policy construction, care must be taken 305 with nested policies to ensure that the effective return value 306 results in the intended behavior. Nested policies are a convenience 307 in many routing policy constructions but creating policies nested 308 beyond a small number of levels (e.g., 2-3) should be discouraged. 310 4. Policy evaluation 312 Evaluation of each policy definition proceeds by evaluating its 313 corresponding individual policy statements in order. When a 314 condition statement in a policy statement is satisfied, the 315 corresponding action statement is executed. If the action statement 316 has either accept-route or reject-route actions, evaluation of the 317 current policy definition stops, and no further policy definitions in 318 the chain are evaluated. 320 If the condition is not satisfied, then evaluation proceeds to the 321 next policy statement. If none of the policy statement conditions 322 are satisfied, then evaluation of the current policy definition 323 stops, and the next policy definition in the chain is evaluated. 324 When the end of the policy chain is reached, the default route 325 disposition action is performed (i.e., reject-route unless an an 326 alternate default action is specified for the chain). 328 5. Applying routing policy 330 Routing policy is applied by defining and attaching policy chains in 331 various routing contexts. Policy chains are sequences of policy 332 definitions (described in Section 3) that have an associated 333 direction (import or export) with respect to the routing context in 334 which they are defined. The routing policy model defines an apply- 335 policy grouping that can be imported and used by other models. As 336 shown below, it allows definition of import and export policy chains, 337 as well as specifying the default route disposition to be used when 338 no policy definition in the chain results in a final decision. 340 +--rw apply-policy 341 | +--rw config 342 | | +--rw import-policy* 343 | | +--rw default-import-policy? default-policy-type 344 | | +--rw export-policy* 345 | | +--rw default-export-policy? default-policy-type 347 The default policy defined by the model is to reject the route for 348 both import and export policies. 350 An example of using the apply-policy group in another routing model 351 is shown below for BGP. Here, import and export policies are applied 352 in the context of a particular BGP peer group. Note that the policy 353 chains reference policy definitions by name that are defined in the 354 routing policy model. 356 +--rw bgp! 357 +--rw peer-groups 358 +--rw peer-group* [peer-group-name] 359 +--rw peer-group-name 360 +--rw config 361 | +--rw peer-as? 362 | +--rw local-as? 363 | +--rw peer-type? 364 | +--rw auth-password? 365 | +--rw remove-private-as? 366 | +--rw route-flap-damping? 367 | +--rw send-community? 368 | +--rw description? 369 | +--rw peer-group-name? 370 +--ro state 371 | +--ro peer-as? 372 | +--ro local-as? 373 | +--ro peer-type? 374 | +--ro auth-password? 375 | +--ro remove-private-as? 376 | +--ro route-flap-damping? 377 | +--ro send-community? 378 | +--ro description? 379 | +--ro peer-group-name? 380 | +--ro total-paths? 381 | +--ro total-prefixes? 382 +--rw apply-policy 383 | +--rw config 384 | | +--rw import-policy* 385 | | +--rw default-import-policy? 386 | | +--rw export-policy* 387 | | +--rw default-export-policy? 388 | +--ro state 389 | +--ro import-policy* 390 | +--ro default-import-policy? 391 | +--ro export-policy* 392 | +--ro default-export-policy? 393 ... 395 6. Routing protocol-specific policies 397 Routing models that require the ability to apply routing policy may 398 augment the routing policy model with protocol or other specific 399 policy configuration. The routing policy model assumes that 400 additional defined sets, conditions, and actions may all be added by 401 other models. 403 An example of this is shown below, in which the BGP configuration 404 model in [I-D.ietf-idr-bgp-model] adds new defined sets to match on 405 community values or AS paths. The model similarly augments BGP- 406 specific conditions and actions into the corresponding sections of 407 the routing policy model. 409 +--rw routing-policy 410 +--rw defined-sets 411 +--rw prefix-sets 412 | +--rw prefix-set* [prefix-set-name] 413 | +--rw prefix-set-name 414 | +--rw prefix* [ip-prefix masklength-range] 415 | +--rw ip-prefix 416 | +--rw masklength-range 417 +--rw neighbor-sets 418 | +--rw neighbor-set* [neighbor-set-name] 419 | +--rw neighbor-set-name 420 | +--rw neighbor* [address] 421 | +--rw address 422 +--rw tag-sets 423 | +--rw tag-set* [tag-set-name] 424 | +--rw tag-set-name 425 | +--rw tag* [value] 426 | +--rw value 427 +--rw bgp-pol:bgp-defined-sets 428 +--rw bgp-pol:community-sets 429 | +--rw bgp-pol:community-set* [community-set-name] 430 | +--rw bgp-pol:community-set-name 431 | +--rw bgp-pol:community-member* 432 +--rw bgp-pol:ext-community-sets 433 | +--rw bgp-pol:ext-community-set* [ext-community-set-name] 434 | +--rw bgp-pol:ext-community-set-name 435 | +--rw bgp-pol:ext-community-member* 436 +--rw bgp-pol:as-path-sets 437 +--rw bgp-pol:as-path-set* [as-path-set-name] 438 +--rw bgp-pol:as-path-set-name 439 +--rw bgp-pol:as-path-set-member* 441 7. Security Considerations 443 Routing policy configuration has a significant impact on network 444 operations, and as such any related model carries potential security 445 risks. 447 YANG data models are generally designed to be used with the NETCONF 448 protocol over an SSH transport. This provides an authenticated and 449 secure channel over which to transfer configuration and operational 450 data. Note that use of alternate transport or data encoding (e.g., 451 JSON over HTTPS) would require similar mechanisms for authenticating 452 and securing access to configuration data. 454 Most of the data elements in the policy model could be considered 455 sensitive from a security standpoint. Unauthorized access or invalid 456 data could cause major disruption. 458 8. IANA Considerations 460 This YANG data model and the component modules currently use a 461 temporary ad-hoc namespace. If and when it is placed on redirected 462 for the standards track, an appropriate namespace URI will be 463 registered in the IETF XML Registry" [RFC3688]. The routing policy 464 YANG modules will be registered in the "YANG Module Names" registry 465 [RFC6020]. 467 9. YANG modules 469 The routing policy model is described by the YANG modules in the 470 sections below. 472 9.1. Routing policy model 474 file "openconfig-routing-policy.yang" 475 module openconfig-routing-policy { 477 yang-version "1"; 479 // namespace 480 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; 482 prefix "oc-rpol"; 484 // import some basic types 485 import ietf-inet-types { prefix inet; } 486 import openconfig-interfaces { prefix oc-if; } 487 import openconfig-policy-types { prefix oc-pol-types; } 488 import openconfig-extensions { prefix oc-ext; } 490 // meta 491 organization 492 "OpenConfig working group"; 494 contact 495 "OpenConfig working group 496 netopenconfig@googlegroups.com"; 498 description 499 "This module describes a YANG model for routing policy 500 configuration. It is a limited subset of all of the policy 501 configuration parameters available in the variety of vendor 502 implementations, but supports widely used constructs for managing 503 how routes are imported, exported, and modified across different 504 routing protocols. This module is intended to be used in 505 conjunction with routing protocol configuration models (e.g., 506 BGP) defined in other modules. 508 Route policy expression: 510 Policies are expressed as a set of top-level policy definitions, 511 each of which consists of a sequence of policy statements. Policy 512 statements consist of simple condition-action tuples. Conditions 513 may include mutiple match or comparison operations, and similarly 514 actions may be multitude of changes to route attributes or a 515 final disposition of accepting or rejecting the route. 517 Route policy evaluation: 519 Policy definitions are referenced in routing protocol 520 configurations using import and export configuration statements. 521 The arguments are members of an ordered list of named policy 522 definitions which comprise a policy chain, and optionally, an 523 explicit default policy action (i.e., reject or accept). 525 Evaluation of each policy definition proceeds by evaluating its 526 corresponding individual policy statements in order. When a 527 condition statement in a policy statement is satisfied, the 528 corresponding action statement is executed. If the action 529 statement has either accept-route or reject-route actions, policy 530 evaluation of the current policy definition stops, and no further 531 policy definitions in the chain are evaluated. 533 If the condition is not satisfied, then evaluation proceeds to 534 the next policy statement. If none of the policy statement 535 conditions are satisfied, then evaluation of the current policy 536 definition stops, and the next policy definition in the chain is 537 evaluated. When the end of the policy chain is reached, the 538 default route disposition action is performed (i.e., reject-route 539 unless an an alternate default action is specified for the 540 chain). 542 Policy 'subroutines' (or nested policies) are supported by 543 allowing policy statement conditions to reference another policy 544 definition which applies conditions and actions from the 545 referenced policy before returning to the calling policy 546 statement and resuming evaluation. If the called policy 547 results in an accept-route (either explicit or by default), then 548 the subroutine returns an effective true value to the calling 549 policy. Similarly, a reject-route action returns false. If the 550 subroutine returns true, the calling policy continues to evaluate 551 the remaining conditions (using a modified route if the 552 subroutine performed any changes to the route)."; 554 oc-ext:openconfig-version "2.0.0"; 556 revision "2016-03-28" { 557 description 558 "OpenConfig public release"; 559 reference "2.0.0"; 560 } 562 // typedef statements 564 typedef default-policy-type { 565 type enumeration { 566 enum ACCEPT_ROUTE { 567 description "default policy to accept the route"; 568 } 569 enum REJECT_ROUTE { 570 description "default policy to reject the route"; 571 } 572 } 573 description "type used to specify default route disposition in 574 a policy chain"; 575 } 577 // grouping statements 579 grouping prefix-set-config { 580 description 581 "Configuration data for prefix sets used in policy 582 definitions."; 584 leaf prefix-set-name { 585 type string; 586 description 587 "name / label of the prefix set -- this is used to 588 reference the set in match conditions"; 589 } 591 } 592 grouping prefix-set-state { 593 description 594 "Operational state data for prefix sets"; 595 } 597 grouping prefix-set-top { 598 description 599 "Top-level data definitions for a list of IPv4 or IPv6 600 prefixes which are matched as part of a policy"; 602 container prefix-sets { 603 description 604 "Enclosing container "; 606 list prefix-set { 607 key prefix-set-name; 608 description 609 "List of the defined prefix sets"; 611 leaf prefix-set-name { 612 type leafref { 613 path "../config/prefix-set-name"; 614 } 615 description 616 "Reference to prefix name list key"; 617 } 619 container config { 620 description 621 "Configuration data for prefix sets"; 623 uses prefix-set-config; 624 } 626 container state { 628 config false; 630 description 631 "Operational state data "; 633 uses prefix-set-config; 634 uses prefix-set-state; 635 } 637 uses prefix-top; 638 } 639 } 641 } 643 grouping prefix-config { 644 description 645 "Configuration data for a prefix definition"; 647 leaf ip-prefix { 648 type inet:ip-prefix; 649 mandatory true; 650 description 651 "The prefix member in CIDR notation -- while the 652 prefix may be either IPv4 or IPv6, most 653 implementations require all members of the prefix set 654 to be the same address family. Mixing address types in 655 the same prefix set is likely to cause an error."; 656 } 658 leaf masklength-range { 659 type string { 660 pattern '^([0-9]+\.\.[0-9]+)|exact$'; 661 } 662 description 663 "Defines a range for the masklength, or 'exact' if 664 the prefix has an exact length. 666 Example: 10.3.192.0/21 through 10.3.192.0/24 would be 667 expressed as prefix: 10.3.192.0/21, 668 masklength-range: 21..24. 670 Example: 10.3.192.0/21 would be expressed as 671 prefix: 10.3.192.0/21, 672 masklength-range: exact"; 673 } 674 } 676 grouping prefix-state { 677 description 678 "Operational state data for prefix definitions"; 679 } 681 grouping prefix-top { 682 description 683 "Top-level grouping for prefixes in a prefix list"; 685 container prefixes { 686 description 687 "Enclosing container for the list of prefixes in a policy 688 prefix list"; 690 list prefix { 691 key "ip-prefix masklength-range"; 692 description 693 "List of prefixes in the prefix set"; 695 leaf ip-prefix { 696 type leafref { 697 path "../config/ip-prefix"; 698 } 699 description 700 "Reference to the ip-prefix list key."; 701 } 703 leaf masklength-range { 704 type leafref { 705 path "../config/masklength-range"; 706 } 707 description 708 "Reference to the masklength-range list key"; 709 } 711 container config { 712 description 713 "Configuration data for prefix definition"; 715 uses prefix-config; 716 } 718 container state { 720 config false; 722 description 723 "Operational state data for prefix definition"; 725 uses prefix-config; 726 uses prefix-state; 727 } 728 } 729 } 730 } 732 grouping neighbor-set-config { 733 description 734 "Configuration data for neighbor set definitions"; 736 leaf neighbor-set-name { 737 type string; 738 description 739 "name / label of the neighbor set -- this is used to 740 reference the set in match conditions"; 741 } 743 leaf-list address { 744 type inet:ip-address; 745 description 746 "List of IP addresses in the neighbor set"; 747 } 748 } 750 grouping neighbor-set-state { 751 description 752 "Operational state data for neighbor set definitions"; 753 } 755 grouping neighbor-set-top { 756 description 757 "Top-level data definition for a list of IPv4 or IPv6 758 neighbors which can be matched in a routing policy"; 760 container neighbor-sets { 761 description 762 "Enclosing container for the list of neighbor set 763 definitions"; 765 list neighbor-set { 766 key neighbor-set-name; 767 description 768 "List of defined neighbor sets for use in policies."; 770 leaf neighbor-set-name { 771 type leafref { 772 path "../config/neighbor-set-name"; 773 } 774 description 775 "Reference to the neighbor set name list key."; 776 } 778 container config { 779 description 780 "Configuration data for neighbor sets."; 782 uses neighbor-set-config; 783 } 785 container state { 786 config false; 788 description 789 "Operational state data for neighbor sets."; 791 uses neighbor-set-config; 792 uses neighbor-set-state; 793 } 794 } 795 } 796 } 798 grouping tag-set-config { 799 description 800 "Configuration data for tag set definitions."; 802 leaf tag-set-name { 803 type string; 804 description 805 "name / label of the tag set -- this is used to reference 806 the set in match conditions"; 807 } 809 leaf-list tag-value { 810 type oc-pol-types:tag-type; 811 description 812 "Value of the tag set member"; 813 } 814 } 816 grouping tag-set-state { 817 description 818 "Operational state data for tag set definitions."; 819 } 821 grouping tag-set-top { 822 description 823 "Top-level data definitions for a list of tags which can 824 be matched in policies"; 826 container tag-sets { 827 description 828 "Enclosing container for the list of tag sets."; 830 list tag-set { 831 key tag-set-name; 832 description 833 "List of tag set definitions."; 835 leaf tag-set-name { 836 type leafref { 837 path "../config/tag-set-name"; 838 } 839 description 840 "Reference to the tag set name list key"; 841 } 843 container config { 844 description 845 "Configuration data for tag sets"; 847 uses tag-set-config; 848 } 850 container state { 852 config false; 854 description 855 "Operational state data for tag sets"; 857 uses tag-set-config; 858 uses tag-set-state; 859 } 860 } 861 } 862 } 864 grouping generic-defined-sets { 865 description 866 "Data definitions for pre-defined sets of attributes used in 867 policy match conditions. These sets are generic and can 868 be used in matching conditions in different routing 869 protocols."; 871 uses prefix-set-top; 872 uses neighbor-set-top; 873 uses tag-set-top; 874 } 876 grouping match-set-options-group { 877 description 878 "Grouping containing options relating to how a particular set 879 should be matched"; 881 leaf match-set-options { 882 type oc-pol-types:match-set-options-type; 883 description 884 "Optional parameter that governs the behaviour of the 885 match operation"; 886 } 887 } 889 grouping match-set-options-restricted-group { 890 description 891 "Grouping for a restricted set of match operation modifiers"; 893 leaf match-set-options { 894 type oc-pol-types:match-set-options-restricted-type; 895 description 896 "Optional parameter that governs the behaviour of the 897 match operation. This leaf only supports matching on ANY 898 member of the set or inverting the match. Matching on ALL is 899 not supported)"; 900 } 901 } 903 grouping match-interface-condition-config { 904 description 905 "Configuration data for interface match condition"; 907 uses oc-if:interface-ref-common; 908 } 910 grouping match-interface-condition-state { 911 description 912 "Operational state data for interface match condition"; 913 } 915 grouping match-interface-condition-top { 916 description 917 "Top-level grouping for the interface match condition"; 919 container match-interface { 920 description 921 "Top-level container for interface match conditions"; 923 container config { 924 description 925 "Configuration data for interface match conditions"; 927 uses match-interface-condition-config; 928 } 930 container state { 931 config false; 933 description 934 "Operational state data for interface match conditions"; 936 uses match-interface-condition-config; 937 uses match-interface-condition-state; 938 } 940 } 941 } 943 grouping prefix-set-condition-config { 944 description 945 "Configuration data for prefix-set conditions"; 947 leaf prefix-set { 948 type leafref { 949 path "/routing-policy/defined-sets/prefix-sets/" + 950 "prefix-set/prefix-set-name"; 951 //TODO: require-instance should be added when it's 952 //supported in YANG 1.1 953 //require-instance true; 954 } 955 description "References a defined prefix set"; 956 } 957 uses match-set-options-restricted-group; 958 } 960 grouping prefix-set-condition-state { 961 description 962 "Operational state data for prefix-set conditions"; 963 } 965 grouping prefix-set-condition-top { 966 description 967 "Top-level grouping for prefix-set conditions"; 969 container match-prefix-set { 970 description 971 "Match a referenced prefix-set according to the logic 972 defined in the match-set-options leaf"; 974 container config { 975 description 976 "Configuration data for a prefix-set condition"; 978 uses prefix-set-condition-config; 980 } 982 container state { 984 config false; 986 description 987 "Operational state data for a prefix-set condition"; 989 uses prefix-set-condition-config; 990 uses prefix-set-condition-state; 991 } 992 } 993 } 995 grouping neighbor-set-condition-config { 996 description 997 "Configuration data for neighbor-set conditions"; 999 leaf neighbor-set { 1000 type leafref { 1001 path "/routing-policy/defined-sets/neighbor-sets/" + 1002 "neighbor-set/neighbor-set-name"; 1003 //TODO: require-instance should be added when it's 1004 //supported in YANG 1.1 1005 //require-instance true; 1006 } 1007 description "References a defined neighbor set"; 1008 } 1010 uses match-set-options-restricted-group; 1011 } 1013 grouping neighbor-set-condition-state { 1014 description 1015 "Operational state data for neighbor-set conditions"; 1016 } 1018 grouping neighbor-set-condition-top { 1019 description 1020 "Top-level grouping for neighbor-set conditions"; 1022 container match-neighbor-set { 1023 description 1024 "Match a referenced neighbor set according to the logic 1025 defined in the match-set-options-leaf"; 1027 container config { 1028 description 1029 "Configuration data "; 1031 uses neighbor-set-condition-config; 1032 } 1034 container state { 1036 config false; 1038 description 1039 "Operational state data "; 1041 uses neighbor-set-condition-config; 1042 uses neighbor-set-condition-state; 1043 } 1044 } 1045 } 1047 grouping tag-set-condition-config { 1048 description 1049 "Configuration data for tag-set condition statements"; 1051 leaf tag-set { 1052 type leafref { 1053 path "/routing-policy/defined-sets/tag-sets/tag-set" + 1054 "/tag-set-name"; 1055 //TODO: require-instance should be added when it's 1056 //supported in YANG 1.1 1057 //require-instance true; 1058 } 1059 description "References a defined tag set"; 1060 } 1061 uses match-set-options-restricted-group; 1062 } 1064 grouping tag-set-condition-state { 1065 description 1066 "Operational state data for tag-set condition statements"; 1067 } 1069 grouping tag-set-condition-top { 1070 description 1071 "Top-level grouping for tag-set conditions"; 1073 container match-tag-set { 1074 description 1075 "Match a referenced tag set according to the logic defined 1076 in the match-options-set leaf"; 1078 container config { 1079 description 1080 "Configuration data for tag-set conditions"; 1082 uses tag-set-condition-config; 1083 } 1085 container state { 1087 config false; 1089 description 1090 "Operational state data tag-set conditions"; 1092 uses tag-set-condition-config; 1093 uses tag-set-condition-state; 1094 } 1095 } 1096 } 1098 grouping generic-conditions { 1099 description "Condition statement definitions for checking 1100 membership in a generic defined set"; 1102 uses match-interface-condition-top; 1103 uses prefix-set-condition-top; 1104 uses neighbor-set-condition-top; 1105 uses tag-set-condition-top; 1107 } 1109 grouping igp-generic-conditions { 1110 description "grouping for IGP policy conditions"; 1112 } 1114 grouping igp-conditions { 1115 description "grouping for IGP-specific policy conditions"; 1117 container igp-conditions { 1118 description "Policy conditions for IGP attributes"; 1120 uses igp-generic-conditions; 1122 } 1124 } 1126 grouping generic-actions { 1127 description 1128 "Definitions for common set of policy action statements that 1129 manage the disposition or control flow of the policy"; 1131 choice route-disposition { 1132 description 1133 "Select the final disposition for the route, either 1134 accept or reject."; 1135 leaf accept-route { 1136 type empty; 1137 description "accepts the route into the routing table"; 1138 } 1140 leaf reject-route { 1141 type empty; 1142 description "rejects the route"; 1143 } 1144 } 1145 } 1147 grouping igp-actions-config { 1148 description 1149 "Configuration data for IGP policy actions"; 1151 leaf set-tag { 1152 type oc-pol-types:tag-type; 1153 description 1154 "Set the tag value for OSPF or IS-IS routes."; 1155 } 1156 } 1158 grouping igp-actions-state { 1159 description 1160 "Operational state data for IGP policy actions "; 1161 } 1163 grouping igp-actions-top { 1164 description 1165 "Top-level grouping "; 1167 container igp-actions { 1168 description 1169 "Actions to set IGP route attributes; these actions 1170 apply to multiple IGPs"; 1172 container config { 1173 description 1174 "Configuration data "; 1176 uses igp-actions-config; 1177 } 1179 container state { 1181 config false; 1183 description 1184 "Operational state data "; 1186 uses igp-actions-config; 1187 uses igp-actions-state; 1188 } 1189 } 1190 } 1192 grouping policy-conditions-config { 1193 description 1194 "Configuration data for general policy conditions, i.e., those 1195 not related to match-sets"; 1197 leaf call-policy { 1198 type leafref { 1199 path "/oc-rpol:routing-policy/" + 1200 "oc-rpol:policy-definitions/" + 1201 "oc-rpol:policy-definition/oc-rpol:name"; 1202 //TODO: require-instance should be added when 1203 //it is supported in YANG 1.1 1204 //require-instance true; 1205 } 1206 description 1207 "Applies the statements from the specified policy 1208 definition and then returns control the current 1209 policy statement. Note that the called policy may 1210 itself call other policies (subject to 1211 implementation limitations). This is intended to 1212 provide a policy 'subroutine' capability. The 1213 called policy should contain an explicit or a 1214 default route disposition that returns an 1215 effective true (accept-route) or false 1216 (reject-route), otherwise the behavior may be 1217 ambiguous and implementation dependent"; 1218 } 1219 leaf install-protocol-eq { 1220 type identityref { 1221 base oc-pol-types:INSTALL_PROTOCOL_TYPE; 1222 } 1223 description 1224 "Condition to check the protocol / method used to install 1225 the route into the local routing table"; 1226 } 1227 } 1229 grouping policy-conditions-state { 1230 description 1231 "Operational state data for policy conditions"; 1232 } 1234 grouping policy-conditions-top { 1235 description 1236 "Top-level grouping for policy conditions"; 1238 container conditions { 1239 description 1240 "Condition statements for the current policy statement"; 1242 container config { 1243 description 1244 "Configuration data for policy conditions"; 1246 uses policy-conditions-config; 1247 } 1249 container state { 1251 config false; 1253 description 1254 "Operational state data for policy conditions"; 1256 uses policy-conditions-config; 1257 uses policy-conditions-state; 1258 } 1259 uses generic-conditions; 1260 uses igp-conditions; 1261 } 1262 } 1264 grouping policy-statements-config { 1265 description 1266 "Configuration data for policy statements"; 1268 leaf name { 1269 type string; 1270 description 1271 "name of the policy statement"; 1272 } 1273 } 1275 grouping policy-statements-state { 1276 description 1277 "Operational state data for policy statements"; 1278 } 1280 grouping policy-actions-config { 1281 description 1282 "Configuration data for policy actions"; 1284 uses generic-actions; 1285 } 1287 grouping policy-actions-state { 1288 description 1289 "Operational state data for policy actions"; 1290 } 1292 grouping policy-actions-top { 1293 description 1294 "Top-level grouping for policy actions"; 1296 container actions { 1297 description 1298 "Top-level container for policy action statements"; 1300 container config { 1301 description 1302 "Configuration data for policy actions"; 1304 uses policy-actions-config; 1305 } 1307 container state { 1309 config false; 1311 description 1312 "Operational state data for policy actions"; 1314 uses policy-actions-config; 1315 uses policy-actions-state; 1316 } 1318 uses igp-actions-top; 1319 } 1320 } 1322 grouping policy-statements-top { 1323 description 1324 "Top-level grouping for the policy statements list"; 1326 container statements { 1327 description 1328 "Enclosing container for policy statements"; 1330 list statement { 1331 key name; 1332 // TODO: names of policy statements within a policy 1333 // definition should be optional, however, YANG 1334 // requires a unique id for lists; not sure that a 1335 // compound key works either -- need to investigate 1336 // further. 1337 ordered-by user; 1338 description 1339 "Policy statements group conditions and actions 1340 within a policy definition. They are evaluated in 1341 the order specified (see the description of policy 1342 evaluation at the top of this module."; 1344 leaf name { 1345 type leafref { 1346 path "../config/name"; 1347 } 1348 description 1349 "Reference to list key"; 1350 } 1352 container config { 1353 description 1354 "Configuration data for policy statements"; 1356 uses policy-statements-config; 1357 } 1359 container state { 1361 config false; 1362 description 1363 "Operational state data for policy statements"; 1365 uses policy-statements-config; 1366 uses policy-statements-state; 1367 } 1369 uses policy-conditions-top; 1370 uses policy-actions-top; 1371 } 1372 } 1373 } 1375 grouping defined-sets-top { 1376 description 1377 "Top-level grouping for defined set definitions"; 1379 container defined-sets { 1380 description 1381 "Predefined sets of attributes used in policy match 1382 statements"; 1384 uses generic-defined-sets; 1385 } 1386 } 1388 grouping policy-definitions-config { 1389 description 1390 "Configuration data for policy definitions"; 1392 leaf name { 1393 type string; 1394 description 1395 "Name of the top-level policy definition -- this name 1396 is used in references to the current policy"; 1397 } 1398 } 1400 grouping policy-definitions-state { 1401 description 1402 "Operational state data for policy definitions"; 1403 } 1405 grouping policy-definitions-top { 1406 description 1407 "Top-level grouping for the policy definition list"; 1409 container policy-definitions { 1410 description 1411 "Enclosing container for the list of top-level policy 1412 definitions"; 1414 list policy-definition { 1415 key name; 1416 description 1417 "List of top-level policy definitions, keyed by unique 1418 name. These policy definitions are expected to be 1419 referenced (by name) in policy chains specified in import 1420 or export configuration statements."; 1422 leaf name { 1423 type leafref { 1424 path "../config/name"; 1425 } 1426 description 1427 "Reference to the list key"; 1428 } 1430 container config { 1431 description 1432 "Configuration data for policy defintions"; 1434 uses policy-definitions-config; 1435 } 1437 container state { 1439 config false; 1441 description 1442 "Operational state data for policy definitions"; 1444 uses policy-definitions-config; 1445 uses policy-definitions-state; 1446 } 1448 uses policy-statements-top; 1449 } 1450 } 1451 } 1453 grouping routing-policy-top { 1454 description 1455 "Top level container for OpenConfig routing policy"; 1457 container routing-policy { 1458 description 1459 "Top-level container for all routing policy configuration"; 1461 uses defined-sets-top; 1463 uses policy-definitions-top; 1464 } 1465 } 1467 grouping apply-policy-import-config { 1468 description 1469 "Configuration data for applying import policies"; 1471 leaf-list import-policy { 1472 type leafref { 1473 path "/oc-rpol:routing-policy/oc-rpol:policy-definitions/" + 1474 "oc-rpol:policy-definition/oc-rpol:name"; 1475 //TODO: require-instance should be added when it's 1476 //supported in YANG 1.1 1477 //require-instance true; 1478 } 1479 ordered-by user; 1480 description 1481 "list of policy names in sequence to be applied on 1482 receiving a routing update in the current context, e.g., 1483 for the current peer group, neighbor, address family, 1484 etc."; 1485 } 1487 leaf default-import-policy { 1488 type default-policy-type; 1489 default REJECT_ROUTE; 1490 description 1491 "explicitly set a default policy if no policy definition 1492 in the import policy chain is satisfied."; 1493 } 1495 } 1497 grouping apply-policy-export-config { 1498 description 1499 "Configuration data for applying export policies"; 1501 leaf-list export-policy { 1502 type leafref { 1503 path "/oc-rpol:routing-policy/oc-rpol:policy-definitions/" + 1504 "oc-rpol:policy-definition/oc-rpol:name"; 1506 //TODO: require-instance should be added when it's 1507 //supported in YANG 1.1 1508 //require-instance true; 1509 } 1510 ordered-by user; 1511 description 1512 "list of policy names in sequence to be applied on 1513 sending a routing update in the current context, e.g., 1514 for the current peer group, neighbor, address family, 1515 etc."; 1516 } 1518 leaf default-export-policy { 1519 type default-policy-type; 1520 default REJECT_ROUTE; 1521 description 1522 "explicitly set a default policy if no policy definition 1523 in the export policy chain is satisfied."; 1524 } 1525 } 1527 grouping apply-policy-config { 1528 description 1529 "Configuration data for routing policies"; 1531 uses apply-policy-import-config; 1532 uses apply-policy-export-config; 1534 } 1536 grouping apply-policy-state { 1537 description 1538 "Operational state associated with routing policy"; 1540 //TODO: identify additional state data beyond the intended 1541 //policy configuration. 1542 } 1544 grouping apply-policy-group { 1545 description 1546 "Top level container for routing policy applications. This 1547 grouping is intended to be used in routing models where 1548 needed."; 1550 container apply-policy { 1551 description 1552 "Anchor point for routing policies in the model. 1553 Import and export policies are with respect to the local 1554 routing table, i.e., export (send) and import (receive), 1555 depending on the context."; 1557 container config { 1558 description 1559 "Policy configuration data."; 1561 uses apply-policy-config; 1562 } 1564 container state { 1566 config false; 1567 description 1568 "Operational state for routing policy"; 1570 uses apply-policy-config; 1571 uses apply-policy-state; 1572 } 1573 } 1574 } 1576 uses routing-policy-top; 1578 } 1579 1581 9.2. Routing policy types 1583 file "openconfig-policy-types.yang" 1584 module openconfig-policy-types { 1586 yang-version "1"; 1588 // namespace 1589 namespace "urn:ietf:params:xml:ns:yang:ietf-policy-types"; 1591 prefix "oc-pol-types"; 1593 // import some basic types 1594 import ietf-yang-types { prefix yang; } 1595 import openconfig-extensions { prefix oc-ext; } 1597 // meta 1598 organization 1599 "OpenConfig working group"; 1601 contact 1602 "OpenConfig working group 1603 netopenconfig@googlegroups.com"; 1605 description 1606 "This module contains general data definitions for use in routing 1607 policy. It can be imported by modules that contain protocol- 1608 specific policy conditions and actions."; 1610 oc-ext:openconfig-version "2.0.0"; 1612 revision "2016-03-28" { 1613 description 1614 "OpenConfig public release"; 1615 reference "2.0.0"; 1616 } 1618 // identity statements 1620 identity ATTRIBUTE_COMPARISON { 1621 description 1622 "base type for supported comparison operators on route 1623 attributes"; 1624 } 1626 identity ATTRIBUTE_EQ { 1627 base ATTRIBUTE_COMPARISON; 1628 description "== comparison"; 1629 } 1631 identity ATTRIBUTE_GE { 1632 base ATTRIBUTE_COMPARISON; 1633 description ">= comparison"; 1634 } 1636 identity ATTRIBUTE_LE { 1637 base ATTRIBUTE_COMPARISON; 1638 description "<= comparison"; 1639 } 1641 typedef match-set-options-type { 1642 type enumeration { 1643 enum ANY { 1644 description "match is true if given value matches any member 1645 of the defined set"; 1647 } 1648 enum ALL { 1649 description "match is true if given value matches all 1650 members of the defined set"; 1651 } 1652 enum INVERT { 1653 description "match is true if given value does not match any 1654 member of the defined set"; 1655 } 1656 } 1657 default ANY; 1658 description 1659 "Options that govern the behavior of a match statement. The 1660 default behavior is ANY, i.e., the given value matches any 1661 of the members of the defined set"; 1662 } 1664 typedef match-set-options-restricted-type { 1665 type enumeration { 1666 enum ANY { 1667 description "match is true if given value matches any member 1668 of the defined set"; 1669 } 1670 enum INVERT { 1671 description "match is true if given value does not match any 1672 member of the defined set"; 1673 } 1674 } 1675 default ANY; 1676 description 1677 "Options that govern the behavior of a match statement. The 1678 default behavior is ANY, i.e., the given value matches any 1679 of the members of the defined set. Note this type is a 1680 restricted version of the match-set-options-type."; 1681 //TODO: restriction on enumerated types is only allowed in 1682 //YANG 1.1. Until then, we will require this additional type 1683 } 1685 grouping attribute-compare-operators { 1686 description "common definitions for comparison operations in 1687 condition statements"; 1689 leaf operator { 1690 type identityref { 1691 base ATTRIBUTE_COMPARISON; 1692 } 1693 description 1694 "type of comparison to be performed"; 1696 } 1698 leaf value { 1699 type uint32; 1700 description 1701 "value to compare with the community count"; 1702 } 1703 } 1705 typedef tag-type { 1706 type union { 1707 type uint32; 1708 type yang:hex-string; 1709 } 1710 description "type for expressing route tags on a local system, 1711 including IS-IS and OSPF; may be expressed as either decimal or 1712 hexidecimal integer"; 1713 reference 1714 "RFC 2178 OSPF Version 2 1715 RFC 5130 A Policy Control Mechanism in IS-IS Using 1716 Administrative Tags"; 1717 } 1719 identity INSTALL_PROTOCOL_TYPE { 1720 description 1721 "Base type for protocols which can install prefixes into the 1722 RIB"; 1723 } 1725 identity BGP { 1726 base INSTALL_PROTOCOL_TYPE; 1727 description "BGP"; 1728 reference "RFC 4271"; 1729 } 1731 identity ISIS { 1732 base INSTALL_PROTOCOL_TYPE; 1733 description "IS-IS"; 1734 reference "ISO/IEC 10589"; 1735 } 1737 identity OSPF { 1738 base INSTALL_PROTOCOL_TYPE; 1739 description "OSPFv2"; 1740 reference "RFC 2328"; 1741 } 1743 identity OSPF3 { 1744 base INSTALL_PROTOCOL_TYPE; 1745 description "OSPFv3"; 1746 reference "RFC 5340"; 1747 } 1749 identity STATIC { 1750 base INSTALL_PROTOCOL_TYPE; 1751 description "Locally-installed static route"; 1752 } 1754 identity DIRECTLY_CONNECTED { 1755 base INSTALL_PROTOCOL_TYPE; 1756 description "A directly connected route"; 1757 } 1759 identity LOCAL_AGGREGATE { 1760 base INSTALL_PROTOCOL_TYPE; 1761 description "Locally defined aggregate route"; 1762 } 1763 } 1764 1766 10. Policy examples 1768 Below we show an example of XML-encoded configuration data using the 1769 routing policy and BGP models to illustrate both how policies are 1770 defined, and also how they can be applied. Note that the XML has 1771 been simplified for readability. 1773 1774 1776 1777 1778 1779 prefix-set-A 1780 1781 192.0.2.0/24 1782 24..32 1783 1784 1785 10.0.0.0/16 1786 16..32 1787 1788 1789 192.168.0.0/19 1790 19..24 1792 1793 1794 1795 1796 1797 cust-tag1 1798 1799 10 1800 1801 1802 1803 1805 1806 1807 export-tagged-BGP 1808 1809 1810 term-0 1811 1812 ns:OSPF3 1813 1814 cust-tag1 1815 1816 1817 1818 1819 1820 1821 1822 1823 1825 1826 1828 11. References 1830 11.1. Normative references 1832 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1833 Network Configuration Protocol (NETCONF)", RFC 6020, 1834 October 2014. 1836 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1837 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1839 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1840 July 2013. 1842 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 1843 2004. 1845 11.2. Informative references 1847 [I-D.ietf-idr-bgp-model] 1848 Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K., 1849 Bansal, D., Clemm, A., Alex, A., Jethanandani, M., and X. 1850 Liu, "BGP Model for Service Provider Networks", draft- 1851 ietf-idr-bgp-model-01 (work in progress), January 2016. 1853 [I-D.openconfig-netmod-opstate] 1854 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 1855 of Operational State Data in YANG", draft-openconfig- 1856 netmod-opstate-01 (work in progress), July 2015. 1858 Appendix A. Acknowledgements 1860 The authors are grateful for valuable contributions to this document 1861 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1862 George, Acee Lindem, Stephane Litkowski, Ina Minei, Carl Moberg, Eric 1863 Osborne, Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, and Russ 1864 White. 1866 Appendix B. Change summary 1868 B.1. Changes between revisions -00 and -01 1870 Updated policy model with additional condition for matching 1871 interfaces. 1873 B.2. Changes between revisions draft-shaikh-rtgwg-policy-model and -00 1875 This revision updates the draft name to reflect adoption as a working 1876 document in the RTGWG. Minor changes include updates to references 1877 and updated author contact information. 1879 Authors' Addresses 1880 Anees Shaikh 1881 Google 1882 1600 Amphitheatre Pkwy 1883 Mountain View, CA 94043 1884 US 1886 Email: aashaikh@google.com 1888 Rob Shakir 1889 Jive Communications, Inc. 1890 1275 West 1600 North, Suite 100 1891 Orem, UT 84057 1893 Email: rjs@rob.sh 1895 Kevin D'Souza 1896 AT&T 1897 200 S. Laurel Ave 1898 Middletown, NJ 1899 US 1901 Email: kd6913@att.com 1903 Chris Chase 1904 AT&T 1905 9505 Arboretum Blvd 1906 Austin, TX 1907 US 1909 Email: chase@labs.att.com