<?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 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-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-i2rs-usecase-reqs-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-usecase-reqs-summary.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-netmod-routing-cfg SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-routing-cfg.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.kini-i2rs-fb-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kini-i2rs-fb-rib-info-model.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.wu-idr-flowspec-yang-cfg SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wu-idr-flowspec-yang-cfg.xml">
<!ENTITY I-D.acee-rtgwg-yang-rib-extend 
   SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.acee-rtgwg-yang-rib-extend.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-hares-rtgwg-fb-rib-01"  ipr="trust200902">
  <front>
    <title abbrev="Filter-Base RIB DM">Filter-Based RIB Data Model </title>
	 <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="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 a yang data model for a 
	Filter-based Routing Information Base (RIB) Yang data model. A routing system uses
	the Filter-based RIB to program FIB entries that process incoming
	packets by matching on multiple fields (n-tuple) within the packet and then performing
	a specified action on it.  The FB-RIB can also specify an action to forward 
	the packet according to the FIB entries programmed
	 using the RIBs of its routing instance.
	 </t>
	 </abstract>
  </front>
  <middle>
  <section anchor="intro" title="Introduction">
     <t> This document provides a yang module for flow filter n-tuple policy that is locally configured.
	 This flow filter policy has also been called Policy routing in some implementations. 
	 </t>
	 <t>
	 This document defines a yang data model for a 
	Filter-based Routing Information Base (RIB) Yang data model. A routing system uses
	the Filter-based RIB to program FIB entries that process incoming
	packets by matching on multiple fields within the packet and then performing
	a specified action on it.  The FB-RIB can also specify an action to forward 
	the packet according to the FIB entries programmed
	 using the RIBs of its routing instance.</t>
	 <section title="Definition of I2RS Filter Based RIB">
	 <t>Filter-based routing is a technique used to make packet forwarding decisions
     based on a n-tuple filter that is matched to the incoming packets and the specified action.
	 It should be noted that that this is distinct from the static routes in the following RIBS:
	 <list style="symbols">
 	<t>configured RIB created using static routes in <xref target="I-D.ietf-netmod-routing-cfg"></xref>
	</t>
	<t>Extended static RIB defined in <xref target="I-D.acee-rtgwg-yang-rib-extend"></xref>,</t>
	<t>Ephmeral Protocol Independent RIB defined in <xref target="I-D.ietf-i2rs-rib-info-model"></xref>, or </t>
	 </list>
	 </t>
	<t> A Filter-Based RIB (Routing Information Base) is contained in a routing
	  instance. It contains a list of filters (match-action conditions), a list of interface the filter-based
      forwarding operates on. Filter-based RIBs (FB-RIBs) operate only on the interface the
       FB-RIB are configured on.
	  </t> 
	<t>A Filter Based RIB uses packet forwarding policy.  If packet reception is considered an
	event, then the I2RS Filter-based RIB uses a minimalistic Event-Condition-Action policy.
	 A Filter-based RIB entry specifies matche filters for the fields in a packet 
	 (which may include layer 1 to layer 3 header fields, transport or 
	 application fields) or size of the packet or interface received on. 
	The matches are contained in an ordered list of filters which 
	contain pairs of match condition-action (aka event-condition-action).
	</t>
	<t>
	If all matches fail, the default action is to forward the packet using 
	FIB entries that were programmed by the default Routing Informational Base
	(RIB) manager configured in the Filter-Based RIB (FB-RB)
	</t>
 
	<t>	Actions in the condition-action pair may impact forwarding or 
	set something in the packet that will impact forwarding.
	Policy actions are typically applied before applying QoS constraints
    since policy actions may override QoS constraint.
	 </t>
	<t>
    The Filter-Based RIB resides in ephemeral state as does the I2RS RIB and I2RS
	topology models.
	 </t>
	 </section>
	<section title="Requirements Language">
	<t>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref target="RFC2119"></xref>
   </t>
	<t> In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.
	</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-Route"><vspace blankLines="1" />  
	      The policy rules in the filter-based RIB are prescriptive of the Event-Condition-Action
		  form which is often represented by if Condition then action.
		  All policy in the filter-based RIB are in a ordered list, ordered by "order-number".
          Order number is similar to some CLI concepts of line number. </t>
		  <t hangText="Policy Group"><vspace blankLines="1" /> Policy Groups are groups of
		  policy rules that are set-up for the convenience of operators who wish to 
		  link the rules connected to a particular client.  
		  <list style="symbols">
		  <t>Groups do not affect the order of policy rulies. 
		  </t>
		  <t> The policy groups 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. This policy group 
		  is a second way to access certain policy rules on the policy rule list.
		  </t>
		  </list>
		  </t>
		  <t hangText="RIB IM "><vspace blankLines="1" /> RIB Informational Model (RIB IM) 
		  <xref target="I-D.ietf-i2rs-rib-info-model"></xref>   </t>
		  <t hangText="Routing instance"><vspace blankLines="1" /> A routing instance, 
		  in the context of the FB-FIB is a
           collection of RIBs, interfaces, and routing parameters.  A routing
           instance creates a logical slice of the router and allows different
           logical slices; across a set of routers; to communicate with each
           other.  </t>
        </list>
		</t>
    </section>
	 <section title="Yang High Level (YHL) graphical form">
  <t> The High-level Yang graphical representation uses the 
    following symbols: 
   <list>
   <t>Brackets "[" and "]" enclose list keys.
   </t>
   <t>Curly braces "{" and "}" contain names of optional features that
      make the corresponding node conditional.
   </t>
   <t>Abbreviations before data node names: "rw" means configuration
      (read-write), "ro" state data (read-only), "-x" RPC operations,
      and "-n" notifications.
   </t>
   <t>Symbols after data node names: "?" means an optional node, "!" a
      container with presence, and "*" denotes a "list" or "leaf-list".
   </t>
   <t>Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").
   </t>
   <t>Ellipsis ("...") stands for contents of subtrees that are not
      shown.
   </t>
   </list>
</t>
 </section> 
 </section> 
 <section title="Where Filter-Based RIB Fits in Global RIBs">
 <t> 		
The Top-level Yang structure for a global FB-RIB types (similar to acl) is 
not defined. The Filter-Based RIB should be defined under this structure
under a routing instance.  The two things under this RIB would be: 
configured Filter-Based RIB (aka Policy routing), I2RS reboot 
Ephemeral Filter-Based RIB.  ACLs <xref target="I-D.ietf-netmod-acl-model"></xref>
have the potential to be augmented to be included, but this version of 
this document does address that issue.  
</t>
<t>The purpose of this section is illustrate why the 
flow specification policy installed in yang modules loaded 
into intended configuration needs to be able to be compared. 
After demonstrating why this is needed, this section suggests
a structure for filter-based RIBS.  
</t>
<t>
BGP's Flow Specification (BGP-FS) configures filter-based policy in the local 
BGP configuration, and passes this information in BGP packets 
(in NLRI and Extended Communities).  The BGP-FS YANG model
 <xref target="I-D.wu-idr-flowspec-yang-cfg"></xref>
specifies the locally configuration, and the derived state that 
includes the BGP Flow Specifications received. 
BGP-FS processing may install the locally configured BGP Flow specification 
in the local FB-RIB. If it does, this policy is like any
other locally configured policy. 
</t>
<t> The BGP-FS may installed the flow policy received 
from a remote BGP peer and stored in derived 
state.  This policy has a different characteristics as it will
disappear if the peer connection between the two peers drops, 
or if the peer changes the BGP-FS policy. Due to the ephemeral 
nature of the BGP-FS, it should be installed unique. 
Otherwise, If the local configuration state changes, 
it cannot differentiate between the true configured state 
and the ephemeral states (I2RS ephemeral and BGP-session ephemeral).
Both I2RS ephemeral and BGP-session ephemeral policy will 
disappear upon a reboot.  
<figure>
<artwork>
ietf-fb-rib module 
+--rw routing-instance 
   +--rw ietf-fb-rib  
      +--rw default-instance-name string 
      +--rw default-router-id rt:router-id 
	  +--rw config-fb-rib // config state 
	     uses fb-ribs 
	  +--rw I2rs-fb-rib  // ephemeral state  
	     uses fb-ribs 
	  +--rw BGP-FB-RIB   // Install derived  
	     uses fb-ribs    // BGP-FS policy state 
		 
    Figure 6: Global FB RIB Yang Structure  
</artwork>
</figure>
</t> 
<t>I2RS architecture <xref target="I-D.ietf-i2rs-architecture"></xref>
specifies that by default the Local configuration will win 
if the local configuration changes. In the NETCONF/NETMOD 
language, the "last write wins".
</t>
<t>An example will help illustrate this: 
<list> 
<t>local configuration installs filter for
  IP-Dest=128.2/16, IP-SRC=192.5.7/24 DPORT=ALL drop 
  in the running configuration, and then synchronously 
  loads it to the intended configuration and applied configuration. 
  </t>
  <t>I2RS installs an ephemeral filter for 
    IP-Dest=128.2/16, IP-SRC=192.5.7/24 DPORT=125 forward
   intended configuration synchronously.
  </t>
  <t>BGP-FS processing installs BGP-FS policy for 
      IP-Dest=128.2/16, IP-SRC=192.5.7/24 DPORT=125 forward, 
	  traffic-rate by bytes. 
   </t>
   <t>local configuration install a filter for 
    IP-Dest=128.2/16, IP-SRC=192.5.7/24, DPort=125, drop.
	This local configuration policy would win over the 
	I2RS policy and the BGP-FS.  The I2RS process is required
	to receive an event indicating the overwrite. 
	The BGP-FS process should also receive an event indicating
	an overwrite. 
   </t>
</list>
</t>
<t>The I2RS <xref target="I-D.ietf-i2rs-architecture"></xref>
also allows that the preference between local-configuration and 
I2RS ephemeral state can be determined by operator-applied policy.
However, illustrations of this are out of scope for 
this version of this document.  
</t>
</section>
  <section title="Proposed Structure for Filter-Based RIBs">
  <t> There are three levels in the Filter-Based RIBs (FB-RIB) structure: 
 <list style="symbols">
 <t> a global FB-RIB structures,
</t>
<t>the common structure of the FB-RIB, and 
</t>
<t>the groupings that make up the FB-RIB  
</t>
</list>
</t>
<t>
 All structures have two types: configuration/ephemeral state and operational state. 
 </t>
 <t>
 This yang model describes three types of FB-RIBS: configuration, I2RS, and 
 BGP Flow Specification.  The configuration FB-RIB yang module is config state ("config true" and
"ephemeral false") and survives a reboot. The I2RS FB-RB yang model is reboot ephemeral 
("config true" and "ephemeral true").  The BGP Flow Specification Filter-Based RIB stores
policy which is received by the BGP peers, and can be considered policy configured as 
part of BGP infrastructure ("config true" and "peer-ephemeral true;")
 </t>
  <t> 
 <figure>
 <artwork> 

Configuration RIBS 

bgp-fs-fb-rib - is the BGP processes installation of 
    the BGP Flow Specification (BGP-FS) policy rules
	from remote peers. Locally configured 
	BGP-FS rules are configured in the BGP peer 
	structure. 
				
   +-----------------------------------------+
   |     routing instance                    |
   +-------|-------------|----------------|--+
           |             |                |
           |             |                |
 +---------|----+  +-----|-----+ +--------|-----+ 
 |config-fb-rib |  |i2rs-fb-rib| |bgp-fs-fb-rib |	 
 +------|-------+  +-----|------+ +------|------+
        |............:....|...............|
                     :  (uses common structures
                     :   in separate lists of FB-RIBs) 		
            +--------|----+  
            |fb-ribs*     |  
            |             |  
            +--|----------+  
               |             
       
  Figure 3: Routing instance with three types of 
            Filter-FIB lists
</artwork>
</figure>
</t> 
</section> 
<section title="Yang High Level Structure for FB-RIBs">	
 <t>
 The following section provides the high level yang structure diagrams
 for the following levels of structures for both config/ephemeral state and operationa. 
 <list style="symbols">
 <t>ietf-fb-rib - contains filter-based RIBS for config, I2RS FB-RIB, and BGP Flow Specification.</t>
 <t>fb-rib - that contains the structures for the filter-based grouping</t>
 <t>fb-rib-types - that contains the structures for groupings within the filter-based RIBS</t>
 </list> 
 These structures are contained within the yang section in this draft. 
 </t> 
 <t>
 The packet-reception ECA policy yang module is contained in the draft
 <xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref>.
 </t>
 <t> For those who desire more information regarding the logic behind the 
 I2RS Filter-Based RIB, please see the Informational Model at:
 <xref target="I-D.kini-i2rs-fb-rib-info-model"></xref>.
 </t>
<section title="Top Level Yang Structure for ietf-fb-rib">
 <t> The Top-level Yang structure for a global FB-RIB types (similar to acl) is 
not defined for filter-based RIBS.
The I2RS Filter-Based RIB should be defined under this structure
under a routing instance.  The three things under this RIB would be: 
configured Filter-Based RIB (aka Policy routing), I2RS reboot 
Ephemeral Filter-Based RIB, and BGP Flow Specification's Filter-Based RIB. 
All of these RIBs have similar actions. 
</t>
 <t>There are two types top-level structures for ietf-fb-ribs: config and operational state.
 </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>
 <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="Filter-Based RIB structures">
<t>The Top-level yang structures at the Filter-Based RIB level have
two types: configuration and operational state.
</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>
 <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> 
<section title="yang models">
	<section title="Filter-Based RIB types">
<t>
Yang model is contained in 
draft-hares-i2rs-fb-rib-data-model-01.txt
</t>
<t>
Please see this draft for the data model. 
</t>
</section>
</section>
 <section anchor="IANA" title="IANA Considerations">
      <t>TBD</t>
    </section>
  <section title="Security Considerations">
      <t>A I2RS RIB is 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:">
  	 &I-D.ietf-netmod-routing-cfg; 
	 &I-D.acee-rtgwg-yang-rib-extend;
 	 &I-D.ietf-i2rs-rib-data-model;
	 &I-D.hares-i2rs-pkt-eca-data-model;
	 &I-D.hares-i2rs-fb-rib-data-model;
	 &I-D.wu-idr-flowspec-yang-cfg;
	</references>
    <references title="Informative References">
      &RFC2119;
	 &I-D.ietf-netmod-acl-model; 
	 &I-D.kini-i2rs-fb-rib-info-model;
	 &I-D.ietf-i2rs-architecture;
     &I-D.ietf-i2rs-rib-info-model;
     &I-D.ietf-i2rs-usecase-reqs-summary;
    </references>
  </back>
</rfc>