idnits 2.17.00 (12 Aug 2021) /tmp/idnits47737/draft-ietf-rtgwg-policy-model-11.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 277 has weird spacing: '...h-lower uin...' == Line 278 has weird spacing: '...h-upper uin...' == Line 477 has weird spacing: '...h-lower uin...' == Line 478 has weird spacing: '...h-upper uin...' == Line 1039 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 26, 2020) is 725 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'INTF-EXT-YANG' -- Possible downref: Non-RFC (?) normative reference: ref. 'SUB-INTF-VLAN-YANG' == Outdated reference: A later version (-13) exists of draft-ietf-idr-bgp-model-08 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Y. Qu 3 Internet-Draft Futurewei 4 Intended status: Standards Track J. Tantsura 5 Expires: November 27, 2020 Apstra 6 A. Lindem 7 Cisco 8 X. Liu 9 Volta Networks 10 May 26, 2020 12 A YANG Data Model for Routing Policy Management 13 draft-ietf-rtgwg-policy-model-11 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 November 27, 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 affect 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 The following terms are defined in [RFC8342]: 132 o client 134 o server 136 o configuration 138 o system state 140 o operational state 141 o intended configuration 143 The following terms are defined in [RFC7950]: 145 o action 147 o augment 149 o container 151 o container with presence 153 o data model 155 o data node 157 o feature 159 o leaf 161 o list 163 o mandatory node 165 o module 167 o schema tree 169 o RPC (Remote Procedure Call) operation 171 2.1. Tree Diagrams 173 Tree diagrams used in this document follow the notation defined in 174 [RFC8340]. 176 2.2. Prefixes in Data Node Names 178 In this document, names of data nodes, actions, and other data model 179 objects are often used without a prefix, as long as it is clear from 180 the context in which YANG module each name is defined. Otherwise, 181 names are prefixed using the standard prefix associated with the 182 corresponding YANG module, as shown in Table 1. 184 +------------+--------------------+----------------------+ 185 | Prefix | YANG module | Reference | 186 +------------+--------------------+----------------------+ 187 | if | ietf-interfaces | [RFC8343] | 188 | | | | 189 | rt | ietf-routing | [RFC8349] | 190 | | | | 191 | yang | ietf-yang-types | [RFC6991] | 192 | | | | 193 | inet | ietf-inet-types | [RFC6991] | 194 | | | | 195 | if-ext | ietf-if-extensions | [INTF-EXT-YANG] | 196 | | | | 197 | if-l3-vlan | ietf-if-l3-vlan | [SUB-INTF-VLAN-YANG] | 198 +------------+--------------------+----------------------+ 200 Table 1: Prefixes and Corresponding YANG Modules 202 3. Model overview 204 The routing policy module has three main parts: 206 o A generic framework to express policies as sets of related 207 conditions and actions. This includes match sets and actions that 208 are useful across many routing protocols. 210 o A structure that allows routing protocol models to add protocol- 211 specific policy conditions and actions though YANG augmentations. 212 There is a complete example of this for BGP [RFC4271] policies in 213 the proposed vendor-neutral BGP data model 214 [I-D.ietf-idr-bgp-model]. 216 o A reusable grouping for attaching import and export rules in the 217 context of routing configuration for different protocols, VRFs, 218 etc. This also enables creation of policy chains and expressing 219 default policy behavior. 221 The module makes use of the standard Internet types, such as IP 222 addresses, autonomous system numbers, etc., defined in RFC 6991 223 [RFC6991]. 225 4. Route policy expression 227 Policies are expressed as a sequence of top-level policy definitions 228 each of which consists of a sequence of policy statements. Policy 229 statements in turn consist of simple condition-action tuples. 230 Conditions may include multiple match or comparison operations, and 231 similarly, actions may effect multiple changes to route attributes, 232 or indicate a final disposition of accepting or rejecting the route. 233 This structure is shown below. 235 +--rw routing-policy 236 +--rw policy-definitions 237 +--rw policy-definition* [name] 238 +--rw name string 239 +--rw statements 240 +--rw statement* [name] 241 +--rw name string 242 +--rw conditions 243 | ... 244 +--rw actions 245 ... 247 4.1. Defined sets for policy matching 249 The models provides a set of generic sets that can be used for 250 matching in policy conditions. These sets are applicable for route 251 selection across multiple routing protocols. They may be further 252 augmented by protocol-specific models which have their own defined 253 sets. The supported defined sets include: 255 o prefix sets - define a set of IP prefixes, each with an associated 256 CIDR netmask range (or exact length) 258 o neighbor sets - define a set of neighboring nodes by their IP 259 addresses. These sets are used for selecting routes based on the 260 neighbors advertising the routes. 262 o tag set - define a set of generic tag values that can be used in 263 matches for filtering routes 265 The model structure for defined sets is shown below. 267 +--rw routing-policy 268 +--rw defined-sets 269 | +--rw prefix-sets 270 | | +--rw prefix-set* [name] 271 | | +--rw name string 272 | | +--rw mode? enumeration 273 | | +--rw prefixes 274 | | +--rw prefix-list* [ip-prefix mask-length-lower 275 | | mask-length-upper] 276 | | +--rw ip-prefix inet:ip-prefix 277 | | +--rw mask-length-lower uint8 278 | | +--rw mask-length-upper uint8 279 | +--rw neighbor-sets 280 | | +--rw neighbor-set* [name] 281 | | +--rw name string 282 | | +--rw address* inet:ip-address 283 | +--rw tag-sets 284 | +--rw tag-set* [name] 285 | +--rw name string 286 | +--rw tag-value* tag-type 288 4.2. Policy conditions 290 Policy statements consist of a set of conditions and actions (either 291 of which may be empty). Conditions are used to match route 292 attributes against a defined set (e.g., a prefix set), or to compare 293 attributes against a specific value. 295 Match conditions may be further modified using the match-set-options 296 configuration which allows operators to change the behavior of a 297 match. Three options are supported: 299 o ALL - match is true only if the given value matches all members of 300 the set. 302 o ANY - match is true if the given value matches any member of the 303 set. 305 o INVERT - match is true if the given value does not match any 306 member of the given set. 308 Not all options are appropriate for matching against all defined sets 309 (e.g., match ALL in a prefix set does not make sense). In the model, 310 a restricted set of match options is used where applicable. 312 Comparison conditions may similarly use options to change how route 313 attributes should be tested, e.g., for equality or inequality, 314 against a given value. 316 While most policy conditions will be added by individual routing 317 protocol models via augmentation, this routing policy model includes 318 several generic match conditions and also the ability to test which 319 protocol or mechanism installed a route (e.g., BGP, IGP, static, 320 etc.). The conditions included in the model are shown below. 322 +--rw routing-policy 323 +--rw policy-definitions 324 +--rw policy-definition* [name] 325 +--rw name string 326 +--rw statements 327 +--rw statement* [name] 328 +--rw conditions 329 | +--rw call-policy? 330 | +--rw source-protocol? 331 | +--rw match-interface 332 | | +--rw interface? 333 | | +--rw subinterface? 334 | +--rw match-prefix-set 335 | | +--rw prefix-set? 336 | | +--rw match-set-options? 337 | +--rw match-neighbor-set 338 | | +--rw neighbor-set? 339 | +--rw match-tag-set 340 | | +--rw tag-set? 341 | | +--rw match-set-options? 342 | +--rw match-proto-route-type* identityref 344 4.3. Policy actions 346 When policy conditions are satisfied, policy actions are used to set 347 various attributes of the route being processed, or to indicate the 348 final disposition of the route, i.e., accept or reject. 350 Similar to policy conditions, the routing policy model includes 351 generic actions in addition to the basic route disposition actions. 352 These are shown below. 354 +--rw routing-policy 355 +--rw policy-definitions 356 +--rw policy-definition* [name] 357 +--rw statements 358 +--rw statement* [name] 359 +--rw actions 360 +--rw policy-result? policy-result-type 361 +--rw set-metric 362 | +--rw metric-modificatiion? 363 | | metric-modification-type 364 | +--rw metric? uint32 365 +--rw set-metric-type 366 | +--rw metric-type? identityref 367 +--rw set-import-level 368 | +--rw import-level? identityref 369 +--rw set-preference? uint16 370 +--rw set-tag? tag-type 371 +--rw set-application-tag? tag-type 373 4.4. Policy subroutines 375 Policy 'subroutines' (or nested policies) are supported by allowing 376 policy statement conditions to reference other policy definitions 377 using the call-policy configuration. Called policies apply their 378 conditions and actions before returning to the calling policy 379 statement and resuming evaluation. The outcome of the called policy 380 affects the evaluation of the calling policy. If the called policy 381 results in an accept-route, then the subroutine returns an effective 382 boolean true value to the calling policy. For the calling policy, 383 this is equivalent to a condition statement evaluating to a true 384 value and evaluation of the policy continues (see Section 5). Note 385 that the called policy may also modify attributes of the route in its 386 action statements. Similarly, a reject-route action returns false 387 and the calling policy evaluation will be affected accordingly. When 388 the end of the subroutine policy chain is reached, the default route 389 disposition action is returned (i.e., boolean false for reject-route 390 unless an alternate default action is specified for the chain). 391 Consequently, a subroutine cannot explicitly accept or reject a 392 route. Rather it merely provides an indication that 'call-policy' 393 condition returns boolean true or false indicating whether or not the 394 condition matches. Route acceptance or rejection is solely 395 determined by the top-level policy. 397 Note that the called policy may itself call other policies (subject 398 to implementation limitations). The model does not prescribe a 399 nesting depth because this varies among implementations. For 400 example, some major implementation may only support a single level of 401 subroutine recursion. As with any routing policy construction, care 402 must be taken with nested policies to ensure that the effective 403 return value results in the intended behavior. Nested policies are a 404 convenience in many routing policy constructions but creating 405 policies nested beyond a small number of levels (e.g., 2-3) should be 406 discouraged. 408 5. Policy evaluation 410 Evaluation of each policy definition proceeds by evaluating its 411 corresponding individual policy statements in order. When all the 412 condition statements in a policy statement are satisfied, the 413 corresponding action statements are executed. If the actions include 414 either accept-route or reject-route actions, evaluation of the 415 current policy definition stops, and no further policy definitions in 416 the chain are evaluated. 418 If the conditions are not satisfied, then evaluation proceeds to the 419 next policy statement. If none of the policy statement conditions 420 are satisfied, then evaluation of the current policy definition 421 stops, and the next policy definition in the chain is evaluated. 422 When the end of the policy chain is reached, the default route 423 disposition action is performed (i.e., reject-route unless an 424 alternate default action is specified for the chain). 426 Note that the route's pre-policy attributes are always used for 427 testing policy statement conditions. In other words, if actions 428 modify the policy application specific attributes, those 429 modifications are not used for policy statement conditions. 431 6. Applying routing policy 433 Routing policy is applied by defining and attaching policy chains in 434 various routing contexts. Policy chains are sequences of policy 435 definitions (described in Section 4) that have an associated 436 direction (import or export) with respect to the routing context in 437 which they are defined. The routing policy model defines an apply- 438 policy grouping that can be imported and used by other models. As 439 shown below, it allows definition of import and export policy chains, 440 as well as specifying the default route disposition to be used when 441 no policy definition in the chain results in a final decision. 443 +--rw apply-policy 444 | +--rw import-policy* 445 | +--rw default-import-policy? default-policy-type 446 | +--rw export-policy* 447 | +--rw default-export-policy? default-policy-type 449 The default policy defined by the model is to reject the route for 450 both import and export policies. 452 7. Routing protocol-specific policies 454 Routing models that require the ability to apply routing policy may 455 augment the routing policy model with protocol or other specific 456 policy configuration. The routing policy model assumes that 457 additional defined sets, conditions, and actions may all be added by 458 other models. 460 An example of this is shown below, in which the BGP configuration 461 model in [I-D.ietf-idr-bgp-model] adds new defined sets to match on 462 community values or AS paths. The model similarly augments BGP- 463 specific conditions and actions in the corresponding sections of the 464 routing policy model. 466 module: ietf-routing-policy 467 +--rw routing-policy 468 +--rw defined-sets 469 | +--rw prefix-sets 470 | | +--rw prefix-set* [name] 471 | | +--rw name string 472 | | +--rw mode? enumeration 473 | | +--rw prefixes 474 | | +--rw prefix-list* [ip-prefix mask-length-lower 475 | | mask-length-upper] 476 | | +--rw ip-prefix inet:ip-prefix 477 | | +--rw mask-length-lower uint8 478 | | +--rw mask-length-upper uint8 479 | +--rw neighbor-sets 480 | | +--rw neighbor-set* [name] 481 | | +--rw name string 482 | | +--rw address* inet:ip-address 483 | +--rw tag-sets 484 | | +--rw tag-set* [name] 485 | | +--rw name string 486 | | +--rw tag-value* tag-type 487 | +--rw bp:bgp-defined-sets 488 | +--rw bp:community-sets 489 | | +--rw bp:community-set* [name] 490 | | +--rw bp:name string 491 | | +--rw bp:member* union 492 | +--rw bp:ext-community-sets 493 | | +--rw bp:ext-community-set* [name] 494 | | +--rw bp:name string 495 | | +--rw bp:member* union 496 | +--rw bp:as-path-sets 497 | +--rw bp:as-path-set* [name] 498 | +--rw bp:name string 499 | +--rw bp:member* string 500 +--rw policy-definitions 501 +--rw policy-definition* [name] 502 +--rw name string 503 +--rw statements 504 +--rw statement* [name] 505 +--rw name string 506 +--rw conditions 507 | +--rw call-policy? 508 | +--rw source-protocol? identityref 509 | +--rw match-interface 510 | | +--rw interface? 511 | | +--rw subinterface? 512 | +--rw match-prefix-set 513 | | +--rw prefix-set? prefix-set/name 514 | | +--rw match-set-options? match-set-options-type 515 | +--rw match-neighbor-set 516 | | +--rw neighbor-set? 517 | +--rw match-tag-set 518 | | +--rw tag-set? 519 | | +--rw match-set-options? match-set-options-type 520 | +--rw match-proto-route-type* identityref 521 | +--rw bp:bgp-conditions 522 | +--rw bp:med-eq? uint32 523 | +--rw bp:origin-eq? bt:bgp-origin-attr-type 524 | +--rw bp:next-hop-in* inet:ip-address-no-zone 525 | +--rw bp:afi-safi-in* identityref 526 | +--rw bp:local-pref-eq? uint32 527 | +--rw bp:route-type? enumeration 528 | +--rw bp:community-count 529 | +--rw bp:as-path-length 530 | +--rw bp:match-community-set 531 | | +--rw bp:community-set? 532 | | +--rw bp:match-set-options? 533 | +--rw bp:match-ext-community-set 534 | | +--rw bp:ext-community-set? 535 | | +--rw bp:match-set-options? 536 | +--rw bp:match-as-path-set 537 | +--rw bp:as-path-set? 538 | +--rw bp:match-set-options? 539 +--rw actions 540 +--rw policy-result? policy-result-type 541 +--rw set-metric 542 | +--rw metric-modification? 543 | +--rw metric? uint32 544 +--rw set-metric-type 545 | +--rw metric-type? identityref 546 +--rw set-import-level 547 | +--rw import-level? identityref 548 +--rw set-preference? uint16 549 +--rw set-tag? tag-type 550 +--rw set-application-tag? tag-type 551 +--rw bp:bgp-actions 552 +--rw bp:set-route-origin?bt:bgp-origin-attr-type 553 +--rw bp:set-local-pref? uint32 554 +--rw bp:set-next-hop? bgp-next-hop-type 555 +--rw bp:set-med? bgp-set-med-type 556 +--rw bp:set-as-path-prepend 557 | +--rw bp:repeat-n? uint8 558 +--rw bp:set-community 559 | +--rw bp:method? enumeration 560 | +--rw bp:options? 561 | +--rw bp:inline 562 | | +--rw bp:communities* union 563 | +--rw bp:reference 564 | +--rw bp:community-set-ref? 565 +--rw bp:set-ext-community 566 +--rw bp:method? enumeration 567 +--rw bp:options? 568 +--rw bp:inline 569 | +--rw bp:communities* union 570 +--rw bp:reference 571 +--rw bp:ext-community-set-ref? 573 8. Security Considerations 575 The YANG modules specified in this document define a schema for data 576 that is designed to be accessed via network management protocols such 577 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 578 is the secure transport layer, and the mandatory-to-implement secure 579 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 580 is HTTPS, and the mandatory-to-implement secure transport is TLS 581 [RFC8446]. 583 The NETCONF Access Control Model (NACM) [RFC8341] provides the means 584 to restrict access for particular NETCONF or RESTCONF users to a pre- 585 configured subset of all available NETCONF or RESTCONF protocol 586 operations and content. 588 There are a number of data nodes defined in this YANG module that are 589 writable/creatable/deletable (i.e., config true, which is the 590 default). These data nodes may be considered sensitive or vulnerable 591 in some network environments. Write operations (e.g., edit-config) 592 to these data nodes without proper protection can have a negative 593 effect on network operations. These are the subtrees and data nodes 594 and their sensitivity/vulnerability: 596 /routing-policy 598 /routing-policy/defined-sets/prefix-sets 600 /routing-policy/defined-sets/neighbor-sets 602 /routing-policy/defined-sets/tag-sets 604 /routing-policy/policy-definitions 606 Unauthorized access to any data node of these subtrees can disclose 607 the operational state information of routing policies on this device. 609 Routing policy configuration has a significant impact on network 610 operations, and, as such, any related model carries potential 611 security risks. Unauthorized access or invalid data could cause 612 major disruption. 614 9. IANA Considerations 616 This document registers a URI in the IETF XML registry [RFC3688]. 617 Following the format in [RFC3688], the following registration is 618 requested to be made: 620 URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy 621 Registrant Contact: The IESG. 622 XML: N/A, the requested URI is an XML namespace. 624 This document registers a YANG module in the YANG Module Names 625 registry [RFC6020]. 627 name: ietf-routing-policy 628 namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy 629 prefix: rt-pol 630 reference: RFC XXXX 632 10. YANG modules 634 The routing policy model is described by the YANG modules in the 635 sections below. 637 10.1. Routing policy model 639 file "ietf-routing-policy@2020-05-26.yang" 640 module ietf-routing-policy { 642 yang-version "1.1"; 644 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; 645 prefix rt-pol; 647 import ietf-inet-types { 648 prefix "inet"; 649 reference "RFC 6991: Common YANG Data Types"; 650 } 652 import ietf-yang-types { 653 prefix "yang"; 654 reference "RFC 6991: Common YANG Data Types"; 655 } 657 import ietf-interfaces { 658 prefix "if"; 659 reference "RFC 8343: A YANG Data Model for Interface 660 Management (NMDA Version)"; 661 } 663 import ietf-routing { 664 prefix "rt"; 665 reference "RFC 8349: A YANG Data Model for Routing 666 Management (NMDA Version)"; 667 } 669 import ietf-if-extensions { 670 prefix "if-ext"; 671 reference "RFC YYYY: Common Interface Extension YANG 672 Data Models. Please replace YYYY with 673 published RFC number for 674 draft-ietf-netmod-intf-ext-yang."; 675 } 677 import ietf-if-l3-vlan { 678 prefix "if-l3-vlan"; 679 reference "RFC XXXX: Sub-interface VLAN YANG Data Models. 680 Please replace XXXX with published RFC number 681 for draft-ietf-netmod-sub-intf-vlan-model."; 682 } 684 organization 685 "IETF RTGWG - Routing Area Working Group"; 686 contact 687 "WG Web: 688 WG List: 690 Editor: Yingzhen Qu 691 692 Jeff Tantsura 693 694 Acee Lindem 695 696 Xufeng Liu 697 "; 699 description 700 "This module describes a YANG model for routing policy 701 configuration. It is a limited subset of all of the policy 702 configuration parameters available in the variety of vendor 703 implementations, but supports widely used constructs for 704 managing how routes are imported, exported, and modified across 705 different routing protocols. This module is intended to be 706 used in conjunction with routing protocol configuration modules 707 (e.g., BGP) defined in other models. 709 Route policy expression: 711 Policies are expressed as a set of top-level policy 712 definitions, each of which consists of a sequence of policy 713 statements. Policy statements consist of simple 714 condition-action tuples. Conditions may include multiple match 715 or comparison operations, and similarly actions may be 716 multitude of changes to route attributes or a final disposition 717 of accepting or rejecting the route. 719 Route policy evaluation: 721 Policy definitions are referenced in routing protocol 722 configurations using import and export configuration 723 statements. The arguments are members of an ordered list of 724 named policy definitions which comprise a policy chain, and 725 optionally, an explicit default policy action (i.e., reject 726 or accept). 728 Evaluation of each policy definition proceeds by evaluating its 729 corresponding individual policy statements in order. When a 730 condition statement in a policy statement is satisfied, the 731 corresponding action statement is executed. If the action 732 statement has either accept-route or reject-route actions, 733 policy evaluation of the current policy definition stops, and 734 no further policy definitions in the chain are evaluated. 736 If the condition is not satisfied, then evaluation proceeds to 737 the next policy statement. If none of the policy statement 738 conditions are satisfied, then evaluation of the current policy 739 definition stops, and the next policy definition in the chain 740 is evaluated. When the end of the policy chain is reached, the 741 default route disposition action is performed (i.e., 742 reject-route unless an alternate default action is specified 743 for the chain). 745 Policy 'subroutines' (or nested policies) are supported by 746 allowing policy statement conditions to reference another 747 policy definition which applies conditions and actions from 748 the referenced policy before returning to the calling policy 749 statement and resuming evaluation. If the called policy 750 results in an accept-route (either explicit or by default), 751 then the subroutine returns an effective true value to the 752 calling policy. Similarly, a reject-route action returns 753 false. If the subroutine returns true, the calling policy 754 continues to evaluate the remaining conditions (using a 755 modified route if the subroutine performed any changes to the 756 route). 758 Copyright (c) 2020 IETF Trust and the persons identified as 759 authors of the code. All rights reserved. 761 Redistribution and use in source and binary forms, with or 762 without modification, is permitted pursuant to, and subject to 763 the license terms contained in, the Simplified BSD License set 764 forth in Section 4.c of the IETF Trust's Legal Provisions 765 Relating to IETF Documents 766 (https://trustee.ietf.org/license-info). 768 This version of this YANG module is part of RFC XXXX 769 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 770 for full legal notices. 772 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 773 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 774 'MAY', and 'OPTIONAL' in this document are to be interpreted as 775 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 776 they appear in all capitals, as shown here. 778 This version of this YANG module is part of RFC XXXX; 779 see the RFC itself for full legal notices."; 781 revision "2020-05-26" { 782 description 783 "Initial revision."; 784 reference 785 "RFC XXXX: Routing Policy Configuration Model for Service 786 Provider Networks"; 787 } 789 /* Identities */ 791 identity metric-type { 792 description 793 "Base identity for route metric types."; 794 } 796 identity ospf-type-1-metric { 797 base metric-type; 798 description 799 "Identity for the OSPF type 1 external metric types. It 800 is only applicable to OSPF routes."; 801 } 803 identity ospf-type-2-metric { 804 base metric-type; 805 description 806 "Identity for the OSPF type 2 external metric types. It 807 is only applicable to OSPF routes."; 808 } 810 identity isis-internal-metric { 811 base metric-type; 812 description 813 "Identity for the IS-IS internal metric types. It is only 814 applicable to IS-IS routes."; 815 } 817 identity isis-external-metric { 818 base metric-type; 819 description 820 "Identity for the IS-IS external metric types. It is only 821 applicable to IS-IS routes."; 822 } 824 identity import-level { 825 description 826 "Base identity for route import level."; 827 } 828 identity ospf-normal { 829 base import-level; 830 description 831 "Identity for OSPF importation into normal areas 832 It is only applicable to routes imported 833 into the OSPF protocol."; 834 } 836 identity ospf-nssa-only { 837 base import-level; 838 description 839 "Identity for the OSPF NSSA area importation. It is only 840 applicable to routes imported into the OSPF protocol."; 841 } 843 identity ospf-normal-nssa { 844 base import-level; 845 description 846 "Identity for OSPF importation into both normal and NSSA 847 areas, It is only applicable to routes imported into 848 the OSPF protocol."; 849 } 851 identity isis-level-1 { 852 base import-level; 853 description 854 "Identity for IS-IS Level 1 area importation. It is only 855 applicable to routes imported into the IS-IS protocol."; 856 } 858 identity isis-level-2 { 859 base import-level; 860 description 861 "Identity for IS-IS Level 2 area importation. It is only 862 applicable to routes imported into the IS-IS protocol."; 863 } 865 identity isis-level-1-2 { 866 base import-level; 867 description 868 "Identity for IS-IS Level 1 and Level 2 area importation. It 869 is only applicable to routes imported into the IS-IS 870 protocol."; 871 } 873 identity proto-route-type { 874 description 875 "Base identity for route type within a protocol."; 877 } 879 identity isis-level-1-type { 880 base proto-route-type; 881 description 882 "Identity for IS-IS Level 1 route type. It is only 883 applicable to IS-IS routes."; 884 } 886 identity isis-level-2-type { 887 base proto-route-type; 888 description 889 "Identity for IS-IS Level 2 route type. It is only 890 applicable to IS-IS routes."; 891 } 893 identity ospf-internal-type { 894 base proto-route-type; 895 description 896 "Identity for OSPF intra-area or inter-area route type. 897 It is only applicable to OSPF routes."; 898 } 900 identity ospf-external-type { 901 base proto-route-type; 902 description 903 "Identity for OSPF external type 1/2 route type. 904 It is only applicable to OSPF routes."; 905 } 907 identity ospf-external-t1 { 908 base ospf-external-type; 909 description 910 "Identity for OSPF external type 1 route type. 911 It is only applicable to OSPF routes."; 912 } 914 identity ospf-external-t2-type { 915 base ospf-external-type; 916 description 917 "Identity for OSPF external type 2 route type. 918 It is only applicable to OSPF routes."; 919 } 921 identity ospf-nssa-type { 922 base proto-route-type; 923 description 924 "Identity for OSPF NSSA type 1/2 route type. 926 It is only applicable to OSPF routes."; 927 } 929 identity ospf-nssa-t1 { 930 base ospf-nssa-type; 931 description 932 "Identity for OSPF NSSA type 1 route type. 933 It is only applicable to OSPF routes."; 934 } 936 identity ospf-nssa-t2 { 937 base ospf-nssa-type; 938 description 939 "Identity for OSPF NSSA type 2 route type. 940 It is only applicable to OSPF routes."; 941 } 943 identity bgp-local { 944 base proto-route-type; 945 description 946 "Identity for BGP local route type. 947 It is only applicable to BGP routes."; 948 } 950 identity bgp-external { 951 base proto-route-type; 952 description 953 "Identity for BGP external route type. 954 It is only applicable to BGP routes."; 955 } 957 /* Type Definitions */ 959 typedef default-policy-type { 960 type enumeration { 961 enum accept-route { 962 description 963 "Default policy to accept the route."; 964 } 965 enum reject-route { 966 description 967 "Default policy to reject the route."; 968 } 969 } 970 description 971 "Type used to specify route disposition in 972 a policy chain. This typedef retained for 973 name compatibility with default import and 974 export policy."; 975 } 977 typedef policy-result-type { 978 type enumeration { 979 enum accept-route { 980 description 981 "Policy accepts the route."; 982 } 983 enum reject-route { 984 description 985 "Policy rejects the route."; 986 } 987 } 988 description 989 "Type used to specify route disposition in 990 a policy chain."; 991 } 993 typedef tag-type { 994 type union { 995 type uint32; 996 type yang:hex-string; 997 } 998 description 999 "Type for expressing route tags on a local system, 1000 including IS-IS and OSPF; may be expressed as either decimal 1001 or hexadecimal integer."; 1002 reference 1003 "RFC 2178 - OSPF Version 2 1004 RFC 5130 - A Policy Control Mechanism in IS-IS Using 1005 Administrative Tags"; 1006 } 1008 typedef match-set-options-type { 1009 type enumeration { 1010 enum any { 1011 description 1012 "Match is true if given value matches any member 1013 of the defined set."; 1014 } 1015 enum all { 1016 description 1017 "Match is true if given value matches all 1018 members of the defined set."; 1019 } 1020 enum invert { 1021 description 1022 "Match is true if given value does not match any 1023 member of the defined set."; 1024 } 1025 } 1026 default any; 1027 description 1028 "Options that govern the behavior of a match statement. The 1029 default behavior is any, i.e., the given value matches any 1030 of the members of the defined set."; 1031 } 1033 typedef metric-modification-type { 1034 type enumeration { 1035 enum set-metric { 1036 description 1037 "Set the metric to the specified value."; 1038 } 1039 enum add-metric { 1040 description 1041 "Add the specified value to the existing metric. 1042 If the result would exceed the the maximum metric 1043 (0xffffffff), set the metric to the maximum."; 1044 } 1045 enum subtract-metric { 1046 description 1047 "Subtract the specified value to the existing metric. 1048 If the result would be less than 0, set the metric to 0."; 1049 } 1050 } 1051 description 1052 "Type used to specify how to set the metric given the 1053 specified value."; 1054 } 1056 /* Groupings */ 1058 grouping prefix { 1059 description 1060 "Configuration data for a prefix definition."; 1062 leaf ip-prefix { 1063 type inet:ip-prefix; 1064 mandatory true; 1065 description 1066 "The prefix member in CIDR notation -- while the 1067 prefix may be either IPv4 or IPv6, most 1068 implementations require all members of the prefix set 1069 to be the same address family. Mixing address types in 1070 the same prefix set is likely to cause an error."; 1071 } 1073 leaf mask-length-lower { 1074 type uint8; 1075 description 1076 "Mask length range lower bound."; 1077 } 1078 leaf mask-length-upper { 1079 type uint8 { 1080 range "1..128"; 1081 } 1082 must "../mask-length-upper >= ../mask-length-lower" { 1083 error-message "The upper bound should not be less" 1084 + "than lower bound."; 1085 } 1086 description 1087 "Mask length range upper bound. 1089 The combination of mask-length-lower and mask-length-upper 1090 define a range for the mask length, or single 'exact' 1091 length if mask-length-lower and mask-length-upper are equal. 1093 Example: 192.0.2.0/24 through 192.0.2.0/26 would be 1094 expressed as prefix: 192.0.2.0/24, 1095 mask-length-lower=24, 1096 mask-length-upper=26 1098 Example: 192.0.2.0/24 (an exact match) would be 1099 expressed as prefix: 192.0.2.0/24, 1100 mask-length-lower=24, 1101 mask-length-upper=24"; 1102 } 1103 } 1105 grouping match-set-options-group { 1106 description 1107 "Grouping containing options relating to how a particular set 1108 should be matched."; 1110 leaf match-set-options { 1111 type match-set-options-type; 1112 description 1113 "Optional parameter that governs the behavior of the 1114 match operation."; 1115 } 1116 } 1117 grouping match-set-options-restricted-group { 1118 description 1119 "Grouping for a restricted set of match operation modifiers."; 1121 leaf match-set-options { 1122 type match-set-options-type { 1123 enum any { 1124 description 1125 "Match is true if given value matches any 1126 member of the defined set."; 1127 } 1128 enum invert { 1129 description 1130 "Match is true if given value does not match 1131 any member of the defined set."; 1132 } 1133 } 1134 description 1135 "Optional parameter that governs the behavior of the 1136 match operation. This leaf only supports matching on 1137 'any' member of the set or 'invert' the match. 1138 Matching on 'all' is not supported."; 1139 } 1140 } 1142 grouping match-interface-condition { 1143 description 1144 "This grouping provides interface match condition."; 1146 container match-interface { 1147 leaf interface { 1148 type leafref { 1149 path "/if:interfaces/if:interface/if:name"; 1150 } 1151 description 1152 "Reference to a base interface. If a reference to a 1153 subinterface is required, this leaf must be specified 1154 to indicate the base interface."; 1155 } 1156 leaf subinterface { 1157 type leafref { 1158 path "/if:interfaces/if:interface/if-ext:encapsulation" 1159 + "/if-l3-vlan:dot1q-vlan" 1160 + "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id"; 1161 } 1162 description 1163 "Reference to a subinterface -- this requires the base 1164 interface to be specified using the interface leaf in 1165 this container. If only a reference to a base interface 1166 is required, this leaf should not be set."; 1167 } 1169 description 1170 "Container for interface match conditions"; 1171 } 1172 } 1174 grouping match-proto-route-type-condition { 1175 description 1176 "This grouping provides route-type match condition"; 1178 leaf-list match-proto-route-type { 1179 type identityref { 1180 base proto-route-type; 1181 } 1182 description 1183 "Condition to check the protocol specific type 1184 of route. This is normally used during route 1185 importation to select routes or to set protocol 1186 specific attributes based on the route type."; 1187 } 1188 } 1190 grouping prefix-set-condition { 1191 description 1192 "This grouping provides prefix-set conditions."; 1194 container match-prefix-set { 1195 leaf prefix-set { 1196 type leafref { 1197 path "../../../../../../../defined-sets/" + 1198 "prefix-sets/prefix-set/name"; 1199 } 1200 description 1201 "References a defined prefix set."; 1202 } 1203 uses match-set-options-restricted-group; 1205 description 1206 "Match a referenced prefix-set according to the logic 1207 defined in the match-set-options leaf."; 1208 } 1209 } 1211 grouping neighbor-set-condition { 1212 description 1213 "This grouping provides neighbor-set conditions."; 1215 container match-neighbor-set { 1216 leaf neighbor-set { 1217 type leafref { 1218 path "../../../../../../../defined-sets/neighbor-sets/" + 1219 "neighbor-set/name"; 1220 require-instance true; 1221 } 1222 description 1223 "References a defined neighbor set."; 1224 } 1226 description 1227 "Match a referenced neighbor set according to the logic 1228 defined in the match-set-options-leaf."; 1229 } 1230 } 1232 grouping tag-set-condition { 1233 description 1234 "This grouping provides tag-set conditions."; 1236 container match-tag-set { 1237 leaf tag-set { 1238 type leafref { 1239 path "../../../../../../../defined-sets/tag-sets" + 1240 "/tag-set/name"; 1241 require-instance true; 1242 } 1243 description 1244 "References a defined tag set."; 1245 } 1246 uses match-set-options-restricted-group; 1248 description 1249 "Match a referenced tag set according to the logic defined 1250 in the match-options-set leaf."; 1251 } 1252 } 1254 grouping apply-policy-import { 1255 description 1256 "Grouping for applying import policies."; 1258 leaf-list import-policy { 1259 type leafref { 1260 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1261 "rt-pol:policy-definition/rt-pol:name"; 1262 require-instance true; 1263 } 1264 ordered-by user; 1265 description 1266 "List of policy names in sequence to be applied on 1267 receiving a routing update in the current context, e.g., 1268 for the current peer group, neighbor, address family, 1269 etc."; 1270 } 1272 leaf default-import-policy { 1273 type default-policy-type; 1274 default reject-route; 1275 description 1276 "Explicitly set a default policy if no policy definition 1277 in the import policy chain is satisfied."; 1278 } 1280 } 1282 grouping apply-policy-export { 1283 description 1284 "Grouping for applying export policies."; 1286 leaf-list export-policy { 1287 type leafref { 1288 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1289 "rt-pol:policy-definition/rt-pol:name"; 1290 require-instance true; 1291 } 1292 ordered-by user; 1293 description 1294 "List of policy names in sequence to be applied on 1295 sending a routing update in the current context, e.g., 1296 for the current peer group, neighbor, address family, 1297 etc."; 1298 } 1300 leaf default-export-policy { 1301 type default-policy-type; 1302 default reject-route; 1303 description 1304 "Explicitly set a default policy if no policy definition 1305 in the export policy chain is satisfied."; 1306 } 1307 } 1308 grouping apply-policy-group { 1309 description 1310 "Top level container for routing policy applications. This 1311 grouping is intended to be used in routing models where 1312 needed."; 1314 container apply-policy { 1315 description 1316 "Anchor point for routing policies in the model. 1317 Import and export policies are with respect to the local 1318 routing table, i.e., export (send) and import (receive), 1319 depending on the context."; 1321 uses apply-policy-import; 1322 uses apply-policy-export; 1324 } 1325 } 1327 container routing-policy { 1328 description 1329 "Top-level container for all routing policy."; 1331 container defined-sets { 1332 description 1333 "Predefined sets of attributes used in policy match 1334 statements."; 1336 container prefix-sets { 1337 description 1338 "Data definitions for a list of IPv4 or IPv6 1339 prefixes which are matched as part of a policy."; 1340 list prefix-set { 1341 key "name"; 1342 description 1343 "List of the defined prefix sets"; 1345 leaf name { 1346 type string; 1347 description 1348 "Name of the prefix set -- this is used as a label to 1349 reference the set in match conditions."; 1350 } 1352 leaf mode { 1353 type enumeration { 1354 enum ipv4 { 1355 description 1356 "Prefix set contains IPv4 prefixes only."; 1357 } 1358 enum ipv6 { 1359 description 1360 "Prefix set contains IPv6 prefixes only."; 1361 } 1362 enum mixed { 1363 description 1364 "Prefix set contains mixed IPv4 and IPv6 prefixes."; 1365 } 1366 } 1367 description 1368 "Indicates the mode of the prefix set, in terms of which 1369 address families (IPv4, IPv6, or both) are present. The 1370 mode provides a hint, but the device must validate that 1371 all prefixes are of the indicated type, and is expected 1372 to reject the configuration if there is a discrepancy. 1373 The MIXED mode may not be supported on devices that 1374 require prefix sets to be of only one address family."; 1375 } 1377 container prefixes { 1378 description 1379 "Container for the list of prefixes in a policy 1380 prefix list."; 1382 list prefix-list { 1383 key "ip-prefix mask-length-lower mask-length-upper"; 1384 description 1385 "List of prefixes in the prefix set."; 1387 uses prefix; 1388 } 1389 } 1390 } 1391 } 1393 container neighbor-sets { 1394 description 1395 "Data definition for a list of IPv4 or IPv6 1396 neighbors which can be matched in a routing policy."; 1398 list neighbor-set { 1399 key "name"; 1400 description 1401 "List of defined neighbor sets for use in policies."; 1403 leaf name { 1404 type string; 1405 description 1406 "Name of the neighbor set -- this is used as a label 1407 to reference the set in match conditions."; 1408 } 1410 leaf-list address { 1411 type inet:ip-address; 1412 description 1413 "List of IP addresses in the neighbor set."; 1414 } 1415 } 1416 } 1418 container tag-sets { 1419 description 1420 "Data definitions for a list of tags which can 1421 be matched in policies."; 1423 list tag-set { 1424 key "name"; 1425 description 1426 "List of tag set definitions."; 1428 leaf name { 1429 type string; 1430 description 1431 "Name of the tag set -- this is used as a label to 1432 reference the set in match conditions."; 1433 } 1435 leaf-list tag-value { 1436 type tag-type; 1437 description 1438 "Value of the tag set member."; 1439 } 1440 } 1441 } 1442 } 1444 container policy-definitions { 1445 description 1446 "Enclosing container for the list of top-level policy 1447 definitions."; 1449 list policy-definition { 1450 key "name"; 1451 description 1452 "List of top-level policy definitions, keyed by unique 1453 name. These policy definitions are expected to be 1454 referenced (by name) in policy chains specified in import 1455 or export configuration statements."; 1457 leaf name { 1458 type string; 1459 description 1460 "Name of the top-level policy definition -- this name 1461 is used in references to the current policy."; 1462 } 1464 container statements { 1465 description 1466 "Enclosing container for policy statements."; 1468 list statement { 1469 key "name"; 1470 ordered-by user; 1471 description 1472 "Policy statements group conditions and actions 1473 within a policy definition. They are evaluated in 1474 the order specified (see the description of policy 1475 evaluation at the top of this module."; 1477 leaf name { 1478 type string; 1479 description 1480 "Name of the policy statement."; 1481 } 1483 container conditions { 1484 description 1485 "Condition statements for the current policy 1486 statement."; 1488 leaf call-policy { 1489 type leafref { 1490 path "../../../../../../" + 1491 "rt-pol:policy-definitions/" + 1492 "rt-pol:policy-definition/rt-pol:name"; 1493 require-instance true; 1494 } 1495 description 1496 "Applies the statements from the specified policy 1497 definition and then returns control the current 1498 policy statement. Note that the called policy may 1499 itself call other policies (subject to 1500 implementation limitations). This is intended to 1501 provide a policy 'subroutine' capability. The 1502 called policy should contain an explicit or a 1503 default route disposition that returns an 1504 effective true (accept-route) or false 1505 (reject-route), otherwise the behavior may be 1506 ambiguous and implementation dependent."; 1507 } 1509 leaf source-protocol { 1510 type identityref { 1511 base rt:control-plane-protocol; 1512 } 1513 description 1514 "Condition to check the protocol / method used to 1515 install the route into the local routing table."; 1516 } 1518 uses match-interface-condition; 1519 uses prefix-set-condition; 1520 uses neighbor-set-condition; 1521 uses tag-set-condition; 1522 uses match-proto-route-type-condition; 1523 } 1525 container actions { 1526 description 1527 "Top-level container for policy action statements."; 1528 leaf policy-result { 1529 type policy-result-type; 1530 description 1531 "Select the final disposition for the route, either 1532 accept or reject."; 1533 } 1534 container set-metric { 1535 leaf metric-modification { 1536 type metric-modification-type; 1537 description 1538 "Indicates how to modify the metric."; 1539 } 1540 leaf metric { 1541 type uint32; 1542 description 1543 "Metric value to set, add, or subtract."; 1544 } 1545 description 1546 "Set the metric for the route."; 1547 } 1548 container set-metric-type { 1549 leaf metric-type { 1550 type identityref { 1551 base metric-type; 1552 } 1553 description 1554 "Route metric type."; 1555 } 1556 description 1557 "Set the metric type for the route."; 1558 } 1559 container set-import-level { 1560 leaf import-level { 1561 type identityref { 1562 base import-level; 1563 } 1564 description 1565 "Route importation level."; 1566 } 1567 description 1568 "Set the import level for importation of routes."; 1569 } 1570 leaf set-preference { 1571 type uint16; 1572 description 1573 "Set the preference for the route."; 1574 } 1575 leaf set-tag { 1576 type tag-type; 1577 description 1578 "Set the tag for the route."; 1579 } 1580 leaf set-application-tag { 1581 type tag-type; 1582 description 1583 "Set the application tag for the route."; 1584 } 1585 } 1586 } 1587 } 1588 } 1589 } 1590 } 1591 } 1592 1594 11. Policy examples 1596 Below we show an example of XML-encoded configuration data using the 1597 routing policy and BGP models to illustrate both how policies are 1598 defined, and also how they can be applied. Note that the XML has 1599 been simplified for readability. 1601 1602 1605 1606 1607 1608 prefix-set-A 1609 1610 1611 192.0.2.0/24 1612 24 1613 32 1614 1615 1616 10.0.0.0/16 1617 16 1618 32 1619 1620 1621 1622 1623 1624 1625 cust-tag1 1626 10 1627 1628 1629 1631 1632 1633 export-tagged-BGP 1634 1635 1636 term-0 1637 1638 bgp 1639 1640 cust-tag1 1641 1643 1644 1645 accept-route 1646 1647 1648 1649 1650 1652 1653 1655 12. References 1657 12.1. Normative references 1659 [INTF-EXT-YANG] 1660 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1661 Sivaraj,, "Common Interface Extension YANG Data Models", 1662 2019, . 1665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1666 Requirement Levels", BCP 14, RFC 2119, 1667 DOI 10.17487/RFC2119, March 1997, 1668 . 1670 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1671 DOI 10.17487/RFC3688, January 2004, 1672 . 1674 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1675 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1676 DOI 10.17487/RFC4271, January 2006, 1677 . 1679 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1680 the Network Configuration Protocol (NETCONF)", RFC 6020, 1681 DOI 10.17487/RFC6020, October 2010, 1682 . 1684 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1685 and A. Bierman, Ed., "Network Configuration Protocol 1686 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1687 . 1689 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1690 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1691 . 1693 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1694 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1695 . 1697 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1698 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1699 . 1701 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1702 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1703 . 1705 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1706 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1707 May 2017, . 1709 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1710 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1711 . 1713 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1714 Access Control Model", STD 91, RFC 8341, 1715 DOI 10.17487/RFC8341, March 2018, 1716 . 1718 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1719 and R. Wilton, "Network Management Datastore Architecture 1720 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1721 . 1723 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1724 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1725 . 1727 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1728 Routing Management (NMDA Version)", RFC 8349, 1729 DOI 10.17487/RFC8349, March 2018, 1730 . 1732 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1733 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1734 . 1736 [SUB-INTF-VLAN-YANG] 1737 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1738 Sivaraj, "Sub-interface VLAN YANG Data Model", 2019, 1739 . 1742 12.2. Informative references 1744 [I-D.ietf-idr-bgp-model] 1745 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1746 YANG Model for Service Provider Networks", draft-ietf-idr- 1747 bgp-model-08 (work in progress), February 2020. 1749 Appendix A. Acknowledgements 1751 The routing policy module defined in this draft is based on the 1752 OpenConfig route policy model. The authors would like to thank to 1753 OpenConfig for their contributions, especially Anees Shaikh, Rob 1754 Shakir, Kevin D'Souza, and Chris Chase. 1756 The authors are grateful for valuable contributions to this document 1757 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1758 George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, 1759 Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and 1760 John Heasley. 1762 Authors' Addresses 1764 Yingzhen Qu 1765 Futurewei 1766 2330 Central Expressway 1767 Santa Clara CA 95050 1768 USA 1770 Email: yingzhen.qu@futurewei.com 1772 Jeff Tantsura 1773 Apstra 1775 Email: jefftant.ietf@gmail.com 1776 Acee Lindem 1777 Cisco 1778 301 Mindenhall Way 1779 Cary, NC 27513 1780 US 1782 Email: acee@cisco.com 1784 Xufeng Liu 1785 Volta Networks 1787 Email: xufeng.liu.ietf@gmail.com