| I2RS working group | S. Hares |
| Internet-Draft | Q. Wu |
| Intended status: Standards Track | Huawei |
| Expires: September 9, 2015 | J. Tantsura |
| R. White | |
| Ericsson | |
| March 8, 2015 |
An Information Model for Basic Network Policy and Filter Rules
draft-hares-i2rs-bnp-info-model-02
This document contains the Basic Network Policy and Filters (BNP IM) Information Model which provides a generic model for representing an ordered list of routing policy or filter rules. Filter rules which combine match-condition with action (forwarding or sets) are supported by this policy.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This generic network policy provide a model to support an ordered list of routing policy or an ordered list of filter rule. An ordered list of policy can be used in protocols such as BGP. An ordered list of filters can be used in filtering for routing data traffic or flows. Two examples of the ordered-based filters is the I2RS Filter-based RIBS or flow specification filtering. This generic model can be used to combine filter rules such as: ACLs, Prefix-filtering, and complex filter match-actions rules (match, set, modify, set).
This generic model combines rules for filter/policy into groups of groups. project.
Antecedents to this generic policy are the generic policy work done in PCIM WG. The PCIM work contains a Policy Core Information Model (PCIM) [RFC3060], Policy Core Informational Model Extensions [RFC3460] and the Quality of Service (QoS) Policy Information Model (QPIM) ([RFC3644]) From PCIM comes the concept that policy rules which are combined into policy groups. PCIM also refined a concept of policy sets that allowed the nesting and aggregation of policy groups. This generic model did not utilize the concept of sets of groups, but could be expanded to include sets of gorups in the future.
Policy rules may include specific filters such as ACL or prefix filters by simple reference. The following drafts provide these more specific filters;
This generic policy model represents filter or routing policies as rules and groups of rules.
The basic concept are:
+-----------+ +------------+
|Rule Group | | Rule Group |
+-----------+ +------------+
^ ^ +----------------+
| | ---| ACL Rules |
| | | | Additions |
| | | +----------------+
| | | +----------------+
+--------^-------+ +-------^-------+ |--|Prefix Rule |
| Rule | | Rule |<----| Additions |
+----------------+ +---------------+ | +----------------+
: : | . . .
: : | +----------------+
......: :..... ---|Other Rules |
: : | Additions |
: : +----------------+
: :
+---------V---------+ +-V-------------+
| Rule Condition | | Rule Action |
+-------------------+ +---------------+
: : : : : :
.....: . :..... .....: . :.....
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+
| Match | | match | |match | | Action || action ||action|
|Operator| |Variable| |Value | |Operator||Variable|| Value|
+--------+ +--------+ +------+ +--------++--------++------+
Figure 1: BNP structure
Rule groups have the following elements:
The rule has the following elements: name, order, status, priority, reference cnt, and match-action as shown as shown in figure 2. The order indicates the order of the rule within the list. The status of the rule is (active, inactive). The priority is the priority within a specific order of policy/filter rules. A reference count (refcnt) indicates the number of entities (E.g. network modules) using this policy. The generic rule match-action conditions have match operator, a match variable and a match value. The rule actions have an action operator, action variable, and an action value.
The generic rules can be included with other types of rules as figure 2 shows.
Figure 2 - Rule Group
+-------------------------------------+ (optional)
| Rule Group |....
+--------------------------------------+ :
* * * ^ :
| | | :....:
| | |
| | |
+------+ +-----+ +-------------------+
| Name | |Role | | Rule_list |
| | | | | |
+------+ +-----+ +------|------------+
* * +------|-----------+
| | | rule |
| | +--|---------------+
| | |
+--+ | | +----------+
| |-| Name |
| | | +----------+
+----+---+ ++----+ | +----------+
|Resource |Scope| | | + Rule |
+--------+ +-----+ |-| order |
| +----------+
| +----------+
|-| Status |
| +----------+
| +----------+
|-| priority |
| +----------+
| +----------+
|-| refcnt |
| +----------+
| +--------------+
|-| Rule |
| match/action |
+-----|--------+
|
+----|--------------|----|-----------+
| | |
+-------|-------+ +----|---------+ +----|---------+ . . .
| bnp generic | | Access rule | | Prefix-list |
| match/action | | match/action | | rule |
+---------------+ +--------------+ +--------------+
Figure 3 - Rule's match-condition
+----------------+
| Rule |
| Match/action |
+----------------+
* *
| |
| |
+---------+ +--------+
...>|Condition|<.......| Action |<...
: +---------+<.......+--------+ :
: : * * : :
:..... | : :... :
| :
+--------+...........:
|Operator|
+--------+
The conditions in one rule may cause actions to set values (E.g. BGP communities) that are examined in a second rule as shown in figure 3.
The generic match conditions are specific to a particular layer are refined by matches to a specific layer (as figure 4 shows), and figure 5's high-level yang defines. The general actions may be generic actions that are specific to a particular layer (L1, L2, L3, service layer) or general forwarding by interface or nexthop. The high-level yang diagram for the matches in figure 5.
Figure 4
+-------------+
| Match |
| Condition |
+-------|-----+
|
+-------------+-|-----------+-----------+
| | | |
V V V V
............ ............ ............ ...........
: L1 : : L2 : : L3 : : Service :
: match : : match : : match : : match :
'''''''''''' '''''''''''' '''''''''''' '''''''''''
Figure 5
module:bnp-generic-rules
import ietf-acl
import ietf-interface
+-rw rule-group* [group-name]
+--rw group-name
+--rw group-scope
| +--resource tree-identity
| +--access access-identity
+--rw group-installer install-identity
+--rw rule* [rule-name]
+--rw rule-name string
+--rw order unit16
+--rw installer
+--rw status enumeration
| +--ro rules-status
| +--ro rule-inactive-reason
| +--ro rule-installer
+--rw priority unit16
+--rw refcnt unit16
+--rw rule-match-act
+--rw match-act-type match-act-type-identity
+--case: BNP-GENERIC-MATCH-ACTION
| +--rw bnp-term-match
| | +--case: interface-match
| | +--case: L1-header-match
| | +--case: L2-header-match
| | +--case: L3-header-match
| | +--case: L4-header-match
| | +--case: Service-header-match
| +--rw bnp-action
| | +--rw genric-actions [nbr-act]
| | | +--rw n-acts
| | | +--rw qos-action
| | | | +--case L1-action
| | | | +--case L2-action
| | | | +--case L3-action
| | | | +--case L4-action
| | | | +--case service-action
| +--rw bnp-forward
| | +--rw forward
| | | +--rw interface interface-ref
| | | +--rw next-hop rib-nexthop-ref
| | | +--rw route-attributes
| | | +--rw rib-route-attributes-ref
| | +--rw fb-std-drop
+--case: ACL-MATCH-ACTION
+--rw acl-match-act acl-list-entry-name
Below is the high level yang diagram for the
The following is an example is an example structure for the rrule match-condition applied to Filter-Based RIB containing a list of routes
figure 6
module: FB-RIB
+--rw FB-RIB-instance-name
+--rw RB-RIB-router-id uint32
+--rw FB-RIB-interface*
| +--rw FB-RIB-interface interface-ref-id
+--rw FB-Default-RIB rib-ref
+--rw FB-RIB
+--rw FB-RIB-Name
+--rw FB-RIB-AFI
+--rw FB-RIB-intf*
+--rw FB-FIB-status-info
| +--rw fb-rib-update-ref uint64
+--rw FB-RIB-Ordered-Filters rule-group-list-ref
uses /nt:bnp-generic-rules
rule-group-list-ref points to rule-group-list
This draft includes no request to IANA.
These generic filters are used in the I2RS FB-RIBs to filter packets in a traffic stream, act to modify packets, and forward data packets. These I2RS filters operate dynamically at same level as currently deployed configured filter-based RIBs to filter, change, and forward traffic. The dynamic nature of this protocol requires that I2RS Filters track the installer of group information and rules.
This section will be augmented after a discussion with security experts.