One document matched: draft-ietf-i2rs-fb-rib-info-model-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC0768 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC0793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC3060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3060.xml">
<!ENTITY RFC3460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3460.xml">
<!ENTITY RFC3644 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3644.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC7223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7223.xml">
<!ENTITY I-D.ietf-netmod-routing-cfg SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-routing-cfg.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-ephemeral-state SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-ephemeral-state.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-i2rs-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-data-model.xml">
<!ENTITY I-D.ietf-netmod-acl-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-acl-model.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf.xml">
<!ENTITY I-D.hares-i2rs-pkt-eca-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-pkt-eca-data-model.xml">
<!ENTITY I-D.hares-i2rs-fb-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-fb-rib-data-model.xml">
<!ENTITY I-D.hares-i2rs-fb-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-fb-rib-data-model.xml">
<!ENTITY I-D.hares-idr-bgp-fb-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-idr-bgp-fb-rib-data-model.xml">
<!ENTITY I-D.ietf-i2rs-usecase-reqs-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-usecase-reqs-summary.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-ietf-i2rs-fb-rib-info-model-00" ipr="trust200902">
<front>
<title abbrev="Filter-Base RIB IM">Filter-Based RIB Information Model </title>
<author fullname="Sriganesh Kini" initials="S." surname="Kini">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city> </city>
<country></country>
</postal>
<email>sriganesh.kini@ericsson.com</email>
</address>
</author>
<author fullname="Susan Hares" initials="S." surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<author fullname="Linda Dunbar" initials="L." surname="Dunbar">
<organization>Huawei</organization>
<address>
<postal>
<street> </street>
<city> </city>
<region> </region>
<code> </code>
<country>USA</country>
</postal>
<email>linda.dunbar@huawei.com</email>
</address>
</author>
<author fullname="Anoop Ghanwani" initials="A." surname="Ghanwani">
<organization>Dell</organization>
<address>
<postal>
<street></street>
<city> </city>
<country></country>
</postal>
<email>anoop@alumni.duke.edu</email>
</address>
</author>
<author fullname="Ram Krishnan" initials="R." surname="Krishnan">
<organization>Dell</organization>
<address>
<postal>
<street></street>
<city></city>
<country></country>
</postal>
<email>Ramkri123@gmail.com</email>
</address>
</author>
<author fullname="Dean Bogdanovic" initials="D." surname="Bogdanovic">
<organization>Juniper Networks</organization>
<address>
<postal>
<street></street>
<city>Westford, MA</city>
<country></country>
</postal>
<email>deanb@juniper.net</email>
</address>
</author>
<author fullname="Russ White" initials="R." surname="White">
<organization>Linkedin</organization>
<address>
<postal>
<street></street>
<city></city>
<country></country>
</postal>
<email>russ@riw.us</email>
</address>
</author>
<date year="2016" />
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t>This document defines an information model associated
with the I2RS ephemeral state for filter-based routing
of IP packets via a Filter-based Routing Information Base (FB-RIB).
FB-RIBs (ephemeral and non-ephemeral) are associated with
specific interfaces interfaces on a routing device, and
process packets received on these interfaces according
a filtering policy. A filtering policy is a
a minimalistic event-match_condition-action (ECA) policy with
only one event - the reception of a frame/packet of data on an
interface. The match conditions in the filter policy are
n-tuple matches based on the content of the frame/packet or the
time of its arrival. Filter-based policy allows actions which
modifying the frame/packet, forward the frame or packet, or drop the frame/packet.
Filter-Based Policy in FB-RIBs engages before any destination based routing so
the FB-RIBs provide a destination-based default RIB that will be used if none of
the filters are matched.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Interface to the Routing System (I2RS) <xref target="I-D.ietf-i2rs-architecture"></xref>
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.
</t>
<t> This document provides an information module for Filter Based Routing Information Base
(FB-RIB) and describes the I2RS interaction with routing filters within a routing element.
</t>
<section title="Definition of I2RS Filter Based RIB">
<t>Filter-based routing is a technique used to make packet forwarding decisions
based policy-based filters that are matched to the incoming packets. These filter policies
are a minimalistic "event-Match Condition-Action" policy with one event -
the reception of a frame or packet on an associated interface. The ECA policies
have:
<list style="symbols">
<t>event = reception of frame/packet on associated interface,</t>
<t>match condition = policy filters which match portions of frame/packet, </t>
<t>actions - to modify frame/packet, and forward or drop frame/packet</t>
</list>
</t>
<t>
Filter-Based forwarding may match on the condition of
any portion of the frame/packet. Figure 1
shows some of the filters that can be applied to the reception of packets.
The filter for individual fields can be combined with an "AND" or
and "OR", but the default combination is that of an "AND".
</t>
<t>
<figure>
<artwork>
Ingress filter Matches (for ECA policy)
|
|
+--------+------+------+---+--+-----+-----+----+-----+------+------+
| | | | | | | | | |
| | | | | | | | | |
L1 L2 L3 L4 VLAN VNID size Time packet/ ...
header header header header header frame
receive
count
Figure 1: Possible matching conditions for basic network filters
</artwork>
</figure>
</t>
<t> A Filter-Based Routing Information Base (FB-RIB)) is a set of
packet-reception ECA policy rules which are:
<list style="symbols">
<t>ordered, and </t>
<t>apply to specific interfaces</t>
</list>
If all matches fail, default action is to forward the packet using
a specific RIB from:
<list style="symbols">
<t>routing RIBs as described in
<xref target="I-D.ietf-netmod-routing-cfg"></xref>"
</t>
<t>ephemeral I2RS RIBs as described
in <xref target="I-D.ietf-i2rs-rib-info-model"></xref>.
</t>
</list>
</t>
</section>
<section title="I2RS Use Cases Suported by Filter-Based RIB">
<t> The I2RS use cases which benefit from Filter-Based Routing are:
<list style="symbols">
<t> Protocol independent Use cases and large flow use cases
described in <xref target="I-D.hares-i2rs-usecase-reqs-summary"></xref>.
</t>
<t>the use cases of steering traffic to their designated service
functions that are different than the packet's destinations, and </t>
<t>large flow use cases described in
<xref target="I-D.hares-i2rs-usecase-reqs-summary"></xref> </t>
</list>
</t>
</section>
<section title="Definitions and Acronyms">
<t>
<list style="hanging">
<t hangText="CLI"><vspace blankLines="1" /> Command Line Interface</t>
<t hangText="FB-RIB"><vspace blankLines="1" /> Filter-Based Routing Information Base</t>
<t hangText="FB-Filter"><vspace blankLines="1" />
One filter in the filter-based RIB. The filters are Event-Condition-Action
filters often represented by the form "if Condition then action". </t>
<t hangText="Policy Group"><vspace blankLines="1" /> Policy Groups are groups of
policy rules. The groups of policy in the basic network policy
<xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref> allow grouping
of policy by name. This name allow easier management of
customer-based or provider based filters.
</t>
<t hangText="RIB IM "><vspace blankLines="1" /> RIB Informational Model (RIB IM)
is an information model which describes a Routing Information Base </t>
<t hangText="Routing instance"><vspace blankLines="1" /> A routing instance is
a core data model within <xref target="I-D.ietf-netmod-routing-cfg"></xref>.
An instance creates a logical slice of the router and allows different
logical slices to communicate to communicate with each
other. </t>
</list>
</t>
</section>
</section>
<section title="I2RS Filter-Based RIB place among Filter-Based RIBS">
<t>
The following three types of Filter-Based RIBs exist:
<list style="symbols">
<t>Policy Based Routing - configured by packet ECA policy,
</t>
<t>I2RS Filter-Based RIBs - proposed by this document, </t>
<t>BGP Flow Specification <xref target="RFC5575"></xref>.
</t>
</list>
This section examines issues regarding ephemeral versus config state,
the need for order within policies, and the current yang support for packet-reception ECA policy.
</t>
<section title="Ephemeral State versus Configuration State">
<t>Filter-Based RIBs with packet-reception ECA policy exist in three
types of state: configuration state,
ephemeral reboot state (I2RS), and BGP Session state.
</t>
<t>
Policy Routing configures the packet-reception ECA policy in
configuration state, and runs this policy to specific interfaces.
This configuration state may be configured by NETCONF/RESTCONF in yang modules
or proprietary configuation via CLI. This specification examines configuration state
specified in yang modules and extended by proprietary additions to yang modules.
Yang modules which specify the normal routing RIBs include:
<list>
<t><xref target="I-D.ietf-netmod-routing-cfg"></xref></t>
<t>statics routes (TBD) </t>
</list>
</t>
<t>
Configuration state set via secure protocols (NETCONF <xref target="RFC6241"></xref>
or RESTCONF <xref target="I-D.ietf-netconf-restconf"></xref>) and survives the
reboot of the system. draft-hares-rtgwg-fb-rib refers to Filter-Based RIB
described above which contains an ordered list of packet
</t>
<t>I2RS ephemeral state <xref target="I-D.ietf-i2rs-ephemeral-state"></xref>
is state which does not persist across a reboot (software or hardware).
I2RS ephemeral state can be indicated a portion of a sub-tree, a sub-tree,
tree within a yang modules, or a full module. I2RS Ephemeral state may
reference configuration state or protocol state (E.g. MPLS LSP or BGP peer state).
</t>
<t>
The I2RS Filter-Based RIB is defined as a ephemeral module with possible links to the
following:
<list>
<t>default RIBs either in the I2RS RIB module <xref target="I-D.ietf-i2rs-rib-data-model"></xref> or
configured RIB <xref target="I-D.ietf-netmod-routing-cfg"></xref>, </t>
<t>interfaces that I2RS Filter-Based RIB is running on. </t>
</list>
</t>
<t>
BGP Flow Specification <xref target="RFC5575"></xref> passes packet-reception ECA
Policy in BGP UPDATE packets (NLRI and BGP Extended Communities). The BGP Flow Specification
packet-reception ECA policy is bgp peer session ephemeral state which disappears when the
BGP peer closes the BGP Session. This bgp session ephemeral state can refer to
configuration state for interfaces configured, and for default RIBs.
<xref target="RFC5575"></xref> does not consider I2RS configuration state.
</t>
<t>
Precedence between these three types of state is defined as most dynamic to least dyanmic, or
<list style="numbers">
<t>BGP Session packet-reception Filter Policy,</t>
<t>I2RS Filter-Based RIB Policy,</t>
<t>Configuration Filter-RIB Policy (aka Policy RIB).</t>
</list>
Precedence impacts when two types of state try to operate on the exact same filter match in the policy.
However, Filter-Based RIBS operate first on "order" and priority within the order, and then on
the level of ephemeral state.
</t>
</section>
<section title="Need for Order">
<t>Filter-Based RIBs use packet-reception ECA policy instead of destination based
forwarding to determine where to forward/send a packet. A packet which matches multiple
filters in a Filter-Based RIB will be forwarded based on the first filter matched. Due to first-match
processing, the order of filters matters in the process. All Filter-Based RIBs
(configuration, I2RS, and BGP Flow Specification) forwarded based on the first match filter.
</t>
<t>Filter-Based Policy is inserted in the RIB by order number. If order number is tied, then
precedence is based on the type of filter, longest prefix match (MAC or
IP address (IPv4/IPv6), lowest value, or longest string). It is expected that order will
contain a large enough number space to differentiate most policies.
</t>
<t>Note: <xref target="RFC5575"></xref> does not support order, but current work is beginning
draft-hares-idr-flow-spec-combo-00.txt to support order in BGP flow specification.
</t>
<t>
<figure>
<artwork>
flow-rule-cmp (a,b)
{
comp1 = next_component(a); /component is the type of filter
comp2 = next_component(b);
while (comp1 || comp2) {
// component_type returns infinity on end of list
if (component_type(comp1) < component_type(comp2)) {
return A_HAS_PRECEDENCE;
}
if (component_type(comp1) > component_type(comp2)) {
return B_HAS_PRECEDENCE;
}
// IP values)
if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) {
common = MIN(prefix_length(comp1),prefix_length(comp2));
cmp = prefix_compare (comp1,comp2,common);
// not equal, lowest value has precedence
// equal, longest match has precedence;
} else if (component_type (comp1) == MAC_DESTINATION ||
MAC_SOURCE) {
common = MIN(MAC_address_length(comp1),
MAC_address_length(comp2));
cmp = MAC_Address_compare(comp1,comp2,common);
//not equal, lowest value has precedence
//equal, longest match has precedence
} else {
common = MIN(component_length(comp1),
component_length(comp2));
cmp = memcmp(data(comp1), data(comp2), common);
//not equal, lowest value has precedence
//equal, longest string has precedence
}
}
}
Figure 2 - precedence
</artwork>
</figure>
</t>
</section>
<section title="ECA Policy Supported">
<t> The filter based-RIB uses event-condition-action policy (ECA) rules.
The following policies are used in this version of the yang module:
<list style="symbols">
<t> Access lists (ACLs) <xref target="I-D.ietf-netmod-acl-model"></xref>
</t>
<t> Packet-reception ECA policy <xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref>
</t>
</list>
</t>
<t>
Proprietary filters may augment these IETF defined ECA rules.
The IETF filters support basic filtering plus QOS and load balancing.
Below is an example set of match conditions on ingreessI2RS
that the basic I2RS FB-RIB can support.
</t>
</section>
<section title="Relationship between Filter-RIBs and RIBS">
<t>
Filter-based RIBS (FB-RIBs) provide packet-reception event-match condition-action policy,
but if the filters do not provide match the Filter-Based RIBs provide
default RIBs for destination based forwarding (IP or MAC). The following are restrictionsThe
for the default RIBs:
<list style="symbols">
<t>The configuration FB-RIBs
can only refer to another configuration RIB.
</t>
<t>The I2RS FB-RIBs can refer to a configuration RIB,
an I2RS reboot ephemeral RIB, or a BGP Session ephemeral RIB.
The BGP peer session may be dropped while a
I2RS FB-RIB is in session. If so, all defaults pointing to the
BGP RIB must be removed. The I2RS RIB may be removed, and if
so all defaults pointing to that route must be removed.
The default order of precedence for the default RIB
is the BGP-Peer default RIB, the I2RS default FB-RIB, and
the configuration default RIB.
</t>
<t>The BGP session FB-RIBs can refer to a configuration RIBs, a I2RS Ephemeral RIB,
and a BGP RIB. Just as with the I2RS FB-RIB, the precedence if multiple default
RIBs exist are: BGP Peer default RIB, then I2RS default RIB, followed by
configuration default RIB.
</t>
<t> The I2RS Ephemeral RIB module is described in <xref target="I-D.ietf-i2rs-rib-info-model"></xref>
and <xref target="I-D.ietf-i2rs-rib-data-model"></xref>.
The I2RS RIB contains a collection of RIBs with the following information per instance:
<list style="symbols">
<t>The set of interfaces indicates which interfaces are
associated with this routing instance. </t>
<t>The RIBs specify how incoming traffic is to be forwarded
based on destination (E.g. RIB and FB-RIB). </t>
<t>The routing parameters control the information in the
RIBs.</t>
</list>
</t>
<t>
A routing instance may have both an I2RS RIB modules and I2RS FB-FIB modules
associated with it. If the I2RS RIB list of interfaces does not contain
the list of interfaces the FB-RIB is operating on, then
the I2RS RIB must not be installed as a default RIB.
</t>
<t>FB-RIB and RIB can not be used at the same time, which means:
<list style="symbols">
<t>If a router doesn’t support filter-based routing, a router
MUST use RIB and MUST not use FB-RIB. The default RIB
for a FB-RIB should destination-based RIB, and this
RIB may be generated by routing protocols.
However, the FB-RIB forwarding must take precedence over
the default RIB.
</t>
<t>If a router supports filter-based routing:
<list>
<t>FB-RIB is used </t>
<t>Multiple FB-RIBs may exist within a routing instance </t>
<t>An interface can be associated with at most one FB-RIB </t>
<t>The Default RIB for a FB-RIB is used if several criteria beyond destination
address is not matched.</t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="Filter-Based-RIB module ">
<t> A Filter-Based RIB (FB-RIB)contains an ordered set of filter routes where each
filter-route is a match condition followed by an action. An FB-RIB is contained in a
routing-instance defined by <xref target="I-D.ietf-netmod-routing-cfg"></xref>.
An FB-RIB has a list of interfaces that is a subset of the list of interfaces in the
routing-instance that it is contained in. An incoming packet on an interface belonging
to a FB-RIB is first handled by the FIB programmed using that FB-RIB.
If no match action succeeds, then the packet is forwarded using the FIB programmed using
the RIB of that routing instance.
</t>
<t>
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). </t>
<t>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,
and list of FB-RIBs. Each interface
can be associated with at most one FB RIB.
</t>
<t> The processing within the FB-RIB process
within the routing system is expected to do the following:
<list style="symbols">
<t> When a packet successfully matches match term/entry in a filter-route, the corresponding
rule-actions are applied.</t>
<t>If a packet does not match the match term/entry in the filter route, the filter route processing goes to the next
term/entry in the order, and looks for a match, within the current filter or goes to the
next filter in the list. This continues until either a filter route match term/entry is successfully
matched, or no more filters in the list exists. </t>
<t>If no match has been found within list of filters in FB-RIB list, then the packet will be
forwarded using the I2RS RIB specified by the FB-RIB if one exists. If no I2RS RIB is specified,
the FB-RIB will check a configured RIB. If no configured RIB exists, the packet will be discarded. </t>
</list>
</t>
<t>
Groups within a I2RS FB-RIB allow the logical grouping of rules under a name for ease of access.
For example, take two customers. Customer-A has three packet-reception ECA policies that insert rules at
order 5, 10, and 20. Customer-B has three packet-reception ECA policies that insert rules at 4, 8, and 9.
The use of the group names "Customer-A" and "Customer-B" allow easy addition or deletion of these rules, but
do not change the ordering of these rules.
</t>
<section title="ietf-fb-rib Configuration: Top level Container">
<t> The FB-RIB configuration entries associated with each FB-RIB in a routing instance are:
<list style="hanging">
<t hangText="default-instance-name (FB-FIB-instance-name):"> default Routing Instance name for all FB-RIBs </t>
<t hangText="default-router-id (FB-RIB-router-id):">router id associated
with the FB-RIB function of the Routing instance </t>
<t hangText="config-fb-rib:">list of filter-based RIBs created
by configuration processes, and described in draft-hares-rtgwg-fb-rib which
utilizes <xref target="I-D.hares-i2rs-fb-rib-data-model"></xref> to
define common filter-based RIB structures.
</t>
<t hangText="i2rs-fb-rib:">list of I2RS reboot ephemeral filter-based RIBs.
Described in this draft with data model in <xref target="I-D.hares-i2rs-fb-rib-data-model"></xref>
which utilizes <xref target="I-D.hares-i2rs-fb-rib-data-model"></xref> to
define common filter-based RIB structures.
</t>
<t hangText="bgp-fb-rib:">list of BGP Session ephemeral filter-based RIBs
Described in this draft, and data model in (draft-hares-idr-bgp-fb-rib-data-model).
which utilizes <xref target="I-D.hares-i2rs-fb-rib-data-model"></xref> to define
common filter-based RIB structures, and <xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref>
to the common packet-reception ECA filters.
</t>
</list>
</t>
<t>
<figure>
<artwork>
Configuration RIBS
+-----------------------------------------+
| routing instance |
+-------|-------------|----------------|--+
| | |
| | |
+---------|----+ +-----|-----+ +--------|-----+
|config-fb-rib | |i2rs-fb-rib| |bgp-fs-fb-rib |
+------|-------+ +-----|------+ +------|------+
|............:....|...............|
: (uses common structures
: in separate lists of FB-RIBs)
+--------|----+
|fd-ribs* |
| |
+--|----------+
|
Figure 3: Routing instance with three types of
Filter-FIB lists
</artwork>
</figure>
</t>
<t>
The Top-level Yang structure for a global
configuration of Filter-Based RIBs are:
<figure>
<artwork>
Augments rt:logical-network-elements:\
:logical-network-element:network-instances: \
network-instance
ietf-fb-rib module
+--rw ietf-fb-rib
+--rw default-instance-name string
+--rw default-router-id rt:router-id
+--rw config-fb-ribs
if-feature "config-filter-based-RIB";
uses fb-ribs;
+--rw i2rs-fb-ribs
if-feature "I2RS-filter-based-RIB";
uses fb-rib-t:fb-ribs;
+--rw bgp-fs-fb-ribs
if-feature "BGP-FS-filter-based-RIB";
uses fb-rib-t:fb-ribs;
Figure 5: configuration state
</artwork>
</figure>
</t>
</section>
<section title="ietf-fb-rib-opstate: Operational Top Level Container">
<t>
The FB-RIB operational state entries associated with each FB-RIB in a routing instance are:
<list style="hanging">
<t hangText="default-instance-name (FB-FIB-instance-name):">Default Routing Instance for FB-RIBs.</t>
<t hangText="default-router-id (FB-RIB-router-id):">Default Router ID associated FB-RIBs. </t>
<t hangText="config-fb-rib-opstate">operational state for
config RIB described in draft-hares-rtgwg-fb-rib which utilizes
<xref target="I-D.hares-i2rs-fb-rib-data-model"></xref> to define common structures.
</t>
<t hangText="i2rs-fb-rib-opstate:">operational state for
I2RS reboot ephemeral Filter-Based RIB. Logic is described in this draft, and
data model is described in <xref target="I-D.hares-i2rs-fb-rib-data-model"></xref>.
Common structures are defined in <xref target="I-D.hares-i2rs-fb-rib-data-model"></xref>.
</t>
<t hangText="bgp-fb-rib-opstate:">BGP Session ephemeral Filter-Based RIB-interface
with logic described in this draft, and data model in (draft-hares-bgp-fb-rib-data-model).
Common structures are also defined in <xref target="I-D.hares-i2rs-fb-rib-data-model"></xref>,
and <xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref>.
</t>
</list>
</t>
<t>
<figure>
<artwork>
Operational state
+-----------------------------------------+
| routing instance |
+-------|-------------|----------------|--+
| | |
| | |
+---------|----+ +-----|------+ +--------|-----+
|config-fb-rib-| |i2rs-fb-rib-| |bgp-fs-fb-rib-|
| opstate | | opstate | | opstate |
+------|-------+ +-----|------+ +------|-------+
|............:....|...............|
: (uses common structures
: in separate lists of FB-RIBs)
+--------|-----------+
|fb-ribs_oper_status |
| |
+--|-----------------+
|
Figure 4: Routing instance with three types of
Filter-FIB lists
</artwork>
</figure>
</t>
<t>
The Top-level Yang structure for a global
operational state of Filter-Based RIBs are:
<figure>
<artwork>
Augments rt:logical-network-elements:\
:logical-network-element:network-instances: \
network-instance
ietf-fb-rib module
+--rw ietf-fb-rib-opstate
+--rw default-instance-name string
+--rw default-router-id rt:router-id
+--rw config-fb-rib-opstate
if-feature "config-filter-based-RIB";
uses fb-rib-t:fb-ribs-oper-status;
+--rw i2rs-fb-rib-opstate {
if-feature "I2RS-filter-based-RIB";
uses fb-rib-t:fb-ribs-oper-status;
+--rw bgp-fs-fb-rib-opstate
if-feature "BGP-FS-filter-based-RIB";
uses fb-rib-t:fb-ribs-oper-status;
Figure 5: operational state
</artwork>
</figure>
</t>
</section>
<section title="fb-ribs: List of Filter-Based RIBs (Configuration)">
<t>Filter-Based RIB structures for configuration (fb-ribs) contain a list of fb-rib structures with the
following high-level structure:
<list style="hanging">
<t hangText="fb-rib-name: ">Name of fb-Rib (key),
</t>
<t hangText="address-family: ">AFI for Address Family,
</t>
<t hangText="fb-type: ">type of FB-RIB
(config, I2RS reboot ephemeral, or BGP Flow Specification session ephemeral).
</t>
<t hangText="Interface_list(FB-RIB-interface):">A list of interfaces
that all of the FB-RIB RIB operates over. This list must be a subset of the
interface_list associated with the routing instance.
</t>
<t hangText="default-RIBS: ">structure with default
RIBS in configuration space, I2RS RIB space, or BGP VPN space.
</t>
<t hangText="instance-using:">list of instances using this FB-RIB (normally one).
</t>
<t hangText="fb-rb-updates:">Tracking Write-References to
this RIB.
</t>
<t hangText="uses pkt-eca:pkt-eca-policy-set:"> pkt ECA Policy
described in <xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref>
</t>
</list>
</t>
<t>
<figure>
<artwork>
+--------|----+
|FB-RIBs* |
| |
+--|----------+
|
^
/|\
+-----^---------------------------+
| FB-RIB |
+----|-------|----------|-----|---+
| +-----|-----+ +--------+ +-------+
| |interface | |default | |default|
| | list | |I2RS | | Config|
| | (Names) | | RIB | | RIB |
| +-----------+ +--------+ +-------+
|
+-----------------------+
| FB-RIB Ordered List |
| of pkt ECA policy |---------+
+-----------|-----------+ |
| |
+-----------|-----------+ |
| Groups | |
+-----------|-----------+ |
| |
+-----------|--------------+ |
| Rules |------+
|(ordered list of rules of |
| the form match-action) |
+--------------------------+
Figure 5: fb-rib (configuration FB-RIB)
</artwork>
</figure>
</t>
<t>
The Top-level Yang structure for the FB-RIB types is:
<figure>
<artwork>
module: fb-rib-types:
+--rw fb-ribs
+--rw fb-rib* [rib-name]
| +--rw rib-name string
| | rw fb-type identityref / ephemeral or not
| +--rw rib-afi rt:address-family
| +--rw fb-rib-intf* [name]
| | +--rw name string
| | +--rw intf if:interface
| +--rw default-rib
| | +--rw rt-rib rt:routing:routing-instance:name
| | +--rw config-rib string; // config rib name
| | +--rw i2rs-rib:routing-instance:name
| | +--rw i2rs-rib string; //ephemeral rib name
| | +--rw bgp-instance-name string
| | +--rw bgp-rib string //session ephemeral
| +--rw fb-rib-refs
| | +--rw fb-rib-update-ref uint32 /count of writes
| +--rw instance-using*
| | device:networking-instance:networking-instance-name
| +--use pkt-eca:pkt-eca-policy-set
Figure 6: FB RIB Type Structure
</artwork>
</figure>
</t>
</section>
<section title="fb-rib-oper-status - list of filter-ribs with operational status">
<t>The Filter-Based RIB structures for operational state have the following entries:
<list style="hanging">
<t hangText="fb-rib-name: ">Name of fb-Rib (key) </t>
<t hangText="uses pkt-eca:pkt-eca-opstate:"> pkt ECA policy
operational state described in <xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref>
</t>
</list>
</t>
<t>
<figure>
<artwork>
HIgh Level Yang
+--rw fb-ribs-oper-status
+--rw fb-rib-oper-status* [fb-rib-name]
uses pkt-eca:pkt-eca-opstate
</artwork>
</figure>
</t>
</section>
<section title="Packet-reception Event-Condition-Action Policy">
<t>
The three levels of policy are expressed as:
<figure>
<artwork>
Config Policy definitions
=======================================
Policy level: pkt-eca-policy-set
group level: pkt-eca-policy-set:groups
rule level: bnp-eca-policy-set:rules
Operational State for Policy
=======================================
Policy level: pkt-eca-policy-opstate
group level: pkt-eca-policy-opstate:groups-status
rule level: bnp-eca-policy-opstate:rules_opstate*
bnp-eca-policy-opstate:rules_opstats*
figure
</artwork>
</figure>
</t>
<t>
High level Yang structure for Configuration
and operational status are shown in figure x below.
<figure>
<artwork>
Packet Reception ECA policy
module ietf-pkt-eca-policy
+--rw pkt-eca-policy-cfg
| +--rw pkt-eca-policy-set
| +--rw groups* [group-name]
| | +--rw vrf-name string
| | +--rw address-family
| | +--rw group-rule-list* [rule-name]
| | | +--rw rule-name
| | | +--rw rule-order-id
| +--rw rules [order-id rule-name]
| +--rw eca-matches
| | ...
| +--rw eca-qos-actions
| | ...
| +--rw eca-fwd-actions
| | ...
+--rw pkt-eca-policy-opstate
+--rw pkt-eca-opstate
+--rw groups* [group-name]
| +--rw rules-installed;
| +--rw rules_status* [rule-name]
+--rw rule-group-link* [rule-name]
| +--rw group-name
+--rw rules_opstate* [rule-order rule-name]
| +--rw status
| +--rw rule-inactive-reason
| +--rw rule-install-reason
| +--rw rule-installer
| +--rw refcnt
+--rw rules_op-stats* [rule-order rule-name]
+--rw pkts-matched
+--rw pkts-modified
+--rw pkts-forwarded
Figure 4 - High-Level Yang structure.
</artwork>
</figure>
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This informational draft does not specify any
IANA requests. </t>
</section>
<section title="Security Considerations">
<t>A I2RS defines an ephemeral data store that will
dyanamically change traffic paths set by the routing configuration.
An I2RS FB-RIB provides dynamic Event-Condition-Action policy that
will further change the operation of forwarding by allow dyanmic
policy and ephemeral RIBs to alter the traffic paths set by
routing configuration. Care must be taken in deployments to
use the appropriate security and operational control to make
use of the tools the I2RS RIB and I2RS FB-RIB provide.
</t>
</section>
</middle>
<back>
<references title="Normative References:">
&RFC2119;
&RFC7223;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-info-model;
&I-D.ietf-i2rs-rib-data-model;
&I-D.ietf-i2rs-ephemeral-state;
&I-D.hares-i2rs-pkt-eca-data-model;
&I-D.hares-i2rs-fb-rib-data-model;
</references>
<references title="Informative References">
&RFC5575;
&RFC6241;
&I-D.ietf-netmod-acl-model;
&I-D.ietf-netmod-routing-cfg;
&I-D.ietf-netconf-restconf;
&I-D.ietf-i2rs-usecase-reqs-summary;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 15:42:06 |