idnits 2.17.1 draft-ietf-rtgwg-policy-model-30.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 : ---------------------------------------------------------------------------- No issues found here. 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 494 has weird spacing: '...h-lower uin...' == Line 495 has weird spacing: '...h-upper uin...' == Line 943 has weird spacing: '... enum add-m...' == (3 more instances...) -- The document date (July 29, 2021) is 1002 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-11 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: January 30, 2022 Juniper Networks 6 A. Lindem 7 Cisco 8 X. Liu 9 Volta Networks 10 July 29, 2021 12 A YANG Data Model for Routing Policy 13 draft-ietf-rtgwg-policy-model-30 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 January 30, 2022. 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. YANG Module and Tree . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Routing Policy Model Tree . . . . . . . . . . . . . . . . 11 71 7.2. Routing policy model . . . . . . . . . . . . . . . . . . 12 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 76 11.1. Normative references . . . . . . . . . . . . . . . . . . 34 77 11.2. Informative references . . . . . . . . . . . . . . . . . 36 78 Appendix A. Routing protocol-specific policies . . . . . . . . . 36 79 Appendix B. Policy examples . . . . . . . . . . . . . . . . . . 39 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 82 1. Introduction 84 This document describes a YANG [RFC7950] data model for routing 85 policy configuration based on operational usage and best practices in 86 a variety of service provider networks. The model is intended to be 87 vendor-neutral, to allow operators to manage policy configuration in 88 a consistent way in environments with routers supplied by multiple 89 vendors. 91 The YANG modules in this document conform to the Network Management 92 Datastore Architecture (NMDA) [RFC8342]. 94 1.1. Goals and approach 96 This model does not aim to be feature complete -- it is a subset of 97 the policy configuration parameters available in a variety of vendor 98 implementations, but supports widely used constructs for managing how 99 routes are imported, exported, and modified across different routing 100 protocols. The model development approach has been to examine actual 101 policy configurations in use across several operator networks. 102 Hence, the focus is on enabling policy configuration capabilities and 103 structure that are in wide use. 105 Despite the differences in details of policy expressions and 106 conventions in various vendor implementations, the model reflects the 107 observation that a relatively simple condition-action approach can be 108 readily mapped to several existing vendor implementations, and also 109 gives operators a familiar and straightforward way to express policy. 110 A side effect of this design decision is that other methods for 111 expressing policies are not considered. 113 Consistent with the goal to produce a data model that is vendor 114 neutral, only policy expressions that are deemed to be widely 115 available in existing major implementations are included in the 116 model. Those configuration items that are only available from a 117 single implementation are omitted from the model with the expectation 118 they will be available in separate vendor-provided modules that 119 augment the current model. 121 2. Terminology and Notation 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 Routing policy: A routing policy defines how routes are imported, 130 exported, modified, and advertised between routing protocol instances 131 or within a single routing protocol instance. 133 Policy chain: A policy chain is a sequence of policy definitions 134 (described in Section 4). They can be referenced from different 135 contexts. 137 Policy statement: Policy statements consist of a set of conditions 138 and actions (either of which may be empty). 140 The following terms are defined in [RFC8342]: 142 o client 144 o server 146 o configuration 148 o system state 150 o operational state 152 o intended configuration 154 The following terms are defined in [RFC7950]: 156 o action 158 o augment 160 o container 162 o container with presence 164 o data model 166 o data node 168 o feature 170 o leaf 172 o list 174 o mandatory node 176 o module 178 o schema tree 180 o RPC (Remote Procedure Call) operation 182 2.1. Tree Diagrams 184 Tree diagrams used in this document follow the notation defined in 185 [RFC8340]. 187 2.2. Prefixes in Data Node Names 189 In this document, names of data nodes, actions, and other data model 190 objects are often used without a prefix, as long as it is clear from 191 the context in which YANG module each name is defined. Otherwise, 192 names are prefixed using the standard prefix associated with the 193 corresponding YANG module, as shown in Table 1. 195 +--------+-----------------+-----------+ 196 | Prefix | YANG module | Reference | 197 +--------+-----------------+-----------+ 198 | if | ietf-interfaces | [RFC8343] | 199 | | | | 200 | rt | ietf-routing | [RFC8349] | 201 | | | | 202 | yang | ietf-yang-types | [RFC6991] | 203 | | | | 204 | inet | ietf-inet-types | [RFC6991] | 205 +--------+-----------------+-----------+ 207 Table 1: Prefixes and Corresponding YANG Modules 209 3. Model overview 211 The routing policy module has three main parts: 213 o A generic framework is provided to express policies as sets of 214 related conditions and actions. This includes match sets and 215 actions that are useful across many routing protocols. 217 o A structure that allows routing protocol models to add protocol- 218 specific policy conditions and actions though YANG augmentations 219 is also provided. There is a complete example of this for BGP 220 [RFC4271] policies in the proposed vendor-neutral BGP data model 221 [I-D.ietf-idr-bgp-model]. Appendix A provides an example of how 222 an augmentation for BGP policies might be accomplished. Note that 223 this section is not normative as the BGP model is still evolving. 225 o Finally, a reusable grouping is defined for attaching import and 226 export rules in the context of routing configuration for different 227 protocols, VRFs, etc. This also enables creation of policy chains 228 and expressing default policy behavior. In this document, policy 229 chains are sequences of policy definitions that are applied in 230 order (described in Section 4). 232 The module makes use of the standard Internet types, such as IP 233 addresses, autonomous system numbers, etc., defined in RFC 6991 234 [RFC6991]. 236 4. Route policy expression 238 Policies are expressed as a sequence of top-level policy definitions 239 each of which consists of a sequence of policy statements. Policy 240 statements in turn consist of simple condition-action tuples. 241 Conditions may include multiple match or comparison operations, and 242 similarly, actions may effect multiple changes to route attributes, 243 or indicate a final disposition of accepting or rejecting the route. 244 This structure is shown below. 246 +--rw routing-policy 247 +--ro match-modified-attributes? boolean 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 model provides a collection 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 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 defines 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. The default action is to 306 reject-route. 308 Match conditions may be further modified using the match-set-options 309 configuration which allows network operators to change the behavior 310 of a match. Three options are supported: 312 o ALL - match is true only if the given value matches all members of 313 the set. 315 o ANY - match is true if the given value matches any member of the 316 set. 318 o INVERT - match is true if the given value does not match any 319 member of the given set. 321 Not all options are appropriate for matching against all defined sets 322 (e.g., match ALL in a prefix set does not make sense). In the model, 323 a restricted set of match options is used where applicable. 325 Comparison conditions may similarly use options to change how route 326 attributes should be tested, e.g., for equality or inequality, 327 against a given value. 329 While most policy conditions will be added by individual routing 330 protocol models via augmentation, this routing policy model includes 331 several generic match conditions and the ability to test which 332 protocol or mechanism installed a route (e.g., BGP, IGP, static, 333 etc.). The conditions included in the model are shown below. 335 +--rw routing-policy 336 +--rw policy-definitions 337 +--rw policy-definition* [name] 338 +--rw name string 339 +--rw statements 340 +--rw statement* [name] 341 +--rw conditions 342 | +--rw call-policy? 343 | +--rw source-protocol? 344 | +--rw match-interface 345 | | +--rw interface? 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 355 | +--rw route-type* 357 4.3. Policy actions 359 When policy conditions are satisfied, policy actions are used to set 360 various attributes of the route being processed, or to indicate the 361 final disposition of the route, i.e., accept or reject. 363 Similar to policy conditions, the routing policy model includes 364 generic actions in addition to the basic route disposition actions. 365 These are shown below. 367 +--rw routing-policy 368 +--rw policy-definitions 369 +--rw policy-definition* [name] 370 +--rw statements 371 +--rw statement* [name] 372 +--rw actions 373 +--rw policy-result? policy-result-type 374 +--rw set-metric 375 | +--rw metric-modification? 376 | | metric-modification-type 377 | +--rw metric? uint32 378 +--rw set-metric-type 379 | +--rw metric-type? identityref 380 +--rw set-route-level 381 | +--rw route-level? identityref 382 +--rw set-route-preference? uint16 383 +--rw set-tag? tag-type 384 +--rw set-application-tag? tag-type 386 4.4. Policy subroutines 388 Policy 'subroutines' (or nested policies) are supported by allowing 389 policy statement conditions to reference other policy definitions 390 using the call-policy configuration. Called policies apply their 391 conditions and actions before returning to the calling policy 392 statement and resuming evaluation. The outcome of the called policy 393 affects the evaluation of the calling policy. If the called policy 394 results in an accept-route, then the subroutine returns an effective 395 Boolean true value to the calling policy. For the calling policy, 396 this is equivalent to a condition statement evaluating to a true 397 value and evaluation of the policy continues (see Section 5). Note 398 that the called policy may also modify attributes of the route in its 399 action statements. Similarly, a reject-route action returns false 400 and the calling policy evaluation will be affected accordingly. When 401 the end of the subroutine policy statements is reached, the default 402 route disposition action is returned (i.e., Boolean false for reject- 403 route). Consequently, a subroutine cannot explicitly accept or 404 reject a route. Rather, the called policy returns Boolean true if 405 its outcome is accept-route or Boolean false if its outcome is 406 reject-route. Route acceptance or rejection is solely determined by 407 the top-level policy. 409 Note that the called policy may itself call other policies (subject 410 to implementation limitations). The model does not prescribe a 411 nesting depth because this varies among implementations. For 412 example, an implementation may only support a single level of 413 subroutine recursion. As with any routing policy construction, care 414 must be taken with nested policies to ensure that the effective 415 return value results in the intended behavior. Nested policies are a 416 convenience in many routing policy constructions but creating 417 policies nested beyond a small number of levels (e.g., 2-3) is 418 discouraged. Also, implementations MUST validate to ensure that 419 there is no recursion amongst nested routing policies. 421 5. Policy evaluation 423 Evaluation of each policy definition proceeds by evaluating its 424 individual policy statements in order that they are defined. When 425 all the condition statements in a policy statement are satisfied, the 426 corresponding action statements are executed. If the actions include 427 either accept-route or reject-route actions, evaluation of the 428 current policy definition stops, and no further policy statement is 429 evaluated. If there are multiple policies in the policy chain, 430 subsequent policies are not evaluated. Policy chains are sequences 431 of policy definitions (as described in Section 4). 433 If the conditions are not satisfied, then evaluation proceeds to the 434 next policy statement. If none of the policy statement conditions 435 are satisfied, then evaluation of the current policy definition 436 stops, and the next policy definition in the chain is evaluated. 437 When the end of the policy chain is reached, the default route 438 disposition action is performed (i.e., reject-route unless an 439 alternate default action is specified for the chain). 441 Whether or not the route's pre-policy attributes are used for testing 442 policy statement conditions is dependent on the implementation 443 specific value of the match-modified-attributes leaf. If match- 444 modified-attributes is false and actions modify route attributes, 445 these modifications are not used for policy statement conditions. 446 Conversely, if match-modified-attributes is true and actions modify 447 the policy application-specific attributes, the attributes as 448 modified by the policy are used for policy condition statements. 450 6. Applying routing policy 452 Routing policy is applied by defining and attaching policy chains in 453 various routing contexts. Policy chains are sequences of policy 454 definitions (described in Section 4). They can be referenced from 455 different contexts. For example, a policy chain could be associated 456 with a routing protocol and used to control its interaction with its 457 protocol peers. Or it could be used to control the interaction 458 between a routing protocol and the local routing information base. A 459 policy chain has an associated direction (import or export), with 460 respect to the context in which it is referenced. 462 The routing policy model defines an apply-policy grouping that can be 463 imported and used by other models. As shown below, it allows 464 definition of import and export policy chains, as well as specifying 465 the default route disposition to be used when no policy definition in 466 the chain results in a final decision. 468 +--rw apply-policy 469 | +--rw import-policy* 470 | +--rw default-import-policy? default-policy-type 471 | +--rw export-policy* 472 | +--rw default-export-policy? default-policy-type 474 The default policy defined by the model is to reject the route for 475 both import and export policies. 477 7. YANG Module and Tree 479 7.1. Routing Policy Model Tree 481 The tree of the routing policy model is shown below. 483 module: ietf-routing-policy 484 rw routing-policy 485 +--rw defined-sets 486 | +--rw prefix-sets 487 | | +--rw prefix-set* [name mode] 488 | | +--rw name string 489 | | +--rw mode enumeration 490 | | +--rw prefixes 491 | | +--rw prefix-list* [ip-prefix mask-length-lower 492 | | mask-length-upper] 493 | | +--rw ip-prefix inet:ip-prefix 494 | | +--rw mask-length-lower uint8 495 | | +--rw mask-length-upper uint8 496 | +--rw neighbor-sets 497 | | +--rw neighbor-set* [name] 498 | | +--rw name string 499 | | +--rw address* inet:ip-address 500 | +--rw tag-sets 501 | +--rw tag-set* [name] 502 | +--rw name string 503 | +--rw tag-value* tag-type 504 +--rw policy-definitions 505 +--ro match-modified-attributes? boolean 506 +--rw policy-definition* [name] 507 +--rw name string 508 +--rw statements 509 +--rw statement* [name] 510 +--rw name string 511 +--rw conditions 512 | +--rw call-policy? -> ../../../../../.. 513 | /policy-definitions 514 | /policy-definition/name 515 | +--rw source-protocol? identityref 516 | +--rw match-interface 517 | | +--rw interface? -> /if:interfaces/interface 518 | | /name 519 | +--rw match-prefix-set 520 | | +--rw prefix-set? -> ../../../../../../.. 521 | | /defined-sets/prefix-sets 522 | | /prefix-set/name 523 | | +--rw match-set-options? match-set-options-type 524 | +--rw match-neighbor-set 525 | | +--rw neighbor-set? -> ../../../../../../.. 526 | | /defined-sets/neighbor-sets 527 | | /neighbor-set/name 528 | +--rw match-tag-set 529 | | +--rw tag-set? -> ../../../../../../.. 530 | | /defined-sets/tag-sets 531 | | /tag-set/name 532 | | +--rw match-set-options? match-set-options-type 533 | +--rw match-route-type* identityref 534 +--rw actions 535 +--rw policy-result? policy-result-type 536 +--rw set-metric 537 | +--rw metric-modification? metric-modification-type 538 | +--rw metric? uint32 539 +--rw set-metric-type 540 | +--rw metric-type? identityref 541 +--rw set-route-level 542 | +--rw route-level? identityref 543 +--rw set-route-preference? uint16 544 +--rw set-tag? tag-type 545 +--rw set-application-tag? tag-type 547 7.2. Routing policy model 549 The following RFCs are not referenced in the document text but are 550 referenced in the ietf-routing-policy.yang module: [RFC2328], 551 [RFC3101], [RFC5130], [RFC5302], [RFC6991], and [RFC8343]. 553 file "ietf-routing-policy@2021-07-28.yang" 554 module ietf-routing-policy { 556 yang-version "1.1"; 557 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; 558 prefix rt-pol; 560 import ietf-inet-types { 561 prefix "inet"; 562 reference 563 "RFC 6991: Common YANG Data Types"; 564 } 566 import ietf-yang-types { 567 prefix "yang"; 568 reference 569 "RFC 6991: Common YANG Data Types"; 570 } 572 import ietf-interfaces { 573 prefix "if"; 574 reference 575 "RFC 8343: A YANG Data Model for Interface 576 Management (NMDA Version)"; 577 } 579 import ietf-routing { 580 prefix "rt"; 581 reference 582 "RFC 8349: A YANG Data Model for Routing 583 Management (NMDA Version)"; 584 } 586 organization 587 "IETF RTGWG - Routing Area Working Group"; 588 contact 589 "WG Web: 590 WG List: 592 Editor: Yingzhen Qu 593 594 Jeff Tantsura 595 596 Acee Lindem 597 598 Xufeng Liu 599 "; 601 description 602 "This module describes a YANG model for routing policy 603 configuration. It is a limited subset of all of the policy 604 configuration parameters available in the variety of vendor 605 implementations, but supports widely used constructs for 606 managing how routes are imported, exported, modified and 607 advertised across different routing protocol instances or 608 within a single routing protocol instance. This module is 609 intended to be used in conjunction with routing protocol 610 configuration modules (e.g., BGP) defined in other models. 612 This YANG module conforms to the Network Management 613 Datastore Architecture (NMDA), as described in RFC 8342. 615 Copyright (c) 2021 IETF Trust and the persons identified as 616 authors of the code. All rights reserved. 618 Redistribution and use in source and binary forms, with or 619 without modification, is permitted pursuant to, and subject to 620 the license terms contained in, the Simplified BSD License set 621 forth in Section 4.c of the IETF Trust's Legal Provisions 622 Relating to IETF Documents 623 (https://trustee.ietf.org/license-info). 625 This version of this YANG module is part of RFC XXXX; 626 see the RFC itself for full legal notices. 628 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 629 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT 630 RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 631 interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, 632 and only when, they appear in all capitals, as shown here."; 634 reference "RFC XXXX: A YANG Data Model for Routing Policy."; 636 revision "2021-07-28" { 637 description 638 "Initial revision."; 639 reference 640 "RFC XXXX: A YANG Data Model for Routing Policy Management."; 641 } 643 /* Identities */ 645 identity metric-type { 646 description 647 "Base identity for route metric types."; 648 } 650 identity ospf-type-1-metric { 651 base metric-type; 652 description 653 "Identity for the OSPF type 1 external metric types. It 654 is only applicable to OSPF routes."; 655 reference 656 "RFC 2328: OSPF Version 2"; 657 } 659 identity ospf-type-2-metric { 660 base metric-type; 661 description 662 "Identity for the OSPF type 2 external metric types. It 663 is only applicable to OSPF routes."; 664 reference 665 "RFC 2328: OSPF Version 2"; 666 } 668 identity isis-internal-metric { 669 base metric-type; 670 description 671 "Identity for the IS-IS internal metric types. It is only 672 applicable to IS-IS routes."; 673 reference 674 "RFC 5302: Domain-Wide Prefix Distribution with 675 Two-Level IS-IS"; 676 } 678 identity isis-external-metric { 679 base metric-type; 680 description 681 "Identity for the IS-IS external metric types. It is only 682 applicable to IS-IS routes."; 683 reference 684 "RFC 5302: Domain-Wide Prefix Distribution with 685 Two-Level IS-IS"; 686 } 688 identity route-level { 689 description 690 "Base identity for route import level."; 691 } 693 identity ospf-normal { 694 base route-level; 695 description 696 "Identity for OSPF importation into normal areas 697 It is only applicable to routes imported 698 into the OSPF protocol."; 699 reference 700 "RFC 2328: OSPF Version 2"; 702 } 704 identity ospf-nssa-only { 705 base route-level; 706 description 707 "Identity for the OSPF Not-So-Stubby Area (NSSA) area 708 importation. It is only applicable to routes imported 709 into the OSPF protocol."; 710 reference 711 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 712 } 714 identity ospf-normal-nssa { 715 base route-level; 716 description 717 "Identity for OSPF importation into both normal and NSSA 718 areas, it is only applicable to routes imported into 719 the OSPF protocol."; 720 reference 721 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 722 } 724 identity isis-level-1 { 725 base route-level; 726 description 727 "Identity for IS-IS Level 1 area importation. It is only 728 applicable to routes imported into the IS-IS protocol."; 729 reference 730 "RFC 5302: Domain-Wide Prefix Distribution with 731 Two-Level IS-IS"; 732 } 734 identity isis-level-2 { 735 base route-level; 736 description 737 "Identity for IS-IS Level 2 area importation. It is only 738 applicable to routes imported into the IS-IS protocol."; 739 reference 740 "RFC 5302: Domain-Wide Prefix Distribution with 741 Two-Level IS-IS"; 742 } 744 identity isis-level-1-2 { 745 base route-level; 746 description 747 "Identity for IS-IS Level 1 and Level 2 area importation. It 748 is only applicable to routes imported into the IS-IS 749 protocol."; 751 reference 752 "RFC 5302: Domain-Wide Prefix Distribution with 753 Two-Level IS-IS"; 754 } 756 identity proto-route-type { 757 description 758 "Base identity for route type within a protocol."; 759 } 761 identity isis-level-1-type { 762 base proto-route-type; 763 description 764 "Identity for IS-IS Level 1 route type. It is only 765 applicable to IS-IS routes."; 766 reference 767 "RFC 5302: Domain-Wide Prefix Distribution with 768 Two-Level IS-IS"; 769 } 771 identity isis-level-2-type { 772 base proto-route-type; 773 description 774 "Identity for IS-IS Level 2 route type. It is only 775 applicable to IS-IS routes."; 776 reference 777 "RFC 5302: Domain-Wide Prefix Distribution with 778 Two-Level IS-IS"; 779 } 781 identity ospf-internal-type { 782 base proto-route-type; 783 description 784 "Identity for OSPF intra-area or inter-area route type. 785 It is only applicable to OSPF routes."; 786 reference 787 "RFC 2328: OSPF Version 2"; 788 } 790 identity ospf-external-type { 791 base proto-route-type; 792 description 793 "Identity for OSPF external type 1/2 route type. 794 It is only applicable to OSPF routes."; 795 reference 796 "RFC 2328: OSPF Version 2"; 797 } 798 identity ospf-external-t1-type { 799 base ospf-external-type; 800 description 801 "Identity for OSPF external type 1 route type. 802 It is only applicable to OSPF routes."; 803 reference 804 "RFC 2328: OSPF Version 2"; 805 } 807 identity ospf-external-t2-type { 808 base ospf-external-type; 809 description 810 "Identity for OSPF external type 2 route type. 811 It is only applicable to OSPF routes."; 812 reference 813 "RFC 2328: OSPF Version 2"; 814 } 816 identity ospf-nssa-type { 817 base proto-route-type; 818 description 819 "Identity for OSPF NSSA type 1/2 route type. 820 It is only applicable to OSPF routes."; 821 reference 822 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 823 } 825 identity ospf-nssa-t1-type { 826 base ospf-nssa-type; 827 description 828 "Identity for OSPF NSSA type 1 route type. 829 It is only applicable to OSPF routes."; 830 reference 831 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 832 } 834 identity ospf-nssa-t2-type { 835 base ospf-nssa-type; 836 description 837 "Identity for OSPF NSSA type 2 route type. 838 It is only applicable to OSPF routes."; 839 reference 840 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 841 } 843 identity bgp-internal { 844 base proto-route-type; 845 description 846 "Identity for routes learned from internal BGP (IBGP). 847 It is only applicable to BGP routes."; 848 reference 849 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 850 } 852 identity bgp-external { 853 base proto-route-type; 854 description 855 "Identity for routes learned from external BGP (EBGP). 856 It is only applicable to BGP routes."; 857 reference 858 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 859 } 861 /* Type Definitions */ 863 typedef default-policy-type { 864 type enumeration { 865 enum accept-route { 866 description 867 "Default policy to accept the route."; 868 } 869 enum reject-route { 870 description 871 "Default policy to reject the route."; 872 } 873 } 874 description 875 "Type used to specify route disposition in 876 a policy chain. This typedef is used in 877 the default import and export policy."; 878 } 880 typedef policy-result-type { 881 type enumeration { 882 enum accept-route { 883 description 884 "Policy accepts the route."; 885 } 886 enum reject-route { 887 description 888 "Policy rejects the route."; 889 } 890 } 891 description 892 "Type used to specify route disposition in 893 a policy chain."; 895 } 897 typedef tag-type { 898 type union { 899 type uint32; 900 type yang:hex-string; 901 } 902 description 903 "Type for expressing route tags on a local system, 904 including IS-IS and OSPF; may be expressed as either decimal 905 or hexadecimal integer."; 906 reference 907 "RFC 2328: OSPF Version 2 908 RFC 5130: A Policy Control Mechanism in IS-IS Using 909 Administrative Tags"; 910 } 912 typedef match-set-options-type { 913 type enumeration { 914 enum any { 915 description 916 "Match is true if given value matches any member 917 of the defined set."; 918 } 919 enum all { 920 description 921 "Match is true if given value matches all 922 members of the defined set."; 923 } 924 enum invert { 925 description 926 "Match is true if given value does not match any 927 member of the defined set."; 928 } 929 } 930 default any; 931 description 932 "Options that govern the behavior of a match statement. The 933 default behavior is any, i.e., the given value matches any 934 of the members of the defined set."; 935 } 937 typedef metric-modification-type { 938 type enumeration { 939 enum set-metric { 940 description 941 "Set the metric to the specified value."; 942 } 943 enum add-metric { 944 description 945 "Add the specified value to the existing metric. 946 If the result would overflow the maximum metric 947 (0xffffffff), set the metric to the maximum."; 948 } 949 enum subtract-metric { 950 description 951 "Subtract the specified value from the existing metric. If 952 the result would be less than 0, set the metric to 0."; 953 } 954 } 955 description 956 "Type used to specify how to set the metric given the 957 specified value."; 958 } 960 /* Groupings */ 962 grouping prefix { 963 description 964 "Configuration data for a prefix definition. 966 The combination of mask-length-lower and mask-length-upper 967 define a range for the mask length, or single 'exact' 968 length if mask-length-lower and mask-length-upper are 969 equal. 971 Example: 192.0.2.0/24 through 192.0.2.0/26 would be 972 expressed as prefix: 192.0.2.0/24, 973 mask-length-lower=24, 974 mask-length-upper=26 976 Example: 192.0.2.0/24 (an exact match) would be 977 expressed as prefix: 192.0.2.0/24, 978 mask-length-lower=24, 979 mask-length-upper=24 981 Example: 2001:DB8::/32 through 2001:DB8::/64 would be 982 expressed as prefix: 2001:DB8::/32, 983 mask-length-lower=32, 984 mask-length-upper=64"; 986 leaf ip-prefix { 987 type inet:ip-prefix; 988 mandatory true; 989 description 990 "The IP prefix represented as an IPv6 or IPv4 network 991 number followed by a prefix length with an intervening 992 slash character as a delimiter. All members of the 993 prefix-set MUST be of the same address family as the 994 prefix-set mode."; 995 } 997 leaf mask-length-lower { 998 type uint8 { 999 range "0..128"; 1000 } 1001 description 1002 "Mask length range lower bound. It MUST NOT be less than 1003 the prefix length defined in ip-prefix."; 1004 } 1005 leaf mask-length-upper { 1006 type uint8 { 1007 range "1..128"; 1008 } 1009 must "../mask-length-upper >= ../mask-length-lower" { 1010 error-message "The upper bound MUST NOT be less" 1011 + "than lower bound."; 1012 } 1013 description 1014 "Mask length range upper bound. It MUST NOT be less than 1015 lower bound."; 1016 } 1017 } 1019 grouping match-set-options-group { 1020 description 1021 "Grouping containing options relating to how a particular set 1022 will be matched."; 1024 leaf match-set-options { 1025 type match-set-options-type; 1026 description 1027 "Optional parameter that governs the behavior of the 1028 match operation."; 1029 } 1030 } 1032 grouping match-set-options-restricted-group { 1033 description 1034 "Grouping for a restricted set of match operation 1035 modifiers."; 1037 leaf match-set-options { 1038 type match-set-options-type { 1039 enum any { 1040 description 1041 "Match is true if given value matches any 1042 member of the defined set."; 1043 } 1044 enum invert { 1045 description 1046 "Match is true if given value does not match 1047 any member of the defined set."; 1048 } 1049 } 1050 description 1051 "Optional parameter that governs the behavior of the 1052 match operation. This leaf only supports matching on 1053 'any' member of the set or 'invert' the match. 1054 Matching on 'all' is not supported."; 1055 } 1056 } 1058 grouping apply-policy-group { 1059 description 1060 "Top level container for routing policy applications. This 1061 grouping is intended to be used in routing models where 1062 needed."; 1064 container apply-policy { 1065 description 1066 "Anchor point for routing policies in the model. 1067 Import and export policies are with respect to the local 1068 routing table, i.e., export (send) and import (receive), 1069 depending on the context."; 1071 leaf-list import-policy { 1072 type leafref { 1073 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1074 "rt-pol:policy-definition/rt-pol:name"; 1075 require-instance true; 1076 } 1077 ordered-by user; 1078 description 1079 "List of policy names in sequence to be applied on 1080 receiving redistributed routes from another routing protocol 1081 or receiving a routing update in the current context, e.g., 1082 for the current peer group, neighbor, address family, etc."; 1083 } 1085 leaf default-import-policy { 1086 type default-policy-type; 1087 default reject-route; 1088 description 1089 "Explicitly set a default policy if no policy definition 1090 in the import policy chain is satisfied."; 1091 } 1093 leaf-list export-policy { 1094 type leafref { 1095 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1096 "rt-pol:policy-definition/rt-pol:name"; 1097 require-instance true; 1098 } 1099 ordered-by user; 1100 description 1101 "List of policy names in sequence to be applied on 1102 redistributing routes from one routing protocol to another 1103 or sending a routing update in the current context, e.g., 1104 for the current peer group, neighbor, address family, etc."; 1105 } 1107 leaf default-export-policy { 1108 type default-policy-type; 1109 default reject-route; 1110 description 1111 "Explicitly set a default policy if no policy definition 1112 in the export policy chain is satisfied."; 1113 } 1114 } 1115 } 1117 container routing-policy { 1118 description 1119 "Top-level container for all routing policy."; 1121 container defined-sets { 1122 description 1123 "Predefined sets of attributes used in policy match 1124 statements."; 1126 container prefix-sets { 1127 description 1128 "Data definitions for a list of IPv4 or IPv6 1129 prefixes which are matched as part of a policy."; 1130 list prefix-set { 1131 key "name mode"; 1132 description 1133 "List of the defined prefix sets"; 1135 leaf name { 1136 type string; 1137 description 1138 "Name of the prefix set -- this is used as a label to 1139 reference the set in match conditions."; 1140 } 1142 leaf mode { 1143 type enumeration { 1144 enum ipv4 { 1145 description 1146 "Prefix set contains IPv4 prefixes only."; 1147 } 1148 enum ipv6 { 1149 description 1150 "Prefix set contains IPv6 prefixes only."; 1151 } 1152 } 1153 description 1154 "Indicates the mode of the prefix set, in terms of 1155 which address families (IPv4 or IPv6) are present. 1156 The mode provides a hint, all prefixes MUST be of 1157 the indicated type. The device MUST validate that 1158 all prefixes and reject the configuration if there 1159 is a discrepancy."; 1160 } 1162 container prefixes { 1163 description 1164 "Container for the list of prefixes in a policy 1165 prefix list. Since individual prefixes do not have 1166 unique actions, the order in which the prefix in 1167 prefix-list are matched has no impact on the outcome 1168 and is left to the implementation. A given prefix-set 1169 condition is satisfied if the input prefix matches 1170 any of the prefixes in the prefix-set."; 1172 list prefix-list { 1173 key "ip-prefix mask-length-lower mask-length-upper"; 1174 description 1175 "List of prefixes in the prefix set."; 1177 uses prefix; 1178 } 1179 } 1180 } 1181 } 1182 container neighbor-sets { 1183 description 1184 "Data definition for a list of IPv4 or IPv6 1185 neighbors which can be matched in a routing policy."; 1187 list neighbor-set { 1188 key "name"; 1189 description 1190 "List of defined neighbor sets for use in policies."; 1192 leaf name { 1193 type string; 1194 description 1195 "Name of the neighbor set -- this is used as a label 1196 to reference the set in match conditions."; 1197 } 1199 leaf-list address { 1200 type inet:ip-address; 1201 description 1202 "List of IP addresses in the neighbor set."; 1203 } 1204 } 1205 } 1207 container tag-sets { 1208 description 1209 "Data definitions for a list of tags which can 1210 be matched in policies."; 1212 list tag-set { 1213 key "name"; 1214 description 1215 "List of tag set definitions."; 1217 leaf name { 1218 type string; 1219 description 1220 "Name of the tag set -- this is used as a label to 1221 reference the set in match conditions."; 1222 } 1224 leaf-list tag-value { 1225 type tag-type; 1226 description 1227 "Value of the tag set member."; 1228 } 1229 } 1231 } 1232 } 1234 container policy-definitions { 1235 description 1236 "Enclosing container for the list of top-level policy 1237 definitions."; 1239 leaf match-modified-attributes { 1240 type boolean; 1241 config false; 1242 description 1243 "This boolean value dictates whether matches are performed 1244 on the actual route attributes or route attributes 1245 modified by policy statements preceding the match."; 1246 } 1248 list policy-definition { 1249 key "name"; 1250 description 1251 "List of top-level policy definitions, keyed by unique 1252 name. These policy definitions are expected to be 1253 referenced (by name) in policy chains specified in 1254 import or export configuration statements."; 1256 leaf name { 1257 type string; 1258 description 1259 "Name of the top-level policy definition -- this name 1260 is used in references to the current policy."; 1261 } 1263 container statements { 1264 description 1265 "Enclosing container for policy statements."; 1267 list statement { 1268 key "name"; 1269 ordered-by user; 1270 description 1271 "Policy statements group conditions and actions 1272 within a policy definition. They are evaluated in 1273 the order specified."; 1275 leaf name { 1276 type string; 1277 description 1278 "Name of the policy statement."; 1280 } 1282 container conditions { 1283 description 1284 "Condition statements for the current policy 1285 statement."; 1287 leaf call-policy { 1288 type leafref { 1289 path "../../../../../../" + 1290 "rt-pol:policy-definitions/" + 1291 "rt-pol:policy-definition/rt-pol:name"; 1292 require-instance true; 1293 } 1294 description 1295 "Applies the statements from the specified policy 1296 definition and then returns control to the current 1297 policy statement. Note that the called policy 1298 may itself call other policies (subject to 1299 implementation limitations). This is intended to 1300 provide a policy 'subroutine' capability. The 1301 called policy SHOULD contain an explicit or a 1302 default route disposition that returns an 1303 effective true (accept-route) or false 1304 (reject-route), otherwise the behavior may be 1305 ambiguous."; 1306 } 1308 leaf source-protocol { 1309 type identityref { 1310 base rt:control-plane-protocol; 1311 } 1312 description 1313 "Condition to check the protocol / method used to 1314 install the route into the local routing table."; 1315 } 1317 container match-interface { 1318 leaf interface { 1319 type leafref { 1320 path "/if:interfaces/if:interface/if:name"; 1321 } 1322 description 1323 "Reference to a base interface."; 1324 } 1325 description 1326 "Container for interface match conditions"; 1327 } 1328 container match-prefix-set { 1329 leaf prefix-set { 1330 type leafref { 1331 path "../../../../../../../defined-sets/" + 1332 "prefix-sets/prefix-set/name"; 1333 } 1334 description 1335 "References a defined prefix set."; 1336 } 1337 uses match-set-options-restricted-group; 1339 description 1340 "Match a referenced prefix-set according to the 1341 logic defined in the match-set-options leaf."; 1342 } 1344 container match-neighbor-set { 1345 leaf neighbor-set { 1346 type leafref { 1347 path "../../../../../../../defined-sets/" + 1348 "neighbor-sets/neighbor-set/name"; 1349 require-instance true; 1350 } 1351 description 1352 "References a defined neighbor set."; 1353 } 1355 description 1356 "Match a referenced neighbor set."; 1357 } 1359 container match-tag-set { 1360 leaf tag-set { 1361 type leafref { 1362 path "../../../../../../../defined-sets/" + 1363 "tag-sets/tag-set/name"; 1364 require-instance true; 1365 } 1366 description 1367 "References a defined tag set."; 1368 } 1369 uses match-set-options-group; 1371 description 1372 "Match a referenced tag set according to the logic 1373 defined in the match-set-options leaf."; 1374 } 1375 container match-route-type { 1376 description 1377 "This container provides route-type match condition"; 1379 leaf-list route-type { 1380 type identityref { 1381 base proto-route-type; 1382 } 1383 description 1384 "Condition to check the protocol-specific type 1385 of route. This is normally used during route 1386 importation to select routes or to set protocol 1387 specific attributes based on the route type."; 1388 } 1389 } 1390 } 1392 container actions { 1393 description 1394 "Top-level container for policy action 1395 statements."; 1396 leaf policy-result { 1397 type policy-result-type; 1398 default reject-route; 1399 description 1400 "Select the final disposition for the route, 1401 either accept or reject."; 1402 } 1403 container set-metric { 1404 leaf metric-modification { 1405 type metric-modification-type; 1406 description 1407 "Indicates how to modify the metric."; 1408 } 1409 leaf metric { 1410 type uint32; 1411 description 1412 "Metric value to set, add, or subtract."; 1413 } 1414 description 1415 "Set the metric for the route."; 1416 } 1417 container set-metric-type { 1418 leaf metric-type { 1419 type identityref { 1420 base metric-type; 1421 } 1422 description 1423 "Route metric type."; 1424 } 1425 description 1426 "Set the metric type for the route."; 1427 } 1428 container set-route-level { 1429 leaf route-level { 1430 type identityref { 1431 base route-level; 1432 } 1433 description 1434 "Route import level."; 1435 } 1436 description 1437 "Set the level for importation or 1438 exportation of routes."; 1439 } 1440 leaf set-route-preference { 1441 type uint16; 1442 description 1443 "Set the preference for the route. It is also 1444 known as 'administrative distance', allows for 1445 selecting the preferred route among routes with 1446 the same destination prefix. A smaller value is 1447 more preferred."; 1448 } 1449 leaf set-tag { 1450 type tag-type; 1451 description 1452 "Set the tag for the route."; 1453 } 1454 leaf set-application-tag { 1455 type tag-type; 1456 description 1457 "Set the application tag for the route. 1458 The application-specific tag is an additional tag 1459 that can be used by applications that require 1460 semantics and/or policy different from that of the 1461 tag. For example, the tag is usually automatically 1462 advertised in OSPF AS-External Link State 1463 Advertisements (LSAs) while this application-specific 1464 tag is not advertised implicitly."; 1465 } 1466 } 1467 } 1468 } 1469 } 1470 } 1472 } 1473 } 1474 1476 8. Security Considerations 1478 The YANG module specified in this document defines a schema for data 1479 that is designed to be accessed via network management protocols such 1480 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1481 is the secure transport layer, and the mandatory-to-implement secure 1482 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1483 is HTTPS, and the mandatory-to-implement secure transport is TLS 1484 [RFC8446]. 1486 The NETCONF Access Control Model (NACM) [RFC8341] provides the means 1487 to restrict access for particular NETCONF or RESTCONF users to a pre- 1488 configured subset of all available NETCONF or RESTCONF protocol 1489 operations and content. 1491 There are a number of data nodes defined in this YANG module that are 1492 writable/creatable/deletable (i.e., config true, which is the 1493 default). These data nodes may be considered sensitive or vulnerable 1494 in some network environments. Write operations (e.g., edit-config) 1495 to these data nodes without proper protection can have a negative 1496 effect on network operations. These are the subtrees and data nodes 1497 and their sensitivity/vulnerability: 1499 /routing-policy/defined-sets/prefix-sets -- Modification to 1500 prefix-sets could result in a Denial-of-Service (DoS) attack. An 1501 attacker may try to modify prefix-sets and redirect or drop 1502 traffic. Redirection of traffic could be used as part of a more 1503 elaborate attack to either collect sensitive information or 1504 masquerade a service. Additionally, a control-plane DoS attack 1505 could be accomplished by allowing a large number of routes to be 1506 leaked into a routing protocol domain (e.g., BGP). 1508 /routing-policy/defined-sets/neighbor-sets -- Modification to the 1509 neighbor-sets could be used to mount a DoS attack or more 1510 elaborate attack as with prefix-sets. For example, a DoS attack 1511 could be mounted by changing the neighbor-set from which routes 1512 are accepted. 1514 /routing-policy/defined-sets/tag-sets -- Modification to the tag- 1515 sets could be used to mount a DoS attack. Routes with certain 1516 tags might be redirected or dropped. The implications are similar 1517 to prefix-sets and neighbor-sets. However, the attack may be more 1518 difficult to detect as the routing policy usage of route tags and 1519 intent must be understood to recognize the breach. Conversely, 1520 the implications of prefix-set or neighbor set modification are 1521 easier to recognize. 1523 /routing-policy/policy-definitions/policy-definition 1524 /statements/statement/conditions -- Modification to the conditions 1525 could be used to mount a DoS attack or other attack. An attacker 1526 may change a policy condition and redirect or drop traffic. As 1527 with prefix-sets, neighbor-sets, or tag-sets, traffic redirection 1528 could be used as part of a more elaborate attack. 1530 /routing-policy/policy-definitions/policy-definition 1531 /statements/statement/actions -- Modification to actions could be 1532 used to mount a DoS attack or other attack. Traffic may be 1533 redirected or dropped. As with prefix-sets, neighbor-sets, or 1534 tag-sets, traffic redirection could be used as part of a more 1535 elaborate attack. Additionally, route attributes may be changed 1536 to mount a second-level attack that is more difficult to detect. 1538 Some of the readable data nodes in the YANG module may be considered 1539 sensitive or vulnerable in some network environments. It is thus 1540 important to control read access (e.g., via get, get-config, or 1541 notification) to these data nodes. These are the subtrees and data 1542 nodes and their sensitivity/vulnerability: 1544 /routing-policy/defined-sets/prefix-sets -- Knowledge of these 1545 data nodes can be used to ascertain which local prefixes are 1546 susceptible to a Denial-of-Service (DoS) attack. 1548 /routing-policy/defined-sets/prefix-sets -- Knowledge of these 1549 data nodes can be used to ascertain local neighbors against whom 1550 to mount a Denial-of-Service (DoS) attack. 1552 /routing-policy/policy-definitions/policy-definition /statements/ 1553 -- Knowledge of these data nodes can be used to attack the local 1554 router with a Denial-of-Service (DoS) attack. Additionally, 1555 policies and their attendant conditions and actions should be 1556 considered proprietary and disclosure could be used to ascertain 1557 partners, customers, and supplies. Furthermore, the policies 1558 themselves could represent intellectual property and disclosure 1559 could diminish their corresponding business advantage. 1561 Routing policy configuration has a significant impact on network 1562 operations, and, as such, other YANG models that reference routing 1563 policies are also susceptible to vulnerabilities relating the YANG 1564 data nodes specified above. 1566 9. IANA Considerations 1568 This document registers a URI in the IETF XML registry [RFC3688]. 1569 Following the format in [RFC3688], the following registration is 1570 requested to be made: 1572 URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy 1573 Registrant Contact: The IESG. 1574 XML: N/A, the requested URI is an XML namespace. 1576 This document registers a YANG module in the YANG Module Names 1577 registry [RFC6020]. 1579 name: ietf-routing-policy 1580 namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy 1581 prefix: rt-pol 1582 reference: RFC XXXX 1584 10. Acknowledgements 1586 The routing policy module defined in this document is based on the 1587 OpenConfig route policy model. The authors would like to thank to 1588 OpenConfig for their contributions, especially Anees Shaikh, Rob 1589 Shakir, Kevin D'Souza, and Chris Chase. 1591 The authors are grateful for valuable contributions to this document 1592 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1593 George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, 1594 Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and 1595 John Heasley. 1597 Thanks to Mahesh Jethanandani, John Scudder, Chris Bower and Tom 1598 Petch for their reviews and comments. 1600 11. References 1602 11.1. Normative references 1604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1605 Requirement Levels", BCP 14, RFC 2119, 1606 DOI 10.17487/RFC2119, March 1997, 1607 . 1609 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1610 DOI 10.17487/RFC2328, April 1998, 1611 . 1613 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1614 RFC 3101, DOI 10.17487/RFC3101, January 2003, 1615 . 1617 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1618 DOI 10.17487/RFC3688, January 2004, 1619 . 1621 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1622 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1623 DOI 10.17487/RFC4271, January 2006, 1624 . 1626 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 1627 Control Mechanism in IS-IS Using Administrative Tags", 1628 RFC 5130, DOI 10.17487/RFC5130, February 2008, 1629 . 1631 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 1632 Distribution with Two-Level IS-IS", RFC 5302, 1633 DOI 10.17487/RFC5302, October 2008, 1634 . 1636 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1637 the Network Configuration Protocol (NETCONF)", RFC 6020, 1638 DOI 10.17487/RFC6020, October 2010, 1639 . 1641 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1642 and A. Bierman, Ed., "Network Configuration Protocol 1643 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1644 . 1646 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1647 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1648 . 1650 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1651 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1652 . 1654 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1655 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1656 . 1658 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1659 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1660 . 1662 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1663 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1664 May 2017, . 1666 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1667 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1668 . 1670 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1671 Access Control Model", STD 91, RFC 8341, 1672 DOI 10.17487/RFC8341, March 2018, 1673 . 1675 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1676 and R. Wilton, "Network Management Datastore Architecture 1677 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1678 . 1680 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1681 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1682 . 1684 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1685 Routing Management (NMDA Version)", RFC 8349, 1686 DOI 10.17487/RFC8349, March 2018, 1687 . 1689 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1690 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1691 . 1693 11.2. Informative references 1695 [I-D.ietf-idr-bgp-model] 1696 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1697 YANG Model for Service Provider Networks", draft-ietf-idr- 1698 bgp-model-11 (work in progress), July 2021. 1700 Appendix A. Routing protocol-specific policies 1702 Routing models that require the ability to apply routing policy may 1703 augment the routing policy model with protocol or other specific 1704 policy configuration. The routing policy model assumes that 1705 additional defined sets, conditions, and actions may all be added by 1706 other models. 1708 The example below provides an illustration of how another data model 1709 can augment parts of this routing policy data model. It uses 1710 specific examples from draft-ietf-idr-bgp-model-09 to show in a 1711 concrete manner how the different pieces fit together. This example 1712 is not normative with respect to [I-D.ietf-idr-bgp-model]. The model 1713 similarly augments BGP-specific conditions and actions in the 1714 corresponding sections of the routing policy model. In the example 1715 below, the XPath prefix "bp:" specifies import from the ietf-bgp- 1716 policy sub-module and the XPath prefix "bt:" specifies import from 1717 the ietf-bgp-types sub-module [I-D.ietf-idr-bgp-model]. 1719 module: ietf-routing-policy 1720 +--rw routing-policy 1721 +--rw defined-sets 1722 | +--rw prefix-sets 1723 | | +--rw prefix-set* [name] 1724 | | +--rw name string 1725 | | +--rw mode? enumeration 1726 | | +--rw prefixes 1727 | | +--rw prefix-list* [ip-prefix mask-length-lower 1728 | | mask-length-upper] 1729 | | +--rw ip-prefix inet:ip-prefix 1730 | | +--rw mask-length-lower uint8 1731 | | +--rw mask-length-upper uint8 1732 | +--rw neighbor-sets 1733 | | +--rw neighbor-set* [name] 1734 | | +--rw name string 1735 | | +--rw address* inet:ip-address 1736 | +--rw tag-sets 1737 | | +--rw tag-set* [name] 1738 | | +--rw name string 1739 | | +--rw tag-value* tag-type 1740 | +--rw bp:bgp-defined-sets 1741 | +--rw bp:community-sets 1742 | | +--rw bp:community-set* [name] 1743 | | +--rw bp:name string 1744 | | +--rw bp:member* union 1745 | +--rw bp:ext-community-sets 1746 | | +--rw bp:ext-community-set* [name] 1747 | | +--rw bp:name string 1748 | | +--rw bp:member* union 1749 | +--rw bp:as-path-sets 1750 | +--rw bp:as-path-set* [name] 1751 | +--rw bp:name string 1752 | +--rw bp:member* string 1753 +--rw policy-definitions 1754 +--ro match-modified-attributes? boolean 1755 +--rw policy-definition* [name] 1756 +--rw name string 1757 +--rw statements 1758 +--rw statement* [name] 1759 +--rw name string 1760 +--rw conditions 1761 | +--rw call-policy? 1762 | +--rw source-protocol? identityref 1763 | +--rw match-interface 1764 | | +--rw interface? 1765 | +--rw match-prefix-set 1766 | | +--rw prefix-set? prefix-set/name 1767 | | +--rw match-set-options? match-set-options-type 1768 | +--rw match-neighbor-set 1769 | | +--rw neighbor-set? 1770 | +--rw match-tag-set 1771 | | +--rw tag-set? 1772 | | +--rw match-set-options? match-set-options-type 1773 | +--rw match-route-type* identityref 1774 | +--rw bp:bgp-conditions 1775 | +--rw bp:med-eq? uint32 1776 | +--rw bp:origin-eq? bt:bgp-origin-attr-type 1777 | +--rw bp:next-hop-in* inet:ip-address-no-zone 1778 | +--rw bp:afi-safi-in* identityref 1779 | +--rw bp:local-pref-eq? uint32 1780 | +--rw bp:route-type? enumeration 1781 | +--rw bp:community-count 1782 | +--rw bp:as-path-length 1783 | +--rw bp:match-community-set 1784 | | +--rw bp:community-set? 1785 | | +--rw bp:match-set-options? 1786 | +--rw bp:match-ext-community-set 1787 | | +--rw bp:ext-community-set? 1788 | | +--rw bp:match-set-options? 1789 | +--rw bp:match-as-path-set 1790 | +--rw bp:as-path-set? 1791 | +--rw bp:match-set-options? 1792 +--rw actions 1793 +--rw policy-result? policy-result-type 1794 +--rw set-metric 1795 | +--rw metric-modification? 1796 | +--rw metric? uint32 1797 +--rw set-metric-type 1798 | +--rw metric-type? identityref 1799 +--rw set-route-level 1800 | +--rw route-level? identityref 1801 +--rw set-route-preference? uint16 1802 +--rw set-tag? tag-type 1803 +--rw set-application-tag? tag-type 1804 +--rw bp:bgp-actions 1805 +--rw bp:set-route-origin?bt:bgp-origin-attr-type 1806 +--rw bp:set-local-pref? uint32 1807 +--rw bp:set-next-hop? bgp-next-hop-type 1808 +--rw bp:set-med? bgp-set-med-type 1809 +--rw bp:set-as-path-prepend 1810 | +--rw bp:repeat-n? uint8 1811 +--rw bp:set-community 1812 | +--rw bp:method? enumeration 1813 | +--rw bp:options? 1814 | +--rw bp:inline 1815 | | +--rw bp:communities* union 1816 | +--rw bp:reference 1817 | +--rw bp:community-set-ref? 1818 +--rw bp:set-ext-community 1819 +--rw bp:method? enumeration 1820 +--rw bp:options? 1821 +--rw bp:inline 1822 | +--rw bp:communities* union 1823 +--rw bp:reference 1824 +--rw bp:ext-community-set-ref? 1826 Appendix B. Policy examples 1828 Below we show examples of XML-encoded configuration data using the 1829 routing policy and BGP models to illustrate both how policies are 1830 defined, and how they can be applied. Note that the XML has been 1831 simplified for readability. 1833 The following example shows how prefix-set and tag-set can be 1834 defined. The policy condition is to match a prefix-set and a tag- 1835 set, and the action is to accept routes that match the condition. 1837 1838 1841 1842 1843 1844 prefix-set-A 1845 ipv4 1846 1847 1848 192.0.2.0/24 1849 24 1850 32 1851 1852 1853 198.51.100.0/24 1854 24 1855 32 1856 1857 1858 1859 1860 prefix-set-B 1861 ipv6 1862 1863 1864 2001:DB8::/32 1865 32 1866 64 1867 1868 1869 1870 1871 1872 1873 cust-tag1 1874 10 1875 1876 1877 1879 1880 1881 export-tagged-BGP 1882 1883 1884 term-0 1885 1886 1887 prefix-set-A 1888 1889 1890 cust-tag1 1891 1892 1893 1894 accept-route 1895 1896 1897 1898 1899 1901 1903 1905 In the following example, all routes in the RIB that have been 1906 learned from OSPF advertisements corresponding to OSPF intra-area and 1907 inter-area route types should get advertised into ISIS level-2 1908 advertisements. 1910 1911 1913 1914 1915 export-all-OSPF-prefixes-into-ISIS-level-2 1916 1917 1918 term-0 1919 1920 ospf-internal-type 1921 1922 1923 1924 isis-level-2 1925 1926 accept-route 1927 1928 1929 1930 1931 1932 1933 1935 Authors' Addresses 1937 Yingzhen Qu 1938 Futurewei 1939 2330 Central Expressway 1940 Santa Clara CA 95050 1941 USA 1943 Email: yingzhen.qu@futurewei.com 1944 Jeff Tantsura 1945 Juniper Networks 1947 Email: jefftant.ietf@gmail.com 1949 Acee Lindem 1950 Cisco 1951 301 Midenhall Way 1952 Cary, NC 27513 1953 US 1955 Email: acee@cisco.com 1957 Xufeng Liu 1958 Volta Networks 1960 Email: xufeng.liu.ietf@gmail.com