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