idnits 2.17.1 draft-ietf-rtgwg-policy-model-10.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 : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 10 characters in excess of 72. -- 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 1040 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 22, 2020) is 1428 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) == Unused Reference: 'I-D.ietf-netmod-sub-intf-vlan-model' is defined on line 1659, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-netmod-intf-ext-yang-08 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-sub-intf-vlan-model-06 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-08 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Y. Qu 3 Internet-Draft Futurewei 4 Intended status: Standards Track J. Tantsura 5 Expires: November 23, 2020 Apstra 6 A. Lindem 7 Cisco 8 X. Liu 9 Volta Networks 10 May 22, 2020 12 A YANG Data Model for Routing Policy Management 13 draft-ietf-rtgwg-policy-model-10 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 23, 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 . . . . . . . . . . . . . . . . . . . 2 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 75 11.1. Normative references . . . . . . . . . . . . . . . . . . 36 76 11.2. Informative references . . . . . . . . . . . . . . . . . 37 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 80 1. Introduction 82 This document describes a YANG [RFC7950] data model for routing 83 policy configuration based on operational usage and best practices in 84 a variety of service provider networks. The model is intended to be 85 vendor-neutral, in order to allow operators to manage policy 86 configuration in a consistent, intuitive way in heterogeneous 87 environments with routers supplied by multiple vendors. 89 The YANG modules in this document conform to the Network Management 90 Datastore Architecture (NMDA) [RFC8342]. 92 1.1. Goals and approach 94 This model does not aim to be feature complete -- it is a subset of 95 the policy configuration parameters available in a variety of vendor 96 implementations, but supports widely used constructs for managing how 97 routes are imported, exported, and modified across different routing 98 protocols. The model development approach has been to examine actual 99 policy configurations in use across a number of operator networks. 100 Hence the focus is on enabling policy configuration capabilities and 101 structure that are in wide use. 103 Despite the differences in details of policy expressions and 104 conventions in various vendor implementations, the model reflects the 105 observation that a relatively simple condition-action approach can be 106 readily mapped to several existing vendor implementations, and also 107 gives operators an intuitive and straightforward way to express 108 policy without sacrificing flexibility. A side affect of this design 109 decision is that legacy methods for expressing policies are not 110 considered. Such methods could be added as an augmentation to the 111 model if needed. 113 Consistent with the goal to produce a data model that is vendor 114 neutral, only policy expressions that are deemed to be widely 115 available in existing major implementations are included in the 116 model. Those configuration items that are only available from a 117 single implementation are omitted from the model with the expectation 118 they will be available in separate vendor-provided modules that 119 augment the current model. 121 2. Terminology and Notation 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 The following terms are defined in [RFC8342]: 131 o client 133 o server 135 o configuration 137 o system state 139 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- | [I-D.ietf-netmod-intf-ext-yang] | 196 | | extensions | | 197 | | | | 198 | if-l3-vla | ietf-if-l3-vlan | [I-D.ietf-netmod-sub-intf-vlan-mod | 199 | n | | el] | 200 +-----------+------------------+------------------------------------+ 202 Table 1: Prefixes and Corresponding YANG Modules 204 3. Model overview 206 The routing policy module has three main parts: 208 o A generic framework to express policies as sets of related 209 conditions and actions. This includes match sets and actions that 210 are useful across many routing protocols. 212 o A structure that allows routing protocol models to add protocol- 213 specific policy conditions and actions though YANG augmentations. 214 There is a complete example of this for BGP [RFC4271] policies in 215 the proposed vendor-neutral BGP data model 216 [I-D.ietf-idr-bgp-model]. 218 o A reusable grouping for attaching import and export rules in the 219 context of routing configuration for different protocols, VRFs, 220 etc. This also enables creation of policy chains and expressing 221 default policy behavior. 223 The module makes use of the standard Internet types, such as IP 224 addresses, autonomous system numbers, etc., defined in RFC 6991 225 [RFC6991]. 227 4. Route policy expression 229 Policies are expressed as a sequence of top-level policy definitions 230 each of which consists of a sequence of policy statements. Policy 231 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? match-set-options-type 536 | +--rw bp:match-ext-community-set 537 | | +--rw bp:ext-community-set? 538 | | +--rw bp:match-set-options? match-set-options-type 539 | +--rw bp:match-as-path-set 540 | +--rw bp:as-path-set? 541 | +--rw bp:match-set-options? match-set-options-type 542 +--rw actions 543 +--rw policy-result? policy-result-type 544 +--rw set-metric 545 | +--rw metric-modification? metric-modification-type 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? bgp-set-community-option-type 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? bgp-set-community-option-type 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-20.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 8343: A YANG Data Model for Interface 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 } 686 organization 687 "IETF RTGWG - Routing Area Working Group"; 688 contact 689 "WG Web: 690 WG List: 692 Editor: Yingzhen Qu 693 694 Jeff Tantsura 695 696 Acee Lindem 697 698 Xufeng Liu 699 "; 701 description 702 "This module describes a YANG model for routing policy 703 configuration. It is a limited subset of all of the policy 704 configuration parameters available in the variety of vendor 705 implementations, but supports widely used constructs for 706 managing how routes are imported, exported, and modified across 707 different routing protocols. This module is intended to be 708 used in conjunction with routing protocol configuration modules 709 (e.g., BGP) defined in other models. 711 Route policy expression: 713 Policies are expressed as a set of top-level policy 714 definitions, each of which consists of a sequence of policy 715 statements. Policy statements consist of simple 716 condition-action tuples. Conditions may include multiple match 717 or comparison operations, and similarly actions may be 718 multitude of changes to route attributes or a final disposition 719 of accepting or rejecting the route. 721 Route policy evaluation: 723 Policy definitions are referenced in routing protocol 724 configurations using import and export configuration 725 statements. The arguments are members of an ordered list of 726 named policy definitions which comprise a policy chain, and 727 optionally, an explicit default policy action (i.e., reject 728 or accept). 730 Evaluation of each policy definition proceeds by evaluating its 731 corresponding individual policy statements in order. When a 732 condition statement in a policy statement is satisfied, the 733 corresponding action statement is executed. If the action 734 statement has either accept-route or reject-route actions, 735 policy evaluation of the current policy definition stops, and 736 no further policy definitions in the chain are evaluated. 738 If the condition is not satisfied, then evaluation proceeds to 739 the next policy statement. If none of the policy statement 740 conditions are satisfied, then evaluation of the current policy 741 definition stops, and the next policy definition in the chain 742 is evaluated. When the end of the policy chain is reached, the 743 default route disposition action is performed (i.e., 744 reject-route unless an alternate default action is specified 745 for the chain). 747 Policy 'subroutines' (or nested policies) are supported by 748 allowing policy statement conditions to reference another 749 policy definition which applies conditions and actions from 750 the referenced policy before returning to the calling policy 751 statement and resuming evaluation. If the called policy 752 results in an accept-route (either explicit or by default), 753 then the subroutine returns an effective true value to the 754 calling policy. Similarly, a reject-route action returns 755 false. If the subroutine returns true, the calling policy 756 continues to evaluate the remaining conditions (using a 757 modified route if the subroutine performed any changes to the 758 route). 760 Copyright (c) 2020 IETF Trust and the persons identified as 761 authors of the code. All rights reserved. 763 Redistribution and use in source and binary forms, with or 764 without modification, is permitted pursuant to, and subject to 765 the license terms contained in, the Simplified BSD License set 766 forth in Section 4.c of the IETF Trust's Legal Provisions 767 Relating to IETF Documents 768 (https://trustee.ietf.org/license-info). 770 This version of this YANG module is part of RFC XXXX 771 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 772 for full legal notices. 774 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 775 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 776 'MAY', and 'OPTIONAL' in this document are to be interpreted as 777 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 778 they appear in all capitals, as shown here. 780 This version of this YANG module is part of RFC XXXX; 781 see the RFC itself for full legal notices."; 783 revision "2020-05-20" { 784 description 785 "Initial revision."; 786 reference 787 "RFC XXXX: Routing Policy Configuration Model for Service 788 Provider Networks"; 789 } 791 /* Identities */ 793 identity metric-type { 794 description 795 "Base identity for route metric types."; 796 } 798 identity ospf-type-1-metric { 799 base metric-type; 800 description 801 "Identity for the OSPF type 1 external metric types. It 802 is only applicable to OSPF routes."; 803 } 805 identity ospf-type-2-metric { 806 base metric-type; 807 description 808 "Identity for the OSPF type 2 external metric types. It 809 is only applicable to OSPF routes."; 810 } 812 identity isis-internal-metric { 813 base metric-type; 814 description 815 "Identity for the IS-IS internal metric types. It is only 816 applicable to IS-IS routes."; 817 } 819 identity isis-external-metric { 820 base metric-type; 821 description 822 "Identity for the IS-IS external metric types. It is only 823 applicable to IS-IS routes."; 824 } 826 identity import-level { 827 description 828 "Base identity for route import level."; 829 } 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 } 875 identity proto-route-type { 876 description 877 "Base identity for route type within a protocol."; 878 } 880 identity isis-level-1-type { 881 base proto-route-type; 882 description 883 "Identity for IS-IS Level 1 route type. It is only 884 applicable to IS-IS routes."; 885 } 887 identity isis-level-2-type { 888 base proto-route-type; 889 description 890 "Identity for IS-IS Level 2 route type. It is only 891 applicable to IS-IS routes."; 892 } 894 identity ospf-internal-type { 895 base proto-route-type; 896 description 897 "Identity for OSPF intra-area or inter-area route type. 898 It is only applicable to OSPF routes."; 899 } 901 identity ospf-external-type { 902 base proto-route-type; 903 description 904 "Identity for OSPF external type 1/2 route type. 905 It is only applicable to OSPF routes."; 906 } 908 identity ospf-external-t1 { 909 base ospf-external-type; 910 description 911 "Identity for OSPF external type 1 route type. 912 It is only applicable to OSPF routes."; 913 } 915 identity ospf-external-t2-type { 916 base ospf-external-type; 917 description 918 "Identity for OSPF external type 2 route type. 919 It is only applicable to OSPF routes."; 920 } 922 identity ospf-nssa-type { 923 base proto-route-type; 924 description 925 "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."; 1020 } 1021 enum invert { 1022 description 1023 "Match is true if given value does not match any 1024 member of the defined set."; 1025 } 1026 } 1027 default any; 1028 description 1029 "Options that govern the behavior of a match statement. The 1030 default behavior is any, i.e., the given value matches any 1031 of the members of the defined set."; 1032 } 1034 typedef metric-modification-type { 1035 type enumeration { 1036 enum set-metric { 1037 description 1038 "Set the metric to the specified value."; 1039 } 1040 enum add-metric { 1041 description 1042 "Add the specified value to the existing metric. 1043 If the result would exceed the the maximum metric 1044 (0xffffffff), set the metric to the maximum."; 1045 } 1046 enum subtract-metric { 1047 description 1048 "Subtract the specified value to the existing metric. 1049 If the result would be less than 0, set the metric to 0."; 1050 } 1051 } 1052 description 1053 "Type used to specify how to set the metric given the 1054 specified value."; 1055 } 1057 /* Groupings */ 1059 grouping prefix-set { 1060 description 1061 "Configuration data for prefix sets used in policy 1062 definitions."; 1064 leaf name { 1065 type string; 1066 description 1067 "Name of the prefix set -- this is used as a label to 1068 reference the set in match conditions."; 1069 } 1071 leaf mode { 1072 type enumeration { 1073 enum ipv4 { 1074 description 1075 "Prefix set contains IPv4 prefixes only."; 1076 } 1077 enum ipv6 { 1078 description 1079 "Prefix set contains IPv6 prefixes only."; 1080 } 1081 enum mixed { 1082 description 1083 "Prefix set contains mixed IPv4 and IPv6 prefixes."; 1084 } 1085 } 1086 description 1087 "Indicates the mode of the prefix set, in terms of which 1088 address families (IPv4, IPv6, or both) are present. The 1089 mode provides a hint, but the device must validate that all 1090 prefixes are of the indicated type, and is expected to 1091 reject the configuration if there is a discrepancy. The 1092 MIXED mode may not be supported on devices that require 1093 prefix sets to be of only one address family."; 1094 } 1096 } 1098 grouping prefix { 1099 description 1100 "Configuration data for a prefix definition."; 1102 leaf ip-prefix { 1103 type inet:ip-prefix; 1104 mandatory true; 1105 description 1106 "The prefix member in CIDR notation -- while the 1107 prefix may be either IPv4 or IPv6, most 1108 implementations require all members of the prefix set 1109 to be the same address family. Mixing address types in 1110 the same prefix set is likely to cause an error."; 1111 } 1113 leaf mask-length-lower { 1114 type uint8; 1115 description 1116 "Mask length range lower bound."; 1117 } 1118 leaf mask-length-upper { 1119 type uint8 { 1120 range "1..128"; 1121 } 1122 must "../mask-length-upper >= ../mask-length-lower" { 1123 error-message "The upper bound should not be less" 1124 + "than lower bound."; 1125 } 1126 description 1127 "Mask length range upper bound. 1129 The combination of mask-length-lower and mask-length-upper 1130 define a range for the mask length, or single 'exact' 1131 length if mask-length-lower and mask-length-upper are equal. 1133 Example: 192.0.2.0/24 through 192.0.2.0/26 would be 1134 expressed as prefix: 192.0.2.0/24, 1135 mask-length-lower=24, 1136 mask-length-upper=26 1138 Example: 192.0.2.0/24 (an exact match) would be 1139 expressed as prefix: 192.0.2.0/24, 1140 mask-length-lower=24, 1141 mask-length-upper=24"; 1142 } 1143 } 1145 grouping neighbor-set { 1146 description 1147 "This grouping provides neighbor set definitions."; 1149 leaf name { 1150 type string; 1151 description 1152 "Name of the neighbor set -- this is used as a label 1153 to reference the set in match conditions."; 1154 } 1156 leaf-list address { 1157 type inet:ip-address; 1158 description 1159 "List of IP addresses in the neighbor set."; 1160 } 1161 } 1163 grouping tag-set { 1164 description 1165 "This grouping provides tag set definitions."; 1167 leaf name { 1168 type string; 1169 description 1170 "Name of the tag set -- this is used as a label to reference 1171 the set in match conditions."; 1172 } 1174 leaf-list tag-value { 1175 type tag-type; 1176 description 1177 "Value of the tag set member."; 1178 } 1179 } 1181 grouping match-set-options-group { 1182 description 1183 "Grouping containing options relating to how a particular set 1184 should be matched."; 1186 leaf match-set-options { 1187 type match-set-options-type; 1188 description 1189 "Optional parameter that governs the behavior of the 1190 match operation."; 1191 } 1192 } 1194 grouping match-set-options-restricted-group { 1195 description 1196 "Grouping for a restricted set of match operation modifiers."; 1198 leaf match-set-options { 1199 type match-set-options-type { 1200 enum any { 1201 description 1202 "Match is true if given value matches any 1203 member of the defined set."; 1204 } 1205 enum invert { 1206 description 1207 "Match is true if given value does not match 1208 any member of the defined set."; 1209 } 1210 } 1211 description 1212 "Optional parameter that governs the behavior of the 1213 match operation. This leaf only supports matching on 1214 'any' member of the set or 'invert' the match. 1215 Matching on 'all' is not supported."; 1216 } 1217 } 1219 grouping match-interface-condition { 1220 description 1221 "This grouping provides interface match condition."; 1223 container match-interface { 1224 leaf interface { 1225 type leafref { 1226 path "/if:interfaces/if:interface/if:name"; 1227 } 1228 description 1229 "Reference to a base interface. If a reference to a 1230 subinterface is required, this leaf must be specified 1231 to indicate the base interface."; 1232 } 1233 leaf subinterface { 1234 type leafref { 1235 path "/if:interfaces/if:interface/if-ext:encapsulation" 1236 + "/if-l3-vlan:dot1q-vlan" 1237 + "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id"; 1238 } 1239 description 1240 "Reference to a subinterface -- this requires the base 1241 interface to be specified using the interface leaf in 1242 this container. If only a reference to a base interface 1243 is required, this leaf should not be set."; 1244 } 1246 description 1247 "Container for interface match conditions"; 1248 } 1249 } 1251 grouping match-proto-route-type-condition { 1252 description 1253 "This grouping provides route-type match condition"; 1255 leaf-list match-proto-route-type { 1256 type identityref { 1257 base proto-route-type; 1258 } 1259 description 1260 "Condition to check the protocol specific type 1261 of route. This is normally used during route 1262 importation to select routes or to set protocol 1263 specific attributes based on the route type."; 1264 } 1265 } 1267 grouping prefix-set-condition { 1268 description 1269 "This grouping provides prefix-set conditions."; 1271 container match-prefix-set { 1272 leaf prefix-set { 1273 type leafref { 1274 path "../../../../../../../defined-sets/" + 1275 "prefix-sets/prefix-set/name"; 1276 } 1277 description 1278 "References a defined prefix set."; 1279 } 1280 uses match-set-options-restricted-group; 1282 description 1283 "Match a referenced prefix-set according to the logic 1284 defined in the match-set-options leaf."; 1285 } 1286 } 1288 grouping neighbor-set-condition { 1289 description 1290 "This grouping provides neighbor-set conditions."; 1292 container match-neighbor-set { 1293 leaf neighbor-set { 1294 type leafref { 1295 path "../../../../../../../defined-sets/neighbor-sets/" + 1296 "neighbor-set/name"; 1297 require-instance true; 1298 } 1299 description 1300 "References a defined neighbor set."; 1301 } 1303 description 1304 "Match a referenced neighbor set according to the logic 1305 defined in the match-set-options-leaf."; 1306 } 1307 } 1308 grouping tag-set-condition { 1309 description 1310 "This grouping provides tag-set conditions."; 1312 container match-tag-set { 1313 leaf tag-set { 1314 type leafref { 1315 path "../../../../../../../defined-sets/tag-sets" + 1316 "/tag-set/name"; 1317 require-instance true; 1318 } 1319 description 1320 "References a defined tag set."; 1321 } 1322 uses match-set-options-restricted-group; 1324 description 1325 "Match a referenced tag set according to the logic defined 1326 in the match-options-set leaf."; 1327 } 1328 } 1330 grouping generic-conditions { 1331 description 1332 "Condition statement definitions for checking 1333 membership in a generic defined set."; 1335 uses match-interface-condition; 1336 uses prefix-set-condition; 1337 uses neighbor-set-condition; 1338 uses tag-set-condition; 1339 uses match-proto-route-type-condition; 1341 } 1343 grouping policy-conditions { 1344 description 1345 "Data for general policy conditions, i.e., those 1346 not related to match-sets."; 1348 leaf call-policy { 1349 type leafref { 1350 path "../../../../../../" + 1351 "rt-pol:policy-definitions/" + 1352 "rt-pol:policy-definition/rt-pol:name"; 1353 require-instance true; 1354 } 1355 description 1356 "Applies the statements from the specified policy 1357 definition and then returns control the current 1358 policy statement. Note that the called policy may 1359 itself call other policies (subject to 1360 implementation limitations). This is intended to 1361 provide a policy 'subroutine' capability. The 1362 called policy should contain an explicit or a 1363 default route disposition that returns an 1364 effective true (accept-route) or false 1365 (reject-route), otherwise the behavior may be 1366 ambiguous and implementation dependent."; 1367 } 1369 leaf source-protocol { 1370 type identityref { 1371 base rt:control-plane-protocol; 1372 } 1373 description 1374 "Condition to check the protocol / method used to install 1375 the route into the local routing table."; 1376 } 1377 } 1379 grouping policy-actions { 1380 description 1381 "Top-level grouping for policy actions."; 1383 container actions { 1384 description 1385 "Top-level container for policy action statements."; 1387 leaf policy-result { 1388 type policy-result-type; 1389 description 1390 "Select the final disposition for the route, either 1391 accept or reject."; 1392 } 1393 container set-metric { 1394 leaf metric-modification { 1395 type metric-modification-type; 1396 description 1397 "Indicates how to modify the metric."; 1398 } 1399 leaf metric { 1400 type uint32; 1401 description 1402 "Metric value to set, add, or subtract."; 1403 } 1404 description 1405 "Set the metric for the route."; 1406 } 1407 container set-metric-type { 1408 leaf metric-type { 1409 type identityref { 1410 base metric-type; 1411 } 1412 description 1413 "Route metric type."; 1414 } 1415 description 1416 "Set the metric type for the route."; 1417 } 1418 container set-import-level { 1419 leaf import-level { 1420 type identityref { 1421 base import-level; 1422 } 1423 description 1424 "Route importation level."; 1425 } 1426 description 1427 "Set the import level for importation of routes."; 1428 } 1429 leaf set-preference { 1430 type uint16; 1431 description 1432 "Set the preference for the route."; 1433 } 1434 leaf set-tag { 1435 type tag-type; 1436 description 1437 "Set the tag for the route."; 1438 } 1439 leaf set-application-tag { 1440 type tag-type; 1441 description 1442 "Set the application tag for the route."; 1443 } 1444 } 1445 } 1447 grouping apply-policy-import { 1448 description 1449 "Grouping for applying import policies."; 1451 leaf-list import-policy { 1452 type leafref { 1453 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1454 "rt-pol:policy-definition/rt-pol:name"; 1455 require-instance true; 1456 } 1457 ordered-by user; 1458 description 1459 "List of policy names in sequence to be applied on 1460 receiving a routing update in the current context, e.g., 1461 for the current peer group, neighbor, address family, 1462 etc."; 1463 } 1465 leaf default-import-policy { 1466 type default-policy-type; 1467 default reject-route; 1468 description 1469 "Explicitly set a default policy if no policy definition 1470 in the import policy chain is satisfied."; 1471 } 1473 } 1475 grouping apply-policy-export { 1476 description 1477 "Grouping for applying export policies."; 1479 leaf-list export-policy { 1480 type leafref { 1481 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1482 "rt-pol:policy-definition/rt-pol:name"; 1483 require-instance true; 1484 } 1485 ordered-by user; 1486 description 1487 "List of policy names in sequence to be applied on 1488 sending a routing update in the current context, e.g., 1489 for the current peer group, neighbor, address family, 1490 etc."; 1491 } 1493 leaf default-export-policy { 1494 type default-policy-type; 1495 default reject-route; 1496 description 1497 "Explicitly set a default policy if no policy definition 1498 in the export policy chain is satisfied."; 1499 } 1501 } 1503 grouping apply-policy { 1504 description 1505 "Configuration data for routing policies."; 1507 uses apply-policy-import; 1508 uses apply-policy-export; 1509 } 1511 grouping apply-policy-group { 1512 description 1513 "Top level container for routing policy applications. This 1514 grouping is intended to be used in routing models where 1515 needed."; 1517 container apply-policy { 1518 description 1519 "Anchor point for routing policies in the model. 1520 Import and export policies are with respect to the local 1521 routing table, i.e., export (send) and import (receive), 1522 depending on the context."; 1524 uses apply-policy; 1526 } 1527 } 1529 container routing-policy { 1530 description 1531 "Top-level container for all routing policy."; 1533 container defined-sets { 1534 description 1535 "Predefined sets of attributes used in policy match 1536 statements."; 1538 container prefix-sets { 1539 description 1540 "Data definitions for a list of IPv4 or IPv6 1541 prefixes which are matched as part of a policy."; 1542 list prefix-set { 1543 key "name"; 1544 description 1545 "List of the defined prefix sets"; 1547 uses prefix-set; 1548 container prefixes { 1549 description 1550 "Container for the list of prefixes in a policy 1551 prefix list."; 1553 list prefix-list { 1554 key "ip-prefix mask-length-lower mask-length-upper"; 1555 description 1556 "List of prefixes in the prefix set."; 1558 uses prefix; 1559 } 1560 } 1561 } 1562 } 1564 container neighbor-sets { 1565 description 1566 "Data definition for a list of IPv4 or IPv6 1567 neighbors which can be matched in a routing policy."; 1569 list neighbor-set { 1570 key "name"; 1571 description 1572 "List of defined neighbor sets for use in policies."; 1574 uses neighbor-set; 1575 } 1576 } 1578 container tag-sets { 1579 description 1580 "Data definitions for a list of tags which can 1581 be matched in policies."; 1583 list tag-set { 1584 key "name"; 1585 description 1586 "List of tag set definitions."; 1587 uses tag-set; 1588 } 1589 } 1590 } 1592 container policy-definitions { 1593 description 1594 "Enclosing container for the list of top-level policy 1595 definitions."; 1597 list policy-definition { 1598 key "name"; 1599 description 1600 "List of top-level policy definitions, keyed by unique 1601 name. These policy definitions are expected to be 1602 referenced (by name) in policy chains specified in import 1603 or export configuration statements."; 1605 leaf name { 1606 type string; 1607 description 1608 "Name of the top-level policy definition -- this name 1609 is used in references to the current policy."; 1610 } 1612 container statements { 1613 description 1614 "Enclosing container for policy statements."; 1616 list statement { 1617 key "name"; 1618 ordered-by user; 1619 description 1620 "Policy statements group conditions and actions 1621 within a policy definition. They are evaluated in 1622 the order specified (see the description of policy 1623 evaluation at the top of this module."; 1625 leaf name { 1626 type string; 1627 description 1628 "Name of the policy statement."; 1629 } 1631 container conditions { 1632 description 1633 "Condition statements for the current policy statement."; 1635 uses policy-conditions; 1636 uses generic-conditions; 1637 } 1639 uses policy-actions; 1640 } 1641 } 1642 } 1643 } 1644 } 1646 } 1647 1649 11. References 1651 11.1. Normative references 1653 [I-D.ietf-netmod-intf-ext-yang] 1654 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1655 Sivaraj, "Common Interface Extension YANG Data Models", 1656 draft-ietf-netmod-intf-ext-yang-08 (work in progress), 1657 November 2019. 1659 [I-D.ietf-netmod-sub-intf-vlan-model] 1660 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1661 Sivaraj, "Sub-interface VLAN YANG Data Models", draft- 1662 ietf-netmod-sub-intf-vlan-model-06 (work in progress), 1663 November 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 11.2. Informative references 1738 [I-D.ietf-idr-bgp-model] 1739 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1740 YANG Model for Service Provider Networks", draft-ietf-idr- 1741 bgp-model-08 (work in progress), February 2020. 1743 Appendix A. Acknowledgements 1745 The routing policy module defined in this draft is based on the 1746 OpenConfig route policy model. The authors would like to thank to 1747 OpenConfig for their contributions, especially Anees Shaikh, Rob 1748 Shakir, Kevin D'Souza, and Chris Chase. 1750 The authors are grateful for valuable contributions to this document 1751 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1752 George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, 1753 Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and 1754 John Heasley. 1756 Authors' Addresses 1758 Yingzhen Qu 1759 Futurewei 1760 2330 Central Expressway 1761 Santa Clara CA 95050 1762 USA 1764 Email: yingzhen.qu@futurewei.com 1766 Jeff Tantsura 1767 Apstra 1769 Email: jefftant.ietf@gmail.com 1771 Acee Lindem 1772 Cisco 1773 301 Mindenhall Way 1774 Cary, NC 27513 1775 US 1777 Email: acee@cisco.com 1779 Xufeng Liu 1780 Volta Networks 1782 Email: xufeng.liu.ietf@gmail.com