One document matched: draft-wang-netmod-yang-policy-dm-01.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="std" docName="draft-wang-netmod-yang-policy-dm-01"
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 Framework ">A Network Policy Framework using
YANG Data Models</title>
<author fullname="Daniel King" initials="D" surname="King">
<organization>Old Dog Consulting</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>UK</country>
</postal>
<email>daniel@olddog.co.uk</email>
</address>
</author>
<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>
<author fullname="Linda Dunbar" initials="L." surname="Dunbar">
<organization abbrev="Huawei">Huawei Technologies,Co.,Ltd</organization>
<address>
<postal>
<street>1700 Alma Drive, Suite 500</street>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>USA</country>
</postal>
<phone/>
<email>ldunbar@huawei.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<date year="2015"/>
<area>OPS Area</area>
<workgroup/>
<abstract>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>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.</t>
<t>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 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.</t>
<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 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.</t>
</section>
<section title="Definitions and Acronyms">
<t><list style="hanging">
<t hangText="ACL:">Access Control List<vspace blankLines="1"/></t>
<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>
<t>The following terms defined in <xref target="RFC3198"/> are also used
in this document: <list style="symbols">
<t>Policy Conflict</t>
<t>Policy Decision</t>
<t>Policy Decision Point (PDP)</t>
<t>Policy Enforcement</t>
<t>Policy Enforcement Point (PEP)</t>
<t>Policy Rule</t>
<t>Service Level Agreement (SLA)</t>
<t>Service Level Objective (SLO)</t>
</list></t>
<t>Additionally, we defines the following terms based on the concepts
described in <xref target="RFC3198"/>: <list style="hanging">
<t hangText="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.<vspace blankLines="1"/></t>
<t hangText="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.<vspace
blankLines="1"/></t>
<t hangText="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.<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="A Network Policy Reference Model">
<figure anchor="refModel" title="Reference Model Overview">
<artwork>
Network Service Definition
|
-----------|-----------------------------------------------
| V |
| +--------------------+ +--------------------+ |
| | Policy | | Policy Repository | |
| | Management System |-------->| (Directory Server, | |
| +--------------------+ | Database, etc.) | |
| * * +--------------------+ |
| * * | |
| * * | |
| * | |
| * +-------------------------------+ |
| * | |
| * | * |
| * | * |
| * | * * * * * * * * * * * * * * * * |
| * | * |
| * | * |
----*-------|--------------------------------------*-------
* | *
---------+---------- Protocol for --------------------
| Policy Provider | Policy Mechanism | Policy Consumer |
| |<------------------>| |
-------------------- --------------------
</artwork>
</figure>
<t>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.</t>
<t>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.</t>
<t>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 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.</t>
</section>
<section title="Architecture of The Core Policy YANG Models">
<t>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.</t>
<t>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.</t>
<t><xref target="relationships"/> 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.</t>
<figure anchor="relationships"
title="Relationship of Policy YANG Models to the Generic Policy YANG Model">
<artwork>
---------
| Generic |
| Policy |
----+----
|
|
+-----------+-------+------------+-----. . .-----+
| | | |
-----+----- ----+---- ----+---- ---------
| QoS | | ACL | | Routing |. . .| foo |
| Policy | | Policy | | Policy | | Policy |
-+--------- ----+---- ----+---- ----+----
| | | | |
-------+- -+------- | ----+---- ----+----
| IntServ | | DiffServ| | | BGP |. . .| foo |
| Policy | | Policy | | |sub-tech | |sub-tech |
---+----- -----+--- | ----+---- ----+----
| | | | |
| | | | |
---+---------------+-----------+------------+-------------+---
| Uniform API |
--------------------------------------------------------------
</artwork>
</figure>
</section>
<section title="Design of Network Policy Modules">
<t>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.</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 title="Usage Examples">
<section title="Routing Policy">
<t>The following figure provide an example of use in routing
policy:</t>
<figure>
<artwork>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</artwork>
</figure>
</section>
<section title="QoS Policy">
<t>The following figure provide an example of use in QoS policy:</t>
<figure>
<artwork>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!</artwork>
</figure>
</section>
</section>
</section>
<section title="IETF Network Policy YANG Module">
<section title="IETF policy-yang-types Yang Module">
<figure>
<artwork> <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 {
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
"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";}
}
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";}
}
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
"simple range covers both ipv4 and ipv6.";
type uint8{
range 1..128;}
}
}
<CODE ENDS></artwork>
</figure>
<section title="IETF basic-policy Yang Module">
<figure>
<artwork> <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
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.";
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;
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;
}
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
"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 */
/* 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{
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;
}
}
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
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 */
/* 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;
}
}
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{
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{
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>
</artwork>
</figure>
</section>
</section>
</section>
<section title="Usage Example Module">
<section title="Routing-Policy-Example">
<figure>
<artwork>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
"/bplc:policy-action" {
leaf accept {
type boolean;
description "accepts the route into the routing table";
}
leaf reject {
type boolean;
description "rejects the route";
}
}
} </artwork>
</figure>
</section>
<section title="Qos-Policy-Example">
<figure>
<artwork>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
"/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;
}
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;
}
} </artwork>
</figure>
</section>
</section>
<section title="Security Considerations">
<t>TBD.</t>
</section>
<section title="IANA Considerations">
<t>TBD.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC3198;
&RFC6020;
&RFC6241;
</references>
<references title="Informative References">
&RFC3060;
&RFC3460;
&RFC4011;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:45:57 |