One document matched: draft-hares-i2rs-bnp-info-model-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3060.xml">
<!ENTITY RFC3644 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3644.xml">
<!ENTITY RFC5394 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5394.xml">
<!ENTITY RFC5511 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5511.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.atlas-i2rs-policy-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-i2rs-policy-framework.xml">
<!ENTITY I-D.hares-i2rs-usecase-reqs-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-usecase-reqs-summary.xml">
<!ENTITY I-D.white-i2rs-use-case SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.white-i2rs-use-case.xml">
<!ENTITY I-D.hares-i2rs-bgp-im SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-bgp-im.xml">
<!ENTITY I-D.hares-i2rs-info-model-service-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-service-topo.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-i2rs-bnp-info-model-00"
ipr="trust200902">
<front>
<title abbrev="IM for policy">An Information Model for Basic Network Policy </title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
<!-- uri and facsimile elements may also be added -->
</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@huawei.com</email>
</address>
</author>
<date year="2014" />
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t>This document contains three information Models:
Basic Network Policy (BNP IM). ACLs do not provide
all the policy support required by BGP, Policy Based Routing (PBR),
SFC Topology Information Model (SF-Topo IM), Service
Forwarding Chaing IM (SFC IM), and and flow specification filtering.
The BNP IM has the
following top-down levels of Policy Hierarchy: Policy Set,
Policy Group, Policy Rule, and conditional actions within the
policy rule (conditional match and Actions). These can be used
in PBR-RIB or BGP to provide an ordered set of policy rules
grouped with a Policy Group via operators (AND, OR, etc.) and ordered by
a combination of priority and precedence. The Policy is
an ordered set of Policy Groups.
</t>
<t>The BNP IM is based on the concept of an extensible information model for
representing policies. This concept is also found in the Policy Core Information Model
(PCIM) (RFC3060) and the Quality of Service (QoS) Policy Information
Model (QPIM)(RFC3644) and policy based routing.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Interface to the Routing System (I2RS) provides read and write
access to the information and state within the routing process within
routing elements. The I2RS client interacts with one or more I2RS agents
to collect information from network routing systems.</t>
<t>Processing of collected information at the I2RS agent may require the
I2RS Agent to filter certain information or group pieces of information
in order to reduce the data flow through the network to the I2RS client.
Some applications that that utilize the services of I2RS client may also
wish to require specific data in response to network events or
conditions based on pre-established rules. This functionality is
necessary to meet the requirements of i2rs enabled services which
include service-layer routing improvements, and control of traffic flows
and exit points.</t>
<t>This document introduces a Basic Network Policy information model
(BNP IM) to handle policies related to the network.
This basic policy model can be easily extended beyond the basic
functions. The <xref target="I-D.ietf-i2rs-architecture"></xref>
suggests that associated with the I2RS RIB model there will be
"Policy-based Routing (ACLs)" and RIB "policy controls". These basic
policy functions can operate as part of this functional blocks providing
the basic model for policy operators. This model can also be considered
as the substance of the policy templates.</t>
<t> The BNP IM
is extensible allowing other extensions to make the BNP IM
policy adaptable to specific I2RS protocol features.
This policy model can be linked with other information models
such as the following:
<list style="symbols">
<t> Policy Base Routing Information model (PBR-IM) (Model in section 4), </t>
<t> I2RS RIB Informational Model (RIB IM) (see section 6)
(<xref target="I-D.ietf-i2rs-rib-info-model"></xref>)</t>
<t> BGP Informational Model (BGP IM) (see section 6)
(<xref target="I-D.hares-i2rs-bgp-im"></xref>) </t>
<t> Service Topology (see section 6)
(<xref target="I-D.hares-i2rs-info-model-service-topo"></xref>) </t>
<t> Service Forwarding Chaining Filters Information Mode (SFC IM) (see section 6)
(ietf-hares-dunbar-i2rs-sfc-policy-im-00.txt) </t>
</list>
</t>
<t>The BNP IM model is a product of the industry
approach to I2RS that standardizes on a few basic
network functions to obtain quick deployment of initial I2RS RIB
modules, and build on this success to create network functions.
Additional I2RS modules add I2RS interfaces to policy-based routing,
BGP, Service topology creation, Service Chaining functions,
and policy templates.</t>
<t>This information model leveraged previous work done on extensible
information model for representing policies. This work included
the Policy Core Information Model (PCIM) <xref target="RFC3060"></xref> [RFC3060],
and an extension to this model to address the need for QoS management,
called the Quality of Service (QoS) Policy Information Model (QPIM)
<xref target="RFC3644"></xref> [RFC3644].</t>
<t>Most policy within routing and forwarding systems has become
hierarchical with individual specific policies being grouped as a policy set.
The hierarchical policy rule definition enhances policy
readability and reusability. Groups of network policies have labels to
aid operational use. Named groups of policy are easily identified and
reused as blocks.</t>
<t>The Basic Network Policy information model contains the following three components:
<list style="hanging">
<t hangText="Policy Group"><vspace blankLines="1" />Policy is
described by a set of policy rules that may be grouped into subsets.
A Policy group is used to provide a hierarchical policy definition
that provides the model context or scope for sub-rule actions. The
model context includes identity, scope, role, precedence, priority
and security model. In a policy group policy rules and policy groups
can be nested within other policy rules.</t>
<t hangText="Policy Set"><vspace blankLines="1" /> A Policy Set is a
set of Policy Groups identified by a Policy Set Name.</t>
<t hangText="Policy Rule"><vspace blankLines="1" />
A Policy Rule is represented by the semantics “If Condition then Action”.
</t>
</list>
</t>
<t> This draft contains the Basic Network-Policy Information Model (BNP IM).
BNP IM is a generic network policy model. It can be thought of as a coherent set
of rules to administer, manage, and control access to network
resources and defines a network policy at its most general level of
abstraction. It models aspects such as actions and conditions that
constitute a policy element relationship, as well as operators
contained in the both condition and action that can either be used
to overwrite an old value of the variable or imply match
relationship.</t>
</section>
<section title="Definitions and Acronyms">
<t><list>
<t>IGP: Interior Gateway Protocol</t>
<t>Information Model: An abstract model of a conceptual domain,
independent of a specific implementations or data representation</t>
<t>CLI: Command Line Interface</t>
<t>SNMP: The Simple Network Management Protocol</t>
<t>NETCONF: The Network Configuration Protocol</t>
<t>RBNF: Routing Backus-Naur Form</t>
<t>INSTANCE: Routing Code often has the ability to spin up multiple
copies of itself into virtual machines. Each Routing code instance or
each protocol instance is denoted as Foo_INSTANCE in the text below. </t>
</list></t>
</section>
<section title="Basic Network Policy Information Model (BNP IM)">
<section title="BNP IM Overview ">
<t>I2RS needs its own implicit and explicit policy. This section
provides an overview of the network policy model. The network policy
model is defined by the following components, whose relationship is
roughly depicted in the figure below.</t>
<t>
<figure>
<artwork>
+-----------------------+
| Network-Policy |
+-----------+-----------+
^
/|\
| "extends"
+-----------^-------------+
| Policy Set |
+--+-------------------+--+
^ ^
/|\ /|\
+------------+ +--------------+
|Policy Group| | Policy Group |
+------------+ +--------------+
^ ^ +----------------+
| | ---|ACL Policy-Rule |
| | | | Additions |
| | | +----------------+
| "extends" | "extends" | +----------------+
+--------^-------+ +-------^-------+ |--|PBR Policy-Rule |
| Policy Rule | | Policy Rule |<----| Additions |
+----------------+ +---------------+ | +----------------+
: : | . . .
: : | +---------------+
......: :..... ---|RIB Policy-Rule|
: : | Additions |
: : +---------------+
: :
+---------V---------+ +-V-------------+
| Policy Condition | | Policy Action |
+-------------------+ +---------------+
: : : : : :
.....: . :..... .....: . :.....
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+
| Match | |Policy | |Policy| | Set || Policy ||Policy|
|Operator| |Variable| |Value | |Operator||Variable|| Value|
+--------+ +--------+ +------+ +--------++--------++------+
Figure 1: Overall model BNP IM structure
</artwork>
</figure>
</t>
<t>Network-Policy - contains sets of policies.</t>
<t>Policy-Set: Provides an ordered list of Policy Groups
according to the priority and precedence of the rules.
rules. it is inserted into the inheritance hierarchy above
both Policy-Group and Policy-Rule. </t>
<t>Policy-Group: Defines the basic network policy Group
model which combines the a list of Policy-Rules. </t>
<t>Policy Rule: Represents the semantics of “If Condition then Action”.
<list style="symbols">
<t> Condition models the elementary match operation “<variable> match
<value>”. </t>
<t> Action models the elementary set operation. "SET
<variable> TO <value>". </t>
</list>
In the Condition model, the ‘Match’ operator is usually implied
while in the action model, the ‘Set' operator is explicitly used.</t>
<t>Policy-Sets, Policy-Groups, and Policy-Rules have
basic functionality (Policy-Basic IM) plus extensions defined
by specific Information Models such as:
<list>
<t> The PBR Information Model (PBR IM) (contained in this document), </t>
<t> The I2RS_Local_Policy Model (LP IM) (contained in this document), </t>
<t> The RIB Information Model (RIB IM) (<xref target="I-D.ietf-i2rs-rib-info-model"></xref>), </t>
<t> The BGP Information Model (BGP-IM) (<xref target="I-D.hares-i2rs-bgp-im"></xref>), </t>
<t> The Traffic Steering Information Model (<xref target="I-D.hares-i2rs-info-model-service-topo"></xref>), </t>
<t> The SFC Information Model (SFC IM) (ietf-hares-dunbar-i2rs-sfc-policy-im-00.txt) </t>
<t> The MPLS LDP Information Model (MPLS LDP IM) (TBD) . </t>
</list>
</t>
<t>
I2RS Client-Agents Information Models MAY support
only the Policy-Basic IM, or MAY support any additional
specific information models. </t>
<t> Each level of the Policy hierarchy (Policy-Set,
Policy-Group, and Policy-Rules have both a read and write scope
</t>
</section>
<section title="The Policy Set" >
<section title="Policy Set Overview">
<t>The Policy-Set structure has the following elements:
<list style="symbols">
<t> Policy-Set_Name - Unique Name for Policy Set </t>
<t> Policy-Set is introduced to provide an abstraction for a set of
rules. It is derived from Policy, and it is inserted into the
inheritance hierarchy above both PolicyGroup and PolicyRule. This
reflects the additional structural flexibility and semantic capability
of both subclasses.</t>
</list>
</t>
</section>
<section title="Policy-Set RBNF">
<t>
<figure>
<artwork>
Figure 2 - Policy Set RBNF
<Network_policy> ::= (<Policy_Set> ...)
<Policy-Set> ::= <Policy-Set-Name> <Policy_Group_list>
<PG_Priority< <PG_precedence>
<Policy-Group_list> ::= (<Policy-Group> ...)
</artwork>
</figure>
</t>
</section>
</section>
<section title="The Policy Group">
<section title="Policy Group Overview">
<t>In order to provide hierarchical policy definition and associate
policy rule with other constraint, the basic policy group model needs
to be defined. The corresponding extensions are introduced in a
component, whose structure is informally depicted in the following
diagram.</t>
<figure>
<artwork>
Figure 2 - Policy Group
+---------------------------------------+ (optional)
| Policy Group |....
+---------------------------------------+ :
* * * * ^ :
| | | :....:
| | | | |
| | | | |
| | | | |
+--------+ +----+ +-----------+ +------------------+
|Identity| |Role| |Group order| | Policy Rule |
+--------+ +----+ +---+--+---+| +------------------+
* * * * * *
| | | | |
+--+ | - +---------+ +-------+ | +-+-------+
| | | |priority | |policy | | |mandatory|
| | +---------+ |order | | +---------+
+----+---+ ++----+ |-+----------+ +-------+ | +-------+
|Resource| |Scope| |-|precedence| | ----+-+ Name +
+--------+ +-----+ | +----------+ | +--------+ | +-------+
* * | +----------+ |-|priority| | +-------+
| | |-|preference| | +--------+ +-|enabled|
| | | +----------+ | +----------+ +-------+
| | | +----------+ |-|precedence|
| | |-| combine | | +----------+
| | | +----------+ | +----------+
| | | +----------+ |-|preference|
| | |-|refcnt | | +----------+
| | +----------+ | +----------+
+-----++-----+ +-| combine |
| Read||Write| | +----------+
|Scope||Scope| | +----------+
+-----++-----+ |-| refcnt |
+----------+
</artwork>
</figure>
<t></t>
<t>The basic information model works as follows: Within the policy
group information model, hierarchy is used to model context or scope
for the sub-rule actions. A policy group contains Identity, role,
and group ordering information.
The ordering is the variables
priority, precedence, preference, combination operators (AND plus OR),
and reference count (refcnt) for the policy group. The same
ordering information is kept at the rule level. </t>
<t>The elements of the Policy Group information model are as follows:
<list style="symbols">
<t> An identity contains the name of the Policy group </t>
<t> A role which identifies a resource (E.g. PBR-RIB, or
BGP Neighbor) and a read/write scope.
A policy group may have read scope, write scope, or both. </t>
<t>A policy group has ordering that includes priority, precedence,
preference (within global route table) and combinational
ordering (combine). A group can have only one priority,
precedence, and preference. The default mechanism for
establishing order to order first on priority, and if matched
to use precedence to order, and if precedence ties, to use preference.
Other priorities may be used and the signalling of these is
not covered at this revision. The policy group reference count
is a read-only variable on the number of times this
policy-group has been associated with an I2RS interface
to a protocol or a RIB (RIB or PBR RIB)</t>
<t> A policy rule has policy condition for matching, actions, and
the same ordering values as the policy group
which include: priority, precedence, preference, and combination ordering.
Policy rules can be ordered within a RIB such as the PBR-RIB or within
the a rules set associated with a protocol.
Please note that ACLS wit their condition for matching, the
DENY/ACCEPT action, and the preference setting form one type of policy group.
</t>
<t> The mandatory flag indicates that this rule is mandatory to be satisfied
for this policy group. (This feature is still under discussion within the
group of authors.)
</t>
<t> The enabled flag indicates that this rule is enabled. The lack of the flag allows
rules to be inserted into a policy set without being enabled. </t>
<t>A policy rule can inherit scope and ordering
from the policy group or use its own values. A policy
rule also can have its own properties, e.g., enabled, mandatory,
usage. Rules </t>
<t>The policy rule policy group elements can be extended with
policy-specific components (policy-extensions,
policy-group-extension respectively). One such extension is the inheritance
of the ACL specific rule as policy rules. </t>
</list></t>
</section>
<section title="Policy-Group RBNF">
<t>A more formal depiction in RBNF format follows below
<figure>
<artwork>
Figure 4 - Policy-Group RBNF
<Policy-Group> ::= <Policy-Group_Identity>
<Policy-Group_Roles>
<Policy-Group_order>
(<Policy-Rule* list>)
[<Supporting-Policy-Group_list>]
[<Policy-Group-Extension>]
<Policy-Group-Roles> ::= (<Policy-Group-Role> ...)
<Policy-Group-Role> ::=<Node-RESOURCES> | <Policy-Group-Scope>
<Node-RESOURCES> ::= [<I2RS_AGENT_RESOURCE>]
<Policy-Group-Scope> ::= (<READ_SCOPE> <Policy-Group_Read_Scope>)
| (<WRITE_SCOPE> <Policy-Group_Write_Scope>)
<Policy-Group_Identity> ::= STRING;
<Policy-Group-Order> ::= <Policy-Group-Priority>
<Policy-Group_precedence>
<Policy-Group_preference>
<Policy-Group_combine>
<Policy-Group_refcnt>
<Policy-Group-priority> ::= <PRIORITY>
<Policy-Group-precedence> ::= <PRECEDENCE>
<Policy-Group-preference> ::= <PREFERENCE>
<Policy-Group_Combine> ::= <COMBO-OPERATORS>
<Policy-Group-refcnt> ::= <REFCNT>
<PRIORITY> :: = INTEGER;
<PRECEDENCE> :: = INTEGER:
<PREFERENCE> ::= INTEGER;
<COMBO-OPERATORS> :: = [AND] | OR| NULL;
<REFCNT> :: = INTEGER;
<Policy-Rule-list> ::= <Policy-Rule>*
[Xpath in Yang may or may not be able to replace the definitions below ]
<Policy-Group_Read_Scope> ::= <Policy-Group_Read_Scope_Type>
[<RIB-IM_READ_list>]
[<BGP-IM-READ_list>]
<Policy-Group_Read_Scope_Type> ::= <RIB-IM_READ_SCOPE_TYPE>
| <BGP-IM_READ_SCOPE_TYPE>
<Policy-Group_Write_Scope> ::= <Policy-Group_Write_Scope_Type>
[<RIB-IM_WRITE_list>]
[<BGP-IM-WRITE_list>]
<Policy-Group_Write_Scope_Type> ::= <RIB-IM_WRITE_SCOPE_TYPE>
| <BGP-IM_WRITE_SCOPE_TYPE>
<Supporting-Policy-Group> ::= <SUPPORT-POLICY-GROUP> (
<Policy-Group> ...)
<Policy-Group-Extension> ::= ... /* Vendor Specific Policy */
</artwork>
</figure>
</t>
</section>
</section>
<section title="The Policy Rule ">
<section title="Policy-Rule Overview">
<t>The following diagram contains an informal graphical depiction of
the main elements of the information model:
<figure>
<artwork>
Figure 5 - Policy Rule
+----------------+
| Policy Rule |
+----------------+
* *
| |
| |
+---------+ +--------+
...>|Condition|<.......| Action |<...
: +---------+<.......+--------+ :
: : * * : :
:..... | : :... :
| :
+--------+...........:
|Operator|
+--------+
</artwork>
</figure>
</t>
<t>Roughly speaking, the basic information model works as follows: A
policy rule must identity, match conditions and actions; and it
may contain policy rule ordering and status information.
A operator connects variable and value in the action or condition.
Condition can map onto and be supported by other condition,
while action can map onto and be supported by other actions. </t>
<t>The elements of the Policy Rule information model are as
follows:
<list style="symbols">
<t>A policy can in turn be part of a hierarchy of policies
Each policy is distinguished via a policy-identity.</t>
<t>Policy rule inherit scope from policy group. A policy role has
a certain scope(read/write). This scope is intended to
capture the unique I2RS read or write functionality of
the role. This is a place-holder for this function of the
I2RS ROLE. Hopefully, policy scope can be deleted. </t>
<t>Furthermore, a policy rule contains conditions and actions,
each captured in their own list. The logic presented is a
compromise between the simple logical AND and the
complicated negation. </t>
<t>A condition contains a variable and a value and use a match
operator, to connect variable with value. Also condition may
be specific to a particular Info-Module like BGP IM.
The list Policy-Rule_Condition_Extensions specifies these
conditions which are unique to the protocol.
</t>
<t>An action contains a variable and a value. An action uses the Set
operator to connect a variable with a value. An action may be
specific to a particular Info-Module like BGP IM.
The list Policy-Rule_Action_Extensions specifies these
conditions which are unique to the protocol.
This is captured in list Policy-Rule_Action_Extensions</t>
<t>The policy, condition, action and operator elements can be
extended with policy-specific components (policy-extensions,
condition-extension, action-extension and operator-extension
respectively) that are specific to other informational models.
</t>
<t> Resources below indicates the amount of space that
the policy might take in the routing instance.
The issue is to try to differentiate between the 50 ACL
policy group and the 300,000 ACL group. </t>
<t> Policy Rule scope maps to ROLE Read/Write Concept.
This concept is under revision (see i2rs-security-draft)
It is intended to restrict even policy to a portion of the
Routing tree. Whether this makes policy simpler or more
complex is the question. </t>
<t>RIB-IM-Tree-Match - indicates a match stored as a
tree form with the longest match. </t>
</list>
</t>
</section>
<section title="Policy-Rule RBNF">
<t>The information model for the Network-policy component is more
formally shown in RBNF below:
<figure>
<artwork>
Figure 6 Policy Rule RBNF
<Policy-Rule> ::= [<Policy-Rule-identity>]
[<Policy-Rule-Order>]
[<Policy-Rule-Scope]
[<Policy-Rule-Status>]
<Policy-Match>
<Policy-Condition>
[<Policy-Rule_rule_extensions>]
<Policy-Rule-Order> ::= <Policy-Group-Priority>
<Policy-Group_precedence>
<Policy-Group_preference>
<Policy-Group_combine>
<Policy-Group_refcnt>
<Policy-Rule-Status> ::= [<Policy-Rule-Enable>]
[<Policy-Rule-Mandatory>]
<Policy-Rule-identity> ::= string;
<Policy-Rule-Priority> ::= <PRIORITY>
<Policy-Rule-precedence> ::= <PRECEDENCE>
<Policy-Rule-preference> ::= <PREFERENCE>
<Policy-Rule-Combine> ::= <COMBO_OPERATORS>
<Policy-Rule-refcnt> ::=<REFCNT>
<Policy-Enable> ::= Boolean;
<Policy-Mandatory> ::=Boolean;
<Policy-Rule_Condition> ::= <Policy-Rule_Match_node>
(<Policy-Rule_Match_value> ...)
[<Policy-Rule_mode>]
[<Policy-Rule_Match_Operator>]
[<Policy-Rule_Condition_extension>]
<Policy-Rule_Match_node> ::= [<Policy-Rule_Match_Node_BNP-IM>]
| [<Policy-Rule_Match_node_external]
<Policy-Rule_Match_value> ::= [<Policy-Rule_Match_Value_BNP-IM>]
| [<Policy-Rule_Match_Value_external]
<Policy-Rule_mode> ::= PERMIT | DENY ;
<Policy-Rule_Match_operator_external> ::=
[<Policy-Rule_Match_Operator_BNP-IM>]
| [<Policy-Rule_Match_Operator_external]
<Policy-Rule-action> ::= <Policy-Rule_Action_variable>
<Policy-Rule_Action_value>
<Policy-Rule_Set-Operator>
[<Policy-Rule_action-extension> ]
<Policy-Rule_Security-Model> ::= <First-Matching>
|<All-Matching>]
<Policy-Rule_rule_extension> ::=
<I2RS-LC-policy_rule_extensions>
<Policy-Rule-action> ::= <Policy-Rule_Action_variable>
<Policy-Rule_Action_value>
<Policy-Rule_Set-Operator>
[<Policy-Rule_action-extension> ]
<Policy-Rule_Action_variable> ::= <Policy-Rule_Action_var>
(<Policy-Rule_Action_value> ...)
[<Policy-Rule_Set_Operator>]
[<Policy-Rule_Action_extension>]
<Policy-Rule_Action_var> ::= [<Policy-Rule_Action_Vars_BNP-IM>]
| [<Policy-Rule_Action_external>]
<Policy-Rule_Action_value> ::= [<Policy-Rule_Action_Vars_BNP-IM>]
| [<Policy-Rule_Action_external>]
<Policy-Rule_Set_Operator> ::= [<Policy-Rule_Set_Operator_BNP-IM>]
| [<Policy-Rule_Set_Operator_external>]
<Policy-Rule-action-extension> ::=
[<Policy-Rule_act_ext_BNP-IM>]
| [<Policy-Rule_act_ext_external>]
<Policy-Rule-Match-Operator-Policy-IM> ::= <IS-SET-MEMBER'>
|<IN-INTEGER-RANGE>
|<IP-ADDRESS-AS-RESOLVED-BY-DNS>
|<Policy_IM-Match-Operator-extension>
<Policy-Rule_condition_extension> ::=
<Policy_Rule_condition_ext-BNP-IM>
[<Policy-Rule_Condition_ext_external>]
! Policy Rule scope maps to ROLE Read/Write Concept
! This concept is under revision (see i2rs-security-draft)
! It is intended to restrict even policy to a portion of the
! Routing tree. Whether this makes policy simpler or more
! complex is the question.
<Policy-Rule_Scope> ::= (<READ_SCOPE>
<Policy-Rule_Read_scope>)
| (<WRITE_SCOPE>
<Policy-Rule_Write_scope>)
<Policy-Rule_Read_scope> ::= ((<BNP_READ_SCOPE_TYPE>
<BNP_READ_SCOPE_list>) ...)
| [<Policy-Rule_Read_Scope_External>]
<Policy-Rule_Write_scope> ::= ((<BNP_WRITE_SCOPE_TYPE>
<BNP_WRITE_SCOPE_list>)...)
[<Policy-Rule_Write_Scope_External>]
/* these scopes besides RIB IM are defined in each IM */
<PR_Read_Scope_RIB_IM> ::=<RIB-IM_READ_SCOPE_TYPE>
<RIB-IM_READ_list>
<PR_Read_Scope_RIB_IM> ::=<RIB-IM_READ_SCOPE_TYPE>
<RIB-IM_READ_list>
<RIB-IM_READ_list> ::= [<RIB-IM-Tree-Match> ...]
<RIB-IM_WRITE_list> ::= [<RIB-IM-Tree-Match> ...]
<RIB-IM-Tree-Match> ::= <RIB-IM-Match-routing-instance>
<RIB-IM-Match-interface-list>
<RIM-IM-Match-rib_list>
<RIB-IM-match-route-list>
/* extensions to other IM */
/* External Read and Write Scope */
<Policy-Rule_Read_Scope_External> ::=
[<PR_Read_Scope_RIB_IM>]
[<PR_Read_Scope_BGP_IM>]
[<PR_Read_Scope_PBR_IM>]
[<PR_Read_Scope_I2RSLC_IM>]
[<PR_Read_Scope_STopo_IM>]
[<PR_Read_Scope_SFC-Policy_IM>]
<Policy-Rule_Write_Scope_External> ::=
[<PR_Write_Scope_RIB_IM>]
[<PR_Write_Scope_BGP_IM>]
[<PR_WriteScope_PBR_IM>]
[<PR_Read_Scope_I2RSLC_IM>]
[<PR_Read_Scope_STopo_IM>]
[<PR_Read_Scope_SFC-PolicyIM>]
/* External Rule Conditionals */
<Policy-Rule_Match_node_external> ::=
[<Policy-Rule_Match_Node_RIB-IM>]
| [<Policy-Rule_Match_Node_PBR-IM>]
| [<Policy-Rule_match_Node_I2RSLC-IM>]
| [<Policy-Rule_Match_Node_BGP-IM>]
| [<Policy-Rule_Match_Node_STopo-IM>]
| [<Policy-Rule_Match_Node_SFC-Policy-IM>]
<Policy-Rule_Match_Value_external> ::=
[<Policy-Rule_Match_Value_RIB-IM>]
| [<Policy-Rule_Match_Value_PBR-IM>]
| [<Policy-Rule_Match_Value_I2RSLC-IM>]
| [<Policy-Rule_Match_Value_BGP-IM>]
| [<Policy-Rule_Match_Value_STopo-IM>]
| [<Policy-Rule_Match_Value_SFC-Policy-IM>]
<Policy-Rule_Match_operator_external> ::=
[<Policy-Rule_Match_Operator_RIB-IM>]
| [<Policy-Rule_Match_Operator_PBR-IM>]
| [<Policy-Rule_Match_Operator_I2RSLC-IM>]
| [<Policy-Rule_Match_Operator_BGP-IM>]
| [<Policy-Rule_Match_Operator_STopo-IM>]
| [<Policy-Rule_Match_Operator_SFC-Policy-IM>]
<Policy-Rule_Action_value_external> ::=
[<Policy-Rule_Action_Values_RIB-IM>]
| [<Policy-Rule_Action_Values_PBR-IM>]
| [<Policy-Rule_Match_Operator_I2RSLC-IM>]
| [<Policy-Rule_Action_Values_BGP-IM>]
| [<Policy-Rule_Set_Operator_STopo-IM>]
| [<Policy-Rule_Set_Operator_SFC-Policy-IM>]
<Policy-Rule_Set_Operator_external> ::=
[<Policy-Rule_Set_Operator_RIB-IM>]
| [<Policy-Rule_Set_Operator_PBR-IM>]
| [<Policy-Rule_Match_Operator_I2RSLC-IM>]
| [<Policy-Rule_Set_Operator_RIB-IM>]
| [<Policy-Rule_Set_Operator_BGP-IM>]
| [<Policy-Rule_Set_Operator_STopo-IM>]
| [<Policy-Rule_Set_Operator_SFC-Policy-IM>]
<Policy-Rule_act_ext_external> ::=
[<Policy-Rule_extension_RIB-IM>]
| [<Policy-Rule_act_ext_PBR-IM>]
| [<Policy-Rule_act_ext_I2RSLC-IM>]
| [<Policy-Rule_act_ext_RIB-IM>]
| [<Policy-Rule_act_ext_BGP-IM>]
| [<Policy-Rule_act_ext_STopo-IM>]
| [<Policy-Rule_act_ext_SFC-Policy-IM>]
| [<I2RS_Vendor-Rule_act_ext>]/* other I2RS IM */
</artwork>
</figure>
</t>
</section>
</section>
<section title="BNP IM Grammar">
<t>This section specifies the network policy information model in
Routing Backus-Naur Form (RBNF, <xref target="RFC5511"></xref>). It also
provides diagrams of the main entities of which the information model is
comprised.</t>
<t>
<figure>
<artwork>
<basic-network_policy_in> ::= (<policy-set> ...)
<basic-network_policy_out> ::= (<policy-set> ...)
<network-policy_rules_list> ::= (<policy-rule>...)
</artwork>
</figure>
</t>
</section>
</section>
<section title="Extensions to the Policy IM">
<section title="Extension to the RIB IM">
<t>
<figure>
<artwork>
Figure 11 - RIB Information Model Extensions
<RIB-IM_READ_list> ::= [<RIB-IM-Tree-Match ...]
<RIB-IM_WRITE_list> ::= [<RIB-IM-Tree-Match ...]
<RIB-IM-Tree-Match> ::= <RIB-IM-Match-routing-instance>
<RIB-IM-Match-interface-list>
<RIM-IM-Match-rib_list>
<RIB-IM-match-route-list;
/* BGP Info Module Tree Match */
<BGP-IM_READ_list> ::= [<BGP-IM-Tree-Match ...]
<BGP-IM_WRITE_list> ::= [<BGP-IM-Tree-Match ...]
<BGP-IM-Tree-Match> ::= <BGP-IM-Tree-Match-protocol-instance>
<BGP-IM-Match-Protocol-instance> ::= (<BGP_protocol> ...)
<pbr_rib> ::= <bgp_route_list>
<bgp_route_list> ::= (<bgp_route> ...)
<bgp_route> ::= <BGP_ROUTE_TYPE>
<bgp_route_prefix>
<bgp_attribute_list>
<bgp_route_create>
<bgp_rt_state_info>
<basic-network_policy_in> ::= (<policy-set> ...)
<basic-network_policy_out> ::= (<policy-set> ...)
<network-policy_rules_list> ::= (<policy-rule>...)
</artwork>
</figure>
</t>
</section>
<section title="Extension from the BGP IM">
<t>
<figure>
<artwork>
Figure 12 - BGP Information Model Extensions
<BGP-IM_READ_list> ::= [<BGP-IM-Tree-Match ...]
<BGP-IM_WRITE_list> ::= [<BGP-IM-Tree-Match ...]
<BGP-IM-Tree-Match> ::= <BGP-IM-Tree-Match-protocol-instance>
<BGP-IM-Match-Protocol-instance> ::= (<BGP_protocol> ...)
</artwork>
</figure>
</t>
</section>
<section title="Extension from SFC Topology IM">
<t>
<figure>
<artwork>
Figure 13 - SFC Topology Information Model Extensions
/* what part of the STopo Model can access */
<STopo-IM_READ_list> ::= [<STopo-IM-Tree-Match ...]
<STopo-IM_WRITE_list> ::= [<STopo-IM-Tree-Match ...]
<STopo-IM-Tree-Match> ::= <STopo-IM-Tree-Match-protocol-instance>
<STopo-IM-Match-Protocol-instance> ::= (<STopo_protocol> ...)
</artwork>
</figure>
</t>
</section>
<section title="Extension from the SFC Traffic Filters">
<t>
<figure>
<artwork>
Figure 14 - Traffic Steering Information Model Extensions
/* what part of the STopo Model can access */
<SFC-Policy-IM_READ_list> ::= [<SF-Policy-IM-Tree-Match ...]
<SFC-Policy-IM_WRITE_list> ::= [<SF-Policy-IM-Tree-Match ...]
<SFC-Policy-IM-Tree-Match> ::= <SF-Policy-IM-Tree-Match-protocol-instance>
<SFC-Policy-IM-Match-Protocol-instance> ::= <SF_instance_list>
</artwork>
</figure>
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft includes no request to IANA.</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Informative References">
&RFC2119;
&RFC3060;
&RFC3644;
&RFC5394;
&RFC5511;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-info-model;
&I-D.hares-i2rs-usecase-reqs-summary;
&I-D.hares-i2rs-bgp-im;
&I-D.hares-i2rs-info-model-service-topo;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:37:42 |