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