Internet DRAFT - draft-wang-netmod-yang-policy-dm
draft-wang-netmod-yang-policy-dm
Network Working Group Z. Wang
Internet-Draft Huawei
Intended status: Experimental May 4, 2015
Expires: November 5, 2015
A Network Policy YANG Data Models using abstraction language
draft-wang-netmod-yang-policy-dm-02
Abstract
This document describes a YANG data model for network policies using
Language Abstractions defined in RFC6095. The model intends to be
applied to deliver various different network services by controlling
the policies that enable features such as QoS, Security, 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.
Earlier revisions of this document were written to trigger discussion
with operator community at IETF-92 in Dallas. This document has been
updated to reflect the limited conclusions of those discussions and
record them for archival purposes. There is no intent to advance
this document any further toward publication.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 November 5, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang Expires November 5, 2015 [Page 1]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
3. Design of Network Policy Modules . . . . . . . . . . . . . . 4
3.1. Common Core Network Policy . . . . . . . . . . . . . . . 4
3.2. The Policy-Set . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Policy-role . . . . . . . . . . . . . . . . . . . . . 6
3.3. Policy-rule . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. The Policy-group . . . . . . . . . . . . . . . . . . . . 8
3.5. PolicyCondition . . . . . . . . . . . . . . . . . . . . . 8
3.6. PolicyAction . . . . . . . . . . . . . . . . . . . . . . 9
3.7. PolicyVariable . . . . . . . . . . . . . . . . . . . . . 9
3.8. PolicyValue . . . . . . . . . . . . . . . . . . . . . . . 9
3.9. Collection . . . . . . . . . . . . . . . . . . . . . . . 10
3.10. ManagedSystemElement . . . . . . . . . . . . . . . . . . 10
4. IETF Abstract Network Policy Data Hierarchy . . . . . . . . . 11
5. Design of Reusable atomic grouping . . . . . . . . . . . . . 12
5.1. PolicyTimePeriodCondition . . . . . . . . . . . . . . . . 12
5.2. Reusable Variable atomic grouping . . . . . . . . . . . . 13
5.3. Reusable ip-headers filter atomic grouping . . . . . . . 13
5.4. Reusable 8021Filter atomic grouping . . . . . . . . . . . 14
6. IETF Network Policy YANG Module . . . . . . . . . . . . . . . 15
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
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.
Wang Expires November 5, 2015 [Page 2]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
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 YANG data model for network policies using
Language Abstractions defined in [RFC6095]. The model intends to be
applied to deliver various different network services by controlling
the policies that enable features such as QoS, Security, 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.
Earlier revisions of this document were written to trigger discussion
with operator community at IETF-92 in Dallas. This document has been
updated to reflect the limited conclusions of those discussions and
record them for archival purposes. There is no intent to advance
this document any further toward publication.
2. Definitions and Acronyms
BNP: Basic Network Policy
QoS: Quality of Service
YANG: [RFC6020]A data definition language for NETCONF[RFC6241]
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:
Wang Expires November 5, 2015 [Page 3]
Internet-DrafNetwork Policy Model using Abstraction Language May 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. Design of Network Policy Modules
In this document we define a common core policy model using language
abstraction 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.
3.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.
Wang Expires November 5, 2015 [Page 4]
Internet-DrafNetwork Policy Model using Abstraction Language May 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 2 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 2: High-Level Structure of the ietf-policy YANG Model
3.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 3 shows the snippet of a policy-set.
Wang Expires November 5, 2015 [Page 5]
Internet-DrafNetwork Policy Model using Abstraction Language May 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 3: 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 3.3.
o The policy-group container contains a name leaf, and this name can
be used to reference the policy-group defined in Section 3.4
3.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
Wang Expires November 5, 2015 [Page 6]
Internet-DrafNetwork Policy Model using Abstraction Language May 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.
3.3. Policy-rule
Policies can be used in either as stand-alone policy rules or can be
aggregated into policy groups functions [RFC3060].
Figure 4 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 4: 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 3.5.
Wang Expires November 5, 2015 [Page 7]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
o The policy-action container contains a name leaf, and this name
can be used to reference the policy-action defined in Section 3.3.
3.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 5 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 5: 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 3.3 and identify each policy rule.
3.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 6 shows the snippet of a PolicyCondition block.
module: ietf-policy
+--rw policy-condition!
+--rw name string
Figure 6: Snippet of the Data Hierarchy Related to PolicyCondition
Wang Expires November 5, 2015 [Page 8]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
3.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 7 shows the snippet of a PolicyAction block.
module: ietf-policy
+--rw policy-action!
+--rw name string
.....
Figure 7: Snippet of the Data Hierarchy Related to PolicyAction
3.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 8 shows the snippet of a PolicyVariable block.
module: ietf-policy
+--rw policy-variable!
+--rw name string
Figure 8: Snippet of the Data Hierarchy Related to PolicyVariable
3.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 9 shows the snippet of a PolicyValue block.
module: ietf-policy
+--rw policy-value!
+--rw name string
Figure 9: Snippet of the Data Hierarchy Related to PolicyValue
Wang Expires November 5, 2015 [Page 9]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
3.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 10 shows the snippet of the data hierarchy related to the
PolicyRoleCollection.
+--rw Policy!
| +--rw PolicySet!
| ......
| +--rw Collection!
| +--rw PolicyRoleCollection!
| +--rw PolicyRole string
Figure 10: Snippet of the Data Hierarchy Related to
PolicyRoleCollection
3.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 11 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 11: Snippet of the Data Hierarchy Related to
ManagedSystemElement
Wang Expires November 5, 2015 [Page 10]
Internet-DrafNetwork Policy Model using Abstraction Language May 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.
4. IETF Abstract Network Policy Data Hierarchy
Figure 12 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
|
Wang Expires November 5, 2015 [Page 11]
Internet-DrafNetwork Policy Model using Abstraction Language May 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 12: The Structure of the IETF Abstract Network Policy YANG
Model
5. 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.
5.1. PolicyTimePeriodCondition
This subsection describes time-period-condition
grouping.Figure 13provides 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 13: 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.
Wang Expires November 5, 2015 [Page 12]
Internet-DrafNetwork Policy Model using Abstraction Language May 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.
5.2. Reusable Variable atomic grouping
This subsection describes Reusable atomic policy variable grouping.
Figure 14 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 14: Extending the PolicyVariable Container
5.3. Reusable ip-headers filter atomic grouping
This section describes Reusable ip-headers filter atomic grouping.
Figure 15 provides the structure of the IpHeadersFilter block.
Wang Expires November 5, 2015 [Page 13]
Internet-DrafNetwork Policy Model using Abstraction Language May 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 15: Snippet of the Data Hierarchy Related to IpHeadersFilter
5.4. Reusable 8021Filter atomic grouping
This section describes a reusable 8021 filter atomic grouping.
Figure 16 provides the structure of the 8021Filter block.
Wang Expires November 5, 2015 [Page 14]
Internet-DrafNetwork Policy Model using Abstraction Language May 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 16: Snippet of the Data Hierarchy Related to 8021Filter
6. IETF Network Policy YANG Module
<CODE BEGINS>
module abstract-policy{
yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:abstract-policy";
prefix aplc;
import ietf-complex-types {prefix "ct"; }
organization "IETF I2RS Working Group";
contact
"wangzitao@huawei.com";
description
"This module defines common core-network-policy yang data model";
typedef bnp-group-type {
type string;
description "basic network group type";
}
typedef bnp-rule-type {
type string;
description "basic network policy rule type";
}
typedef role-type {
type string;
description "basic network policy role type";
}
Wang Expires November 5, 2015 [Page 15]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
grouping bnp-role{
leaf role{
description
"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.";
type role-type;
}
}
grouping ietf-policy-rule{
ct:complex-type PolicyRule{
list policy-rule{
description
"defines a list of policy rules.";
key "rule-name";
leaf rule-name{
type string;
description
"The entry-index is the identification of the policy-rule-entry list";
}
leaf rule-type{
description
"The rule-type is used to indicate the type of the policy rule.";
type bnp-rule-type;
}
leaf priority{
description
"The priority leaf indicate the priority of the policy rule.
And it will be used when a single client is sending operations
to accomplish multiple tasks.";
type uint32;
}
leaf sequenced-actions{
description
"This leaf gives a policy administrator a way of specifying
the ordering of the policy 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.";}
Wang Expires November 5, 2015 [Page 16]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
}
}
leaf execution-strategy{
description
"This leaf defines the execution strategy to be used
upon the sequenced actions is this policy-rule.";
type enumeration{
enum DoUntilSuccess {
description
"execute actions according to predefined order,
until successful execution of a single action.";}
enum DoAll{
description
"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.";}
}
}
}
}
}
grouping ietf-role-collection{
container PolicyRoleCollection{
uses bnp-role;
}
}
grouping ietf-filter{
list FilterList{
key "list-name";
leaf list-name{
type string;
}
}
}
grouping ietf-policy-group{
ct:complex-type PolicyGroup{
list policy-group{
key "group-name";
leaf group-name{
description
Wang Expires November 5, 2015 [Page 17]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
"The group-name is the identification of the policy-group.";
type string;
}
leaf group-type{
description
"The group-type is used to indicate the type of the policy group.";
type bnp-group-type;
}
}
}
}
ct:complex-type Policy{ct:abstract true;}
ct:complex-type PolicySet{
ct:abstract true;
uses bnp-role;
leaf policy-decision-strategy {
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 enumeration{
enum First-Matching {
description "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.";}
enum All-Matching {
description " 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.";}
}
}
}
ct:complex-type PolicyCondition{
ct:abstract true;
}
ct:complex-type PolicyAction{
ct:abstract true;
}
ct:complex-type PolicyVariable{
ct:abstract true;
}
ct:complex-type PolicyValue{
ct:abstract true;
}
ct:complex-type Collection{
Wang Expires November 5, 2015 [Page 18]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
ct:abstract true;
}
ct:complex-type ManagedSystemElement{
ct:abstract true;
ct:complex-type LogicalElement{
ct:abstract true;
ct:complex-type System{
ct:abstract true;
ct:complex-type AdminDomain{
ct:abstract true;
}
}
ct:complex-type FilterEntryBase{
ct:abstract true;
}
ct:complex-type PolicyTimePeriodCondition{
ct:extends PolicyCondition;
leaf TimePeriod{type string;}
leaf TimeMask{type yang:date-and-time;}
leaf LocalOrUtcTime{
type enumeration{
enum localTime;
enum utcTime;
}
}
}
ct:complex-type PolicyImplicitVariable{
ct:extends PolicyVariable;
container PolicySourceIPv4Variable;
container PolicySourceIPv6Variable;
container PolicyDestinationIPv4Variable;
container PolicyDestinationIPv6Variable;
container PolicySourcePortVariable;
container PolicyDestinationPortVariable;
container PolicyIPProtocolVariable;
container PolicyIPToSVariable;
container PolicyDSCPVariable;
container PolicyFlowIdVariable;
container PolicySourceMACVariable;
container PolicyDestinationMACVariable;
container PolicyVLANVariable;
container PolicyCoSVariable;
container PolicyEthertypeVariable;
container PolicySourceSAPVariable;
container PolicyDestinationSAPVariable;
Wang Expires November 5, 2015 [Page 19]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
container PolicySNAPOUIVariable;
container PolicySNAPTypeVariable;
container PolicyFlowDirectionVariable;
}
ct:complex-type IpHeadersFilter{
ct:extends FilterEntryBase;
container HdrIpVersion;
container HdrSrcAddress;
container HdrSrcAddressEndOfRange;
container HdrSrcMask;
container HdrDestAddress;
container HdrDestAddressEndOfRange;
container HdrDestMask;
container HdrProtocolID;
container HdrSrcPortStart;
container HdrSrcPortEnd;
container HdrDestPortStart;
container HdrDestPortEnd;
container HdrDSCP;
container HdrFlowLabel;
}
ct:complex-type 8021Filter{
ct:extends FilterEntryBase;
container 8021HdrSrcMACAddr;
container 8021HdrSrcMACMask;
container 8021HdrDestMACAddr;
container 8021HdrDestMACMask;
container 8021HdrProtocolID;
container 8021HdrPriorityValue;
container 8021HDRVLANID;
}
}
}
}
<CODE ENDS>
7. Conclusion
This document uses Policy core information model defined in
[RFC3060][RFC3460] as basis and makes a exploration on how Policy
core information model can be represented using YANG. To better
describe class inheritance and recursiveness, RFC6095 introduces
language abstractions to improve the model extensibility and reuse.
In case the model of a system that should be managed with NETCONF
Wang Expires November 5, 2015 [Page 20]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
makes use of inheritance, complex types enable an almost one-to- one
mapping between the classes in the original model and the YANG
module. Unfortuately Language Abstractions defined in RFC6095 has
its limitation due to introduce multi-level hiearchy and is not
widely used in practice.
8. Acknowledgements
The authors would like to thank Daniel King, Linda Dunbar and Qin Wu
for the very fruitful discussions and useful suggestions in the
initial version.
9. References
9.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.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
9.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.
[RFC6095] Linowski, B., Ersue, M., and S. Kuryla, "Extending YANG
with Language Abstractions", RFC 6095, March 2011.
Wang Expires November 5, 2015 [Page 21]
Internet-DrafNetwork Policy Model using Abstraction Language May 2015
Author's Address
Zitao Wang
Huawei Technologies,Co.,Ltd
101 Software Avenue, Yuhua District
Nanjing 210012
China
Email: wangzitao@huawei.com
Wang Expires November 5, 2015 [Page 22]
