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