draft-ietf-i2rs-pkt-eca-data-model-02.txt   draft-ietf-i2rs-pkt-eca-data-model-03.txt 
I2RS working group S. Hares I2RS working group S. Hares
Internet-Draft Q. Wu Internet-Draft L. Dunbar
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: April 8, 2017 R. White Expires: September 14, 2017 R. White
Ericsson Ericsson
October 5, 2016 March 13, 2017
Filter-Based Packet Forwarding ECA Policy Filter-Based Packet Forwarding ECA Policy
draft-ietf-i2rs-pkt-eca-data-model-02.txt draft-ietf-i2rs-pkt-eca-data-model-03.txt
Abstract Abstract
This document describes the yang data model for packet forwarding This document describes the yang data model for packet forwarding
policy that filters received packets and forwards (or drops) the policy that filters received packets and forwards (or drops) the
packets. Prior to forwarding the packets out other interfaces, some packets. Filters for Layer 2, Layer 3, Layer 4, and packet-arrival
of the fields in the packets may be modified. If one considers the time are linked together to support filtering for the routing layer.
packet reception an event, this packet policy is a minimalistic Prior to forwarding the packets out other interfaces, some of the
Event-Match Condition-Action policy. This policy controls forwarding fields in the packets may be modified. (If one considers the packet
of packets received by a routing device on one or more interfaces on reception an event, this packet policy is a minimalistic Event-Match
which this policy is enabled. The policy is composed of an ordered Condition-Action policy.) This policy controls forwarding of packets
list of policy rules. Each policy policy rule contains a set of received by a routing device on one or more interfaces on which this
match conditions that filters for packets plus a set of actions to policy is enabled.
modify the packet and forward packets. The match conditions can
match tuples in multiple layers (L1-L4, application), interface This data model may be used in either the configuration datastore,
received on, and and other conditions regarding the packet (size of control plane datastores, or the I2RS ephemeral control plane
packet, time of day). The modify packet actions allow for setting datastore.
things within the packet plus decapsulation and encapsulation packet.
The forwarding actions include forwarding via interfaces, tunnels, or
nexthops and dropping the packet. The policy model can be used with
the session ephemeral (BGP Flow Specifications), reboot ephemeral
state (I2RS ephemeral), and non-ephemeral routing/forwarding state
(e.g. configuration state ).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 8, 2017.
This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 4
1.2. Antecedents this Policy in IETF . . . . . . . . . . . . . 4
2. Generic Route Filters/Policy Overview . . . . . . . . . . . . 4 2. Generic Route Filters/Policy Overview . . . . . . . . . . . . 4
3. BNP Rule Groups . . . . . . . . . . . . . . . . . . . . . . . 5 3. BNP Rule Groups . . . . . . . . . . . . . . . . . . . . . . . 5
4. Packet ECA (event-condition-action) Filter Model in High 4. BNP Generic Info Model in High Level Yang . . . . . . . . . . 7
Level Yang . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. i2rs-eca-policy Yang module . . . . . . . . . . . . . . . . . 10
4.1. modules included . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
4.2. top level description . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
4.3. Conditional filters . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.1. Event Match Filters . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 38
4.3.2. ECA Packet Condition Matches . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 38
4.4. ECA Packet Actions . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
4.5. Policy Conflict Resolution strategies . . . . . . . . . . 22
4.6. External Data . . . . . . . . . . . . . . . . . . . . . . 22
5. i2rs-eca-policy Yang module . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
7. Security Considerations . . . . . . . . . . . . . . . . . . . 54
8. Informative References . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
This document describes the yang data model for packet forwarding This document describes the yang data model for packet forwarding
policy that filters received packets and forwards (or drops) the policy that filters received packets and forwards (or drops) the
packets. Prior to forwarding the packets out other interfaces, some packets. Prior to forwarding the packets out other interfaces, some
of the fields in the packets may be modified. If one considers the of the fields in the packets may be modified. Filters for Layer 2,
reception of a packet as an event, this minimalistic Event-Match Layer 3, Layer-4 and packet arrival time are linked together to
Condition-Action policy. If one considers the reception of packets support filtering for the routing layer.
containing Layer 1 to Layer 4 + application data a single packet,
then this minimalistic policy can be called a packet-only ECA policy.
This document will use the term packet-only ECA policy for this model
utilizing the term "packet" in this fashion.
This packet-only ECA policy data model supports an ordered list of If one considers the reception of a packet as an event, this
ECA policy rules where each policy rule has a name. The match minimalistic Event-Match Condition-Action policy. Full event-match-
condition filters include matches on condition policy can be found at
[I-D.ietf-supa-generic-policy-data-model] (or the information model
at [I-D.ietf-supa-generic-policy-info-model]). This document will
use the term packet-only ECA policy for this model utilizing the term
"packet" in this fashion.
o content of packet headers for layer 1 to layer 4, ACL data models [I-D.ietf-netmod-acl-model] can also provide a
minimal set of filtering for packet-eca by compiling a large group of
filters. However, this data model also provides the L2-L4 filters
plus a concept of grouping and policy rules. The pkt-eca structure
helps create users with structures with more substantial policy for
security or data flow direction.
o application protocol data and headers, This packet-only ECA policy data model supports an ordered list of
ECA policy rules
o packet headers for layer 2 to layer 4,
o interfaces the packet was received on, o interfaces the packet was received on,
o time packet was received, and o time packet was received, and
o size of packet. o size of packet.
The actions include packet modify actions and forwarding options. The actions include packet modify actions and forwarding options.
The modify options allow for the following: The modify options allow for the following:
o setting fields in the packet header at Layer 2 (L2) to Layer 4 o setting fields in the packet header at Layer 2 (L2) to Layer 4
(L4), and (L4), and
o encapsulation and decapsulation the packet. o encapsulation and decapsulation the packet.
The forwardingng actions allow forwardsing the packet via interfaces, The forwardinng actions allow forwardsing the packet via interfaces,
tunnels, next-hops, or dropping the packet. setting things within tunnels, next-hops, or dropping the packet. setting things within
the packet at Layer 2 (L2) to layer 4 (L4) plus overlay or the packet at Layer 2 (L2) to layer 4 (L4).
application data.
This packet policy draft has been developed as a set of protocol
independent policy It may be used for the configuration datastore, a
control plane datastore, or an I2RS ephemeral control plane datastore
[RFC7921]. For more information configuration and control plane
datastores please see [I-D.ietf-netmod-revised-datastores]. This
yang model may be transmitted over NETCONF [RFC6241] or RESTCONF
[RFC8040]. For use with the control plane datastores and ephemeral
control plane datastores, additional capabilities support control
plane daatastores will need to be added to the base NETCONF and
RESTCONF to support these datastores.
This yang data model depends on the the I2RS RIB
[I-D.ietf-i2rs-rib-data-model] which can be deployed in an
configuration datastore, a control plane datastore, or the I2RS
ephemeral control plane datastore. )for informational module see
[I-D.ietf-i2rs-rib-info-model]. The update of RIB entries via the
rpc features allows datastore validation differences to be handled in
the rpc code.
The first section of this draft contains an overview of the policy The first section of this draft contains an overview of the policy
structure. The second provides a high-level yang module. The third structure. The second provides a high-level yang module. The third
contains the yang module. contains the yang module.
The high-level yang and the actual yang are not aligned. This is an
interim-release of this document.
1.1. Definitions and Acronyms 1.1. Definitions and Acronyms
INSTANCE: Routing Code often has the ability to spin up multiple INSTANCE: Routing Code often has the ability to spin up multiple
copies of itself into virtual machines. Each Routing code copies of itself into virtual machines. Each Routing code
instance or each protocol instance is denoted as Foo_INSTANCE in instance or each protocol instance is denoted as Foo_INSTANCE in
the text below. the text below.
NETCONF: The Network Configuration Protocol NETCONF: The Network Configuration Protocol
PCIM - Policy Core Information Model PCIM - Policy Core Information Model
RESTconf - http programmatic protocol to access yang modules RESTconf - http programmatic protocol to access yang modules
1.2. Antecedents this Policy in IETF
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 groups in the
future.
2. Generic Route Filters/Policy Overview 2. Generic Route Filters/Policy Overview
This generic policy model represents filter or routing policies as This generic policy model represents filter or routing policies as
rules and groups of rules. rules and groups of rules.
The basic concept are: The basic concept are:
Policy set: Rule Group
Policy set is a set of policies
Policy:
A policy is a is an ordered set of rules . A rule group is is an ordered set of rules .
Rule Rule
A Rule is represented by the semantics "If Condition then Action". A Rule is represented by the semantics "If Condition then Action".
A Rule may have a priority assigned to it. A Rule may have a priority assigned to it.
+-------------+ +-----------+ +------------+
| Policy Set | |Rule Group | | Rule Group |
+-^---------^-+ +-----------+ +------------+
| | ^ ^
| | | |
+---------+ +---------+ | |
| policy | | rules |-=========|| +--------^-------+ +-------^-------+
+---------+ +---------+ || | Rule | | Rule |
^ || +----------------+ +---------------+
| || : :
+-|----------+ || : :
| rule-list | || ......: :.....
+------------+ || : :
^ ^ || +---------V---------+ +-V-------------+
| | || | Rule Condition | | Rule Action |
| | || +-------------------+ +---------------+
+-----^---+ +-----^--+ +---^-------+ || : : : : : :
| Rule |==| Rule |==| Rule |==|| .....: . :..... .....: . :.....
+---------+ +--------+ +-:------:---+ : : : : : :
: : +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+
+-----------:+ +-:----------+ | Match | | match | |match | | Action || action ||action|
| cfg-rule | | cfg rule | |Operator| |Variable| |Value | |Operator||Variable|| Value|
| conditions | | Actions | +--------+ +--------+ +------+ +--------++--------++------+
+--:-:-------+ +:---:-:--:--+
: : : : : :.................
:...............: : : : :......... :
: : ......: : : :
: : : : : :
+:-------+ +-------V--+ +-V------+ +-V-----+ +-V-----+ +--V----+
| Rule | | Rule | |eca- | |eca- | |eca- | |eca- |
| event | | Condition| |ingress-| |fwd- | |egress-| |qos- | ...
| match | | match | |actions | |actions| |actions| |actions|
+--------+ +--:---:---+ +--------+ +-------+ +-------+ +-------+
: :
:........: :
: :
+----V----+ +-----V---------+
|eca-event| | eca-condition |
| -match | | -match |
+---------+ +---------------+
Figure 1: ECA rule structure Figure 1: ECA rule structure
3. BNP Rule Groups 3. BNP Rule Groups
The pkt ECA policy is a policy whihc is an order set of pkt-ECA The pkt ECA policy is an order set of pkt-ECA policy rules. The
policy rules. The rules assume the event is the reception of a rules assume the event is the reception of a packet on the machine on
packet on the machine on a set of interfaces. This policy is a set of interfaces. This policy is associated with a set of
associated with a set of interfaces on a routing device (physical or interfaces on a routing device (physical or virtual).
virtual).
A Policy allows for the easy combination of rules for management A Rule group allows for the easy combination of rules for management
stations or users. A policy has the following elements: stations or users. A Rule group has the following elements:
o name that identifies the grouping of policy rules o name that identifies the grouping of policy rules
o module reference - reference to a yang module(s) in the yang o module reference - reference to a yang module(s) in the yang
module library that this group of policy writes policy to module library that this group of policy writes policy to
o list of rules o list of rules
A policy group may have rulies at different order levels. For Rule groups may have multiple policy groups at specific orders. For
example, policy group 1 could have three policy rules at rule order 1 example, policy gorup 1 could have three policy rules at rule order 1
and four policy rules at rule order 5. and four policy rules at rule order 5.
The rule has the following elements: name, order, status, priority, The rule has the following elements: name, order, status, priority,
reference cnt, and match condition, and action as shown as shown in reference cnt, and match condition, and action as shown as shown in
figure 2. The order indicates the order of the rule within the the figure 2. The order indicates the order of the rule within the the
complete list. The status of the rule is (active, inactive). The complete list. The status of the rule is (active, inactive). The
priority is the priority within a specific order of policy/filter priority is the priority within a specific order of policy/filter
rules. A reference count (refcnt) indicates the number of entities rules. A reference count (refcnt) indicates the number of entities
(E.g. network modules) using this policy. The generic rule match- (E.g. network modules) using this policy. The generic rule match-
action conditions have match operator, a match variable and a match action conditions have match operator, a match variable and a match
value. The rule actions have an action operator, action variable, value. The rule actions have an action operator, action variable,
and an action value. and an action value.
Rules can exist with the same rule order and same priority. Rules Rules can exist with the same rule order and same priority. Rules
with the same rule order and same priority are not guaranteed to be with the same rule order and same priority are not guaranteed to be
at any specific ordering. The order number and priority have at any specific ordering. The order number and priority have
sufficient depth that administrators who wish order can specify it. sufficient depth that administrators who wish order can specify it.
Figure 2 - Rule Group
+--------------------------------------+
| Rule Group |
+--------------------------------------+
* * *
| | |
| | |
| | |
+------+ +-------------------+
| Name | | Rule_list |
| | | |
+------+ +------|------------+
+----------------|-----------------------------+
| rule |
|-|------|----------|-----------|------------|-+
| | | | |
+---|--+ +-|----+ +---|-------+ +-|------+ +-------+
| Name | |rule | | ECA | |rule | |ref-cnt|
+------+ |order | | match | |priority| +-------+
|number| |qos-actions| +--------+
+------+ |fwd-actions|
+-----------+
The generic match conditions are specific to a particular layer are The generic match conditions are specific to a particular layer are
refined by matches to a specific layer (as figure 2 shows), and refined by matches to a specific layer (as figure 3 shows), and
figure 5's high-level yang defines. The general actions may be figure 5's high-level yang defines. The general actions may be
generic actions that are specific to a particular layer (L1, L2, L3, generic actions that are specific to a particular layer (L2, L3, or
service layer) or time of day or packet size. The qos actions can be L4) or time of day or packet size. The qos actions can be setting
setting fields in the packet at any layer (L1-L4, service) or fields in the packet at any layer (L2-l4) or encapsulating or
encapsulating or decapsulating the packet at a layer. The fwd- decapsulating the packet at a layer. The fwd-actions are forwarding
actions are forwarding functions that forward on an interface or to a functions that forward on an interface or to a next-hop. The rule
next-hop. The rule status is the operational status per rule. status is the operational status per rule.
+-----------------+ Figure 3
| eca-pkt-matches | +-------------+
+-------|---------+ | Match |
| Condition |
+-------|-----+
| |
+-------------+-|-----------+-----------+ +-------------+-|-----------+-----------+
| | | | | | | |
V V V V V V V V
............ ............ ............ ........... ............ ............ ............ ...........
: L1 : : L2 : : L3 : : Service : . . . : interface: : L2 : : L3 : : L4 : . . .
: match : : match : : match : : match : : match : : match : : match : : match :
'''''''''''' '''''''''''' '''''''''''' ''''''''''' '''''''''''' '''''''''''' '''''''''''' '''''''''''
Figure 2 match logic 4. BNP Generic Info Model in High Level Yang
4. Packet ECA (event-condition-action) Filter Model in High Level Yang
The description of packet event-condition-action data model include:
module included in module
top level diagram
4.1. modules included
Below is the high level module inclusions. Below is the high level inclusion
Figure 5
module:pkt-eca-policy module:pkt-eca-policy
import ietf-inet-types {prefix "inet"} import ietf-inet-types {prefix "inet"}
import ietf-interface {prefix "if"} import ietf-interface {prefix "if"}
import ietf-i2rs-rib {prefix "i2rs-rib"} import ietf-i2rs-rib {prefix "iir"}
import ietf-interfaces { import ietf-interfaces {
prefix "if"; prefix "if";
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
//rfc6991 //rfc6991
} }
import ietf-i2rs-rib {
prefix "i2rs-rib";
Figure 3 - high level inclusion
4.2. top level description
Below is the high level yang diagram Below is the high level yang diagram
module ietf-pkt-eca-policy module ietf-pkt-eca-policy
+--rw pkt-eca-policy-cfg +--rw pkt-eca-policy-cfg
| +--rw pkt-eca-policy-set | +--rw pkt-eca-policy-set
| +--rw policies* [policy-name] | +--rw groups* [group-name]
| | +--rw policy-name string | | +--rw group-name string
| | +--rw vrf-name string | | +--rw vrf-name string
| | +--rw address-family | | +--rw address-family
| | +--rw rule-list* [rule-name] | | +--rw group-rule-list* [rule-name]
| | | +--rw rule-name | | | +--rw rule-name
| | | +--rw rule-order-id uint16 | | | +--rw rule-order-id
| | | +--rw default-action-id integer | | | +--rw default-action-id integer
| | | +--rw default-resolution-strategy-id integer | | | +--rw default-resolution-strategy-id integer
| +--rw rules* [order-id rule-name] | +--rw rules* [order-id rule-name]
| +--rw order-id uint16 | +--rw order-id
| +--rw rule-name string | +--rw rule-name
| +--rw policy-name string | +--rw cfg-rule-conditions [cfgr-cnd-id]
| +--rw cfg-rule-conditions [rule-cnd-id] | | +--rw cfgr-cnd-id integer
| | +--rw rule-cnd-id uint32 | | +--rw eca-event-match
| | +--rw support | | | +--rw time-event-match*
| | | +--rw event-matches boolean | | | | .. (time of day)
| | | +--rw pkt-matches boolean
| | | +--rw usr-context-matches boolean
| | +--rw eca-events-match* [rule-event-id]
| | | +--rw rule-event-it uint16
| | | | ... time-event match (see below)
| | +--rw eca-condition-match | | +--rw eca-condition-match
| | | +--rw eca-pkt-matches* [pkt-match-id] | | | +--rw eca-pkt-matches*
| | | | ...(see packet matches below) | | | | ... (L2-L4 matches)
| | | | ... (address, packet header, packet payload)
| | | +--rw eca-user-context-matches* [usr-match-id]
| | | | ... (see user context match below)
| +--rw cfg-rule-actions [cfgr-action-id] | +--rw cfg-rule-actions [cfgr-action-id]
| | +--rw cfgr-action-id | | +--rw cfgr-action-id
| | +--rw eca-actions* [action-id] | | +--rw eca-actions* [action-id]
| | | +--rw action-id uint32 | | | +--rw action-id uint32
| | | +--rw eca-ingress-actions* | | | +--rw eca-ingress-act*
| | | | ... (permit, deny, mirror) | | | | ... (permit, deny, mirror)
| | | +--rw eca-fwd-actions* | | | +--rw eca-fwd-actions*
| | | | ... (invoke, tunnel encap, fwd) | | | | ... (invoke, tunnel encap, fwd)
| | | +--rw eca-egress-acttions* | | | +--rw eca-egress-act*
| | | | .. . | | | | .. .
| | | +--rw eca-qos-actions* | | | +--rw eca-qos-actions*
| | | | ... | | | | ...
| | | +--rw eca-security-actions*
| +--rw policy-conflict-resolution* [strategy-id]
| | +--rw strategy-id integer
| | +--rw filter-strategy identityref
| | | .. FMR, ADTP, Longest-match
| | +--rw global-strategy identityref
| | +--rw mandatory-strategy identityref
| | +--rw local-strategy identityref
| | +--rw resolution-fcn uint32
| | +--rw resolution-value uint32
| | +--rw resolution-info string
| | +--rw associated-ext-data*
| | | +--rw ext-data-id integer | | | +--rw ext-data-id integer
| +--rw cfg-external-data* [cfg-ext-data-id] | +--rw cfg-external-data* [cfg-ext-data-id]
| | +--rw cfg-ext-data-id integer | | +--rw cfg-ext-data-id integer
| | +--rw data-type integer | | +--rw data-type integer
| | +--rw priority uint64 | | +--rw priority uint64
| | | uses external-data-forms | | | uses external-data-forms
| | ... (other external data) | | ... (other external data)
+--rw pkt-eca-policy-opstate +--rw pkt-eca-policy-opstate
+--rw pkt-eca-opstate +--rw pkt-eca-opstate
+--rw policies-opstat* [policy-name] +--rw groups* [group-name]
| +--rw rules-installed; | +--rw rules-installed;
| +--rw rules_opstat* [rule-name] | +--rw rules_status* [rule-name]
| +--rw strategy-used [strategy-id] | +--rw strategy-used [strategy-id]
| +--rw
+--rw rule-group-link* [rule-name]
| +--rw group-name
+--rw rules_opstate* [rule-order rule-name] +--rw rules_opstate* [rule-order rule-name]
| +--rw status | +--rw status
| +--rw rule-inactive-reason | +--rw rule-inactive-reason
| +--rw rule-install-reason | +--rw rule-install-reason
| +--rw rule-installer | +--rw rule-installer
| +--rw refcnt | +--rw refcnt
+--rw rules_pktstats* [rule-order rule-name] +--rw rules_op-stats* [rule-order rule-name]
| +--rw pkts-matched | +--rw pkts-matched
| +--rw pkts-modified | +--rw pkts-modified
| +--rw pkts-forward | +--rw pkts-forward
+--rw op-external-data [op-ext-data-id] +--rw op-external-data [op-ext-data-id]
| +--rw op-ext-data-id integer | +--rw op-ext-data-id integer
| +--rw type identityref | +--rw type identityref
| +--rw installed-priority integer | +--rw installed-priority integer
| | (other details on external data ) | | (other details on external data )
figure 4 - high-level yang for policy set
The three levels of policy are expressed as: The three levels of policy are expressed as:
Config Policy definitions Config Policy definitions
======================================= =======================================
Policy level: pkt-eca-policy-set Policy level: pkt-eca-policy-set
group level: pkt-eca-policy-set:policies group level: pkt-eca-policy-set:groups
rule level: pkt-eca-policy-set:rules rule level: pkt-eca-policy-set:rules
external id: pkt-eca-policy-set:cfg-external-data external id: pkt-eca-policy-set:cfg-external-data
Operational State for Policy Operational State for Policy
======================================= =======================================
Policy level: pkt-eca-policy-opstate Policy level: pkt-eca-policy-opstate
group level: pkt-eca-opstate:policies-opstat* group level: pkt-eca-opstate:groups
rule level: pkt-eca-opstate:rules_opstat* group-rule: pkt-eca-opstate:rule-group-link*
pkt-eca-opstate:rules-pktstat* rule level: pkt-eca_opstate:rules_opstate*
external id: pkt-eca-opstate:op-external-data* pkt-eca_op-stats
figure 5
4.3. Conditional filters
The condition filters in the packet eca policy module included the
following:
o event filters - time as an augment to reception of a packet.
o conditional matches on packet content or user-related content
The sections below provide the high-level yang for these sections of
hte model.
module:i2rs-pkt-eca-policy
.....
+--rw pkt-eca-policy-cfg
| +--rw pkt-eca-policy-set
| +--rw pkt-eca-policy-set
| | ...
| +--rw rules* [order-id rule-name]
| +--rw order-id uint16
| +--rw rule-name string
| +--rw policy-name string
| +--rw cfg-rule-conditions [rule-cnd-id]
| | +--rw rule-cnd-id integer
| | +--rw eca-events-match* [rule-event-id]
| | | +--rw rule-event-it uint16
| | | | ... time-event match (see below)
| | +--rw eca-condition-match
| | | +--rw eca-pkt-matches* [pkt-match-id]
| | | | ... (see L1-L4 matches below)
| | | +--rw eca-usr-context-matches* [usr-match-id]
| | | | (user, schedule, region, target,
| | | | state, direction)
Figure 6
4.3.1. Event Match Filters
The default event is the event of receiving a packet. In addition,
the events allow a time-event match. Time events are provided as a
list which includes specific times or ranges of time.
| +--rw pkt-eca-policy-set
| +--rw pkt-eca-policy-set
| | ...
| +--rw rules* [order-id rule-name]
| +--rw order-id uint16
| +--rw rule-name string
| +--rw policy-name string
| +--rw cfg-rule-conditions [rule-cnd-id]
| | +--rw rule-cnd-id uint32
| | +--rw support
| | | +--rw event-matches boolean
| | | +--rw pkt-matches boolean
| | | +--rw usr-context-matches boolean
| | +--rw eca-events-match* [rule-event-id]
| | | +--rw rule-event-it uint16
| | | +--rw time-type identityref
| | | +--(one-time)
| | | | +--rw event-time yang:date-and-time
| | | +--(range-time)
| | | +--rw event-start-time yang:date-and-time
| | | +--rw event-end-time yang:date-and-time
figure 7
4.3.2. ECA Packet Condition Matches
The ECA condition matches are packet matches (eca)
4.3.2.1. Packet-match filter list (eca-pkt-match*)
The packet match content filters include: address filters and packet
header content filters, and packet payload filters.
module:i2rs-pkt-eca-policy
+--pkt-eca-policy-set
+--rw rules* [order-id rule-name]
| |....
| +--rw cfg-rule-conditions [rule-cnd-id]
| | +--rw rule-cnd-id uint32
| | +--rw support
| | | +--rw event-matches boolean
| | | +--rw pkt-matches boolean
| | | +--rw usr-context-matches boolean
| | +--rw eca-event-match
| | | ...
| | +--rw eca-condition-match
| | +--rw eca-pkt-matches* [pkt-match-id]
| | | +--rw packet-match-id uint16
| | | +--rw packet-match-type identityref
| | | +--(packet-match-type)?
| | | | +--:(address-pkt-match)
| | | | | ...
| | | | +--:(layer-pkt-match)
| | | | | ...
| | | | +--:(payload-pkt-match)
| | | | | ...
| | +--rw eca-user-matches [user-match-id]
Figure 8
4.3.2.1.1. Match filters for addresses in packet
The address matches match the L3, mpls, MAC and interface address
scope. Figure x shows this match
+--rw eca-pkt-matches* [pkt-match-id]
| +--rw packet-match-id uint16
| +--rw eca-pkt-match-type identityref
| +--address-scope?
| | +--:(route-type)
| | | +--: (ipv4)
| | | | ... src, dest, src-dest
| | | +--: (ipv6)
| | | | ... src, dest, src-dest
| | | +--: (mpls)
| | | | ... 32 bit label
| | | +--: (mac)
| | | | ... src, dest, src-dest
| | | +--: (interface-route)
| | | | .... interface
Figure 9
4.3.2.1.2. Packet header matches
The packet header matches match interface, L1-L4 headers, service
chain headers, and packet size. The L1 header expected to be a null
match except if there is an advanced L1 technology such as l1 with a
L1 identifier that can be detected in the packet. Figure x shows
these matches.
| +--rw (layer-type)
| | +--:(interface-match-type)
| | | |...
| | +--:(L1-header-match)
| | | |...
| | +--:(L2-header-match)
| | | +--(802.1Q)
| | | |....
| | | +--(802.11)
| | | | ...
| | | +--(802.15)
| | | | ...
| | | +--(NVGRE)
| | | | ...
| | | +--(VXLAN)
| | | | ...
| | | +--(MPLS )
| | | | ..
| | +--:(L3-header-match)
| | | +--(l3-ipv4-header)
| | | | ...
| | | +--(l3-ipv6-header)
| | | | ...
| | | +--(l3-gre-header)
| | | | ...
| | +--: L4-header-match
| | | +--(l4-tcp-header)
| | | | ...
| | | +--(l4-udp-header)
| | | | ...
| | | +--(l4-sctp-header)
| | | | ...
| | | +--: Service-header-match
| | | +--(sf-chain-meta-match)
| | | ...
| | | +--(sf-path-meta-match)
| | | ..
| | +--:(packet-size)
| | +--l1-size-match uint32
| | +--l2-size-match uint32
| | +--l3-size-match uint32
| | +--l4-size-mtach uint32
| | +--service-meta-size uint32
| | +--leaf service-meta-payload uint32
| +---rw packet
Figure 10
4.3.2.1.3. Payload matches
The payload information is a stream of bytes to be found in the
packet payload beyond the L4 or service-path header. The structure
of this data is simply a list of byte strings as figure x shows.
| | |....
| | +--rw eca-pkt-matches* [pkt-match-id]
| | | +--rw packet-match-id uint16
| | | +--rw packet-match-type identityref
| | | +--(packet-match-type)?
| | | | +--:(address-pkt-match)
| | | | | ...
| | | | +--:(layer-pkt-match)
| | | | | ...
| | | | +--:(payload-pkt-match)
| | | | | +--rw packet-payload *[packet-payload-id]
| | | | | +--rw packet-payload-id uint16
| | | | | +--rw payload-match-bytes uint16
| | | | | +--rw packet-payload string
Figure 11
4.3.2.2. Matches on User Context
The match on user context allows filtering for a packet plus a filter
related to a user.
Since not all I2RS routers are access routers, the support for
matches has a flag for user filter. It is expected that core routers
may not support contextual matching.
One example of user filters is for is parental controls. During
school hours, the teenager Joe is restrict from certain web sites
from September 1 while Joe is at at school. This "school" filter is
an example of a period filter which has a start time (8:00am) and end
time (3:30pm), which is valid beginning September 1, 2016. This
filter applies only to the region of school networks. The filter
looks for specific entertainment (e.g. YouTube) web sites, social-
media (e.g. facebook), and gaming sites. This block is for their
mobile phone and tablet, but not the computer that says at home.
The following is the components
o user identifier (name, tenant id, virtual network),
o schedule for the user filter (once or periodic, time range (start/
end), and weekly validity check),
o region this filter is valid.
o targeted services, applications, devices, and state. figure
The filter matches struture is shown below
module:i2rs-pkt-eca-policy module:i2rs-pkt-eca-policy
..... +--rw pkt-eca-policy-cfg
+--rw pkt-eca-policy-cfg | +--rw pkt-eca-policy-set
| +--rw pkt-eca-policy-set | +--rw groups* [group-name]
| +--rw pkt-eca-policy-set | | ...
| | ... | +--rw rules [order-id rule-name]
| +--rw rules* [order-id rule-name] | +--rw eca-matches
| +--rw order-id uint16 | | | +--case: interface-match
| +--rw rule-name string | | | +--case: L2-header-match
| +--rw policy-name string | | | +--case: L3-header-match
| +--rw cfg-rule-conditions [rule-cnd-id] | | | +--case: L4-header-match
| | +--rw rule-cnd-id uint32 | | | +--case: packet-size
| | | ... | | | +--case: time-of-day
| | +--rw eca-event-match* [rule-event-id]
| | | ..
| | +--rw eca-pkt-matches* [pkt-match-id]
| | | ....
| | +--rw eca-usr-context-matches* [usr-match-id]
| | | +--rw user* [user-id]
| | | | +--rw user-id uint32
| | | | +--rw user-name string
| | | | +--rw user-type identityref
| | | | | +--(user-type)?
| | | | | | +--:(tenant)
| | | | | | | +--rw tenant-id uint16
| | | | | | +--:(vn-id)
| | | | | | | +--rw vn-id uint16
| | | +--rw schedule* [schedule-name]
| | | | .....
| | | +--rw target
| | | | +--rw protocol
| | | | | ... (UDP, TCP, ICMP, ICMPv6, IP, IPv6)
| | | | +--rw transport-ports
| | | | | +--rw src-port inet:port-number
| | | | | +--rw dest-port intent:port-number
| | | | +--service [service-name]
| | | | |...
| | | | +--rw application
| | | | |...
| | | | +--rw device
| | | | | ..
Figure 12
Schedule filters allow a time for the filter. Continuing our
parental control filters for school, the schedule an be a list of
weekly filters for Monday-Friday of the school week. The first
filter (School-Monday) would have a of start time of 8:00am GMT
September 5, 2016 an end time of 4:00pm GMT September 5, 2016. The
schedule type woudl be weekly. The validity-until time would be
December 20, 2016. The region impacted by this schedule would be
AS20999 which is the service provider of the school's network.
+--rw pkt-eca-policy-cfg
| +--rw pkt-eca-policy-set
| +--rw pkt-eca-policy-set
| | ...
| +--rw rules* [order-id rule-name]
| +--rw order-id uint16
| +--rw rule-name string
| +--rw policy-name string
| +--rw cfg-rule-conditions [rule-cnd-id]
| | +--rw rule-cnd-id uint32
| | +--rw eca-usr-context-matches* [usr-match-id]
| | | +--rw schedule* [schedule-name]
| | | | +--rw schedule-name
| | | | +--rw schedule-type identityref /* one-time, weekly, 2 weeks, monthly */
| | | | +--rw start-type? yang:date-and-time
| | | | +--rw end-type? yang:date-and-time
| | | | +--rw validity-until yang:date-and-time /* valid until */
| | | +--rw region *[as-4byte]
| | | | +--rw as-4byte uint32 /* region */
figure 13
The target for this service filtering is specified by protocols,
applications, and devices. The figure below shows the filtering for
a target protocol and port number or an application.
+--rw pkt-eca-policy-cfg
| +--rw pkt-eca-policy-set
| +--rw pkt-eca-policy-set
| | ...
| +--rw rules* [order-id rule-name]
| +--rw order-id uint16
| +--rw rule-name string
| +--rw policy-name string
| +--rw cfg-rule-conditions [rule-cnd-id]
| | +--rw rule-cnd-id uint32
| | +--rw eca-usr-context-matches* [usr-match-id]
| | | +--rw target
| | | | +--rw service* [svc-id svc-name]
| | | | | +--rw svc-id uint16
| | | | | +--rw svc-name string
| | | | | +--rw protocol-support
| | | | | | +--rw TCP boolean
| | | | | | +--rw UDP boolean
| | | | | | +--rw ICMP boolean
| | | | | | +--rw ICMPv6 boolean
| | | | | | +--rw IP boolean
| | | | | +--rw src-port? inet:port-number
| | | | | +--rw dest-port? inet_port-number
| | | | +--rw application* [app-name]
| | | | | +--rw app-name string
| | | | | +--rw app-id uint16
| | | | | +--rw app-category
| | | | | /* business, educational, internet */
| | | | | +--rw app-subcategory
| | | | | /* finance, email, game, social-net, web */
| | | | | +--rw app-data-transmission
| | | | | /* client-server, web-brower, p2p, network */
| | | | | +--rw app-risk-level
| | | | | /* exploitable, evasive, data-lost, malware-vehicle, tun
| | | | +--rw device
| | | | | +--rw pc boolean
| | | | | +--rw mobile-phone boolean
| | | | | +--rw tablet boolean
| | | | | +--rw voip-phone boolean
Figure 14
4.4. ECA Packet Actions
The packet actions list includes ingress actions,egress actions, Qos
actions that modify the packet, and security actions. The High level
Yang that shows where the action fit is in figure 15, and the details
are shown in figure 16. The QoS actions per header is shown in
figure 17.
module ietf-pkt-eca-policy module:i2rs-pkt-eca-policy
+--rw pkt-eca-policy-cfg +--rw pkt-eca-policy-cfg
| +--rw pkt-eca-policy-set | +--rw pkt-eca-policy-set
| +--rw policies* [policy-name] | +--rw groups* [group-name]
| | +--rw policy-name string | | ...
| | +--rw vrf-name string
| | +--rw address-family
| | +--rw rule-list* [rule-name]
| | | +--rw rule-name
| | | +--rw rule-order-id uint16
| | | +--rw default-action-id integer
| | | +--rw default-resolution-strategy-id integer
| +--rw rules* [order-id rule-name] | +--rw rules* [order-id rule-name]
| +--rw order-id uint16 | +--rw eca-matches
| +--rw rule-name string | | . . .
| +--rw cfg-rule-conditions [rule-cnd-id] | +--rw ecq-qos-actions
| | ... | | +--rw cnt-actions
| +--rw cfg-rule-actions* [cfgr-action-id]
| | +--rw cfgr-action-id
| | +--rw eca-actions* [action-id]
| | | +--rw action-id uint32
| | | +--rw eca-ingress-actions
| | | | ... (permit, deny, mirror)
| | | +--rw eca-fwd-actions*
| | | | ... (invoke, tunnel encap, fwd)
| | | +--rw eca-egress-actions*
| | | | ()
| | | +--rw eca-qos-actions*
| | | | ...
| | | +--rw eca-security-actions*
Figure 15
This figure shows the details for each action section (ingress,
egress, qos, and security).
| +--rw eca-ingress-actions
| | +--rw num-fwd-actions
| | +--rw fwd-actions
| | | +--rw permit boolean
| | | +--rw mirror boolean
| | | +--rw interface-fwd ip:interface-ref
| | | +--uses i2rs:rib-nexthop
| | | +--uses ip-next-fwd;
| +--rw eca-egress-actions
| | +--rw packet-rate uint32
| | +--rw byte-rate uint32
| | +--rw tunnel-encap boolean
| | +--rw exit-fwding boolean
| | +--rw interface-egress ip:interface-ref
| | +--uses i2rs:rib-nexthop
| | +--uses ip-next-fwd;
| +--rw eca-qos-actions
| | ... (see figure x below )
| +--rw eca-security
|
| | +--rw security-action-type identityref
| | +--(security-action-type)?
| | +--:(content-security-action) ANYXML
| | | ...
| | +--:(attack-mitigation-type) ANYXML
| | | ..
| | +--:(single-packet-type) ANYXML
figure 16 - forwarding
> The QOS actions modify the headers are shown below.
| +--rw ecq-qos-actions
| | +--rw cnt-actions uint8 /* modifying actions */
| | +--rw mod-actions | | +--rw mod-actions
| | | +--case interface-actions | | | +--case interface-actions
| | | | ..
| | | +--case L1-action
| | | | ..
| | | +--case L2-action | | | +--case L2-action
| | | | ..
| | | +--case L3-action | | | +--case L3-action
| | | | ..
| | | +--case L4-action | | | +--case L4-action
| | | | .. | +--rw eca-fwd-actions
| | | +--case service-action | | +--rw num-fwd-actions
| | | | .. | | +--rw fwd-actions
| | | +--rw interface interface-ref
Figure 17 | | | +--rw next-hop rib-nexthop-ref
| | | +--rw route-attributes
4.5. Policy Conflict Resolution strategies | | | +--rw rib-route-attributes-ref
| | | +--rw fb-std-drop
Some policies within the filter-base policy will conflict. For
example, a global strategy may conflict with a local node strategy.
This portion of the filter-based data model provides this support.
| +--rw pc-resolution-strategies* [strategy-id]
| | +--rw strategy-id integer
| | +--rw pc-resolution-supported boolean
| | +--rw filter-strategy identityref
| | | .. FMR, ADTP, Longest-match
| | +--rw global-strategy identityref
| | +--rw mandatory-strategy identityref
| | +--rw local-strategy identityref
| | +--rw resolution-fcn uint32
| | +--rw resolution-value uint32
| | +--rw resolution-info string
| | +--rw associated-ext-data*
| | | +--rw ext-data-id integer
Figure 18
4.6. External Data
External data may be used to set the policy.
| +--rw cfg-external-data* [cfg-ext-data-id]
| | +--rw cfg-ext-data-id integer
| | +--rw data-type integer
| | +--rw priority uint64
| | +--rw external-data-forms anyxml /* mount point */
Figure 19
5. i2rs-eca-policy Yang module 5. i2rs-eca-policy Yang module
<CODE BEGINS> file "ietf-pkt-eca-policy@2016-02-09.yang" <CODE BEGINS> file "ietf-pkt-eca-policy@2017-03-13.yang"
module ietf-pkt-eca-policy { module ietf-pkt-eca-policy {
namespace "urn:ietf:params:xml:ns:yang:ietf-pkt-eca-policy"; namespace "urn:ietf:params:xml:ns:yang:ietf-pkt-eca-policy";
// replace with iana namespace when assigned // replace with iana namespace when assigned
prefix "pkt-eca-policy"; prefix "pkt-eca-policy";
import ietf-routing {
import ietf-routing { prefix "rt";
prefix "rt"; }
} import ietf-interfaces {
import ietf-interfaces { prefix "if";
prefix "if"; }
} import ietf-inet-types {
import ietf-inet-types { prefix inet;
prefix inet; //rfc6991
//rfc6991
}
import ietf-i2rs-rib {
prefix "i2rs-rib";
} }
// meta import ietf-i2rs-rib {
organization "IETF I2RS WG"; prefix "iir";
}
contact
"email: shares@ndzh.com
email: russ.white@riw.com
email: linda.dunbar@huawei.com
email: bill.wu@huawei.com";
description
"This module describes a basic network policy
model with filter per layer.";
revision "2016-06-26" { // meta
description "sec ond revision"; organization "IETF I2RS WG";
reference "draft-ietf-i2rs-pkt-eca-policy-dm-03";
} contact
"email: shares@ndzh.com
email: russ.white@riw.com
email: linda.dunbar@huawei.com
email: bill.wu@huawei.com";
// interfaces - no identity matches description
"This module describes a basic network policy
model with filter per layer.";
// L1 header match identities revision "2017-03-13" {
identity l1-header-match-type { description "third revision";
description reference "draft-ietf-i2rs-pkt-eca-policy-dm-03";
" L1 header type for match "; }
}
identity l1-hdr-sonet-type { // interfaces - no identity matches
base l1-header-match-type;
description
" L1 header sonet match ";
}
identity l1-hdr-OTN-type { // L2 header match identities
base l1-header-match-type; identity l2-header-match-type {
description description
" L1 header OTN match "; " l2 header type for match ";
} }
identity l1-hdr-dwdm-type {
base l1-header-match-type;
description
" L1 header DWDM match ";
}
// L2 header match identities
identity l2-header-match-type {
description
" l2 header type for match ";
}
identity l2-802-1Q { identity l2-802-1Q {
base l2-header-match-type; base l2-header-match-type;
description description
" l2 header type for 802.1Q match "; " l2 header type for 802.1Q match ";
} }
identity l2-802-11 {
base l2-header-match-type;
description
" l2 header type for 802.11 match ";
}
identity l2-802-11 { identity l2-802-15 {
base l2-header-match-type; base l2-header-match-type;
description description
" l2 header type for 802.11 match "; " l2 header type for 802.15 match ";
} }
identity l2-802-15 {
base l2-header-match-type;
description
" l2 header type for 802.15 match ";
}
identity l2-NVGRE { identity l2-NVGRE {
base l2-header-match-type;
description
" l2 header type for NVGRE match ";
}
identity l2-mpls {
base l2-header-match-type; base l2-header-match-type;
description
" l2 header type for MPLS match ";
}
identity l2-VXLAN {
base l2-header-match-type;
description description
" l2 header type for VXLAN match "; " l2 header type for NVGRE match ";
} }
identity l2-mpls {
// L3 header match identities base l2-header-match-type;
identity l3-header-match-type { description
description " l2 header type for MPLS match ";
" l3 header type for match "; }
}
identity l3-ipv4-hdr {
base l3-header-match-type;
description
" l3 header type for IPv4 match ";
}
identity l3-ipv6-hdr {
base l3-header-match-type;
description
" l3 header type for IPv6 match ";
}
identity l3-gre-tunnel {
base l3-header-match-type;
description "l3 header r
type for GRE tunnel match ";
}
identity l3-icmp-header {
base l3-header-match-type;
description "L3 header match for ICMP";
}
identity l3-ipsec-ah-header {
base l3-header-match-type;
description "AH IPSEC header ";
}
identity l3-ipsec-esp-header {
base l3-header-match-type;
description "AH IPSEC header ";
}
// L4 header match identities
identity l4-header-match-type {
description "L4 header
match types. (TCP, UDP,
SCTP, UDPLite, etc. )";
}
identity l4-tcp-header {
base l4-header-match-type;
description "L4 header for TCP";
}
identity l4-udp-header { identity l2-VXLAN {
base l4-header-match-type; base l2-header-match-type;
description "L4 header match for UDP"; description
} " l2 header type for VXLAN match ";
}
identity l4-udplite { // L3 header match identities
base l4-header-match-type; identity l3-header-match-type {
description "L4 header match for description
UDP lite"; " l3 header type for match ";
} }
identity l4-sctp-header { identity l3-ipv4-hdr {
base l4-header-match-type; base l3-header-match-type;
description "L4 header match for SCTP"; description
} " l3 header type for IPv4 match ";
}
// Service header identities identity l3-ipv6-hdr {
base l3-header-match-type;
description
" l3 header type for IPv6 match ";
}
identity l3-gre-tunnel {
base l3-header-match-type;
description "l3 header r
type for GRE tunnel match ";
}
identity service-header-match-type { identity l3-icmp-header {
description "service header base l3-header-match-type;
match types: service function path description "L3 header match for ICMP";
(sf-path)), SF-chain, sf-discovery, }
and others (added here)";
}
identity sf-chain-meta-match { identity l3-ipsec-ah-header {
base service-header-match-type; base l3-header-match-type;
description "service header match for description "AH IPSEC header ";
meta-match header"; }
}
identity sf-path-meta-match { identity l3-ipsec-esp-header {
base service-header-match-type; base l3-header-match-type;
description "service header match for description "AH IPSEC header ";
path-match header"; }
}
identity rule-status-type { // L4 header match identities
description "status
values for rule: invalid (0),
valid (1), valid and installed (2)";
}
identity rule-status-invalid { identity l4-header-match-type {
base rule-status-type; description "L4 header
description "invalid rule status."; match types. (TCP, UDP,
} SCTP, UDPLite, etc. )";
}
identity rule-status-valid { identity l4-tcp-header {
base rule-status-type; base l4-header-match-type;
description "This status indicates description "L4 header for TCP";
a valid rule."; }
} identity l4-udp-header {
base l4-header-match-type;
description "L4 header match for UDP";
}
identity rule-status-valid-installed { identity l4-udplite {
base rule-status-type; base l4-header-match-type;
description "This status indicates description "L4 header match for
an installed rule."; UDP lite";
} }
identity rule-status-valid-inactive {
base rule-status-type;
description "This status indicates
a valid ruled that is not installed.";
}
identity rule-cr-type { identity l4-sctp-header {
description "status base l4-header-match-type;
values for rule: FMR (0), ADTP (1), description "L4 header match for SCTP";
Longest-match (2)"; }
}
identity rule-cr-FMR { identity rule-status-type {
base rule-cr-type; description "status
description "first match resolution."; values for rule: invalid (0),
} valid (1), valid and installed (2)";
}
identity rule-cr-ADTP { identity rule-status-invalid {
base rule-cr-type; base rule-status-type;
description "ADTP resolution."; description "invalid rule status.";
} }
identity rule-cr-longest { identity rule-status-valid {
base rule-cr-type; base rule-status-type;
description "longest match resolution."; description "This status indicates
} a valid rule.";
grouping interface-match {
leaf match-if-name {
type if:interface-ref;
description "match on interface name";
} }
description "interface
has name, description, type, enabled
as potential matches";
}
grouping interface-actions {
description
"interface action up/down and
enable/disable";
leaf interface-up {
type boolean;
description
"action to put interface up";
}
leaf interface-down {
type boolean;
description
"action to put interface down";
}
leaf interface-enable {
type boolean;
description
"action to enable interface";
}
leaf interface-disable {
type boolean;
description
"action to disable interface";
}
}
grouping L1-header-match { identity rule-status-valid-installed {
choice l1-header-match-type { base rule-status-type;
case l1-hdr-sonet-type { description "This status indicates
// sonet matches an installed rule.";
} }
case L1-hdr-OTN-type { identity rule-status-valid-inactive {
// OTN matches base rule-status-type;
} description "This status indicates
case L1-hdr-dwdm-type { a valid ruled that is not installed.";
// DWDM matches }
}
description
"The Layer 1 header match choices";
}
description
"The Layer 1 header match includes
any reference to L1 technology";
}
grouping L1-header-actions {
leaf l1-hdr-sonet-act {
type uint8;
description "sonet actions";
}
leaf l1-hdr-OTN-act {
type uint8;
description "OTN actions";
}
leaf l1-hdr-dwdm-act {
type uint8;
description "DWDM actions";
}
description "L1 header match
types";
}
grouping L2-802-1Q-header { grouping interface-match {
description leaf match-if-name {
"This is short-term 802.1 header type if:interface-ref;
match which will be replaced description "match on interface name";
by reference to IEEE yang when }
it arrives. Qtag 1 is 802.1Q description "interface
Qtag2 is 802.1AD"; has name, description, type, enabled
as potential matches";
}
leaf vlan-present { grouping interface-actions {
type boolean; description
description " Include VLAN in header"; "interface action up/down and
} enable/disable";
leaf qtag1-present { leaf interface-up {
type boolean;
description " This flag value indicates
inclusion of one 802.1Q tag in header";
}
leaf qtag2-present{
type boolean; type boolean;
description "This flag indicates the description
inclusion of second 802.1Q tag in header"; "action to put interface up";
} }
leaf interface-down {
leaf dest-mac { type boolean;
type uint64; //change to uint48 description
description "IEEE destination MAC value "action to put interface down";
from the header"; }
leaf interface-enable {
type boolean;
description
"action to enable interface";
}
leaf interface-disable {
type boolean;
description
"action to disable interface";
} }
leaf src-mac { }
type uint64; //change to uint48
description "IEEE source MAC
from the header";
} grouping L2-802-1Q-header {
leaf vlan-tag { description
type uint16; "This is short-term 802.1 header
description "IEEE VLAN Tag match which will be replaced
from the header"; by reference to IEEE yang when
} it arrives. Qtag 1 is 802.1Q
leaf qtag1 { Qtag2 is 802.1AD";
type uint32;
description "Qtag1 value leaf vlan-present {
from the header"; type boolean;
} description " Include VLAN in header";
leaf qtag2 { }
type uint32; leaf qtag1-present {
description "Qtag1 value type boolean;
description " This flag value indicates
inclusion of one 802.1Q tag in header";
}
leaf qtag2-present{
type boolean;
description "This flag indicates the
inclusion of second 802.1Q tag in header";
}
leaf dest-mac {
type uint64; //change to uint48
description "IEEE destination MAC value
from the header"; from the header";
} }
leaf L2-ethertype { leaf src-mac {
type uint16; type uint64; //change to uint48
description "Ether type description "IEEE source MAC
from the header"; from the header";
}
}
grouping L2-VXLAN-header { }
container vxlan-header { leaf vlan-tag {
uses i2rs-rib:ipv4-header; type uint16;
leaf vxlan-network-id { description "IEEE VLAN Tag
type uint32; from the header";
description "VLAN network id"; }
leaf qtag1 {
type uint32;
description "Qtag1 value
from the header";
}
leaf qtag2 {
type uint32;
description "Qtag1 value
from the header";
} }
description " choices for leaf L2-ethertype {
L2-VLAN header matches. type uint16;
Outer-header only. description "Ether type
Need to fix inner header. "; from the header";
} }
description }
"This VXLAN header may
be replaced by actual VXLAN yang
module reference";
}
grouping L2-NVGRE-header {
container nvgre-header { grouping L2-VXLAN-header {
uses L2-802-1Q-header; container vxlan-header {
uses i2rs-rib:ipv4-header; uses iir:ipv4-header;
leaf gre-version { leaf vxlan-network-id {
type uint8; type uint32;
description "L2-NVGRE GRE version"; description "VLAN network id";
}
leaf gre-proto {
type uint16;
description "L2-NVGRE protocol value";
} }
leaf virtual-subnet-id { description " choices for
type uint32; L2-VLAN header matches.
description "L2-NVGRE subnet id value"; Outer-header only.
} Need to fix inner header. ";
leaf flow-id { }
type uint16; description
description "L2-NVGRE Flow id value"; "This VXLAN header may
} be replaced by actual VXLAN yang
// uses L2-802-1Q-header;
description
"This NVGRE header may
be replaced by actual NVGRE yang
module reference"; module reference";
} }
description "Grouping for
L2 NVGRE header.";
}
grouping L2-header-match { grouping L2-NVGRE-header {
choice l2-header-match-type { container nvgre-header {
case l2-802-1Q { uses L2-802-1Q-header;
uses L2-802-1Q-header; uses iir:ipv4-header;
} leaf gre-version {
case l2-802-11 { type uint8;
// matches for 802.11 headers description "L2-NVGRE GRE version";
} }
case l2-802-15 { leaf gre-proto {
// matches for 802.1 Ethernet type uint16;
} description "L2-NVGRE protocol value";
case l2-NVGRE { }
// matches for NVGRE leaf virtual-subnet-id {
uses L2-NVGRE-header; type uint32;
} description "L2-NVGRE subnet id value";
case l2-VXLAN-header {
uses L2-VXLAN-header;
}
case l2-mpls-header {
uses i2rs-rib:mpls-header;
}
description "Choice of L2
headers for L2 match";
} }
description leaf flow-id {
" The layer 2 header match includes type uint16;
any reference to L2 technology"; description "L2-NVGRE Flow id value";
} }
// uses L2-802-1Q-header;
description
"This NVGRE header may
be replaced by actual NVGRE yang
module reference";
}
description "Grouping for
L2 NVGRE header.";
}
grouping L2-NVGRE-mod-acts { grouping L2-header-match {
// actions for NVGRE
leaf set-vsid {
type boolean;
description
"Boolean flag to set VSID in packet";
}
leaf set-flowid {
type boolean;
description
"Boolean flag to set VSID in packet";
}
leaf vsi {
type uint32;
description
"VSID value to set in packet";
}
leaf flow-id {
type uint16;
description
"flow-id value to set in packet";
}
description "L2-NVRE Actions";
}
grouping L2-VXLAN-mod-acts { choice l2-header-match-type {
leaf set-network-id { case l2-802-1Q {
type boolean; uses L2-802-1Q-header;
description }
"flag to set network id in packet"; case l2-802-11 {
} // matches for 802.11 headers
leaf network-id { }
type uint32; case l2-802-15 {
description // matches for 802.1 Ethernet
"network id value to set in packet"; }
} case l2-NVGRE {
description "VXLAN header // matches for NVGRE
modification actions."; uses L2-NVGRE-header;
} }
case l2-VXLAN-header {
uses L2-VXLAN-header;
}
case l2-mpls-header {
uses iir:mpls-header;
}
description "Choice of L2
headers for L2 match";
}
description
" The layer 2 header match includes
any reference to L2 technology";
}
grouping L2-mpls-mod-acts { grouping L2-NVGRE-mod-acts {
leaf pop { // actions for NVGRE
leaf set-vsid {
type boolean; type boolean;
description
"Boolean flag to pop mpls header";
}
leaf push {
type boolean;
description
"Boolean flag to push value into
mpls header";
}
leaf mpls-label {
type uint32;
description description
"mpls label to push in header"; "Boolean flag to set VSID in packet";
}
description "MPLS modify
header actions";
}
grouping l2-header-mod-actions {
leaf l2-802-1Q {
type uint8;
description "actions for 802.1Q";
}
leaf l2-802-11 {
type uint8;
description "actions for 802.11";
}
leaf l2-802-15 {
type uint8;
description "ations for 802.15";
}
uses L2-NVGRE-mod-acts;
uses L2-VXLAN-mod-acts;
uses L2-mpls-mod-acts;
description
" The layer 2 header match includes
any reference to L2 technology";
}
grouping L3-header-match {
choice L3-header-match-type {
case l3-ipv4-hdr {
uses i2rs-rib:ipv4-header;
} }
case l3-ipv6-hdr { leaf set-flowid {
uses i2rs-rib:ipv6-header; type boolean;
description
"Boolean flag to set VSID in packet";
} }
case L3-gre-tunnel { leaf vsi {
uses i2rs-rib:gre-header; type uint32;
description
"VSID value to set in packet";
} }
description "match for L3 leaf flow-id {
headers for IPv4, IPv6, type uint16;
and GRE tunnels"; description
} "flow-id value to set in packet";
description "match for L3 headers"; }
} description "L2-NVRE Actions";
}
grouping ipv4-encapsulate-gre {
leaf encapsulate {
type boolean;
description "flag to encapsulate headers";
}
leaf ipv4-dest-address {
type inet:ipv4-address;
description "Destination Address for GRE header";
}
leaf ipv4-source-address {
type inet:ipv4-address;
description "Source Address for GRE header";
}
description "encapsulation actions for IPv4 headers";
}
grouping L3-header-actions { grouping L2-VXLAN-mod-acts {
choice l3-header-act-type { leaf set-network-id {
case l3-ipv4-hdr { type boolean;
leaf set-ttl { description
type boolean; "flag to set network id in packet";
description "flag to set TTL"; }
} leaf network-id {
leaf set-dscp { type uint32;
type boolean; description
description "flag to set DSCP"; "network id value to set in packet";
} }
leaf ttl-value { description "VXLAN header
type uint8; modification actions.";
description "TTL value to set";
}
leaf dscp-val {
type uint8;
description "dscp value to set";
}
} }
case l3-ipv6-hdr {
leaf set-next-header {
type boolean;
description
"flag to set next routing
header in IPv6 header";
}
leaf set-traffic-class {
type boolean;
description
"flag to set traffic class
in IPv6 header";
} grouping L2-mpls-mod-acts {
leaf set-flow-label { leaf pop {
type boolean; type boolean;
description description
"flag to set flow label "Boolean flag to pop mpls header";
in IPv6 header"; }
} leaf push {
leaf set-hop-limit { type boolean;
type boolean; description
description "flag "Boolean flag to push value into
to set hop limit in mpls header";
L3 packet"; }
} leaf mpls-label {
leaf ipv6-next-header { type uint32;
type uint8; description
description "value to "mpls label to push in header";
set in next IPv6 header"; }
} description "MPLS modify
leaf ipv6-traffic-class { header actions";
type uint8; }
description "value to set
in traffic class";
} grouping l2-header-mod-actions {
leaf ipv6-flow-label { leaf l2-802-1Q {
type uint16; type uint8;
description "value to set description "actions for 802.1Q";
in IPOv6 flow label";
}
leaf ipv6-hop-limit {
type uint8;
description "value to set
in hop count";
} }
} leaf l2-802-11 {
type uint8;
case L3-gre-tunnel { description "actions for 802.11";
leaf decapsulate { }
type boolean; leaf l2-802-15 {
description "flag to type uint8;
decapsulate GRE packet"; description "ations for 802.15";
} }
description "GRE tunnel
actions" ;
}
description "actions that can
be performed on L3 header";
}
description "actions to
be performed on L3 header";
}
grouping tcp-header-match { uses L2-NVGRE-mod-acts;
leaf tcp-src-port { uses L2-VXLAN-mod-acts;
type uint16; uses L2-mpls-mod-acts;
description "source port match value"; description
} " The layer 2 header match includes
leaf tcp-dst-port { any reference to L2 technology";
type uint16; }
description "dest port value
to match";
}
leaf sequence-number {
type uint32;
description "sequence number
value to match";
}
leaf ack-number {
type uint32;
description "action value to
match";
}
description "match for TCP
header";
}
grouping tcp-header-action { grouping L3-header-match {
leaf set-tcp-src-port {
type boolean;
description "flag to set
source port value";
}
leaf set-tcp-dst-port {
type boolean;
description "flag to set source port value";
}
leaf tcp-s-port { choice L3-header-match-type {
type uint16; case l3-ipv4-hdr {
description "source port match value"; uses iir:ipv4-header;
} }
leaf tcp-d-port { case l3-ipv6-hdr {
type uint16; uses iir:ipv6-header;
description "dest port value }
to match"; case L3-gre-tunnel {
uses iir:gre-header;
}
description "match for L3
headers for IPv4, IPv6,
and GRE tunnels";
}
description "match for L3 headers";
}
grouping ipv4-encapsulate-gre {
leaf encapsulate {
type boolean;
description "flag to encapsulate headers";
}
leaf ipv4-dest-address {
type inet:ipv4-address;
description
"Destination Address for GRE header";
}
leaf ipv4-source-address {
type inet:ipv4-address;
description
"Source Address for GRE header";
}
description
"encapsulation actions for IPv4 headers";
} }
leaf seq-num {
type uint32;
description "sequence number
value to match";
}
leaf ack-num {
type uint32;
description "action value to
match";
}
description "Actions to
modify TCP header";
}
grouping udp-header-match { grouping L3-header-actions {
leaf udp-src-port { choice l3-header-act-type {
type uint16; case l3-ipv4-hdr {
description "UDP source leaf set-ttl {
port match value"; type boolean;
} description "flag to set TTL";
leaf udp-dst-port { }
type uint16; leaf set-dscp {
description "UDP Destination type boolean;
port match value"; description "flag to set DSCP";
} }
description "match values for leaf ttl-value {
UDP header"; type uint8;
description "TTL value to set";
}
leaf dscp-val {
type uint8;
description "dscp value to set";
}
}
case l3-ipv6-hdr {
leaf set-next-header {
type boolean;
description
"flag to set next routing
header in IPv6 header";
}
leaf set-traffic-class {
type boolean;
description
"flag to set traffic class
in IPv6 header";
} }
leaf set-flow-label {
type boolean;
description
"flag to set flow label
in IPv6 header";
}
leaf set-hop-limit {
type boolean;
description "flag
to set hop limit in
L3 packet";
}
leaf ipv6-next-header {
type uint8;
description "value to
set in next IPv6 header";
}
leaf ipv6-traffic-class {
type uint8;
description "value to set
in traffic class";
grouping udp-header-action { }
leaf set-udp-src-port { leaf ipv6-flow-label {
type boolean; type uint16;
description "flag to set description "value to set
UDP source port match value"; in IPOv6 flow label";
} }
leaf set-udp-dst-port { leaf ipv6-hop-limit {
type boolean; type uint8;
description description "value to set
"flag to set UDP destination port match value"; in hop count";
} }
leaf udp-s-port { }
type uint16;
description "UDP source
port match value";
}
leaf udp-d-port {
type uint16;
description "UDP Destination
port match value";
}
description "actions to set case L3-gre-tunnel {
values in UDP header"; leaf decapsulate {
} type boolean;
description "flag to
decapsulate GRE packet";
}
description "GRE tunnel
actions" ;
}
description "actions that can
be performed on L3 header";
}
description "actions to
be performed on L3 header";
}
grouping sctp-chunk { grouping tcp-header-match {
leaf chunk-type { leaf tcp-src-port {
type uint8; type uint16;
description "sctp chunk type value"; description "source port match value";
} }
leaf chunk-flag { leaf tcp-dst-port {
type uint8; type uint16;
description "sctp chunk type description "dest port value
flag value"; to match";
} }
leaf sequence-number {
type uint32;
description "sequence number
value to match";
leaf chunk-length { }
type uint16; leaf ack-number {
description "sctp chunk length"; type uint32;
} description "action value to
match";
}
description "match for TCP
header";
}
leaf chunk-data-byte-zero { grouping tcp-header-action {
type uint32; leaf set-tcp-src-port {
description "byte zero of type boolean;
stcp chunk data"; description "flag to set
source port value";
}
leaf set-tcp-dst-port {
type boolean;
description "flag to set source port value";
}
leaf tcp-s-port {
type uint16;
description "source port match value";
}
leaf tcp-d-port {
type uint16;
description "dest port value
to match";
}
leaf seq-num {
type uint32;
description "sequence number
value to match";
}
leaf ack-num {
type uint32;
description "action value to
match";
}
description "Actions to
modify TCP header";
} }
description "sctp chunck
header match fields";
}
grouping sctp-header-match { grouping udp-header-match {
uses sctp-chunk; leaf udp-src-port {
leaf stcp-src-port { type uint16;
type uint16; description "UDP source
description "sctp header match port match value";
source port value"; }
} leaf udp-dst-port {
leaf sctp-dst-port { type uint16;
type uint16; description "UDP Destination
description "sctp header match port match value";
destination port value"; }
} description "match values for
leaf sctp-verify-tag { UDP header";
type uint32;
description "sctp header match }
verification tag value";
}
description "SCTP header
match values";
}
grouping sctp-header-action { grouping udp-header-action {
leaf set-stcp-src-port { leaf set-udp-src-port {
type boolean; type boolean;
description "set source port in sctp header"; description "flag to set
} UDP source port match value";
leaf set-stcp-dst-port { }
type boolean; leaf set-udp-dst-port {
description "set destination port in sctp header"; type boolean;
} description
leaf set-stcp-chunk1 { "flag to set UDP destination port match value";
type boolean; }
description "set chunk value in sctp header"; leaf udp-s-port {
} type uint16;
leaf chunk-type-value { description "UDP source
type uint8; port match value";
description "sctp chunk type value"; }
} leaf udp-d-port {
leaf chunk-flag-value { type uint16;
type uint8; description "UDP Destination
description "sctp chunk type port match value";
flag value"; }
}
leaf chunk-len { description "actions to set
type uint16; values in UDP header";
description "sctp chunk length"; }
}
leaf chunk-data-bzero { grouping sctp-chunk {
type uint32; leaf chunk-type {
description "byte zero of type uint8;
stcp chunk data"; description "sctp chunk type value";
}
leaf chunk-flag {
type uint8;
description "sctp chunk type
flag value";
}
leaf chunk-length {
type uint16;
description "sctp chunk length";
}
leaf chunk-data-byte-zero {
type uint32;
description "byte zero of
stcp chunk data";
}
description "sctp chunck
header match fields";
} }
description "sctp qos actions";
}
grouping L4-header-match { grouping sctp-header-match {
choice l4-header-match-type { uses sctp-chunk;
case l4-tcp-header { leaf stcp-src-port {
uses tcp-header-match; type uint16;
description "sctp header match
source port value";
}
leaf sctp-dst-port {
type uint16;
description "sctp header match
destination port value";
}
leaf sctp-verify-tag {
type uint32;
description "sctp header match
verification tag value";
}
description "SCTP header
match values";
}
grouping sctp-header-action {
leaf set-stcp-src-port {
type boolean;
description "set source port in sctp header";
} }
case l4-udp-header { leaf set-stcp-dst-port {
uses udp-header-match; type boolean;
description "set destination port in sctp header";
} }
case l4-sctp { leaf set-stcp-chunk1 {
uses sctp-header-match; type boolean;
description "set chunk value in sctp header";
} }
description "L4 match leaf chunk-type-value {
header choices"; type uint8;
} description "sctp chunk type value";
description "L4 header }
match type"; leaf chunk-flag-value {
} type uint8;
description "sctp chunk type
flag value";
}
grouping L4-header-actions { leaf chunk-len {
uses tcp-header-action; type uint16;
uses udp-header-action; description "sctp chunk length";
uses sctp-header-action; }
description "L4 header matches";
}
grouping service-header-match { leaf chunk-data-bzero {
choice service-header-match-type { type uint32;
case sf-chain-meta-match { description "byte zero of
description "uses stcp chunk data";
sfc-sfc:service-function-chain-grouping: }
+ sfc-sfc:service-function-chain"; description "sctp qos actions";
} }
case sf-path-meta-match {
description "uses
sfc-spf:service-function-paths:
+ sfc-spf:service-function-path";
}
description "SFC header match
choices";
}
description "SFC header and path
matches";
}
grouping sfc-header-actions { grouping L4-header-match {
choice service-header-match-type { choice l4-header-match-type {
case sf-chain-meta-match { case l4-tcp-header {
leaf set-chain { uses tcp-header-match;
type boolean; }
description "flag to set case l4-udp-header {
chain in sfc. Should uses udp-header-match;
be amended to use SFC service }
chain matching. case l4-sctp {
uses sfc-sfc:service-function-chain-grouping: uses sctp-header-match;
+ sfc-sfc:service-function-chain"; }
} description "L4 match
} header choices";
case sf-path-meta-match {
leaf set-path {
type boolean;
description "flag to set path in
sfc header. Amend to use sfc-spf
function headers. Uses
sfc-spf:service-function-paths:
+ sfc-spf:service-function-path.";
} }
} description "L4 header
description "choices in SFC for match type";
chain match and path match."; }
}
description "modify action for
SFC header.";
}
grouping rule_status { grouping L4-header-actions {
leaf rule-status { uses tcp-header-action;
type string; uses udp-header-action;
description "status information uses sctp-header-action;
free form string."; description "L4 header matches";
}
leaf rule-inactive-reason {
type string;
description "description of
why rule is inactive";
}
leaf rule-install-reason {
type string;
description "response on rule installed";
}
leaf rule-installer {
type string;
description "client id of installer";
}
leaf refcnt {
type uint16;
description "reference count on rule. ";
}
description
"rule operational status";
}
// group status }
grouping groups-status {
list group_opstate { grouping rule_status {
key "grp-name"; leaf rule-status {
leaf grp-name { type string;
type string; description "status information
description "eca group name"; free form string.";
}
leaf rule-inactive-reason {
type string;
description "description of
why rule is inactive";
}
leaf rule-install-reason {
type string;
description "response on rule installed";
}
leaf rule-installer {
type string;
description "client id of installer";
}
leaf refcnt {
type uint16;
description "reference count on rule. ";
}
description
"rule operational status";
} }
leaf rules-installed {
type uint32; // group status
description "rules in grouping groups-status {
group installed"; list group_opstate {
key "grp-name";
leaf grp-name {
type string;
description "eca group name";
}
leaf rules-installed {
type uint32;
description "rules in
group installed";
}
list rules_status {
key "rule-name";
leaf rule-name {
type string;
description "name of rule ";
}
leaf rule-order {
type uint32;
description "rule-order";
}
description "rules per
group";
}
description "group operational
status";
}
description "group to rules
list";
} }
list rules_status {
key "rule-name"; // links between rule to group
leaf rule-name {
grouping rule-group-link {
list rule-group {
key rule-name;
leaf rule-name {
type string;
description "rule name";
}
leaf group-name {
type string; type string;
description "name of rule "; description "group name";
} }
leaf rule-order { description "link between
type uint32; group and link";
description "rule-order"; }
} description "rule-name to
description "rules per group link";
group";
} }
description "group operational
status";
}
description "group to rules
list";
}
// links between rule to group // rule status by name
grouping rules_opstate {
list rules_status {
key "rule-order rule-name";
leaf rule-order {
type uint32;
description "order of rules";
}
leaf rule-name {
type string;
description "rule name";
}
uses rule_status;
description "eca rule list";
grouping rule-group-link { }
list rule-group { description "rules
key rule-name; operational state";
leaf rule-name {
type string;
description "rule name";
} }
leaf group-name {
type string;
description "group name";
} // rule statistics by name and order
description "link between grouping rules_opstats {
group and link"; list rule-stat {
} key "rule-order rule-name";
description "rule-name to leaf rule-order {
group link"; type uint32;
} description "order of rules";
}
leaf rule-name {
type string;
description "name of rule";
}
leaf pkts-matched {
type uint64;
description "number of
packets that matched filter";
}
leaf pkts-modified {
type uint64;
description "number of
packets that filter caused
to be modified";
}
leaf pkts-dropped {
type uint64;
description "number of
packets that filter caused
to be modified";
}
leaf bytes-dropped {
type uint64;
description "number of
packets that filter caused
to be modified";
}
leaf pkts-forwarded {
type uint64;
description "number of
packets that filter caused
to be forwarded.";
}
leaf bytes-forwarded {
type uint64;
description "number of
packets that filter caused
to be forwarded.";
}
// rule status by name description "list of
grouping rules_opstate { operational statistics for each
list rules_status { rule.";
key "rule-order rule-name"; }
leaf rule-order { description "statistics
type uint32; on packet filter matches, and
description "order of rules"; based on matches on many were
} modified and/or forwarded";
leaf rule-name { }
type string;
description "rule name";
}
uses rule_status;
description "eca rule list";
}
description "rules
operational state";
}
// rule statistics by name and order grouping packet-size-match {
grouping rules_opstats { leaf l2-size-match {
list rule-stat { type uint32;
key "rule-order rule-name"; description "L2 packet match size.";
leaf rule-order {
type uint32;
description "order of rules";
}
leaf rule-name {
type string;
description "name of rule";
}
leaf pkts-matched {
type uint64;
description "number of
packets that matched filter";
}
leaf pkts-modified {
type uint64;
description "number of
packets that filter caused
to be modified";
} }
leaf pkts-dropped { leaf l3-size-match {
type uint64; type uint32;
description "number of description "L3 packet match size.";
packets that filter caused
to be modified";
} }
leaf bytes-dropped { leaf l4-size-match {
type uint64; type uint32;
description "number of description "L4 packet match size.";
packets that filter caused
to be modified";
} }
leaf pkts-forwarded {
type uint64;
description "number of
packets that filter caused
to be forwarded.";
}
leaf bytes-forwarded {
type uint64;
description "number of
packets that filter caused
to be forwarded.";
}
description "list of description "packet size by layer
operational statistics for each only non-zero values are matched";
rule.";
}
description "statistics
on packet filter matches, and
based on matches on many were
modified and/or forwarded";
}
grouping packet-size-match {
leaf l1-size-match {
type uint32;
description "L1 packet match size.";
}
leaf l2-size-match {
type uint32;
description "L2 packet match size.";
}
leaf l3-size-match {
type uint32;
description "L3 packet match size.";
}
leaf l4-size-match {
type uint32;
description "L4 packet match size.";
}
leaf service-meta-size {
type uint32;
description "service meta info match size.";
}
leaf service-meta-payload {
type uint32;
description "service meta-play match size";
} }
description "packet size by layer
only non-zero values are matched";
}
grouping time-day-match {
leaf hour { grouping time-day-match {
type uint8;
description "hour
of day in 24 hours.
(add range)";
}
leaf minute {
type uint8;
description
"minute in day.";
}
leaf second {
type uint8;
description
"second in day.";
}
description "matches for leaf hour {
time of day."; type uint8;
description "hour
of day in 24 hours.
(add range)";
}
leaf minute {
type uint8;
description
"minute in day.";
}
leaf second {
type uint8;
description
"second in day.";
}
} description "matches for
time of day.";
grouping user-event-match {
leaf user-name {
type string;
description "name of user
event";
}
leaf match-string {
type string;
description "user match
string";
} }
description "matches for grouping eca-event-matches {
time of day."; uses time-day-match;
description "matches for events
which include:
time of day.";
} }
grouping eca-event-matches { grouping eca-pkt-matches {
uses time-day-match; uses interface-match;
uses user-event-match; uses L2-header-match;
description "matches for events uses L3-header-match;
which include: uses L4-header-match;
time of day, and uses packet-size-match;
user specified matches."; description "ECA matches";
}
} grouping user-status-matches {
leaf user {
type string;
description "user";
}
leaf region {
type string;
description "region";
}
leaf state {
type string;
description "state";
}
grouping eca-pkt-matches { leaf user-status {
uses interface-match; type string;
uses L1-header-match; description "status of user";
uses L2-header-match; }
uses L3-header-match; description "user status
uses L4-header-match; matches - region,
uses service-header-match; target, location";
uses packet-size-match; }
description "ECA matches";
}
grouping user-status-matches { grouping eca-condition-matches {
leaf user { uses eca-pkt-matches;
type string; uses user-status-matches;
description "user"; description "pkt
} and user status matches";
leaf region {
type string;
description "region";
} }
leaf state {
type string;
description "state";
} grouping eca-qos-actions {
leaf cnt-actions {
type uint32;
description "count of ECA actions";
}
list qos-actions {
key "action-id";
leaf action-id {
type uint32;
description "action id";
}
uses interface-actions;
uses l2-header-mod-actions;
uses L3-header-actions;
uses L4-header-actions;
leaf user-status { description "ECA set or change
type string; packet Actions. Actions may be
description "status of user"; added here for interface,
} L2, L3, and L4
headers.";
}
description "eca- qos actions";
}
description "user status grouping ip-next-fwd {
matches - region, leaf rib-name {
target, location"; type string;
} description "name of RIB";
}
leaf next-hop-name {
type string;
description "name of next hop";
}
description "ECA set or change
packet Actions";
grouping eca-condition-matches { }
uses eca-pkt-matches;
uses user-status-matches;
description "pkt
and user status matches";
}
grouping eca-qos-actions { grouping eca-ingress-actions {
leaf cnt-actions { leaf permit {
type uint32; type boolean;
description "count of ECA actions"; description "permit ingress
} traffic. False
list qos-actions { means to deny.";
key "action-id";
leaf action-id {
type uint32;
description "action id";
} }
uses interface-actions; leaf mirror {
uses L1-header-actions; type boolean;
uses l2-header-mod-actions; description "copy bytes
uses L3-header-actions; ingressed to mirror port";
uses L4-header-actions; }
description "ingress eca match";
description "ECA set or change
packet Actions. Actions may be
added here for interface,
L1, L2, L3, L4 nad service forwarding
headers.";
} }
description "eca- qos actions";
}
grouping ip-next-fwd {
leaf rib-name {
type string;
description "name of RIB";
}
leaf next-hop-name {
type string;
description "name of next hop";
}
description "ECA set or change
packet Actions";
}
grouping eca-ingress-actions { grouping eca-fwd-actions {
leaf permit { leaf interface-fwd {
type boolean; type if:interface-ref;
description "permit ingress description "name of interface to forward on";
traffic. False }
means to deny."; uses iir:nexthop;
} uses ip-next-fwd;
leaf mirror { leaf drop-packet {
type boolean; type boolean;
description "copy bytes description "drop packet flag";
ingressed to mirror port"; }
} description "ECA forwarding actions";
description "ingress eca match"; }
}
grouping eca-fwd-actions { grouping eca-security-actions {
leaf interface-fwd { leaf actions-exist {
type if:interface-ref;
description "name of interface to forward on";
}
uses i2rs-rib:nexthop;
uses ip-next-fwd;
leaf drop-packet {
type boolean; type boolean;
description "drop packet flag"; description "existance of
} eca security actions";
description "ECA forwarding actions";
} }
description "content actions
grouping eca-security-actions { for security. Needs more
leaf actions-exist { description.";
type boolean;
description "existance of
eca security actions";
} }
description "content actions
for security. Needs more
description.";
}
grouping eca-egress-actions { grouping eca-egress-actions {
leaf packet-rate { leaf packet-rate {
type uint32;
description "maximum packet-rate";
}
leaf byte-rate {
type uint64;
description "maximum byte-rate ";
}
description "packet security actions";
}
grouping policy-conflict-resolution {
list resolution-strategy {
key "strategy-id";
leaf strategy-id {
type uint32; type uint32;
description "Id for strategy"; description "maximum packet-rate";
} }
leaf stategy-name { leaf byte-rate {
type string; type uint64;
description "name of strategy"; description "maximum byte-rate ";
} }
leaf filter-strategy { description "packet security actions";
type string; }
description "type of resolution";
} grouping policy-conflict-resolution {
leaf global-strategy { list resolution-strategy {
type boolean; key "strategy-id";
description "global strategy"; leaf strategy-id {
} type uint32;
leaf mandatory-strategy { description "Id for strategy";
type boolean; }
description "required strategy"; leaf stategy-name {
} type string;
leaf local-strategy { description "name of strategy";
type boolean; }
description "local strategy"; leaf filter-strategy {
} type string;
leaf resolution-fcn { description "type of resolution";
type uint64;
description "resolution function id ";
}
leaf resolution-value {
type uint64;
description "resolution value";
}
leaf resolution-info {
type string;
description "resolution info";
}
list associate-ext-data {
key "ext-data-id";
leaf ext-data-id {
type uint64;
description "ID of external data";
}
leaf ext-data {
type string;
description "external data";
}
description "linked external data";
}
description "list of strategies";
}
description "policy conflict
resolution strategies";
}
grouping cfg-external-data { }
list cfg-ext-data { leaf global-strategy {
key "cfg-ext-data-id"; type boolean;
leaf cfg-ext-data-id { description "global strategy";
type uint64;
description "id for external data";
}
leaf data-type {
type uint32;
description "external data type ID";
} }
leaf priority { leaf mandatory-strategy {
type boolean;
description "required strategy";
}
leaf local-strategy {
type boolean;
description "local strategy";
}
leaf resolution-fcn {
type uint64; type uint64;
description "priority of data"; description "resolution function id ";
} }
leaf other-data { leaf resolution-value {
type string; type uint64;
description "string description "resolution value";
external data"; }
leaf resolution-info {
type string;
description "resolution info";
}
list associate-ext-data {
key "ext-data-id";
leaf ext-data-id {
type uint64;
description "ID of external data";
}
leaf ext-data {
type string;
description "external data";
}
description "linked external data";
}
description "list of strategies";
} }
description "external data"; description "policy conflict
} resolution strategies";
description "external data list"; }
}
grouping pkt-eca-policy-set { grouping cfg-external-data {
list groups { list cfg-ext-data {
key "group-name"; key "cfg-ext-data-id";
leaf group-name { leaf cfg-ext-data-id {
type string; type uint64;
description description "id for external data";
"name of group of rules"; }
} leaf data-type {
leaf vrf-name { type uint32;
type string; description "external data type ID";
description "VRF name";
}
uses rt:address-family;
list group-rule-list {
key "rule-name";
leaf rule-name {
type string;
description "name of rule";
}
leaf rule-order-id {
type uint16;
description "rule-order-id";
}
description "rules per group";
}
description "pkt eca rule groups";
}
list eca-rules {
key "order-id";
ordered-by user;
leaf order-id {
type uint16;
description "Number of order
in ordered list (ascending)";
} }
leaf eca-rule-name { leaf priority {
type string; type uint64;
description "name of rule"; description "priority of data";
} }
leaf installer { leaf other-data {
type string; type string;
description description "string
"Id of I2RS client external data";
that installs this rule."; }
description "external data";
}
description "external data list";
}
} grouping pkt-eca-policy-set {
uses eca-event-matches; list groups {
uses eca-ingress-actions; key "group-name";
uses eca-qos-actions; leaf group-name {
uses eca-security-actions; type string;
uses eca-fwd-actions; description
uses eca-egress-actions; "name of group of rules";
uses cfg-external-data; }
uses policy-conflict-resolution; leaf vrf-name {
type string;
description "VRF name";
}
uses rt:address-family;
list group-rule-list {
key "rule-name";
leaf rule-name {
type string;
description "name of rule";
}
leaf rule-order-id {
type uint16;
description "rule-order-id";
}
description "rules per group";
}
description "pkt eca rule groups";
}
list eca-rules {
key "order-id";
ordered-by user;
leaf order-id {
type uint16;
description "Number of order
in ordered list (ascending)";
}
leaf eca-rule-name {
type string;
description "name of rule";
}
leaf installer {
type string;
description
"Id of I2RS client
that installs this rule.";
}
uses eca-event-matches;
uses eca-ingress-actions;
uses eca-qos-actions;
uses eca-security-actions;
uses eca-fwd-actions;
uses eca-egress-actions;
uses cfg-external-data;
uses policy-conflict-resolution;
description "ECA rules"; description "ECA rules";
} // end of rule } // end of rule
description "Policy sets."; description "Policy sets.";
} }
grouping pkt-eca-opstate { grouping pkt-eca-opstate {
uses groups-status; uses groups-status;
uses rule-group-link; uses rule-group-link;
uses rules_opstate; uses rules_opstate;
uses rules_opstats; uses rules_opstats;
description "pkt eca policy description "pkt eca policy
op-state main"; op-state main";
} }
container pkt-eca-policy-opstate { container pkt-eca-policy-opstate {
config "false"; config "false";
uses pkt-eca-opstate; uses pkt-eca-opstate;
description "operational state"; description "operational state";
} }
} }
<CODE ENDS> <CODE ENDS>
6. IANA Considerations 6. IANA Considerations
This draft requests IANA Assign a urn in the IETF yang module space This draft requests IANA Assign a urn in the IETF yang module space
for: for:
"urn:ietf:params:xml:ns:yang:ietf-pkt-eca-policy"; "urn:ietf:params:xml:ns:yang:ietf-pkt-eca-policy";
associated prefix "pkt-eca"; associated prefix "pkt-eca";
7. Security Considerations 7. Security Considerations
These generic filters are used in the I2RS FB-RIBs to filter packets These generic filters are filter packets in a traffic stream, act to
in a traffic stream, act to modify packets, and forward data packets. modify packets, and forward data packets. These filters operate
These I2RS filters operate dynamically at same level as currently dynamically at same level as currently deployed configured filter-
deployed configured filter-based RIBs to filter, change, and forward based RIBs to filter, change, and forward traffic.
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 Due to the potential to use Filters as an attack vector, this data
experts. model should be used with the secure transport described in the
[I-D.ietf-i2rs-protocol-security-requirements]
8. Informative References 8. References
8.1. Normative References
[I-D.ietf-i2rs-rib-data-model]
Wang, L., Ananthakrishnan, H., Chen, M.,
amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A
YANG Data Model for Routing Information Base (RIB)",
draft-ietf-i2rs-rib-data-model-07 (work in progress),
January 2017.
8.2. Informative References
[I-D.ietf-i2rs-protocol-security-requirements]
Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", draft-ietf-i2rs-protocol-security-
requirements-17 (work in progress), September 2016.
[I-D.ietf-i2rs-rib-info-model] [I-D.ietf-i2rs-rib-info-model]
Bahadur, N., Kini, S., and J. Medved, "Routing Information Bahadur, N., Kini, S., and J. Medved, "Routing Information
Base Info Model", draft-ietf-i2rs-rib-info-model-09 (work Base Info Model", draft-ietf-i2rs-rib-info-model-10 (work
in progress), July 2016. in progress), December 2016.
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-17 (work in
progress), September 2016.
[I-D.ietf-netmod-acl-model] [I-D.ietf-netmod-acl-model]
Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,
"Network Access Control List (ACL) YANG Data Model", "Network Access Control List (ACL) YANG Data Model",
draft-ietf-netmod-acl-model-08 (work in progress), July draft-ietf-netmod-acl-model-10 (work in progress), March
2016. 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.ietf-netmod-revised-datastores]
Requirement Levels", BCP 14, RFC 2119, Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
DOI 10.17487/RFC2119, March 1997, and R. Wilton, "A Revised Conceptual Model for YANG
<http://www.rfc-editor.org/info/rfc2119>. Datastores", draft-ietf-netmod-revised-datastores-00 (work
in progress), December 2016.
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, [I-D.ietf-supa-generic-policy-data-model]
"Policy Core Information Model -- Version 1 Halpern, J. and J. Strassner, "Generic Policy Data Model
Specification", RFC 3060, DOI 10.17487/RFC3060, February for Simplified Use of Policy Abstractions (SUPA)", draft-
2001, <http://www.rfc-editor.org/info/rfc3060>. ietf-supa-generic-policy-data-model-02 (work in progress),
October 2016.
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) [I-D.ietf-supa-generic-policy-info-model]
Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003, Strassner, J., Halpern, J., and S. Meer, "Generic Policy
<http://www.rfc-editor.org/info/rfc3460>. Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
model-02 (work in progress), January 2017.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
Moore, "Policy Quality of Service (QoS) Information and A. Bierman, Ed., "Network Configuration Protocol
Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc3644>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", RFC 7921, DOI 10.17487/RFC7921, June 2016, System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
<http://www.rfc-editor.org/info/rfc7921>. <http://www.rfc-editor.org/info/rfc7921>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>.
Authors' Addresses Authors' Addresses
Susan Hares Susan Hares
Huawei Huawei
7453 Hickory Hill 7453 Hickory Hill
Saline, MI 48176 Saline, MI 48176
USA USA
Email: shares@ndzh.com Email: shares@ndzh.com
Qin Wu Linda Dunbar
Huawei Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com Email: Linda.Dunbar@huawei.com
Russ White Russ White
Ericsson Ericsson
Email: russw@riw.us Email: russw@riw.us
 End of changes. 218 change blocks. 
2017 lines changed or deleted 1364 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/