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