idnits 2.17.1 draft-ietf-rtgwg-policy-model-14.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 281 has weird spacing: '...h-lower uin...' == Line 282 has weird spacing: '...h-upper uin...' == Line 481 has weird spacing: '...h-lower uin...' == Line 482 has weird spacing: '...h-upper uin...' == Line 1096 has weird spacing: '... enum add-m...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 1, 2020) is 1417 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-08 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). 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: December 3, 2020 Apstra 6 A. Lindem 7 Cisco 8 X. Liu 9 Volta Networks 10 June 1, 2020 12 A YANG Data Model for Routing Policy Management 13 draft-ietf-rtgwg-policy-model-14 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 December 3, 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 module . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 10.1. Routing policy model . . . . . . . . . . . . . . . . . . 15 74 11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 36 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 76 12.1. Normative references . . . . . . . . . . . . . . . . . . 37 77 12.2. Informative references . . . . . . . . . . . . . . . . . 39 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 81 1. Introduction 83 This document describes a YANG [RFC7950] data model for routing 84 policy configuration based on operational usage and best practices in 85 a variety of service provider networks. The model is intended to be 86 vendor-neutral, in order to allow operators to manage policy 87 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 effect 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 Routing Policy: A routing policy defines how routes are imported, 131 exported, modified, and advertised between routing protocols 132 instances or within a single routing protocol instance. 134 The following terms are defined in [RFC8342]: 136 o client 138 o server 140 o configuration 141 o system state 143 o operational state 145 o intended configuration 147 The following terms are defined in [RFC7950]: 149 o action 151 o augment 153 o container 155 o container with presence 157 o data model 159 o data node 161 o feature 163 o leaf 165 o list 167 o mandatory node 169 o module 171 o schema tree 173 o RPC (Remote Procedure Call) operation 175 2.1. Tree Diagrams 177 Tree diagrams used in this document follow the notation defined in 178 [RFC8340]. 180 2.2. Prefixes in Data Node Names 182 In this document, names of data nodes, actions, and other data model 183 objects are often used without a prefix, as long as it is clear from 184 the context in which YANG module each name is defined. Otherwise, 185 names are prefixed using the standard prefix associated with the 186 corresponding YANG module, as shown in Table 1. 188 +------------+--------------------+----------------------+ 189 | Prefix | YANG module | Reference | 190 +------------+--------------------+----------------------+ 191 | if | ietf-interfaces | [RFC8343] | 192 | | | | 193 | rt | ietf-routing | [RFC8349] | 194 | | | | 195 | yang | ietf-yang-types | [RFC6991] | 196 | | | | 197 | inet | ietf-inet-types | [RFC6991] | 198 | | | | 199 | if-ext | ietf-if-extensions | [INTF-EXT-YANG] | 200 | | | | 201 | if-l3-vlan | ietf-if-l3-vlan | [SUB-INTF-VLAN-YANG] | 202 +------------+--------------------+----------------------+ 204 Table 1: Prefixes and Corresponding YANG Modules 206 3. Model overview 208 The routing policy module has three main parts: 210 o A generic framework to express policies as sets of related 211 conditions and actions. This includes match sets and actions that 212 are useful across many routing protocols. 214 o A structure that allows routing protocol models to add protocol- 215 specific policy conditions and actions though YANG augmentations. 216 There is a complete example of this for BGP [RFC4271] policies in 217 the proposed vendor-neutral BGP data model 218 [I-D.ietf-idr-bgp-model]. 220 o A reusable grouping for attaching import and export rules in the 221 context of routing configuration for different protocols, VRFs, 222 etc. This also enables creation of policy chains and expressing 223 default policy behavior. 225 The module makes use of the standard Internet types, such as IP 226 addresses, autonomous system numbers, etc., defined in RFC 6991 227 [RFC6991]. 229 4. Route policy expression 231 Policies are expressed as a sequence of top-level policy definitions 232 each of which consists of a sequence of policy statements. Policy 233 statements in turn consist of simple condition-action tuples. 234 Conditions may include multiple match or comparison operations, and 235 similarly, actions may effect multiple changes to route attributes, 236 or indicate a final disposition of accepting or rejecting the route. 237 This structure is shown below. 239 +--rw routing-policy 240 +--rw policy-definitions 241 +--rw policy-definition* [name] 242 +--rw name string 243 +--rw statements 244 +--rw statement* [name] 245 +--rw name string 246 +--rw conditions 247 | ... 248 +--rw actions 249 ... 251 4.1. Defined sets for policy matching 253 The models provides a set of generic sets that can be used for 254 matching in policy conditions. These sets are applicable for route 255 selection across multiple routing protocols. They may be further 256 augmented by protocol-specific models which have their own defined 257 sets. The supported defined sets include: 259 o prefix sets - define a set of IP prefixes, each with an associated 260 IP prefix and netmask range (or exact length) 262 o neighbor sets - define a set of neighboring nodes by their IP 263 addresses. These sets are used for selecting routes based on the 264 neighbors advertising the routes. 266 o tag set - define a set of generic tag values that can be used in 267 matches for filtering routes 269 The model structure for defined sets is shown below. 271 +--rw routing-policy 272 +--rw defined-sets 273 | +--rw prefix-sets 274 | | +--rw prefix-set* [name] 275 | | +--rw name string 276 | | +--rw mode? enumeration 277 | | +--rw prefixes 278 | | +--rw prefix-list* [ip-prefix mask-length-lower 279 | | mask-length-upper] 280 | | +--rw ip-prefix inet:ip-prefix 281 | | +--rw mask-length-lower uint8 282 | | +--rw mask-length-upper uint8 283 | +--rw neighbor-sets 284 | | +--rw neighbor-set* [name] 285 | | +--rw name string 286 | | +--rw address* inet:ip-address 287 | +--rw tag-sets 288 | +--rw tag-set* [name] 289 | +--rw name string 290 | +--rw tag-value* tag-type 292 4.2. Policy conditions 294 Policy statements consist of a set of conditions and actions (either 295 of which may be empty). Conditions are used to match route 296 attributes against a defined set (e.g., a prefix set), or to compare 297 attributes against a specific value. 299 Match conditions may be further modified using the match-set-options 300 configuration which allows operators to change the behavior of a 301 match. Three options are supported: 303 o ALL - match is true only if the given value matches all members of 304 the set. 306 o ANY - match is true if the given value matches any member of the 307 set. 309 o INVERT - match is true if the given value does not match any 310 member of the given set. 312 Not all options are appropriate for matching against all defined sets 313 (e.g., match ALL in a prefix set does not make sense). In the model, 314 a restricted set of match options is used where applicable. 316 Comparison conditions may similarly use options to change how route 317 attributes should be tested, e.g., for equality or inequality, 318 against a given value. 320 While most policy conditions will be added by individual routing 321 protocol models via augmentation, this routing policy model includes 322 several generic match conditions and also the ability to test which 323 protocol or mechanism installed a route (e.g., BGP, IGP, static, 324 etc.). The conditions included in the model are shown below. 326 +--rw routing-policy 327 +--rw policy-definitions 328 +--rw policy-definition* [name] 329 +--rw name string 330 +--rw statements 331 +--rw statement* [name] 332 +--rw conditions 333 | +--rw call-policy? 334 | +--rw source-protocol? 335 | +--rw match-interface 336 | | +--rw interface? 337 | | +--rw subinterface? 338 | +--rw match-prefix-set 339 | | +--rw prefix-set? 340 | | +--rw match-set-options? 341 | +--rw match-neighbor-set 342 | | +--rw neighbor-set? 343 | +--rw match-tag-set 344 | | +--rw tag-set? 345 | | +--rw match-set-options? 346 | +--rw match-route-type* identityref 348 4.3. Policy actions 350 When policy conditions are satisfied, policy actions are used to set 351 various attributes of the route being processed, or to indicate the 352 final disposition of the route, i.e., accept or reject. 354 Similar to policy conditions, the routing policy model includes 355 generic actions in addition to the basic route disposition actions. 356 These are shown below. 358 +--rw routing-policy 359 +--rw policy-definitions 360 +--rw policy-definition* [name] 361 +--rw statements 362 +--rw statement* [name] 363 +--rw actions 364 +--rw policy-result? policy-result-type 365 +--rw set-metric 366 | +--rw metric-modification? 367 | | metric-modification-type 368 | +--rw metric? uint32 369 +--rw set-metric-type 370 | +--rw metric-type? identityref 371 +--rw set-import-level 372 | +--rw import-level? identityref 373 +--rw set-preference? uint16 374 +--rw set-tag? tag-type 375 +--rw set-application-tag? tag-type 377 4.4. Policy subroutines 379 Policy 'subroutines' (or nested policies) are supported by allowing 380 policy statement conditions to reference other policy definitions 381 using the call-policy configuration. Called policies apply their 382 conditions and actions before returning to the calling policy 383 statement and resuming evaluation. The outcome of the called policy 384 affects the evaluation of the calling policy. If the called policy 385 results in an accept-route, then the subroutine returns an effective 386 boolean true value to the calling policy. For the calling policy, 387 this is equivalent to a condition statement evaluating to a true 388 value and evaluation of the policy continues (see Section 5). Note 389 that the called policy may also modify attributes of the route in its 390 action statements. Similarly, a reject-route action returns false 391 and the calling policy evaluation will be affected accordingly. When 392 the end of the subroutine policy chain is reached, the default route 393 disposition action is returned (i.e., boolean false for reject-route 394 unless an alternate default action is specified for the chain). 395 Consequently, a subroutine cannot explicitly accept or reject a 396 route. Rather it merely provides an indication that 'call-policy' 397 condition returns boolean true or false indicating whether or not the 398 condition matches. Route acceptance or rejection is solely 399 determined by the top-level policy. 401 Note that the called policy may itself call other policies (subject 402 to implementation limitations). The model does not prescribe a 403 nesting depth because this varies among implementations. For 404 example, some major implementation may only support a single level of 405 subroutine recursion. As with any routing policy construction, care 406 must be taken with nested policies to ensure that the effective 407 return value results in the intended behavior. Nested policies are a 408 convenience in many routing policy constructions but creating 409 policies nested beyond a small number of levels (e.g., 2-3) should be 410 discouraged. 412 5. Policy evaluation 414 Evaluation of each policy definition proceeds by evaluating its 415 corresponding individual policy statements in order. When all the 416 condition statements in a policy statement are satisfied, the 417 corresponding action statements are executed. If the actions include 418 either accept-route or reject-route actions, evaluation of the 419 current policy definition stops, and no further policy definitions in 420 the chain are evaluated. 422 If the conditions are not satisfied, then evaluation proceeds to the 423 next policy statement. If none of the policy statement conditions 424 are satisfied, then evaluation of the current policy definition 425 stops, and the next policy definition in the chain is evaluated. 426 When the end of the policy chain is reached, the default route 427 disposition action is performed (i.e., reject-route unless an 428 alternate default action is specified for the chain). 430 Note that the route's pre-policy attributes are always used for 431 testing policy statement conditions. In other words, if actions 432 modify the policy application specific attributes, those 433 modifications are not used for policy statement conditions. 435 6. Applying routing policy 437 Routing policy is applied by defining and attaching policy chains in 438 various routing contexts. Policy chains are sequences of policy 439 definitions (described in Section 4) that have an associated 440 direction (import or export) with respect to the routing context in 441 which they are defined. The routing policy model defines an apply- 442 policy grouping that can be imported and used by other models. As 443 shown below, it allows definition of import and export policy chains, 444 as well as specifying the default route disposition to be used when 445 no policy definition in the chain results in a final decision. 447 +--rw apply-policy 448 | +--rw import-policy* 449 | +--rw default-import-policy? default-policy-type 450 | +--rw export-policy* 451 | +--rw default-export-policy? default-policy-type 453 The default policy defined by the model is to reject the route for 454 both import and export policies. 456 7. Routing protocol-specific policies 458 Routing models that require the ability to apply routing policy may 459 augment the routing policy model with protocol or other specific 460 policy configuration. The routing policy model assumes that 461 additional defined sets, conditions, and actions may all be added by 462 other models. 464 An example of this is shown below, in which the BGP configuration 465 model in [I-D.ietf-idr-bgp-model] adds new defined sets to match on 466 community values or AS paths. The model similarly augments BGP- 467 specific conditions and actions in the corresponding sections of the 468 routing policy model. 470 module: ietf-routing-policy 471 +--rw routing-policy 472 +--rw defined-sets 473 | +--rw prefix-sets 474 | | +--rw prefix-set* [name] 475 | | +--rw name string 476 | | +--rw mode? enumeration 477 | | +--rw prefixes 478 | | +--rw prefix-list* [ip-prefix mask-length-lower 479 | | mask-length-upper] 480 | | +--rw ip-prefix inet:ip-prefix 481 | | +--rw mask-length-lower uint8 482 | | +--rw mask-length-upper uint8 483 | +--rw neighbor-sets 484 | | +--rw neighbor-set* [name] 485 | | +--rw name string 486 | | +--rw address* inet:ip-address 487 | +--rw tag-sets 488 | | +--rw tag-set* [name] 489 | | +--rw name string 490 | | +--rw tag-value* tag-type 491 | +--rw bp:bgp-defined-sets 492 | +--rw bp:community-sets 493 | | +--rw bp:community-set* [name] 494 | | +--rw bp:name string 495 | | +--rw bp:member* union 496 | +--rw bp:ext-community-sets 497 | | +--rw bp:ext-community-set* [name] 498 | | +--rw bp:name string 499 | | +--rw bp:member* union 500 | +--rw bp:as-path-sets 501 | +--rw bp:as-path-set* [name] 502 | +--rw bp:name string 503 | +--rw bp:member* string 504 +--rw policy-definitions 505 +--rw policy-definition* [name] 506 +--rw name string 507 +--rw statements 508 +--rw statement* [name] 509 +--rw name string 510 +--rw conditions 511 | +--rw call-policy? 512 | +--rw source-protocol? identityref 513 | +--rw match-interface 514 | | +--rw interface? 515 | | +--rw subinterface? 516 | +--rw match-prefix-set 517 | | +--rw prefix-set? prefix-set/name 518 | | +--rw match-set-options? match-set-options-type 519 | +--rw match-neighbor-set 520 | | +--rw neighbor-set? 521 | +--rw match-tag-set 522 | | +--rw tag-set? 523 | | +--rw match-set-options? match-set-options-type 524 | +--rw match-route-type* identityref 525 | +--rw bp:bgp-conditions 526 | +--rw bp:med-eq? uint32 527 | +--rw bp:origin-eq? bt:bgp-origin-attr-type 528 | +--rw bp:next-hop-in* inet:ip-address-no-zone 529 | +--rw bp:afi-safi-in* identityref 530 | +--rw bp:local-pref-eq? uint32 531 | +--rw bp:route-type? enumeration 532 | +--rw bp:community-count 533 | +--rw bp:as-path-length 534 | +--rw bp:match-community-set 535 | | +--rw bp:community-set? 536 | | +--rw bp:match-set-options? 537 | +--rw bp:match-ext-community-set 538 | | +--rw bp:ext-community-set? 539 | | +--rw bp:match-set-options? 540 | +--rw bp:match-as-path-set 541 | +--rw bp:as-path-set? 542 | +--rw bp:match-set-options? 543 +--rw actions 544 +--rw policy-result? policy-result-type 545 +--rw set-metric 546 | +--rw metric-modification? 547 | +--rw metric? uint32 548 +--rw set-metric-type 549 | +--rw metric-type? identityref 550 +--rw set-import-level 551 | +--rw import-level? identityref 552 +--rw set-preference? uint16 553 +--rw set-tag? tag-type 554 +--rw set-application-tag? tag-type 555 +--rw bp:bgp-actions 556 +--rw bp:set-route-origin?bt:bgp-origin-attr-type 557 +--rw bp:set-local-pref? uint32 558 +--rw bp:set-next-hop? bgp-next-hop-type 559 +--rw bp:set-med? bgp-set-med-type 560 +--rw bp:set-as-path-prepend 561 | +--rw bp:repeat-n? uint8 562 +--rw bp:set-community 563 | +--rw bp:method? enumeration 564 | +--rw bp:options? 565 | +--rw bp:inline 566 | | +--rw bp:communities* union 567 | +--rw bp:reference 568 | +--rw bp:community-set-ref? 569 +--rw bp:set-ext-community 570 +--rw bp:method? enumeration 571 +--rw bp:options? 572 +--rw bp:inline 573 | +--rw bp:communities* union 574 +--rw bp:reference 575 +--rw bp:ext-community-set-ref? 577 8. Security Considerations 579 The YANG modules specified in this document define a schema for data 580 that is designed to be accessed via network management protocols such 581 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 582 is the secure transport layer, and the mandatory-to-implement secure 583 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 584 is HTTPS, and the mandatory-to-implement secure transport is TLS 585 [RFC8446]. 587 The NETCONF Access Control Model (NACM) [RFC8341] provides the means 588 to restrict access for particular NETCONF or RESTCONF users to a pre- 589 configured subset of all available NETCONF or RESTCONF protocol 590 operations and content. 592 There are a number of data nodes defined in this YANG module that are 593 writable/creatable/deletable (i.e., config true, which is the 594 default). These data nodes may be considered sensitive or vulnerable 595 in some network environments. Write operations (e.g., edit-config) 596 to these data nodes without proper protection can have a negative 597 effect on network operations. These are the subtrees and data nodes 598 and their sensitivity/vulnerability: 600 /routing-policy 602 /routing-policy/defined-sets/prefix-sets 604 /routing-policy/defined-sets/neighbor-sets 606 /routing-policy/defined-sets/tag-sets 608 /routing-policy/policy-definitions 610 Unauthorized access to any data node of these subtrees can disclose 611 the operational state information of routing policies on this device. 613 Routing policy configuration has a significant impact on network 614 operations, and, as such, any related model carries potential 615 security risks. Unauthorized access or invalid data could cause 616 major disruption. 618 9. IANA Considerations 620 This document registers a URI in the IETF XML registry [RFC3688]. 621 Following the format in [RFC3688], the following registration is 622 requested to be made: 624 URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy 625 Registrant Contact: The IESG. 626 XML: N/A, the requested URI is an XML namespace. 628 This document registers a YANG module in the YANG Module Names 629 registry [RFC6020]. 631 name: ietf-routing-policy 632 namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy 633 prefix: rt-pol 634 reference: RFC XXXX 636 10. YANG module 638 The routing policy model is described by the YANG modules in the 639 sections below. [RFC2328], [RFC3101], [RFC5130], and [RFC5302] are 640 referenced here since they are referenced in the YANG model but not 641 elsewhere in the draft. 643 10.1. Routing policy model 645 file "ietf-routing-policy@2020-06-01.yang" 646 module ietf-routing-policy { 648 yang-version "1.1"; 650 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; 651 prefix rt-pol; 653 import ietf-inet-types { 654 prefix "inet"; 655 reference "RFC 6991: Common YANG Data Types"; 656 } 658 import ietf-yang-types { 659 prefix "yang"; 660 reference "RFC 6991: Common YANG Data Types"; 661 } 663 import ietf-interfaces { 664 prefix "if"; 665 reference "RFC 8343: A YANG Data Model for Interface 666 Management (NMDA Version)"; 667 } 669 import ietf-routing { 670 prefix "rt"; 671 reference "RFC 8349: A YANG Data Model for Routing 672 Management (NMDA Version)"; 673 } 675 import ietf-if-extensions { 676 prefix "if-ext"; 677 reference "RFC YYYY: Common Interface Extension YANG 678 Data Models. Please replace YYYY with 679 published RFC number for 680 draft-ietf-netmod-intf-ext-yang."; 681 } 683 import ietf-if-l3-vlan { 684 prefix "if-l3-vlan"; 685 reference "RFC ZZZZ: Sub-interface VLAN YANG Data Models. 686 Please replace ZZZZ with published RFC number 687 for draft-ietf-netmod-sub-intf-vlan-model."; 688 } 690 organization 691 "IETF RTGWG - Routing Area Working Group"; 692 contact 693 "WG Web: 694 WG List: 696 Editor: Yingzhen Qu 697 698 Jeff Tantsura 699 700 Acee Lindem 701 702 Xufeng Liu 703 "; 705 description 706 "This module describes a YANG model for routing policy 707 configuration. It is a limited subset of all of the policy 708 configuration parameters available in the variety of vendor 709 implementations, but supports widely used constructs for 710 managing how routes are imported, exported, modified and 711 advertised across different routing protocol instances or 712 within a single routing protocol instance. This module is 713 intended to be used in conjunction with routing protocol 714 configuration modules (e.g., BGP) defined in other models. 716 Route policy expression: 718 Policies are expressed as a set of top-level policy 719 definitions, each of which consists of a sequence of policy 720 statements. Policy statements consist of simple 721 condition-action tuples. Conditions may include multiple match 722 or comparison operations, and similarly actions may be 723 multitude of changes to route attributes or a final 724 disposition of accepting or rejecting the route. 726 Route policy evaluation: 728 Policy definitions are referenced in routing protocol 729 configurations using import and export configuration 730 statements. The arguments are members of an ordered list of 731 named policy definitions which comprise a policy chain, and 732 optionally, an explicit default policy action (i.e., reject 733 or accept). 735 Evaluation of each policy definition proceeds by evaluating 736 its corresponding individual policy statements in order. When 737 a condition statement in a policy statement is satisfied, the 738 corresponding action statement is executed. If the action 739 statement has either accept-route or reject-route actions, 740 policy evaluation of the current policy definition stops, and 741 no further policy definitions in the chain are evaluated. 743 If the condition is not satisfied, then evaluation proceeds to 744 the next policy statement. If none of the policy statement 745 conditions are satisfied, then evaluation of the current 746 policy definition stops, and the next policy definition in the 747 chain is evaluated. When the end of the policy chain is 748 reached, the default route disposition action is performed 749 (i.e., reject-route unless an alternate default action is 750 specified for the chain). 752 Policy 'subroutines' (or nested policies) are supported by 753 allowing policy statement conditions to reference another 754 policy definition which applies conditions and actions from 755 the referenced policy before returning to the calling policy 756 statement and resuming evaluation. If the called policy 757 results in an accept-route (either explicit or by default), 758 then the subroutine returns an effective true value to the 759 calling policy. Similarly, a reject-route action returns 760 false. If the subroutine returns true, the calling policy 761 continues to evaluate the remaining conditions (using a 762 modified route if the subroutine performed any changes to the 763 route). 765 Copyright (c) 2020 IETF Trust and the persons identified as 766 authors of the code. All rights reserved. 768 Redistribution and use in source and binary forms, with or 769 without modification, is permitted pursuant to, and subject to 770 the license terms contained in, the Simplified BSD License set 771 forth in Section 4.c of the IETF Trust's Legal Provisions 772 Relating to IETF Documents 773 (https://trustee.ietf.org/license-info). 775 This version of this YANG module is part of RFC XXXX 776 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 777 for full legal notices. 779 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 780 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT 781 RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 782 interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, 783 and only when, they appear in all capitals, as shown here. 785 This version of this YANG module is part of RFC XXXX; 786 see the RFC itself for full legal notices."; 788 revision "2020-06-01" { 789 description 790 "Initial revision."; 791 reference 792 "RFC XXXX: Routing Policy Configuration Model for Service 793 Provider Networks"; 794 } 796 /* Identities */ 798 identity metric-type { 799 description 800 "Base identity for route metric types."; 801 } 803 identity ospf-type-1-metric { 804 base metric-type; 805 description 806 "Identity for the OSPF type 1 external metric types. It 807 is only applicable to OSPF routes."; 808 reference 809 "RFC 2328 - OSPF Version 2"; 810 } 812 identity ospf-type-2-metric { 813 base metric-type; 814 description 815 "Identity for the OSPF type 2 external metric types. It 816 is only applicable to OSPF routes."; 817 reference 818 "RFC 2328 - OSPF Version 2"; 819 } 821 identity isis-internal-metric { 822 base metric-type; 823 description 824 "Identity for the IS-IS internal metric types. It is only 825 applicable to IS-IS routes."; 826 reference 827 "RFC 5302 - Domain-Wide Prefix Distributino with 828 Two-Level IS-IS"; 829 } 831 identity isis-external-metric { 832 base metric-type; 833 description 834 "Identity for the IS-IS external metric types. It is only 835 applicable to IS-IS routes."; 837 reference 838 "RFC 5302 - Domain-Wide Prefix Distributino with 839 Two-Level IS-IS"; 840 } 842 identity import-level { 843 description 844 "Base identity for route import level."; 845 } 847 identity ospf-normal { 848 base import-level; 849 description 850 "Identity for OSPF importation into normal areas 851 It is only applicable to routes imported 852 into the OSPF protocol."; 853 reference 854 "RFC 2328 - OSPF Version 2"; 855 } 857 identity ospf-nssa-only { 858 base import-level; 859 description 860 "Identity for the OSPF Not-So-Stubby Area (NSSA) area 861 importation. It is only applicable to routes imported 862 into the OSPF protocol."; 863 reference 864 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 865 } 867 identity ospf-normal-nssa { 868 base import-level; 869 description 870 "Identity for OSPF importation into both normal and NSSA 871 areas, it is only applicable to routes imported into 872 the OSPF protocol."; 873 reference 874 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 875 } 877 identity isis-level-1 { 878 base import-level; 879 description 880 "Identity for IS-IS Level 1 area importation. It is only 881 applicable to routes imported into the IS-IS protocol."; 882 reference 883 "RFC 5302 - Domain-Wide Prefix Distributino with 884 Two-Level IS-IS"; 886 } 888 identity isis-level-2 { 889 base import-level; 890 description 891 "Identity for IS-IS Level 2 area importation. It is only 892 applicable to routes imported into the IS-IS protocol."; 893 reference 894 "RFC 5302 - Domain-Wide Prefix Distributino with 895 Two-Level IS-IS"; 896 } 898 identity isis-level-1-2 { 899 base import-level; 900 description 901 "Identity for IS-IS Level 1 and Level 2 area importation. It 902 is only applicable to routes imported into the IS-IS 903 protocol."; 904 reference 905 "RFC 5302 - Domain-Wide Prefix Distributino with 906 Two-Level IS-IS"; 907 } 909 identity proto-route-type { 910 description 911 "Base identity for route type within a protocol."; 912 } 914 identity isis-level-1-type { 915 base proto-route-type; 916 description 917 "Identity for IS-IS Level 1 route type. It is only 918 applicable to IS-IS routes."; 919 reference 920 "RFC 5302 - Domain-Wide Prefix Distributino with 921 Two-Level IS-IS"; 922 } 924 identity isis-level-2-type { 925 base proto-route-type; 926 description 927 "Identity for IS-IS Level 2 route type. It is only 928 applicable to IS-IS routes."; 929 reference 930 "RFC 5302 - Domain-Wide Prefix Distributino with 931 Two-Level IS-IS"; 932 } 933 identity ospf-internal-type { 934 base proto-route-type; 935 description 936 "Identity for OSPF intra-area or inter-area route type. 937 It is only applicable to OSPF routes."; 938 reference 939 "RFC 2328 - OSPF Version 2"; 940 } 942 identity ospf-external-type { 943 base proto-route-type; 944 description 945 "Identity for OSPF external type 1/2 route type. 946 It is only applicable to OSPF routes."; 947 reference 948 "RFC 2328 - OSPF Version 2"; 949 } 951 identity ospf-external-t1 { 952 base ospf-external-type; 953 description 954 "Identity for OSPF external type 1 route type. 955 It is only applicable to OSPF routes."; 956 reference 957 "RFC 2328 - OSPF Version 2"; 958 } 960 identity ospf-external-t2-type { 961 base ospf-external-type; 962 description 963 "Identity for OSPF external type 2 route type. 964 It is only applicable to OSPF routes."; 965 reference 966 "RFC 2328 - OSPF Version 2"; 967 } 969 identity ospf-nssa-type { 970 base proto-route-type; 971 description 972 "Identity for OSPF NSSA type 1/2 route type. 973 It is only applicable to OSPF routes."; 974 reference 975 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 976 } 978 identity ospf-nssa-t1 { 979 base ospf-nssa-type; 980 description 981 "Identity for OSPF NSSA type 1 route type. 982 It is only applicable to OSPF routes."; 983 reference 984 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 985 } 987 identity ospf-nssa-t2 { 988 base ospf-nssa-type; 989 description 990 "Identity for OSPF NSSA type 2 route type. 991 It is only applicable to OSPF routes."; 992 reference 993 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 994 } 996 identity bgp-local { 997 base proto-route-type; 998 description 999 "Identity for BGP local route type. 1000 It is only applicable to BGP routes."; 1001 reference 1002 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 1003 } 1005 identity bgp-external { 1006 base proto-route-type; 1007 description 1008 "Identity for BGP external route type. 1009 It is only applicable to BGP routes."; 1010 reference 1011 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 1012 } 1014 /* Type Definitions */ 1016 typedef default-policy-type { 1017 type enumeration { 1018 enum accept-route { 1019 description 1020 "Default policy to accept the route."; 1021 } 1022 enum reject-route { 1023 description 1024 "Default policy to reject the route."; 1025 } 1026 } 1027 description 1028 "Type used to specify route disposition in 1029 a policy chain. This typedef retained for 1030 name compatibility with default import and 1031 export policy."; 1032 } 1034 typedef policy-result-type { 1035 type enumeration { 1036 enum accept-route { 1037 description 1038 "Policy accepts the route."; 1039 } 1040 enum reject-route { 1041 description 1042 "Policy rejects the route."; 1043 } 1044 } 1045 description 1046 "Type used to specify route disposition in 1047 a policy chain."; 1048 } 1050 typedef tag-type { 1051 type union { 1052 type uint32; 1053 type yang:hex-string; 1054 } 1055 description 1056 "Type for expressing route tags on a local system, 1057 including IS-IS and OSPF; may be expressed as either decimal 1058 or hexadecimal integer."; 1059 reference 1060 "RFC 2328 - OSPF Version 2 1061 RFC 5130 - A Policy Control Mechanism in IS-IS Using 1062 Administrative Tags"; 1063 } 1065 typedef match-set-options-type { 1066 type enumeration { 1067 enum any { 1068 description 1069 "Match is true if given value matches any member 1070 of the defined set."; 1071 } 1072 enum all { 1073 description 1074 "Match is true if given value matches all 1075 members of the defined set."; 1076 } 1077 enum invert { 1078 description 1079 "Match is true if given value does not match any 1080 member of the defined set."; 1081 } 1082 } 1083 default any; 1084 description 1085 "Options that govern the behavior of a match statement. The 1086 default behavior is any, i.e., the given value matches any 1087 of the members of the defined set."; 1088 } 1090 typedef metric-modification-type { 1091 type enumeration { 1092 enum set-metric { 1093 description 1094 "Set the metric to the specified value."; 1095 } 1096 enum add-metric { 1097 description 1098 "Add the specified value to the existing metric. 1099 If the result would overflow the maximum metric 1100 (0xffffffff), set the metric to the maximum."; 1101 } 1102 enum subtract-metric { 1103 description 1104 "Subtract the specified value to the existing metric. If 1105 the result would be less than 0, set the metric to 0."; 1106 } 1107 } 1108 description 1109 "Type used to specify how to set the metric given the 1110 specified value."; 1111 } 1113 /* Groupings */ 1115 grouping prefix { 1116 description 1117 "Configuration data for a prefix definition."; 1119 leaf ip-prefix { 1120 type inet:ip-prefix; 1121 mandatory true; 1122 description 1123 "The IP prefix represented as an IPv6 or IPv4 network 1124 number followed prefix length with an intervening slash 1125 character a delimiter -- while the prefix may be either 1126 IPv4 or IPv6, most implementations require all members 1127 of the prefix set to be the same address family. Mixing 1128 address types in the same prefix set is likely to cause 1129 an error."; 1130 } 1132 leaf mask-length-lower { 1133 type uint8; 1134 description 1135 "Mask length range lower bound."; 1136 } 1137 leaf mask-length-upper { 1138 type uint8 { 1139 range "1..128"; 1140 } 1141 must "../mask-length-upper >= ../mask-length-lower" { 1142 error-message "The upper bound should not be less" 1143 + "than lower bound."; 1144 } 1145 description 1146 "Mask length range upper bound. 1148 The combination of mask-length-lower and mask-length-upper 1149 define a range for the mask length, or single 'exact' 1150 length if mask-length-lower and mask-length-upper are 1151 equal. 1153 Example: 192.0.2.0/24 through 192.0.2.0/26 would be 1154 expressed as prefix: 192.0.2.0/24, 1155 mask-length-lower=24, 1156 mask-length-upper=26 1158 Example: 192.0.2.0/24 (an exact match) would be 1159 expressed as prefix: 192.0.2.0/24, 1160 mask-length-lower=24, 1161 mask-length-upper=24"; 1162 } 1163 } 1165 grouping match-set-options-group { 1166 description 1167 "Grouping containing options relating to how a particular set 1168 should be matched."; 1170 leaf match-set-options { 1171 type match-set-options-type; 1172 description 1173 "Optional parameter that governs the behavior of the 1174 match operation."; 1175 } 1176 } 1178 grouping match-set-options-restricted-group { 1179 description 1180 "Grouping for a restricted set of match operation 1181 modifiers."; 1183 leaf match-set-options { 1184 type match-set-options-type { 1185 enum any { 1186 description 1187 "Match is true if given value matches any 1188 member of the defined set."; 1189 } 1190 enum invert { 1191 description 1192 "Match is true if given value does not match 1193 any member of the defined set."; 1194 } 1195 } 1196 description 1197 "Optional parameter that governs the behavior of the 1198 match operation. This leaf only supports matching on 1199 'any' member of the set or 'invert' the match. 1200 Matching on 'all' is not supported."; 1201 } 1202 } 1204 grouping match-interface-condition { 1205 description 1206 "This grouping provides interface match condition."; 1208 container match-interface { 1209 leaf interface { 1210 type leafref { 1211 path "/if:interfaces/if:interface/if:name"; 1212 } 1213 description 1214 "Reference to a base interface. If a reference to a 1215 subinterface is required, this leaf must be specified 1216 to indicate the base interface."; 1217 } 1218 leaf subinterface { 1219 type leafref { 1220 path "/if:interfaces/if:interface/if-ext:encapsulation" 1221 + "/if-l3-vlan:dot1q-vlan" 1222 + "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id"; 1223 } 1224 description 1225 "Reference to a subinterface -- this requires the base 1226 interface to be specified using the interface leaf in 1227 this container. If only a reference to a base interface 1228 is required, this leaf should not be set."; 1229 } 1231 description 1232 "Container for interface match conditions"; 1233 } 1234 } 1236 grouping match-route-type-condition { 1237 description 1238 "This grouping provides route-type match condition"; 1240 leaf-list match-route-type { 1241 type identityref { 1242 base proto-route-type; 1243 } 1244 description 1245 "Condition to check the protocol specific type 1246 of route. This is normally used during route 1247 importation to select routes or to set protocol 1248 specific attributes based on the route type."; 1249 } 1250 } 1252 grouping prefix-set-condition { 1253 description 1254 "This grouping provides prefix-set conditions."; 1256 container match-prefix-set { 1257 leaf prefix-set { 1258 type leafref { 1259 path "../../../../../../../defined-sets/" + 1260 "prefix-sets/prefix-set/name"; 1261 } 1262 description 1263 "References a defined prefix set."; 1264 } 1265 uses match-set-options-restricted-group; 1267 description 1268 "Match a referenced prefix-set according to the logic 1269 defined in the match-set-options leaf."; 1270 } 1271 } 1273 grouping neighbor-set-condition { 1274 description 1275 "This grouping provides neighbor-set conditions."; 1277 container match-neighbor-set { 1278 leaf neighbor-set { 1279 type leafref { 1280 path "../../../../../../../defined-sets/neighbor-sets/" + 1281 "neighbor-set/name"; 1282 require-instance true; 1283 } 1284 description 1285 "References a defined neighbor set."; 1286 } 1288 description 1289 "Match a referenced neighbor set according to the logic 1290 defined in the match-set-options-leaf."; 1291 } 1292 } 1294 grouping tag-set-condition { 1295 description 1296 "This grouping provides tag-set conditions."; 1298 container match-tag-set { 1299 leaf tag-set { 1300 type leafref { 1301 path "../../../../../../../defined-sets/tag-sets" + 1302 "/tag-set/name"; 1303 require-instance true; 1304 } 1305 description 1306 "References a defined tag set."; 1307 } 1308 uses match-set-options-restricted-group; 1310 description 1311 "Match a referenced tag set according to the logic defined 1312 in the match-options-set leaf."; 1313 } 1314 } 1316 grouping apply-policy-import { 1317 description 1318 "Grouping for applying import policies."; 1320 leaf-list import-policy { 1321 type leafref { 1322 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1323 "rt-pol:policy-definition/rt-pol:name"; 1324 require-instance true; 1325 } 1326 ordered-by user; 1327 description 1328 "List of policy names in sequence to be applied on 1329 receiving a routing update in the current context, e.g., 1330 for the current peer group, neighbor, address family, 1331 etc."; 1332 } 1334 leaf default-import-policy { 1335 type default-policy-type; 1336 default reject-route; 1337 description 1338 "Explicitly set a default policy if no policy definition 1339 in the import policy chain is satisfied."; 1340 } 1342 } 1344 grouping apply-policy-export { 1345 description 1346 "Grouping for applying export policies."; 1348 leaf-list export-policy { 1349 type leafref { 1350 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1351 "rt-pol:policy-definition/rt-pol:name"; 1352 require-instance true; 1353 } 1354 ordered-by user; 1355 description 1356 "List of policy names in sequence to be applied on 1357 sending a routing update in the current context, e.g., 1358 for the current peer group, neighbor, address family, 1359 etc."; 1360 } 1362 leaf default-export-policy { 1363 type default-policy-type; 1364 default reject-route; 1365 description 1366 "Explicitly set a default policy if no policy definition 1367 in the export policy chain is satisfied."; 1368 } 1369 } 1371 grouping apply-policy-group { 1372 description 1373 "Top level container for routing policy applications. This 1374 grouping is intended to be used in routing models where 1375 needed."; 1377 container apply-policy { 1378 description 1379 "Anchor point for routing policies in the model. 1380 Import and export policies are with respect to the local 1381 routing table, i.e., export (send) and import (receive), 1382 depending on the context."; 1384 uses apply-policy-import; 1385 uses apply-policy-export; 1387 } 1388 } 1390 container routing-policy { 1391 description 1392 "Top-level container for all routing policy."; 1394 container defined-sets { 1395 description 1396 "Predefined sets of attributes used in policy match 1397 statements."; 1399 container prefix-sets { 1400 description 1401 "Data definitions for a list of IPv4 or IPv6 1402 prefixes which are matched as part of a policy."; 1403 list prefix-set { 1404 key "name"; 1405 description 1406 "List of the defined prefix sets"; 1408 leaf name { 1409 type string; 1410 description 1411 "Name of the prefix set -- this is used as a label to 1412 reference the set in match conditions."; 1414 } 1416 leaf mode { 1417 type enumeration { 1418 enum ipv4 { 1419 description 1420 "Prefix set contains IPv4 prefixes only."; 1421 } 1422 enum ipv6 { 1423 description 1424 "Prefix set contains IPv6 prefixes only."; 1425 } 1426 enum mixed { 1427 description 1428 "Prefix set contains mixed IPv4 and IPv6 1429 prefixes."; 1430 } 1431 } 1432 description 1433 "Indicates the mode of the prefix set, in terms of 1434 which address families (IPv4, IPv6, or both) are 1435 present. The mode provides a hint, but the device 1436 must validate that all prefixes are of the indicated 1437 type, and is expected to reject the configuration if 1438 there is a discrepancy. The MIXED mode may not be 1439 supported on devices that require prefix sets to be 1440 of only one address family."; 1441 } 1443 container prefixes { 1444 description 1445 "Container for the list of prefixes in a policy 1446 prefix list."; 1448 list prefix-list { 1449 key "ip-prefix mask-length-lower mask-length-upper"; 1450 description 1451 "List of prefixes in the prefix set."; 1453 uses prefix; 1454 } 1455 } 1456 } 1457 } 1459 container neighbor-sets { 1460 description 1461 "Data definition for a list of IPv4 or IPv6 1462 neighbors which can be matched in a routing policy."; 1464 list neighbor-set { 1465 key "name"; 1466 description 1467 "List of defined neighbor sets for use in policies."; 1469 leaf name { 1470 type string; 1471 description 1472 "Name of the neighbor set -- this is used as a label 1473 to reference the set in match conditions."; 1474 } 1476 leaf-list address { 1477 type inet:ip-address; 1478 description 1479 "List of IP addresses in the neighbor set."; 1480 } 1481 } 1482 } 1484 container tag-sets { 1485 description 1486 "Data definitions for a list of tags which can 1487 be matched in policies."; 1489 list tag-set { 1490 key "name"; 1491 description 1492 "List of tag set definitions."; 1494 leaf name { 1495 type string; 1496 description 1497 "Name of the tag set -- this is used as a label to 1498 reference the set in match conditions."; 1499 } 1501 leaf-list tag-value { 1502 type tag-type; 1503 description 1504 "Value of the tag set member."; 1505 } 1506 } 1507 } 1508 } 1509 container policy-definitions { 1510 description 1511 "Enclosing container for the list of top-level policy 1512 definitions."; 1514 list policy-definition { 1515 key "name"; 1516 description 1517 "List of top-level policy definitions, keyed by unique 1518 name. These policy definitions are expected to be 1519 referenced (by name) in policy chains specified in 1520 import or export configuration statements."; 1522 leaf name { 1523 type string; 1524 description 1525 "Name of the top-level policy definition -- this name 1526 is used in references to the current policy."; 1527 } 1529 container statements { 1530 description 1531 "Enclosing container for policy statements."; 1533 list statement { 1534 key "name"; 1535 ordered-by user; 1536 description 1537 "Policy statements group conditions and actions 1538 within a policy definition. They are evaluated in 1539 the order specified (see the description of policy 1540 evaluation at the top of this module."; 1542 leaf name { 1543 type string; 1544 description 1545 "Name of the policy statement."; 1546 } 1548 container conditions { 1549 description 1550 "Condition statements for the current policy 1551 statement."; 1553 leaf call-policy { 1554 type leafref { 1555 path "../../../../../../" + 1556 "rt-pol:policy-definitions/" + 1557 "rt-pol:policy-definition/rt-pol:name"; 1558 require-instance true; 1559 } 1560 description 1561 "Applies the statements from the specified policy 1562 definition and then returns control the current 1563 policy statement. Note that the called policy 1564 may itself call other policies (subject to 1565 implementation limitations). This is intended to 1566 provide a policy 'subroutine' capability. The 1567 called policy should contain an explicit or a 1568 default route disposition that returns an 1569 effective true (accept-route) or false 1570 (reject-route), otherwise the behavior may be 1571 ambiguous and implementation dependent."; 1572 } 1574 leaf source-protocol { 1575 type identityref { 1576 base rt:control-plane-protocol; 1577 } 1578 description 1579 "Condition to check the protocol / method used to 1580 install the route into the local routing table."; 1581 } 1583 uses match-interface-condition; 1584 uses prefix-set-condition; 1585 uses neighbor-set-condition; 1586 uses tag-set-condition; 1587 uses match-route-type-condition; 1588 } 1590 container actions { 1591 description 1592 "Top-level container for policy action 1593 statements."; 1594 leaf policy-result { 1595 type policy-result-type; 1596 description 1597 "Select the final disposition for the route, 1598 either accept or reject."; 1599 } 1600 container set-metric { 1601 leaf metric-modification { 1602 type metric-modification-type; 1603 description 1604 "Indicates how to modify the metric."; 1606 } 1607 leaf metric { 1608 type uint32; 1609 description 1610 "Metric value to set, add, or subtract."; 1611 } 1612 description 1613 "Set the metric for the route."; 1614 } 1615 container set-metric-type { 1616 leaf metric-type { 1617 type identityref { 1618 base metric-type; 1619 } 1620 description 1621 "Route metric type."; 1622 } 1623 description 1624 "Set the metric type for the route."; 1625 } 1626 container set-import-level { 1627 leaf import-level { 1628 type identityref { 1629 base import-level; 1630 } 1631 description 1632 "Route importation level."; 1633 } 1634 description 1635 "Set the import level for importation of 1636 routes."; 1637 } 1638 leaf set-preference { 1639 type uint16; 1640 description 1641 "Set the preference for the route."; 1642 } 1643 leaf set-tag { 1644 type tag-type; 1645 description 1646 "Set the tag for the route."; 1647 } 1648 leaf set-application-tag { 1649 type tag-type; 1650 description 1651 "Set the application tag for the route."; 1652 } 1653 } 1655 } 1656 } 1657 } 1658 } 1659 } 1660 } 1661 1663 11. Policy examples 1665 Below we show an example of XML-encoded configuration data using the 1666 routing policy and BGP models to illustrate both how policies are 1667 defined, and also how they can be applied. Note that the XML has 1668 been simplified for readability. 1670 1671 1674 1675 1676 1677 prefix-set-A 1678 1679 1680 192.0.2.0/24 1681 24 1682 32 1683 1684 1685 10.0.0.0/16 1686 16 1687 32 1688 1689 1690 1691 1692 1693 1694 cust-tag1 1695 10 1696 1697 1698 1700 1701 1702 export-tagged-BGP 1703 1704 1705 term-0 1706 1707 1708 cust-tag1 1709 1710 1711 1712 accept-route 1713 1714 1715 1716 1717 1719 1720 1722 12. References 1724 12.1. Normative references 1726 [INTF-EXT-YANG] 1727 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1728 Sivaraj,, "Common Interface Extension YANG Data Models", 1729 2019, . 1732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1733 Requirement Levels", BCP 14, RFC 2119, 1734 DOI 10.17487/RFC2119, March 1997, 1735 . 1737 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1738 DOI 10.17487/RFC2328, April 1998, 1739 . 1741 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1742 RFC 3101, DOI 10.17487/RFC3101, January 2003, 1743 . 1745 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1746 DOI 10.17487/RFC3688, January 2004, 1747 . 1749 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1750 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1751 DOI 10.17487/RFC4271, January 2006, 1752 . 1754 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 1755 Control Mechanism in IS-IS Using Administrative Tags", 1756 RFC 5130, DOI 10.17487/RFC5130, February 2008, 1757 . 1759 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 1760 Distribution with Two-Level IS-IS", RFC 5302, 1761 DOI 10.17487/RFC5302, October 2008, 1762 . 1764 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1765 the Network Configuration Protocol (NETCONF)", RFC 6020, 1766 DOI 10.17487/RFC6020, October 2010, 1767 . 1769 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1770 and A. Bierman, Ed., "Network Configuration Protocol 1771 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1772 . 1774 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1775 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1776 . 1778 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1779 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1780 . 1782 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1783 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1784 . 1786 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1787 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1788 . 1790 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1791 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1792 May 2017, . 1794 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1795 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1796 . 1798 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1799 Access Control Model", STD 91, RFC 8341, 1800 DOI 10.17487/RFC8341, March 2018, 1801 . 1803 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1804 and R. Wilton, "Network Management Datastore Architecture 1805 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1806 . 1808 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1809 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1810 . 1812 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1813 Routing Management (NMDA Version)", RFC 8349, 1814 DOI 10.17487/RFC8349, March 2018, 1815 . 1817 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1818 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1819 . 1821 [SUB-INTF-VLAN-YANG] 1822 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1823 Sivaraj, "Sub-interface VLAN YANG Data Model", 2019, 1824 . 1827 12.2. Informative references 1829 [I-D.ietf-idr-bgp-model] 1830 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1831 YANG Model for Service Provider Networks", draft-ietf-idr- 1832 bgp-model-08 (work in progress), February 2020. 1834 Appendix A. Acknowledgements 1836 The routing policy module defined in this draft is based on the 1837 OpenConfig route policy model. The authors would like to thank to 1838 OpenConfig for their contributions, especially Anees Shaikh, Rob 1839 Shakir, Kevin D'Souza, and Chris Chase. 1841 The authors are grateful for valuable contributions to this document 1842 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1843 George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, 1844 Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and 1845 John Heasley. 1847 Thanks to Mahesh Jethanandani and Tom Petch for their review and 1848 comments. 1850 Authors' Addresses 1852 Yingzhen Qu 1853 Futurewei 1854 2330 Central Expressway 1855 Santa Clara CA 95050 1856 USA 1858 Email: yingzhen.qu@futurewei.com 1860 Jeff Tantsura 1861 Apstra 1863 Email: jefftant.ietf@gmail.com 1865 Acee Lindem 1866 Cisco 1867 301 Midenhall Way 1868 Cary, NC 27513 1869 US 1871 Email: acee@cisco.com 1873 Xufeng Liu 1874 Volta Networks 1876 Email: xufeng.liu.ietf@gmail.com