idnits 2.17.1 draft-ietf-rtgwg-policy-model-25.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 284 has weird spacing: '...h-lower uin...' == Line 285 has weird spacing: '...h-upper uin...' == Line 985 has weird spacing: '... enum add-m...' == Line 991 has weird spacing: '... enum subtr...' == Line 1709 has weird spacing: '...h-lower uin...' == (1 more instance...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: leaf mask-length-lower { type uint8; description "Mask length range lower bound. It MUST not be less than the prefix length defined in ip-prefix."; } leaf mask-length-upper { type uint8 { range "1..128"; } must "../mask-length-upper >= ../mask-length-lower" { error-message "The upper bound MUST not be less" + "than lower bound."; == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: container match-interface { leaf interface { type leafref { path "/if:interfaces/if:interface/if:name"; } description "Reference to a base interface. If a reference to a subinterface is required, this leaf MUST be specified to indicate the base interface."; } leaf subinterface { type leafref { path "/if:interfaces/if:interface/if-ext:encapsulation" + "/if-flex:flexible/if-flex:match" + "/if-flex:dot1q-vlan-tagged" + "/if-flex:outer-tag/if-flex:vlan-id"; } description "Reference to a subinterface -- this requires the base interface to be specified using the interface leaf in this container. If only a reference to a base interface is required, this leaf SHOULD not be set."; } -- The document date (September 18, 2020) is 1306 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 (~~), 10 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: March 22, 2021 Apstra 6 A. Lindem 7 Cisco 8 X. Liu 9 Volta Networks 10 September 18, 2020 12 A YANG Data Model for Routing Policy Management 13 draft-ietf-rtgwg-policy-model-25 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 22, 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. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 9. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 9.1. Routing policy model . . . . . . . . . . . . . . . . . . 12 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 75 11.1. Normative references . . . . . . . . . . . . . . . . . . 34 76 11.2. Informative references . . . . . . . . . . . . . . . . . 36 77 Appendix A. Routing protocol-specific policies . . . . . . . . . 36 78 Appendix B. Policy examples . . . . . . . . . . . . . . . . . . 39 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. In this document, policy chains are 224 sequences of policy definitions that are applied in order 225 (described in Section 4). 227 The module makes use of the standard Internet types, such as IP 228 addresses, autonomous system numbers, etc., defined in RFC 6991 229 [RFC6991]. 231 4. Route policy expression 233 Policies are expressed as a sequence of top-level policy definitions 234 each of which consists of a sequence of policy statements. Policy 235 statements in turn consist of simple condition-action tuples. 237 Conditions may include multiple match or comparison operations, and 238 similarly, actions may effect multiple changes to route attributes, 239 or indicate a final disposition of accepting or rejecting the route. 240 This structure is shown below. 242 +--rw routing-policy 243 +--rw policy-definitions 244 +--rw policy-definition* [name] 245 +--rw name string 246 +--rw statements 247 +--rw statement* [name] 248 +--rw name string 249 +--rw conditions 250 | ... 251 +--rw actions 252 ... 254 4.1. Defined sets for policy matching 256 The models provide a set of generic sets that can be used for 257 matching in policy conditions. These sets are applicable for route 258 selection across multiple routing protocols. They may be further 259 augmented by protocol-specific models which have their own defined 260 sets. The supported defined sets include: 262 o prefix sets - define a set of IP prefixes, each with an associated 263 IP prefix and netmask range (or exact length) 265 o neighbor sets - define a set of neighboring nodes by their IP 266 addresses. These sets are used for selecting routes based on the 267 neighbors advertising the routes. 269 o tag set - define a set of generic tag values that can be used in 270 matches for filtering routes 272 The model structure for defined sets is shown below. 274 +--rw routing-policy 275 +--rw defined-sets 276 | +--rw prefix-sets 277 | | +--rw prefix-set* [name] 278 | | +--rw name string 279 | | +--rw mode? enumeration 280 | | +--rw prefixes 281 | | +--rw prefix-list* [ip-prefix mask-length-lower 282 | | mask-length-upper] 283 | | +--rw ip-prefix inet:ip-prefix 284 | | +--rw mask-length-lower uint8 285 | | +--rw mask-length-upper uint8 286 | +--rw neighbor-sets 287 | | +--rw neighbor-set* [name] 288 | | +--rw name string 289 | | +--rw address* inet:ip-address 290 | +--rw tag-sets 291 | +--rw tag-set* [name] 292 | +--rw name string 293 | +--rw tag-value* tag-type 295 4.2. Policy conditions 297 Policy statements consist of a set of conditions and actions (either 298 of which may be empty). Conditions are used to match route 299 attributes against a defined set (e.g., a prefix set), or to compare 300 attributes against a specific value. 302 Match conditions may be further modified using the match-set-options 303 configuration which allows network operators to change the behavior 304 of a match. Three options are supported: 306 o ALL - match is true only if the given value matches all members of 307 the set. 309 o ANY - match is true if the given value matches any member of the 310 set. 312 o INVERT - match is true if the given value does not match any 313 member of the given set. 315 Not all options are appropriate for matching against all defined sets 316 (e.g., match ALL in a prefix set does not make sense). In the model, 317 a restricted set of match options is used where applicable. 319 Comparison conditions may similarly use options to change how route 320 attributes should be tested, e.g., for equality or inequality, 321 against a given value. 323 While most policy conditions will be added by individual routing 324 protocol models via augmentation, this routing policy model includes 325 several generic match conditions and also the ability to test which 326 protocol or mechanism installed a route (e.g., BGP, IGP, static, 327 etc.). The conditions included in the model are shown below. 329 +--rw routing-policy 330 +--rw policy-definitions 331 +--rw policy-definition* [name] 332 +--rw name string 333 +--rw statements 334 +--rw statement* [name] 335 +--rw conditions 336 | +--rw call-policy? 337 | +--rw source-protocol? 338 | +--rw match-interface 339 | | +--rw interface? 340 | | +--rw subinterface? 341 | +--rw match-prefix-set 342 | | +--rw prefix-set? 343 | | +--rw match-set-options? 344 | +--rw match-neighbor-set 345 | | +--rw neighbor-set? 346 | +--rw match-tag-set 347 | | +--rw tag-set? 348 | | +--rw match-set-options? 349 | +--rw match-route-type* identityref 351 4.3. Policy actions 353 When policy conditions are satisfied, policy actions are used to set 354 various attributes of the route being processed, or to indicate the 355 final disposition of the route, i.e., accept or reject. 357 Similar to policy conditions, the routing policy model includes 358 generic actions in addition to the basic route disposition actions. 359 These are shown below. 361 +--rw routing-policy 362 +--rw policy-definitions 363 +--rw policy-definition* [name] 364 +--rw statements 365 +--rw statement* [name] 366 +--rw actions 367 +--rw policy-result? policy-result-type 368 +--rw set-metric 369 | +--rw metric-modification? 370 | | metric-modification-type 371 | +--rw metric? uint32 372 +--rw set-metric-type 373 | +--rw metric-type? identityref 374 +--rw set-route-level 375 | +--rw route-level? identityref 376 +--rw set-preference? uint16 377 +--rw set-tag? tag-type 378 +--rw set-application-tag? tag-type 380 4.4. Policy subroutines 382 Policy 'subroutines' (or nested policies) are supported by allowing 383 policy statement conditions to reference other policy definitions 384 using the call-policy configuration. Called policies apply their 385 conditions and actions before returning to the calling policy 386 statement and resuming evaluation. The outcome of the called policy 387 affects the evaluation of the calling policy. If the called policy 388 results in an accept-route, then the subroutine returns an effective 389 boolean true value to the calling policy. For the calling policy, 390 this is equivalent to a condition statement evaluating to a true 391 value and evaluation of the policy continues (see Section 5). Note 392 that the called policy may also modify attributes of the route in its 393 action statements. Similarly, a reject-route action returns false 394 and the calling policy evaluation will be affected accordingly. When 395 the end of the subroutine policy statements is reached, the default 396 route disposition action is returned (i.e., boolean false for reject- 397 route). Consequently, a subroutine cannot explicitly accept or 398 reject a route. Rather it merely provides an indication that 'call- 399 policy' condition returns boolean true or false indicating whether or 400 not the condition matches. Route acceptance or rejection is solely 401 determined by the top-level policy. 403 Note that the called policy may itself call other policies (subject 404 to implementation limitations). The model does not prescribe a 405 nesting depth because this varies among implementations. For 406 example, some major implementation may only support a single level of 407 subroutine recursion. As with any routing policy construction, care 408 must be taken with nested policies to ensure that the effective 409 return value results in the intended behavior. Nested policies are a 410 convenience in many routing policy constructions but creating 411 policies nested beyond a small number of levels (e.g., 2-3) are 412 discouraged. Also, implementations should have validation to ensure 413 that there is no recursion amongst nested routing policies. 415 5. Policy evaluation 417 Evaluation of each policy definition proceeds by evaluating its 418 corresponding individual policy statements in order. When all the 419 condition statements in a policy statement are satisfied, the 420 corresponding action statements are executed. If the actions include 421 either accept-route or reject-route actions, evaluation of the 422 current policy definition stops, and no further policy statement are 423 evaluated. If there are multiple policies in the policy chain, 424 subsequent policies are not evaluated. Policy chains are sequences 425 of policy definitions (described in . (Section 4)). 427 If the conditions are not satisfied, then evaluation proceeds to the 428 next policy statement. If none of the policy statement conditions 429 are satisfied, then evaluation of the current policy definition 430 stops, and the next policy definition in the chain is evaluated. 431 When the end of the policy chain is reached, the default route 432 disposition action is performed (i.e., reject-route unless an 433 alternate default action is specified for the chain). 435 Note that the route's pre-policy attributes are always used for 436 testing policy statement conditions. In other words, if actions 437 modify the policy application specific attributes, those 438 modifications are not used for policy statement conditions. 440 6. Applying routing policy 442 Routing policy is applied by defining and attaching policy chains in 443 various routing contexts. Policy chains are sequences of policy 444 definitions (described in Section 4). They can be referenced from 445 different contexts. For example, a policy chain could be associated 446 with a routing protocol and used to control its interaction with its 447 protocol peers. Or, it could be used to control the interaction 448 between a routing protocol and the local routing information base. A 449 policy chain has an associated direction (import or export), with 450 respect to the context in which it is referenced. 452 The routing policy model defines an apply-policy grouping that can be 453 imported and used by other models. As shown below, it allows 454 definition of import and export policy chains, as well as specifying 455 the default route disposition to be used when no policy definition in 456 the chain results in a final decision. 458 +--rw apply-policy 459 | +--rw import-policy* 460 | +--rw default-import-policy? default-policy-type 461 | +--rw export-policy* 462 | +--rw default-export-policy? default-policy-type 464 The default policy defined by the model is to reject the route for 465 both import and export policies. 467 7. Security Considerations 469 The YANG modules specified in this document define a schema for data 470 that is designed to be accessed via network management protocols such 471 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 472 is the secure transport layer, and the mandatory-to-implement secure 473 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 474 is HTTPS, and the mandatory-to-implement secure transport is TLS 475 [RFC8446]. 477 The NETCONF Access Control Model (NACM) [RFC8341] provides the means 478 to restrict access for particular NETCONF or RESTCONF users to a pre- 479 configured subset of all available NETCONF or RESTCONF protocol 480 operations and content. 482 There are a number of data nodes defined in this YANG module that are 483 writable/creatable/deletable (i.e., config true, which is the 484 default). These data nodes may be considered sensitive or vulnerable 485 in some network environments. Write operations (e.g., edit-config) 486 to these data nodes without proper protection can have a negative 487 effect on network operations. These are the subtrees and data nodes 488 and their sensitivity/vulnerability: 490 /routing-policy 492 /routing-policy/defined-sets/prefix-sets 494 /routing-policy/defined-sets/neighbor-sets 496 /routing-policy/defined-sets/tag-sets 498 /routing-policy/policy-definitions 500 Unauthorized access to any data node of these subtrees can disclose 501 the operational state information of routing policies on this device. 503 Routing policy configuration has a significant impact on network 504 operations, and, as such, any related model carries potential 505 security risks. Unauthorized access or invalid data could cause 506 major disruption. 508 8. IANA Considerations 510 This document registers a URI in the IETF XML registry [RFC3688]. 511 Following the format in [RFC3688], the following registration is 512 requested to be made: 514 URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy 515 Registrant Contact: The IESG. 516 XML: N/A, the requested URI is an XML namespace. 518 This document registers a YANG module in the YANG Module Names 519 registry [RFC6020]. 521 name: ietf-routing-policy 522 namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy 523 prefix: rt-pol 524 reference: RFC XXXX 526 9. YANG module 528 The routing policy model is described by the YANG modules in the 529 sections below. [RFC2328], [RFC3101], [RFC5130], and [RFC5302] are 530 referenced here since they are referenced in the YANG model but not 531 elsewhere in this document. 533 9.1. Routing policy model 535 file "ietf-routing-policy@2020-09-18.yang" 536 module ietf-routing-policy { 538 yang-version "1.1"; 540 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; 541 prefix rt-pol; 543 import ietf-inet-types { 544 prefix "inet"; 545 reference "RFC 6991: Common YANG Data Types"; 546 } 548 import ietf-yang-types { 549 prefix "yang"; 550 reference "RFC 6991: Common YANG Data Types"; 551 } 552 import ietf-interfaces { 553 prefix "if"; 554 reference "RFC 8343: A YANG Data Model for Interface 555 Management (NMDA Version)"; 556 } 558 import ietf-routing { 559 prefix "rt"; 560 reference "RFC 8349: A YANG Data Model for Routing 561 Management (NMDA Version)"; 562 } 564 import ietf-if-extensions { 565 prefix "if-ext"; 566 reference "RFC YYYY: Common Interface Extension YANG 567 Data Models. Please replace YYYY with 568 published RFC number for 569 draft-ietf-netmod-intf-ext-yang."; 570 } 572 import ietf-if-flexible-encapsulation { 573 prefix "if-flex"; 574 reference "RFC ZZZZ: Sub-interface VLAN YANG Data Models. 575 Please replace ZZZZ with published RFC number 576 for draft-ietf-netmod-sub-intf-vlan-model."; 577 } 579 organization 580 "IETF RTGWG - Routing Area Working Group"; 581 contact 582 "WG Web: 583 WG List: 585 Editor: Yingzhen Qu 586 587 Jeff Tantsura 588 589 Acee Lindem 590 591 Xufeng Liu 592 "; 594 description 595 "This module describes a YANG model for routing policy 596 configuration. It is a limited subset of all of the policy 597 configuration parameters available in the variety of vendor 598 implementations, but supports widely used constructs for 599 managing how routes are imported, exported, modified and 600 advertised across different routing protocol instances or 601 within a single routing protocol instance. This module is 602 intended to be used in conjunction with routing protocol 603 configuration modules (e.g., BGP) defined in other models. 605 Route policy expression: 607 Policies are expressed as a set of top-level policy 608 definitions, each of which consists of a sequence of policy 609 statements. Policy statements consist of simple 610 condition-action tuples. Conditions may include multiple match 611 or comparison operations, and similarly actions may be a 612 multitude of changes to route attributes or a final 613 disposition of accepting or rejecting the route. 615 Route policy evaluation: 617 Policy definitions are referenced in routing protocol 618 configurations using import and export configuration 619 statements. The arguments are members of an ordered list of 620 named policy definitions which comprise a policy chain, and 621 optionally, an explicit default policy action (i.e., reject 622 or accept). 624 Evaluation of each policy definition proceeds by evaluating 625 its corresponding individual policy statements in order. When 626 a condition statement in a policy statement is satisfied, the 627 corresponding action statement is executed. If the action 628 statement has either accept-route or reject-route actions, 629 policy evaluation of the current policy definition stops, and 630 no further policy definitions in the chain are evaluated. 632 If the condition is not satisfied, then evaluation proceeds to 633 the next policy statement. If none of the policy statement 634 conditions are satisfied, then evaluation of the current 635 policy definition stops, and the next policy definition in the 636 chain is evaluated. When the end of the policy chain is 637 reached, the default route disposition action is performed 638 (i.e., reject-route unless an alternate default action is 639 specified for the chain). 641 Policy 'subroutines' (or nested policies) are supported by 642 allowing policy statement conditions to reference another 643 policy definition which applies conditions and actions from 644 the referenced policy before returning to the calling policy 645 statement and resuming evaluation. If the called policy 646 results in an accept-route (either explicit or by default), 647 then the subroutine returns an effective true value to the 648 calling policy. Similarly, a reject-route action returns 649 false. If the subroutine returns true, the calling policy 650 continues to evaluate the remaining conditions with the initial 651 data if route attribute values are modified. 653 Copyright (c) 2020 IETF Trust and the persons identified as 654 authors of the code. All rights reserved. 656 Redistribution and use in source and binary forms, with or 657 without modification, is permitted pursuant to, and subject to 658 the license terms contained in, the Simplified BSD License set 659 forth in Section 4.c of the IETF Trust's Legal Provisions 660 Relating to IETF Documents 661 (https://trustee.ietf.org/license-info). 663 This version of this YANG module is part of RFC XXXX 664 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 665 for full legal notices. 667 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 668 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT 669 RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 670 interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, 671 and only when, they appear in all capitals, as shown here. 673 This version of this YANG module is part of RFC XXXX; 674 see the RFC itself for full legal notices."; 676 revision "2020-09-18" { 677 description 678 "Initial revision."; 679 reference 680 "RFC XXXX: Routing Policy Configuration Model for Service 681 Provider Networks"; 682 } 684 /* Identities */ 686 identity metric-type { 687 description 688 "Base identity for route metric types."; 689 } 691 identity ospf-type-1-metric { 692 base metric-type; 693 description 694 "Identity for the OSPF type 1 external metric types. It 695 is only applicable to OSPF routes."; 696 reference 697 "RFC 2328 - OSPF Version 2"; 698 } 700 identity ospf-type-2-metric { 701 base metric-type; 702 description 703 "Identity for the OSPF type 2 external metric types. It 704 is only applicable to OSPF routes."; 705 reference 706 "RFC 2328 - OSPF Version 2"; 707 } 709 identity isis-internal-metric { 710 base metric-type; 711 description 712 "Identity for the IS-IS internal metric types. It is only 713 applicable to IS-IS routes."; 714 reference 715 "RFC 5302 - Domain-Wide Prefix Distribution with 716 Two-Level IS-IS"; 717 } 719 identity isis-external-metric { 720 base metric-type; 721 description 722 "Identity for the IS-IS external metric types. It is only 723 applicable to IS-IS routes."; 724 reference 725 "RFC 5302 - Domain-Wide Prefix Distribution with 726 Two-Level IS-IS"; 727 } 729 identity route-level { 730 description 731 "Base identity for route import or export level."; 732 } 734 identity ospf-normal { 735 base route-level; 736 description 737 "Identity for OSPF importation into normal areas 738 It is only applicable to routes imported 739 into the OSPF protocol."; 740 reference 741 "RFC 2328 - OSPF Version 2"; 743 } 745 identity ospf-nssa-only { 746 base route-level; 747 description 748 "Identity for the OSPF Not-So-Stubby Area (NSSA) area 749 importation. It is only applicable to routes imported 750 into the OSPF protocol."; 751 reference 752 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 753 } 755 identity ospf-normal-nssa { 756 base route-level; 757 description 758 "Identity for OSPF importation into both normal and NSSA 759 areas, it is only applicable to routes imported into 760 the OSPF protocol."; 761 reference 762 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 763 } 765 identity isis-level-1 { 766 base route-level; 767 description 768 "Identity for IS-IS Level 1 area importation. It is only 769 applicable to routes imported into the IS-IS protocol."; 770 reference 771 "RFC 5302 - Domain-Wide Prefix Distribution with 772 Two-Level IS-IS"; 773 } 775 identity isis-level-2 { 776 base route-level; 777 description 778 "Identity for IS-IS Level 2 area importation. It is only 779 applicable to routes imported into the IS-IS protocol."; 780 reference 781 "RFC 5302 - Domain-Wide Prefix Distribution with 782 Two-Level IS-IS"; 783 } 785 identity isis-level-1-2 { 786 base route-level; 787 description 788 "Identity for IS-IS Level 1 and Level 2 area importation. It 789 is only applicable to routes imported into the IS-IS 790 protocol."; 792 reference 793 "RFC 5302 - Domain-Wide Prefix Distribution with 794 Two-Level IS-IS"; 795 } 797 identity proto-route-type { 798 description 799 "Base identity for route type within a protocol."; 800 } 802 identity isis-level-1-type { 803 base proto-route-type; 804 description 805 "Identity for IS-IS Level 1 route type. It is only 806 applicable to IS-IS routes."; 807 reference 808 "RFC 5302 - Domain-Wide Prefix Distribution with 809 Two-Level IS-IS"; 810 } 812 identity isis-level-2-type { 813 base proto-route-type; 814 description 815 "Identity for IS-IS Level 2 route type. It is only 816 applicable to IS-IS routes."; 817 reference 818 "RFC 5302 - Domain-Wide Prefix Distribution with 819 Two-Level IS-IS"; 820 } 822 identity ospf-internal-type { 823 base proto-route-type; 824 description 825 "Identity for OSPF intra-area or inter-area route type. 826 It is only applicable to OSPF routes."; 827 reference 828 "RFC 2328 - OSPF Version 2"; 829 } 831 identity ospf-external-type { 832 base proto-route-type; 833 description 834 "Identity for OSPF external type 1/2 route type. 835 It is only applicable to OSPF routes."; 836 reference 837 "RFC 2328 - OSPF Version 2"; 838 } 839 identity ospf-external-t1-type { 840 base ospf-external-type; 841 description 842 "Identity for OSPF external type 1 route type. 843 It is only applicable to OSPF routes."; 844 reference 845 "RFC 2328 - OSPF Version 2"; 846 } 848 identity ospf-external-t2-type { 849 base ospf-external-type; 850 description 851 "Identity for OSPF external type 2 route type. 852 It is only applicable to OSPF routes."; 853 reference 854 "RFC 2328 - OSPF Version 2"; 855 } 857 identity ospf-nssa-type { 858 base proto-route-type; 859 description 860 "Identity for OSPF NSSA type 1/2 route type. 861 It is only applicable to OSPF routes."; 862 reference 863 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 864 } 866 identity ospf-nssa-t1-type { 867 base ospf-nssa-type; 868 description 869 "Identity for OSPF NSSA type 1 route type. 870 It is only applicable to OSPF routes."; 871 reference 872 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 873 } 875 identity ospf-nssa-t2-type { 876 base ospf-nssa-type; 877 description 878 "Identity for OSPF NSSA type 2 route type. 879 It is only applicable to OSPF routes."; 880 reference 881 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 882 } 884 identity bgp-internal { 885 base proto-route-type; 886 description 887 "Identity for routes learned from internal BGP (IBGP). 888 It is only applicable to BGP routes."; 889 reference 890 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 891 } 893 identity bgp-external { 894 base proto-route-type; 895 description 896 "Identity for routes learned from external BGP (EBGP). 897 It is only applicable to BGP routes."; 898 reference 899 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 900 } 902 /* Type Definitions */ 904 typedef default-policy-type { 905 type enumeration { 906 enum accept-route { 907 description 908 "Default policy to accept the route."; 909 } 910 enum reject-route { 911 description 912 "Default policy to reject the route."; 913 } 914 } 915 description 916 "Type used to specify route disposition in 917 a policy chain. This typedef retained for 918 name compatibility with default import and 919 export policy."; 920 } 922 typedef policy-result-type { 923 type enumeration { 924 enum accept-route { 925 description 926 "Policy accepts the route."; 927 } 928 enum reject-route { 929 description 930 "Policy rejects the route."; 931 } 932 } 933 description 934 "Type used to specify route disposition in 935 a policy chain."; 936 } 938 typedef tag-type { 939 type union { 940 type uint32; 941 type yang:hex-string; 942 } 943 description 944 "Type for expressing route tags on a local system, 945 including IS-IS and OSPF; may be expressed as either decimal 946 or hexadecimal integer."; 947 reference 948 "RFC 2328 - OSPF Version 2 949 RFC 5130 - A Policy Control Mechanism in IS-IS Using 950 Administrative Tags"; 951 } 953 typedef match-set-options-type { 954 type enumeration { 955 enum any { 956 description 957 "Match is true if given value matches any member 958 of the defined set."; 959 } 960 enum all { 961 description 962 "Match is true if given value matches all 963 members of the defined set."; 964 } 965 enum invert { 966 description 967 "Match is true if given value does not match any 968 member of the defined set."; 969 } 970 } 971 default any; 972 description 973 "Options that govern the behavior of a match statement. The 974 default behavior is any, i.e., the given value matches any 975 of the members of the defined set."; 976 } 978 typedef metric-modification-type { 979 type enumeration { 980 enum set-metric { 981 description 982 "Set the metric to the specified value."; 984 } 985 enum add-metric { 986 description 987 "Add the specified value to the existing metric. 988 If the result would overflow the maximum metric 989 (0xffffffff), set the metric to the maximum."; 990 } 991 enum subtract-metric { 992 description 993 "Subtract the specified value to the existing metric. If 994 the result would be less than 0, set the metric to 0."; 995 } 996 } 997 description 998 "Type used to specify how to set the metric given the 999 specified value."; 1000 } 1002 /* Groupings */ 1004 grouping prefix { 1005 description 1006 "Configuration data for a prefix definition."; 1008 leaf ip-prefix { 1009 type inet:ip-prefix; 1010 mandatory true; 1011 description 1012 "The IP prefix represented as an IPv6 or IPv4 network 1013 number followed by a prefix length with an intervening 1014 slash character as a delimiter. All members of the prefix 1015 set MUST be of the same address family as the prefix-set 1016 mode."; 1017 } 1019 leaf mask-length-lower { 1020 type uint8; 1021 description 1022 "Mask length range lower bound. It MUST not be less than 1023 the prefix length defined in ip-prefix."; 1024 } 1025 leaf mask-length-upper { 1026 type uint8 { 1027 range "1..128"; 1028 } 1029 must "../mask-length-upper >= ../mask-length-lower" { 1030 error-message "The upper bound MUST not be less" 1031 + "than lower bound."; 1033 } 1034 description 1035 "Mask length range upper bound. 1037 The combination of mask-length-lower and mask-length-upper 1038 define a range for the mask length, or single 'exact' 1039 length if mask-length-lower and mask-length-upper are 1040 equal. 1042 Example: 192.0.2.0/24 through 192.0.2.0/26 would be 1043 expressed as prefix: 192.0.2.0/24, 1044 mask-length-lower=24, 1045 mask-length-upper=26 1047 Example: 192.0.2.0/24 (an exact match) would be 1048 expressed as prefix: 192.0.2.0/24, 1049 mask-length-lower=24, 1050 mask-length-upper=24"; 1051 } 1052 } 1054 grouping match-set-options-group { 1055 description 1056 "Grouping containing options relating to how a particular set 1057 will be matched."; 1059 leaf match-set-options { 1060 type match-set-options-type; 1061 description 1062 "Optional parameter that governs the behavior of the 1063 match operation."; 1064 } 1065 } 1067 grouping match-set-options-restricted-group { 1068 description 1069 "Grouping for a restricted set of match operation 1070 modifiers."; 1072 leaf match-set-options { 1073 type match-set-options-type { 1074 enum any { 1075 description 1076 "Match is true if given value matches any 1077 member of the defined set."; 1078 } 1079 enum invert { 1080 description 1081 "Match is true if given value does not match 1082 any member of the defined set."; 1083 } 1084 } 1085 description 1086 "Optional parameter that governs the behavior of the 1087 match operation. This leaf only supports matching on 1088 'any' member of the set or 'invert' the match. 1089 Matching on 'all' is not supported."; 1090 } 1091 } 1093 grouping match-interface-condition { 1094 description 1095 "This grouping provides interface match condition."; 1097 container match-interface { 1098 leaf interface { 1099 type leafref { 1100 path "/if:interfaces/if:interface/if:name"; 1101 } 1102 description 1103 "Reference to a base interface. If a reference to a 1104 subinterface is required, this leaf MUST be specified 1105 to indicate the base interface."; 1106 } 1107 leaf subinterface { 1108 type leafref { 1109 path "/if:interfaces/if:interface/if-ext:encapsulation" 1110 + "/if-flex:flexible/if-flex:match" 1111 + "/if-flex:dot1q-vlan-tagged" 1112 + "/if-flex:outer-tag/if-flex:vlan-id"; 1113 } 1114 description 1115 "Reference to a subinterface -- this requires the base 1116 interface to be specified using the interface leaf in 1117 this container. If only a reference to a base interface 1118 is required, this leaf SHOULD not be set."; 1119 } 1121 description 1122 "Container for interface match conditions"; 1123 } 1124 } 1126 grouping match-route-type-condition { 1127 description 1128 "This grouping provides route-type match condition"; 1130 leaf-list match-route-type { 1131 type identityref { 1132 base proto-route-type; 1133 } 1134 description 1135 "Condition to check the protocol-specific type 1136 of route. This is normally used during route 1137 importation to select routes or to set protocol 1138 specific attributes based on the route type."; 1139 } 1140 } 1142 grouping prefix-set-condition { 1143 description 1144 "This grouping provides prefix-set conditions."; 1146 container match-prefix-set { 1147 leaf prefix-set { 1148 type leafref { 1149 path "../../../../../../../defined-sets/" + 1150 "prefix-sets/prefix-set/name"; 1151 } 1152 description 1153 "References a defined prefix set."; 1154 } 1155 uses match-set-options-restricted-group; 1157 description 1158 "Match a referenced prefix-set according to the logic 1159 defined in the match-set-options leaf."; 1160 } 1161 } 1163 grouping neighbor-set-condition { 1164 description 1165 "This grouping provides neighbor-set conditions."; 1167 container match-neighbor-set { 1168 leaf neighbor-set { 1169 type leafref { 1170 path "../../../../../../../defined-sets/neighbor-sets/" + 1171 "neighbor-set/name"; 1172 require-instance true; 1173 } 1174 description 1175 "References a defined neighbor set."; 1176 } 1177 description 1178 "Match a referenced neighbor set according to the logic 1179 defined in the match-set-options-leaf."; 1180 } 1181 } 1183 grouping tag-set-condition { 1184 description 1185 "This grouping provides tag-set conditions."; 1187 container match-tag-set { 1188 leaf tag-set { 1189 type leafref { 1190 path "../../../../../../../defined-sets/tag-sets" + 1191 "/tag-set/name"; 1192 require-instance true; 1193 } 1194 description 1195 "References a defined tag set."; 1196 } 1197 uses match-set-options-restricted-group; 1199 description 1200 "Match a referenced tag set according to the logic defined 1201 in the match-options-set leaf."; 1202 } 1203 } 1205 grouping apply-policy-import { 1206 description 1207 "Grouping for applying import policies."; 1209 leaf-list import-policy { 1210 type leafref { 1211 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1212 "rt-pol:policy-definition/rt-pol:name"; 1213 require-instance true; 1214 } 1215 ordered-by user; 1216 description 1217 "List of policy names in sequence to be applied on 1218 receiving redistributed routes from another routing protocol 1219 or receiving a routing update in the current context, e.g., 1220 for the current peer group, neighbor, address family, 1221 etc."; 1222 } 1224 leaf default-import-policy { 1225 type default-policy-type; 1226 default reject-route; 1227 description 1228 "Explicitly set a default policy if no policy definition 1229 in the import policy chain is satisfied."; 1230 } 1232 } 1234 grouping apply-policy-export { 1235 description 1236 "Grouping for applying export policies."; 1238 leaf-list export-policy { 1239 type leafref { 1240 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1241 "rt-pol:policy-definition/rt-pol:name"; 1242 require-instance true; 1243 } 1244 ordered-by user; 1245 description 1246 "List of policy names in sequence to be applied on 1247 redistributing routes from one routing protocol to another 1248 or sending a routing update in the current context, e.g., 1249 for the current peer group, neighbor, address family, 1250 etc."; 1251 } 1253 leaf default-export-policy { 1254 type default-policy-type; 1255 default reject-route; 1256 description 1257 "Explicitly set a default policy if no policy definition 1258 in the export policy chain is satisfied."; 1259 } 1260 } 1262 grouping apply-policy-group { 1263 description 1264 "Top level container for routing policy applications. This 1265 grouping is intended to be used in routing models where 1266 needed."; 1268 container apply-policy { 1269 description 1270 "Anchor point for routing policies in the model. 1271 Import and export policies are with respect to the local 1272 routing table, i.e., export (send) and import (receive), 1273 depending on the context."; 1275 uses apply-policy-import; 1276 uses apply-policy-export; 1278 } 1279 } 1281 container routing-policy { 1282 description 1283 "Top-level container for all routing policy."; 1285 container defined-sets { 1286 description 1287 "Predefined sets of attributes used in policy match 1288 statements."; 1290 container prefix-sets { 1291 description 1292 "Data definitions for a list of IPv4 or IPv6 1293 prefixes which are matched as part of a policy."; 1294 list prefix-set { 1295 key "name mode"; 1296 description 1297 "List of the defined prefix sets"; 1299 leaf name { 1300 type string; 1301 description 1302 "Name of the prefix set -- this is used as a label to 1303 reference the set in match conditions."; 1304 } 1306 leaf mode { 1307 type enumeration { 1308 enum ipv4 { 1309 description 1310 "Prefix set contains IPv4 prefixes only."; 1311 } 1312 enum ipv6 { 1313 description 1314 "Prefix set contains IPv6 prefixes only."; 1315 } 1316 } 1317 description 1318 "Indicates the mode of the prefix set, in terms of 1319 which address families (IPv4, IPv6, or both) are 1320 present. The mode provides a hint, but the device 1321 MUST validate that all prefixes are of the indicated 1322 type, and is expected to reject the configuration if 1323 there is a discrepancy."; 1324 } 1326 container prefixes { 1327 description 1328 "Container for the list of prefixes in a policy 1329 prefix list. Since individual prefixes do not have 1330 unique actions, the order in which the prefix in 1331 prefix-list are matched has no impact on the outcome 1332 and is left to the implementation. A given prefix-set 1333 condition is satisfied if the input prefix matches 1334 any of the prefixes in the prefix-set."; 1336 list prefix-list { 1337 key "ip-prefix mask-length-lower mask-length-upper"; 1338 description 1339 "List of prefixes in the prefix set."; 1341 uses prefix; 1342 } 1343 } 1344 } 1345 } 1347 container neighbor-sets { 1348 description 1349 "Data definition for a list of IPv4 or IPv6 1350 neighbors which can be matched in a routing policy."; 1352 list neighbor-set { 1353 key "name"; 1354 description 1355 "List of defined neighbor sets for use in policies."; 1357 leaf name { 1358 type string; 1359 description 1360 "Name of the neighbor set -- this is used as a label 1361 to reference the set in match conditions."; 1362 } 1364 leaf-list address { 1365 type inet:ip-address; 1366 description 1367 "List of IP addresses in the neighbor set."; 1368 } 1370 } 1371 } 1373 container tag-sets { 1374 description 1375 "Data definitions for a list of tags which can 1376 be matched in policies."; 1378 list tag-set { 1379 key "name"; 1380 description 1381 "List of tag set definitions."; 1383 leaf name { 1384 type string; 1385 description 1386 "Name of the tag set -- this is used as a label to 1387 reference the set in match conditions."; 1388 } 1390 leaf-list tag-value { 1391 type tag-type; 1392 description 1393 "Value of the tag set member."; 1394 } 1395 } 1396 } 1397 } 1399 container policy-definitions { 1400 description 1401 "Enclosing container for the list of top-level policy 1402 definitions."; 1404 list policy-definition { 1405 key "name"; 1406 description 1407 "List of top-level policy definitions, keyed by unique 1408 name. These policy definitions are expected to be 1409 referenced (by name) in policy chains specified in 1410 import or export configuration statements."; 1412 leaf name { 1413 type string; 1414 description 1415 "Name of the top-level policy definition -- this name 1416 is used in references to the current policy."; 1417 } 1418 container statements { 1419 description 1420 "Enclosing container for policy statements."; 1422 list statement { 1423 key "name"; 1424 ordered-by user; 1425 description 1426 "Policy statements group conditions and actions 1427 within a policy definition. They are evaluated in 1428 the order specified (see the description of policy 1429 evaluation at the top of this module."; 1431 leaf name { 1432 type string; 1433 description 1434 "Name of the policy statement."; 1435 } 1437 container conditions { 1438 description 1439 "Condition statements for the current policy 1440 statement."; 1442 leaf call-policy { 1443 type leafref { 1444 path "../../../../../../" + 1445 "rt-pol:policy-definitions/" + 1446 "rt-pol:policy-definition/rt-pol:name"; 1447 require-instance true; 1448 } 1449 description 1450 "Applies the statements from the specified policy 1451 definition and then returns control to the current 1452 policy statement. Note that the called policy 1453 may itself call other policies (subject to 1454 implementation limitations). This is intended to 1455 provide a policy 'subroutine' capability. The 1456 called policy SHOULD contain an explicit or a 1457 default route disposition that returns an 1458 effective true (accept-route) or false 1459 (reject-route), otherwise the behavior may be 1460 ambiguous."; 1461 } 1463 leaf source-protocol { 1464 type identityref { 1465 base rt:control-plane-protocol; 1467 } 1468 description 1469 "Condition to check the protocol / method used to 1470 install the route into the local routing table."; 1471 } 1473 uses match-interface-condition; 1474 uses prefix-set-condition; 1475 uses neighbor-set-condition; 1476 uses tag-set-condition; 1477 uses match-route-type-condition; 1478 } 1480 container actions { 1481 description 1482 "Top-level container for policy action 1483 statements."; 1484 leaf policy-result { 1485 type policy-result-type; 1486 description 1487 "Select the final disposition for the route, 1488 either accept or reject."; 1489 } 1490 container set-metric { 1491 leaf metric-modification { 1492 type metric-modification-type; 1493 description 1494 "Indicates how to modify the metric."; 1495 } 1496 leaf metric { 1497 type uint32; 1498 description 1499 "Metric value to set, add, or subtract."; 1500 } 1501 description 1502 "Set the metric for the route."; 1503 } 1504 container set-metric-type { 1505 leaf metric-type { 1506 type identityref { 1507 base metric-type; 1508 } 1509 description 1510 "Route metric type."; 1511 } 1512 description 1513 "Set the metric type for the route."; 1514 } 1515 container set-route-level { 1516 leaf route-level { 1517 type identityref { 1518 base route-level; 1519 } 1520 description 1521 "Route import or export level."; 1522 } 1523 description 1524 "Set the level for importation or 1525 exportation of routes."; 1526 } 1527 leaf set-preference { 1528 type uint16; 1529 description 1530 "Set the preference for the route."; 1531 } 1532 leaf set-tag { 1533 type tag-type; 1534 description 1535 "Set the tag for the route."; 1536 } 1537 leaf set-application-tag { 1538 type tag-type; 1539 description 1540 "Set the application tag for the route."; 1541 } 1542 } 1543 } 1544 } 1545 } 1546 } 1547 } 1548 } 1549 CODE ENDS> 1551 10. Acknowledgements 1553 The routing policy module defined in this document is based on the 1554 OpenConfig route policy model. The authors would like to thank to 1555 OpenConfig for their contributions, especially Anees Shaikh, Rob 1556 Shakir, Kevin D'Souza, and Chris Chase. 1558 The authors are grateful for valuable contributions to this document 1559 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1560 George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, 1561 Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and 1562 John Heasley. 1564 Thanks to Mahesh Jethanandani, John Scudder, Chris Bower and Tom 1565 Petch for their reviews and comments. 1567 11. References 1569 11.1. Normative references 1571 [INTF-EXT-YANG] 1572 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1573 Sivaraj,, "Common Interface Extension YANG Data Models", 1574 2019, . 1577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1578 Requirement Levels", BCP 14, RFC 2119, 1579 DOI 10.17487/RFC2119, March 1997, 1580 . 1582 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1583 DOI 10.17487/RFC2328, April 1998, 1584 . 1586 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1587 RFC 3101, DOI 10.17487/RFC3101, January 2003, 1588 . 1590 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1591 DOI 10.17487/RFC3688, January 2004, 1592 . 1594 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1595 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1596 DOI 10.17487/RFC4271, January 2006, 1597 . 1599 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 1600 Control Mechanism in IS-IS Using Administrative Tags", 1601 RFC 5130, DOI 10.17487/RFC5130, February 2008, 1602 . 1604 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 1605 Distribution with Two-Level IS-IS", RFC 5302, 1606 DOI 10.17487/RFC5302, October 2008, 1607 . 1609 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1610 the Network Configuration Protocol (NETCONF)", RFC 6020, 1611 DOI 10.17487/RFC6020, October 2010, 1612 . 1614 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1615 and A. Bierman, Ed., "Network Configuration Protocol 1616 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1617 . 1619 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1620 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1621 . 1623 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1624 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1625 . 1627 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1628 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1629 . 1631 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1632 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1633 . 1635 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1636 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1637 May 2017, . 1639 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1640 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1641 . 1643 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1644 Access Control Model", STD 91, RFC 8341, 1645 DOI 10.17487/RFC8341, March 2018, 1646 . 1648 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1649 and R. Wilton, "Network Management Datastore Architecture 1650 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1651 . 1653 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1654 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1655 . 1657 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1658 Routing Management (NMDA Version)", RFC 8349, 1659 DOI 10.17487/RFC8349, March 2018, 1660 . 1662 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1663 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1664 . 1666 [SUB-INTF-VLAN-YANG] 1667 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1668 Sivaraj, "Sub-interface VLAN YANG Data Model", 2019, 1669 . 1672 11.2. Informative references 1674 [I-D.ietf-idr-bgp-model] 1675 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1676 YANG Model for Service Provider Networks", draft-ietf-idr- 1677 bgp-model-09 (work in progress), June 2020. 1679 Appendix A. Routing protocol-specific policies 1681 Routing models that require the ability to apply routing policy may 1682 augment the routing policy model with protocol or other specific 1683 policy configuration. The routing policy model assumes that 1684 additional defined sets, conditions, and actions may all be added by 1685 other models. 1687 The example below provides an illustration of how another data model 1688 can augment parts of this routing policy data model. It uses 1689 specific examples from draft-ietf-idr-bgp-model-09 to show in a 1690 concrete manner how the different pieces fit together. This example 1691 is not normative with respect to [I-D.ietf-idr-bgp-model]. The model 1692 similarly augments BGP-specific conditions and actions in the 1693 corresponding sections of the routing policy model. In the example 1694 below, the XPath prefix "bp:" specifies import from the ietf-bgp- 1695 policy sub-module and the XPath prefix "bt:" specifies import from 1696 the ietf-bgp-types sub-module [I-D.ietf-idr-bgp-model]. 1698 module: ietf-routing-policy 1699 +--rw routing-policy 1700 +--rw defined-sets 1701 | +--rw prefix-sets 1702 | | +--rw prefix-set* [name] 1703 | | +--rw name string 1704 | | +--rw mode? enumeration 1705 | | +--rw prefixes 1706 | | +--rw prefix-list* [ip-prefix mask-length-lower 1707 | | mask-length-upper] 1708 | | +--rw ip-prefix inet:ip-prefix 1709 | | +--rw mask-length-lower uint8 1710 | | +--rw mask-length-upper uint8 1711 | +--rw neighbor-sets 1712 | | +--rw neighbor-set* [name] 1713 | | +--rw name string 1714 | | +--rw address* inet:ip-address 1715 | +--rw tag-sets 1716 | | +--rw tag-set* [name] 1717 | | +--rw name string 1718 | | +--rw tag-value* tag-type 1719 | +--rw bp:bgp-defined-sets 1720 | +--rw bp:community-sets 1721 | | +--rw bp:community-set* [name] 1722 | | +--rw bp:name string 1723 | | +--rw bp:member* union 1724 | +--rw bp:ext-community-sets 1725 | | +--rw bp:ext-community-set* [name] 1726 | | +--rw bp:name string 1727 | | +--rw bp:member* union 1728 | +--rw bp:as-path-sets 1729 | +--rw bp:as-path-set* [name] 1730 | +--rw bp:name string 1731 | +--rw bp:member* string 1732 +--rw policy-definitions 1733 +--rw policy-definition* [name] 1734 +--rw name string 1735 +--rw statements 1736 +--rw statement* [name] 1737 +--rw name string 1738 +--rw conditions 1739 | +--rw call-policy? 1740 | +--rw source-protocol? identityref 1741 | +--rw match-interface 1742 | | +--rw interface? 1743 | | +--rw subinterface? 1744 | +--rw match-prefix-set 1745 | | +--rw prefix-set? prefix-set/name 1746 | | +--rw match-set-options? match-set-options-type 1747 | +--rw match-neighbor-set 1748 | | +--rw neighbor-set? 1749 | +--rw match-tag-set 1750 | | +--rw tag-set? 1751 | | +--rw match-set-options? match-set-options-type 1752 | +--rw match-route-type* identityref 1753 | +--rw bp:bgp-conditions 1754 | +--rw bp:med-eq? uint32 1755 | +--rw bp:origin-eq? bt:bgp-origin-attr-type 1756 | +--rw bp:next-hop-in* inet:ip-address-no-zone 1757 | +--rw bp:afi-safi-in* identityref 1758 | +--rw bp:local-pref-eq? uint32 1759 | +--rw bp:route-type? enumeration 1760 | +--rw bp:community-count 1761 | +--rw bp:as-path-length 1762 | +--rw bp:match-community-set 1763 | | +--rw bp:community-set? 1764 | | +--rw bp:match-set-options? 1765 | +--rw bp:match-ext-community-set 1766 | | +--rw bp:ext-community-set? 1767 | | +--rw bp:match-set-options? 1768 | +--rw bp:match-as-path-set 1769 | +--rw bp:as-path-set? 1770 | +--rw bp:match-set-options? 1771 +--rw actions 1772 +--rw policy-result? policy-result-type 1773 +--rw set-metric 1774 | +--rw metric-modification? 1775 | +--rw metric? uint32 1776 +--rw set-metric-type 1777 | +--rw metric-type? identityref 1778 +--rw set-route-level 1779 | +--rw route-level? identityref 1780 +--rw set-preference? uint16 1781 +--rw set-tag? tag-type 1782 +--rw set-application-tag? tag-type 1783 +--rw bp:bgp-actions 1784 +--rw bp:set-route-origin?bt:bgp-origin-attr-type 1785 +--rw bp:set-local-pref? uint32 1786 +--rw bp:set-next-hop? bgp-next-hop-type 1787 +--rw bp:set-med? bgp-set-med-type 1788 +--rw bp:set-as-path-prepend 1789 | +--rw bp:repeat-n? uint8 1790 +--rw bp:set-community 1791 | +--rw bp:method? enumeration 1792 | +--rw bp:options? 1793 | +--rw bp:inline 1794 | | +--rw bp:communities* union 1795 | +--rw bp:reference 1796 | +--rw bp:community-set-ref? 1797 +--rw bp:set-ext-community 1798 +--rw bp:method? enumeration 1799 +--rw bp:options? 1800 +--rw bp:inline 1801 | +--rw bp:communities* union 1802 +--rw bp:reference 1803 +--rw bp:ext-community-set-ref? 1805 Appendix B. Policy examples 1807 Below we show an example of XML-encoded configuration data using the 1808 routing policy and BGP models to illustrate both how policies are 1809 defined, and also how they can be applied. Note that the XML has 1810 been simplified for readability. 1812 1813 1816 1817 1818 1819 prefix-set-A 1820 ipv4 1821 1822 1823 192.0.2.0/24 1824 24 1825 32 1826 1827 1828 198.51.100.0/24 1829 24 1830 32 1831 1832 1833 1834 1835 1836 1837 cust-tag1 1838 10 1839 1840 1841 1843 1844 1845 export-tagged-BGP 1846 1847 1848 term-0 1849 1850 1851 cust-tag1 1852 1853 1854 1855 accept-route 1856 1857 1858 1859 1860 1862 1863 1865 In the following example, all routes in the RIB that have been 1866 learned from OSPF advertisements corresponding to OSPF intra-area and 1867 inter-area route types should get advertised into ISIS level-2 1868 advertisements. 1870 1871 1873 1874 1875 export-all-OSPF-prefixes-into-ISIS-level-2 1876 1877 1878 term-0 1879 1880 ospf-internal-type 1881 1882 1883 1884 isis-level-2 1885 1886 accept-route 1887 1888 1889 1890 1891 1892 1893 1895 Authors' Addresses 1897 Yingzhen Qu 1898 Futurewei 1899 2330 Central Expressway 1900 Santa Clara CA 95050 1901 USA 1903 Email: yingzhen.qu@futurewei.com 1905 Jeff Tantsura 1906 Apstra 1908 Email: jefftant.ietf@gmail.com 1910 Acee Lindem 1911 Cisco 1912 301 Midenhall Way 1913 Cary, NC 27513 1914 US 1916 Email: acee@cisco.com 1918 Xufeng Liu 1919 Volta Networks 1921 Email: xufeng.liu.ietf@gmail.com