One document matched: draft-wang-netmod-yang-policy-dm-01.txt
Differences from draft-wang-netmod-yang-policy-dm-00.txt
Network Working Group D. King
Internet-Draft Old Dog Consulting
Intended status: Standards Track Z. Wang
Expires: September 10, 2015 L. Dunbar
Q. Wu
Huawei
March 9, 2015
A Network Policy Framework using YANG Data Models
draft-wang-netmod-yang-policy-dm-01
Abstract
The purpose of a Network Policy System is to manage and control a
network as a whole. To achieve this purpose, network operators need
to control the behavior of the individual entities that comprise the
network, and this control needs to be harmonized across multiple
entities. For example, to control the access to a network, the
operator must control the behavior at all of network elements at the
edge of the network, and must apply consistent policies at those
elements.
Network Services are provided by network operators to their customers
using the resources of the network. To effectively control a
network, the operator must have knowledge of network services
supported by the network, as well as knowledge of the network
resource utilization and the capabilities of each network entity.
Control of the network to deliver the network services will involve
applying policy at individual network entities and across the whole
network, as well as controlling and allocating the resources within
the network.
This document describes a common framework and common core YANG data
model for network policies. The framework can be applied to deliver
various different network services by controlling the policies that
enable features such as Constraint-based Routing, Network QoS,
Traffic engineering, network management, etc. In future, the core
data model could be augmented by additional YANG data modules
modeling and configuring policy-related protocols and functions. The
policy data model described in this document provides common building
blocks for such extensions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
King, et al. Expires September 10, 2015 [Page 1]
Internet-Draft Network Policy Framework March 2015
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4
2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
3. A Network Policy Reference Model . . . . . . . . . . . . . . 6
4. Architecture of The Core Policy YANG Models . . . . . . . . . 8
5. Design of Network Policy Modules . . . . . . . . . . . . . . 9
5.1. Common Core Network Policy . . . . . . . . . . . . . . . 9
5.2. The Policy-Set . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Policy-role . . . . . . . . . . . . . . . . . . . . . 11
5.3. Policy-rule . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. The Policy-group . . . . . . . . . . . . . . . . . . . . 13
5.5. PolicyCondition . . . . . . . . . . . . . . . . . . . . . 13
5.6. PolicyAction . . . . . . . . . . . . . . . . . . . . . . 14
5.7. PolicyVariable . . . . . . . . . . . . . . . . . . . . . 14
5.8. PolicyValue . . . . . . . . . . . . . . . . . . . . . . . 14
5.9. Collection . . . . . . . . . . . . . . . . . . . . . . . 15
5.10. ManagedSystemElement . . . . . . . . . . . . . . . . . . 15
6. IETF Abstract Network Policy Data Hierarchy . . . . . . . . . 16
7. Design of Reusable atomic grouping . . . . . . . . . . . . . 17
King, et al. Expires September 10, 2015 [Page 2]
Internet-Draft Network Policy Framework March 2015
7.1. PolicyTimePeriodCondition . . . . . . . . . . . . . . . . 17
7.2. Reusable Variable atomic grouping . . . . . . . . . . . . 18
7.3. Reusable ip-headers filter atomic grouping . . . . . . . 18
7.4. Reusable 8021Filter atomic grouping . . . . . . . . . . . 19
7.5. Usage Examples . . . . . . . . . . . . . . . . . . . . . 20
7.5.1. Routing Policy . . . . . . . . . . . . . . . . . . . 20
7.5.2. QoS Policy . . . . . . . . . . . . . . . . . . . . . 20
8. IETF Network Policy YANG Module . . . . . . . . . . . . . . . 21
8.1. IETF policy-yang-types Yang Module . . . . . . . . . . . 21
8.1.1. IETF basic-policy Yang Module . . . . . . . . . . . . 26
9. Usage Example Module . . . . . . . . . . . . . . . . . . . . 39
9.1. Routing-Policy-Example . . . . . . . . . . . . . . . . . 40
9.2. Qos-Policy-Example . . . . . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction
The purpose of a Network Policy System is to manage and control a
network as a whole. To achieve this purpose, network operators need
to control the behavior of the individual entities that comprise the
network, and this control needs to be harmonized across multiple
entities. For example, to control the access to a network, the
operator must control the behavior at all of network elements at the
edge of the network, and must apply consistent policies at those
elements.
Network Services are provided by network operators to their customers
using the resources of the network. To effectively control a
network, the operator must have knowledge of network services
supported by the network, as well as knowledge of the network
resource utilization and the capabilities of each network entity.
Control of the network to deliver the network services will involve
applying policy at individual network entities and across the whole
network, as well as controlling and allocating the resources within
the network. Policies will often be managed for the operator by a
network policy system or policy management system.
Network service configuration can be applied based on the needs of
network applications. For example, more precise allocation of
network resources to a network service can be achieved with better
visibility of the network. To achieve this, the policy management
system is often forced to limit itself to manage only those features
common to the management interfaces common to the majority of the
King, et al. Expires September 10, 2015 [Page 3]
Internet-Draft Network Policy Framework March 2015
entities in the network since other approaches require the policy
management system to be aware of the fine-grain differences between
the management interfaces of each release of each different network
entity: implementation of policy across networks is still piecemeal
and proprietary.
The Policy Core Information Model [RFC3060] models the network as a
state machine and uses corresponding policy to aggregate a set of
policy rules to control relevant devices at any given time.
Policies can either be used in a stand-alone policy rule or
aggregated into policy group functions [RFC3060]. In order to
perform more elaborate functions, [RFC3460] defines a policy set to
aggregate policy rules and policy groups. A set of conditions is
associated with a policy rule to specify when the policy rule is
applicable. If the conditions evaluate to true, then a corresponding
set of actions will be executed.
This document describes a common framework and common core YANG data
model for network policies. The framework can be applied to deliver
various different network services by controlling the policies that
enable features such as Constraint-based Routing, Network QoS,
Traffic engineering, network management, etc. In future, the core
data model could be augmented by additional YANG data modules
modeling and configuring policy-related protocols and functions. The
policy data model described in this document provides common building
blocks for such extensions.
2. Definitions and Acronyms
ACL: Access Control List
BNP: Basic Network Policy
QoS: Quality of Service
YANG: [RFC6020]A data definition language for NETCONF[RFC6241]
The following terms defined in [RFC3198] are also used in this
document:
o Policy Conflict
o Policy Decision
King, et al. Expires September 10, 2015 [Page 4]
Internet-Draft Network Policy Framework March 2015
o Policy Decision Point (PDP)
o Policy Enforcement
o Policy Enforcement Point (PEP)
o Policy Rule
o Service Level Agreement (SLA)
o Service Level Objective (SLO)
Additionally, we defines the following terms based on the concepts
described in [RFC3198]:
Policy Consistency Checking: An analysis of multiple policies to
determine their consistency or possible inconsistency with rspect
to each other. When an inconsistency is discovered, a policy
discrepancy is reported.
Policy Provider: a function element responsible for acquiring
Policy Rules, deploying Policy Rules, Communicating the Policy
Rules, and validating Policy rules. The Policy Provider can
correspond to one or more Policy Decision points.
Policy Consumer: a functional element responsible for translating
Policy Rules and carrying out the actions indicated by the Policy
Rules. A Policy Consumer can be a Policy Enforcement Point.
2.1. Tree Diagrams
A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as
follows:
King, et al. Expires September 10, 2015 [Page 5]
Internet-Draft Network Policy Framework March 2015
Each node is printed as:
<status> <flags> <name> <opts> <type>
<status> is one of:
+ for current
x for deprecated
o for obsolete
<flags> is one of:
rw for Read/Write
ro for ReadOnly
-x for rpcs (remote procedure calls)
-n for notifications
<name> is the name of the node
If the node is augmented into the tree from another module, its name
is printed as <prefix>:<name>.
<opts> is one of:
? for an optional leaf or choice
! for a presence container
* for a leaf-list or list
[<keys>] for the keys of a particular list
Figure 1: Symbols Used in Diagrams in this Document
3. A Network Policy Reference Model
King, et al. Expires September 10, 2015 [Page 6]
Internet-Draft Network Policy Framework March 2015
Network Service Definition
|
-----------|-----------------------------------------------
| V |
| +--------------------+ +--------------------+ |
| | Policy | | Policy Repository | |
| | Management System |-------->| (Directory Server, | |
| +--------------------+ | Database, etc.) | |
| * * +--------------------+ |
| * * | |
| * * | |
| * | |
| * +-------------------------------+ |
| * | |
| * | * |
| * | * |
| * | * * * * * * * * * * * * * * * * |
| * | * |
| * | * |
----*-------|--------------------------------------*-------
* | *
---------+---------- Protocol for --------------------
| Policy Provider | Policy Mechanism | Policy Consumer |
| |<------------------>| |
-------------------- --------------------
Figure 2: Reference Model Overview
A network service definition is derived from the contractual service-
level agreements (SLA) established between the network operator and
the customer. Conversely, the SLA is defined with the definition of
the network service in mind.
The network service definition is injected into the policy management
system as policy prescription. The policy management system provides
mapping to and from the lower-level policy rule representation. A
policy repository is used for persistent storage and retrieval of
policy rules.
The policy rules are network device-independent and provide a
deterministic set of policies for managing network resources in the
policy domain. They are composed by the policy provider and consumed
by policy consumer. Before composing a policy rule, the policy
management system needs to verify whether the network resource can
meet service requirements in the network service definition by
looking up resource distribution map. If network resources can meet
the service requirements, the policy management system will produce
King, et al. Expires September 10, 2015 [Page 7]
Internet-Draft Network Policy Framework March 2015
the policy rules, store them in the policy repository using a defined
schema, and communicate with the corresponding policy provider. The
policy provider is responsible for communicating the policy rules to
the policy consumer. The policy mechanisms used by both the policy
provider and the policy consumer allow for configuring the necessary
logic in the network components. When changes are made to the
policies stored in the policy repository, the policy provider need to
be informed.
4. Architecture of The Core Policy YANG Models
In this document we define a set of common core policy models. The
YANG models defined here are generic such that they can be extended
for technology- specific needs.
The Generic Policy YANG model acts as the root for other policy YANG
models. This allows users to access policies for different
technologies through a uniform API. It also provides a nested policy
workflow.
Figure 3 depicts the relationship between the different policy YANG
models, and shows how they are all related to the Generic Policy YANG
model. Some technologies may have different sub-technologies. As an
example, consider Network QoS: this could employ either Diffserv or
Inteserv as a QoS methodology. The Generic Policy YANG model
provides a framework where technology-specific YANG models can
inherit constructs from the base YANG model or from a parent model
without needing to redefine them for each sub-technology.
King, et al. Expires September 10, 2015 [Page 8]
Internet-Draft Network Policy Framework March 2015
---------
| Generic |
| Policy |
----+----
|
|
+-----------+-------+------------+-----. . .-----+
| | | |
-----+----- ----+---- ----+---- ---------
| QoS | | ACL | | Routing |. . .| foo |
| Policy | | Policy | | Policy | | Policy |
-+--------- ----+---- ----+---- ----+----
| | | | |
-------+- -+------- | ----+---- ----+----
| IntServ | | DiffServ| | | BGP |. . .| foo |
| Policy | | Policy | | |sub-tech | |sub-tech |
---+----- -----+--- | ----+---- ----+----
| | | | |
| | | | |
---+---------------+-----------+------------+-------------+---
| Uniform API |
--------------------------------------------------------------
Figure 3: Relationship of Policy YANG Models to the Generic Policy
YANG Model
5. Design of Network Policy Modules
In this document we define a common core policy model including
several abstract nodes such as PolicyConditon, PolicyAction,
PolicyValue, PolicyVariable, etc. A new model can inherit abstract
nodes from the common core model to derive new instance class nodes
or abstract nodes. The purpose of this document is to reuse existing
class/block definitions, such as PolicyCondition, as much as
possible.
5.1. Common Core Network Policy
Policies can be used either in a stand-alone fashion when they are
called policy rules, or can be aggregated into policy groups to
perform more elaborate functions [RFC3060]. And in accordance with
[RFC3460], a policy set is inserted into the inheritance hierarchy
above both policy group and policy rule. In this document, we define
an abstract common core network policy block, and specific policies
can inherit and augment from it.
King, et al. Expires September 10, 2015 [Page 9]
Internet-Draft Network Policy Framework March 2015
This section describes the common core network policy YANG model
structure and also describes the separate elements:
Policy-Set is a set of Policies which is inserted into the
inheritance hierarchy above both policy-group and policy-rule.
Policy-Group is used to provide a hierarchical policy definition
that gives the model context or scope for each policy-rule. The
policy-group is identified by a policy group-name, and contains a
set of policy-rules. One policy-group can be nested within
another policy-group.
Policy-Rule is represented by the semantics "If Condition then
Action". A policy-rule may have a priority and a precedence
assigned to it. One policy-rule can be nested within another
policy-rule.
Figure 4 shows the high-level structure of the ietf-policy YANG
model.
module: ietf-policy
|
|- rw policy-set!
| | ....
| +--rw policy-group* [group-name]
| | ....
| +--rw policy-rule* [rule-name]
| | ....
|-rw policy-group!
|-rw policy-rule!
Figure 4: High-Level Structure of the ietf-policy YANG Model
5.2. The Policy-Set
A policy-set contain a policy-role leaf, a policy-decision-strategy
leaf, a list of policy-groups, and a list of policy-rules. A policy-
set refers to a set of policies that can be applied to multiple
device that fulfil the same role within the network.
Figure 5 shows the snippet of a policy-set.
King, et al. Expires September 10, 2015 [Page 10]
Internet-Draft Network Policy Framework March 2015
module: ietf-policy
+--rw policy-set!
+--rw PolicyRole role-type
+--rw PolicyDecisionStrategy py:policy-decision-strategy
+--rw policy-rule
| +--rw name leafref
+--rw policy-group
+--rw name leafref
......
Figure 5: Snippet of the Data Hierarchy Related to policy-set
o The policy-decision-strategy leaf is used to specify the decision
strategy for a policies. There are two matching strategies:
"First-Matching" and "All-Matching." The First-Matching strategy
is used to cause the evaluation of the rules in a set such that
the only actions enforced on a given examination of the policy-set
are those for the first rule that has its conditions evaluate to
true. The All-Matching strategy is used to cause the evaluation
of all rules in a set: for all of the rules whose conditions
evaluate to true, the actions are enforced. [RFC3460].
o The policy-role is an administratively specified characteristic of
a managed element. As a selector for policies, it determines the
applicability of the policy to a particular managed element.
o The policy-rule container contains a name leaf, this name can be
used to reference the policy-rule defined in Section 5.3.
o The policy-group container contains a name leaf, and this name can
be used to reference the policy-group defined in Section 5.4
5.2.1. Policy-role
In [RFC4011] the policy-role is described as "A role is an
administratively specified characteristic of a managed element. As a
selector for policies, it determines the applicability of the policy
to a particular managed element."
Some examples of the policy-role type have already been defined in
[RFC4011], such as political, financial, legal, geographical, and
architectural characteristics.
In this document, the policy-role is defined as an abstract property.
Specific policies can specify corresponding roles. For example, in
MPLS management one Label Switched Path (LSP) can be assigned various
roles including "primary", "secondary", "backup", and "tunnel". The
secondary LSP can be used to carry primary LSP traffic so that
King, et al. Expires September 10, 2015 [Page 11]
Internet-Draft Network Policy Framework March 2015
network resource utilization can be banlanced. When the primary LSP
fails, the backup LSP can be activiated so that network high
availability can be achieved. Tunneled LSPs can be used by other
LSPs to provide a routing service or to support traffic engineering.
5.3. Policy-rule
Policies can be used in either as stand-alone policy rules or can be
aggregated into policy groups functions [RFC3060].
Figure 6 shows the snippet of a policy-rule.
module: ietf-policy
+--rw policy-rules!
+--rw name string
+--rw policy-rule* [name]
+--rw name string
+--rw Enabled boolean
+--rw Mandatory boolean
+--rw ConditionListType py:policy-conditionlist-type
+--rw SequencedActions py:policy-sequenced-actions
+--rw ExecutionStrategy py:policy-execution-strategy
+--rw policy-condition
| +--rw name leafref
+--rw policy-action
+--rw name leafref
.......
Figure 6: Snippet of the Data Hierarchy Related to policy-rule
o name is the identification of a policy-rule. Different
occurrences of policy-rule are distinguished via the rule-name
leaf.
o The ConditionListType is an enumeration type and indicates whether
the list of policy conditions associated with this policy rule is
in disjunctive normal form (DNF) or conjunctive normal form (CNF).
o The Sequenced-Actions leaf is an enumeration type and indicate the
action ordering.
o The ExecutionStrategy leaf defines the execution strategy to be
used upon the sequenced actions is this policy-rule.
o The policy-condition container contains a name leaf, this name can
be used to reference the policy-condition defined in Section 5.5.
King, et al. Expires September 10, 2015 [Page 12]
Internet-Draft Network Policy Framework March 2015
o The policy-action container contains a name leaf, and this name
can be used to reference the policy-action defined in Section 5.3.
5.4. The Policy-group
Policy-group is a generalized container in the form of a list. This
can contain a set of policy-rules that belong to the same group
(e.g., having the same role for various policy-rules). A policy-
group list can also contains other policy-group instances, but a
policy group may not contain instances of both policy-group and
policy-rule [RFC3060].
Figure 7 shows the snippet of a policy-group list.
module: ietf-policy
+--rw policy-group!
+--rw name string
+--rw policy-groups*[name]
| +--rw name leafref
| +--rw policy-rules*[name]
+--rw name eafref
....
Figure 7: Snippet of the Data Hierarchy Related to policy-group
o Name under policy-group container is the identification of the
policy-group. Different policy-group list instances are
distinguished via the leaf group name.
o The name in policy-rules can be used to reference the rules
defined in Section 5.3 and identify each policy rule.
5.5. PolicyCondition
A policy-rule usually follows the "If Condition then Action"
semantics. In this section we define an abstract PolicyCondition
block that can be re-used flexibly. For an extended policy YANG
model, the policy-rule can extend and re-use the PolicyConditon
block.
Figure 8 shows the snippet of a PolicyCondition block.
module: ietf-policy
+--rw policy-condition!
+--rw name string
Figure 8: Snippet of the Data Hierarchy Related to PolicyCondition
King, et al. Expires September 10, 2015 [Page 13]
Internet-Draft Network Policy Framework March 2015
5.6. PolicyAction
A policy-rule usually follows the "If Condition then Action"
semantics. In this section we define an abstract PolicyAction block
which can be re-used flexibly. For an extended policy YANG model,
the policy-rule can extend and re-use the PolicyAction block.
Figure 9 shows the snippet of a PolicyAction block.
module: ietf-policy
+--rw policy-action!
+--rw name string
.....
Figure 9: Snippet of the Data Hierarchy Related to PolicyAction
5.7. PolicyVariable
A simple condition models an elementary Boolean expression of the
form "variable matches value". In this section we define an abstract
PolicyVariable block which can be re-use flexibly. For an extended
policy YANG model, the condition can extend and re-use the
PolicyVariable block.
Figure 10 shows the snippet of a PolicyVariable block.
module: ietf-policy
+--rw policy-variable!
+--rw name string
Figure 10: Snippet of the Data Hierarchy Related to PolicyVariable
5.8. PolicyValue
A simple condition models an elementary Boolean expression of the
form "variable matches value". In this section, we define an
abstract policy-value building block which can provide re-use
flexiblely. And for an extended policy yang model, the condition can
extend and reuse the policy-value block.
Figure 11 shows the snippet of a PolicyValue block.
module: ietf-policy
+--rw policy-value!
+--rw name string
Figure 11: Snippet of the Data Hierarchy Related to PolicyValue
King, et al. Expires September 10, 2015 [Page 14]
Internet-Draft Network Policy Framework March 2015
5.9. Collection
This section describes a collection of managed elements that share a
common role. The PolicyRoleCollection always exists in the context
of a system. The value of the PolicyRole property in this class
specifies the role and can be re-used in other instances of
PolicyRule or PolicyGroup.
Figure 12 shows the snippet of the data hierarchy related to the
PolicyRoleCollection.
+--rw Policy!
| +--rw PolicySet!
| ......
| +--rw Collection!
| +--rw PolicyRoleCollection!
| +--rw PolicyRole string
Figure 12: Snippet of the Data Hierarchy Related to
PolicyRoleCollection
5.10. ManagedSystemElement
The ManagedSystemElement is an abstract container that can describe
and aggregate a set of abstract managed system elements such as
LogicalElement, etc.
Figure 13 shows the snippet of the data hierarchy related to the
ManagedSystemElement.
+--rw Policy!
| +--rw PolicySet!
......
+--rw ManagedSystemElement!
+--rw LogicalElement!
+--rw System!
| +--rw AdminDomain!
| +--rw ReusablePolicyContainer!
+--rw FilterEntryBase!
+--rw FilterList* [filter-name]
+--rw filter-name string
Figure 13: Snippet of the Data Hierarchy Related to
ManagedSystemElement
King, et al. Expires September 10, 2015 [Page 15]
Internet-Draft Network Policy Framework March 2015
o ReusablePolicyContainer describes an administratively defined
container for reusable policy-related information [RFC3460].
Notice that this container does not introduce any additional
properties beyond the AdminDomain. It does, however, participate
in a number of unique associations.
o FilterEntryBase is an abstract contaienr representing a single
filter that is aggregated into a FilterList via the aggregation.
6. IETF Abstract Network Policy Data Hierarchy
Figure 14 shows the structure of the IETF Abstract Network Policy
YANG model.
module: ietf-policy
+--rw policy-set!
| +--rw PolicyRole role-type
| +--rw PolicyDecisionStrategy py:policy-decision-strategy
| +--rw policy-rule!
| | +--rw name leafref
| +--rw policy-group!
| +--rw name leafref
|
+--rw policy-rule!
| +--rw name string
| +--rw policy-rules*[name]
| +--rw name string
| +--rw Enabled boolean
| +--rw Mandatory boolean
| +--rw ConditionListType py:policy-conditionlist-type
| +--rw SequencedActions py:policy-sequenced-actions
| +--rw ExecutionStrategy py:policy-execution-strategy
| +--rw policy-condition
| | +--rw name leafref
| +--rw policy-action
| +--rw name leafref
|
+--rw policy-group!
| +--rw name string
| +--rw policy-groups* [name]
| | +--rw name leafref
| +--rw policy-rule* [name]
| +--rw name leafref
|
+--rw policy-condition!
| +--rw name string
|
King, et al. Expires September 10, 2015 [Page 16]
Internet-Draft Network Policy Framework March 2015
+--rw policy-action!
| +--rw name string
|
+--rw policy-variable!
| +--rw name string
|
+--rw filter-entry-base!
| +--rw name string
|
+--rw ManagedSystemElement!
+--rw LogicalElement!
+--rw System!
| +--rw AdminDomain!
| +--rw ReusablePolicyContainer!
+--rw FilterEntryBase!
+--rw FilterList* [filter-name]
+--rw filter-name string
Figure 14: The Structure of the IETF Abstract Network Policy YANG
Model
7. Design of Reusable atomic grouping
The abstract containers provide a set of atomic blocks which can be
used to aggregate or describe some policy elements. And these
abstract containers can be augmented and reused. This section
describes these reusable atomic grouping.
7.1. PolicyTimePeriodCondition
This subsection describes time-period-condition
grouping.Figure 15provides the structure of time-period-conditon
grouping block
+--rw PolicyTimePeriodCondition!
+--rw TimePeriod string
+--rw MonthOfYearMask yang:data-and-time
+--rw DayOfMonthMask yang:data-and-time
+--rw DayOfWeekMask string
+--rw TimeOfDayMask yang:data-and-time
+--rw LocalOrUtcTime enumeration
Figure 15: The Structure of time-period-conditon grouping block
o The TimePeriod leaf describes the range of calendar dates on which
a policy rule is valid.
King, et al. Expires September 10, 2015 [Page 17]
Internet-Draft Network Policy Framework March 2015
o The TimeMask leaf describes a mask identifying time in which a
policy rule is valid.
o The LocalOrUtcTime leaf describes an indication of whether the
other times in this instance represent local times or UTC times.
7.2. Reusable Variable atomic grouping
This subsection describes Reusable atomic policy variable grouping.
Figure 16 provides the structure of the PolicyVariable block.
+--rw Policy!
......
| +--rw PolicyVariable!
+--rw PolicyImplicitVariable!
+--rw PolicySourceIPv4Variable
+--rw PolicySourceIPv6Variable
+--rw PolicyDestinationIPv4Variable
+--rw PolicyDestinationIPv6Variable
+--rw PolicySourcePortVariable
+--rw PolicyDestinationPortVariable
+--rw PolicyIPProtocolVariable
+--rw PolicyIPToSVariable
+--rw PolicyDSCPVariable
+--rw PolicyFlowIdVariable
+--rw PolicySourceMACVariable
+--rw PolicyDestinationMACVariable
+--rw PolicyVLANVariable
+--rw PolicyCoSVariable
+--rw PolicyEthertypeVariable
+--rw PolicySourceSAPVariable
+--rw PolicyDestinationSAPVariable
+--rw PolicySNAPOUIVariable
+--rw PolicySNAPTypeVariable
+--rw PolicyFlowDirectionVariable
Figure 16: Extending the PolicyVariable Container
7.3. Reusable ip-headers filter atomic grouping
This section describes Reusable ip-headers filter atomic grouping.
Figure 17 provides the structure of the IpHeadersFilter block.
King, et al. Expires September 10, 2015 [Page 18]
Internet-Draft Network Policy Framework March 2015
+--rw Policy!
......
+--rw ManagedSystemElement!
+--rw LogicalElement!
+--rw System!
| ......
+--rw FilterEntryBase!
| +--rw IpHeadersFilter!
| +--rw HdrIpVersion
| +--rw HdrSrcAddress
| +--rw HdrSrcAddressEndOfRange
| +--rw HdrSrcMask
| +--rw HdrDestAddress
| +--rw HdrDestAddressEndOfRange
| +--rw HdrDestMask
| +--rw HdrProtocolID
| +--rw HdrSrcPortStart
| +--rw HdrSrcPortEnd
| +--rw HdrDestPortStart
| +--rw HdrDestPortEnd
| +--rw HdrDSCP
| +--rw HdrFlowLabel
Figure 17: Snippet of the Data Hierarchy Related to IpHeadersFilter
7.4. Reusable 8021Filter atomic grouping
This section describes a reusable 8021 filter atomic grouping.
Figure 18 provides the structure of the 8021Filter block.
King, et al. Expires September 10, 2015 [Page 19]
Internet-Draft Network Policy Framework March 2015
+--rw Policy!
......
+--rw ManagedSystemElement!
+--rw LogicalElement!
+--rw System!
| ......
+--rw FilterEntryBase!
| +--rw IpHeadersFilter!
| +--rw 8021Filter!
| +--rw 8021HdrSrcMACAddr
| +--rw 8021HdrSrcMACMask
| +--rw 8021HdrDestMACAddr
| +--rw 8021HdrDestMACMask
| +--rw 8021HdrProtocolID
| +--rw 8021HdrPriorityValue
| +--rw 8021HDRVLANID
Figure 18: Snippet of the Data Hierarchy Related to 8021Filter
7.5. Usage Examples
7.5.1. Routing Policy
The following figure provide an example of use in routing policy:
augment /bplc:policy-condition
+--rw policy-variable!
+--rw name leafref
augment /bplc:policy-variable
+--rw HdrSrcAddress py:policy-ip-address
+--rw HdrSrcAddressEndOfRange py:policy-addr-range
+--rw mask-length py:policy-addr-length
+--rw mask-length-range py:policy-addr-range
+--rw neighbor* [name]
+--rw name string
+--rw HdrSrcAddress py:policy-ip-address
augment /bplc:policy-action
+--rw accept boolean
+--rw reject boolean
7.5.2. QoS Policy
The following figure provide an example of use in QoS policy:
King, et al. Expires September 10, 2015 [Page 20]
Internet-Draft Network Policy Framework March 2015
augment /bplc:policy-condition
+--rw policy-variable!
+--rw name leafref
Augment /bplc:policy-variable
+--rw qos-rsvp-variable!
+--rw source-IPv4 py:policy-IPv4-addr
+--rw source-IPv6 py:policy-IPv6-addr
+--rw destination-IPv4 py:policy-IPv4-addr
+--rw destination-IPv6 py:policy-IPv6-addr
+--rw QoS-Message-Type enumeration
+--rw QoS-RSVPPreemption-Priority uint32
+--rw QoS-RSVPPreemption-DefPriority uint32
+--rw QoS-RSVP-User string
+--rw QoS-RSVP-Application string
+--rw QoS-RSVP-AuthMethod enumeration
augment /bplc:policy-action
+--rw QoSPolicyRSVPSimpleAction!
+--rw QoSPolicyDiscardAction!
+--rw QoSPolicyAdmissionAction!
+--rw QoSPolicyPHBAction!
8. IETF Network Policy YANG Module
8.1. IETF policy-yang-types Yang Module
<CODE BEGINS>
file "policy-yang-types.yang"
module policy-yang-types {
yang-version "1";
namespace "urn:TBD:params:xml:ns:yang:policy-yang-types";
prefix "py";
import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; }
organization "IETF Netmod Working Group";
contact "wangzitao@huawei.com";
description
"This module defines general data definitions for policy.";
typedef policy-decision-strategy {
King, et al. Expires September 10, 2015 [Page 21]
Internet-Draft Network Policy Framework March 2015
description
"The policy-decision-strategy is used to specify the matching
strategy for the policies of the policy rule. There are two
matching strategies: First-Matching and All-Matching.";
type enumeration{
enum FirstMatching {
description
"The FirstMatching strategy is used to cause the evaluation of
the rules in a set such that the only actions enforced on a
given examination of the Policy Set are those for the first rule
that has its conditions evaluate to TRUE.";}
enum AllMatching {
description
"The AllMatching strategy is used to cause the evaluation of
all rules in a set; for all of the rules whose conditions
evaluate to TRUE, the actions are enforced.";}
}
default FirstMatching;
}
typedef policy-sequenced-actions {
type enumeration{
enum mandatory{
description
"Do the actions in the indicated order, or don't do them at
all.";}
enum recommended{
description
"Do the actions in the indicated order if you can, but if you
can't do them in this order, do them in another order if you
can.";}
enum dontCare{
description
"I don't care about the order.";}
}
default dontCare;
}
typedef policy-execution-strategy {
type enumeration{
enum DoUntilSuccess {
description
"Execute actions according to predefined order, until
successful execution of a single action.";}
enum DoAll{
description
King, et al. Expires September 10, 2015 [Page 22]
Internet-Draft Network Policy Framework March 2015
"Execute ALL actions which are part of the modeled set,
according to their predefined order. Continue doing this, even
if one or more of the actions fails.";}
enum DoUntilFailure{
description
"Execute actions according to predefined order, until the first
failure in execution of a single sub-action.";}
}
default DoAll;
}
typedef policy-conditionlist-type {
type enumeration{
enum DNF;
enum CNF;
}
default DNF;
}
//policy values
typedef policy-IPv4-addr{
description
"The IPv4 address. of the outermost IP packet header.";
type inet:ipv4-address;
}
typedef policy-IPv6-addr{
description
"The IPv6 address. of the outermost IP packet header.";
type inet:ipv6-address;
}
typedef policy-port{
description
"For TCP and UDP flows, the PolicySourcePortVariable is logically
bound to the source port field of the outermost UDP or TCP packet
header.";
type inet:port-number;
}
typedef policy-protocol{
description
"The IP protocol number.";
type uint16{
range "0..65535";}
}
King, et al. Expires September 10, 2015 [Page 23]
Internet-Draft Network Policy Framework March 2015
typedef policy-ip-version{
description
"The IP version number.";
type inet:ip-version;
}
typedef policy-dscp{
description
"The 6 bit Differentiated Service Code Point.";
type inet:dscp;
}
typedef policy-flow-label{
description
"The flow identifier of the outermost IPv6 packet header.";
type uint32{
range "0..1048575";}
}
typedef policy-mac-addr{
description
"The source MAC address.";
type yang:mac-address;
}
typedef policy-vlan{
description
"The virtual Bridged Local Area Network Identifier, a 12-bit
field as defined in the IEEE 802.1q standard.";
type uint16{
range "0..4095";}
}
typedef policy-cos{
description
"A 3-bit field, used in the layer 2 header to select the
forwarding treatment. Bound to the IEEE 802.1q user-priority
field.";
type uint8{
range "0..7";}
}
typedef policy-ether-type{
description
"The Ethertype protocol number of Ethernet frames.";
type uint16{
range "0..65535";}
}
King, et al. Expires September 10, 2015 [Page 24]
Internet-Draft Network Policy Framework March 2015
typedef policy-sap{
description
"The Source Service Access Point (SAP) number of thev IEEE 802.2
LLC header.";
type uint8{
range "0..255";}
}
typedef policy-snap-oui{
description
"The value of the first three octets of the Sub-Network Access
Protocol (SNAP) Protocol Identifier field for 802.2 SNAP
encapsulation, containing an Organizationally Unique Identifier
(OUI). The value 00-00-00 indicates the encapsulation of
Ethernet frames (RFC 1042). OUI value 00-00-F8 indicates the
special encapsulation of Ethernet frames by certain types of
bridges (IEEE 802.1H). Other values are supported, but are not
further defined here. These OUI values are to be interpreted
according to the endian-notation conventions of IEEE 802. For
either of the two Ethernet encapsulations, the remainder of the
Protocol Identifier field is represented by the
PolicySNAPTypeVariable.";
type uint32{
range "0..16777215";}
}
typedef policy-flow-direction {
type enumeration{
enum IN;
enum OUT;
enum BOTH;
}
default BOTH;
}
typedef policy-ip-address{
type inet:ip-address;
}
typedef policy-addr-range {
type union{
type inet:ipv4-prefix;
type inet:ipv6-prefix;
}
}
typedef policy-addr-length{
description
King, et al. Expires September 10, 2015 [Page 25]
Internet-Draft Network Policy Framework March 2015
"simple range covers both ipv4 and ipv6.";
type uint8{
range 1..128;}
}
}
<CODE ENDS>
8.1.1. IETF basic-policy Yang Module
<CODE BEGINS>
file "ietf-policy.yang"
module ietf-policy{
yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:basic-policy";
prefix bplc;
import ietf-yang-types { prefix yang;}
import policy-yang-types {prefix py;}
organization "IETF Netmod Working Group";
contact
"wangzitao@huawei.com";
description
"This module defines basic-network-policy yang data model";
typedef role-type {
type string;
description "basic network policy role type";
}
/* Reusable atomic grouping */
grouping basic-roles{
leaf PolicyRoles
{
description
"A set of strings representing the roles and role combinations
associated with a policy rule. Each value represents one role
combination.";
type string;
}
}
grouping basic-role{
leaf PolicyRole{
description
"A role is an administratively specified characteristic of a
King, et al. Expires September 10, 2015 [Page 26]
Internet-Draft Network Policy Framework March 2015
managed element. As a selector for policies, it determines
the applicability of the policy to a particular managed
element.";
type role-type;
}
}
grouping core-policy-set{
description
"This grouping collect a set of core parameters of PolicySet.";
uses basic-roles;
leaf PolicyDecisionStrategy {
description
"The match-strategy leaf is used to specify the matching
strategy for the policies of the policy rule. There are two
matching strategy: First-Matching and All-Matching.";
type py:policy-decision-strategy;
}
}
grouping action-method{
description
"This grouping collect SequencedActions and ExecutionStrategy
methods. And this grouping may be used in PolicyRule, etc.";
leaf SequencedActions{
description
"This leaf gives a policy administrator a way of specifying
the ordering of the policy actions.";
type py:policy-sequenced-actions;
}
leaf ExecutionStrategy{
description
"This leaf defines the execution strategy to be used upon the
sequenced actions is this policy-rule.";
type py:policy-execution-strategy;
}
}
grouping condition-method{
description
"This grouping collect ConditionListType methods. And this
grouping may be used in PolicyRule or CompoundPolicyCondition,
etc.";
King, et al. Expires September 10, 2015 [Page 27]
Internet-Draft Network Policy Framework March 2015
leaf ConditionListType{
description
"Indicates whether the list of policy conditions associated
with this policy rule is in disjunctive normal form (DNF) or
conjunctive normal form (CNF).";
type py:policy-conditionlist-type;
}
}
grouping core-policy-rule{
description
"This grouping collect a set of core parameters of PolicyRule.";
leaf Enabled{
description
"An enumeration indicating whether a policy rule is
administratively enabled, administratively disabled, or
enabled for debug mode.";
type enumeration{
enum enabled;
enum disabled;
enum enabledForDebug;
}
default enabled;
}
leaf Mandatory{
description
"A flag indicating that the evaluation of the PolicyConditions
and execution of PolicyActions (if the condition list
evaluates to TRUE) is required.";
type boolean;
default true;
}
uses condition-method;
uses action-method;
}
/* Reusable atomic policy condition grouping */
grouping time-period-condition{
container PolicyTimePeriodCondition{
description
"A condition that provides the capability of
enabling/disabling a policy rule according to a pre-determined
schedule.";
uses condition-method;
King, et al. Expires September 10, 2015 [Page 28]
Internet-Draft Network Policy Framework March 2015
leaf TimePeriod{
description
"The range of calendar dates on which a policy rule is
valid. And the format is: yyyymmddThhmmss/yyyymmddThhmmss,
where the first date/time may be replaced with the string
THISANDPRIOR or the second date/time may be replaced with
the string THISANDFUTURE.";
type string;
}
leaf MonthOfYearMask{
description
"A mask identifying the months of the year in which a policy
rule is valid.";
type yang:date-and-time;
}
leaf DayOfMonthMask{
description
"A mask identifying the days of the month on which a policy
rule is valid.";
type yang:date-and-time;
}
leaf DayOfWeekMask{
description
"A mask identifying the days of the week on which a policy
rule is valid.";
type string;
}
leaf TimeOfDayMask{
description
"The range of times at which a policy rule is valid. If the
second time is earlier than the first, then the interval
spans midnight.";
type yang:date-and-time;
}
leaf LocalOrUtcTime{
description
"An indication of whether the other times in this instance
represent local times or UTC times.";
type enumeration{
enum localTime;
enum utcTime;
}
King, et al. Expires September 10, 2015 [Page 29]
Internet-Draft Network Policy Framework March 2015
default utcTime;
}
}
}
grouping vendor-condition{
container VendorPolicyCondition{
description
"A container defines a registered means to describe a policy
condition.";
uses condition-method;
leaf Constraint{
description
"Representing constraints that have not been modeled as
specific properties. The format of the values is identified
by the OID stored in the property ConstraintEncoding.";
type string;
}
leaf ConstraintEncoding{
description
"An OID encoded as a string, identifying the format and
semantics for this instance's Constraint property. The
value is a dotted sequence of decimal digits (for example,
1.2.100.200) representing the arcs of the OID. The
characters in the string are the UCS-2 characters
corresponding to the US ASCII encodings of the numeric
characters and the period.";
type string;
}
}
}
grouping compound-condition{
description
"Introduces the ConditionListType property, used for assigning
DNF/CNF semantics to subordinate policy conditions.";
uses condition-method;
container CompoundFilterCondition{
description
"Introduces the IsMirrored property.
The IsMirrored property indicates whether packets that mirror
a compound filter condition should be treated as matching the
filter.";
uses condition-method;
leaf IsMirrored{
description
King, et al. Expires September 10, 2015 [Page 30]
Internet-Draft Network Policy Framework March 2015
"Indicates whether packets that mirror the specified filter
are to be treated as matching the filter.";
type boolean;
default false;
}
}
}
/* END OF Reusable atomic policy condition grouping */
/* Reusable atomic policy action grouping */
grouping vendor-action{
description
"Defines a registered means to describe a policy action.";
uses action-method;
leaf ActionData{
description
"Actions that have not been modeled as specific properties.
The format of the values is identified by the OID stored in
the property ActionEncoding.";
type string;
}
leaf ActionEncoding{
description
"An OID encoded as a string, identifying the format and
semantics for this instance's ActionData property. The value
is a dotted sequence of decimal digits (for example,
1.2.100.200) representing the arcs of the OID. The characters
in the string are the UCS-2 characters corresponding to the US
ASCII encodings of the numeric characters and the period.";
type string;
}
}
grouping compound-action{
description
"Representing sequenced action terms. Each action term is
defined to be a subclass of the PolicyAction class.";
uses action-method;
}
/* END OF Reusable atomic policy action grouping */
King, et al. Expires September 10, 2015 [Page 31]
Internet-Draft Network Policy Framework March 2015
/* Reusable atomic policy variable grouping */
grouping source-IPv4{
leaf PolicySourceIPv4Variable{
description
"The source IPv4 address. of the outermost IP packet header.";
type py:policy-IPv4-addr;
}
}
grouping source-IPv6{
leaf PolicySourceIPv6Variable{
description
"The source IPv6 address. of the outermost IP packet header.";
type py:policy-IPv6-addr;
}
}
grouping destination-IPv4{
leaf PolicyDestinationIPv4Variable{
description
"The destination IPv4 address. of the outermost IP packet
header.";
type py:policy-IPv4-addr;
}
}
grouping destination-IPv6{
leaf PolicyDestinationIPv6Variable{
description
"The destination IPv6 address. of the outermost IP packet
header.";
type py:policy-IPv6-addr;
}
}
grouping source-port{
leaf PolicySourcePortVariable{
description
"For TCP and UDP flows, the PolicySourcePortVariable is
logically bound to the source port field of the outermost UDP
or TCP packet header.";
type py:policy-port;
}
}
grouping destination-port{
leaf PolicyDestinationPortVariable{
King, et al. Expires September 10, 2015 [Page 32]
Internet-Draft Network Policy Framework March 2015
description
"For TCP and UDP flows, the PolicyDestinationPortVariable is
logically bound to the destination port field of the outermost
UDP or TCP packet header.";
type py:policy-port;
}
}
grouping protocol{
leaf PolicyIPProtocolVariable{
description
"The IP protocol number.";
type py:policy-protocol;
}
}
grouping IP-version{
leaf PolicyIPVersionVariable{
description
"The IP version number.";
type py:policy-ip-version;
}
}
grouping dscp{
leaf PolicyDSCPVariable{
description
"The 6 bit Differentiated Service Code Point.";
type py:policy-dscp;
}
}
grouping flow-id{
leaf PolicyFlowIdVariable{
description
"The flow identifier of the outermost IPv6 packet header.";
type py:policy-flow-label;
}
}
grouping source-mac{
leaf PolicySourceMACVariable{
description
"The source MAC address.";
type py:policy-mac-addr;
}
}
King, et al. Expires September 10, 2015 [Page 33]
Internet-Draft Network Policy Framework March 2015
grouping destination-mac{
leaf PolicyDestinationMACVariable{
description
"The destination MAC address.";
type py:policy-mac-addr;
}
}
grouping vlan-variable{
leaf PolicyVLANVariable{
description
"The virtual Bridged Local Area Network Identifier, a 12-bit
field as defined in the IEEE 802.1q standard.";
type py:policy-vlan;
}
}
grouping cos-variable{
leaf PolicyCoSVariable{
description
"A 3-bit field, used in the layer 2 header to select the
forwarding treatment. Bound to the IEEE 802.1q user-priority
field.";
type py:policy-cos;
}
}
grouping ether-type{
leaf PolicyEthertypeVariable{
description
"The Ethertype protocol number of Ethernet frames.";
type py:policy-ether-type;
}
}
grouping source-sap{
leaf PolicySourceSAPVariable{
description
"The Source Service Access Point (SAP) number of thev IEEE
802.2 LLC header.";
type py:policy-sap;
}
}
grouping destination-sap{
leaf PolicyDestinationSAPVariable{
description
"The Destination Service Access Point (SAP) number of the
King, et al. Expires September 10, 2015 [Page 34]
Internet-Draft Network Policy Framework March 2015
IEEE 802.2 LLC header.";
type py:policy-sap;
}
}
grouping snap-oui{
leaf PolicySNAPOUIVariable{
description
"The value of the first three octets of the Sub-Network Access
Protocol (SNAP) Protocol Identifier field for 802.2 SNAP
encapsulation, containing an Organizationally Unique
Identifier (OUI). The value 00-00-00 indicates the
encapsulation of Ethernet frames (RFC 1042). OUI value
00-00-F8 indicates the special encapsulation of Ethernet
frames by certain types of bridges (IEEE 802.1H). Other
values are supported, but are not further defined here. These
OUI values are to be interpreted according to the endian-
notation conventions of IEEE 802. For either of the two
Ethernet encapsulations, the remainder of the Protocol
Identifier field is represented by the
PolicySNAPTypeVariable.";
type py:policy-snap-oui;
}
}
grouping flow-direction{
leaf PolicyFlowDirectionVariable{
description
"The direction of a flow relative to a network element.
Direction may be IN and/or OUT.";
type py:policy-flow-direction;
}
}
/* END OF Reusable atomic policy variable grouping */
/* atomic policy collection grouping */
grouping role-collection{
description
"Be used to collect managed elements that share a role.";
uses basic-role;
}
/* END OF atomic policy role-collection grouping */
King, et al. Expires September 10, 2015 [Page 35]
Internet-Draft Network Policy Framework March 2015
/* Reusable ManagedSystemElement atomic grouping */
/* Reusable LogicalElement atomic grouping */
/* grouping reusable-policy-container{
leaf-list policy-name{
type leafref{
path "/policy/policy-id";
}
}
} */
/* Reusable ip-headers filter atomic grouping */
grouping hdr-ip-version{
leaf HdrIpVersion{
type py:policy-ip-version;
}
}
grouping hdr-src-addr{
leaf HdrSrcAddress{
type py:policy-ip-address;
}
}
grouping hdr-src-range{
leaf HdrSrcAddressEndOfRange{
type py:policy-addr-range;
}
}
grouping policy-addr-mask{
leaf mask-length {
description
"masklength for the prefix specification";
type py:policy-addr-length;
mandatory true;
}
leaf mask-length-range {
type py:policy-addr-range;
}
}
grouping hdr-dest-addr{
leaf HdrDestAddress{
type py:policy-ip-address;
King, et al. Expires September 10, 2015 [Page 36]
Internet-Draft Network Policy Framework March 2015
}
}
grouping hdr-dest-range{
leaf HdrDestAddressEndOfRange{
type py:policy-addr-range;
}
}
grouping hdr-protocol{
leaf HdrProtocolID{
type py:policy-protocol;
}
}
grouping hdr-srcport-start{
leaf HdrSrcPortStart{
type py:policy-port;
}
}
grouping hdr-srcport-end{
leaf HdrSrcPortEnd{
type py:policy-port;
}
}
grouping hdr-destport-start{
leaf HdrDestPortStart{
type py:policy-port;
}
}
grouping hdr-destport-end{
leaf HdrDestPortEnd{
type py:policy-port;
}
}
grouping hdr-dscp{
leaf HdrDSCP{
type py:policy-dscp;
}
}
grouping hdr-flow-label{
leaf HdrFlowLabel{
King, et al. Expires September 10, 2015 [Page 37]
Internet-Draft Network Policy Framework March 2015
type py:policy-flow-label;
}
}
/* END OF Reusable ip-headers filter atomic grouping */
/* END OF Reusable LogicalElement atomic grouping */
grouping ietf-oper-info{
leaf-list targets{
description
"This leaf list can be used to present a set of targets which
the policy is applied.";
type string;
}
}
/*END OF Reusable ManagedSystemElement atomic grouping */
/* END OF Reusable atomic grouping */
/* Application Template*/
container policy-group{
leaf name{
type string;
}
container policy-group{
leaf name{
type leafref{
path "/policy-group/name";
}
}
}
container policy-rule{
leaf name{
type leafref{
path "/policy-rule/name";
}
}
}
}
container policy-rule{
leaf name{
King, et al. Expires September 10, 2015 [Page 38]
Internet-Draft Network Policy Framework March 2015
type string;
}
uses bplc:core-policy-rule;
list policy-rules{
key "name";
leaf name{
type string;
}
container policy-condition{
leaf name{
type leafref{
path "/policy-condition/name";
}
}
container policy-variable{
leaf name{
type leafref{
path "/policy-variable/name";
}
}
}
}
container policy-action{
leaf name{
type leafref{
path "/policy-variable/name";
}
}
}
}
}
}
<CODE ENDS>
9. Usage Example Module
King, et al. Expires September 10, 2015 [Page 39]
Internet-Draft Network Policy Framework March 2015
9.1. Routing-Policy-Example
module routing-policy-example{
yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:routing-policy-example";
prefix rpe;
import basic-policy {prefix bplc;}
organization "IETF Netmod Working Group";
contact
"xxxxxxxx";
description
"This module defines basic-network-policy yang data model";
identity routing-policy {
base bplc:policy-type;
description
"routing policy.";
}
augment
"/bplc:policy-condition" {
container policy-variable{
leaf name{
type leafref{
path "/bplc:policy-variable/bplc:name";
}
}
}
}
augment
"/bplc:policy-variable" {
uses bplc:hdr-src-addr;
uses bplc:hdr-dest-addr;
uses bplc:policy-addr-mask;
list neighbor{
key "name";
leaf name{
type string;
}
uses bplc:hdr-src-addr; //update!
}
}
augment
King, et al. Expires September 10, 2015 [Page 40]
Internet-Draft Network Policy Framework March 2015
"/bplc:policy-action" {
leaf accept {
type boolean;
description "accepts the route into the routing table";
}
leaf reject {
type boolean;
description "rejects the route";
}
}
}
9.2. Qos-Policy-Example
module qos-policy-example{
yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:qos-policy-example";
prefix qpe;
import basic-policy {prefix bplc;}
organization "IETF Netmod Working Group";
contact
"xxxxxxxx";
description
"This module defines QoS Policy yang data model.";
identity qos-policy {
base bplc:policy-type;
description
"QOS policy.";
}
augment
"/bplc:policy-condition" {
container policy-variable{
leaf name{
type leafref{
path "/bplc:policy-variable/bplc:name";
}
}
}
}
augment
King, et al. Expires September 10, 2015 [Page 41]
Internet-Draft Network Policy Framework March 2015
"/bplc:policy-variable" {
container qos-rsvp-variable{
/* uses the atomic reusable groups*/
uses bplc:source-IPv4;
uses bplc:source-IPv6;
uses bplc:destination-IPv4;
uses bplc:destination-IPv6;
/* ........*/
leaf QoS-Message-Type{
description
"The RSVP message type.";
type enumeration{
enum PATH;
enum PATHTEAR;
enum RESV;
enum RESVTEAR;
enum REVERR;
enum CONF;
enum PATHERR;
}
}
leaf QoS-RSVPPreemption-Priority{
description
"The RSVP reservation priority.";
type uint32;
}
leaf QoS-RSVPPreemption-DefPriority{
description
"The RSVP reservation defending
priority.";
type uint32;
}
leaf QoS-RSVP-User{
description
"The ID of the user that initiated the flow
as defined in the User Locator string.";
type string;
}
leaf QoS-RSVP-Application{
description
"The ID of the application that generated the flow
as defined in the application locator string.";
type string;
King, et al. Expires September 10, 2015 [Page 42]
Internet-Draft Network Policy Framework March 2015
}
leaf QoS-RSVP-AuthMethod{
description
"The type of authentication.";
type enumeration{
enum NONE;
enum PLAIN-TEXT;
enum DIGITAL-SIG;
enum KERBEROS_TKT;
enum X509_V3_CERT;
enum PGP_CERT;
}
}
}
}
augment
"/bplc:policy-action" {
container QoSPolicyRSVPSimpleAction;
container QoSPolicyDiscardAction;
container QoSPolicyAdmissionAction ;
container QoSPolicyPHBAction;
}
}
10. Security Considerations
TBD.
11. IANA Considerations
TBD.
12. References
12.1. Normative References
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J., and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, November 2001.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
King, et al. Expires September 10, 2015 [Page 43]
Internet-Draft Network Policy Framework March 2015
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
12.2. Informative References
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
"Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001.
[RFC3460] Moore, B., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003.
[RFC4011] Waldbusser, S., Saperia, J., and T. Hongal, "Policy Based
Management MIB", RFC 4011, March 2005.
Authors' Addresses
Daniel King
Old Dog Consulting
UK
Email: daniel@olddog.co.uk
Zitao Wang
Huawei Technologies,Co.,Ltd
101 Software Avenue, Yuhua District
Nanjing 210012
China
Email: wangzitao@huawei.com
Linda Dunbar
Huawei Technologies,Co.,Ltd
1700 Alma Drive, Suite 500
Plano, TX 75075
USA
Email: ldunbar@huawei.com
King, et al. Expires September 10, 2015 [Page 44]
Internet-Draft Network Policy Framework March 2015
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
King, et al. Expires September 10, 2015 [Page 45]
| PAFTECH AB 2003-2026 | 2026-04-24 05:31:58 |