idnits 2.17.1 draft-ietf-rtgwg-policy-model-18.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 488 has weird spacing: '...h-lower uin...' == Line 489 has weird spacing: '...h-upper uin...' == Line 1102 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 (July 13, 2020) is 1382 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-09 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: January 14, 2021 Apstra 6 A. Lindem 7 Cisco 8 X. Liu 9 Volta Networks 10 July 13, 2020 12 A YANG Data Model for Routing Policy Management 13 draft-ietf-rtgwg-policy-model-18 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 January 14, 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 10.1. Routing policy model . . . . . . . . . . . . . . . . . . 15 74 11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 36 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 76 12.1. Normative references . . . . . . . . . . . . . . . . . . 38 77 12.2. Informative references . . . . . . . . . . . . . . . . . 40 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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 protocol instances 132 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 provide 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 network operators to change the behavior 301 of a 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-route-level 372 | +--rw route-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) are 410 discouraged. Also, implementations should have validation to ensure 411 that there is no recursion amongst nested routing policies. 413 5. Policy evaluation 415 Evaluation of each policy definition proceeds by evaluating its 416 corresponding individual policy statements in order. When all the 417 condition statements in a policy statement are satisfied, the 418 corresponding action statements are executed. If the actions include 419 either accept-route or reject-route actions, evaluation of the 420 current policy definition stops, and no further policy definitions in 421 the chain are evaluated. 423 If the conditions are not satisfied, then evaluation proceeds to the 424 next policy statement. If none of the policy statement conditions 425 are satisfied, then evaluation of the current policy definition 426 stops, and the next policy definition in the chain is evaluated. 427 When the end of the policy chain is reached, the default route 428 disposition action is performed (i.e., reject-route unless an 429 alternate default action is specified for the chain). 431 Note that the route's pre-policy attributes are always used for 432 testing policy statement conditions. In other words, if actions 433 modify the policy application specific attributes, those 434 modifications are not used for policy statement conditions. 436 6. Applying routing policy 438 Routing policy is applied by defining and attaching policy chains in 439 various routing contexts. Policy chains are sequences of policy 440 definitions (described in Section 4). They can be referenced from 441 different contexts. For example, a policy chain could be associated 442 with a routing protocol and used to control its interaction with its 443 protocol peers. Or, it could be used to control the interaction 444 between a routing protocol and the local routing information base. A 445 policy chain has an associated direction (import or export), with 446 respect to the context in which it is referenced. 448 The routing policy model defines an apply-policy grouping that can be 449 imported and used by other models. As shown below, it allows 450 definition of import and export policy chains, as well as specifying 451 the default route disposition to be used when no policy definition in 452 the chain results in a final decision. 454 +--rw apply-policy 455 | +--rw import-policy* 456 | +--rw default-import-policy? default-policy-type 457 | +--rw export-policy* 458 | +--rw default-export-policy? default-policy-type 460 The default policy defined by the model is to reject the route for 461 both import and export policies. 463 7. Routing protocol-specific policies 465 Routing models that require the ability to apply routing policy may 466 augment the routing policy model with protocol or other specific 467 policy configuration. The routing policy model assumes that 468 additional defined sets, conditions, and actions may all be added by 469 other models. 471 An example of this is shown below, in which the BGP configuration 472 model in [I-D.ietf-idr-bgp-model] adds new defined sets to match on 473 community values or AS paths. The model similarly augments BGP- 474 specific conditions and actions in the corresponding sections of the 475 routing policy model. 477 module: ietf-routing-policy 478 +--rw routing-policy 479 +--rw defined-sets 480 | +--rw prefix-sets 481 | | +--rw prefix-set* [name] 482 | | +--rw name string 483 | | +--rw mode? enumeration 484 | | +--rw prefixes 485 | | +--rw prefix-list* [ip-prefix mask-length-lower 486 | | mask-length-upper] 487 | | +--rw ip-prefix inet:ip-prefix 488 | | +--rw mask-length-lower uint8 489 | | +--rw mask-length-upper uint8 490 | +--rw neighbor-sets 491 | | +--rw neighbor-set* [name] 492 | | +--rw name string 493 | | +--rw address* inet:ip-address 494 | +--rw tag-sets 495 | | +--rw tag-set* [name] 496 | | +--rw name string 497 | | +--rw tag-value* tag-type 498 | +--rw bp:bgp-defined-sets 499 | +--rw bp:community-sets 500 | | +--rw bp:community-set* [name] 501 | | +--rw bp:name string 502 | | +--rw bp:member* union 503 | +--rw bp:ext-community-sets 504 | | +--rw bp:ext-community-set* [name] 505 | | +--rw bp:name string 506 | | +--rw bp:member* union 507 | +--rw bp:as-path-sets 508 | +--rw bp:as-path-set* [name] 509 | +--rw bp:name string 510 | +--rw bp:member* string 511 +--rw policy-definitions 512 +--rw policy-definition* [name] 513 +--rw name string 514 +--rw statements 515 +--rw statement* [name] 516 +--rw name string 517 +--rw conditions 518 | +--rw call-policy? 519 | +--rw source-protocol? identityref 520 | +--rw match-interface 521 | | +--rw interface? 522 | | +--rw subinterface? 523 | +--rw match-prefix-set 524 | | +--rw prefix-set? prefix-set/name 525 | | +--rw match-set-options? match-set-options-type 526 | +--rw match-neighbor-set 527 | | +--rw neighbor-set? 528 | +--rw match-tag-set 529 | | +--rw tag-set? 530 | | +--rw match-set-options? match-set-options-type 531 | +--rw match-route-type* identityref 532 | +--rw bp:bgp-conditions 533 | +--rw bp:med-eq? uint32 534 | +--rw bp:origin-eq? bt:bgp-origin-attr-type 535 | +--rw bp:next-hop-in* inet:ip-address-no-zone 536 | +--rw bp:afi-safi-in* identityref 537 | +--rw bp:local-pref-eq? uint32 538 | +--rw bp:route-type? enumeration 539 | +--rw bp:community-count 540 | +--rw bp:as-path-length 541 | +--rw bp:match-community-set 542 | | +--rw bp:community-set? 543 | | +--rw bp:match-set-options? 544 | +--rw bp:match-ext-community-set 545 | | +--rw bp:ext-community-set? 546 | | +--rw bp:match-set-options? 547 | +--rw bp:match-as-path-set 548 | +--rw bp:as-path-set? 549 | +--rw bp:match-set-options? 550 +--rw actions 551 +--rw policy-result? policy-result-type 552 +--rw set-metric 553 | +--rw metric-modification? 554 | +--rw metric? uint32 555 +--rw set-metric-type 556 | +--rw metric-type? identityref 557 +--rw set-route-level 558 | +--rw route-level? identityref 559 +--rw set-preference? uint16 560 +--rw set-tag? tag-type 561 +--rw set-application-tag? tag-type 562 +--rw bp:bgp-actions 563 +--rw bp:set-route-origin?bt:bgp-origin-attr-type 564 +--rw bp:set-local-pref? uint32 565 +--rw bp:set-next-hop? bgp-next-hop-type 566 +--rw bp:set-med? bgp-set-med-type 567 +--rw bp:set-as-path-prepend 568 | +--rw bp:repeat-n? uint8 569 +--rw bp:set-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:community-set-ref? 576 +--rw bp:set-ext-community 577 +--rw bp:method? enumeration 578 +--rw bp:options? 579 +--rw bp:inline 580 | +--rw bp:communities* union 581 +--rw bp:reference 582 +--rw bp:ext-community-set-ref? 584 8. Security Considerations 586 The YANG modules specified in this document define a schema for data 587 that is designed to be accessed via network management protocols such 588 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 589 is the secure transport layer, and the mandatory-to-implement secure 590 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 591 is HTTPS, and the mandatory-to-implement secure transport is TLS 592 [RFC8446]. 594 The NETCONF Access Control Model (NACM) [RFC8341] provides the means 595 to restrict access for particular NETCONF or RESTCONF users to a pre- 596 configured subset of all available NETCONF or RESTCONF protocol 597 operations and content. 599 There are a number of data nodes defined in this YANG module that are 600 writable/creatable/deletable (i.e., config true, which is the 601 default). These data nodes may be considered sensitive or vulnerable 602 in some network environments. Write operations (e.g., edit-config) 603 to these data nodes without proper protection can have a negative 604 effect on network operations. These are the subtrees and data nodes 605 and their sensitivity/vulnerability: 607 /routing-policy 609 /routing-policy/defined-sets/prefix-sets 611 /routing-policy/defined-sets/neighbor-sets 613 /routing-policy/defined-sets/tag-sets 615 /routing-policy/policy-definitions 617 Unauthorized access to any data node of these subtrees can disclose 618 the operational state information of routing policies on this device. 620 Routing policy configuration has a significant impact on network 621 operations, and, as such, any related model carries potential 622 security risks. Unauthorized access or invalid data could cause 623 major disruption. 625 9. IANA Considerations 627 This document registers a URI in the IETF XML registry [RFC3688]. 628 Following the format in [RFC3688], the following registration is 629 requested to be made: 631 URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy 632 Registrant Contact: The IESG. 633 XML: N/A, the requested URI is an XML namespace. 635 This document registers a YANG module in the YANG Module Names 636 registry [RFC6020]. 638 name: ietf-routing-policy 639 namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy 640 prefix: rt-pol 641 reference: RFC XXXX 643 10. YANG module 645 The routing policy model is described by the YANG modules in the 646 sections below. [RFC2328], [RFC3101], [RFC5130], and [RFC5302] are 647 referenced here since they are referenced in the YANG model but not 648 elsewhere in this document. 650 10.1. Routing policy model 652 file "ietf-routing-policy@2020-07-13.yang" 653 module ietf-routing-policy { 655 yang-version "1.1"; 657 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; 658 prefix rt-pol; 660 import ietf-inet-types { 661 prefix "inet"; 662 reference "RFC 6991: Common YANG Data Types"; 663 } 665 import ietf-yang-types { 666 prefix "yang"; 667 reference "RFC 6991: Common YANG Data Types"; 668 } 670 import ietf-interfaces { 671 prefix "if"; 672 reference "RFC 8343: A YANG Data Model for Interface 673 Management (NMDA Version)"; 674 } 676 import ietf-routing { 677 prefix "rt"; 678 reference "RFC 8349: A YANG Data Model for Routing 679 Management (NMDA Version)"; 680 } 682 import ietf-if-extensions { 683 prefix "if-ext"; 684 reference "RFC YYYY: Common Interface Extension YANG 685 Data Models. Please replace YYYY with 686 published RFC number for 687 draft-ietf-netmod-intf-ext-yang."; 688 } 690 import ietf-if-l3-vlan { 691 prefix "if-l3-vlan"; 692 reference "RFC ZZZZ: Sub-interface VLAN YANG Data Models. 693 Please replace ZZZZ with published RFC number 694 for draft-ietf-netmod-sub-intf-vlan-model."; 695 } 697 organization 698 "IETF RTGWG - Routing Area Working Group"; 699 contact 700 "WG Web: 701 WG List: 703 Editor: Yingzhen Qu 704 705 Jeff Tantsura 706 707 Acee Lindem 708 709 Xufeng Liu 710 "; 712 description 713 "This module describes a YANG model for routing policy 714 configuration. It is a limited subset of all of the policy 715 configuration parameters available in the variety of vendor 716 implementations, but supports widely used constructs for 717 managing how routes are imported, exported, modified and 718 advertised across different routing protocol instances or 719 within a single routing protocol instance. This module is 720 intended to be used in conjunction with routing protocol 721 configuration modules (e.g., BGP) defined in other models. 723 Route policy expression: 725 Policies are expressed as a set of top-level policy 726 definitions, each of which consists of a sequence of policy 727 statements. Policy statements consist of simple 728 condition-action tuples. Conditions may include multiple match 729 or comparison operations, and similarly actions may be a 730 multitude of changes to route attributes or a final 731 disposition of accepting or rejecting the route. 733 Route policy evaluation: 735 Policy definitions are referenced in routing protocol 736 configurations using import and export configuration 737 statements. The arguments are members of an ordered list of 738 named policy definitions which comprise a policy chain, and 739 optionally, an explicit default policy action (i.e., reject 740 or accept). 742 Evaluation of each policy definition proceeds by evaluating 743 its corresponding individual policy statements in order. When 744 a condition statement in a policy statement is satisfied, the 745 corresponding action statement is executed. If the action 746 statement has either accept-route or reject-route actions, 747 policy evaluation of the current policy definition stops, and 748 no further policy definitions in the chain are evaluated. 750 If the condition is not satisfied, then evaluation proceeds to 751 the next policy statement. If none of the policy statement 752 conditions are satisfied, then evaluation of the current 753 policy definition stops, and the next policy definition in the 754 chain is evaluated. When the end of the policy chain is 755 reached, the default route disposition action is performed 756 (i.e., reject-route unless an alternate default action is 757 specified for the chain). 759 Policy 'subroutines' (or nested policies) are supported by 760 allowing policy statement conditions to reference another 761 policy definition which applies conditions and actions from 762 the referenced policy before returning to the calling policy 763 statement and resuming evaluation. If the called policy 764 results in an accept-route (either explicit or by default), 765 then the subroutine returns an effective true value to the 766 calling policy. Similarly, a reject-route action returns 767 false. If the subroutine returns true, the calling policy 768 continues to evaluate the remaining conditions with the initial 769 data if route attribute values are modified. 771 Copyright (c) 2020 IETF Trust and the persons identified as 772 authors of the code. All rights reserved. 774 Redistribution and use in source and binary forms, with or 775 without modification, is permitted pursuant to, and subject to 776 the license terms contained in, the Simplified BSD License set 777 forth in Section 4.c of the IETF Trust's Legal Provisions 778 Relating to IETF Documents 779 (https://trustee.ietf.org/license-info). 781 This version of this YANG module is part of RFC XXXX 782 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 783 for full legal notices. 785 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 786 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT 787 RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 788 interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, 789 and only when, they appear in all capitals, as shown here. 791 This version of this YANG module is part of RFC XXXX; 792 see the RFC itself for full legal notices."; 794 revision "2020-07-13" { 795 description 796 "Initial revision."; 797 reference 798 "RFC XXXX: Routing Policy Configuration Model for Service 799 Provider Networks"; 800 } 802 /* Identities */ 804 identity metric-type { 805 description 806 "Base identity for route metric types."; 807 } 809 identity ospf-type-1-metric { 810 base metric-type; 811 description 812 "Identity for the OSPF type 1 external metric types. It 813 is only applicable to OSPF routes."; 814 reference 815 "RFC 2328 - OSPF Version 2"; 816 } 818 identity ospf-type-2-metric { 819 base metric-type; 820 description 821 "Identity for the OSPF type 2 external metric types. It 822 is only applicable to OSPF routes."; 823 reference 824 "RFC 2328 - OSPF Version 2"; 825 } 827 identity isis-internal-metric { 828 base metric-type; 829 description 830 "Identity for the IS-IS internal metric types. It is only 831 applicable to IS-IS routes."; 832 reference 833 "RFC 5302 - Domain-Wide Prefix Distribution with 834 Two-Level IS-IS"; 835 } 837 identity isis-external-metric { 838 base metric-type; 839 description 840 "Identity for the IS-IS external metric types. It is only 841 applicable to IS-IS routes."; 842 reference 843 "RFC 5302 - Domain-Wide Prefix Distribution with 844 Two-Level IS-IS"; 845 } 847 identity route-level { 848 description 849 "Base identity for route import or export level."; 850 } 852 identity ospf-normal { 853 base route-level; 854 description 855 "Identity for OSPF importation into normal areas 856 It is only applicable to routes imported 857 into the OSPF protocol."; 858 reference 859 "RFC 2328 - OSPF Version 2"; 860 } 862 identity ospf-nssa-only { 863 base route-level; 864 description 865 "Identity for the OSPF Not-So-Stubby Area (NSSA) area 866 importation. It is only applicable to routes imported 867 into the OSPF protocol."; 868 reference 869 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 870 } 872 identity ospf-normal-nssa { 873 base route-level; 874 description 875 "Identity for OSPF importation into both normal and NSSA 876 areas, it is only applicable to routes imported into 877 the OSPF protocol."; 878 reference 879 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 880 } 881 identity isis-level-1 { 882 base route-level; 883 description 884 "Identity for IS-IS Level 1 area importation. It is only 885 applicable to routes imported into the IS-IS protocol."; 886 reference 887 "RFC 5302 - Domain-Wide Prefix Distribution with 888 Two-Level IS-IS"; 889 } 891 identity isis-level-2 { 892 base route-level; 893 description 894 "Identity for IS-IS Level 2 area importation. It is only 895 applicable to routes imported into the IS-IS protocol."; 896 reference 897 "RFC 5302 - Domain-Wide Prefix Distribution with 898 Two-Level IS-IS"; 899 } 901 identity isis-level-1-2 { 902 base route-level; 903 description 904 "Identity for IS-IS Level 1 and Level 2 area importation. It 905 is only applicable to routes imported into the IS-IS 906 protocol."; 907 reference 908 "RFC 5302 - Domain-Wide Prefix Distribution with 909 Two-Level IS-IS"; 910 } 912 identity proto-route-type { 913 description 914 "Base identity for route type within a protocol."; 915 } 917 identity isis-level-1-type { 918 base proto-route-type; 919 description 920 "Identity for IS-IS Level 1 route type. It is only 921 applicable to IS-IS routes."; 922 reference 923 "RFC 5302 - Domain-Wide Prefix Distribution with 924 Two-Level IS-IS"; 925 } 927 identity isis-level-2-type { 928 base proto-route-type; 929 description 930 "Identity for IS-IS Level 2 route type. It is only 931 applicable to IS-IS routes."; 932 reference 933 "RFC 5302 - Domain-Wide Prefix Distribution with 934 Two-Level IS-IS"; 935 } 937 identity ospf-internal-type { 938 base proto-route-type; 939 description 940 "Identity for OSPF intra-area or inter-area route type. 941 It is only applicable to OSPF routes."; 942 reference 943 "RFC 2328 - OSPF Version 2"; 944 } 946 identity ospf-external-type { 947 base proto-route-type; 948 description 949 "Identity for OSPF external type 1/2 route type. 950 It is only applicable to OSPF routes."; 951 reference 952 "RFC 2328 - OSPF Version 2"; 953 } 955 identity ospf-external-t1-type { 956 base ospf-external-type; 957 description 958 "Identity for OSPF external type 1 route type. 959 It is only applicable to OSPF routes."; 960 reference 961 "RFC 2328 - OSPF Version 2"; 962 } 964 identity ospf-external-t2-type { 965 base ospf-external-type; 966 description 967 "Identity for OSPF external type 2 route type. 968 It is only applicable to OSPF routes."; 969 reference 970 "RFC 2328 - OSPF Version 2"; 971 } 973 identity ospf-nssa-type { 974 base proto-route-type; 975 description 976 "Identity for OSPF NSSA type 1/2 route type. 978 It is only applicable to OSPF routes."; 979 reference 980 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 981 } 983 identity ospf-nssa-t1-type { 984 base ospf-nssa-type; 985 description 986 "Identity for OSPF NSSA type 1 route type. 987 It is only applicable to OSPF routes."; 988 reference 989 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 990 } 992 identity ospf-nssa-t2-type { 993 base ospf-nssa-type; 994 description 995 "Identity for OSPF NSSA type 2 route type. 996 It is only applicable to OSPF routes."; 997 reference 998 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 999 } 1001 identity bgp-internal { 1002 base proto-route-type; 1003 description 1004 "Identity for routes learned from internal BGP (iBGP). 1005 It is only applicable to BGP routes."; 1006 reference 1007 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 1008 } 1010 identity bgp-external { 1011 base proto-route-type; 1012 description 1013 "Identity for routes learned from external BGP (eBGP). 1014 It is only applicable to BGP routes."; 1015 reference 1016 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 1017 } 1019 /* Type Definitions */ 1021 typedef default-policy-type { 1022 type enumeration { 1023 enum accept-route { 1024 description 1025 "Default policy to accept the route."; 1027 } 1028 enum reject-route { 1029 description 1030 "Default policy to reject the route."; 1031 } 1032 } 1033 description 1034 "Type used to specify route disposition in 1035 a policy chain. This typedef retained for 1036 name compatibility with default import and 1037 export policy."; 1038 } 1040 typedef policy-result-type { 1041 type enumeration { 1042 enum accept-route { 1043 description 1044 "Policy accepts the route."; 1045 } 1046 enum reject-route { 1047 description 1048 "Policy rejects the route."; 1049 } 1050 } 1051 description 1052 "Type used to specify route disposition in 1053 a policy chain."; 1054 } 1056 typedef tag-type { 1057 type union { 1058 type uint32; 1059 type yang:hex-string; 1060 } 1061 description 1062 "Type for expressing route tags on a local system, 1063 including IS-IS and OSPF; may be expressed as either decimal 1064 or hexadecimal integer."; 1065 reference 1066 "RFC 2328 - OSPF Version 2 1067 RFC 5130 - A Policy Control Mechanism in IS-IS Using 1068 Administrative Tags"; 1069 } 1071 typedef match-set-options-type { 1072 type enumeration { 1073 enum any { 1074 description 1075 "Match is true if given value matches any member 1076 of the defined set."; 1077 } 1078 enum all { 1079 description 1080 "Match is true if given value matches all 1081 members of the defined set."; 1082 } 1083 enum invert { 1084 description 1085 "Match is true if given value does not match any 1086 member of the defined set."; 1087 } 1088 } 1089 default any; 1090 description 1091 "Options that govern the behavior of a match statement. The 1092 default behavior is any, i.e., the given value matches any 1093 of the members of the defined set."; 1094 } 1096 typedef metric-modification-type { 1097 type enumeration { 1098 enum set-metric { 1099 description 1100 "Set the metric to the specified value."; 1101 } 1102 enum add-metric { 1103 description 1104 "Add the specified value to the existing metric. 1105 If the result would overflow the maximum metric 1106 (0xffffffff), set the metric to the maximum."; 1107 } 1108 enum subtract-metric { 1109 description 1110 "Subtract the specified value to the existing metric. If 1111 the result would be less than 0, set the metric to 0."; 1112 } 1113 } 1114 description 1115 "Type used to specify how to set the metric given the 1116 specified value."; 1117 } 1119 /* Groupings */ 1121 grouping prefix { 1122 description 1123 "Configuration data for a prefix definition."; 1125 leaf ip-prefix { 1126 type inet:ip-prefix; 1127 mandatory true; 1128 description 1129 "The IP prefix represented as an IPv6 or IPv4 network 1130 number followed by a prefix length with an intervening 1131 slash character as a delimiter. All members of the prefix 1132 set should be of the same address family as the prefix-set 1133 mode."; 1134 } 1136 leaf mask-length-lower { 1137 type uint8; 1138 description 1139 "Mask length range lower bound. It should not be less than 1140 the prefix length defined in ip-prefix."; 1141 } 1142 leaf mask-length-upper { 1143 type uint8 { 1144 range "1..128"; 1145 } 1146 must "../mask-length-upper >= ../mask-length-lower" { 1147 error-message "The upper bound should not be less" 1148 + "than lower bound."; 1149 } 1150 description 1151 "Mask length range upper bound. 1153 The combination of mask-length-lower and mask-length-upper 1154 define a range for the mask length, or single 'exact' 1155 length if mask-length-lower and mask-length-upper are 1156 equal. 1158 Example: 192.0.2.0/24 through 192.0.2.0/26 would be 1159 expressed as prefix: 192.0.2.0/24, 1160 mask-length-lower=24, 1161 mask-length-upper=26 1163 Example: 192.0.2.0/24 (an exact match) would be 1164 expressed as prefix: 192.0.2.0/24, 1165 mask-length-lower=24, 1166 mask-length-upper=24"; 1167 } 1168 } 1170 grouping match-set-options-group { 1171 description 1172 "Grouping containing options relating to how a particular set 1173 should be matched."; 1175 leaf match-set-options { 1176 type match-set-options-type; 1177 description 1178 "Optional parameter that governs the behavior of the 1179 match operation."; 1180 } 1181 } 1183 grouping match-set-options-restricted-group { 1184 description 1185 "Grouping for a restricted set of match operation 1186 modifiers."; 1188 leaf match-set-options { 1189 type match-set-options-type { 1190 enum any { 1191 description 1192 "Match is true if given value matches any 1193 member of the defined set."; 1194 } 1195 enum invert { 1196 description 1197 "Match is true if given value does not match 1198 any member of the defined set."; 1199 } 1200 } 1201 description 1202 "Optional parameter that governs the behavior of the 1203 match operation. This leaf only supports matching on 1204 'any' member of the set or 'invert' the match. 1205 Matching on 'all' is not supported."; 1206 } 1207 } 1209 grouping match-interface-condition { 1210 description 1211 "This grouping provides interface match condition."; 1213 container match-interface { 1214 leaf interface { 1215 type leafref { 1216 path "/if:interfaces/if:interface/if:name"; 1217 } 1218 description 1219 "Reference to a base interface. If a reference to a 1220 subinterface is required, this leaf must be specified 1221 to indicate the base interface."; 1222 } 1223 leaf subinterface { 1224 type leafref { 1225 path "/if:interfaces/if:interface/if-ext:encapsulation" 1226 + "/if-l3-vlan:dot1q-vlan" 1227 + "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id"; 1228 } 1229 description 1230 "Reference to a subinterface -- this requires the base 1231 interface to be specified using the interface leaf in 1232 this container. If only a reference to a base interface 1233 is required, this leaf should not be set."; 1234 } 1236 description 1237 "Container for interface match conditions"; 1238 } 1239 } 1241 grouping match-route-type-condition { 1242 description 1243 "This grouping provides route-type match condition"; 1245 leaf-list match-route-type { 1246 type identityref { 1247 base proto-route-type; 1248 } 1249 description 1250 "Condition to check the protocol-specific type 1251 of route. This is normally used during route 1252 importation to select routes or to set protocol 1253 specific attributes based on the route type."; 1254 } 1255 } 1257 grouping prefix-set-condition { 1258 description 1259 "This grouping provides prefix-set conditions."; 1261 container match-prefix-set { 1262 leaf prefix-set { 1263 type leafref { 1264 path "../../../../../../../defined-sets/" + 1265 "prefix-sets/prefix-set/name"; 1266 } 1267 description 1268 "References a defined prefix set."; 1269 } 1270 uses match-set-options-restricted-group; 1272 description 1273 "Match a referenced prefix-set according to the logic 1274 defined in the match-set-options leaf."; 1275 } 1276 } 1278 grouping neighbor-set-condition { 1279 description 1280 "This grouping provides neighbor-set conditions."; 1282 container match-neighbor-set { 1283 leaf neighbor-set { 1284 type leafref { 1285 path "../../../../../../../defined-sets/neighbor-sets/" + 1286 "neighbor-set/name"; 1287 require-instance true; 1288 } 1289 description 1290 "References a defined neighbor set."; 1291 } 1293 description 1294 "Match a referenced neighbor set according to the logic 1295 defined in the match-set-options-leaf."; 1296 } 1297 } 1299 grouping tag-set-condition { 1300 description 1301 "This grouping provides tag-set conditions."; 1303 container match-tag-set { 1304 leaf tag-set { 1305 type leafref { 1306 path "../../../../../../../defined-sets/tag-sets" + 1307 "/tag-set/name"; 1308 require-instance true; 1309 } 1310 description 1311 "References a defined tag set."; 1312 } 1313 uses match-set-options-restricted-group; 1314 description 1315 "Match a referenced tag set according to the logic defined 1316 in the match-options-set leaf."; 1317 } 1318 } 1320 grouping apply-policy-import { 1321 description 1322 "Grouping for applying import policies."; 1324 leaf-list import-policy { 1325 type leafref { 1326 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1327 "rt-pol:policy-definition/rt-pol:name"; 1328 require-instance true; 1329 } 1330 ordered-by user; 1331 description 1332 "List of policy names in sequence to be applied on 1333 receiving redistributed routes from another routing protocol 1334 or receiving a routing update in the current context, e.g., 1335 for the current peer group, neighbor, address family, 1336 etc."; 1337 } 1339 leaf default-import-policy { 1340 type default-policy-type; 1341 default reject-route; 1342 description 1343 "Explicitly set a default policy if no policy definition 1344 in the import policy chain is satisfied."; 1345 } 1347 } 1349 grouping apply-policy-export { 1350 description 1351 "Grouping for applying export policies."; 1353 leaf-list export-policy { 1354 type leafref { 1355 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1356 "rt-pol:policy-definition/rt-pol:name"; 1357 require-instance true; 1358 } 1359 ordered-by user; 1360 description 1361 "List of policy names in sequence to be applied on 1362 redistributing routes from one routing protocol to another 1363 or sending a routing update in the current context, e.g., 1364 for the current peer group, neighbor, address family, 1365 etc."; 1366 } 1368 leaf default-export-policy { 1369 type default-policy-type; 1370 default reject-route; 1371 description 1372 "Explicitly set a default policy if no policy definition 1373 in the export policy chain is satisfied."; 1374 } 1375 } 1377 grouping apply-policy-group { 1378 description 1379 "Top level container for routing policy applications. This 1380 grouping is intended to be used in routing models where 1381 needed."; 1383 container apply-policy { 1384 description 1385 "Anchor point for routing policies in the model. 1386 Import and export policies are with respect to the local 1387 routing table, i.e., export (send) and import (receive), 1388 depending on the context."; 1390 uses apply-policy-import; 1391 uses apply-policy-export; 1393 } 1394 } 1396 container routing-policy { 1397 description 1398 "Top-level container for all routing policy."; 1400 container defined-sets { 1401 description 1402 "Predefined sets of attributes used in policy match 1403 statements."; 1405 container prefix-sets { 1406 description 1407 "Data definitions for a list of IPv4 or IPv6 1408 prefixes which are matched as part of a policy."; 1409 list prefix-set { 1410 key "name mode"; 1411 description 1412 "List of the defined prefix sets"; 1414 leaf name { 1415 type string; 1416 description 1417 "Name of the prefix set -- this is used as a label to 1418 reference the set in match conditions."; 1419 } 1421 leaf mode { 1422 type enumeration { 1423 enum ipv4 { 1424 description 1425 "Prefix set contains IPv4 prefixes only."; 1426 } 1427 enum ipv6 { 1428 description 1429 "Prefix set contains IPv6 prefixes only."; 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."; 1439 } 1441 container prefixes { 1442 description 1443 "Container for the list of prefixes in a policy 1444 prefix list. Since individual prefixes do not have 1445 unique actions, the order in which the prefix in 1446 prefix-list are matched has no impact on the outcome 1447 outcome and is is left to the implementation. A 1448 given prefix-set condition is statisfied if the 1449 input prefix matches any of the prefixes in the 1450 prefix-set."; 1452 list prefix-list { 1453 key "ip-prefix mask-length-lower mask-length-upper"; 1454 description 1455 "List of prefixes in the prefix set."; 1457 uses prefix; 1459 } 1460 } 1461 } 1462 } 1464 container neighbor-sets { 1465 description 1466 "Data definition for a list of IPv4 or IPv6 1467 neighbors which can be matched in a routing policy."; 1469 list neighbor-set { 1470 key "name"; 1471 description 1472 "List of defined neighbor sets for use in policies."; 1474 leaf name { 1475 type string; 1476 description 1477 "Name of the neighbor set -- this is used as a label 1478 to reference the set in match conditions."; 1479 } 1481 leaf-list address { 1482 type inet:ip-address; 1483 description 1484 "List of IP addresses in the neighbor set."; 1485 } 1486 } 1487 } 1489 container tag-sets { 1490 description 1491 "Data definitions for a list of tags which can 1492 be matched in policies."; 1494 list tag-set { 1495 key "name"; 1496 description 1497 "List of tag set definitions."; 1499 leaf name { 1500 type string; 1501 description 1502 "Name of the tag set -- this is used as a label to 1503 reference the set in match conditions."; 1504 } 1506 leaf-list tag-value { 1507 type tag-type; 1508 description 1509 "Value of the tag set member."; 1510 } 1511 } 1512 } 1513 } 1515 container policy-definitions { 1516 description 1517 "Enclosing container for the list of top-level policy 1518 definitions."; 1520 list policy-definition { 1521 key "name"; 1522 description 1523 "List of top-level policy definitions, keyed by unique 1524 name. These policy definitions are expected to be 1525 referenced (by name) in policy chains specified in 1526 import or export configuration statements."; 1528 leaf name { 1529 type string; 1530 description 1531 "Name of the top-level policy definition -- this name 1532 is used in references to the current policy."; 1533 } 1535 container statements { 1536 description 1537 "Enclosing container for policy statements."; 1539 list statement { 1540 key "name"; 1541 ordered-by user; 1542 description 1543 "Policy statements group conditions and actions 1544 within a policy definition. They are evaluated in 1545 the order specified (see the description of policy 1546 evaluation at the top of this module."; 1548 leaf name { 1549 type string; 1550 description 1551 "Name of the policy statement."; 1552 } 1554 container conditions { 1555 description 1556 "Condition statements for the current policy 1557 statement."; 1559 leaf call-policy { 1560 type leafref { 1561 path "../../../../../../" + 1562 "rt-pol:policy-definitions/" + 1563 "rt-pol:policy-definition/rt-pol:name"; 1564 require-instance true; 1565 } 1566 description 1567 "Applies the statements from the specified policy 1568 definition and then returns control the current 1569 policy statement. Note that the called policy 1570 may itself call other policies (subject to 1571 implementation limitations). This is intended to 1572 provide a policy 'subroutine' capability. The 1573 called policy should contain an explicit or a 1574 default route disposition that returns an 1575 effective true (accept-route) or false 1576 (reject-route), otherwise the behavior may be 1577 ambiguous."; 1578 } 1580 leaf source-protocol { 1581 type identityref { 1582 base rt:control-plane-protocol; 1583 } 1584 description 1585 "Condition to check the protocol / method used to 1586 install the route into the local routing table."; 1587 } 1589 uses match-interface-condition; 1590 uses prefix-set-condition; 1591 uses neighbor-set-condition; 1592 uses tag-set-condition; 1593 uses match-route-type-condition; 1594 } 1596 container actions { 1597 description 1598 "Top-level container for policy action 1599 statements."; 1600 leaf policy-result { 1601 type policy-result-type; 1602 description 1603 "Select the final disposition for the route, 1604 either accept or reject."; 1605 } 1606 container set-metric { 1607 leaf metric-modification { 1608 type metric-modification-type; 1609 description 1610 "Indicates how to modify the metric."; 1611 } 1612 leaf metric { 1613 type uint32; 1614 description 1615 "Metric value to set, add, or subtract."; 1616 } 1617 description 1618 "Set the metric for the route."; 1619 } 1620 container set-metric-type { 1621 leaf metric-type { 1622 type identityref { 1623 base metric-type; 1624 } 1625 description 1626 "Route metric type."; 1627 } 1628 description 1629 "Set the metric type for the route."; 1630 } 1631 container set-route-level { 1632 leaf route-level { 1633 type identityref { 1634 base route-level; 1635 } 1636 description 1637 "Route import or export level."; 1638 } 1639 description 1640 "Set the level for importation or 1641 exportation of routes."; 1642 } 1643 leaf set-preference { 1644 type uint16; 1645 description 1646 "Set the preference for the route."; 1647 } 1648 leaf set-tag { 1649 type tag-type; 1650 description 1651 "Set the tag for the route."; 1652 } 1653 leaf set-application-tag { 1654 type tag-type; 1655 description 1656 "Set the application tag for the route."; 1657 } 1658 } 1659 } 1660 } 1661 } 1662 } 1663 } 1664 } 1666 CODE ENDS> 1668 11. Policy examples 1670 Below we show an example of XML-encoded configuration data using the 1671 routing policy and BGP models to illustrate both how policies are 1672 defined, and also how they can be applied. Note that the XML has 1673 been simplified for readability. 1675 1676 1679 1680 1681 1682 prefix-set-A 1683 ipv4 1684 1685 1686 192.0.2.0/24 1687 24 1688 32 1689 1690 1691 198.51.100.0/24 1692 24 1693 32 1694 1695 1696 1697 1698 1699 1700 cust-tag1 1701 10 1702 1703 1704 1706 1707 1708 export-tagged-BGP 1709 1710 1711 term-0 1712 1713 1714 cust-tag1 1715 1716 1717 1718 accept-route 1719 1720 1721 1722 1723 1725 1726 1728 In the following example, all routes in the RIB that have been 1729 learned from OSPF advertisements corresponding to OSPF intra-area and 1730 inter-area route types should get advertised into ISIS level-2 1731 advertisements. 1733 1734 1736 1737 1738 export-all-OSPF-prefixes-into-ISIS-level-2 1739 1740 1741 term-0 1742 1743 ospf-internal-type 1744 1745 1746 1747 isis-level-2 1748 1749 accept-route 1750 1751 1752 1753 1754 1755 1756 1758 12. References 1760 12.1. Normative references 1762 [INTF-EXT-YANG] 1763 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1764 Sivaraj,, "Common Interface Extension YANG Data Models", 1765 2019, . 1768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1769 Requirement Levels", BCP 14, RFC 2119, 1770 DOI 10.17487/RFC2119, March 1997, 1771 . 1773 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1774 DOI 10.17487/RFC2328, April 1998, 1775 . 1777 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1778 RFC 3101, DOI 10.17487/RFC3101, January 2003, 1779 . 1781 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1782 DOI 10.17487/RFC3688, January 2004, 1783 . 1785 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1786 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1787 DOI 10.17487/RFC4271, January 2006, 1788 . 1790 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 1791 Control Mechanism in IS-IS Using Administrative Tags", 1792 RFC 5130, DOI 10.17487/RFC5130, February 2008, 1793 . 1795 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 1796 Distribution with Two-Level IS-IS", RFC 5302, 1797 DOI 10.17487/RFC5302, October 2008, 1798 . 1800 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1801 the Network Configuration Protocol (NETCONF)", RFC 6020, 1802 DOI 10.17487/RFC6020, October 2010, 1803 . 1805 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1806 and A. Bierman, Ed., "Network Configuration Protocol 1807 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1808 . 1810 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1811 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1812 . 1814 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1815 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1816 . 1818 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1819 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1820 . 1822 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1823 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1824 . 1826 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1827 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1828 May 2017, . 1830 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1831 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1832 . 1834 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1835 Access Control Model", STD 91, RFC 8341, 1836 DOI 10.17487/RFC8341, March 2018, 1837 . 1839 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1840 and R. Wilton, "Network Management Datastore Architecture 1841 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1842 . 1844 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1845 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1846 . 1848 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1849 Routing Management (NMDA Version)", RFC 8349, 1850 DOI 10.17487/RFC8349, March 2018, 1851 . 1853 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1854 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1855 . 1857 [SUB-INTF-VLAN-YANG] 1858 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1859 Sivaraj, "Sub-interface VLAN YANG Data Model", 2019, 1860 . 1863 12.2. Informative references 1865 [I-D.ietf-idr-bgp-model] 1866 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1867 YANG Model for Service Provider Networks", draft-ietf-idr- 1868 bgp-model-09 (work in progress), June 2020. 1870 Appendix A. Acknowledgements 1872 The routing policy module defined in this document is based on the 1873 OpenConfig route policy model. The authors would like to thank to 1874 OpenConfig for their contributions, especially Anees Shaikh, Rob 1875 Shakir, Kevin D'Souza, and Chris Chase. 1877 The authors are grateful for valuable contributions to this document 1878 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1879 George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, 1880 Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and 1881 John Heasley. 1883 Thanks to Mahesh Jethanandani, John Scudder, Chris Bower and Tom 1884 Petch for their reviews and comments. 1886 Authors' Addresses 1888 Yingzhen Qu 1889 Futurewei 1890 2330 Central Expressway 1891 Santa Clara CA 95050 1892 USA 1894 Email: yingzhen.qu@futurewei.com 1896 Jeff Tantsura 1897 Apstra 1899 Email: jefftant.ietf@gmail.com 1901 Acee Lindem 1902 Cisco 1903 301 Midenhall Way 1904 Cary, NC 27513 1905 US 1907 Email: acee@cisco.com 1909 Xufeng Liu 1910 Volta Networks 1912 Email: xufeng.liu.ietf@gmail.com