idnits 2.17.00 (12 Aug 2021) /tmp/idnits56928/draft-ietf-rtgwg-policy-model-13.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 481 has weird spacing: '...h-lower uin...' == Line 482 has weird spacing: '...h-upper uin...' == Line 1044 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 (May 30, 2020) is 721 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 (-13) 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 1, 2020 Apstra 6 A. Lindem 7 Cisco 8 X. Liu 9 Volta Networks 10 May 30, 2020 12 A YANG Data Model for Routing Policy Management 13 draft-ietf-rtgwg-policy-model-13 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 1, 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 modules . . . . . . . . . . . . . . . . . . . . . . . . 14 73 10.1. Routing policy model . . . . . . . . . . . . . . . . . . 15 74 11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 35 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 76 12.1. Normative references . . . . . . . . . . . . . . . . . . 36 77 12.2. Informative references . . . . . . . . . . . . . . . . . 38 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 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 CIDR 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-proto-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. 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 definitions in 420 the chain are evaluated. 422 If the conditions are not satisfied, then evaluation proceeds to the 423 next policy statement. If none of the policy statement conditions 424 are satisfied, then evaluation of the current policy definition 425 stops, and the next policy definition in the chain is evaluated. 426 When the end of the policy chain is reached, the default route 427 disposition action is performed (i.e., reject-route unless an 428 alternate default action is specified for the chain). 430 Note that the route's pre-policy attributes are always used for 431 testing policy statement conditions. In other words, if actions 432 modify the policy application specific attributes, those 433 modifications are not used for policy statement conditions. 435 6. Applying routing policy 437 Routing policy is applied by defining and attaching policy chains in 438 various routing contexts. Policy chains are sequences of policy 439 definitions (described in Section 4) that have an associated 440 direction (import or export) with respect to the routing context in 441 which they are defined. The routing policy model defines an apply- 442 policy grouping that can be imported and used by other models. As 443 shown below, it allows definition of import and export policy chains, 444 as well as specifying the default route disposition to be used when 445 no policy definition in the chain results in a final decision. 447 +--rw apply-policy 448 | +--rw import-policy* 449 | +--rw default-import-policy? default-policy-type 450 | +--rw export-policy* 451 | +--rw default-export-policy? default-policy-type 453 The default policy defined by the model is to reject the route for 454 both import and export policies. 456 7. Routing protocol-specific policies 458 Routing models that require the ability to apply routing policy may 459 augment the routing policy model with protocol or other specific 460 policy configuration. The routing policy model assumes that 461 additional defined sets, conditions, and actions may all be added by 462 other models. 464 An example of this is shown below, in which the BGP configuration 465 model in [I-D.ietf-idr-bgp-model] adds new defined sets to match on 466 community values or AS paths. The model similarly augments BGP- 467 specific conditions and actions in the corresponding sections of the 468 routing policy model. 470 module: ietf-routing-policy 471 +--rw routing-policy 472 +--rw defined-sets 473 | +--rw prefix-sets 474 | | +--rw prefix-set* [name] 475 | | +--rw name string 476 | | +--rw mode? enumeration 477 | | +--rw prefixes 478 | | +--rw prefix-list* [ip-prefix mask-length-lower 479 | | mask-length-upper] 480 | | +--rw ip-prefix inet:ip-prefix 481 | | +--rw mask-length-lower uint8 482 | | +--rw mask-length-upper uint8 483 | +--rw neighbor-sets 484 | | +--rw neighbor-set* [name] 485 | | +--rw name string 486 | | +--rw address* inet:ip-address 487 | +--rw tag-sets 488 | | +--rw tag-set* [name] 489 | | +--rw name string 490 | | +--rw tag-value* tag-type 491 | +--rw bp:bgp-defined-sets 492 | +--rw bp:community-sets 493 | | +--rw bp:community-set* [name] 494 | | +--rw bp:name string 495 | | +--rw bp:member* union 496 | +--rw bp:ext-community-sets 497 | | +--rw bp:ext-community-set* [name] 498 | | +--rw bp:name string 499 | | +--rw bp:member* union 500 | +--rw bp:as-path-sets 501 | +--rw bp:as-path-set* [name] 502 | +--rw bp:name string 503 | +--rw bp:member* string 504 +--rw policy-definitions 505 +--rw policy-definition* [name] 506 +--rw name string 507 +--rw statements 508 +--rw statement* [name] 509 +--rw name string 510 +--rw conditions 511 | +--rw call-policy? 512 | +--rw source-protocol? identityref 513 | +--rw match-interface 514 | | +--rw interface? 515 | | +--rw subinterface? 516 | +--rw match-prefix-set 517 | | +--rw prefix-set? prefix-set/name 518 | | +--rw match-set-options? match-set-options-type 519 | +--rw match-neighbor-set 520 | | +--rw neighbor-set? 521 | +--rw match-tag-set 522 | | +--rw tag-set? 523 | | +--rw match-set-options? match-set-options-type 524 | +--rw match-proto-route-type* identityref 525 | +--rw bp:bgp-conditions 526 | +--rw bp:med-eq? uint32 527 | +--rw bp:origin-eq? bt:bgp-origin-attr-type 528 | +--rw bp:next-hop-in* inet:ip-address-no-zone 529 | +--rw bp:afi-safi-in* identityref 530 | +--rw bp:local-pref-eq? uint32 531 | +--rw bp:route-type? enumeration 532 | +--rw bp:community-count 533 | +--rw bp:as-path-length 534 | +--rw bp:match-community-set 535 | | +--rw bp:community-set? 536 | | +--rw bp:match-set-options? 537 | +--rw bp:match-ext-community-set 538 | | +--rw bp:ext-community-set? 539 | | +--rw bp:match-set-options? 540 | +--rw bp:match-as-path-set 541 | +--rw bp:as-path-set? 542 | +--rw bp:match-set-options? 543 +--rw actions 544 +--rw policy-result? policy-result-type 545 +--rw set-metric 546 | +--rw metric-modification? 547 | +--rw metric? uint32 548 +--rw set-metric-type 549 | +--rw metric-type? identityref 550 +--rw set-import-level 551 | +--rw import-level? identityref 552 +--rw set-preference? uint16 553 +--rw set-tag? tag-type 554 +--rw set-application-tag? tag-type 555 +--rw bp:bgp-actions 556 +--rw bp:set-route-origin?bt:bgp-origin-attr-type 557 +--rw bp:set-local-pref? uint32 558 +--rw bp:set-next-hop? bgp-next-hop-type 559 +--rw bp:set-med? bgp-set-med-type 560 +--rw bp:set-as-path-prepend 561 | +--rw bp:repeat-n? uint8 562 +--rw bp:set-community 563 | +--rw bp:method? enumeration 564 | +--rw bp:options? 565 | +--rw bp:inline 566 | | +--rw bp:communities* union 567 | +--rw bp:reference 568 | +--rw bp:community-set-ref? 569 +--rw bp:set-ext-community 570 +--rw bp:method? enumeration 571 +--rw bp:options? 572 +--rw bp:inline 573 | +--rw bp:communities* union 574 +--rw bp:reference 575 +--rw bp:ext-community-set-ref? 577 8. Security Considerations 579 The YANG modules specified in this document define a schema for data 580 that is designed to be accessed via network management protocols such 581 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 582 is the secure transport layer, and the mandatory-to-implement secure 583 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 584 is HTTPS, and the mandatory-to-implement secure transport is TLS 585 [RFC8446]. 587 The NETCONF Access Control Model (NACM) [RFC8341] provides the means 588 to restrict access for particular NETCONF or RESTCONF users to a pre- 589 configured subset of all available NETCONF or RESTCONF protocol 590 operations and content. 592 There are a number of data nodes defined in this YANG module that are 593 writable/creatable/deletable (i.e., config true, which is the 594 default). These data nodes may be considered sensitive or vulnerable 595 in some network environments. Write operations (e.g., edit-config) 596 to these data nodes without proper protection can have a negative 597 effect on network operations. These are the subtrees and data nodes 598 and their sensitivity/vulnerability: 600 /routing-policy 602 /routing-policy/defined-sets/prefix-sets 604 /routing-policy/defined-sets/neighbor-sets 606 /routing-policy/defined-sets/tag-sets 608 /routing-policy/policy-definitions 610 Unauthorized access to any data node of these subtrees can disclose 611 the operational state information of routing policies on this device. 613 Routing policy configuration has a significant impact on network 614 operations, and, as such, any related model carries potential 615 security risks. Unauthorized access or invalid data could cause 616 major disruption. 618 9. IANA Considerations 620 This document registers a URI in the IETF XML registry [RFC3688]. 621 Following the format in [RFC3688], the following registration is 622 requested to be made: 624 URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy 625 Registrant Contact: The IESG. 626 XML: N/A, the requested URI is an XML namespace. 628 This document registers a YANG module in the YANG Module Names 629 registry [RFC6020]. 631 name: ietf-routing-policy 632 namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy 633 prefix: rt-pol 634 reference: RFC XXXX 636 10. YANG modules 638 The routing policy model is described by the YANG modules in the 639 sections below. 641 10.1. Routing policy model 643 file "ietf-routing-policy@2020-05-26.yang" 644 module ietf-routing-policy { 646 yang-version "1.1"; 648 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; 649 prefix rt-pol; 651 import ietf-inet-types { 652 prefix "inet"; 653 reference "RFC 6991: Common YANG Data Types"; 654 } 656 import ietf-yang-types { 657 prefix "yang"; 658 reference "RFC 6991: Common YANG Data Types"; 659 } 661 import ietf-interfaces { 662 prefix "if"; 663 reference "RFC 8343: A YANG Data Model for Interface 664 Management (NMDA Version)"; 665 } 667 import ietf-routing { 668 prefix "rt"; 669 reference "RFC 8349: A YANG Data Model for Routing 670 Management (NMDA Version)"; 671 } 673 import ietf-if-extensions { 674 prefix "if-ext"; 675 reference "RFC YYYY: Common Interface Extension YANG 676 Data Models. Please replace YYYY with 677 published RFC number for 678 draft-ietf-netmod-intf-ext-yang."; 679 } 681 import ietf-if-l3-vlan { 682 prefix "if-l3-vlan"; 683 reference "RFC XXXX: Sub-interface VLAN YANG Data Models. 684 Please replace XXXX with published RFC number 685 for draft-ietf-netmod-sub-intf-vlan-model."; 686 } 688 organization 689 "IETF RTGWG - Routing Area Working Group"; 690 contact 691 "WG Web: 692 WG List: 694 Editor: Yingzhen Qu 695 696 Jeff Tantsura 697 698 Acee Lindem 699 700 Xufeng Liu 701 "; 703 description 704 "This module describes a YANG model for routing policy 705 configuration. It is a limited subset of all of the policy 706 configuration parameters available in the variety of vendor 707 implementations, but supports widely used constructs for 708 managing how routes are imported, exported, modified and 709 advertised across different routing protocol instances or 710 within a single routing protocol instance. This module is 711 intended to be used in conjunction with routing protocol 712 configuration modules (e.g., BGP) defined in other models. 714 Route policy expression: 716 Policies are expressed as a set of top-level policy 717 definitions, each of which consists of a sequence of policy 718 statements. Policy statements consist of simple 719 condition-action tuples. Conditions may include multiple match 720 or comparison operations, and similarly actions may be 721 multitude of changes to route attributes or a final 722 disposition of accepting or rejecting the route. 724 Route policy evaluation: 726 Policy definitions are referenced in routing protocol 727 configurations using import and export configuration 728 statements. The arguments are members of an ordered list of 729 named policy definitions which comprise a policy chain, and 730 optionally, an explicit default policy action (i.e., reject 731 or accept). 733 Evaluation of each policy definition proceeds by evaluating 734 its corresponding individual policy statements in order. When 735 a condition statement in a policy statement is satisfied, the 736 corresponding action statement is executed. If the action 737 statement has either accept-route or reject-route actions, 738 policy evaluation of the current policy definition stops, and 739 no further policy definitions in the chain are evaluated. 741 If the condition is not satisfied, then evaluation proceeds to 742 the next policy statement. If none of the policy statement 743 conditions are satisfied, then evaluation of the current 744 policy definition stops, and the next policy definition in the 745 chain is evaluated. When the end of the policy chain is 746 reached, the default route disposition action is performed 747 (i.e., reject-route unless an alternate default action is 748 specified for the chain). 750 Policy 'subroutines' (or nested policies) are supported by 751 allowing policy statement conditions to reference another 752 policy definition which applies conditions and actions from 753 the referenced policy before returning to the calling policy 754 statement and resuming evaluation. If the called policy 755 results in an accept-route (either explicit or by default), 756 then the subroutine returns an effective true value to the 757 calling policy. Similarly, a reject-route action returns 758 false. If the subroutine returns true, the calling policy 759 continues to evaluate the remaining conditions (using a 760 modified route if the subroutine performed any changes to the 761 route). 763 Copyright (c) 2020 IETF Trust and the persons identified as 764 authors of the code. All rights reserved. 766 Redistribution and use in source and binary forms, with or 767 without modification, is permitted pursuant to, and subject to 768 the license terms contained in, the Simplified BSD License set 769 forth in Section 4.c of the IETF Trust's Legal Provisions 770 Relating to IETF Documents 771 (https://trustee.ietf.org/license-info). 773 This version of this YANG module is part of RFC XXXX 774 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 775 for full legal notices. 777 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 778 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT 779 RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 780 interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, 781 and only when, they appear in all capitals, as shown here. 783 This version of this YANG module is part of RFC XXXX; 784 see the RFC itself for full legal notices."; 786 revision "2020-05-26" { 787 description 788 "Initial revision."; 789 reference 790 "RFC XXXX: Routing Policy Configuration Model for Service 791 Provider Networks"; 792 } 794 /* Identities */ 796 identity metric-type { 797 description 798 "Base identity for route metric types."; 799 } 801 identity ospf-type-1-metric { 802 base metric-type; 803 description 804 "Identity for the OSPF type 1 external metric types. It 805 is only applicable to OSPF routes."; 806 } 808 identity ospf-type-2-metric { 809 base metric-type; 810 description 811 "Identity for the OSPF type 2 external metric types. It 812 is only applicable to OSPF routes."; 813 } 815 identity isis-internal-metric { 816 base metric-type; 817 description 818 "Identity for the IS-IS internal metric types. It is only 819 applicable to IS-IS routes."; 820 } 822 identity isis-external-metric { 823 base metric-type; 824 description 825 "Identity for the IS-IS external metric types. It is only 826 applicable to IS-IS routes."; 827 } 829 identity import-level { 830 description 831 "Base identity for route import level."; 832 } 833 identity ospf-normal { 834 base import-level; 835 description 836 "Identity for OSPF importation into normal areas 837 It is only applicable to routes imported 838 into the OSPF protocol."; 839 } 841 identity ospf-nssa-only { 842 base import-level; 843 description 844 "Identity for the OSPF NSSA area importation. It is only 845 applicable to routes imported into the OSPF protocol."; 846 } 848 identity ospf-normal-nssa { 849 base import-level; 850 description 851 "Identity for OSPF importation into both normal and NSSA 852 areas, it is only applicable to routes imported into 853 the OSPF protocol."; 854 } 856 identity isis-level-1 { 857 base import-level; 858 description 859 "Identity for IS-IS Level 1 area importation. It is only 860 applicable to routes imported into the IS-IS protocol."; 861 } 863 identity isis-level-2 { 864 base import-level; 865 description 866 "Identity for IS-IS Level 2 area importation. It is only 867 applicable to routes imported into the IS-IS protocol."; 868 } 870 identity isis-level-1-2 { 871 base import-level; 872 description 873 "Identity for IS-IS Level 1 and Level 2 area importation. It 874 is only applicable to routes imported into the IS-IS 875 protocol."; 876 } 878 identity proto-route-type { 879 description 880 "Base identity for route type within a protocol."; 882 } 884 identity isis-level-1-type { 885 base proto-route-type; 886 description 887 "Identity for IS-IS Level 1 route type. It is only 888 applicable to IS-IS routes."; 889 } 891 identity isis-level-2-type { 892 base proto-route-type; 893 description 894 "Identity for IS-IS Level 2 route type. It is only 895 applicable to IS-IS routes."; 896 } 898 identity ospf-internal-type { 899 base proto-route-type; 900 description 901 "Identity for OSPF intra-area or inter-area route type. 902 It is only applicable to OSPF routes."; 903 } 905 identity ospf-external-type { 906 base proto-route-type; 907 description 908 "Identity for OSPF external type 1/2 route type. 909 It is only applicable to OSPF routes."; 910 } 912 identity ospf-external-t1 { 913 base ospf-external-type; 914 description 915 "Identity for OSPF external type 1 route type. 916 It is only applicable to OSPF routes."; 917 } 919 identity ospf-external-t2-type { 920 base ospf-external-type; 921 description 922 "Identity for OSPF external type 2 route type. 923 It is only applicable to OSPF routes."; 924 } 926 identity ospf-nssa-type { 927 base proto-route-type; 928 description 929 "Identity for OSPF NSSA type 1/2 route type. 931 It is only applicable to OSPF routes."; 932 } 934 identity ospf-nssa-t1 { 935 base ospf-nssa-type; 936 description 937 "Identity for OSPF NSSA type 1 route type. 938 It is only applicable to OSPF routes."; 939 } 941 identity ospf-nssa-t2 { 942 base ospf-nssa-type; 943 description 944 "Identity for OSPF NSSA type 2 route type. 945 It is only applicable to OSPF routes."; 946 } 948 identity bgp-local { 949 base proto-route-type; 950 description 951 "Identity for BGP local route type. 952 It is only applicable to BGP routes."; 953 } 955 identity bgp-external { 956 base proto-route-type; 957 description 958 "Identity for BGP external route type. 959 It is only applicable to BGP routes."; 960 } 962 /* Type Definitions */ 964 typedef default-policy-type { 965 type enumeration { 966 enum accept-route { 967 description 968 "Default policy to accept the route."; 969 } 970 enum reject-route { 971 description 972 "Default policy to reject the route."; 973 } 974 } 975 description 976 "Type used to specify route disposition in 977 a policy chain. This typedef retained for 978 name compatibility with default import and 979 export policy."; 980 } 982 typedef policy-result-type { 983 type enumeration { 984 enum accept-route { 985 description 986 "Policy accepts the route."; 987 } 988 enum reject-route { 989 description 990 "Policy rejects the route."; 991 } 992 } 993 description 994 "Type used to specify route disposition in 995 a policy chain."; 996 } 998 typedef tag-type { 999 type union { 1000 type uint32; 1001 type yang:hex-string; 1002 } 1003 description 1004 "Type for expressing route tags on a local system, 1005 including IS-IS and OSPF; may be expressed as either decimal 1006 or hexadecimal integer."; 1007 reference 1008 "RFC 2178 - OSPF Version 2 1009 RFC 5130 - A Policy Control Mechanism in IS-IS Using 1010 Administrative Tags"; 1011 } 1013 typedef match-set-options-type { 1014 type enumeration { 1015 enum any { 1016 description 1017 "Match is true if given value matches any member 1018 of the defined set."; 1019 } 1020 enum all { 1021 description 1022 "Match is true if given value matches all 1023 members of the defined set."; 1024 } 1025 enum invert { 1026 description 1027 "Match is true if given value does not match any 1028 member of the defined set."; 1029 } 1030 } 1031 default any; 1032 description 1033 "Options that govern the behavior of a match statement. The 1034 default behavior is any, i.e., the given value matches any 1035 of the members of the defined set."; 1036 } 1038 typedef metric-modification-type { 1039 type enumeration { 1040 enum set-metric { 1041 description 1042 "Set the metric to the specified value."; 1043 } 1044 enum add-metric { 1045 description 1046 "Add the specified value to the existing metric. 1047 If the result would exceed the maximum metric 1048 (0xffffffff), set the metric to the maximum."; 1049 } 1050 enum subtract-metric { 1051 description 1052 "Subtract the specified value to the existing metric. If 1053 the result would be less than 0, set the metric to 0."; 1054 } 1055 } 1056 description 1057 "Type used to specify how to set the metric given the 1058 specified value."; 1059 } 1061 /* Groupings */ 1063 grouping prefix { 1064 description 1065 "Configuration data for a prefix definition."; 1067 leaf ip-prefix { 1068 type inet:ip-prefix; 1069 mandatory true; 1070 description 1071 "The prefix member in CIDR notation -- while the 1072 prefix may be either IPv4 or IPv6, most 1073 implementations require all members of the prefix set 1074 to be the same address family. Mixing address types in 1075 the same prefix set is likely to cause an error."; 1076 } 1078 leaf mask-length-lower { 1079 type uint8; 1080 description 1081 "Mask length range lower bound."; 1082 } 1083 leaf mask-length-upper { 1084 type uint8 { 1085 range "1..128"; 1086 } 1087 must "../mask-length-upper >= ../mask-length-lower" { 1088 error-message "The upper bound should not be less" 1089 + "than lower bound."; 1090 } 1091 description 1092 "Mask length range upper bound. 1094 The combination of mask-length-lower and mask-length-upper 1095 define a range for the mask length, or single 'exact' 1096 length if mask-length-lower and mask-length-upper are 1097 equal. 1099 Example: 192.0.2.0/24 through 192.0.2.0/26 would be 1100 expressed as prefix: 192.0.2.0/24, 1101 mask-length-lower=24, 1102 mask-length-upper=26 1104 Example: 192.0.2.0/24 (an exact match) would be 1105 expressed as prefix: 192.0.2.0/24, 1106 mask-length-lower=24, 1107 mask-length-upper=24"; 1108 } 1109 } 1111 grouping match-set-options-group { 1112 description 1113 "Grouping containing options relating to how a particular set 1114 should be matched."; 1116 leaf match-set-options { 1117 type match-set-options-type; 1118 description 1119 "Optional parameter that governs the behavior of the 1120 match operation."; 1121 } 1122 } 1123 grouping match-set-options-restricted-group { 1124 description 1125 "Grouping for a restricted set of match operation 1126 modifiers."; 1128 leaf match-set-options { 1129 type match-set-options-type { 1130 enum any { 1131 description 1132 "Match is true if given value matches any 1133 member of the defined set."; 1134 } 1135 enum invert { 1136 description 1137 "Match is true if given value does not match 1138 any member of the defined set."; 1139 } 1140 } 1141 description 1142 "Optional parameter that governs the behavior of the 1143 match operation. This leaf only supports matching on 1144 'any' member of the set or 'invert' the match. 1145 Matching on 'all' is not supported."; 1146 } 1147 } 1149 grouping match-interface-condition { 1150 description 1151 "This grouping provides interface match condition."; 1153 container match-interface { 1154 leaf interface { 1155 type leafref { 1156 path "/if:interfaces/if:interface/if:name"; 1157 } 1158 description 1159 "Reference to a base interface. If a reference to a 1160 subinterface is required, this leaf must be specified 1161 to indicate the base interface."; 1162 } 1163 leaf subinterface { 1164 type leafref { 1165 path "/if:interfaces/if:interface/if-ext:encapsulation" 1166 + "/if-l3-vlan:dot1q-vlan" 1167 + "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id"; 1168 } 1169 description 1170 "Reference to a subinterface -- this requires the base 1171 interface to be specified using the interface leaf in 1172 this container. If only a reference to a base interface 1173 is required, this leaf should not be set."; 1174 } 1176 description 1177 "Container for interface match conditions"; 1178 } 1179 } 1181 grouping match-proto-route-type-condition { 1182 description 1183 "This grouping provides route-type match condition"; 1185 leaf-list match-proto-route-type { 1186 type identityref { 1187 base proto-route-type; 1188 } 1189 description 1190 "Condition to check the protocol specific type 1191 of route. This is normally used during route 1192 importation to select routes or to set protocol 1193 specific attributes based on the route type."; 1194 } 1195 } 1197 grouping prefix-set-condition { 1198 description 1199 "This grouping provides prefix-set conditions."; 1201 container match-prefix-set { 1202 leaf prefix-set { 1203 type leafref { 1204 path "../../../../../../../defined-sets/" + 1205 "prefix-sets/prefix-set/name"; 1206 } 1207 description 1208 "References a defined prefix set."; 1209 } 1210 uses match-set-options-restricted-group; 1212 description 1213 "Match a referenced prefix-set according to the logic 1214 defined in the match-set-options leaf."; 1215 } 1216 } 1218 grouping neighbor-set-condition { 1219 description 1220 "This grouping provides neighbor-set conditions."; 1222 container match-neighbor-set { 1223 leaf neighbor-set { 1224 type leafref { 1225 path "../../../../../../../defined-sets/neighbor-sets/" + 1226 "neighbor-set/name"; 1227 require-instance true; 1228 } 1229 description 1230 "References a defined neighbor set."; 1231 } 1233 description 1234 "Match a referenced neighbor set according to the logic 1235 defined in the match-set-options-leaf."; 1236 } 1237 } 1239 grouping tag-set-condition { 1240 description 1241 "This grouping provides tag-set conditions."; 1243 container match-tag-set { 1244 leaf tag-set { 1245 type leafref { 1246 path "../../../../../../../defined-sets/tag-sets" + 1247 "/tag-set/name"; 1248 require-instance true; 1249 } 1250 description 1251 "References a defined tag set."; 1252 } 1253 uses match-set-options-restricted-group; 1255 description 1256 "Match a referenced tag set according to the logic defined 1257 in the match-options-set leaf."; 1258 } 1259 } 1261 grouping apply-policy-import { 1262 description 1263 "Grouping for applying import policies."; 1265 leaf-list import-policy { 1266 type leafref { 1267 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1268 "rt-pol:policy-definition/rt-pol:name"; 1269 require-instance true; 1270 } 1271 ordered-by user; 1272 description 1273 "List of policy names in sequence to be applied on 1274 receiving a routing update in the current context, e.g., 1275 for the current peer group, neighbor, address family, 1276 etc."; 1277 } 1279 leaf default-import-policy { 1280 type default-policy-type; 1281 default reject-route; 1282 description 1283 "Explicitly set a default policy if no policy definition 1284 in the import policy chain is satisfied."; 1285 } 1287 } 1289 grouping apply-policy-export { 1290 description 1291 "Grouping for applying export policies."; 1293 leaf-list export-policy { 1294 type leafref { 1295 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1296 "rt-pol:policy-definition/rt-pol:name"; 1297 require-instance true; 1298 } 1299 ordered-by user; 1300 description 1301 "List of policy names in sequence to be applied on 1302 sending a routing update in the current context, e.g., 1303 for the current peer group, neighbor, address family, 1304 etc."; 1305 } 1307 leaf default-export-policy { 1308 type default-policy-type; 1309 default reject-route; 1310 description 1311 "Explicitly set a default policy if no policy definition 1312 in the export policy chain is satisfied."; 1313 } 1314 } 1315 grouping apply-policy-group { 1316 description 1317 "Top level container for routing policy applications. This 1318 grouping is intended to be used in routing models where 1319 needed."; 1321 container apply-policy { 1322 description 1323 "Anchor point for routing policies in the model. 1324 Import and export policies are with respect to the local 1325 routing table, i.e., export (send) and import (receive), 1326 depending on the context."; 1328 uses apply-policy-import; 1329 uses apply-policy-export; 1331 } 1332 } 1334 container routing-policy { 1335 description 1336 "Top-level container for all routing policy."; 1338 container defined-sets { 1339 description 1340 "Predefined sets of attributes used in policy match 1341 statements."; 1343 container prefix-sets { 1344 description 1345 "Data definitions for a list of IPv4 or IPv6 1346 prefixes which are matched as part of a policy."; 1347 list prefix-set { 1348 key "name"; 1349 description 1350 "List of the defined prefix sets"; 1352 leaf name { 1353 type string; 1354 description 1355 "Name of the prefix set -- this is used as a label to 1356 reference the set in match conditions."; 1357 } 1359 leaf mode { 1360 type enumeration { 1361 enum ipv4 { 1362 description 1363 "Prefix set contains IPv4 prefixes only."; 1364 } 1365 enum ipv6 { 1366 description 1367 "Prefix set contains IPv6 prefixes only."; 1368 } 1369 enum mixed { 1370 description 1371 "Prefix set contains mixed IPv4 and IPv6 1372 prefixes."; 1373 } 1374 } 1375 description 1376 "Indicates the mode of the prefix set, in terms of 1377 which address families (IPv4, IPv6, or both) are 1378 present. The mode provides a hint, but the device 1379 must validate that all prefixes are of the indicated 1380 type, and is expected to reject the configuration if 1381 there is a discrepancy. The MIXED mode may not be 1382 supported on devices that require prefix sets to be 1383 of only one address family."; 1384 } 1386 container prefixes { 1387 description 1388 "Container for the list of prefixes in a policy 1389 prefix list."; 1391 list prefix-list { 1392 key "ip-prefix mask-length-lower mask-length-upper"; 1393 description 1394 "List of prefixes in the prefix set."; 1396 uses prefix; 1397 } 1398 } 1399 } 1400 } 1402 container neighbor-sets { 1403 description 1404 "Data definition for a list of IPv4 or IPv6 1405 neighbors which can be matched in a routing policy."; 1407 list neighbor-set { 1408 key "name"; 1409 description 1410 "List of defined neighbor sets for use in policies."; 1412 leaf name { 1413 type string; 1414 description 1415 "Name of the neighbor set -- this is used as a label 1416 to reference the set in match conditions."; 1417 } 1419 leaf-list address { 1420 type inet:ip-address; 1421 description 1422 "List of IP addresses in the neighbor set."; 1423 } 1424 } 1425 } 1427 container tag-sets { 1428 description 1429 "Data definitions for a list of tags which can 1430 be matched in policies."; 1432 list tag-set { 1433 key "name"; 1434 description 1435 "List of tag set definitions."; 1437 leaf name { 1438 type string; 1439 description 1440 "Name of the tag set -- this is used as a label to 1441 reference the set in match conditions."; 1442 } 1444 leaf-list tag-value { 1445 type tag-type; 1446 description 1447 "Value of the tag set member."; 1448 } 1449 } 1450 } 1451 } 1453 container policy-definitions { 1454 description 1455 "Enclosing container for the list of top-level policy 1456 definitions."; 1458 list policy-definition { 1459 key "name"; 1460 description 1461 "List of top-level policy definitions, keyed by unique 1462 name. These policy definitions are expected to be 1463 referenced (by name) in policy chains specified in 1464 import or export configuration statements."; 1466 leaf name { 1467 type string; 1468 description 1469 "Name of the top-level policy definition -- this name 1470 is used in references to the current policy."; 1471 } 1473 container statements { 1474 description 1475 "Enclosing container for policy statements."; 1477 list statement { 1478 key "name"; 1479 ordered-by user; 1480 description 1481 "Policy statements group conditions and actions 1482 within a policy definition. They are evaluated in 1483 the order specified (see the description of policy 1484 evaluation at the top of this module."; 1486 leaf name { 1487 type string; 1488 description 1489 "Name of the policy statement."; 1490 } 1492 container conditions { 1493 description 1494 "Condition statements for the current policy 1495 statement."; 1497 leaf call-policy { 1498 type leafref { 1499 path "../../../../../../" + 1500 "rt-pol:policy-definitions/" + 1501 "rt-pol:policy-definition/rt-pol:name"; 1502 require-instance true; 1503 } 1504 description 1505 "Applies the statements from the specified policy 1506 definition and then returns control the current 1507 policy statement. Note that the called policy 1508 may itself call other policies (subject to 1509 implementation limitations). This is intended to 1510 provide a policy 'subroutine' capability. The 1511 called policy should contain an explicit or a 1512 default route disposition that returns an 1513 effective true (accept-route) or false 1514 (reject-route), otherwise the behavior may be 1515 ambiguous and implementation dependent."; 1516 } 1518 leaf source-protocol { 1519 type identityref { 1520 base rt:control-plane-protocol; 1521 } 1522 description 1523 "Condition to check the protocol / method used to 1524 install the route into the local routing table."; 1525 } 1527 uses match-interface-condition; 1528 uses prefix-set-condition; 1529 uses neighbor-set-condition; 1530 uses tag-set-condition; 1531 uses match-proto-route-type-condition; 1532 } 1534 container actions { 1535 description 1536 "Top-level container for policy action 1537 statements."; 1538 leaf policy-result { 1539 type policy-result-type; 1540 description 1541 "Select the final disposition for the route, 1542 either accept or reject."; 1543 } 1544 container set-metric { 1545 leaf metric-modification { 1546 type metric-modification-type; 1547 description 1548 "Indicates how to modify the metric."; 1549 } 1550 leaf metric { 1551 type uint32; 1552 description 1553 "Metric value to set, add, or subtract."; 1554 } 1555 description 1556 "Set the metric for the route."; 1557 } 1558 container set-metric-type { 1559 leaf metric-type { 1560 type identityref { 1561 base metric-type; 1562 } 1563 description 1564 "Route metric type."; 1565 } 1566 description 1567 "Set the metric type for the route."; 1568 } 1569 container set-import-level { 1570 leaf import-level { 1571 type identityref { 1572 base import-level; 1573 } 1574 description 1575 "Route importation level."; 1576 } 1577 description 1578 "Set the import level for importation of 1579 routes."; 1580 } 1581 leaf set-preference { 1582 type uint16; 1583 description 1584 "Set the preference for the route."; 1585 } 1586 leaf set-tag { 1587 type tag-type; 1588 description 1589 "Set the tag for the route."; 1590 } 1591 leaf set-application-tag { 1592 type tag-type; 1593 description 1594 "Set the application tag for the route."; 1595 } 1596 } 1597 } 1598 } 1599 } 1600 } 1601 } 1602 } 1603 1605 11. Policy examples 1607 Below we show an example of XML-encoded configuration data using the 1608 routing policy and BGP models to illustrate both how policies are 1609 defined, and also how they can be applied. Note that the XML has 1610 been simplified for readability. 1612 1613 1616 1617 1618 1619 prefix-set-A 1620 1621 1622 192.0.2.0/24 1623 24 1624 32 1625 1626 1627 10.0.0.0/16 1628 16 1629 32 1630 1631 1632 1633 1634 1635 1636 cust-tag1 1637 10 1638 1639 1640 1642 1643 1644 export-tagged-BGP 1645 1646 1647 term-0 1648 1649 1650 cust-tag1 1651 1652 1653 1654 accept-route 1655 1656 1657 1658 1659 1661 1662 1664 12. References 1666 12.1. Normative references 1668 [INTF-EXT-YANG] 1669 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1670 Sivaraj,, "Common Interface Extension YANG Data Models", 1671 2019, . 1674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1675 Requirement Levels", BCP 14, RFC 2119, 1676 DOI 10.17487/RFC2119, March 1997, 1677 . 1679 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1680 DOI 10.17487/RFC3688, January 2004, 1681 . 1683 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1684 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1685 DOI 10.17487/RFC4271, January 2006, 1686 . 1688 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1689 the Network Configuration Protocol (NETCONF)", RFC 6020, 1690 DOI 10.17487/RFC6020, October 2010, 1691 . 1693 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1694 and A. Bierman, Ed., "Network Configuration Protocol 1695 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1696 . 1698 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1699 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1700 . 1702 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1703 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1704 . 1706 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1707 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1708 . 1710 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1711 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1712 . 1714 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1715 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1716 May 2017, . 1718 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1719 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1720 . 1722 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1723 Access Control Model", STD 91, RFC 8341, 1724 DOI 10.17487/RFC8341, March 2018, 1725 . 1727 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1728 and R. Wilton, "Network Management Datastore Architecture 1729 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1730 . 1732 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1733 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1734 . 1736 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1737 Routing Management (NMDA Version)", RFC 8349, 1738 DOI 10.17487/RFC8349, March 2018, 1739 . 1741 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1742 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1743 . 1745 [SUB-INTF-VLAN-YANG] 1746 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1747 Sivaraj, "Sub-interface VLAN YANG Data Model", 2019, 1748 . 1751 12.2. Informative references 1753 [I-D.ietf-idr-bgp-model] 1754 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1755 YANG Model for Service Provider Networks", draft-ietf-idr- 1756 bgp-model-08 (work in progress), February 2020. 1758 Appendix A. Acknowledgements 1760 The routing policy module defined in this draft is based on the 1761 OpenConfig route policy model. The authors would like to thank to 1762 OpenConfig for their contributions, especially Anees Shaikh, Rob 1763 Shakir, Kevin D'Souza, and Chris Chase. 1765 The authors are grateful for valuable contributions to this document 1766 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1767 George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, 1768 Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and 1769 John Heasley. 1771 Thanks to Mahesh Jethanandani for valuable comments. 1773 Authors' Addresses 1775 Yingzhen Qu 1776 Futurewei 1777 2330 Central Expressway 1778 Santa Clara CA 95050 1779 USA 1781 Email: yingzhen.qu@futurewei.com 1783 Jeff Tantsura 1784 Apstra 1786 Email: jefftant.ietf@gmail.com 1787 Acee Lindem 1788 Cisco 1789 301 Midenhall Way 1790 Cary, NC 27513 1791 US 1793 Email: acee@cisco.com 1795 Xufeng Liu 1796 Volta Networks 1798 Email: xufeng.liu.ietf@gmail.com