| I2RS working group | S. Kini |
| Internet-Draft | Ericsson |
| Intended status: Standards Track | S. Hares |
| Expires: September 10, 2015 | Huawei |
| A. Ghanwani | |
| Dell | |
| R. Krishnan | |
| Brocade | |
| Q. Wu | |
| Huawei | |
| D. Bogdanovic | |
| Juniper Networks | |
| J. Tantsura | |
| R. White | |
| Ericsson | |
| March 9, 2015 |
Filter-Based RIB Information Model
draft-kini-i2rs-fb-rib-info-model-00
This document defines an information model I2RS Filter based RIB (Routing information Model). Filter based forwarding matches fields in the IP header plus other higher layer packet information. These matches may be ordered. Matches may contain actions which could impact forward, such as setting a nexthop.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Interface to the Routing System (I2RS) [I-D.ietf-i2rs-architecture] architecture provides dynamic read and write access to the information and state within the routing elements. The I2RS client interacts with the I2RS agent in one or more network routing systems.
This document provides a generic information model for a I2RS filter based RIB (FB-RIB) and describes the I2RS interaction with routing filters within a routing element.
Filter based (FB) routing matches fields in the IP header plus other higher layer packet information. Filters with a match-action pair allow the filters to impact the forwarding of packets. Actions may impact forwarding or set something in the packet that will impact forwarding.
A Filter-Based RIB (Routing Information Base) contains a list of filters (match-action conditions) and a default RIB of the form found in [I-D.ietf-i2rs-rib-info-model]. The default RIB routes any packet not matched by the order list of filter rules. If any packet does not match filter, it is dropped.
Some drafts which provide models for match filters are the following:
This generic model for filters aligns with the generic model for topology in providing a simple model that can be utilize for other filters. The abstract filter model utilizes a generic filter based model that can be applied for specific filters at each level. The default RIB specification for the FB-RIB uses the I2RS RIB Model.
+------------------------+
| |
| Abstract Network Model |
| |
+------------------------+
|
+-------+-------+--
| |
V V
+---------------+ +------------+ +-----------+
| Abstract | | Abstract | | I2RS |
| Filter-Based | | Topology | | RIB |
| (FB)RIB Model | | Model | | Model |
+---------------+ +------------+ +-----------+
|
augments |
+-------------+-------------+-----------+
| | | |
V V V V
............ ............ ............ ...........
: L1 : : L2 : : L3 : : Service :
: FB-RIB : : FB-RIB : : FB-RIB : : FB-RIB :
: Model : : Model : : Model : : Model :
'''''''''''' '''''''''''' '''''''''''' '''''''''''
Figure 1: The network model structure
Filter based routing is a technique used to make packet routing decisions based on filter policies set by the network administrator. Routing decisions in a Filter-Based RIB (FB-RIB) are based on several criteria beyond destination address, such as application, IP protocol used, identity of the end system, and even packet size. Policy actions are typically applied before applying QoS constraints since policy actions may override QoS constraint.
The Filter-Based routing may provide many benefits, including better resource allocation, load balancing and QoS.
The I2RS use cases which benefit from Filter-Based Routing are: Protocol independent Use cases and large flow use cases described in [I-D.hares-i2rs-usecase-reqs-summary].
The Filter-based policies are specified in most routers/switches as an ordered set of rules. Each policy rule has a set of match conditions, and a set of actions which may include forwarding actions and QoS actions. This draft uses a generic description of filters rules described in [I-D.hares-i2rs-bnp-info-model], but other policy models could be used if they have the same characteristics.
(Note: Antecedents of this generic structure for filter/policy rules can be found in the IETF PCIM work ([RFC3060], [RFC3460], and [RFC3644]).)
A Filter-Based RIB (FB-RIB) information model can be considered in either a top-down view examining the filter policy which controls the RIBs or from a bottom-up view which considers the data plane. A top-down view considers how the I2RS client provides filters for what can be added to a FB-RIB. This draft takes a bottom-up approach and looks at just the routes being installed in the FB-RIB. The bottoms-up view considers how routes link to forwarding data planes that must be supported. In this view, the match filters must consider IP [both IPv4 and IPv6], but may also consider MPLS and encapsulated protocols such as TCP [RFC0793], UDP [RFC0768], STCP [RFC4960], ICMP [RFC0792]. This draft takes the bottoms-up viewpoint which looks at how the FB-RIB controls the data plane.
This provides a generic FB-FIB description in section 4, and provide FB-FIB extension to cover the L3 IP filter covering IPv4 [RFC0791] and IPV6 [RFC2460]) in section 5.
Generic filter rules are described in [I-D.hares-i2rs-bnp-info-model]. The filter rules are included as list of groups of rules which in turn contain rules. This grouping hierarchy allows the ordering of all rules, and a logical group of filter rules based on a logical group (E.g. customers).
Within a particular order (E.g. Order 2), priority will establish the filter sequence within the order. If two priorities match, it is assumed the ordering of the filters do not impact the level
Each Rule within the Rule list has a rule-action match condition which is based on type. Type can be the "generic filter match-actions" or match actions specific to another type of policy (e.g. ACL rule match-action). For the generic filter match-actions has match field (bnp-term-match), action field (bnp-action), and a forwarding field (bnp-generic forwarding) as figure 1 shows.
+-----------------+
| group of rules |
+-----------------+
|
+-----------------+
| list of rules |
+-----------------+
|
+-----------------+
| Rule |
+-------|---------+
|
+-------------------+
| Rule Match action |
+------|------------+
+----|---------------+
+-----|---------+ +-------|-----+
| Generic Rule | | ACL Rule |
| match-action | | match-action |
+-----------|--+ +--------------+
|
+-----------|----|-----------|------------------+
| | |
+--------V------+ +----V--------+ +-------V-----+
| bnp term-match| | bnp-action | | bnp-generic |
| Condition | | action | | forwarding |
| | | | | actions |
+--------|------+ +-------|-----+ +-------------+
| | (drop, forward)
| |
+-------|------|-|-------+ +-|-|-----|------|--------|-+
| | | | | | | |
V V V V V V V V
....... ....... ....... .......... ........ ..... ...... .........
:L1 : :L2 : :L3 : : Service: : L1 : :L2 : :L3 : :Service:
:match: :match: :match: : match : :action: :act.: :act.: :action :
''''''' ''''''' ''''''' '''''''''' '''''''' ''''' ''''' '''''''''
Figure 2
Group
Name: internal-nets
Scope: L3-FB-RIB, R/W
group-installer: v-netops
rule-list
rule-1;
name: v-netops-lan
order: 1
installer: v-netops
status
ro-status: active
ro-rule-inactive-reason null
ro-iule-installer: v-netops
priority 1
rule-match-act
case:BNP-GENERIC-MATCH-ACTION
Case:L3-Header
term-match DEST-Header 192.200.1.*/24
term-action:
n-acts: 0
term-forward: drop
rule-2
name:ICMP packets
order: 2
installer: v-netops
status:
ro-status: inactive
ro-rule-inactive-reason: admin-inactive
ro-installer-active-filter: (null)
priority 3
rule-match-act:
Case:BNP-GENERIC_MATCH-ACTION
Case:L3-Header
term-match: ICMP-Type
term-action:
n-acts: 0
term-forward: drop
Figure 3: Example structure
An example of this hierarchy is shown in figure 2:
A Filter-Based RIB (FB-RIB) is an entity that contains an ordered set of filters (match/action conditions) and a default RIB of the form found in [I-D.ietf-i2rs-rib-info-model]. An ordered set of filters implies that the insertion of a filter route into a FB-RIB MUST provide the ability to insert a filter route at any specific position and delete of a filter-based route at a specific position. The ability to change a filter route at a specific position combines these two functions (delete an existing filter route rule and add a new policy rule).
Each FB-RIB is contained within a routing instance, but one routing instance (named by an INSTANCE_NAME) can contain multiple FB-RIBs. Each routing instance is associated with a set of interfaces, a router-id, a FB default-RIB, and list of FB-RIBs. Only some of the interfaces associated with a routing instance may be associated with a FB-RIB. Each interface can be associated with at most one FB RIB.
Packets arriving on an interface associated with a FB-RIB will be forwarded based on filters in a FB-RIB or the FB-RIB Default RIB (if no matches occur). The processing within the FB-RIB process within the routing system is expected to do the following:
+-------------------------------+
| routing instance |
+--|--------|---------------+---+
| | |
| | |
+-----------+ +-------------+ +-----------+
|interface* | |FB_RIB *list | | FB-Default|
| list | | | |-RIB |
+-----------+ +--|----------+ +---|-------+
| RIB (RIB-info IM)
^
/|\
+-----------^-----------+
| FB RIB |
+-----------|-----------+
|
|
+-----------------------+
| FB FIB Ordered List |
| of filter rules |
+-----------|------------+
| uses bnp generic filter-policy
+-----------|------------+
| BNP-Rule-Group* |
+-----------|-----------+
|
+-----------|--------------+
| BNP-Rule* |
|(ordered list of rules of |
| the form match-action) |
+--------------------------+
Figure 4: Routing instance with FB-RIB
The FB-RIB entries associated with each FB-RIB in a routing instance are:
module: FB-RIB
+--FB-RIB-module
+--rw FB-RIB-instance-name
+--rw RB-RIB-router-id uint32
+--rw FB-RIB-interface*
| +--rw FB-RIB-interface interface-ref-id
+--rw FB-Default-RIB rib-ref
+--rw FB-RIB
+--rw FB-RIB-Name
+--rw FB-RIB-AFI
+--rw FB-RIB-intf*
+--rw FB-FIB-status-info
| +--rw fb-rib-update-ref uint64
+--rw FB-RIB-Ordered-Filters
uses bnp-policy for filters
augments /nt:bnp-generic-rules/rule-group/
Figure 4: FB RIB Yang Structure
The Top-level Yang structure for the FB-RIB is:
Each FB-RIB has the following:
+-----------------------+
| Filter Rule |
| |
+--|-----------------|--+
: : .......
: : : :
+--------V-------+ +-------V-------+ :
|Filter Condition| | Filter Action |<...
+----------------+ +-+----------+--+
/|\ /|\
"extends"| | "extends"
+---+ +--------+
| |
+-------^-------+ +-----^---------+
| QoS Action | |Forward Action |
+---------------+ +---------------+
: : : : : :
....: : :..... .....: : :.....
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V-----+
|Set | |QoS | |QoS | |Forward ||Next Hop||Next Hop|
|Operator| |Variable| |Value | |Operator||Variable||Value |
+--------+ +--------+ +------+ +--------++--+-----++--------+
/|\
| "extends"
+---^----+
|Next Hop|
|Type |
+--------+
Figure 5: Filter Actions for FB-RIB
This section provides a short description of the generic filter policy rule's condition-action from [I-D.hares-i2rs-bnp-info-model] which is used by the FB-RIB.
The policy/filter rule contains the following:
The I2RS client-agent pair process within a routing process to add ephemeral these changes to the filter State so that
FB-RIB-rules(running) = FB-RIB-config + FB-Rules-I2RS-ephemeral
The I2RS ephemeral state will not survive a reboot of the machine. Upon a reboot, the I2RS client must reload the I2RS Agent with the I2RS FB-RIB state lost in the reboot.
Writing I2RS FB-rules to permanent configuration may be desirable. This has not been considered in this verison of this draft.
The RIB in a router with I2RS is the following:
running RIB = configured-RIB + routes-installed-from-protocols + I2RS-ephemeral-state
As described in [I-D.ietf-i2rs-rib-info-model], the I2RS ephemeral RIB information in routing instance contains a collection of RIBs, interfaces, and routing parameters including the following:
FB-RIB and RIB can not be used at the same time, which means:
Layer 3 match might contain the following:
Layer 3 Actions might set values in:
Layer 3 Forwarding can augment the basic to forward via tunnels.
This section record the issues with the initials of the person who recorded it.
This draft includes no request to IANA.
TBD.
| [I-D.hares-i2rs-bnp-info-model] | Hares, S. and Q. Wu, "An Information Model for Basic Network Policy", Internet-Draft draft-hares-i2rs-bnp-info-model-00, September 2014. |
| [I-D.ietf-i2rs-architecture] | Atlas, A., Halpern, J., Hares, S., Ward, D. and T. Nadeau, "An Architecture for the Interface to the Routing System", Internet-Draft draft-ietf-i2rs-architecture-00, August 2013. |
| [I-D.ietf-i2rs-rib-info-model] | Bahadur, N., Folkes, R., Kini, S. and J. Medved, "Routing Information Base Info Model", Internet-Draft draft-ietf-i2rs-rib-info-model-01, October 2013. |
| [I-D.ietf-netmod-acl-model] | Bogdanovic, D., Sreenivasa, K., Huang, L. and D. Blair, "Network Access Control List (ACL) YANG Data Model", Internet-Draft draft-ietf-netmod-acl-model-02, March 2015. |