< draft-ietf-rtgwg-policy-model-03.txt   draft-ietf-rtgwg-policy-model-04.txt >
RTGWG Y. Qu RTGWG Y. Qu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational J. Tantsura Intended status: Informational J. Tantsura
Expires: December 31, 2018 Nuage Networks Expires: April 22, 2019 Apstra
A. Lindem A. Lindem
Cisco Cisco
X. Liu X. Liu
Jabil Volta Networks
A. Shaikh October 19, 2018
Google
June 29, 2018
A YANG Data Model for Routing Policy Management A YANG Data Model for Routing Policy Management
draft-ietf-rtgwg-policy-model-03 draft-ietf-rtgwg-policy-model-04
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
skipping to change at page 1, line 40 skipping to change at page 1, line 38
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 https://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 December 31, 2018. This Internet-Draft will expire on April 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(https://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 . . . . . . . . . . . . . . . . . . . 3 1.1. Goals and approach . . . . . . . . . . . . . . . . . . . 3
2. Model overview . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
3. Route policy expression . . . . . . . . . . . . . . . . . . . 4 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Defined sets for policy matching . . . . . . . . . . . . 4 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4
3.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 5 3. Model overview . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 6 4. Route policy expression . . . . . . . . . . . . . . . . . . . 5
3.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 7 4.1. Defined sets for policy matching . . . . . . . . . . . . 6
4. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 7
5. Applying routing policy . . . . . . . . . . . . . . . . . . . 8 4.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 8
6. Routing protocol-specific policies . . . . . . . . . . . . . 8 4.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Applying routing policy . . . . . . . . . . . . . . . . . . . 10
9. YANG modules . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Routing protocol-specific policies . . . . . . . . . . . . . 10
9.1. Routing policy model . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. YANG modules . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative references . . . . . . . . . . . . . . . . . . 28 10.1. Routing policy model . . . . . . . . . . . . . . . . . . 13
11.2. Informative references . . . . . . . . . . . . . . . . . 29 11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix B. Change summary . . . . . . . . . . . . . . . . . . . 29 12.1. Normative references . . . . . . . . . . . . . . . . . . 30
B.1. Changes between revisions -01 and -02 . . . . . . . . . . 29 12.2. Informative references . . . . . . . . . . . . . . . . . 31
B.2. Changes between revisions -00 and -01 . . . . . . . . . . 29 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 31
B.3. Changes between revisions draft-shaikh-rtgwg-policy-model Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
and -00 . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document describes a YANG [RFC6020] [RFC7950] data model for This document describes a YANG [RFC6020] [RFC7950] data model for
routing policy configuration based on operational usage and best routing policy configuration based on operational usage and best
practices in a variety of service provider networks. The model is practices in a variety of service provider networks. The model is
intended to be vendor-neutral, in order to allow operators to manage intended to be vendor-neutral, in order to allow operators to manage
policy 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 The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA)[I-D.ietf-netmod-revised-datastores]. Datastore Architecture (NMDA) [RFC8342].
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
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are defined in [RFC8342]:
o client
o server
o configuration
o system state
o operational state
o intended configuration
The following terms are defined in [RFC7950]:
o action
o augment
o container
o container with presence
o data model
o data node
o feature
o leaf
o list
o mandatory node
o module
o schema tree
o RPC (Remote Procedure Call) operation
2.1. Tree Diagrams
Tree diagrams used in this document follow the notation defined in
[RFC8340].
2.2. Prefixes in Data Node Names
In this document, names of data nodes, actions, and other data model
objects are often used without a prefix, as long as it is clear from
the context in which YANG module each name is defined. Otherwise,
names are prefixed using the standard prefix associated with the
corresponding YANG module, as shown in Table 1.
+--------+------------------------+---------------------------------+
| Prefix | YANG module | Reference |
+--------+------------------------+---------------------------------+
| if | ietf-interfaces | [RFC8343] |
| | | |
| rt | ietf-routing | [RFC8349] |
| | | |
| yang | ietf-yang-types | [RFC6991] |
| | | |
| inet | ietf-inet-types | [RFC6991] |
| | | |
| if-cmn | ietf-interfaces-common | [I-D.ietf-netmod-intf-ext-yang] |
+--------+------------------------+---------------------------------+
Table 1: Prefixes and Corresponding YANG Modules
3. Model overview
The routing policy module has three main parts: The routing policy module 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
skipping to change at page 4, line 9 skipping to change at page 5, line 44
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.
The module makes 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 4. 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,
or indicate a final disposition of accepting or rejecting the route. or indicate a final disposition of accepting or rejecting the route.
This structure is shown below. This structure is shown below.
+--rw routing-policy +--rw routing-policy
skipping to change at page 4, line 31 skipping to change at page 6, line 17
+--rw policy-definition* [name] +--rw policy-definition* [name]
+--rw name string +--rw name string
+--rw statements +--rw statements
+--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 4.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 for route matching in policy conditions. These sets are applicable for route
selection across multiple routing protocols. They may be further selection across multiple routing protocols. They may be further
augmented by protocol-specific models which have their own defined augmented by protocol-specific models which have their own defined
sets. The supported 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)
skipping to change at page 5, line 26 skipping to change at page 7, line 26
| | +--rw masklength-upper uint8 | | +--rw masklength-upper uint8
| +--rw neighbor-sets | +--rw neighbor-sets
| | +--rw neighbor-set* [name] | | +--rw neighbor-set* [name]
| | +--rw name string | | +--rw name string
| | +--rw address* inet:ip-address | | +--rw address* inet:ip-address
| +--rw tag-sets | +--rw tag-sets
| +--rw tag-set* [name] | +--rw tag-set* [name]
| +--rw name string | +--rw name string
| +--rw tag-value* tag-type | +--rw tag-value* tag-type
3.2. Policy conditions 4.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
match. Three options are supported: match. Three options are supported:
skipping to change at page 6, line 36 skipping to change at page 8, line 36
| | +--rw subinterface? | | +--rw subinterface?
| +--rw match-prefix-set | +--rw match-prefix-set
| | +--rw prefix-set? | | +--rw prefix-set?
| | +--rw match-set-options? | | +--rw match-set-options?
| +--rw match-neighbor-set | +--rw match-neighbor-set
| | +--rw neighbor-set? | | +--rw neighbor-set?
| +--rw match-tag-set | +--rw match-tag-set
| +--rw tag-set? | +--rw tag-set?
| +--rw match-set-options? | +--rw match-set-options?
3.3. Policy actions 4.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 policy-result? policy-result-type +--rw policy-result? policy-result-type
+--rw set-metric? uint16 +--rw set-metric? uint32
+--rw set-preference? uint8 +--rw set-preference? uint16
3.4. Policy subroutines 4.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 5). 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. Consequently, a subroutine cannot will be affected accordingly. Consequently, a subroutine cannot
explicitly accept or reject a route. Rather it merely provides an explicitly accept or reject a route. Rather it merely provides an
indication that 'call-policy' condition returns boolean true or false indication that 'call-policy' condition returns boolean true or false
indicating whether or not the condition matches. Route acceptance or indicating whether or not the condition matches. Route acceptance or
rejection is solely determined by the top-level policy. 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. For nesting depth because this varies among implementations. For
example, some major implementation may only support a single level of example, some major implementation may only support a single level of
subroutine recursion. As with any routing policy construction, care subroutine recursion. As with any routing policy construction, care
must be taken with nested policies to ensure that the effective must be taken with nested policies to ensure that the effective
return value results in the intended behavior. Nested policies are a return value results in the intended behavior. Nested policies are a
convenience in many routing policy constructions but creating convenience in many routing policy constructions but creating
policies nested beyond a small number of levels (e.g., 2-3) should be policies nested beyond a small number of levels (e.g., 2-3) should be
discouraged. discouraged.
4. Policy evaluation 5. 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 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 6. 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 4) 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 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.
6. Routing protocol-specific policies 7. 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 in the corresponding sections of the specific conditions and actions in the corresponding sections of the
routing policy model. routing policy model.
module: ietf-routing-policy +--rw routing-policy
+--rw routing-policy +--rw defined-sets
+--rw defined-sets | +--rw prefix-sets
| +--rw prefix-sets | | +--rw prefix-set* [name]
| | +--rw prefix-set* [name] | | +--rw name string
| | +--rw name string | | +--rw mode? enumeration
| | +--rw mode? enumeration | | +--rw prefixes
| | +--rw prefixes | | +--rw prefix-list* [ip-prefix masklength-lower
| | +--rw prefix-list* [ip-prefix masklength-lower | | masklength-upper]
| | masklength-upper] | | +--rw ip-prefix inet:ip-prefix
| | +--rw ip-prefix inet:ip-prefix | | +--rw masklength-lower uint8
| | +--rw masklength-lower uint8 | | +--rw masklength-upper uint8
| | +--rw masklength-upper uint8 | +--rw neighbor-sets
| +--rw neighbor-sets | | +--rw neighbor-set* [name]
| | +--rw neighbor-set* [name] | | +--rw name string
| | +--rw name string | | +--rw address* inet:ip-address
| | +--rw address* inet:ip-address | +--rw tag-sets
| +--rw tag-sets | | +--rw tag-set* [name]
| | +--rw tag-set* [name] | | +--rw name string
| | +--rw name string | | +--rw tag-value* tag-type
| | +--rw tag-value* tag-type | +--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 string
| | +--rw bgp-pol:community-set-name string | | +--rw bgp-pol:community-member* union
| | +--rw bgp-pol:community-member* union | +--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* [ext-community-set-name] | | +--rw bgp-pol:ext-community-set-name string
| | +--rw bgp-pol:ext-community-set-name string | | +--rw bgp-pol:ext-community-member* union
| | +--rw bgp-pol:ext-community-member* union | +--rw bgp-pol:as-path-sets
| +--rw bgp-pol:as-path-sets | +--rw bgp-pol:as-path-set* [as-path-set-name]
| +--rw bgp-pol:as-path-set* [as-path-set-name] | +--rw bgp-pol:as-path-set-name string
| +--rw bgp-pol:as-path-set-name string | +--rw bgp-pol:as-path-set-member* string
| +--rw bgp-pol:as-path-set-member* string +--rw policy-definitions
+--rw policy-definitions +--rw policy-definition* [name]
+--rw policy-definition* [name] +--rw name string
+--rw name string +--rw statements
+--rw statements +--rw statement* [name]
+--rw statement* [name] +--rw name string
+--rw name string +--rw conditions
+--rw conditions | +--rw call-policy?
| +--rw call-policy? | +--rw source-protocol? identityref
| +--rw source-protocol? identityref | +--rw match-interface
| +--rw match-interface | | +--rw interface?
| | +--rw interface? | | +--rw subinterface?
| | +--rw subinterface? | +--rw match-prefix-set
| +--rw match-prefix-set | | +--rw prefix-set?
| | +--rw prefix-set? | | +--rw match-set-options? match-set-options-type
| | +--rw match-set-options? match-set-options-type | +--rw match-neighbor-set
| +--rw match-neighbor-set | | +--rw neighbor-set?
| | +--rw neighbor-set? | +--rw match-tag-set
| +--rw match-tag-set | | +--rw tag-set?
| | +--rw tag-set? | | +--rw match-set-options? match-set-options-type
| | +--rw match-set-options? match-set-options-type | +--rw bgp-pol:bgp-conditions
| +--rw bgp-pol:bgp-conditions | +--rw bgp-pol:med-eq? uint32
| +--rw bgp-pol:med-eq? uint32 | +--rw bgp-pol:origin-eq?
| +--rw bgp-pol:origin-eq? | bgp-types:bgp-origin-attr-type
| bgp-types:bgp-origin-attr-type | +--rw bgp-pol:next-hop-in*
| +--rw bgp-pol:next-hop-in* | inet:ip-address-no-zone
| inet:ip-address-no-zone | +--rw bgp-pol:afi-safi-in* identityref
| +--rw bgp-pol:afi-safi-in* identityref | +--rw bgp-pol:local-pref-eq? uint32
| +--rw bgp-pol:local-pref-eq? uint32 | +--rw bgp-pol:route-type? enumeration
| +--rw bgp-pol:route-type? enumeration | +--rw bgp-pol:community-count
| +--rw bgp-pol:community-count | +--rw bgp-pol:as-path-length
| +--rw bgp-pol:as-path-length | +--rw bgp-pol:match-community-set
| +--rw bgp-pol:match-community-set | | +--rw bgp-pol:community-set?
| | +--rw bgp-pol:community-set? | | +--rw bgp-pol:match-set-options?
| | +--rw bgp-pol:match-set-options? | match-set-options-type
| match-set-options-type | +--rw bgp-pol:match-ext-community-set
| +--rw bgp-pol:match-ext-community-set | | +--rw bgp-pol:ext-community-set?
| | +--rw bgp-pol:ext-community-set? | | +--rw bgp-pol:match-set-options?
| | +--rw bgp-pol:match-set-options? | | match-set-options-type
| | match-set-options-type | +--rw bgp-pol:match-as-path-set
| +--rw bgp-pol:match-as-path-set | +--rw bgp-pol:as-path-set?
| +--rw bgp-pol:as-path-set? | +--rw bgp-pol:match-set-options?
| +--rw bgp-pol:match-set-options? | match-set-options-type
| match-set-options-type +--rw actions
+--rw actions +--rw policy-result? policy-result-type
+--rw policy-result? policy-result-type +--rw set-metric? uint32
+--rw set-metric? uint16 +--rw set-preference? uint16
+--rw set-preference? uint8 +--rw bgp-pol:bgp-actions
+--rw bgp-pol:bgp-actions +--rw bgp-pol:set-route-origin?
+--rw bgp-pol:set-route-origin? bgp-types:bgp-origin-attr-type
bgp-types:bgp-origin-attr-type +--rw bgp-pol:set-local-pref? uint32
+--rw bgp-pol:set-local-pref? uint32 +--rw bgp-pol:set-next-hop? bgp-next-hop-type
+--rw bgp-pol:set-next-hop? bgp-next-hop-type +--rw bgp-pol:set-med? bgp-set-med-type
+--rw bgp-pol:set-med? bgp-set-med-type +--rw bgp-pol:set-as-path-prepend
+--rw bgp-pol:set-as-path-prepend | +--rw bgp-pol:repeat-n? uint8
| +--rw bgp-pol:repeat-n? uint8 +--rw bgp-pol:set-community
+--rw bgp-pol:set-community | +--rw bgp-pol:method? enumeration
| +--rw bgp-pol:method? enumeration | +--rw bgp-pol:options?
| +--rw bgp-pol:options? bgp-set-community-option-type
bgp-set-community-option-type | +--rw bgp-pol:inline
| +--rw bgp-pol:inline | | +--rw bgp-pol:communities* union
| | +--rw bgp-pol:communities* union | +--rw bgp-pol:reference
| +--rw bgp-pol:reference | +--rw bgp-pol:community-set-ref?
| +--rw bgp-pol:community-set-ref? +--rw bgp-pol:set-ext-community
+--rw bgp-pol:set-ext-community +--rw bgp-pol:method? enumeration
+--rw bgp-pol:method? enumeration +--rw bgp-pol:options?
+--rw bgp-pol:options? bgp-set-community-option-type
bgp-set-community-option-type +--rw bgp-pol:inline
+--rw bgp-pol:inline | +--rw bgp-pol:communities* union
| +--rw bgp-pol:communities* union +--rw bgp-pol:reference
+--rw bgp-pol:reference +--rw bgp-pol:ext-community-set-ref?
+--rw bgp-pol:ext-community-set-ref?
7. Security Considerations 8. 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 operations, and, as such, any related model carries potential
security 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
data could cause major disruption. data could cause major disruption.
8. IANA Considerations 9. IANA Considerations
This YANG data model and the component modules currently use a This YANG data model and the component modules currently use a
temporary ad-hoc namespace. If and when it is placed on redirected temporary ad-hoc namespace. If and when it is placed on redirected
for the standards track, an appropriate namespace URI will be for the standards track, an appropriate namespace URI will be
registered in the IETF XML Registry" [RFC3688]. The routing policy registered in the IETF XML Registry" [RFC3688]. The routing policy
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 10. 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 10.1. Routing policy model
<CODE BEGINS> file "ietf-routing-policy@2018-06-25.yang" <CODE BEGINS> file "ietf-routing-policy@2018-10-19.yang"
module ietf-routing-policy { module ietf-routing-policy {
yang-version "1.1"; 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 rt-pol;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
import ietf-yang-types { import ietf-yang-types {
skipping to change at page 14, line 8 skipping to change at page 16, line 8
definition which applies conditions and actions from the definition which applies conditions and actions from the
referenced policy before returning to the calling policy referenced policy before returning to the calling policy
statement and resuming evaluation. If the called policy statement and resuming evaluation. If the called policy
results in an accept-route (either explicit or by default), then results in an accept-route (either explicit or by default), then
the subroutine returns an effective true value to the calling the subroutine returns an effective true value to the calling
policy. Similarly, a reject-route action returns false. If the policy. Similarly, a reject-route action returns false. If the
subroutine returns true, the calling policy continues to subroutine returns true, the calling policy continues to
evaluate the remaining conditions (using a modified route if the evaluate the remaining conditions (using a modified route if the
subroutine performed any changes to the route)."; subroutine performed any changes to the route).";
revision "2018-06-25" { revision "2018-10-19" {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Routing Policy Configuration Model for Service "RFC XXXX: Routing Policy Configuration Model for Service
Provider Networks"; Provider Networks";
} }
// typedef statements // typedef statements
typedef default-policy-type { typedef default-policy-type {
skipping to change at page 24, line 30 skipping to change at page 26, line 30
description description
"Top-level container for policy action statements"; "Top-level container for policy action statements";
leaf policy-result { leaf policy-result {
type policy-result-type; 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 set-metric { leaf set-metric {
type uint16; type uint32;
description description
"Set a new metric for the route."; "Set a new metric for the route.";
} }
leaf set-preference { leaf set-preference {
type uint8; type uint16;
description description
"Set a new preference for the route."; "Set a new preference for the route.";
} }
} }
} }
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";
skipping to change at page 28, line 17 skipping to change at page 30, line 17
uses policy-definitions; uses policy-definitions;
uses policy-statements-top; uses policy-statements-top;
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
10. Policy examples 11. 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.
<?yfile include="file:///tmp/routing-policy-example-draft.xml"?> <?yfile include="file:///tmp/routing-policy-example-draft.xml"?>
11. References 12. References
11.1. Normative references 12.1. Normative references
[I-D.ietf-netmod-revised-datastores] [I-D.ietf-netmod-intf-ext-yang]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Wilton, R., Ball, D., tsingh@juniper.net, t., and S.
and R. Wilton, "Network Management Datastore Sivaraj, "Common Interface Extension YANG Data Models",
Architecture", draft-ietf-netmod-revised-datastores-10 draft-ietf-netmod-intf-ext-yang-06 (work in progress),
(work in progress), January 2018. July 2018.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2004. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
Protocol 4 (BGP-4)", RFC 4271, January 2006. DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Network Configuration Protocol (NETCONF)", RFC 6020, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
October 2014. DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
July 2013. the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
11.2. Informative references [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
12.2. Informative references
[I-D.ietf-idr-bgp-model] [I-D.ietf-idr-bgp-model]
Patel, K., Jethanandani, M., and S. Hares, "BGP Model for Patel, K., Jethanandani, M., and S. Hares, "BGP Model for
Service Provider Networks", draft-ietf-idr-bgp-model-03 Service Provider Networks", draft-ietf-idr-bgp-model-03
(work in progress), May 2018. (work in progress), May 2018.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The routing policy module defined in this draft is based on the The routing policy module defined in this draft is based on the
OpenConfig route policy model. The authors would like to thank to OpenConfig route policy model. The authors would like to thank to
OpenConfig for their contributions, especially Rob Shakir, Kevin OpenConfig for their contributions, especially Anees Shaikh, Rob
D'Souza, and Chris Chase. 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, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne,
Osborne, Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, and Russ Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, and Russ White.
White.
Appendix B. Change summary
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
interfaces.
B.3. Changes between revisions draft-shaikh-rtgwg-policy-model and -00
This revision updates the draft name to reflect adoption as a working
document in the RTGWG. Minor changes include updates to references
and updated author contact information.
Authors' Addresses Authors' Addresses
Yingzhen Qu Yingzhen Qu
Huawei Huawei
2330 Central Expressway 2330 Central Expressway
Santa Clara CA 95050 Santa Clara CA 95050
USA USA
Email: yingzhen.qu@huawei.com Email: yingzhen.qu@huawei.com
Jeff Tantsura Jeff Tantsura
Nuage Networks Apstra
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Acee Lindem Acee Lindem
Cisco Cisco
301 Mindenhall Way 301 Mindenhall Way
Cary, NC 27513 Cary, NC 27513
US US
Email: acee@cisco.com Email: acee@cisco.com
Xufeng Liu Xufeng Liu
Jabil Volta Networks
8281 Greensboro Drive, Suite 200
Mclean, VA 22102
US
Email: xufeng_liu@jabil.com
Anees Shaikh
Google
1600 Amphitheatre Pkwy
Mountain View, CA 94043
US
Email: aashaikh@google.com Email: xufeng.liu.ietf@gmail.com
 End of changes. 42 change blocks. 
211 lines changed or deleted 288 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/