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