<?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 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 RFC5511 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5511.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-usecase-reqs-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-usecase-reqs-summary.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.ietf-netmod-acl-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-acl-model.xml">
<!ENTITY I-D.dunbar-i2rs-info-model-service-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-service-topo.xml">
<!ENTITY I-D.zhdankin-idr-bgp-cfg SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhdankin-idr-bgp-cfg.xml">
<!ENTITY I-D.kini-i2rs-pbr-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-pbr-im.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf.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-i2rs-bnp-info-model-02"  ipr="trust200902">
  <front>
    <title abbrev="BNP Generic Policy/Filter IM">An Information Model for Basic Network Policy and Filter Rules </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="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>bill.wu@huawei.com</email>
      </address>
    </author>
	<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
	  <organization>Ericsson </organization>
	   <address>
	   <email>Jeff Tantsura jeff.tantsura@ericsson.com</email>
	   </address>
	 </author>
	 <author fullname="Russ White" initials="R." surname="White">
	  <organization> Ericsson </organization>
	  <address> 
	  <email>russw@riw.us</email>
	  </address>
	  </author>
    <date year="2015" />

    <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 contains the Basic Network Policy and Filters (BNP IM)
	  Information Model which provides a generic model for 
      representing an ordered list of routing policy or 
	  filter rules. Filter rules which combine match-condition 
	  with action (forwarding or sets) are supported by this policy. 
	  </t> 
    </abstract>
  </front>
  <middle>
     <section anchor="intro" title="Introduction">
      <t>This generic network policy provide a model to support
	  an ordered list of routing policy or an ordered list of filter rule. 
      An ordered list of policy can be used in protocols such as BGP.
	  An ordered list of filters can be used in filtering for routing
	  data traffic or flows.  Two examples of the ordered-based filters is
	  the I2RS Filter-based RIBS or flow specification filtering.  
	  This generic model can be used to combine filter rules such as: 
	  ACLs, Prefix-filtering, and complex filter match-actions rules (match, set, modify, set).
	  </t>
	  <t> 
	  This generic model combines rules for filter/policy into
	  groups of groups.  
      project.
	  </t>
	  <t> Antecedents to this generic policy are the generic policy
	  work done in PCIM WG. The PCIM work contains a Policy Core Information Model
      (PCIM) <xref target="RFC3060"></xref>, Policy Core Informational Model Extensions 	 
	  <xref target="RFC3460"></xref> and the Quality of Service (QoS) Policy Information
      Model (QPIM) (<xref target="RFC3644"></xref>)
	  From PCIM comes the concept that policy rules which are combined into
	  policy groups. PCIM also refined a concept of policy sets that allowed
	  the nesting and aggregation of policy groups. This generic model 
	  did not utilize the concept of sets of groups, but could be expanded to include
	  sets of gorups in the future. </t>
	  <t> 
	  Policy rules may include specific filters such as ACL or prefix filters by
	  simple reference. The following drafts provide these more specific filters; 
	  <list style="symbols">
	  <t> ACL policy <xref target="I-D.ietf-netmod-acl-model"></xref> </t> 
	  <t> BGP Prefix filter policy <xref target="I-D.zhdankin-idr-bgp-cfg"></xref></t>
	  </list> 
	  </t> 
    </section>
    <section title="Definitions and Acronyms">
      <t><list>
	      <t>BGP: Border Gateway Protocol </t> 
          <t>CLI: Command Line Interface</t>
          <t>IGP: Interior Gateway Protocol</t>
          <t>Information Model: An abstract model of a conceptual domain,
          independent of a specific implementations or data representation</t>
		  <t>INSTANCE: Routing Code often has the ability to spin up multiple 
		   copies of itself into virtual machines.  Each Routing code instance or
		   each protocol instance is denoted as Foo_INSTANCE in the text below. </t> 
		  <t>NETCONF: The Network Configuration Protocol</t>
		  <t> PCIM - Policy Core Information Model </t> 
		  <t> RESTconf - http programmatic protocol to access yang modules </t> 
        </list>
		</t>
    </section>
    <section title="Generic Route Filters/Policy Overview"> 
      <t>This generic policy model represents filter or routing policies
	  as rules and groups of rules.  
	  </t>
	  <t> 
      The basic concept are:     	  
	  <list style="hanging">
          <t hangText="Rule Group"><vspace blankLines="1" /> A rule group is
		  is an ordered set of rules . </t>
		  		  
		  <t hangText="Rule"><vspace blankLines="1" /> 
		  A Rule is represented by the semantics “If Condition then Action”.
		  A Rule may have a priority assigned to it. 
		  </t> 
	</list> 
	</t> 
	 <t> 
    <figure>
        <artwork>
 
	+-----------+     +------------+		
	|Rule Group |     | Rule Group |
    +-----------+     +------------+					
       	 ^                  ^                +----------------+
         |                  |             ---| ACL Rules      |
         |                  |             |  |   Additions    |
         |                  |             |  +----------------+
         |                  |             |  +----------------+
+--------^-------+   +-------^-------+    |--|Prefix  Rule    |
|      Rule      |   |     Rule      |&lt;----|  Additions    |
+----------------+   +---------------+    |  +----------------+
                       :          :       |      . . .
                       :          :       |  +----------------+
                 ......:          :.....  ---|Other Rules     |
                 :                     :     | Additions      |
                 :                     :     +----------------+
                 :                     :
       +---------V---------+         +-V-------------+
       |  Rule Condition   |         |  Rule Action  |
       +-------------------+         +---------------+
           :     :    :                 :     :    :
      .....:     .    :.....       .....:     .    :.....
      :          :         :       :          :         :
 +----V---+  +---V----+ +--V---+ +-V------++--V-----++--V---+
 |  Match |  | match  | |match | | Action || action ||action|
 |Operator|  |Variable| |Value | |Operator||Variable|| Value|
 +--------+  +--------+ +------+ +--------++--------++------+

           Figure 1: BNP structure
		</artwork>
      </figure>
	  </t> 
    </section> 
      <section title="BNP Rule Groups "> 
      <t> Rule groups have the following elements: 
		<list style="symbols"> 
		<t> name that identifies the grouping of policy rules</t>
		<t> role - that is a combination of target resource (E.g. IPv4 FB-FIB filters) and a scope 
	  (read, read-write, write-only).  </t>
		<t> list of rules </t> 
	    </list>
	  </t>
	  <t> The rule has the following elements: name, order, status, priority, reference cnt, and  
	  match-action as shown as shown in figure 2. The order indicates the order of the rule within the 
      list. The status of the rule is (active, inactive). The priority is the priority within
	  a specific order of policy/filter rules. A reference count (refcnt) indicates the number of entities 
	  (E.g. network modules) using this policy. The generic rule match-action conditions have match
	  operator, a match variable and a match value.  The rule actions have an action operator, 
	  action variable, and an action value.  
      </t>
	  <t> 
	  The generic rules can be included with other types of rules as figure 2 shows. 
      </t>
	  <t>
     <figure>
          <artwork>
                  Figure 2 - Rule Group 
     +-------------------------------------+ (optional) 
     |             Rule Group              |....
     +--------------------------------------+   :
       *      *                   *        ^    :
       |      |                   |        :....:
       |      |                   |        
       |      |                   |        
  +------+ +-----+   +-------------------+
  | Name | |Role |   |     Rule_list     |
  |      | |     |   |                   |
  +------+ +-----+   +------|------------+
            *   *    +------|-----------+
            |   |    |   rule           |
            |   |    +--|---------------+			
            |   |       |                     
         +--+   |       | +----------+   
         |       |-|   Name   |      
         |      |       | +----------+      
    +----+---+ ++----+  | +----------+
    |Resource  |Scope|  | | + Rule   |
    +--------+ +-----+  |-| order    |
                        | +----------+   
                        | +----------+ 
                        |-| Status   |
                        | +----------+
                        | +----------+				
                        |-| priority |  
                        | +----------+   
                        | +----------+   
                        |-| refcnt   |
                        | +----------+ 
                        | +--------------+
                        |-|    Rule      |
                          | match/action |					   
                          +-----|--------+
                                |
       +----|--------------|----|-----------+	
            |              |	            | 
    +-------|-------+ +----|---------+ +----|---------+  . . . 
    |  bnp generic  | | Access rule  | | Prefix-list  | 
    |  match/action | | match/action | | rule         |				   
    +---------------+ +--------------+ +--------------+
					 
      </artwork>
        </figure>
       </t>
	   <t> The conditions in one rule may cause actions to 
	   set values (E.g. BGP communities) that are examined
	   in a second rule as shown in figure 3. 
	   <figure>
       <artwork>
		  
		  Figure 3 - Rule's match-condition

            +----------------+
            |     Rule       |
            | Match/action   |  
            +----------------+    
              *           *   
              |           |   
              |           |
     +---------+        +--------+
 ...&gt;|Condition|&lt;.......| Action |&lt;...
 :   +---------+&lt;.......+--------+   :
 :    :   *                *    :    :
 :.....   |                :    :... :
          |                :
     +--------+...........:
     |Operator|
     +--------+
		</artwork>
        </figure>
        </t>
	<t> The generic match conditions are specific to a particular layer 
     are refined by matches to a specific layer (as figure 4 shows), and 
	 figure 5's high-level yang defines. The general actions may be 
	 generic actions that are specific to a particular layer (L1, L2, L3, service layer) or
     general forwarding by interface or nexthop.
     The high-level yang diagram for the matches in figure 5. 
     </t>
	 <t> 
	   <figure>
	   <artwork>
	   Figure 4 
                 +-------------+
                 |  Match      |
                 |  Condition  |
                 +-------|-----+
                         |
         +-------------+-|-----------+-----------+
         |             |             |           |
         V             V             V           V
   ............  ............  ............ ...........
   :    L1    :  :    L2    :  :    L3    : : Service :  
   :  match   :  :   match  :  :   match  : : match   :
   ''''''''''''  ''''''''''''  '''''''''''' '''''''''''
   </artwork>
   </figure>
   </t>
   </section>
   <section title="BNP Generic Info Model in High Level Yang">
   <t>
   Below is the high level yang diagram for the    
   <figure> 
   <artwork> 
   Figure 5 
	module:bnp-generic-rules
	  import ietf-acl 
	  import ietf-interface
	  +-rw rule-group* [group-name]
	    +--rw group-name
	    +--rw group-scope
	    |  +--resource  tree-identity 
	    |  +--access    access-identity
        +--rw group-installer install-identity		
        +--rw rule*  [rule-name]
           +--rw rule-name string
           +--rw order unit16
		   +--rw installer 
           +--rw status enumeration
           |  +--ro rules-status
           |  +--ro rule-inactive-reason
           |  +--ro rule-installer 		   
           +--rw priority unit16
           +--rw refcnt unit16 
           +--rw rule-match-act
              +--rw match-act-type match-act-type-identity 
                 +--case: BNP-GENERIC-MATCH-ACTION
                 |  +--rw bnp-term-match 
                 |  |  +--case: interface-match
                 |  |  +--case: L1-header-match 
                 |  |  +--case: L2-header-match
                 |  |  +--case: L3-header-match
                 |  |  +--case: L4-header-match
                 |  |  +--case: Service-header-match
                 |  +--rw bnp-action 
                 |  |  +--rw genric-actions [nbr-act]
                 |  |  |  +--rw n-acts
                 |  |  |  +--rw qos-action
                 |  |  |  |  +--case L1-action
                 |  |  |  |  +--case L2-action
                 |  |  |  |  +--case L3-action
                 |  |  |  |  +--case L4-action
                 |  |  |  |  +--case service-action
    	         |  +--rw bnp-forward 
                 |  |  +--rw forward
                 |  |  |  +--rw interface interface-ref
                 |  |  |  +--rw next-hop  rib-nexthop-ref
                 |  |  |  +--rw route-attributes
                 |  |  |  +--rw rib-route-attributes-ref 				 
                 |  |  +--rw fb-std-drop
                 +--case: ACL-MATCH-ACTION     
                    +--rw acl-match-act acl-list-entry-name
	  </artwork>
	  </figure>
	  </t> 
	 </section>
	  <section title="Example of use in filters  "> 
	<t>
	The following is an example is an example structure for the rrule  match-condition
	applied to Filter-Based RIB containing a list of routes </t>
	<t> 
	<figure> 
	<artwork> 
	figure 6
   module: FB-RIB
    +--rw FB-RIB-instance-name 
    +--rw RB-RIB-router-id  uint32
	   +--rw FB-RIB-interface* 
	   |  +--rw FB-RIB-interface interface-ref-id
	   +--rw FB-Default-RIB rib-ref 
       +--rw FB-RIB
	      +--rw FB-RIB-Name
	  	  +--rw FB-RIB-AFI
		  +--rw FB-RIB-intf* 
		  +--rw FB-FIB-status-info
		  |  +--rw fb-rib-update-ref uint64
		  +--rw FB-RIB-Ordered-Filters  rule-group-list-ref
	         uses /nt:bnp-generic-rules 
		
	rule-group-list-ref points to rule-group-list 
      		
   </artwork>
   </figure>
  </t>    
    </section> 
    <section anchor="IANA" title="IANA Considerations">
      <t>This draft includes no request to IANA.</t>
    </section>
    <section title="Security Considerations">
      <t>These generic filters are 
      used in the I2RS FB-RIBs to filter packets in a traffic stream, 
	  act to modify packets, and forward data packets.  These I2RS filters 
	  operate dynamically at same level as currently deployed configured
	  filter-based RIBs to filter, change, and forward traffic. 
	  The dynamic nature of this protocol requires that I2RS Filters
	  track the installer of group information and rules. 
	  </t> 
	  <t> This section will be augmented after a discussion
	  with security experts.
	  </t> 
    </section>
  </middle>
  <back>
    <references title="Informative References">
      &RFC2119;
      &RFC3060;
	  &RFC3460;
      &RFC3644;
      &RFC5511;
      &I-D.ietf-i2rs-architecture;
      &I-D.ietf-i2rs-rib-info-model;
      &I-D.ietf-i2rs-usecase-reqs-summary; 
	  &I-D.ietf-netmod-acl-model; 
	  &I-D.ietf-netconf-restconf;
	  &I-D.zhdankin-idr-bgp-cfg; 
    </references>
  </back>
</rfc>
