idnits 2.17.00 (12 Aug 2021) /tmp/idnits50961/draft-ietf-rtgwg-policy-model-09.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 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 280 has weird spacing: '...h-lower uin...' == Line 281 has weird spacing: '...h-upper uin...' == Line 479 has weird spacing: '...h-lower uin...' == Line 480 has weird spacing: '...h-upper uin...' == Line 492 has weird spacing: '...et-name str...' == (3 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 4, 2020) is 808 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-netmod-sub-intf-vlan-model' is defined on line 1620, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-netmod-intf-ext-yang-08 == Outdated reference: A later version (-07) exists of draft-ietf-netmod-sub-intf-vlan-model-06 == Outdated reference: A later version (-13) exists of draft-ietf-idr-bgp-model-08 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Y. Qu 3 Internet-Draft Futurewei 4 Intended status: Standards Track J. Tantsura 5 Expires: September 5, 2020 Apstra 6 A. Lindem 7 Cisco 8 X. Liu 9 Volta Networks 10 March 4, 2020 12 A YANG Data Model for Routing Policy Management 13 draft-ietf-rtgwg-policy-model-09 15 Abstract 17 This document defines a YANG data model for configuring and managing 18 routing policies in a vendor-neutral way and based on actual 19 operational practice. The model provides a generic policy framework 20 which can be augmented with protocol-specific policy configuration. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 5, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Goals and approach . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 59 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 61 3. Model overview . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Route policy expression . . . . . . . . . . . . . . . . . . . 5 63 4.1. Defined sets for policy matching . . . . . . . . . . . . 6 64 4.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 8 66 4.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 9 67 5. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 10 68 6. Applying routing policy . . . . . . . . . . . . . . . . . . . 10 69 7. Routing protocol-specific policies . . . . . . . . . . . . . 11 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 10. YANG modules . . . . . . . . . . . . . . . . . . . . . . . . 14 73 10.1. Routing policy model . . . . . . . . . . . . . . . . . . 14 74 11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 35 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 76 12.1. Normative references . . . . . . . . . . . . . . . . . . 35 77 12.2. Informative references . . . . . . . . . . . . . . . . . 36 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 81 1. Introduction 83 This document describes a YANG [RFC6020] [RFC7950] data model for 84 routing policy configuration based on operational usage and best 85 practices in a variety of service provider networks. The model is 86 intended to be vendor-neutral, in order to allow operators to manage 87 policy configuration in a consistent, intuitive way in heterogeneous 88 environments with routers supplied by multiple vendors. 90 The YANG modules in this document conform to the Network Management 91 Datastore Architecture (NMDA) [RFC8342]. 93 1.1. Goals and approach 95 This model does not aim to be feature complete -- it is a subset of 96 the policy configuration parameters available in a variety of vendor 97 implementations, but supports widely used constructs for managing how 98 routes are imported, exported, and modified across different routing 99 protocols. The model development approach has been to examine actual 100 policy configurations in use across a number of operator networks. 101 Hence the focus is on enabling policy configuration capabilities and 102 structure that are in wide use. 104 Despite the differences in details of policy expressions and 105 conventions in various vendor implementations, the model reflects the 106 observation that a relatively simple condition-action approach can be 107 readily mapped to several existing vendor implementations, and also 108 gives operators an intuitive and straightforward way to express 109 policy without sacrificing flexibility. A side affect of this design 110 decision is that legacy methods for expressing policies are not 111 considered. Such methods could be added as an augmentation to the 112 model if needed. 114 Consistent with the goal to produce a data model that is vendor 115 neutral, only policy expressions that are deemed to be widely 116 available in existing major implementations are included in the 117 model. Those configuration items that are only available from a 118 single implementation are omitted from the model with the expectation 119 they will be available in separate vendor-provided modules that 120 augment the current model. 122 2. Terminology and Notation 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 The following terms are defined in [RFC8342]: 132 o client 134 o server 136 o configuration 138 o system state 140 o operational state 141 o intended configuration 143 The following terms are defined in [RFC7950]: 145 o action 147 o augment 149 o container 151 o container with presence 153 o data model 155 o data node 157 o feature 159 o leaf 161 o list 163 o mandatory node 165 o module 167 o schema tree 169 o RPC (Remote Procedure Call) operation 171 2.1. Tree Diagrams 173 Tree diagrams used in this document follow the notation defined in 174 [RFC8340]. 176 2.2. Prefixes in Data Node Names 178 In this document, names of data nodes, actions, and other data model 179 objects are often used without a prefix, as long as it is clear from 180 the context in which YANG module each name is defined. Otherwise, 181 names are prefixed using the standard prefix associated with the 182 corresponding YANG module, as shown in Table 1. 184 +-----------+------------------+------------------------------------+ 185 | Prefix | YANG module | Reference | 186 +-----------+------------------+------------------------------------+ 187 | if | ietf-interfaces | [RFC8343] | 188 | | | | 189 | rt | ietf-routing | [RFC8349] | 190 | | | | 191 | yang | ietf-yang-types | [RFC6991] | 192 | | | | 193 | inet | ietf-inet-types | [RFC6991] | 194 | | | | 195 | if-ext | ietf-if- | [I-D.ietf-netmod-intf-ext-yang] | 196 | | extensions | | 197 | | | | 198 | if-l3-vla | ietf-if-l3-vlan | [I-D.ietf-netmod-sub-intf-vlan-mod | 199 | n | | el] | 200 +-----------+------------------+------------------------------------+ 202 Table 1: Prefixes and Corresponding YANG Modules 204 3. Model overview 206 The routing policy module has three main parts: 208 o A generic framework to express policies as sets of related 209 conditions and actions. This includes match sets and actions that 210 are useful across many routing protocols. 212 o A structure that allows routing protocol models to add protocol- 213 specific policy conditions and actions though YANG augmentations. 214 There is a complete example of this for BGP [RFC4271] policies in 215 the proposed vendor-neutral BGP data model 216 [I-D.ietf-idr-bgp-model]. 218 o A reusable grouping for attaching import and export rules in the 219 context of routing configuration for different protocols, VRFs, 220 etc. This also enables creation of policy chains and expressing 221 default policy behavior. 223 The module makes use of the standard Internet types, such as IP 224 addresses, autonomous system numbers, etc., defined in RFC 6991 225 [RFC6991]. 227 4. Route policy expression 229 Policies are expressed as a sequence of top-level policy definitions 230 each of which consists of a sequence of policy statements. Policy 231 statements in turn consist of simple condition-action tuples. 233 Conditions may include multiple match or comparison operations, and 234 similarly, actions may effect multiple changes to route attributes, 235 or indicate a final disposition of accepting or rejecting the route. 236 This structure is shown below. 238 +--rw routing-policy 239 +--rw policy-definitions 240 +--rw policy-definition* [name] 241 +--rw name string 242 +--rw policy-statements 243 +--rw statement* [name] 244 +--rw name string 245 +--rw conditions 246 | ... 247 +--rw actions 248 ... 250 4.1. Defined sets for policy matching 252 The models provides a set of generic sets that can be used for 253 matching in policy conditions. These sets are applicable for route 254 selection across multiple routing protocols. They may be further 255 augmented by protocol-specific models which have their own defined 256 sets. The supported defined sets include: 258 o prefix sets - define a set of IP prefixes, each with an associated 259 CIDR netmask range (or exact length) 261 o neighbor sets - define a set of neighboring nodes by their IP 262 addresses. These sets are used for selecting routes based on the 263 neighbors advertising the routes. 265 o tag set - define a set of generic tag values that can be used in 266 matches for filtering routes 268 The model structure for defined sets is shown below. 270 +--rw routing-policy 271 +--rw defined-sets 272 | +--rw prefix-sets 273 | | +--rw prefix-set* [name] 274 | | +--rw name string 275 | | +--rw mode? enumeration 276 | | +--rw prefixes 277 | | +--rw prefix-list* [ip-prefix masklength-lower 278 | | masklength-upper] 279 | | +--rw ip-prefix inet:ip-prefix 280 | | +--rw masklength-lower uint8 281 | | +--rw masklength-upper uint8 282 | +--rw neighbor-sets 283 | | +--rw neighbor-set* [name] 284 | | +--rw name string 285 | | +--rw address* inet:ip-address 286 | +--rw tag-sets 287 | +--rw tag-set* [name] 288 | +--rw name string 289 | +--rw tag-value* tag-type 291 4.2. Policy conditions 293 Policy statements consist of a set of conditions and actions (either 294 of which may be empty). Conditions are used to match route 295 attributes against a defined set (e.g., a prefix set), or to compare 296 attributes against a specific value. 298 Match conditions may be further modified using the match-set-options 299 configuration which allows operators to change the behavior of a 300 match. Three options are supported: 302 o ALL - match is true only if the given value matches all members of 303 the set. 305 o ANY - match is true if the given value matches any member of the 306 set. 308 o INVERT - match is true if the given value does not match any 309 member of the given set. 311 Not all options are appropriate for matching against all defined sets 312 (e.g., match ALL in a prefix set does not make sense). In the model, 313 a restricted set of match options is used where applicable. 315 Comparison conditions may similarly use options to change how route 316 attributes should be tested, e.g., for equality or inequality, 317 against a given value. 319 While most policy conditions will be added by individual routing 320 protocol models via augmentation, this routing policy model includes 321 several generic match conditions and also the ability to test which 322 protocol or mechanism installed a route (e.g., BGP, IGP, static, 323 etc.). The conditions included in the model are shown below. 325 +--rw routing-policy 326 +--rw policy-definitions 327 +--rw policy-definition* [name] 328 +--rw name string 329 +--rw policy-statements 330 +--rw statement* [name] 331 +--rw conditions 332 | +--rw call-policy? 333 | +--rw install-protocol-eq? 334 | +--rw match-interface 335 | | +--rw interface? 336 | | +--rw subinterface? 337 | +--rw match-prefix-set 338 | | +--rw prefix-set? 339 | | +--rw match-set-options? 340 | +--rw match-neighbor-set 341 | | +--rw neighbor-set? 342 | +--rw match-tag-set 343 | | +--rw tag-set? 344 | | +--rw match-set-options? 345 | +--rw match-proto-route-type* identityref 347 4.3. Policy actions 349 When policy conditions are satisfied, policy actions are used to set 350 various attributes of the route being processed, or to indicate the 351 final disposition of the route, i.e., accept or reject. 353 Similar to policy conditions, the routing policy model includes 354 generic actions in addition to the basic route disposition actions. 355 These are shown below. 357 +--rw routing-policy 358 +--rw policy-definitions 359 +--rw policy-definition* [name] 360 +--rw policy-statements 361 +--rw statement* [name] 362 +--rw actions 363 +--rw policy-result? policy-result-type 364 +--rw set-metric 365 | +--rw metric-modificatiion? 366 | | metric-modification-type 367 | +--rw metric? uint32 368 +--rw set-metric-type 369 | +--rw metric-type? identityref 370 +--rw set-import-level 371 | +--rw import-level? identityref 372 +--rw set-preference? uint16 373 +--rw set-tag? tag-type 374 +--rw set-application-tag? tag-type 376 4.4. Policy subroutines 378 Policy 'subroutines' (or nested policies) are supported by allowing 379 policy statement conditions to reference other policy definitions 380 using the call-policy configuration. Called policies apply their 381 conditions and actions before returning to the calling policy 382 statement and resuming evaluation. The outcome of the called policy 383 affects the evaluation of the calling policy. If the called policy 384 results in an accept-route, then the subroutine returns an effective 385 boolean true value to the calling policy. For the calling policy, 386 this is equivalent to a condition statement evaluating to a true 387 value and evaluation of the policy continues (see Section 5). Note 388 that the called policy may also modify attributes of the route in its 389 action statements. Similarly, a reject-route action returns false 390 and the calling policy evaluation will be affected accordingly. When 391 the end of the subroutine policy chain is reached, the default route 392 disposition action is returned (i.e., boolean false for reject-route 393 unless an alternate default action is specified for the chain). 394 Consequently, a subroutine cannot explicitly accept or reject a 395 route. Rather it merely provides an indication that 'call-policy' 396 condition returns boolean true or false indicating whether or not the 397 condition matches. Route acceptance or rejection is solely 398 determined by the top-level policy. 400 Note that the called policy may itself call other policies (subject 401 to implementation limitations). The model does not prescribe a 402 nesting depth because this varies among implementations. For 403 example, some major implementation may only support a single level of 404 subroutine recursion. As with any routing policy construction, care 405 must be taken with nested policies to ensure that the effective 406 return value results in the intended behavior. Nested policies are a 407 convenience in many routing policy constructions but creating 408 policies nested beyond a small number of levels (e.g., 2-3) should be 409 discouraged. 411 5. Policy evaluation 413 Evaluation of each policy definition proceeds by evaluating its 414 corresponding individual policy statements in order. When all the 415 condition statements in a policy statement are satisfied, the 416 corresponding action statements are executed. If the actions include 417 either accept-route or reject-route actions, evaluation of the 418 current policy definition stops, and no further policy definitions in 419 the chain are evaluated. 421 If the conditions are not satisfied, then evaluation proceeds to the 422 next policy statement. If none of the policy statement conditions 423 are satisfied, then evaluation of the current policy definition 424 stops, and the next policy definition in the chain is evaluated. 425 When the end of the policy chain is reached, the default route 426 disposition action is performed (i.e., reject-route unless an 427 alternate default action is specified for the chain). 429 Note that the route's pre-policy attributes are always used for 430 testing policy statement conditions. In other words, if actions 431 modify the policy application specific attributes, those 432 modifications are not used for policy statement conditions. 434 6. Applying routing policy 436 Routing policy is applied by defining and attaching policy chains in 437 various routing contexts. Policy chains are sequences of policy 438 definitions (described in Section 4) that have an associated 439 direction (import or export) with respect to the routing context in 440 which they are defined. The routing policy model defines an apply- 441 policy grouping that can be imported and used by other models. As 442 shown below, it allows definition of import and export policy chains, 443 as well as specifying the default route disposition to be used when 444 no policy definition in the chain results in a final decision. 446 +--rw apply-policy 447 | +--rw import-policy* 448 | +--rw default-import-policy? default-policy-type 449 | +--rw export-policy* 450 | +--rw default-export-policy? default-policy-type 452 The default policy defined by the model is to reject the route for 453 both import and export policies. 455 7. Routing protocol-specific policies 457 Routing models that require the ability to apply routing policy may 458 augment the routing policy model with protocol or other specific 459 policy configuration. The routing policy model assumes that 460 additional defined sets, conditions, and actions may all be added by 461 other models. 463 An example of this is shown below, in which the BGP configuration 464 model in [I-D.ietf-idr-bgp-model] adds new defined sets to match on 465 community values or AS paths. The model similarly augments BGP- 466 specific conditions and actions in the corresponding sections of the 467 routing policy model. 469 +--rw routing-policy 470 +--rw defined-sets 471 | +--rw prefix-sets 472 | | +--rw prefix-set* [name] 473 | | +--rw name string 474 | | +--rw mode? enumeration 475 | | +--rw prefixes 476 | | +--rw prefix-list* [ip-prefix masklength-lower 477 | | masklength-upper] 478 | | +--rw ip-prefix inet:ip-prefix 479 | | +--rw masklength-lower uint8 480 | | +--rw masklength-upper uint8 481 | +--rw neighbor-sets 482 | | +--rw neighbor-set* [name] 483 | | +--rw name string 484 | | +--rw address* inet:ip-address 485 | +--rw tag-sets 486 | | +--rw tag-set* [name] 487 | | +--rw name string 488 | | +--rw tag-value* tag-type 489 | +--rw bgp-pol:bgp-defined-sets 490 | +--rw bgp-pol:community-sets 491 | | +--rw bgp-pol:community-set* [community-set-name] 492 | | +--rw bgp-pol:community-set-name string 493 | | +--rw bgp-pol:community-member* union 494 | +--rw bgp-pol:ext-community-sets 495 | | +--rw bgp-pol:ext-community-set* [ext-community-set-name] 496 | | +--rw bgp-pol:ext-community-set-name string 497 | | +--rw bgp-pol:ext-community-member* union 498 | +--rw bgp-pol:as-path-sets 499 | +--rw bgp-pol:as-path-set* [as-path-set-name] 500 | +--rw bgp-pol:as-path-set-name string 501 | +--rw bgp-pol:as-path-set-member* string 502 +--rw policy-definitions 503 +--rw policy-definition* [name] 504 +--rw name string 505 +--rw policy-statements 506 +--rw statement* [name] 507 +--rw name string 508 +--rw conditions 509 | +--rw call-policy? 510 | +--rw source-protocol? identityref 511 | +--rw match-interface 512 | | +--rw interface? 513 | | +--rw subinterface? 514 | +--rw match-prefix-set 515 | | +--rw prefix-set? 516 | | +--rw match-set-options? match-set-options-type 517 | +--rw match-neighbor-set 518 | | +--rw neighbor-set? 519 | +--rw match-tag-set 520 | | +--rw tag-set? 521 | | +--rw match-set-options? match-set-options-type 522 | +--rw match-proto-route-type* identityref 523 | +--rw bgp-pol:bgp-conditions 524 | +--rw bgp-pol:med-eq? uint32 525 | +--rw bgp-pol:origin-eq? 526 | bgp-types:bgp-origin-attr-type 527 | +--rw bgp-pol:next-hop-in* 528 | inet:ip-address-no-zone 529 | +--rw bgp-pol:afi-safi-in* identityref 530 | +--rw bgp-pol:local-pref-eq? uint32 531 | +--rw bgp-pol:route-type? enumeration 532 | +--rw bgp-pol:community-count 533 | +--rw bgp-pol:as-path-length 534 | +--rw bgp-pol:match-community-set 535 | | +--rw bgp-pol:community-set? 536 | | +--rw bgp-pol:match-set-options? 537 | match-set-options-type 538 | +--rw bgp-pol:match-ext-community-set 539 | | +--rw bgp-pol:ext-community-set? 540 | | +--rw bgp-pol:match-set-options? 541 | | match-set-options-type 542 | +--rw bgp-pol:match-as-path-set 543 | +--rw bgp-pol:as-path-set? 544 | +--rw bgp-pol:match-set-options? 545 | match-set-options-type 546 +--rw actions 547 +--rw policy-result? policy-result-type 548 +--rw set-metric 549 | +--rw metric-modificatiion? 550 | | metric-modification-type 551 | +--rw metric? uint32 552 +--rw set-metric-type 553 | +--rw metric-type? identityref 554 +--rw set-import-level 555 | +--rw import-level? identityref 556 +--rw set-preference? uint16 557 +--rw set-tag? tag-type 558 +--rw set-application-tag? tag-type 559 +--rw bgp-pol:bgp-actions 560 +--rw bgp-pol:set-route-origin? 561 bgp-types:bgp-origin-attr-type 562 +--rw bgp-pol:set-local-pref? uint32 563 +--rw bgp-pol:set-next-hop? bgp-next-hop-type 564 +--rw bgp-pol:set-med? bgp-set-med-type 565 +--rw bgp-pol:set-as-path-prepend 566 | +--rw bgp-pol:repeat-n? uint8 567 +--rw bgp-pol:set-community 568 | +--rw bgp-pol:method? enumeration 569 | +--rw bgp-pol:options? 570 bgp-set-community-option-type 571 | +--rw bgp-pol:inline 572 | | +--rw bgp-pol:communities* union 573 | +--rw bgp-pol:reference 574 | +--rw bgp-pol:community-set-ref? 575 +--rw bgp-pol:set-ext-community 576 +--rw bgp-pol:method? enumeration 577 +--rw bgp-pol:options? 578 bgp-set-community-option-type 579 +--rw bgp-pol:inline 580 | +--rw bgp-pol:communities* union 581 +--rw bgp-pol:reference 582 +--rw bgp-pol:ext-community-set-ref? 584 8. Security Considerations 586 Routing policy configuration has a significant impact on network 587 operations, and, as such, any related model carries potential 588 security risks. 590 YANG data models are generally designed to be used with the NETCONF 591 protocol over an SSH transport. This provides an authenticated and 592 secure channel over which to transfer configuration and operational 593 data. Note that use of alternate transport or data encoding (e.g., 594 JSON over HTTPS) would require similar mechanisms for authenticating 595 and securing access to configuration data. 597 Most of the data elements in the policy model could be considered 598 sensitive from a security standpoint. Unauthorized access or invalid 599 data could cause major disruption. 601 9. IANA Considerations 603 This YANG data model and the component modules currently use a 604 temporary ad-hoc namespace. If and when it is placed on redirected 605 for the standards track, an appropriate namespace URI will be 606 registered in the IETF XML Registry" [RFC3688]. The routing policy 607 YANG modules will be registered in the "YANG Module Names" registry 608 [RFC6020]. 610 10. YANG modules 612 The routing policy model is described by the YANG modules in the 613 sections below. 615 10.1. Routing policy model 617 file "ietf-routing-policy@2020-03-04.yang" 618 module ietf-routing-policy { 620 yang-version "1.1"; 621 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; 622 prefix rt-pol; 624 import ietf-inet-types { 625 prefix "inet"; 626 } 628 import ietf-yang-types { 629 prefix "yang"; 630 } 632 import ietf-interfaces { 633 prefix "if"; 634 } 636 import ietf-routing { 637 prefix "rt"; 638 } 640 import ietf-if-extensions { 641 prefix if-ext; 642 } 644 import ietf-if-l3-vlan { 645 prefix "if-l3-vlan"; 646 } 648 organization 649 "IETF RTGWG - Routing Area Working Group"; 650 contact 651 "WG Web: 652 WG List: 654 Editor: Yingzhen Qu 655 656 Jeff Tantsura 657 658 Acee Lindem 659 660 Xufeng Liu 661 "; 663 description 664 "This module describes a YANG model for routing policy 665 configuration. It is a limited subset of all of the policy 666 configuration parameters available in the variety of vendor 667 implementations, but supports widely used constructs for 668 managing how routes are imported, exported, and modified across 669 different routing protocols. This module is intended to be 670 used in conjunction with routing protocol configuration modules 671 (e.g., BGP) defined in other models. 673 Copyright (c) 2020 IETF Trust and the persons identified as 674 authors of the code. All rights reserved. 676 Redistribution and use in source and binary forms, with or 677 without modification, is permitted pursuant to, and subject to 678 the license terms contained in, the Simplified BSD License set 679 forth in Section 4.c of the IETF Trust's Legal Provisions 680 Relating to IETF Documents 681 (https://trustee.ietf.org/license-info). 683 This version of this YANG module is part of RFC XXXX 684 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 685 for full legal notices. 687 Route policy expression: 689 Policies are expressed as a set of top-level policy 690 definitions, each of which consists of a sequence of policy 691 statements. Policy statements consist of simple 692 condition-action tuples. Conditions may include mutiple match 693 or comparison operations, and similarly actions may be 694 multitude of changes to route attributes or a final disposition 695 of accepting or rejecting the route. 697 Route policy evaluation: 699 Policy definitions are referenced in routing protocol 700 configurations using import and export configuration 701 statements. The arguments are members of an ordered list of 702 named policy definitions which comprise a policy chain, and 703 optionally, an explicit default policy action (i.e., reject 704 or accept). 706 Evaluation of each policy definition proceeds by evaluating its 707 corresponding individual policy statements in order. When a 708 condition statement in a policy statement is satisfied, the 709 corresponding action statement is executed. If the action 710 statement has either accept-route or reject-route actions, 711 policy evaluation of the current policy definition stops, and 712 no further policy definitions in the chain are evaluated. 714 If the condition is not satisfied, then evaluation proceeds to 715 the next policy statement. If none of the policy statement 716 conditions are satisfied, then evaluation of the current policy 717 definition stops, and the next policy definition in the chain 718 is evaluated. When the end of the policy chain is reached, the 719 default route disposition action is performed (i.e., 720 reject-route unless an alternate default action is specified 721 for the chain). 723 Policy 'subroutines' (or nested policies) are supported by 724 allowing policy statement conditions to reference another 725 policy definition which applies conditions and actions from 726 the referenced policy before returning to the calling policy 727 statement and resuming evaluation. If the called policy 728 results in an accept-route (either explicit or by default), 729 then the subroutine returns an effective true value to the 730 calling policy. Similarly, a reject-route action returns 731 false. If the subroutine returns true, the calling policy 732 continues to evaluate the remaining conditions (using a 733 modified route if the subroutine performed any changes to the 734 route)."; 736 revision "2020-03-04" { 737 description 738 "Initial revision."; 739 reference 740 "RFC XXXX: Routing Policy Configuration Model for Service 741 Provider Networks"; 742 } 744 /* Identities */ 746 identity metric-type { 747 description "Base identity for route metric types."; 748 } 750 identity ospf-type-1-metric { 751 base metric-type; 752 description 753 "Identity for the OSPF type 1 external metric types. It 754 is only applicable to OSPF routes."; 755 } 757 identity ospf-type-2-metric { 758 base metric-type; 759 description 760 "Identity for the OSPF type 2 external metric types. It 761 is only applicable to OSPF routes."; 762 } 764 identity isis-internal-metric { 765 base metric-type; 766 description 767 "Identity for the IS-IS internal metric types. It is only 768 applicable to IS-IS routes."; 769 } 771 identity isis-external-metric { 772 base metric-type; 773 description 774 "Identity for the IS-IS external metric types. It is only 775 applicable to IS-IS routes."; 776 } 778 identity import-level { 779 description "Base identity for route import level."; 780 } 782 identity ospf-normal { 783 base import-level; 784 description 785 "Identity for OSPF importation into normal areas 786 It is only applicable to routes imported 787 into the OSPF protocol."; 788 } 790 identity ospf-nssa-only { 791 base import-level; 792 description 793 "Identity for the OSPF NSSA area importation. It is only 794 applicable to routes imported into the OSPF protocol."; 795 } 797 identity ospf-normal-nssa { 798 base import-level; 799 description 800 "Identity for OSPF importation into both normal and NSSA 801 areas, It is only applicable to routes imported into 802 the OSPF protocol."; 803 } 805 identity isis-level-1 { 806 base import-level; 807 description 808 "Identity for IS-IS Level 1 area importation. It is only 809 applicable to routes imported into the IS-IS protocol."; 810 } 812 identity isis-level-2 { 813 base import-level; 814 description 815 "Identity for IS-IS Level 2 area importation. It is only 816 applicable to routes imported into the IS-IS protocol."; 817 } 819 identity isis-level-1-2 { 820 base import-level; 821 description 822 "Identity for IS-IS Level 1 and Level 2 ara importation. It 823 is only applicable to routes imported into the IS-IS 824 protocol."; 825 } 827 identity proto-route-type { 828 description 829 "Base identity for route type within a protocol."; 830 } 832 identity isis-level-1-type { 833 base proto-route-type; 834 description 835 "Identity for IS-IS Level 1 route type. It is only 836 applicable to IS-IS routes."; 837 } 839 identity isis-level-2-type { 840 base proto-route-type; 841 description 842 "Identity for IS-IS Level 2 route type. It is only 843 applicable to IS-IS routes."; 844 } 846 identity ospf-internal-type { 847 base proto-route-type; 848 description 849 "Identity for OSPF intra-area or inter-area route type. 850 It is only applicable to OSPF routes."; 851 } 853 identity ospf-external-type { 854 base proto-route-type; 855 description 856 "Identity for OSPF external type 1/2 route type. 857 It is only applicable to OSPF routes."; 858 } 860 identity ospf-external-t1 { 861 base ospf-external-type; 862 description 863 "Identity for OSPF external type 1 route type. 864 It is only applicable to OSPF routes."; 865 } 867 identity ospf-external-t2-type { 868 base ospf-external-type; 869 description 870 "Identity for OSPF external type 2 route type. 871 It is only applicable to OSPF routes."; 872 } 874 identity ospf-nssa-type { 875 base proto-route-type; 876 description 877 "Identity for OSPF NSSA type 1/2 route type. 878 It is only applicable to OSPF routes."; 879 } 880 identity ospf-nssa-t1 { 881 base ospf-nssa-type; 882 description 883 "Identity for OSPF NSSA type 1 route type. 884 It is only applicable to OSPF routes."; 885 } 887 identity ospf-nssa-t2 { 888 base ospf-nssa-type; 889 description 890 "Identity for OSPF NSSA type 2 route type. 891 It is only applicable to OSPF routes."; 892 } 894 identity bgp-local { 895 base proto-route-type; 896 description 897 "Identity for BGP local route type. 898 It is only applicable to BGP routes."; 899 } 901 identity bgp-external { 902 base proto-route-type; 903 description 904 "Identity for BGP external route type. 905 It is only applicable to BGP routes."; 906 } 908 /* Type Definitions */ 910 typedef default-policy-type { 911 /* This typedef retained for name compatibiity with default 912 import and export policy. */ 913 type enumeration { 914 enum accept-route { 915 description 916 "Default policy to accept the route"; 917 } 918 enum reject-route { 919 description 920 "Default policy to reject the route"; 921 } 922 } 923 description 924 "Type used to specify route disposition in 925 a policy chain"; 926 } 927 typedef policy-result-type { 928 type enumeration { 929 enum accept-route { 930 description "Policy accepts the route"; 931 } 932 enum reject-route { 933 description "Policy rejects the route"; 934 } 935 } 936 description 937 "Type used to specify route disposition in 938 a policy chain"; 939 } 941 typedef tag-type { 942 type union { 943 type uint32; 944 type yang:hex-string; 945 } 946 description "Type for expressing route tags on a local system, 947 including IS-IS and OSPF; may be expressed as either decimal 948 or hexadecimal integer"; 949 reference 950 "RFC 2178 - OSPF Version 2 951 RFC 5130 - A Policy Control Mechanism in IS-IS Using 952 Administrative Tags"; 953 } 955 typedef match-set-options-type { 956 type enumeration { 957 enum any { 958 description "Match is true if given value matches any member 959 of the defined set"; 960 } 961 enum all { 962 description "Match is true if given value matches all 963 members of the defined set"; 964 } 965 enum invert { 966 description "Match is true if given value does not match any 967 member of the defined set"; 968 } 969 } 970 default any; 971 description 972 "Options that govern the behavior of a match statement. The 973 default behavior is any, i.e., the given value matches any 974 of the members of the defined set"; 976 } 978 typedef metric-modification-type { 979 type enumeration { 980 enum set-metric { 981 description "Set the metric to the specified value"; 982 } 983 enum add-metric { 984 description 985 "Add the specified value to the existing metric. 986 If the result would exceed the the maximum metric 987 (0xffffffff), set the metric to the maximum."; 988 } 989 enum subtract-metric { 990 description 991 "Subtract the specified value to the existing metric. 992 If the result would be less than 0, set the metric to 0."; 993 } 994 } 995 description 996 "Type used to specify how to set the metric given the 997 specified value"; 998 } 1000 /* Groupings */ 1002 grouping prefix-set { 1003 description 1004 "Configuration data for prefix sets used in policy 1005 definitions."; 1007 leaf name { 1008 type string; 1009 description 1010 "Name of the prefix set -- this is used as a label to 1011 reference the set in match conditions"; 1012 } 1014 leaf mode { 1015 type enumeration { 1016 enum ipv4 { 1017 description 1018 "Prefix set contains IPv4 prefixes only"; 1019 } 1020 enum ipv6 { 1021 description 1022 "Prefix set contains IPv6 prefixes only"; 1023 } 1024 enum mixed { 1025 description 1026 "Prefix set contains mixed IPv4 and IPv6 prefixes"; 1027 } 1028 } 1029 description 1030 "Indicates the mode of the prefix set, in terms of which 1031 address families (IPv4, IPv6, or both) are present. The 1032 mode provides a hint, but the device must validate that all 1033 prefixes are of the indicated type, and is expected to 1034 reject the configuration if there is a discrepancy. The 1035 MIXED mode may not be supported on devices that require 1036 prefix sets to be of only one address family."; 1037 } 1039 } 1041 grouping prefix { 1042 description 1043 "Configuration data for a prefix definition"; 1045 leaf ip-prefix { 1046 type inet:ip-prefix; 1047 mandatory true; 1048 description 1049 "The prefix member in CIDR notation -- while the 1050 prefix may be either IPv4 or IPv6, most 1051 implementations require all members of the prefix set 1052 to be the same address family. Mixing address types in 1053 the same prefix set is likely to cause an error."; 1054 } 1056 leaf masklength-lower { 1057 type uint8; 1058 description 1059 "Masklength range lower bound."; 1060 } 1061 leaf masklength-upper { 1062 type uint8 { 1063 range "1..128"; 1064 } 1065 must "../masklength-upper >= ../masklength-lower" { 1066 error-message "The upper bound should not be less" 1067 + "than lower bound."; 1068 } 1069 description 1070 "Masklength range upper bound. 1072 The combination of masklength-lower and masklength-upper 1073 define a range for the mask length, or single 'exact' 1074 length if masklength-lower and masklenght-upper are equal. 1076 Example: 10.3.192.0/21 through 10.3.192.0/24 would be 1077 expressed as prefix: 10.3.192.0/21, 1078 masklength-lower=21, 1079 masklength-upper=24 1081 Example: 10.3.192.0/21 (an exact match) would be 1082 expressed as prefix: 10.3.192.0/21, 1083 masklength-lower=21, 1084 masklength-upper=21"; 1085 } 1086 } 1088 grouping neighbor-set { 1089 description 1090 "This grouping provides neighbor set definitions"; 1092 leaf name { 1093 type string; 1094 description 1095 "Name of the neighbor set -- this is used as a label 1096 to reference the set in match conditions"; 1097 } 1099 leaf-list address { 1100 type inet:ip-address; 1101 description 1102 "List of IP addresses in the neighbor set"; 1103 } 1104 } 1106 grouping tag-set { 1107 description 1108 "This grouping provides tag set definitions."; 1110 leaf name { 1111 type string; 1112 description 1113 "Name of the tag set -- this is used as a label to reference 1114 the set in match conditions"; 1115 } 1117 leaf-list tag-value { 1118 type tag-type; 1119 description 1120 "Value of the tag set member"; 1121 } 1122 } 1124 grouping match-set-options-group { 1125 description 1126 "Grouping containing options relating to how a particular set 1127 should be matched"; 1129 leaf match-set-options { 1130 type match-set-options-type; 1131 description 1132 "Optional parameter that governs the behavior of the 1133 match operation"; 1134 } 1135 } 1137 grouping match-set-options-restricted-group { 1138 description 1139 "Grouping for a restricted set of match operation modifiers"; 1141 leaf match-set-options { 1142 type match-set-options-type { 1143 enum any { 1144 description "Match is true if given value matches any 1145 member of the defined set"; 1146 } 1147 enum invert { 1148 description "Match is true if given value does not match 1149 any member of the defined set"; 1150 } 1151 } 1152 description 1153 "Optional parameter that governs the behavior of the 1154 match operation. This leaf only supports matching on ANY 1155 member of the set or inverting the match. Matching on ALL 1156 is not supported"; 1157 } 1158 } 1160 grouping match-interface-condition { 1161 description 1162 "This grouping provides interface match condition"; 1164 container match-interface { 1165 leaf interface { 1166 type leafref { 1167 path "/if:interfaces/if:interface/if:name"; 1168 } 1169 description 1170 "Reference to a base interface. If a reference to a 1171 subinterface is required, this leaf must be specified 1172 to indicate the base interface."; 1173 } 1174 leaf subinterface { 1175 type leafref { 1176 path "/if:interfaces/if:interface/if-ext:encapsulation" 1177 + "/if-l3-vlan:dot1q-vlan" 1178 + "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id"; 1179 } 1180 description 1181 "Reference to a subinterface -- this requires the base 1182 interface to be specified using the interface leaf in 1183 this container. If only a reference to a base interface 1184 is requuired, this leaf should not be set."; 1185 } 1187 description 1188 "Container for interface match conditions"; 1189 } 1190 } 1192 grouping match-proto-route-type-condition { 1193 description 1194 "This grouping provides route-type match condition"; 1196 leaf-list match-proto-route-type { 1197 type identityref { 1198 base proto-route-type; 1199 } 1200 description 1201 "Condition to check the protocol specific type 1202 of route. This is normally used during route 1203 importation to select routes or to set protocol 1204 specific attributes based on the route type."; 1205 } 1206 } 1208 grouping prefix-set-condition { 1209 description 1210 "This grouping provides prefix-set conditions"; 1212 container match-prefix-set { 1213 leaf prefix-set { 1214 type leafref { 1215 path "../../../../../../../defined-sets/" + 1216 "prefix-sets/prefix-set/name"; 1217 } 1218 description "References a defined prefix set"; 1219 } 1220 uses match-set-options-restricted-group; 1222 description 1223 "Match a referenced prefix-set according to the logic 1224 defined in the match-set-options leaf"; 1225 } 1226 } 1228 grouping neighbor-set-condition { 1229 description 1230 "This grouping provides neighbor-set conditions"; 1232 container match-neighbor-set { 1233 leaf neighbor-set { 1234 type leafref { 1235 path "../../../../../../../defined-sets/neighbor-sets/" + 1236 "neighbor-set/name"; 1237 require-instance true; 1238 } 1239 description "References a defined neighbor set"; 1240 } 1242 description 1243 "Match a referenced neighbor set according to the logic 1244 defined in the match-set-options-leaf"; 1245 } 1246 } 1248 grouping tag-set-condition { 1249 description 1250 "This grouping provides tag-set conditions"; 1252 container match-tag-set { 1253 leaf tag-set { 1254 type leafref { 1255 path "../../../../../../../defined-sets/tag-sets" + 1256 "/tag-set/name"; 1257 require-instance true; 1258 } 1259 description "References a defined tag set"; 1260 } 1261 uses match-set-options-restricted-group; 1262 description 1263 "Match a referenced tag set according to the logic defined 1264 in the match-options-set leaf"; 1265 } 1266 } 1268 grouping generic-conditions { 1269 description "Condition statement definitions for checking 1270 membership in a generic defined set"; 1272 uses match-interface-condition; 1273 uses prefix-set-condition; 1274 uses neighbor-set-condition; 1275 uses tag-set-condition; 1276 uses match-proto-route-type-condition; 1278 } 1280 grouping policy-conditions { 1281 description 1282 "Data for general policy conditions, i.e., those 1283 not related to match-sets"; 1285 leaf call-policy { 1286 type leafref { 1287 path "../../../../../../" + 1288 "rt-pol:policy-definitions/" + 1289 "rt-pol:policy-definition/rt-pol:name"; 1290 require-instance true; 1291 } 1292 description 1293 "Applies the statements from the specified policy 1294 definition and then returns control the current 1295 policy statement. Note that the called policy may 1296 itself call other policies (subject to 1297 implementation limitations). This is intended to 1298 provide a policy 'subroutine' capability. The 1299 called policy should contain an explicit or a 1300 default route disposition that returns an 1301 effective true (accept-route) or false 1302 (reject-route), otherwise the behavior may be 1303 ambiguous and implementation dependent"; 1304 } 1306 leaf source-protocol { 1307 type identityref { 1308 base rt:control-plane-protocol; 1309 } 1310 description 1311 "Condition to check the protocol / method used to install 1312 the route into the local routing table"; 1313 } 1314 } 1316 grouping policy-actions { 1317 description 1318 "Top-level grouping for policy actions"; 1320 container actions { 1321 description 1322 "Top-level container for policy action statements"; 1324 leaf policy-result { 1325 type policy-result-type; 1326 description 1327 "Select the final disposition for the route, either 1328 accept or reject."; 1329 } 1330 container set-metric { 1331 leaf metric-modificatiion { 1332 type metric-modification-type; 1333 description 1334 "Indicates how to modify the metric."; 1335 } 1336 leaf metric { 1337 type uint32; 1338 description 1339 "Metric value to set, add, or subtract."; 1340 } 1341 description 1342 "Set the metric for the route."; 1343 } 1344 container set-metric-type { 1345 leaf metric-type { 1346 type identityref { 1347 base metric-type; 1348 } 1349 description 1350 "Route metric type."; 1351 } 1352 description 1353 "Set the metric type for the route."; 1354 } 1355 container set-import-level { 1356 leaf import-level { 1357 type identityref { 1358 base import-level; 1359 } 1360 description 1361 "Route importation level."; 1362 } 1363 description 1364 "Set the import level for importation of routes."; 1365 } 1366 leaf set-preference { 1367 type uint16; 1368 description 1369 "Set the preference for the route."; 1370 } 1371 leaf set-tag { 1372 type tag-type; 1373 description 1374 "Set the tag for the route."; 1375 } 1376 leaf set-application-tag { 1377 type tag-type; 1378 description 1379 "Set the application tag for the route."; 1380 } 1381 } 1382 } 1384 grouping policy-statements { 1385 description 1386 "Grouping for the policy statements list"; 1388 container policy-statements { 1389 description 1390 "Enclosing container for policy statements"; 1392 list statement { 1393 key "name"; 1394 ordered-by user; 1395 description 1396 "Policy statements group conditions and actions 1397 within a policy definition. They are evaluated in 1398 the order specified (see the description of policy 1399 evaluation at the top of this module."; 1401 leaf name { 1402 type string; 1403 description 1404 "Name of the policy statement"; 1405 } 1406 container conditions { 1407 description 1408 "Condition statements for the current policy statement"; 1410 uses policy-conditions; 1412 uses generic-conditions; 1413 } 1415 uses policy-actions; 1416 } 1417 } 1418 } 1420 grouping policy-definitions { 1421 description 1422 "This grouping provides policy definitions"; 1424 leaf name { 1425 type string; 1426 description 1427 "Name of the top-level policy definition -- this name 1428 is used in references to the current policy"; 1429 } 1430 } 1432 grouping apply-policy-import { 1433 description 1434 "Grouping for applying import policies"; 1436 leaf-list import-policy { 1437 type leafref { 1438 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1439 "rt-pol:policy-definition/rt-pol:name"; 1440 require-instance true; 1441 } 1442 ordered-by user; 1443 description 1444 "List of policy names in sequence to be applied on 1445 receiving a routing update in the current context, e.g., 1446 for the current peer group, neighbor, address family, 1447 etc."; 1448 } 1450 leaf default-import-policy { 1451 type default-policy-type; 1452 default reject-route; 1453 description 1454 "Explicitly set a default policy if no policy definition 1455 in the import policy chain is satisfied."; 1456 } 1458 } 1460 grouping apply-policy-export { 1461 description 1462 "Grouping for applying export policies"; 1464 leaf-list export-policy { 1465 type leafref { 1466 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1467 "rt-pol:policy-definition/rt-pol:name"; 1468 require-instance true; 1469 } 1470 ordered-by user; 1471 description 1472 "List of policy names in sequence to be applied on 1473 sending a routing update in the current context, e.g., 1474 for the current peer group, neighbor, address family, 1475 etc."; 1476 } 1478 leaf default-export-policy { 1479 type default-policy-type; 1480 default reject-route; 1481 description 1482 "Explicitly set a default policy if no policy definition 1483 in the export policy chain is satisfied."; 1484 } 1485 } 1487 grouping apply-policy { 1488 description 1489 "Configuration data for routing policies"; 1491 uses apply-policy-import; 1492 uses apply-policy-export; 1493 } 1495 grouping apply-policy-group { 1496 description 1497 "Top level container for routing policy applications. This 1498 grouping is intended to be used in routing models where 1499 needed."; 1501 container apply-policy { 1502 description 1503 "Anchor point for routing policies in the model. 1504 Import and export policies are with respect to the local 1505 routing table, i.e., export (send) and import (receive), 1506 depending on the context."; 1508 uses apply-policy; 1510 } 1511 } 1513 container routing-policy { 1514 description 1515 "Top-level container for all routing policy"; 1517 container defined-sets { 1518 description 1519 "Predefined sets of attributes used in policy match 1520 statements"; 1522 container prefix-sets { 1523 description 1524 "Data definitions for a list of IPv4 or IPv6 1525 prefixes which are matched as part of a policy"; 1526 list prefix-set { 1527 key "name"; 1528 description 1529 "List of the defined prefix sets"; 1531 uses prefix-set; 1533 container prefixes { 1534 description 1535 "Container for the list of prefixes in a policy 1536 prefix list"; 1538 list prefix-list { 1539 key "ip-prefix masklength-lower masklength-upper"; 1540 description 1541 "List of prefixes in the prefix set"; 1543 uses prefix; 1544 } 1545 } 1546 } 1548 } 1550 container neighbor-sets { 1551 description 1552 "Data definition for a list of IPv4 or IPv6 1553 neighbors which can be matched in a routing policy"; 1555 list neighbor-set { 1556 key "name"; 1557 description 1558 "List of defined neighbor sets for use in policies."; 1560 uses neighbor-set; 1561 } 1562 } 1564 container tag-sets { 1565 description 1566 "Data definitions for a list of tags which can 1567 be matched in policies"; 1569 list tag-set { 1570 key "name"; 1571 description 1572 "List of tag set definitions."; 1573 uses tag-set; 1574 } 1575 } 1576 } 1578 container policy-definitions { 1579 description 1580 "Enclosing container for the list of top-level policy 1581 definitions"; 1583 list policy-definition { 1584 key "name"; 1585 description 1586 "List of top-level policy definitions, keyed by unique 1587 name. These policy definitions are expected to be 1588 referenced (by name) in policy chains specified in import 1589 or export configuration statements."; 1591 uses policy-definitions; 1593 uses policy-statements; 1594 } 1595 } 1597 } 1598 } 1599 1601 11. Policy examples 1603 Below we show an example of XML-encoded configuration data using the 1604 routing policy and BGP models to illustrate both how policies are 1605 defined, and also how they can be applied. Note that the XML has 1606 been simplified for readability. 1608 1610 12. References 1612 12.1. Normative references 1614 [I-D.ietf-netmod-intf-ext-yang] 1615 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1616 Sivaraj, "Common Interface Extension YANG Data Models", 1617 draft-ietf-netmod-intf-ext-yang-08 (work in progress), 1618 November 2019. 1620 [I-D.ietf-netmod-sub-intf-vlan-model] 1621 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1622 Sivaraj, "Sub-interface VLAN YANG Data Models", draft- 1623 ietf-netmod-sub-intf-vlan-model-06 (work in progress), 1624 November 2019. 1626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1627 Requirement Levels", BCP 14, RFC 2119, 1628 DOI 10.17487/RFC2119, March 1997, 1629 . 1631 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1632 DOI 10.17487/RFC3688, January 2004, 1633 . 1635 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1636 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1637 DOI 10.17487/RFC4271, January 2006, 1638 . 1640 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1641 the Network Configuration Protocol (NETCONF)", RFC 6020, 1642 DOI 10.17487/RFC6020, October 2010, 1643 . 1645 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1646 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1647 . 1649 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1650 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1651 . 1653 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1654 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1655 May 2017, . 1657 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1658 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1659 . 1661 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1662 and R. Wilton, "Network Management Datastore Architecture 1663 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1664 . 1666 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1667 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1668 . 1670 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1671 Routing Management (NMDA Version)", RFC 8349, 1672 DOI 10.17487/RFC8349, March 2018, 1673 . 1675 12.2. Informative references 1677 [I-D.ietf-idr-bgp-model] 1678 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1679 YANG Model for Service Provider Networks", draft-ietf-idr- 1680 bgp-model-08 (work in progress), February 2020. 1682 Appendix A. Acknowledgements 1684 The routing policy module defined in this draft is based on the 1685 OpenConfig route policy model. The authors would like to thank to 1686 OpenConfig for their contributions, especially Anees Shaikh, Rob 1687 Shakir, Kevin D'Souza, and Chris Chase. 1689 The authors are grateful for valuable contributions to this document 1690 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1691 George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, 1692 Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and 1693 John Heasley. 1695 Authors' Addresses 1697 Yingzhen Qu 1698 Futurewei 1699 2330 Central Expressway 1700 Santa Clara CA 95050 1701 USA 1703 Email: yingzhen.qu@futurewei.com 1705 Jeff Tantsura 1706 Apstra 1708 Email: jefftant.ietf@gmail.com 1710 Acee Lindem 1711 Cisco 1712 301 Mindenhall Way 1713 Cary, NC 27513 1714 US 1716 Email: acee@cisco.com 1718 Xufeng Liu 1719 Volta Networks 1721 Email: xufeng.liu.ietf@gmail.com