[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-i2rs-fb-rib-info-model

I2RS working group                                               S. Kini
Internet-Draft                                                  Ericsson
Intended status: Standards Track                                S. Hares
Expires: August 10, 2016                                       L. Dunbar
                                                                  Huawei
                                                             A. Ghanwani
                                                             R. Krishnan
                                                                    Dell
                                                           D. Bogdanovic
                                                        Juniper Networks
                                                                R. White
                                                                Linkedin
                                                        February 7, 2016


                   Filter-Based RIB Information Model
                  draft-kini-i2rs-fb-rib-info-model-03

Abstract

   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.

Status of This Memo

   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



Kini, et al.             Expires August 10, 2016                [Page 1]


Internet-Draft             Filter-Base RIB IM              February 2016


   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 August 10, 2016.

Copyright Notice

   Copyright (c) 2016 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Definition of I2RS Filter Based RIB . . . . . . . . . . .   3
     1.2.  I2RS Use Cases Suported by Filter-Based RIB . . . . . . .   4
     1.3.  Definitions and Acronyms  . . . . . . . . . . . . . . . .   4
   2.  I2RS Filter-Based RIB place among Filter-Based RIBS . . . . .   5
     2.1.  Ephemeral State versus Configuration State  . . . . . . .   5
     2.2.  Need for Order  . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  ECA Policy Supported  . . . . . . . . . . . . . . . . . .   8
     2.4.  Relationship between Filter-RIBs and RIBS . . . . . . . .   8
   3.  Filter-Based-RIB module . . . . . . . . . . . . . . . . . . .   9
     3.1.  ietf-fb-rib Configuration: Top level Container  . . . . .  10
     3.2.  ietf-fb-rib-opstate: Operational Top Level Container  . .  12
     3.3.  fb-ribs: List of Filter-Based RIBs (Configuration)  . . .  14
     3.4.  fb-rib-oper-status - list of filter-ribs with operational
           status  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     3.5.  Packet-reception Event-Condition-Action Policy  . . . . .  16
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     6.1.  Normative References: . . . . . . . . . . . . . . . . . .  19
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20







Kini, et al.             Expires August 10, 2016                [Page 2]


Internet-Draft             Filter-Base RIB IM              February 2016


1.  Introduction

   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 an information module for Filter Based Routing
   Information Base (FB-RIB) and describes the I2RS interaction with
   routing filters within a routing element.

1.1.  Definition of I2RS Filter Based RIB

   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:

   o  event = reception of frame/packet on associated interface,

   o  match condition = policy filters which match portions of frame/
      packet,

   o  actions - to modify frame/packet, and forward or drop frame/packet

   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".

                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

   A Filter-Based Routing Information Base (FB-RIB)) is a set of packet-
   reception ECA policy rules which are:



Kini, et al.             Expires August 10, 2016                [Page 3]


Internet-Draft             Filter-Base RIB IM              February 2016


   o  ordered, and

   o  apply to specific interfaces

   If all matches fail, default action is to forward the packet using a
   specific RIB from:

   o  routing RIBs as described in [I-D.ietf-netmod-routing-cfg]"

   o  ephemeral I2RS RIBs as described in
      [I-D.ietf-i2rs-rib-info-model].

1.2.  I2RS Use Cases Suported by Filter-Based RIB

   The I2RS use cases which benefit from Filter-Based Routing are:

   o  Protocol independent Use cases and large flow use cases described
      in [I-D.hares-i2rs-usecase-reqs-summary].

   o  the use cases of steering traffic to their designated service
      functions that are different than the packet's destinations, and

   o  large flow use cases described in
      [I-D.hares-i2rs-usecase-reqs-summary]

1.3.  Definitions and Acronyms

   CLI

      Command Line Interface

   FB-RIB

      Filter-Based Routing Information Base

   FB-Filter

      One filter in the filter-based RIB.  The filters are Event-
      Condition-Action filters often represented by the form "if
      Condition then action".

   Policy Group

      Policy Groups are groups of policy rules.  The groups of policy in
      the basic network policy [I-D.hares-i2rs-pkt-eca-data-model] allow
      grouping of policy by name.  This name allow easier management of
      customer-based or provider based filters.




Kini, et al.             Expires August 10, 2016                [Page 4]


Internet-Draft             Filter-Base RIB IM              February 2016


   RIB IM

      RIB Informational Model (RIB IM) is an information model which
      describes a Routing Information Base

   Routing instance

      A routing instance is a core data model within
      [I-D.ietf-netmod-routing-cfg].  An instance creates a logical
      slice of the router and allows different logical slices to
      communicate to communicate with each other.

2.  I2RS Filter-Based RIB place among Filter-Based RIBS

   The following three types of Filter-Based RIBs exist:

   o  Policy Based Routing - configured by packet ECA policy,

   o  I2RS Filter-Based RIBs - proposed by this document,

   o  BGP Flow Specification [RFC5575].

   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.

2.1.  Ephemeral State versus Configuration State

   Filter-Based RIBs with packet-reception ECA policy exist in three
   types of state: configuration state, ephemeral reboot state (I2RS),
   and BGP Session state.

   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:

      [I-D.ietf-netmod-routing-cfg]

      statics routes (TBD)

   Configuration state set via secure protocols (NETCONF [RFC6241] or
   RESTCONF [I-D.ietf-netconf-restconf]) 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



Kini, et al.             Expires August 10, 2016                [Page 5]


Internet-Draft             Filter-Base RIB IM              February 2016


   I2RS ephemeral state [I-D.ietf-i2rs-ephemeral-state] 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).

   The I2RS Filter-Based RIB is defined as a ephemeral module with
   possible links to the following:

      default RIBs either in the I2RS RIB module
      [I-D.ietf-i2rs-rib-data-model] or configured RIB
      [I-D.ietf-netmod-routing-cfg],

      interfaces that I2RS Filter-Based RIB is running on.

   BGP Flow Specification [RFC5575] 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.  [RFC5575]
   does not consider I2RS configuration state.

   Precedence between these three types of state is defined as most
   dynamic to least dyanmic, or

   1.  BGP Session packet-reception Filter Policy,

   2.  I2RS Filter-Based RIB Policy,

   3.  Configuration Filter-RIB Policy (aka Policy RIB).

   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.

2.2.  Need for Order

   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.




Kini, et al.             Expires August 10, 2016                [Page 6]


Internet-Draft             Filter-Base RIB IM              February 2016


   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.

   Note: [RFC5575] does not support order, but current work is beginning
   draft-hares-idr-flow-spec-combo-00.txt to support order in BGP flow
   specification.

   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




Kini, et al.             Expires August 10, 2016                [Page 7]


Internet-Draft             Filter-Base RIB IM              February 2016


2.3.  ECA Policy Supported

   The filter based-RIB uses event-condition-action policy (ECA) rules.
   The following policies are used in this version of the yang module:

   o  Access lists (ACLs) [I-D.ietf-netmod-acl-model]

   o  Packet-reception ECA policy [I-D.hares-i2rs-pkt-eca-data-model]

   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.

2.4.  Relationship between Filter-RIBs and RIBS

   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:

   o  The configuration FB-RIBs can only refer to another configuration
      RIB.

   o  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.

   o  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.

   o  The I2RS Ephemeral RIB module is described in
      [I-D.ietf-i2rs-rib-info-model] and [I-D.ietf-i2rs-rib-data-model].
      The I2RS RIB contains a collection of RIBs with the following
      information per instance:

      *  The set of interfaces indicates which interfaces are associated
         with this routing instance.





Kini, et al.             Expires August 10, 2016                [Page 8]


Internet-Draft             Filter-Base RIB IM              February 2016


      *  The RIBs specify how incoming traffic is to be forwarded based
         on destination (E.g.  RIB and FB-RIB).

      *  The routing parameters control the information in the RIBs.

   o  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.

   o  FB-RIB and RIB can not be used at the same time, which means:

      *  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.

      *  If a router supports filter-based routing:

         +  FB-RIB is used

         +  Multiple FB-RIBs may exist within a routing instance

         +  An interface can be associated with at most one FB-RIB

         +  The Default RIB for a FB-RIB is used if several criteria
            beyond destination address is not matched.

3.  Filter-Based-RIB module

   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
   [I-D.ietf-netmod-routing-cfg].  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.

   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




Kini, et al.             Expires August 10, 2016                [Page 9]


Internet-Draft             Filter-Base RIB IM              February 2016


   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, and list of FB-RIBs.  Each interface can be associated
   with at most one FB RIB.

   The processing within the FB-RIB process within the routing system is
   expected to do the following:

   o  When a packet successfully matches match term/entry in a filter-
      route, the corresponding rule-actions are applied.

   o  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.

   o  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.

   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.

3.1.  ietf-fb-rib Configuration: Top level Container

   The FB-RIB configuration entries associated with each FB-RIB in a
   routing instance are:

   default-instance-name (FB-FIB-instance-name):  default Routing
      Instance name for all FB-RIBs

   default-router-id (FB-RIB-router-id):  router id associated with the
      FB-RIB function of the Routing instance





Kini, et al.             Expires August 10, 2016               [Page 10]


Internet-Draft             Filter-Base RIB IM              February 2016


   config-fb-rib:  list of filter-based RIBs created by configuration
      processes, and described in draft-hares-rtgwg-fb-rib which
      utilizes [I-D.hares-i2rs-fb-rib-data-model] to define common
      filter-based RIB structures.

   i2rs-fb-rib:  list of I2RS reboot ephemeral filter-based RIBs.
      Described in this draft with data model in
      [I-D.hares-i2rs-fb-rib-data-model] which utilizes
      [I-D.hares-i2rs-fb-rib-data-model] to define common filter-based
      RIB structures.

   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
      [I-D.hares-i2rs-fb-rib-data-model] to define common filter-based
      RIB structures, and [I-D.hares-i2rs-pkt-eca-data-model] to the
      common packet-reception ECA filters.


   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

   The Top-level Yang structure for a global configuration of Filter-
   Based RIBs are:







Kini, et al.             Expires August 10, 2016               [Page 11]


Internet-Draft             Filter-Base RIB IM              February 2016


   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

3.2.  ietf-fb-rib-opstate: Operational Top Level Container

   The FB-RIB operational state entries associated with each FB-RIB in a
   routing instance are:

   default-instance-name (FB-FIB-instance-name):  Default Routing
      Instance for FB-RIBs.

   default-router-id (FB-RIB-router-id):  Default Router ID associated
      FB-RIBs.

   config-fb-rib-opstate  operational state for config RIB described in
      draft-hares-rtgwg-fb-rib which utilizes
      [I-D.hares-i2rs-fb-rib-data-model] to define common structures.

   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 [I-D.hares-i2rs-fb-rib-data-model].  Common
      structures are defined in [I-D.hares-i2rs-fb-rib-data-model].

   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 [I-D.hares-i2rs-fb-rib-data-model], and
      [I-D.hares-i2rs-pkt-eca-data-model].





Kini, et al.             Expires August 10, 2016               [Page 12]


Internet-Draft             Filter-Base RIB IM              February 2016


   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

   The Top-level Yang structure for a global operational state of
   Filter-Based RIBs are:

   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





Kini, et al.             Expires August 10, 2016               [Page 13]


Internet-Draft             Filter-Base RIB IM              February 2016


3.3.  fb-ribs: List of Filter-Based RIBs (Configuration)

   Filter-Based RIB structures for configuration (fb-ribs) contain a
   list of fb-rib structures with the following high-level structure:

   fb-rib-name:   Name of fb-Rib (key),

   address-family:   AFI for Address Family,

   fb-type:   type of FB-RIB (config, I2RS reboot ephemeral, or BGP Flow
      Specification session ephemeral).

   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.

   default-RIBS:   structure with default RIBS in configuration space,
      I2RS RIB space, or BGP VPN space.

   instance-using:  list of instances using this FB-RIB (normally one).

   fb-rb-updates:  Tracking Write-References to this RIB.

   uses pkt-eca:pkt-eca-policy-set:  pkt ECA Policy described in
      [I-D.hares-i2rs-pkt-eca-data-model]


























Kini, et al.             Expires August 10, 2016               [Page 14]


Internet-Draft             Filter-Base RIB IM              February 2016


               +--------|----+
               |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)

   The Top-level Yang structure for the FB-RIB types is:
















Kini, et al.             Expires August 10, 2016               [Page 15]


Internet-Draft             Filter-Base RIB IM              February 2016


    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

3.4.  fb-rib-oper-status - list of filter-ribs with operational status

   The Filter-Based RIB structures for operational state have the
   following entries:

   fb-rib-name:   Name of fb-Rib (key)

   uses pkt-eca:pkt-eca-opstate:  pkt ECA policy operational state
      described in [I-D.hares-i2rs-pkt-eca-data-model]

   HIgh Level Yang

   +--rw fb-ribs-oper-status
      +--rw fb-rib-oper-status* [fb-rib-name]
            uses pkt-eca:pkt-eca-opstate

3.5.  Packet-reception Event-Condition-Action Policy

   The three levels of policy are expressed as:








Kini, et al.             Expires August 10, 2016               [Page 16]


Internet-Draft             Filter-Base RIB IM              February 2016


   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


   High level Yang structure for Configuration and operational status
   are shown in figure x below.

































Kini, et al.             Expires August 10, 2016               [Page 17]


Internet-Draft             Filter-Base RIB IM              February 2016


   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.

4.  IANA Considerations

   This informational draft does not specify any IANA requests.

5.  Security Considerations

   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



Kini, et al.             Expires August 10, 2016               [Page 18]


Internet-Draft             Filter-Base RIB IM              February 2016


   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.

6.  References

6.1.  Normative References:

   [I-D.hares-i2rs-fb-rib-data-model]
              Hares, S., Kini, S., Dunbar, L., Ghanwani, A., Krishnan,
              R., Bogdanovic, D., Tantsura, J., and R. White, "Filter-
              Based RIB Data Model", draft-hares-i2rs-fb-rib-data-
              model-01 (work in progress), January 2016.

   [I-D.hares-i2rs-pkt-eca-data-model]
              Hares, S., Wu, Q., and R. White, "Filter-Based Packet
              Forwarding ECA Policy", draft-hares-i2rs-pkt-eca-data-
              model-00 (work in progress), January 2016.

   [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", draft-ietf-i2rs-architecture-12 (work in
              progress), December 2015.

   [I-D.ietf-i2rs-ephemeral-state]
              Haas, J. and S. Hares, "I2RS Ephemeral State
              Requirements", draft-ietf-i2rs-ephemeral-state-02 (work in
              progress), September 2015.

   [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-04 (work in progress),
              November 2015.

   [I-D.ietf-i2rs-rib-info-model]
              Bahadur, N., Kini, S., and J. Medved, "Routing Information
              Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work
              in progress), October 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.





Kini, et al.             Expires August 10, 2016               [Page 19]


Internet-Draft             Filter-Base RIB IM              February 2016


   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
              <http://www.rfc-editor.org/info/rfc7223>.

6.2.  Informative References

   [I-D.hares-i2rs-usecase-reqs-summary]
              Hares, S. and M. Chen, "Summary of I2RS Use Case
              Requirements", draft-hares-i2rs-usecase-reqs-summary-02
              (work in progress), May 2015.

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-09 (work in
              progress), December 2015.

   [I-D.ietf-netmod-acl-model]
              Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,
              "Network Access Control List (ACL) YANG Data Model",
              draft-ietf-netmod-acl-model-06 (work in progress),
              December 2015.

   [I-D.ietf-netmod-routing-cfg]
              Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
              Management", draft-ietf-netmod-routing-cfg-20 (work in
              progress), October 2015.

   [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
              <http://www.rfc-editor.org/info/rfc5575>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

Authors' Addresses

   Sriganesh Kini
   Ericsson

   Email: sriganesh.kini@ericsson.com








Kini, et al.             Expires August 10, 2016               [Page 20]


Internet-Draft             Filter-Base RIB IM              February 2016


   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com


   Linda Dunbar
   Huawei
   USA

   Email: linda.dunbar@huawei.com


   Anoop Ghanwani
   Dell

   Email: anoop@alumni.duke.edu


   Ram Krishnan
   Dell

   Email: Ramkri123@gmail.com


   Dean Bogdanovic
   Juniper Networks
   Westford, MA

   Email: deanb@juniper.net


   Russ White
   Linkedin

   Email: russ@riw.us












Kini, et al.             Expires August 10, 2016               [Page 21]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/