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