One document matched: draft-wang-netmod-yang-policy-dm-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3060.xml">
<!ENTITY RFC3198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3198.xml">
<!ENTITY RFC3460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3460.xml">
<!ENTITY RFC4011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4011.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
]>
<rfc category="exp" docName="draft-wang-netmod-yang-policy-dm-02"
ipr="trust200902">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<front>
<title abbrev="Network Policy Model using Abstraction Language">A Network
Policy YANG Data Models using abstraction language</title>
<author fullname="Zitao Wang" initials="Z." surname="Wang">
<organization abbrev="Huawei">Huawei Technologies,Co.,Ltd</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region/>
<code>210012</code>
<country>China</country>
</postal>
<email>wangzitao@huawei.com</email>
</address>
</author>
<date year="2015"/>
<area>OPS Area</area>
<workgroup/>
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Policy Core Information Model <xref target="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.</t>
<t>Policies can either be used in a stand-alone policy rule or
aggregated into policy group functions <xref target="RFC3060"/>. In
order to perform more elaborate functions, <xref target="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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Definitions and Acronyms">
<t><list style="hanging">
<t hangText="BNP:">Basic Network Policy<vspace blankLines="1"/></t>
<t hangText="QoS:">Quality of Service<vspace blankLines="1"/></t>
<t hangText="YANG:"><xref target="RFC6020"/>A data definition
language for NETCONF<xref target="RFC6241"/> <vspace
blankLines="1"/></t>
</list></t>
<section title="Tree Diagrams">
<t>A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as
follows:</t>
<figure anchor="symbols"
title="Symbols Used in Diagrams in this Document">
<artwork>
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
</artwork>
</figure>
</section>
</section>
<section title="Design of Network Policy Modules">
<t>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.</t>
<section title="Common Core Network Policy">
<t>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 <xref target="RFC3060"/>. And in
accordance with <xref target="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.</t>
<t>This section describes the common core network policy YANG model
structure and also describes the separate elements: <list
style="hanging">
<t hangText="Policy-Set">is a set of Policies which is inserted
into the inheritance hierarchy above both policy-group and
policy-rule.<vspace blankLines="1"/></t>
<t hangText="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. <vspace
blankLines="1"/></t>
<t hangText="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. <vspace blankLines="1"/></t>
</list></t>
<t><xref target="hiStructIETFpolicy"/> shows the high-level structure
of the ietf-policy YANG model.</t>
<figure anchor="hiStructIETFpolicy"
title="High-Level Structure of the ietf-policy YANG Model">
<artwork>
module: ietf-policy
|
|- rw policy-set!
| | ....
| +--rw policy-group* [group-name]
| | ....
| +--rw policy-rule* [rule-name]
| | ....
|-rw policy-group!
|-rw policy-rule!
</artwork>
</figure>
</section>
<section title="The Policy-Set">
<t>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.</t>
<t><xref target="structPolicySet"/> shows the snippet of a
policy-set.</t>
<figure anchor="structPolicySet"
title="Snippet of the Data Hierarchy Related to policy-set">
<artwork>
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
...... </artwork>
</figure>
<t><list style="symbols">
<t>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.
<xref target="RFC3460"/>.</t>
<t>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.</t>
<t>The policy-rule container contains a name leaf, this name can
be used to reference the policy-rule defined in <xref
target="secPolicyRule"/>.</t>
<t>The policy-group container contains a name leaf, and this name
can be used to reference the policy-group defined in <xref
target="secPolicyGroup"/></t>
</list></t>
<section title="Policy-role">
<t>In <xref target="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."</t>
<t>Some examples of the policy-role type have already been defined
in <xref target="RFC4011"/>, such as political, financial, legal,
geographical, and architectural characteristics.</t>
<t>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 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.</t>
</section>
</section>
<section anchor="secPolicyRule" title="Policy-rule">
<t>Policies can be used in either as stand-alone policy rules or can
be aggregated into policy groups functions <xref
target="RFC3060"/>.</t>
<t><xref target="structPolicyRule"/> shows the snippet of a
policy-rule.</t>
<figure anchor="structPolicyRule"
title="Snippet of the Data Hierarchy Related to policy-rule">
<artwork>
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
....... </artwork>
</figure>
<t><list style="symbols">
<t>name is the identification of a policy-rule. Different
occurrences of policy-rule are distinguished via the rule-name
leaf.</t>
<t>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).</t>
<t>The Sequenced-Actions leaf is an enumeration type and indicate
the action ordering.</t>
<t>The ExecutionStrategy leaf defines the execution strategy to be
used upon the sequenced actions is this policy-rule.</t>
<t>The policy-condition container contains a name leaf, this name
can be used to reference the policy-condition defined in <xref
target="secPolicyCondition"/>.</t>
<t>The policy-action container contains a name leaf, and this name
can be used to reference the policy-action defined in <xref
target="secPolicyRule"/>.</t>
</list></t>
</section>
<section anchor="secPolicyGroup" title="The Policy-group">
<t>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 <xref
target="RFC3060"/>.</t>
<t><xref target="structPolicyGroup"/> shows the snippet of a
policy-group list.</t>
<figure anchor="structPolicyGroup"
title="Snippet of the Data Hierarchy Related to policy-group">
<artwork>
module: ietf-policy
+--rw policy-group!
+--rw name string
+--rw policy-groups*[name]
| +--rw name leafref
| +--rw policy-rules*[name]
+--rw name eafref
.... </artwork>
</figure>
<t><list style="symbols">
<t>Name under policy-group container is the identification of the
policy-group. Different policy-group list instances are
distinguished via the leaf group name.</t>
<t>The name in policy-rules can be used to reference the rules
defined in <xref target="secPolicyRule"/> and identify each policy
rule.</t>
</list></t>
</section>
<section anchor="secPolicyCondition" title="PolicyCondition">
<t>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.</t>
<t><xref target="structPolicyCondition"/> shows the snippet of a
PolicyCondition block.</t>
<figure anchor="structPolicyCondition"
title="Snippet of the Data Hierarchy Related to PolicyCondition">
<artwork>
module: ietf-policy
+--rw policy-condition!
+--rw name string </artwork>
</figure>
</section>
<section anchor="secPolicyAction" title="PolicyAction">
<t>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.</t>
<t><xref target="structPolicyAction"/> shows the snippet of a
PolicyAction block.</t>
<figure anchor="structPolicyAction"
title="Snippet of the Data Hierarchy Related to PolicyAction">
<artwork>
module: ietf-policy
+--rw policy-action!
+--rw name string
..... </artwork>
</figure>
</section>
<section title="PolicyVariable">
<t>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.</t>
<t><xref target="structPolicyVariable"/> shows the snippet of a
PolicyVariable block.</t>
<figure anchor="structPolicyVariable"
title="Snippet of the Data Hierarchy Related to PolicyVariable">
<artwork>
module: ietf-policy
+--rw policy-variable!
+--rw name string
</artwork>
</figure>
</section>
<section title="PolicyValue">
<t>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.</t>
<t><xref target="structPolicyValue"/> shows the snippet of a
PolicyValue block.</t>
<figure anchor="structPolicyValue"
title="Snippet of the Data Hierarchy Related to PolicyValue">
<artwork>
module: ietf-policy
+--rw policy-value!
+--rw name string
</artwork>
</figure>
</section>
<section title="Collection">
<t>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.</t>
<t><xref target="structCollection"/> shows the snippet of the data
hierarchy related to the PolicyRoleCollection.</t>
<figure anchor="structCollection"
title="Snippet of the Data Hierarchy Related to PolicyRoleCollection">
<artwork>
+--rw Policy!
| +--rw PolicySet!
| ......
| +--rw Collection!
| +--rw PolicyRoleCollection!
| +--rw PolicyRole string
</artwork>
</figure>
</section>
<section title="ManagedSystemElement">
<t>The ManagedSystemElement is an abstract container that can describe
and aggregate a set of abstract managed system elements such as
LogicalElement, etc.</t>
<t><xref target="structMgdSysElt"/> shows the snippet of the data
hierarchy related to the ManagedSystemElement.</t>
<figure anchor="structMgdSysElt"
title="Snippet of the Data Hierarchy Related to ManagedSystemElement">
<artwork>
+--rw Policy!
| +--rw PolicySet!
......
+--rw ManagedSystemElement!
+--rw LogicalElement!
+--rw System!
| +--rw AdminDomain!
| +--rw ReusablePolicyContainer!
+--rw FilterEntryBase!
+--rw FilterList* [filter-name]
+--rw filter-name string
</artwork>
</figure>
<t><list style="symbols">
<t>ReusablePolicyContainer describes an administratively defined
container for reusable policy-related information <xref
target="RFC3460"/>. Notice that this container does not introduce
any additional properties beyond the AdminDomain. It does,
however, participate in a number of unique associations.</t>
<t>FilterEntryBase is an abstract contaienr representing a single
filter that is aggregated into a FilterList via the
aggregation.</t>
</list></t>
</section>
</section>
<section title="IETF Abstract Network Policy Data Hierarchy">
<t><xref target="structIETFpolicy"/> shows the structure of the IETF
Abstract Network Policy YANG model.</t>
<figure anchor="structIETFpolicy"
title="The Structure of the IETF Abstract Network Policy YANG Model">
<artwork>
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
|
+--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
</artwork>
</figure>
</section>
<section title="Design of Reusable atomic grouping">
<t>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.</t>
<section title="PolicyTimePeriodCondition">
<t>This subsection describes time-period-condition grouping.<xref
target="extPolicyCondition"/>provides the structure of
time-period-conditon grouping block</t>
<figure anchor="extPolicyCondition"
title="The Structure of time-period-conditon grouping block">
<artwork>
+--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
</artwork>
</figure>
<t><list style="symbols">
<t>The TimePeriod leaf describes the range of calendar dates on
which a policy rule is valid.</t>
<t>The TimeMask leaf describes a mask identifying time in which a
policy rule is valid.</t>
<t>The LocalOrUtcTime leaf describes an indication of whether the
other times in this instance represent local times or UTC
times.</t>
</list></t>
</section>
<section title="Reusable Variable atomic grouping">
<t>This subsection describes Reusable atomic policy variable
grouping.</t>
<t><xref target="extPolicyVariable"/> provides the structure of the
PolicyVariable block.</t>
<figure anchor="extPolicyVariable"
title="Extending the PolicyVariable Container">
<artwork>
+--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
</artwork>
</figure>
</section>
<section title="Reusable ip-headers filter atomic grouping">
<t>This section describes Reusable ip-headers filter atomic
grouping.</t>
<t><xref target="structIPhdrFilter"/> provides the structure of the
IpHeadersFilter block.</t>
<figure anchor="structIPhdrFilter"
title="Snippet of the Data Hierarchy Related to IpHeadersFilter">
<artwork>
+--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
</artwork>
</figure>
</section>
<section title="Reusable 8021Filter atomic grouping">
<t>This section describes a reusable 8021 filter atomic grouping.</t>
<t><xref target="struct8021Filter"/> provides the structure of the
8021Filter block.</t>
<figure anchor="struct8021Filter"
title="Snippet of the Data Hierarchy Related to 8021Filter">
<artwork>
+--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
</artwork>
</figure>
</section>
</section>
<section title="IETF Network Policy YANG Module">
<figure>
<artwork> <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";
}
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.";}
}
}
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
"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{
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;
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>
</artwork>
</figure>
</section>
<section title="Conclusion">
<t>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 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.</t>
</section>
<section title="Acknowledgements">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC3198;
&RFC6020;
&RFC6241;
</references>
<references title="Informative References">
&RFC3060;
&RFC3460;
&RFC4011;
<?rfc include='reference.RFC.6095'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:46:59 |