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