< draft-ietf-rtgwg-policy-model-01.txt   draft-ietf-rtgwg-policy-model-02.txt >
Network Working Group A. Shaikh RTGWG Y. Qu
Internet-Draft Google Internet-Draft Huawei
Intended status: Informational R. Shakir Intended status: Informational J. Tantsura
Expires: October 8, 2016 Jive Communications Expires: September 4, 2018 Nuage Networks
K. D'Souza A. Lindem
C. Chase Cisco
AT&T X. Liu
April 6, 2016 Jabil
A. Shaikh
Google
March 3, 2018
Routing Policy Configuration Model for Service Provider Networks A YANG Data Model for Routing Policy Management
draft-ietf-rtgwg-policy-model-01 draft-ietf-rtgwg-policy-model-02
Abstract Abstract
This document defines a YANG data model for configuring and managing This document defines a YANG data model for configuring and managing
routing policies in a vendor-neutral way and based on actual routing policies in a vendor-neutral way and based on actual
operational practice. The model provides a generic policy framework operational practice. The model provides a generic policy framework
which can be augmented with protocol-specific policy configuration. which can be augmented with protocol-specific policy configuration.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 8, 2016. This Internet-Draft will expire on September 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Goals and approach . . . . . . . . . . . . . . . . . . . 2 1.1. Goals and approach . . . . . . . . . . . . . . . . . . . 3
2. Model overview . . . . . . . . . . . . . . . . . . . . . . . 3 2. Model overview . . . . . . . . . . . . . . . . . . . . . . . 3
3. Route policy expression . . . . . . . . . . . . . . . . . . . 4 3. Route policy expression . . . . . . . . . . . . . . . . . . . 4
3.1. Defined sets for policy matching . . . . . . . . . . . . 4 3.1. Defined sets for policy matching . . . . . . . . . . . . 4
3.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 5 3.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 5
3.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 6 3.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 6
3.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 7 3.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 7
4. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 7 4. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 7
5. Applying routing policy . . . . . . . . . . . . . . . . . . . 8 5. Applying routing policy . . . . . . . . . . . . . . . . . . . 8
6. Routing protocol-specific policies . . . . . . . . . . . . . 9 6. Routing protocol-specific policies . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. YANG modules . . . . . . . . . . . . . . . . . . . . . . . . 11 9. YANG modules . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Routing policy model . . . . . . . . . . . . . . . . . . 11 9.1. Routing policy model . . . . . . . . . . . . . . . . . . 10
9.2. Routing policy types . . . . . . . . . . . . . . . . . . 34 10. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 26
10. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.1. Normative references . . . . . . . . . . . . . . . . . . 27
11.1. Normative references . . . . . . . . . . . . . . . . . . 39 11.2. Informative references . . . . . . . . . . . . . . . . . 27
11.2. Informative references . . . . . . . . . . . . . . . . . 40 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40 Appendix B. Change summary . . . . . . . . . . . . . . . . . . . 28
Appendix B. Change summary . . . . . . . . . . . . . . . . . . . 40 B.1. Changes between revisions -01 and -02 . . . . . . . . . . 28
B.1. Changes between revisions -00 and -01 . . . . . . . . . . 40 B.2. Changes between revisions -00 and -01 . . . . . . . . . . 28
B.2. Changes between revisions draft-shaikh-rtgwg-policy-model B.3. Changes between revisions draft-shaikh-rtgwg-policy-model
and -00 . . . . . . . . . . . . . . . . . . . . . . . . . 40 and -00 . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document describes a YANG [RFC6020] data model for routing This document describes a YANG [RFC6020] [RFC7950] data model for
policy configuration based on operational usage and best practices in routing policy configuration based on operational usage and best
a variety of service provider networks. The model is intended to be practices in a variety of service provider networks. The model is
vendor-neutral, in order to allow operators to manage policy intended to be vendor-neutral, in order to allow operators to manage
configuration in a consistent, intuitive way in heterogeneous policy configuration in a consistent, intuitive way in heterogeneous
environments with routers supplied by multiple vendors. environments with routers supplied by multiple vendors.
The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA)[I-D.ietf-netmod-revised-datastores].
1.1. Goals and approach 1.1. Goals and approach
This model does not aim to be feature complete -- it is a subset of This model does not aim to be feature complete -- it is a subset of
the policy configuration parameters available in a variety of vendor the policy configuration parameters available in a variety of vendor
implementations, but supports widely used constructs for managing how implementations, but supports widely used constructs for managing how
routes are imported, exported, and modified across different routing routes are imported, exported, and modified across different routing
protocols. The model development approach has been to examine actual protocols. The model development approach has been to examine actual
policy configurations in use across a number of operator networks. policy configurations in use across a number of operator networks.
Hence the focus is on enabling policy configuration capabilities and Hence the focus is on enabling policy configuration capabilities and
structure that are in wide use. structure that are in wide use.
Despite the differences in details of policy expressions and Despite the differences in details of policy expressions and
conventions in various vendor implementations, the model reflects the conventions in various vendor implementations, the model reflects the
observation that a relatively simple condition- action approach can observation that a relatively simple condition-action approach can be
be readily mapped to several existing vendor implementations, and readily mapped to several existing vendor implementations, and also
also gives operators an intuitive and straightforward way to express gives operators an intuitive and straightforward way to express
policy without sacrificing flexibility. A side affect of this design policy without sacrificing flexibility. A side affect of this design
decision is that legacy methods for expressing policies are not decision is that legacy methods for expressing policies are not
considered. Such methods could be added as an augmentation to the considered. Such methods could be added as an augmentation to the
model if needed. model if needed.
Consistent with the goal to produce a data model that is vendor Consistent with the goal to produce a data model that is vendor
neutral, only policy expressions that are deemed to be widely neutral, only policy expressions that are deemed to be widely
available in existing major implementations are included in the available in existing major implementations are included in the
model. Those configuration items that are only available from a model. Those configuration items that are only available from a
single implementation are omitted from the model with the expectation single implementation are omitted from the model with the expectation
they will be available in separate vendor-provided modules that they will be available in separate vendor-provided modules that
augment the current model. augment the current model.
2. Model overview 2. Model overview
The routing policy model is defined in two YANG modules, the main The routing policy module has three main parts:
policy module, and an auxiliary module providing additional generic
types. The model has three main parts:
o A generic framework to express policies as sets of related o A generic framework to express policies as sets of related
conditions and actions. This includes match sets and actions that conditions and actions. This includes match sets and actions that
are useful across many routing protocols. are useful across many routing protocols.
o A structure that allows routing protocol models to add protocol- o A structure that allows routing protocol models to add protocol-
specific policy conditions and actions though YANG augmentations. specific policy conditions and actions though YANG augmentations.
There is a complete example of this for BGP [RFC4271] policies in There is a complete example of this for BGP [RFC4271] policies in
the proposed vendor-neutral BGP data model the proposed vendor-neutral BGP data model
[I-D.ietf-idr-bgp-model]. [I-D.ietf-idr-bgp-model].
o A reusable grouping for attaching import and export rules in the o A reusable grouping for attaching import and export rules in the
context of routing configuration for different protocols, VRFs, context of routing configuration for different protocols, VRFs,
etc. This also enables creation of policy chains and expressing etc. This also enables creation of policy chains and expressing
default policy behavior. default policy behavior.
These modules make use of the standard Internet types, such as IP The module makes use of the standard Internet types, such as IP
addresses, autonomous system numbers, etc., defined in RFC 6991 addresses, autonomous system numbers, etc., defined in RFC 6991
[RFC6991]. [RFC6991].
3. Route policy expression 3. Route policy expression
Policies are expressed as a sequence of top-level policy definitions Policies are expressed as a sequence of top-level policy definitions
each of which consists of a sequence of policy statements. Policy each of which consists of a sequence of policy statements. Policy
statements in turn consist of simple condition-action tuples. statements in turn consist of simple condition-action tuples.
Conditions may include multiple match or comparison operations, and Conditions may include multiple match or comparison operations, and
similarly, actions may effect multiple changes to route attributes, similarly, actions may effect multiple changes to route attributes,
skipping to change at page 4, line 30 skipping to change at page 4, line 34
+--rw statement* [name] +--rw statement* [name]
+--rw name string +--rw name string
+--rw conditions +--rw conditions
| ... | ...
+--rw actions +--rw actions
... ...
3.1. Defined sets for policy matching 3.1. Defined sets for policy matching
The models provides a set of generic sets that can be used for The models provides a set of generic sets that can be used for
matching in policy conditions. These sets are applicable across matching in policy conditions. These sets are applicable for route
multiple routing protocols, and may be further augmented by protocol- selection across multiple routing protocols. They may be further
specific models which have their own defined sets. The supported augmented by protocol-specific models which have their own defined
defined sets include: sets. The supported defined sets include:
o prefix sets - define a set of IP prefixes, each with an associated o prefix sets - define a set of IP prefixes, each with an associated
CIDR netmask range (or exact length) CIDR netmask range (or exact length)
o neighbor sets - define a set of neighboring nodes by their IP o neighbor sets - define a set of neighboring nodes by their IP
addresses addresses. These sets are used for selecting routes based on the
neighbors advertising the routes.
o tag set - define a set of generic tag values that can be used in o tag set - define a set of generic tag values that can be used in
matches for filtering routes matches for filtering routes
The model structure for defined sets is shown below. The model structure for defined sets is shown below.
+--rw routing-policy +--rw routing-policy
+--rw defined-sets +--rw defined-sets
+--rw prefix-sets | +--rw prefix-sets
| +--rw prefix-set* [prefix-set-name] | | +--rw prefix-set* [name]
| +--rw prefix-set-name string | | +--rw name string
| +--rw prefix* [ip-prefix masklength-range] | | +--rw mode? enumeration
| +--rw ip-prefix inet:ip-prefix | | +--rw prefixes
| +--rw masklength-range string | | +--rw prefix* [ip-prefix masklength-range]
+--rw neighbor-sets | | +--rw ip-prefix inet:ip-prefix
| +--rw neighbor-set* [neighbor-set-name] | | +--rw masklength-range string
| +--rw neighbor-set-name string | +--rw neighbor-sets
| +--rw neighbor* [address] | | +--rw neighbor-set* [name]
| +--rw address inet:ip-address | | +--rw name string
+--rw tag-sets | | +--rw address* inet:ip-address
+--rw tag-set* [tag-set-name] | +--rw tag-sets
+--rw tag-set-name string | +--rw tag-set* [name]
+--rw tag* [value] | +--rw name string
+--rw value pt:tag-type | +--rw tag-value* tag-type
3.2. Policy conditions 3.2. Policy conditions
Policy statements consist of a set of conditions and actions (either Policy statements consist of a set of conditions and actions (either
of which may be empty). Conditions are used to match route of which may be empty). Conditions are used to match route
attributes against a defined set (e.g., a prefix set), or to compare attributes against a defined set (e.g., a prefix set), or to compare
attributes against a specific value. attributes against a specific value.
Match conditions may be further modified using the match-set-options Match conditions may be further modified using the match-set-options
configuration which allows operators to change the behavior of a configuration which allows operators to change the behavior of a
skipping to change at page 6, line 11 skipping to change at page 6, line 11
Comparison conditions may similarly use options to change how route Comparison conditions may similarly use options to change how route
attributes should be tested, e.g., for equality or inequality, attributes should be tested, e.g., for equality or inequality,
against a given value. against a given value.
While most policy conditions will be added by individual routing While most policy conditions will be added by individual routing
protocol models via augmentation, this routing policy model includes protocol models via augmentation, this routing policy model includes
several generic match conditions and also the ability to test which several generic match conditions and also the ability to test which
protocol or mechanism installed a route (e.g., BGP, IGP, static, protocol or mechanism installed a route (e.g., BGP, IGP, static,
etc.). The conditions included in the model are shown below. etc.). The conditions included in the model are shown below.
+--rw routing-policy +--rw routing-policy
+--rw policy-definitions +--rw policy-definitions
+--rw policy-definition* [name] +--rw policy-definition* [name]
+--rw statements +--rw name string
+--rw statement* [name] +--rw statements
+--rw conditions +--rw statement* [name]
+--rw call-policy? +--rw conditions
+--rw match-interface? | +--rw call-policy?
+--rw match-prefix-set! | +--rw install-protocol-eq?
| +--rw prefix-set? | +--rw match-interface
| +--rw match-set-options? | | +--rw interface?
+--rw match-neighbor-set! | +--rw match-prefix-set
| +--rw neighbor-set? | | +--rw prefix-set?
| +--rw match-set-options? | | +--rw match-set-options?
+--rw match-tag-set! | +--rw match-neighbor-set
| +--rw tag-set? | | +--rw neighbor-set?
| +--rw match-set-options? | | +--rw match-set-options?
+--rw install-protocol-eq? | | match-set-options-restricted-type
+--rw igp-conditions | +--rw match-tag-set
| +--rw tag-set?
| +--rw match-set-options?
match-set-options-restricted-type
3.3. Policy actions 3.3. Policy actions
When policy conditions are satisfied, policy actions are used to set When policy conditions are satisfied, policy actions are used to set
various attributes of the route being processed, or to indicate the various attributes of the route being processed, or to indicate the
final disposition of the route, i.e., accept or reject. final disposition of the route, i.e., accept or reject.
Similar to policy conditions, the routing policy model includes Similar to policy conditions, the routing policy model includes
generic actions in addition to the basic route disposition actions. generic actions in addition to the basic route disposition actions.
These are shown below. These are shown below.
+--rw routing-policy +--rw routing-policy
+--rw policy-definitions +--rw policy-definitions
+--rw policy-definition* [name] +--rw policy-definition* [name]
+--rw statements +--rw statements
+--rw statement* [name] +--rw statement* [name]
+--rw actions +--rw actions
+--rw (route-disposition)? +--rw policy-result? policy-result-type
| +--:(accept-route)
| | +--rw accept-route? empty
| +--:(reject-route)
| +--rw reject-route? empty
+--rw igp-actions
+--rw set-tag? pt:tag-type
3.4. Policy subroutines 3.4. Policy subroutines
Policy 'subroutines' (or nested policies) are supported by allowing Policy 'subroutines' (or nested policies) are supported by allowing
policy statement conditions to reference other policy definitions policy statement conditions to reference other policy definitions
using the call-policy configuration. Called policies apply their using the call-policy configuration. Called policies apply their
conditions and actions before returning to the calling policy conditions and actions before returning to the calling policy
statement and resuming evaluation. The outcome of the called policy statement and resuming evaluation. The outcome of the called policy
affects the evaluation of the calling policy. If the called policy affects the evaluation of the calling policy. If the called policy
results in an accept-route (either explicit or by default), then the results in an accept-route (either explicit or by default), then the
subroutine returns an effective boolean true value to the calling subroutine returns an effective boolean true value to the calling
policy. For the calling policy, this is equivalent to a condition policy. For the calling policy, this is equivalent to a condition
statement evaluating to a true value and evaluation of the policy statement evaluating to a true value and evaluation of the policy
continues (see Section 4). Note that the called policy may also continues (see Section 4). Note that the called policy may also
modify attributes of the route in its action statements. Similarly, modify attributes of the route in its action statements. Similarly,
a reject-route action returns false and the calling policy evaluation a reject-route action returns false and the calling policy evaluation
will be affected accordingly. will be affected accordingly. Consequently, a subroutine cannot
explicitly accept or reject a route. Rather it merely provides an
indication that 'call-policy' condition returns boolean true or false
indicating whether or not the condition matches. Route acceptance or
rejection is solely determined by the top-level policy.
Note that the called policy may itself call other policies (subject Note that the called policy may itself call other policies (subject
to implementation limitations). The model does not prescribe a to implementation limitations). The model does not prescribe a
nesting depth because this varies among implementations, with some nesting depth because this varies among implementations. For
major implementations only supporting a single subroutine, for example, some major implementation may only support a single level of
example. As with any routing policy construction, care must be taken subroutine recursion. As with any routing policy construction, care
with nested policies to ensure that the effective return value must be taken with nested policies to ensure that the effective
results in the intended behavior. Nested policies are a convenience return value results in the intended behavior. Nested policies are a
in many routing policy constructions but creating policies nested convenience in many routing policy constructions but creating
beyond a small number of levels (e.g., 2-3) should be discouraged. policies nested beyond a small number of levels (e.g., 2-3) should be
discouraged.
4. Policy evaluation 4. Policy evaluation
Evaluation of each policy definition proceeds by evaluating its Evaluation of each policy definition proceeds by evaluating its
corresponding individual policy statements in order. When a corresponding individual policy statements in order. When a
condition statement in a policy statement is satisfied, the condition statement in a policy statement is satisfied, the
corresponding action statement is executed. If the action statement corresponding action statement is executed. If the action statement
has either accept-route or reject-route actions, evaluation of the has either accept-route or reject-route actions, evaluation of the
current policy definition stops, and no further policy definitions in current policy definition stops, and no further policy definitions in
the chain are evaluated. the chain are evaluated.
If the condition is not satisfied, then evaluation proceeds to the If the condition is not satisfied, then evaluation proceeds to the
next policy statement. If none of the policy statement conditions next policy statement. If none of the policy statement conditions
are satisfied, then evaluation of the current policy definition are satisfied, then evaluation of the current policy definition
stops, and the next policy definition in the chain is evaluated. stops, and the next policy definition in the chain is evaluated.
When the end of the policy chain is reached, the default route When the end of the policy chain is reached, the default route
disposition action is performed (i.e., reject-route unless an an disposition action is performed (i.e., reject-route unless an
alternate default action is specified for the chain). alternate default action is specified for the chain).
5. Applying routing policy 5. Applying routing policy
Routing policy is applied by defining and attaching policy chains in Routing policy is applied by defining and attaching policy chains in
various routing contexts. Policy chains are sequences of policy various routing contexts. Policy chains are sequences of policy
definitions (described in Section 3) that have an associated definitions (described in Section 3) that have an associated
direction (import or export) with respect to the routing context in direction (import or export) with respect to the routing context in
which they are defined. The routing policy model defines an apply- which they are defined. The routing policy model defines an apply-
policy grouping that can be imported and used by other models. As policy grouping that can be imported and used by other models. As
shown below, it allows definition of import and export policy chains, shown below, it allows definition of import and export policy chains,
as well as specifying the default route disposition to be used when as well as specifying the default route disposition to be used when
no policy definition in the chain results in a final decision. no policy definition in the chain results in a final decision.
+--rw apply-policy +--rw apply-policy
| +--rw config | +--rw import-policy*
| | +--rw import-policy* | +--rw default-import-policy? default-policy-type
| | +--rw default-import-policy? default-policy-type | +--rw export-policy*
| | +--rw export-policy* | +--rw default-export-policy? default-policy-type
| | +--rw default-export-policy? default-policy-type
The default policy defined by the model is to reject the route for The default policy defined by the model is to reject the route for
both import and export policies. both import and export policies.
An example of using the apply-policy group in another routing model
is shown below for BGP. Here, import and export policies are applied
in the context of a particular BGP peer group. Note that the policy
chains reference policy definitions by name that are defined in the
routing policy model.
+--rw bgp!
+--rw peer-groups
+--rw peer-group* [peer-group-name]
+--rw peer-group-name
+--rw config
| +--rw peer-as?
| +--rw local-as?
| +--rw peer-type?
| +--rw auth-password?
| +--rw remove-private-as?
| +--rw route-flap-damping?
| +--rw send-community?
| +--rw description?
| +--rw peer-group-name?
+--ro state
| +--ro peer-as?
| +--ro local-as?
| +--ro peer-type?
| +--ro auth-password?
| +--ro remove-private-as?
| +--ro route-flap-damping?
| +--ro send-community?
| +--ro description?
| +--ro peer-group-name?
| +--ro total-paths?
| +--ro total-prefixes?
+--rw apply-policy
| +--rw config
| | +--rw import-policy*
| | +--rw default-import-policy?
| | +--rw export-policy*
| | +--rw default-export-policy?
| +--ro state
| +--ro import-policy*
| +--ro default-import-policy?
| +--ro export-policy*
| +--ro default-export-policy?
...
6. Routing protocol-specific policies 6. Routing protocol-specific policies
Routing models that require the ability to apply routing policy may Routing models that require the ability to apply routing policy may
augment the routing policy model with protocol or other specific augment the routing policy model with protocol or other specific
policy configuration. The routing policy model assumes that policy configuration. The routing policy model assumes that
additional defined sets, conditions, and actions may all be added by additional defined sets, conditions, and actions may all be added by
other models. other models.
An example of this is shown below, in which the BGP configuration An example of this is shown below, in which the BGP configuration
model in [I-D.ietf-idr-bgp-model] adds new defined sets to match on model in [I-D.ietf-idr-bgp-model] adds new defined sets to match on
community values or AS paths. The model similarly augments BGP- community values or AS paths. The model similarly augments BGP-
specific conditions and actions into the corresponding sections of specific conditions and actions in the corresponding sections of the
the routing policy model. routing policy model.
+--rw routing-policy +--rw routing-policy
+--rw defined-sets +--rw defined-sets
+--rw prefix-sets +--rw prefix-sets
| +--rw prefix-set* [prefix-set-name] | +--rw prefix-set* [prefix-set-name]
| +--rw prefix-set-name | +--rw prefix-set-name
| +--rw prefix* [ip-prefix masklength-range] | +--rw prefix* [ip-prefix masklength-range]
| +--rw ip-prefix | +--rw ip-prefix
| +--rw masklength-range | +--rw masklength-range
+--rw neighbor-sets +--rw neighbor-sets
| +--rw neighbor-set* [neighbor-set-name] | +--rw neighbor-set* [neighbor-set-name]
| +--rw neighbor-set-name | +--rw neighbor-set-name
| +--rw neighbor* [address] | +--rw neighbor* [address]
| +--rw address | +--rw address
+--rw tag-sets +--rw tag-sets
| +--rw tag-set* [tag-set-name] | +--rw tag-set* [tag-set-name]
| +--rw tag-set-name | +--rw tag-set-name
| +--rw tag* [value] | +--rw tag* [value]
| +--rw value | +--rw value
+--rw bgp-pol:bgp-defined-sets +--rw bgp-pol:bgp-defined-sets
+--rw bgp-pol:community-sets +--rw bgp-pol:community-sets
| +--rw bgp-pol:community-set* [community-set-name] | +--rw bgp-pol:community-set* [community-set-name]
| +--rw bgp-pol:community-set-name | +--rw bgp-pol:community-set-name
| +--rw bgp-pol:community-member* | +--rw bgp-pol:community-member*
+--rw bgp-pol:ext-community-sets +--rw bgp-pol:ext-community-sets
| +--rw bgp-pol:ext-community-set* [ext-community-set-name] | +--rw bgp-pol:ext-community-set*
| +--rw bgp-pol:ext-community-set-name | [ext-community-set-name]
| +--rw bgp-pol:ext-community-member* | +--rw bgp-pol:ext-community-set-name
+--rw bgp-pol:as-path-sets | +--rw bgp-pol:ext-community-member*
+--rw bgp-pol:as-path-set* [as-path-set-name] +--rw bgp-pol:as-path-sets
+--rw bgp-pol:as-path-set-name +--rw bgp-pol:as-path-set* [as-path-set-name]
+--rw bgp-pol:as-path-set-member* +--rw bgp-pol:as-path-set-name
+--rw bgp-pol:as-path-set-member*
7. Security Considerations 7. Security Considerations
Routing policy configuration has a significant impact on network Routing policy configuration has a significant impact on network
operations, and as such any related model carries potential security operations, and, as such, any related model carries potential
risks. security risks.
YANG data models are generally designed to be used with the NETCONF YANG data models are generally designed to be used with the NETCONF
protocol over an SSH transport. This provides an authenticated and protocol over an SSH transport. This provides an authenticated and
secure channel over which to transfer configuration and operational secure channel over which to transfer configuration and operational
data. Note that use of alternate transport or data encoding (e.g., data. Note that use of alternate transport or data encoding (e.g.,
JSON over HTTPS) would require similar mechanisms for authenticating JSON over HTTPS) would require similar mechanisms for authenticating
and securing access to configuration data. and securing access to configuration data.
Most of the data elements in the policy model could be considered Most of the data elements in the policy model could be considered
sensitive from a security standpoint. Unauthorized access or invalid sensitive from a security standpoint. Unauthorized access or invalid
skipping to change at page 11, line 27 skipping to change at page 10, line 25
YANG modules will be registered in the "YANG Module Names" registry YANG modules will be registered in the "YANG Module Names" registry
[RFC6020]. [RFC6020].
9. YANG modules 9. YANG modules
The routing policy model is described by the YANG modules in the The routing policy model is described by the YANG modules in the
sections below. sections below.
9.1. Routing policy model 9.1. Routing policy model
<CODE BEGINS> file "openconfig-routing-policy.yang" <CODE BEGINS> file "ietf-routing-policy@2018-02-26.yang"
module openconfig-routing-policy { module ietf-routing-policy {
yang-version "1";
// namespace yang-version "1.1";
namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
prefix rt-pol;
prefix "oc-rpol"; import ietf-inet-types {
prefix "inet";
}
// import some basic types import ietf-yang-types {
import ietf-inet-types { prefix inet; } prefix "yang";
import openconfig-interfaces { prefix oc-if; } }
import openconfig-policy-types { prefix oc-pol-types; }
import openconfig-extensions { prefix oc-ext; }
// meta import ietf-interfaces {
organization prefix "if";
"OpenConfig working group"; }
import ietf-routing {
prefix "rt";
}
import ietf-interfaces-common {
prefix if-cmn;
}
import ietf-if-l3-vlan {
prefix "if-l3-vlan";
}
organization
"IETF RTGWG - Routing Area Working Group";
contact contact
"OpenConfig working group "WG Web: <http://tools.ietf.org/wg/rtgwg/>
netopenconfig@googlegroups.com"; WG List: <mailto:rtgwg@ietf.org>
Editor: Yingzhen Qu
<mailto:yingzhen.qu@huawei.com>
Jeff Tantsura
<mailto:jefftant.ietf@gmail.com>
Acee Lindem
<mailto:acee@cisco.com>
Xufeng Liu
<mailto:xufeng_liu@jabil.com>
Anees Shaikh
<mailto:aashaikh@google.com>";
description description
"This module describes a YANG model for routing policy "This module describes a YANG model for routing policy
configuration. It is a limited subset of all of the policy configuration. It is a limited subset of all of the policy
configuration parameters available in the variety of vendor configuration parameters available in the variety of vendor
implementations, but supports widely used constructs for managing implementations, but supports widely used constructs for
how routes are imported, exported, and modified across different managing how routes are imported, exported, and modified across
routing protocols. This module is intended to be used in different routing protocols. This module is intended to be used
conjunction with routing protocol configuration models (e.g., in conjunction with routing protocol configuration modules
BGP) defined in other modules. (e.g., BGP) defined in other models.
Route policy expression:
Policies are expressed as a set of top-level policy definitions, Route policy expression:
each of which consists of a sequence of policy statements. Policy
statements consist of simple condition-action tuples. Conditions
may include mutiple match or comparison operations, and similarly
actions may be multitude of changes to route attributes or a
final disposition of accepting or rejecting the route.
Route policy evaluation: Policies are expressed as a set of top-level policy definitions,
each of which consists of a sequence of policy statements.
Policy statements consist of simple condition-action tuples.
Conditions may include mutiple match or comparison operations,
and similarly actions may be multitude of changes to route
attributes or a final disposition of accepting or rejecting the
route.
Policy definitions are referenced in routing protocol Route policy evaluation:
configurations using import and export configuration statements.
The arguments are members of an ordered list of named policy
definitions which comprise a policy chain, and optionally, an
explicit default policy action (i.e., reject or accept).
Evaluation of each policy definition proceeds by evaluating its Policy definitions are referenced in routing protocol
corresponding individual policy statements in order. When a configurations using import and export configuration statements.
condition statement in a policy statement is satisfied, the The arguments are members of an ordered list of named policy
corresponding action statement is executed. If the action definitions which comprise a policy chain, and optionally, an
statement has either accept-route or reject-route actions, policy explicit default policy action (i.e., reject or accept).
evaluation of the current policy definition stops, and no further
policy definitions in the chain are evaluated.
If the condition is not satisfied, then evaluation proceeds to Evaluation of each policy definition proceeds by evaluating its
the next policy statement. If none of the policy statement corresponding individual policy statements in order. When a
conditions are satisfied, then evaluation of the current policy condition statement in a policy statement is satisfied, the
definition stops, and the next policy definition in the chain is corresponding action statement is executed. If the action
evaluated. When the end of the policy chain is reached, the statement has either accept-route or reject-route actions,
default route disposition action is performed (i.e., reject-route policy evaluation of the current policy definition stops, and
unless an an alternate default action is specified for the no further policy definitions in the chain are evaluated.
chain).
Policy 'subroutines' (or nested policies) are supported by If the condition is not satisfied, then evaluation proceeds to
allowing policy statement conditions to reference another policy the next policy statement. If none of the policy statement
definition which applies conditions and actions from the conditions are satisfied, then evaluation of the current policy
referenced policy before returning to the calling policy definition stops, and the next policy definition in the chain is
statement and resuming evaluation. If the called policy evaluated. When the end of the policy chain is reached, the
results in an accept-route (either explicit or by default), then default route disposition action is performed (i.e.,
the subroutine returns an effective true value to the calling reject-route unless an alternate default action is specified
policy. Similarly, a reject-route action returns false. If the for the chain).
subroutine returns true, the calling policy continues to evaluate
the remaining conditions (using a modified route if the
subroutine performed any changes to the route).";
oc-ext:openconfig-version "2.0.0"; Policy 'subroutines' (or nested policies) are supported by
allowing policy statement conditions to reference another policy
definition which applies conditions and actions from the
referenced policy before returning to the calling policy
statement and resuming evaluation. If the called policy
results in an accept-route (either explicit or by default), then
the subroutine returns an effective true value to the calling
policy. Similarly, a reject-route action returns false. If the
subroutine returns true, the calling policy continues to
evaluate the remaining conditions (using a modified route if the
subroutine performed any changes to the route).";
revision "2016-03-28" { revision "2018-02-26" {
description description
"OpenConfig public release"; "Initial revision.";
reference "2.0.0"; reference
"RFC XXXX: Routing Policy Configuration Model for Service
Provider Networks";
} }
// typedef statements // typedef statements
typedef default-policy-type { typedef default-policy-type {
// this typedef retained for name compatibiity with default
// import and export policy
type enumeration { type enumeration {
enum ACCEPT_ROUTE { enum accept-route {
description "default policy to accept the route"; description
"Default policy to accept the route";
} }
enum REJECT_ROUTE { enum reject-route {
description "default policy to reject the route"; description
"Default policy to reject the route";
} }
} }
description "type used to specify default route disposition in description
a policy chain"; "Type used to specify route disposition in
a policy chain";
}
typedef policy-result-type {
type enumeration {
enum accept-route {
description "Policy accepts the route";
}
enum reject-route {
description "Policy rejects the route";
}
}
description
"Type used to specify route disposition in
a policy chain";
}
typedef tag-type {
type union {
type uint32;
type yang:hex-string;
}
description "Type for expressing route tags on a local system,
including IS-IS and OSPF; may be expressed as either decimal
or hexadecimal integer";
reference
"RFC 2178 - OSPF Version 2
RFC 5130 - A Policy Control Mechanism in IS-IS Using
Administrative Tags";
}
typedef match-set-options-type {
type enumeration {
enum any {
description "Match is true if given value matches any member
of the defined set";
}
enum all {
description "Match is true if given value matches all
members of the defined set";
}
enum invert {
description "Match is true if given value does not match any
member of the defined set";
}
}
default any;
description
"Options that govern the behavior of a match statement. The
default behavior is any, i.e., the given value matches any
of the members of the defined set";
} }
// grouping statements // grouping statements
grouping prefix-set-config { grouping prefix-set {
description description
"Configuration data for prefix sets used in policy "Configuration data for prefix sets used in policy
definitions."; definitions.";
leaf prefix-set-name { leaf name {
type string; type string;
description description
"name / label of the prefix set -- this is used to "Name of the prefix set -- this is used as a label to
reference the set in match conditions"; reference the set in match conditions";
}
leaf mode {
type enumeration {
enum ipv4 {
description
"Prefix set contains IPv4 prefixes only";
}
enum ipv6 {
description
"Prefix set contains IPv6 prefixes only";
}
enum mixed {
description
"Prefix set contains mixed IPv4 and IPv6 prefixes";
}
}
description
"Indicates the mode of the prefix set, in terms of which
address families (IPv4, IPv6, or both) are present. The
mode provides a hint, but the device must validate that all
prefixes are of the indicated type, and is expected to
reject the configuration if there is a discrepancy. The
MIXED mode may not be supported on devices that require
prefix sets to be of only one address family.";
} }
}
grouping prefix-set-state {
description
"Operational state data for prefix sets";
} }
grouping prefix-set-top { grouping prefix-set-top {
description description
"Top-level data definitions for a list of IPv4 or IPv6 "Top-level data definitions for a list of IPv4 or IPv6
prefixes which are matched as part of a policy"; prefixes which are matched as part of a policy";
container prefix-sets { container prefix-sets {
description description
"Enclosing container "; "Enclosing container ";
list prefix-set { list prefix-set {
key prefix-set-name; key "name";
description description
"List of the defined prefix sets"; "List of the defined prefix sets";
leaf prefix-set-name { uses prefix-set;
type leafref {
path "../config/prefix-set-name";
}
description
"Reference to prefix name list key";
}
container config {
description
"Configuration data for prefix sets";
uses prefix-set-config;
}
container state {
config false;
description
"Operational state data ";
uses prefix-set-config;
uses prefix-set-state;
}
uses prefix-top; uses prefix-top;
} }
} }
} }
grouping prefix-config { grouping prefix {
description description
"Configuration data for a prefix definition"; "Configuration data for a prefix definition";
leaf ip-prefix { leaf ip-prefix {
type inet:ip-prefix; type inet:ip-prefix;
mandatory true; mandatory true;
description description
"The prefix member in CIDR notation -- while the "The prefix member in CIDR notation -- while the
prefix may be either IPv4 or IPv6, most prefix may be either IPv4 or IPv6, most
implementations require all members of the prefix set implementations require all members of the prefix set
to be the same address family. Mixing address types in to be the same address family. Mixing address types in
the same prefix set is likely to cause an error."; the same prefix set is likely to cause an error.";
} }
leaf masklength-range { leaf masklength-range {
type string { type string {
pattern '^([0-9]+\.\.[0-9]+)|exact$'; pattern '([0-9]{2}\.\.[0-9]{2})|([0-9]{2})';
} }
description description
"Defines a range for the masklength, or 'exact' if "Defines a range for the masklength, or 'exact' if
the prefix has an exact length. the prefix has an exact length.
Example: 10.3.192.0/21 through 10.3.192.0/24 would be Example: 10.3.192.0/21 through 10.3.192.0/24 would be
expressed as prefix: 10.3.192.0/21, expressed as prefix: 10.3.192.0/21,
masklength-range: 21..24. masklength-range: 21..24.
Example: 10.3.192.0/21 would be expressed as Example: 10.3.192.0/21 would be expressed as
prefix: 10.3.192.0/21, prefix: 10.3.192.0/21,
masklength-range: exact"; masklength-range: exact";
} }
} }
grouping prefix-state {
description
"Operational state data for prefix definitions";
}
grouping prefix-top { grouping prefix-top {
description description
"Top-level grouping for prefixes in a prefix list"; "Top-level grouping for prefixes in a prefix list";
container prefixes { container prefixes {
description description
"Enclosing container for the list of prefixes in a policy "Enclosing container for the list of prefixes in a policy
prefix list"; prefix list";
list prefix { list prefix-list {
key "ip-prefix masklength-range"; key "ip-prefix masklength-range";
description description
"List of prefixes in the prefix set"; "List of prefixes in the prefix set";
leaf ip-prefix { uses prefix;
type leafref {
path "../config/ip-prefix";
}
description
"Reference to the ip-prefix list key.";
}
leaf masklength-range {
type leafref {
path "../config/masklength-range";
}
description
"Reference to the masklength-range list key";
}
container config {
description
"Configuration data for prefix definition";
uses prefix-config;
}
container state {
config false;
description
"Operational state data for prefix definition";
uses prefix-config;
uses prefix-state;
}
} }
} }
} }
grouping neighbor-set-config { grouping neighbor-set {
description description
"Configuration data for neighbor set definitions"; "This grouping provides neighbor set definitions";
leaf neighbor-set-name { leaf name {
type string; type string;
description description
"name / label of the neighbor set -- this is used to "Name of the neighbor set -- this is used as a label
reference the set in match conditions"; to reference the set in match conditions";
} }
leaf-list address { leaf-list address {
type inet:ip-address; type inet:ip-address;
description description
"List of IP addresses in the neighbor set"; "List of IP addresses in the neighbor set";
} }
} }
grouping neighbor-set-state {
description
"Operational state data for neighbor set definitions";
}
grouping neighbor-set-top { grouping neighbor-set-top {
description description
"Top-level data definition for a list of IPv4 or IPv6 "Top-level data definition for a list of IPv4 or IPv6
neighbors which can be matched in a routing policy"; neighbors which can be matched in a routing policy";
container neighbor-sets { container neighbor-sets {
description description
"Enclosing container for the list of neighbor set "Enclosing container for the list of neighbor set
definitions"; definitions";
list neighbor-set { list neighbor-set {
key neighbor-set-name; key "name";
description description
"List of defined neighbor sets for use in policies."; "List of defined neighbor sets for use in policies.";
leaf neighbor-set-name { uses neighbor-set;
type leafref {
path "../config/neighbor-set-name";
}
description
"Reference to the neighbor set name list key.";
}
container config {
description
"Configuration data for neighbor sets.";
uses neighbor-set-config;
}
container state {
config false;
description
"Operational state data for neighbor sets.";
uses neighbor-set-config;
uses neighbor-set-state;
}
} }
} }
} }
grouping tag-set-config { grouping tag-set {
description description
"Configuration data for tag set definitions."; "This grouping provides tag set definitions.";
leaf tag-set-name { leaf name {
type string; type string;
description description
"name / label of the tag set -- this is used to reference "Name of the tag set -- this is used as a label to reference
the set in match conditions"; the set in match conditions";
} }
leaf-list tag-value { leaf-list tag-value {
type oc-pol-types:tag-type; type tag-type;
description description
"Value of the tag set member"; "Value of the tag set member";
} }
} }
grouping tag-set-state {
description
"Operational state data for tag set definitions.";
}
grouping tag-set-top { grouping tag-set-top {
description description
"Top-level data definitions for a list of tags which can "Top-level data definitions for a list of tags which can
be matched in policies"; be matched in policies";
container tag-sets { container tag-sets {
description description
"Enclosing container for the list of tag sets."; "Enclosing container for the list of tag sets.";
list tag-set { list tag-set {
key tag-set-name; key "name";
description description
"List of tag set definitions."; "List of tag set definitions.";
leaf tag-set-name { uses tag-set;
type leafref {
path "../config/tag-set-name";
}
description
"Reference to the tag set name list key";
}
container config {
description
"Configuration data for tag sets";
uses tag-set-config;
}
container state {
config false;
description
"Operational state data for tag sets";
uses tag-set-config;
uses tag-set-state;
}
} }
} }
} }
grouping generic-defined-sets {
description
"Data definitions for pre-defined sets of attributes used in
policy match conditions. These sets are generic and can
be used in matching conditions in different routing
protocols.";
uses prefix-set-top;
uses neighbor-set-top;
uses tag-set-top;
}
grouping match-set-options-group { grouping match-set-options-group {
description description
"Grouping containing options relating to how a particular set "Grouping containing options relating to how a particular set
should be matched"; should be matched";
leaf match-set-options { leaf match-set-options {
type oc-pol-types:match-set-options-type; type match-set-options-type;
description description
"Optional parameter that governs the behaviour of the "Optional parameter that governs the behavior of the
match operation"; match operation";
} }
} }
grouping match-set-options-restricted-group { grouping match-set-options-restricted-group {
description description
"Grouping for a restricted set of match operation modifiers"; "Grouping for a restricted set of match operation modifiers";
leaf match-set-options { leaf match-set-options {
type oc-pol-types:match-set-options-restricted-type; type match-set-options-type {
enum any {
description "Match is true if given value matches any
member of the defined set";
}
enum invert {
description "Match is true if given value does not match
any member of the defined set";
}
}
description description
"Optional parameter that governs the behaviour of the "Optional parameter that governs the behavior of the
match operation. This leaf only supports matching on ANY match operation. This leaf only supports matching on ANY
member of the set or inverting the match. Matching on ALL is member of the set or inverting the match. Matching on ALL
not supported)"; is not supported";
} }
} }
grouping match-interface-condition-config { grouping match-interface-condition {
description
"Configuration data for interface match condition";
uses oc-if:interface-ref-common;
}
grouping match-interface-condition-state {
description
"Operational state data for interface match condition";
}
grouping match-interface-condition-top {
description description
"Top-level grouping for the interface match condition"; "This grouping provides interface match condition";
container match-interface { container match-interface {
description leaf interface {
"Top-level container for interface match conditions"; type leafref {
path "/if:interfaces/if:interface/if:name";
container config { }
description description
"Configuration data for interface match conditions"; "Reference to a base interface. If a reference to a
subinterface is required, this leaf must be specified
uses match-interface-condition-config; to indicate the base interface.";
} }
leaf subinterface {
container state { type leafref {
config false; path "/if:interfaces/if:interface/if-cmn:encapsulation"
+ "/if-l3-vlan:dot1q-vlan"
+ "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id";
}
description description
"Operational state data for interface match conditions"; "Reference to a subinterface -- this requires the base
interface to be specified using the interface leaf in
uses match-interface-condition-config; this container. If only a reference to a base interface
uses match-interface-condition-state; is requuired, this leaf should not be set.";
} }
description
"Container for interface match conditions";
} }
} }
grouping prefix-set-condition-config { grouping prefix-set-condition {
description description
"Configuration data for prefix-set conditions"; "This grouping provides prefix-set conditions";
leaf prefix-set { container match-prefix-set {
leaf prefix-set {
type leafref { type leafref {
path "/routing-policy/defined-sets/prefix-sets/" + path "../../../../../../../defined-sets/" +
"prefix-set/prefix-set-name"; "prefix-sets/prefix-set/name";
//TODO: require-instance should be added when it's
//supported in YANG 1.1
//require-instance true;
} }
description "References a defined prefix set"; description "References a defined prefix set";
} }
uses match-set-options-restricted-group; uses match-set-options-restricted-group;
}
grouping prefix-set-condition-state {
description
"Operational state data for prefix-set conditions";
}
grouping prefix-set-condition-top {
description
"Top-level grouping for prefix-set conditions";
container match-prefix-set {
description description
"Match a referenced prefix-set according to the logic "Match a referenced prefix-set according to the logic
defined in the match-set-options leaf"; defined in the match-set-options leaf";
container config {
description
"Configuration data for a prefix-set condition";
uses prefix-set-condition-config;
}
container state {
config false;
description
"Operational state data for a prefix-set condition";
uses prefix-set-condition-config;
uses prefix-set-condition-state;
}
} }
} }
grouping neighbor-set-condition-config { grouping neighbor-set-condition {
description description
"Configuration data for neighbor-set conditions"; "This grouping provides neighbor-set conditions";
leaf neighbor-set { container match-neighbor-set {
type leafref { leaf neighbor-set {
path "/routing-policy/defined-sets/neighbor-sets/" + type leafref {
"neighbor-set/neighbor-set-name"; path "../../../../../../../defined-sets/neighbor-sets/" +
//TODO: require-instance should be added when it's "neighbor-set/name";
//supported in YANG 1.1 require-instance true;
//require-instance true; }
description "References a defined neighbor set";
} }
description "References a defined neighbor set";
}
uses match-set-options-restricted-group;
}
grouping neighbor-set-condition-state {
description
"Operational state data for neighbor-set conditions";
}
grouping neighbor-set-condition-top {
description
"Top-level grouping for neighbor-set conditions";
container match-neighbor-set {
description description
"Match a referenced neighbor set according to the logic "Match a referenced neighbor set according to the logic
defined in the match-set-options-leaf"; defined in the match-set-options-leaf";
container config {
description
"Configuration data ";
uses neighbor-set-condition-config;
}
container state {
config false;
description
"Operational state data ";
uses neighbor-set-condition-config;
uses neighbor-set-condition-state;
}
} }
} }
grouping tag-set-condition-config { grouping tag-set-condition {
description description
"Configuration data for tag-set condition statements"; "This grouping provides tag-set conditions";
leaf tag-set { container match-tag-set {
type leafref { leaf tag-set {
path "/routing-policy/defined-sets/tag-sets/tag-set" + type leafref {
"/tag-set-name"; path "../../../../../../../defined-sets/tag-sets/tag-set" +
//TODO: require-instance should be added when it's "/name";
//supported in YANG 1.1 require-instance true;
//require-instance true; }
description "References a defined tag set";
} }
description "References a defined tag set"; uses match-set-options-restricted-group;
}
uses match-set-options-restricted-group;
}
grouping tag-set-condition-state {
description
"Operational state data for tag-set condition statements";
}
grouping tag-set-condition-top {
description
"Top-level grouping for tag-set conditions";
container match-tag-set {
description description
"Match a referenced tag set according to the logic defined "Match a referenced tag set according to the logic defined
in the match-options-set leaf"; in the match-options-set leaf";
container config {
description
"Configuration data for tag-set conditions";
uses tag-set-condition-config;
}
container state {
config false;
description
"Operational state data tag-set conditions";
uses tag-set-condition-config;
uses tag-set-condition-state;
}
} }
} }
grouping generic-conditions { grouping generic-conditions {
description "Condition statement definitions for checking description "Condition statement definitions for checking
membership in a generic defined set"; membership in a generic defined set";
uses match-interface-condition-top;
uses prefix-set-condition-top;
uses neighbor-set-condition-top;
uses tag-set-condition-top;
}
grouping igp-generic-conditions {
description "grouping for IGP policy conditions";
}
grouping igp-conditions {
description "grouping for IGP-specific policy conditions";
container igp-conditions {
description "Policy conditions for IGP attributes";
uses igp-generic-conditions;
} uses match-interface-condition;
uses prefix-set-condition;
uses neighbor-set-condition;
uses tag-set-condition;
} }
grouping generic-actions { grouping generic-actions {
description description
"Definitions for common set of policy action statements that "Definitions for common set of policy action statements that
manage the disposition or control flow of the policy"; manage the disposition or control flow of the policy";
choice route-disposition { leaf policy-result {
type policy-result-type;
description description
"Select the final disposition for the route, either "Select the final disposition for the route, either
accept or reject."; accept or reject.";
leaf accept-route {
type empty;
description "accepts the route into the routing table";
}
leaf reject-route {
type empty;
description "rejects the route";
}
}
}
grouping igp-actions-config {
description
"Configuration data for IGP policy actions";
leaf set-tag {
type oc-pol-types:tag-type;
description
"Set the tag value for OSPF or IS-IS routes.";
}
}
grouping igp-actions-state {
description
"Operational state data for IGP policy actions ";
}
grouping igp-actions-top {
description
"Top-level grouping ";
container igp-actions {
description
"Actions to set IGP route attributes; these actions
apply to multiple IGPs";
container config {
description
"Configuration data ";
uses igp-actions-config;
}
container state {
config false;
description
"Operational state data ";
uses igp-actions-config;
uses igp-actions-state;
}
} }
} }
grouping policy-conditions-config { grouping policy-conditions {
description description
"Configuration data for general policy conditions, i.e., those "Data for general policy conditions, i.e., those
not related to match-sets"; not related to match-sets";
leaf call-policy { leaf call-policy {
type leafref { type leafref {
path "/oc-rpol:routing-policy/" + path "../../../../../../" +
"oc-rpol:policy-definitions/" + "rt-pol:policy-definitions/" +
"oc-rpol:policy-definition/oc-rpol:name"; "rt-pol:policy-definition/rt-pol:name";
//TODO: require-instance should be added when require-instance true;
//it is supported in YANG 1.1
//require-instance true;
} }
description description
"Applies the statements from the specified policy "Applies the statements from the specified policy
definition and then returns control the current definition and then returns control the current
policy statement. Note that the called policy may policy statement. Note that the called policy may
itself call other policies (subject to itself call other policies (subject to
implementation limitations). This is intended to implementation limitations). This is intended to
provide a policy 'subroutine' capability. The provide a policy 'subroutine' capability. The
called policy should contain an explicit or a called policy should contain an explicit or a
default route disposition that returns an default route disposition that returns an
effective true (accept-route) or false effective true (accept-route) or false
(reject-route), otherwise the behavior may be (reject-route), otherwise the behavior may be
ambiguous and implementation dependent"; ambiguous and implementation dependent";
} }
leaf install-protocol-eq { leaf install-protocol-eq {
type identityref { type identityref {
base oc-pol-types:INSTALL_PROTOCOL_TYPE; base rt:control-plane-protocol;
} }
description description
"Condition to check the protocol / method used to install "Condition to check the protocol / method used to install
the route into the local routing table"; the route into the local routing table";
} }
} }
grouping policy-conditions-state {
description
"Operational state data for policy conditions";
}
grouping policy-conditions-top { grouping policy-conditions-top {
description description
"Top-level grouping for policy conditions"; "Top-level grouping for policy conditions";
container conditions { container conditions {
description description
"Condition statements for the current policy statement"; "Condition statements for the current policy statement";
container config { uses policy-conditions;
description
"Configuration data for policy conditions";
uses policy-conditions-config;
}
container state {
config false;
description
"Operational state data for policy conditions";
uses policy-conditions-config;
uses policy-conditions-state;
}
uses generic-conditions; uses generic-conditions;
uses igp-conditions;
} }
} }
grouping policy-statements-config { grouping policy-statements {
description description
"Configuration data for policy statements"; "Data for policy statements";
leaf name { leaf name {
type string; type string;
description description
"name of the policy statement"; "Name of the policy statement";
} }
} }
grouping policy-statements-state { grouping policy-actions {
description
"Operational state data for policy statements";
}
grouping policy-actions-config {
description description
"Configuration data for policy actions"; "Grouping for policy actions";
uses generic-actions; uses generic-actions;
} }
grouping policy-actions-state {
description
"Operational state data for policy actions";
}
grouping policy-actions-top { grouping policy-actions-top {
description description
"Top-level grouping for policy actions"; "Top-level grouping for policy actions";
container actions { container actions {
description description
"Top-level container for policy action statements"; "Top-level container for policy action statements";
container config { uses policy-actions;
description
"Configuration data for policy actions";
uses policy-actions-config;
}
container state {
config false;
description
"Operational state data for policy actions";
uses policy-actions-config;
uses policy-actions-state;
}
uses igp-actions-top;
} }
} }
grouping policy-statements-top { grouping policy-statements-top {
description description
"Top-level grouping for the policy statements list"; "Top-level grouping for the policy statements list";
container statements { container statements {
description description
"Enclosing container for policy statements"; "Enclosing container for policy statements";
list statement { list statement {
key name; key "name";
// TODO: names of policy statements within a policy
// definition should be optional, however, YANG
// requires a unique id for lists; not sure that a
// compound key works either -- need to investigate
// further.
ordered-by user; ordered-by user;
description description
"Policy statements group conditions and actions "Policy statements group conditions and actions
within a policy definition. They are evaluated in within a policy definition. They are evaluated in
the order specified (see the description of policy the order specified (see the description of policy
evaluation at the top of this module."; evaluation at the top of this module.";
leaf name {
type leafref {
path "../config/name";
}
description
"Reference to list key";
}
container config {
description
"Configuration data for policy statements";
uses policy-statements-config;
}
container state {
config false;
description
"Operational state data for policy statements";
uses policy-statements-config; uses policy-statements;
uses policy-statements-state;
}
uses policy-conditions-top; uses policy-conditions-top;
uses policy-actions-top; uses policy-actions-top;
} }
} }
} }
grouping defined-sets-top { grouping policy-definitions {
description
"Top-level grouping for defined set definitions";
container defined-sets {
description
"Predefined sets of attributes used in policy match
statements";
uses generic-defined-sets;
}
}
grouping policy-definitions-config {
description description
"Configuration data for policy definitions"; "This grouping provides policy definitions";
leaf name { leaf name {
type string; type string;
description description
"Name of the top-level policy definition -- this name "Name of the top-level policy definition -- this name
is used in references to the current policy"; is used in references to the current policy";
} }
}
grouping policy-definitions-state {
description
"Operational state data for policy definitions";
} }
grouping policy-definitions-top { grouping apply-policy-import {
description
"Top-level grouping for the policy definition list";
container policy-definitions {
description
"Enclosing container for the list of top-level policy
definitions";
list policy-definition {
key name;
description
"List of top-level policy definitions, keyed by unique
name. These policy definitions are expected to be
referenced (by name) in policy chains specified in import
or export configuration statements.";
leaf name {
type leafref {
path "../config/name";
}
description
"Reference to the list key";
}
container config {
description
"Configuration data for policy defintions";
uses policy-definitions-config;
}
container state {
config false;
description
"Operational state data for policy definitions";
uses policy-definitions-config;
uses policy-definitions-state;
}
uses policy-statements-top;
}
}
}
grouping routing-policy-top {
description
"Top level container for OpenConfig routing policy";
container routing-policy {
description
"Top-level container for all routing policy configuration";
uses defined-sets-top;
uses policy-definitions-top;
}
}
grouping apply-policy-import-config {
description description
"Configuration data for applying import policies"; "Grouping for applying import policies";
leaf-list import-policy { leaf-list import-policy {
type leafref { type leafref {
path "/oc-rpol:routing-policy/oc-rpol:policy-definitions/" + path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +
"oc-rpol:policy-definition/oc-rpol:name"; "rt-pol:policy-definition/rt-pol:name";
//TODO: require-instance should be added when it's require-instance true;
//supported in YANG 1.1
//require-instance true;
} }
ordered-by user; ordered-by user;
description description
"list of policy names in sequence to be applied on "List of policy names in sequence to be applied on
receiving a routing update in the current context, e.g., receiving a routing update in the current context, e.g.,
for the current peer group, neighbor, address family, for the current peer group, neighbor, address family,
etc."; etc.";
} }
leaf default-import-policy { leaf default-import-policy {
type default-policy-type; type default-policy-type;
default REJECT_ROUTE; default reject-route;
description description
"explicitly set a default policy if no policy definition "Explicitly set a default policy if no policy definition
in the import policy chain is satisfied."; in the import policy chain is satisfied.";
} }
} }
grouping apply-policy-export-config { grouping apply-policy-export {
description description
"Configuration data for applying export policies"; "Grouping for applying export policies";
leaf-list export-policy { leaf-list export-policy {
type leafref { type leafref {
path "/oc-rpol:routing-policy/oc-rpol:policy-definitions/" + path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +
"oc-rpol:policy-definition/oc-rpol:name"; "rt-pol:policy-definition/rt-pol:name";
require-instance true;
//TODO: require-instance should be added when it's
//supported in YANG 1.1
//require-instance true;
} }
ordered-by user; ordered-by user;
description description
"list of policy names in sequence to be applied on "List of policy names in sequence to be applied on
sending a routing update in the current context, e.g., sending a routing update in the current context, e.g.,
for the current peer group, neighbor, address family, for the current peer group, neighbor, address family,
etc."; etc.";
} }
leaf default-export-policy { leaf default-export-policy {
type default-policy-type; type default-policy-type;
default REJECT_ROUTE; default reject-route;
description description
"explicitly set a default policy if no policy definition "Explicitly set a default policy if no policy definition
in the export policy chain is satisfied."; in the export policy chain is satisfied.";
} }
} }
grouping apply-policy-config { grouping apply-policy {
description description
"Configuration data for routing policies"; "Configuration data for routing policies";
uses apply-policy-import-config; uses apply-policy-import;
uses apply-policy-export-config; uses apply-policy-export;
} container apply-policy-state {
description
"Operational state associated with routing policy";
grouping apply-policy-state { //TODO: identify additional state data beyond the intended
description //policy configuration.
"Operational state associated with routing policy"; }
//TODO: identify additional state data beyond the intended
//policy configuration.
} }
grouping apply-policy-group { grouping apply-policy-group {
description description
"Top level container for routing policy applications. This "Top level container for routing policy applications. This
grouping is intended to be used in routing models where grouping is intended to be used in routing models where
needed."; needed.";
container apply-policy { container apply-policy {
description description
"Anchor point for routing policies in the model. "Anchor point for routing policies in the model.
Import and export policies are with respect to the local Import and export policies are with respect to the local
routing table, i.e., export (send) and import (receive), routing table, i.e., export (send) and import (receive),
depending on the context."; depending on the context.";
container config {
description
"Policy configuration data.";
uses apply-policy-config;
}
container state {
config false; uses apply-policy;
description
"Operational state for routing policy";
uses apply-policy-config;
uses apply-policy-state;
}
} }
} }
uses routing-policy-top; container routing-policy {
}
<CODE ENDS>
9.2. Routing policy types
<CODE BEGINS> file "openconfig-policy-types.yang"
module openconfig-policy-types {
yang-version "1";
// namespace
namespace "urn:ietf:params:xml:ns:yang:ietf-policy-types";
prefix "oc-pol-types";
// import some basic types
import ietf-yang-types { prefix yang; }
import openconfig-extensions { prefix oc-ext; }
// meta
organization
"OpenConfig working group";
contact
"OpenConfig working group
netopenconfig@googlegroups.com";
description
"This module contains general data definitions for use in routing
policy. It can be imported by modules that contain protocol-
specific policy conditions and actions.";
oc-ext:openconfig-version "2.0.0";
revision "2016-03-28" {
description
"OpenConfig public release";
reference "2.0.0";
}
// identity statements
identity ATTRIBUTE_COMPARISON {
description description
"base type for supported comparison operators on route "Top-level container for all routing policy";
attributes";
}
identity ATTRIBUTE_EQ {
base ATTRIBUTE_COMPARISON;
description "== comparison";
}
identity ATTRIBUTE_GE {
base ATTRIBUTE_COMPARISON;
description ">= comparison";
}
identity ATTRIBUTE_LE {
base ATTRIBUTE_COMPARISON;
description "<= comparison";
}
typedef match-set-options-type {
type enumeration {
enum ANY {
description "match is true if given value matches any member
of the defined set";
} container defined-sets {
enum ALL { description
description "match is true if given value matches all "Predefined sets of attributes used in policy match
members of the defined set"; statements";
}
enum INVERT {
description "match is true if given value does not match any
member of the defined set";
}
}
default ANY;
description
"Options that govern the behavior of a match statement. The
default behavior is ANY, i.e., the given value matches any
of the members of the defined set";
}
typedef match-set-options-restricted-type { uses prefix-set-top;
type enumeration { uses neighbor-set-top;
enum ANY { uses tag-set-top;
description "match is true if given value matches any member
of the defined set";
}
enum INVERT {
description "match is true if given value does not match any
member of the defined set";
}
} }
default ANY;
description
"Options that govern the behavior of a match statement. The
default behavior is ANY, i.e., the given value matches any
of the members of the defined set. Note this type is a
restricted version of the match-set-options-type.";
//TODO: restriction on enumerated types is only allowed in
//YANG 1.1. Until then, we will require this additional type
}
grouping attribute-compare-operators { container policy-definitions {
description "common definitions for comparison operations in description
condition statements"; "Enclosing container for the list of top-level policy
definitions";
leaf operator { list policy-definition {
type identityref { key "name";
base ATTRIBUTE_COMPARISON;
}
description description
"type of comparison to be performed"; "List of top-level policy definitions, keyed by unique
name. These policy definitions are expected to be
} referenced (by name) in policy chains specified in import
or export configuration statements.";
leaf value { uses policy-definitions;
type uint32;
description
"value to compare with the community count";
}
}
typedef tag-type { uses policy-statements-top;
type union { }
type uint32;
type yang:hex-string;
} }
description "type for expressing route tags on a local system,
including IS-IS and OSPF; may be expressed as either decimal or
hexidecimal integer";
reference
"RFC 2178 OSPF Version 2
RFC 5130 A Policy Control Mechanism in IS-IS Using
Administrative Tags";
}
identity INSTALL_PROTOCOL_TYPE {
description
"Base type for protocols which can install prefixes into the
RIB";
}
identity BGP {
base INSTALL_PROTOCOL_TYPE;
description "BGP";
reference "RFC 4271";
}
identity ISIS {
base INSTALL_PROTOCOL_TYPE;
description "IS-IS";
reference "ISO/IEC 10589";
}
identity OSPF {
base INSTALL_PROTOCOL_TYPE;
description "OSPFv2";
reference "RFC 2328";
}
identity OSPF3 {
base INSTALL_PROTOCOL_TYPE;
description "OSPFv3";
reference "RFC 5340";
}
identity STATIC {
base INSTALL_PROTOCOL_TYPE;
description "Locally-installed static route";
}
identity DIRECTLY_CONNECTED {
base INSTALL_PROTOCOL_TYPE;
description "A directly connected route";
}
identity LOCAL_AGGREGATE {
base INSTALL_PROTOCOL_TYPE;
description "Locally defined aggregate route";
} }
} }
<CODE ENDS> <CODE ENDS>
10. Policy examples 10. Policy examples
Below we show an example of XML-encoded configuration data using the Below we show an example of XML-encoded configuration data using the
routing policy and BGP models to illustrate both how policies are routing policy and BGP models to illustrate both how policies are
defined, and also how they can be applied. Note that the XML has defined, and also how they can be applied. Note that the XML has
been simplified for readability. been simplified for readability.
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <?yfile include="file:///tmp/routing-policy-example-draft.xml"?>
<routing-policy xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
<defined-sets>
<prefix-sets>
<prefix-set>
<prefix-set-name>prefix-set-A</prefix-set-name>
<prefix>
<ip-prefix>192.0.2.0/24</ip-prefix>
<masklength-range>24..32</masklength-range>
</prefix>
<prefix>
<ip-prefix>10.0.0.0/16</ip-prefix>
<masklength-range>16..32</masklength-range>
</prefix>
<prefix>
<ip-prefix>192.168.0.0/19</ip-prefix>
<masklength-range>19..24</masklength-range>
</prefix> 11. References
</prefix-set>
</prefix-sets>
<tag-sets>
<tag-set>
<tag-set-name>cust-tag1</tag-set-name>
<tag>
<value>10</value>
</tag>
</tag-set>
</tag-sets>
</defined-sets>
<policy-definitions> 11.1. Normative references
<policy-definition>
<name>export-tagged-BGP</name>
<statements>
<statement>
<name>term-0</name>
<conditions>
<install-protocol-eq xmlns:ns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">ns:OSPF3</install-protocol-eq>
<match-tag-set>
<tag-set>cust-tag1</tag-set>
</match-tag-set>
</conditions>
<actions>
<accept-route />
</actions>
</statement>
</statements>
</policy-definition>
</policy-definitions>
</routing-policy> [I-D.ietf-netmod-revised-datastores]
</config> Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore
Architecture", draft-ietf-netmod-revised-datastores-10
(work in progress), January 2018.
11. References [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004.
11.1. Normative references [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2014. October 2014.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013. July 2013.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
2004. RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
11.2. Informative references 11.2. Informative references
[I-D.ietf-idr-bgp-model] [I-D.ietf-idr-bgp-model]
Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K., Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K.,
Bansal, D., Clemm, A., Alex, A., Jethanandani, M., and X. Bansal, D., Clemm, A., Zhdankin, A., Jethanandani, M., and
Liu, "BGP Model for Service Provider Networks", draft- X. Liu, "BGP Model for Service Provider Networks", draft-
ietf-idr-bgp-model-01 (work in progress), January 2016. ietf-idr-bgp-model-02 (work in progress), July 2016.
[I-D.openconfig-netmod-opstate]
Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling
of Operational State Data in YANG", draft-openconfig-
netmod-opstate-01 (work in progress), July 2015.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The routing policy module defined in this draft is based on the
OpenConfig route policy model. The authors would like to thank to
OpenConfig for their contributions, especially Rob Shakir, Kevin
D'Souza, and Chris Chase.
The authors are grateful for valuable contributions to this document The authors are grateful for valuable contributions to this document
and the associated models from: Ebben Aires, Luyuan Fang, Josh and the associated models from: Ebben Aires, Luyuan Fang, Josh
George, Acee Lindem, Stephane Litkowski, Ina Minei, Carl Moberg, Eric George, Acee Lindem, Stephane Litkowski, Ina Minei, Carl Moberg, Eric
Osborne, Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, and Russ Osborne, Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, and Russ
White. White.
Appendix B. Change summary Appendix B. Change summary
B.1. Changes between revisions -00 and -01 B.1. Changes between revisions -01 and -02
Updated the model to use IETF modules and be NMDA compliant.
B.2. Changes between revisions -00 and -01
Updated policy model with additional condition for matching Updated policy model with additional condition for matching
interfaces. interfaces.
B.2. Changes between revisions draft-shaikh-rtgwg-policy-model and -00 B.3. Changes between revisions draft-shaikh-rtgwg-policy-model and -00
This revision updates the draft name to reflect adoption as a working This revision updates the draft name to reflect adoption as a working
document in the RTGWG. Minor changes include updates to references document in the RTGWG. Minor changes include updates to references
and updated author contact information. and updated author contact information.
Authors' Addresses Authors' Addresses
Anees Shaikh
Google
1600 Amphitheatre Pkwy
Mountain View, CA 94043
US
Email: aashaikh@google.com Yingzhen Qu
Huawei
2330 Central Expressway
Santa Clara CA 95050
USA
Rob Shakir Email: yingzhen.qu@huawei.com
Jive Communications, Inc.
1275 West 1600 North, Suite 100
Orem, UT 84057
Email: rjs@rob.sh Jeff Tantsura
Nuage Networks
Kevin D'Souza Email: jefftant.ietf@gmail.com
AT&T
200 S. Laurel Ave Acee Lindem
Middletown, NJ Cisco
301 Mindenhall Way
Cary, NC 27513
US US
Email: kd6913@att.com Email: acee@cisco.com
Xufeng Liu
Jabil
8281 Greensboro Drive, Suite 200
Mclean, VA 22102
US
Chris Chase Email: xufeng_liu@jabil.com
AT&T
9505 Arboretum Blvd Anees Shaikh
Austin, TX Google
1600 Amphitheatre Pkwy
Mountain View, CA 94043
US US
Email: chase@labs.att.com Email: aashaikh@google.com
 End of changes. 202 change blocks. 
1189 lines changed or deleted 596 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/