A YANG Data Model for Routing Policy ManagementHuawei2330 Central ExpresswaySanta ClaraCA 95050USAyingzhen.qu@huawei.comNuage Networksjefftant.ietf@gmail.comCisco301 Mindenhall WayCaryNC27513USacee@cisco.comJabil8281 Greensboro Drive, Suite 200McleanVA22102USxufeng_liu@jabil.comGoogle1600 Amphitheatre PkwyMountain ViewCA94043USaashaikh@google.com
Routing
RTGWGThis document defines a YANG data model for configuring and
managing routing policies in a vendor-neutral way and based on
actual operational practice. The model provides a generic policy
framework which can be augmented with protocol-specific policy
configuration.
This document describes a YANG data model for routing policy configuration based on operational
usage and best practices in a variety of service provider
networks. The model is intended to be vendor-neutral, in order
to allow operators to manage policy configuration in a
consistent, intuitive way in heterogeneous
environments with routers supplied by multiple vendors.
The YANG modules in this document conform to the Network Management Datastore
Architecture (NMDA).
This model does not aim to be feature complete -- it is a
subset of the policy configuration parameters available
in a variety of vendor implementations, but supports widely
used constructs for managing how routes are imported,
exported, and modified across different routing protocols.
The model development approach has been to examine actual
policy configurations in use across a number of operator
networks. Hence the focus is on enabling policy configuration
capabilities and structure that are in wide use.
Despite the differences in details of policy expressions and
conventions in various vendor implementations, the model
reflects the observation that a relatively simple condition-action
approach can be readily mapped to several existing vendor
implementations, and also gives operators an intuitive and
straightforward way to express policy without sacrificing
flexibility. A side affect of this design decision is that
legacy methods for expressing policies are not considered. Such
methods could be added as an augmentation to the model if
needed.
Consistent with the goal to produce a data model that is vendor
neutral, only policy expressions that are deemed to be widely
available in existing major implementations are included in the
model. Those configuration items that are only available from
a single implementation are omitted from the model with the
expectation they will be available in separate vendor-provided
modules that augment the current model.
The routing policy module has three main parts:
A generic framework to express policies as sets of related
conditions and actions. This includes match sets and actions
that are useful across many routing protocols.
A structure that allows routing protocol models to add
protocol-specific policy conditions and actions though
YANG augmentations. There is a complete example of this
for BGP policies in the proposed vendor-neutral
BGP data model.
A reusable grouping for attaching import and export rules in
the context of routing configuration for different
protocols, VRFs, etc. This also enables creation of policy
chains and expressing default policy behavior.
The module makes use of the standard Internet types,
such as IP addresses, autonomous system numbers, etc.,
defined in RFC 6991.
Policies are expressed as a sequence of top-level policy
definitions each of which consists of a sequence of policy statements.
Policy statements in turn consist of simple condition-action
tuples. Conditions may include multiple match or comparison
operations, and similarly, actions may effect multiple changes to
route attributes, or indicate a final disposition of accepting
or rejecting the route. This structure is shown below.
The models provides a set of generic sets that can be used for
matching in policy conditions. These sets are applicable for
route selection across multiple routing protocols. They may be
further augmented by
protocol-specific models which have their own defined sets. The
supported defined sets include:
prefix sets - define a set of IP prefixes, each with an
associated CIDR netmask range (or exact length)
neighbor sets - define a set of neighboring nodes by their
IP addresses. These sets are used for selecting routes based on the
neighbors advertising the routes.
tag set - define a set of generic tag values that can be used
in matches for filtering routes
The model structure for defined sets is shown below.
Policy statements consist of a set of conditions and actions
(either 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 specific value.
Match conditions may be further modified using the
match-set-options configuration which allows operators to
change the behavior of a match. Three options are supported:
ALL - match is true only if the given value matches
all members of the set.
ANY - match is true if the given value matches any
member of the set.
INVERT - match is true if the given value does not
match any member of the given set.
Not all options are appropriate for matching against all
defined sets (e.g., match ALL in a prefix set does not make sense).
In the model, a restricted set of match options is used where
applicable.
Comparison conditions may similarly use options to change how
route attributes should be tested, e.g., for equality or
inequality, against a given value.
While most policy conditions will be added by individual
routing protocol models via augmentation, this routing policy
model includes several generic match conditions and also the
ability to test which protocol or mechanism installed a route
(e.g., BGP, IGP, static, etc.). The conditions included in
the model are shown below.
When policy conditions are satisfied, policy actions are used
to set various attributes of the route being processed, or to
indicate the final disposition of the route, i.e., accept or
reject.
Similar to policy conditions, the routing policy model includes
generic actions in addition to the basic route
disposition actions. These are shown below.
Policy 'subroutines' (or nested policies) are
supported by allowing policy statement conditions to reference
other policy definitions using the call-policy configuration.
Called policies apply their conditions and
actions before returning to the calling policy statement and
resuming evaluation. The outcome of 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 subroutine returns an effective boolean true value to
the calling policy. For the calling policy, this is equivalent
to a condition statement evaluating to a true value and
evaluation of the policy continues
(see ). Note that
the called policy may also modify attributes of the route in
its action statements. Similarly, a reject-route action
returns false and the calling policy evaluation 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
to implementation limitations). The model does not prescribe a
nesting depth because this varies among implementations. For example,
some major implementation may only support a single level of
subroutine recursion. As with any routing policy construction, care
must be taken with nested policies to ensure that the effective
return value results in the intended behavior. Nested policies
are a convenience in many routing policy constructions but
creating policies nested beyond a small number of levels (e.g., 2-3)
should be discouraged.
Evaluation of each policy definition proceeds by evaluating its
corresponding individual policy statements in order. When a
condition statement in a policy statement is satisfied, the
corresponding action statement is executed. If the action
statement has either accept-route or reject-route actions,
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
the next policy statement. If none of the policy statement
conditions are satisfied, then evaluation of the current policy
definition stops, and the next policy definition in the chain is
evaluated. When the end of the policy chain is reached, the
default route disposition action is performed (i.e., reject-route
unless an alternate default action is specified for the
chain).
Routing policy is applied by defining and attaching policy chains
in various routing contexts. Policy chains are sequences of
policy definitions (described in ) that have an associated direction (import or export)
with respect to the routing context in which they are defined.
The routing policy model defines an apply-policy grouping that
can be imported and used by other models. As shown below, it
allows definition of import and export policy chains, as well as
specifying the default route disposition to be used when no
policy definition in the chain results in a final decision.
The default policy defined by the model is to reject the route for
both import and export policies.
Routing models that require the ability to apply routing policy
may augment the routing policy model with protocol or other
specific policy configuration. The routing policy model
assumes that additional defined sets, conditions, and actions
may all be added by other models.
An example of this is shown below, in which the BGP configuration
model in
adds new defined sets to match on community values or AS paths.
The model similarly augments BGP-specific conditions and actions
in the corresponding sections of the routing policy model.
Routing policy configuration has a significant impact on network operations,
and, as such, any related model carries potential security risks.
YANG data models are generally designed to be used with the
NETCONF protocol over an SSH transport. This provides an
authenticated and secure channel over which to transfer
configuration and operational data. Note that use of
alternate transport or data encoding (e.g., JSON over HTTPS)
would require similar mechanisms for authenticating and
securing access to configuration data.
Most of the data elements in the policy model could be
considered sensitive from a security standpoint. Unauthorized
access or invalid data could cause major disruption.
This YANG data model and the component modules currently use
a temporary ad-hoc namespace. If and when it is placed on redirected for
the standards track, an appropriate namespace URI will be
registered in the IETF XML Registry".
The routing policy YANG modules will be registered in the
"YANG Module Names" registry [RFC6020].
The routing policy model is described by the YANG modules in the
sections below.
Below we show an example of XML-encoded configuration data using
the routing policy and BGP models to illustrate both how policies
are defined, and also how they can be applied. Note that the XML
has been simplified for readability.
YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)Tail-f SystemsA Border Gateway Protocol 4 (BGP-4)Common YANG Data TypesJacobs UniversityThe IETF XML RegistryVerisign, Inc.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 and the associated models from: Ebben Aires, Luyuan Fang,
Josh George, Acee Lindem, Stephane Litkowski, Ina Minei,
Carl Moberg, Eric Osborne, Steve Padgett, Juergen Schoenwaelder,
Jim Uttaro, and Russ White.
Updated the model to use IETF modules and be NMDA compliant.
Updated policy model with additional condition for matching interfaces.
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.