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