﻿<?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 RFC3644 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3644.xml">
<!ENTITY RFC5394 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5394.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.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-pce-stateful-pce SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-stateful-pce.xml">
<!ENTITY I-D.white-i2rs-use-case SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.white-i2rs-use-case.xml">
<!ENTITY I-D.keyupate-i2rs-bgp-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.keyupate-i2rs-bgp-usecases.xml">
<!ENTITY I-D.hares-i2rs-info-model-policy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-policy.xml">
<!ENTITY I-D.ji-i2rs-usecases-ccne-service SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ji-i2rs-usecases-ccne-service.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-im-read-info-policy-00"
     ipr="trust200902">
  
 
  <front>
    
<title abbrev="IM for policy">An Information Model for I2RS Reading Information Policy</title>
     <author fullname="Susan Hares" initials="S" surname="Hares">
      <organization>Hickory Hill Consulting</organization>
      <address>
        <postal>
          <street>7453 Hickory Hill</street>
          <!-- Reorder these if your country does things differently -->
          <city>Saline</city>
          <region>CA</region>
          <code>48176</code>
          <country>USA</country>
        </postal>
        <email>shares@ndzh.com</email>
        <!-- uri and facsimile elements may also be added -->
      </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>sunseawq@huawei.com</email>
      </address>
</author>
<date year="2014" />
   <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> The Interface to the routing system (I2RS) specifies a
    new interface that a client (I2RS client) can utilize
	to interface to the routing system. Some applications 
	that utilize the services of I2RS client may require a specific set
	of data in response to network events or conditions based on 
	pre-established rules. In order to reduce the data flow through the network,
	the I2RS client needs to signal the I2RS agent to filter some of the
	collected data or events prior to transmission to the i2rs client. 
	This functionality is necessary to meet the 
    requirements I2RS enabled services which include service-layer routing
    improvements, and control of traffic flows and exit points.  
    </t>     
	 <t>This document introduces a read-only I2RS RIB policy 
      Informational Model that provides filters for
	  the reads and notifications from the I2RS RIB Info Model (IM). 
	  This model utilizes a generic information model (IM) for
      policy templates that is extensible and hierarchical.
	  These templates support the features described by the 
	  I2RS architectural model.  
   </t>
   
</abstract>
</front>
<middle>
    
<section anchor="intro" title="Introduction">
   <t>The Interface to the Routing System (I2RS) [<xref target="I-D.ietf-i2rs-architecture" />] 
   provides read and write access to the information and state within the
    routing process within routing elements. The I2RS client
    interacts with one or more I2RS agents to collect information
    from network routing systems. One set of protocol independent
	use cases that the I2RS interface be used in are
	described in <xref target="I-D.white-i2rs-use-case" /> Protocol 
	Independent Use Case for the Interface.  
	These scenarios suggest that require I2RS interfaces to be able to:
	<list style="symbols"> 
	<t> monitor available routes installed based on the routes
        installed in a RIB for a routing instance associated with 
	    forwarding device at a near real-time rate</t> 
     <t>interact with various policies configured on the
          forwarding devices, in order to inform the policies implemented by
          the dynamic routing processes. </t>
     <t>interact with traffic flow and other network
        traffic level measurement protocols and systems, in order to
        determine path performance, top talkers, and other information
        required to make an informed path decision based on locally
        configured policy.</t>
	</list> 
	</t>
    <t> Processing of collected information at the I2RS agent 
       may require the I2RS Agent to filter certain information
       or group pieces of information in order to reduce the data 
       flow through the network to the I2RS client.
	   Some applications utilizing the services of an I2RS client
       may also wish to require specific data in response to network
       events or conditions based on pre-established policy rules.  
	   For example if the traffic flow measured by network devices
	   exceeds some limit, then the I2RS client may wish to query for
	   all routes with some match pattern.  This will allow 
	   service-layer routing improvements, and control of 
       traffic flows and exit points.   
   </t>
   <t> This document introduces an information model (IM) for filtering 
       policies enacted at I2RS agent before transmitting data to
	   the I2RS client. The <xref target="I-D.ietf-i2rs-architecture" /> 
	   suggests that associated with the I2RS RIB model there will be 
	   "Policy-based Routing (ACLs)" and RIB "policy controls". 
	   This policy model utilizes the generic policy model found in 
	   <xref target="I-D.hares-i2rs-info-model-policy" /> and operates on the
	   I2RS RIB information module <xref target="I-D.ietf-i2rs-rib-info-model" />.
	   The use of a generic policy model allows the creation of 
	   named templates for reading or writing to the I2RS RIB module
	   that have three levels of structure (policy group, network policy, and
	   Local elements of policy).  The local elements of policy operate in the
	   monitoring stage as read functionality and as filters for the I2RS agent
	   transmission of data to the I2RS client.
	</t>   
	   <t>Reading information via I2RS from the BGP protocol regarding 
	   BGP routes, BGP protocol events, and BGP protocol statistics
	   may also be needed to filter the information an I2RS agent 
	   sends to an I2RS client.  The <xref target="I-D.keyupate-i2rs-bgp-usecases" /> provides a
	   use case for BGP monitoring in section 5 where it indicates
	   it is important to monitor prefixes of "high visibility" end-users for 
	   the announcement or withdraw of prefixes, the suppression of 
	   prefix announcements (due to flap damping), and alternate best path selections.
	   It is also important to trace dropped routes, and statistics per EBGP session. 
	   These BGP prefixes may need to be tracked both at the BGP and at the
	   active RIB level. The read policy described here for use 
	   by the I2RS agent for the RIB Information can be extended
	   to support the read filtering for BGP. 
  	   </t> 
	   <t>Policy about what I2RS can read from the RIB is contained in the following: 
    <list style="hanging">   
    <t hangText="Read Policy Group"><vspace blankLines="1" />Policy is
        described by a set of policy rules that may be grouped into subsets.
		The read policy group provides model context (or scope) for the 
		Policy rules within it. The model context has an identity, scope, role,
        precedence, priority and security model. In a policy group, policy
		rules and policy groups can be nested within other policy rules.</t>
     <t hangText="Network-Policy"><vspace blankLines="1" />contains a
          coherent set of rules to administer, manage, and control access 
		  between the I2RS client and the I2RS Agent. </t>
     <t hangText="Local Config "><vspace blankLines="1" />defines
          individual rules kept in the I2RS agent that are utilized to filter
		  data sent to the I2RS client. The filters associated
          with the I2RS RIB Model, will include filters on the RIB Info model 
		  including: routing instance ID, RIB ID, 
		  route attributes, route, next-hop list, installation in FIB, Active in RIB, 
		  and unresolved. </t>
     </list>
     </t>
</section> 
<section title="Reading of Network Policy Information">
<t> This section provides an overview of the Network 
    Policy information model. The next section contains an example of
    the RIB Filtering model. </t> 
<t></t> 
<t>I2RS client requesting filtered data from the I2RS agent 
	sets the policy into a Network Policy list for Read Filtering.  
	This policy list is created as a set of policy sets that 
	contain a policy group with its associated policy rules. 
	These policy rules are saved in the I2RS Agent's local store.</t>
	<t> 
	If the I2RS Agent fails, then these policy rules must be
	instantiated by the I2RS Client.  The templates for the
	I2RS Agent may be part of the generic templates stored 
    within the routing system and uploaded by name
	by the I2RS client. This would provide easy of maintenance
	for systems with these policy templates.  However, 
	this is not a requirement for the proper function 
	of this Read Filtering Policy model. 
     </t>
	<t> Below is a diagram of the Read Filtering policy model. 
	</t> 
<figure>       
<artwork>
 
      +-------------------------+  
	  |    Read Filtering       |	  
      |    Policy for 		    | 
  	  |    I2RS Agent           |
      |    Policy Set           |
      |                         |
      +--+-------------------+--+
         ^                   ^
        /|\                 /|\  (sequence of) 
         | "extends"        | "extends"
+--------^-------+   +-------^-------+     +------------+
|
| Policy Group   |   | Policy Rule   |&lt;---|Local Policy|
| 
+----------------+   +---------------+     +------------+
                       :          :
                 ......:          :.....
                 :                     :
                 :                     :
       +---------V---------+         +-V-------------+
       |  Policy Condition |         | Policy Action |
       +-------------------+         +---------------+
           :     :    :                 :     :    :
      .....:     .    :.....       .....:     .    :.....
      :          :         :       :          :         :
 +----V---+  +---V----+ +--V---+ +-V------++--V-----++--V---+
 |  Match |  |Policy  | |Policy| |  Set   || Policy ||Policy|
 |Operator|  |Variable| |Value | |Operator||Variable|| Value|
 +--------+  +--------+ +------+ +--------++--------++------+

           Figure 1: Overall model structure

</artwork>     
</figure>
<t><list style="hanging">
	<t hangText="Policy set for Read Filtering Policy for I2RS agent"><vspace blankLines="1"/> It is 
	a policy set that describes all filtering that the 
		I2RS Agent does prior to sending data to the I2RS Client.  
        This policy set contains a set policy groups with their associated policy rules
		and an indication whether this will be stored locally at the 
		I2RS Agent. </t>
	<t hangText="Policy Group"><vspace blankLines="1" /> The policy group is a policy set
      	which links to a set of policy rules, and contains an identity, scope,
		role, precedence, priority and security model. </t>
	<t hangText="Policy Rule"><vspace blankLines="1" />  The policy rules are a set
        of policies in which each policy is defined as: 
		"&lt; policy variable&gt; matches value" where the result of the match
		can be a set operator of "SET policy variable TO value". </t> 
</list></t> 
<t> Policy Groups can include other policy groups. This aids in building 
up the policy set as logical components.  Operational groups can utilize
this to map the policy groups to actual operational service policies. 
In a similar fashion, policy sets could contain other policy sets. 
</t> 
</section>
<section title="Example of Use of Read Filter Policy Information Model">
 <t> This section provides an example of the Read Filter Policy Information model. 
 The example is taken from the protocol independent use cases 
	use cases this I2RS architecture can be used in are
	described in <xref target="I-D.white-i2rs-use-case" /> Protocol 
	Independent Use Case for the Interface which contains the following examples:
	<list style="symbols"> 
	<t> Distributed reaction to Network Based Attacks </t>
	<t> Remote Service Routing </t> 
	<t> Within Data Center Routing </t>
    <t> Temporary overlays between Data Centers </t>
    </list>
 The specific read monitoring filtering policy is proposed for
 each use case.</t>
<section title="Read Filtering for Distributed Reaction to Network Based Attacks">
<t> scenario: </t> 
<figure align="center" alt="" height="" suppress-title="false" title="" width="">
<artwork align="center" alt="" height="" name="" type="" width=""
                 xml:space="preserve"><![CDATA[
        +----------+
	    |i2rs-client|-------------------
		|           |-----------+      |
        -----------+            |      |
				 |           +------+  |
				 |           | ir2s |  |
				 |   	     | agent|  |
Valid Source--\  |       /---|R2    |-------+\
               +-------+/    +------+  |       \
               |R1 i2rs|               |    R3--Valid
			   |  agent|               |    Destination
			   +-------+        i2rs agent
Attack Source--/     \--Monitoring Device-----/]]>
              
	Figure 2 - Distributed reaction to Network Attacks </artwork>
</figure> 
<t> Description: </t> 
<t> In the scenario of the of the Distributed Reactions, an I2RS client is attached
to the routing functions on a two network devices (R1 and R2), and a network monitoring
device (see figure 2). The routing device R1 has external ports upon which both valid sources
and (upon attack) invalid sources may send data. The I2RS client is learning 
attack prefixes from the monitoring devices which are processing samples of the traffic.
A set of suspected prefixes are collected by the I2RS client from 
the monitoring devices. The I2RS Client uses these prefixes to control 
the attack mitigation reading and writing RIB policy.  </t>
<t> 
Currently, the <xref target="I-D.ietf-i2rs-rib-info-model" />  
only includes a "route change notification" or "next-hop resolution".
Neither of these change notifications directly imply listening to a stream of the
data below, but should. This draft is focused on the READ filters
installed for the stream of notifications suggested by the 
<xref target="I-D.ietf-i2rs-architecture" /> </t>
<t> The I2RS Client sends command to the I2RS agent in R1 and R2
to request event notification of route changes for any 
destination routes matching (exact or longer) prefixes 
which begin with 129.10/16 or 192.169/16.     
The I2RS Client sends notification filter policies to the I2RS Agents at
R1 and R2 to collect with the notification: the routing instance,
the RIB, the Route(route-attributes, route-match, and next-hop list) for
the watched prefixes. The I2RS Client also sends commands to the forwarding
function of R1, R2, and the monitoring device to 
provide traffic statistics regarding the number of prefixes received with these
routes beginning with the prefix 129.10/16 (match or longer), and 192.169/16 (match or longer). 
</t> 
<t> The Read Filter policy is instantiated at R1 and R2 in order to filter 
just the routes necessary to track. Previous attack patterns have seen 
192.169.10/24 or longer prefixes used to during the attack. A special
detailed receive policy is also set-up to prepare for these attacks.  </t>
<t> The policy filtering matches security attack vector named 
"red dog 1" so the operator decides to give this policy set 
an identity of "red dog 1" with a scope of read, 
a role of security monitoring, a precedence of 1, a priority of 1, and a 
security model of secure TCP. The network prefix 129.10/16 (exact or longer) is identified as red-net,
and the prefix 192.169/16 (exact or longer) is weak-red-net. 
The 192.169.10/24 is identified as weak-red-watch. 
</t> 
<t> The Read filters sent for the states are include filters 
for the traffic statistics per interface (Eg. exterior interface
to network, attack source, and R1-R2 Interface). </t> 
<t> 
The following diagram provides the filters for the first policy.  
The policy filtering matches attack vector "red dog 1" so the operator decides
to give this policy set an identity of "red dog 1" with a scope of read, 
a role of security monitoring, a precedence of 1, a priority of 1, and a 
security model of secure TCP. </t>
<figure>       
<artwork>
      +-------------------------+  
	  |  Read Filtering         |	  
      |  Policy for I2RS Agent  | 
      |  Policy Set for         |
      |  Attack filters         |
      +--+-----------------+----+
         ^ [1..N]          ^  [1..N]
        /|\               /|\ ------------------------------------+
         | "extends"       |-----------------+                    |
         |                 |                 | 		              |
+--------^-----+   +-------^-------+   +-----+---------+  +-------+------+
| Policy Group |   | Policy Rule 1 |   | Policy Rule 2 |  |Policy Rule 3 |  ....
| Red Dog 1    |   | red-net       |   | weak-red-net  |  |weak-red-watch|
+--------------+   +---------------+   +---------------+  +--------------+
                       :          :
                 ......:          :.....
                 :                     :
                 :                     :
       +---------V---------+         +-V-------------+
       |  Policy Condition |         | Policy Action |
       +-------------------+         +---------------+
           :     :    :                  :     :    :
      .....:     .    :.....        .....:     .    :.....
      :          :         :        :          :         :
 +----V---+  +---V----+ +--V---+  +-V------++--V-----++--V---+
 |  Match |  |Policy  | |Policy|  |  Set   || Policy ||Policy|
 |Operator|  |Variable| |Value |  |Operator||Variable|| Value|
 +--------+  +--------+ +------+  +--------++--------++------+
  IP-ADDRESS- Destination                    Send
  AS-RESOLVED Address    129.10/16  Set      Route 	    yes 
  -BY-DNS                                    info        
  
           Figure 3: Example of read statistics filter 
</artwork>
</figure>
<t> The following is the Read Filtering Policy Set 1</t> 
<t><list style="hanging">
<t hangText="Policy Group"> <vspace blankLines="1" /> The policy group
        has an identity of "red dog 1", and a scope of "read",
		role: "security monitor", precedence of 1, priority of 1, and
		security model of "secure TCP". </t>
<t hangText="Policy Rule 1"><vspace blankLines="1" /> The policy rule 1
		has an identity of "red-net".  The policy condition is:
		has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY-DNS", 
		a policy variable of "Destination Address", and a policy value 
		of 129.10/16. The Policy actions associated with Policy Rule 1
		indicates a "SET" operator for the forwarding of any 
		route matching 129.10/16 prefix with exact
		match or longer match, and an ACTION of "notify
        I2RS Client".	</t>
<t hangText="Policy Rule 2"><vspace blankLines="1" /> The policy rule 2
		has an identity of "weak-red-net".  The policy condition is:
		has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY-DNS", 
		a policy variable of "Destination Address", and a policy value 
		of 192.169/16. The Policy actions associated with Policy Rule 2
		indicates a "SET" operator for the forwarding of any 
		route matching 129.10/16 prefix with exact
		match or longer match, and an ACTION of "notify
        I2RS Client". </t>
<t hangText="Policy Rule 3"><vspace blankLines="1" /> The policy rule 3
		has an identity of "weak-red-watch".  The policy condition is:
		has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY-DNS", 
		a policy variable of "Destination Address", and a policy value 
		of 192.168.10/24. The Policy actions associated with Policy Rule 3
		indicates a "SET" operator for the sending of forwarding 
		statistics on any data packet matching 192.168.10/24 prefix with exact
		match or longer match, and an ACTION of "notify
        I2RS Client.</t>
<t hangText="Policy Rule 4"><vspace blankLines="1" /> The policy rule 4
		has an identity of "red-net stats".  The policy condition is:
		has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY-DNS", 
		a policy variable of "Destination Address", and a policy value 
		of 129.10/16. The Policy actions associated with Policy Rule 4
		indicates a "SET" operator for the sending of forwarding 
		statistics on any data packet matching 129.10/16 prefix with exact
		match or longer match from designated interfaces, and an 
		and an ACTION of "notify I2RS Client".</t>	
<t hangText="Policy Rule 5"><vspace blankLines="1" /> The policy rule 5
		has an identity of "weak-red-net stats".  The policy condition is:
		has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY-DNS", 
		a policy variable of "Destination Address", and a policy value 
		of 192.169/16. The Policy actions associated with Policy Rule 5
		indicates a "SET" operator for the sending of forwarding 
		statistics on any data packet matching 192.169/16 prefix with exact
		match or longer match from designated interfaces,  
		and an ACTION of "notify I2RS Client" </t>	
<t hangText="Policy Rule 6"><vspace blankLines="1" /> The policy rule 6
		has an identity of "weak-red-net stats".  The policy condition is:
		has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY-DNS", 
		a policy variable of "Destination Address", and a policy value 
		of 192.169.10/24. The Policy actions associated with Policy Rule 6
		indicates a "SET" operator for the sending of forwarding 
		statistics on any data packet matching 192.169/16 prefix with exact
		match or longer match from designated interfaces,  
		and an ACTION of "notify I2RS Client" </t>	
</list></t> 
<t>Read Policy List </t> 
<t> The read policy list has the summary structure below.
   All Structures underneath the filter policies can utilize template
   from the three layer generic policy model found in 
	   <xref target="I-D.hares-i2rs-info-model-policy" />.     
    Note that policy groups can be included in 
	policy groups.</t>
<figure>       
<artwork>
        read filter-policies
      0...N |            
	      policy set
            |------------------------|
	 |---policy group [1-N]       policy rules [1-N]-- status 
	 |----|	 |                   |         |             |
			 |                   |         |             | 
	+-------+----+-------+       policy   policy   enabled/disable	
	|       |	 |       | 	     condition Action  mandatory/optional
 Identity role  priority precedence
           |
     +----------+
     |          |
   resource    scope 
               (read / write) 
               (event)  

           Figure 5 - read filter policies 			   
</artwork>
</figure> 
</section> 
<section title="Remote Service Monitoring">
<t> scenario: </t>
<figure>
<artwork>
            +---------------------+
			|  APP or Controller  |
			+---------------------+
			     |
				 | 
			  +----------------+
			 /  Centralized     \    
			+   Route server     + 
			----------------------
            |      hub    (F)    |
		    |      192.50.128/24 *---------+
 			+--*----*---*------*-+         |
		    |  |    |   |      |           |
	        +--*--+ | +-*--+  +*----+      |
 source 1---|  A  |---|  C |--|  E  |----  |
	 \     /+--+--+ | +----+  +-----+      |
	   \  /    |    |    |                 |
	    \/     |    |    |                 |
        /\  +-----+ |   +-----+*-----------+   
 source 2 \ |  B  *-|   |  D  |                 
           \|     |-----|     |-----
	        +-----+     +-----+
			
	 *- are BGP RR connections
	 |- are hub/spoke connects 
	 spokes:  A,B,C,D,E nodes
	 hub: F node 
	 
	 
</artwork>
</figure> 
    <t> The second use case mentioned in <xref target="I-D.white-i2rs-use-case" />
	is an improvement of the hub and spoke overlay networks.  Current hub and
	spoke networks balance between information held in the spoke table and
	optimized routing in the overlay, and mobility of nodes.
	Most solutions in this space use some form of centralized route server
	which keeps all routes (reachable destination and next hops), and
	has a protocol by which the route-server and spoke devices communicate, and 
	caches at remote site. <xref target="I-D.white-i2rs-use-case" /> suggests
	that I2RS can provide an alternative control plane by allowing 
	remote sites to register (or transmit through BGP) the reachable destinations
	at each site, along with the router within the forwarding path. </t>
	<t> The <xref target="I-D.ji-i2rs-usecases-ccne-service" /> also provides a more 
	detailed discussion of the centralized control element that supports
	using I2rs plus BGP Route-Reflectors (RR), I2RS plus MPLS-TE and PCE (RFC4655),
	(both stateless and stateful <xref target="I-D.ietf-pce-stateful-pce" />). </t>
	<t> For both use cases, the read filtering allows the centralized server to obtain 
	 notification of route changes (installed, active, who) 
	and next-hop resolution per  <xref target="I-D.ietf-i2rs-rib-info-model" />
    for a particular range of addresses.  In addition, interface
	failures will impact the possible route calculated at the hub.  
	A notification stream watching interfaces and nexthop changes
	can be tailored to watch the interfaces for the main traffic path and
	backup paths.</t>
	<t> </t> 
	<t> Example Read Filters </t>
	<t> Across the "*--*" links the hub passes the I2RS and BGP protocol
		packets. Also across these links passes the the traffic forwarded
		to the hub, and then forward to the correct destination. 
		</t>
	<t> The route server sets policy group CCNE-2 to look for address changes in 
		forwarding pathway routes in address range 192.50.128/18(match or longer), 
		nexthop changes on 192.150.150/24, interface failures in 192.150.160/24, 
		and failures for Route installs. Policy is name CCNE-2.
        </t> 	
<t><list style="hanging">
<t hangText="Policy Group"> <vspace blankLines="1" /> The policy group has an identity of "CCNE-2", 
		and a scope of "read", role: "route-server", precedence of 2, priority of 1, and
		security model of "secure TCP". </t>
<t hangText="Policy Rule 1"><vspace blankLines="1" /> The policy rule 1
		has an identity of "hub-net".  The policy condition is:
		has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY-DNS", 
		a policy variable of "Destination Address", and a policy value 
		of 192.50.128/18. The Policy actions associated with Policy Rule 1
		indicates a "SET" operator for any route matching 128 prefix with exact
		match or longer match, and an ACTION of "notify I2RS Client"</t>
<t hangText="Policy Rule 2"><vspace blankLines="1" /> The policy rule 2
		has an identity of "CCNE NextHops".  The policy condition is:
		has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY-DNS", 
		a policy variable of "NextHop Address", and a policy value 
		of 192.168.150/24, and a SET Operator of "prefix-match", 
		and an ACTION of "notify I2RS Client". 	</t>
<t hangText="Policy Rule 3"><vspace blankLines="1" /> The policy rule 3
		has an identity of "CCNE Interfaces".  The policy condition is:
		has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY-DNS", 
		a policy variable of "interface address", and a policy value 
		of 192.150.150/24, and status = "down". The Policy actions
		associated with policy rule 3 indicates a "SET" for
		match or longer, and "ACTION" is "notify I2RS Client".</t>
<t hangText="Policy Rule 4"><vspace blankLines="1" /> The policy rule 4
		has an identity of "CCNE Install Watch".  The policy condition is:
		has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY-DNS", 
		a policy variable of "Routes", and a policy value 
		of 192.150.128/18, Notification Status is "Route Change 
		notification Return Code "No", and policy actions
		indicate "SET" for match or longer, and
		"ACTION" is "notify I2RS Client".</t>
</list></t> 
<t> The following additions to the RIB Info model 
	are needed to support this use case  </t>
<t><list style="symbols">
<t>Notification for interface change </t>
<t>Notification for Route change </t> 
<t>Notification for NextHop change </t> 
</list> </t> 
</section> 
<section title="Within Data Center Routing">
<t> scenario: TBD </t> 
</section> 
<section title="Temporary overlays between Data Centers">
<t> scenario: TBD </t> 
</section> 
</section> 
<section title="Read Filter Policy Information Model">
 <t> This section specifies the network policy information model in
      Routing Backus-Naur Form (RBNF, <xref target="RFC5511" />). 
    The policy definitions utilize the generic information
	model for policy. The RBNF form below is split into two
	parts: specific read filter policies, and
	a reference section for the generic information model 
	(<xref target="I-D.hares-i2rs-info-model-policy" />) </t> 
<section title="Read Filter Policies"> 
<figure> 
<artwork>
   &lt;Read-Filter-Policies&gt; ::=  [&lt;Policy-Set&gt;]
   &lt;Policy-Set&gt; ::=[&lt;Policy-Group&gt;]
</artwork> 
</figure> 
</section> 
<section title="Generic Informational Model Templates"> 
<t> This section provides the RBNF definitions from 
	utilized from the generic information model 
	(<xref target="I-D.hares-i2rs-info-model-policy" />).
	This section is informational and will be 
	removed once referencing issues to the
	generic model have been resolved. </t>
<figure>
<artwork> 
  &lt;PolicyGroup&gt; ::= &lt;Identity&gt;
				    &lt;Role&gt;
                    &lt;priority&gt;
                    &lt;precedence&gt;
                    &lt;Policy-Rule&gt;
                    [&lt;Supporting-Policy-Group&gt;]
                    [&lt;Policy-Group-Extension&gt;]
					
  &lt;Scope&gt; ::= &lt;Read-Scope&gt;
              |&lt;Write-Scope&gt;
 
 &lt;Role&gt; ::= &lt;Resource&gt; 
             | &lt;Scope&gt;

			 &lt;Policy-Group-Extension&gt; ::= &lt;&gt; 
                                       ...
									   
  &lt;network-policy-rule&gt; ::= (&lt;policy-rule&gt;...)
  
  
  &lt;policy-rule&gt; ::= &lt;Identity&gt;
                    &lt;priority&gt;
                    &lt;precedence&gt;
                    &lt;Role&gt;
                    (&lt;Condition&gt;
                    (&lt;Action&gt;...)  
                    &lt;Security-Model&gt;
                    [&lt;policy-rule-extension&gt;]	
					
  &lt;Scope&gt; ::= (&lt;Read&gt; [&lt;read-scope&gt;]) |
                   (&lt;Write&gt; [&lt;write-scope&gt;])
				   (&lt;Notification&gt; [&lt;notification-scope&gt;])
				   
  &lt;Role&gt; ::= &lt;Resource&gt; | &lt;Scope&gt;
  
  &lt;Security-Model&gt; ::= &lt;First-Matching&gt;|&lt;All-Matching&gt;
 
 &lt;policy-rule-extension&gt; ::= &lt;i2rs-policy-extension&gt; |
                               ...
  &lt;condition&gt; ::= &lt;variable&gt;      
                       (&lt;value&gt;...)
                       [&lt;Match-Operator&gt;]
                       [&lt;condition-extension&gt;]
					   
  &lt;Match-Operator&gt; ::= &lt;IS-SET-MEMBER'&gt;    
                     |&lt;IN-INTEGER-RANGE&gt;
                     |&lt;IP-ADDRESS-AS-RESOLVED-BY-DNS&gt;        
                     |&lt;Match-Operator-extension&gt;
					 
  &lt;condition-extension&gt; ::= &lt;i2rs-condition-extension&gt; | 
                              ...
  &lt;action&gt; ::= &lt;variable&gt;       
                     &lt;value&gt;
                     &lt;Set-Operator&gt;
					 &lt;Notify-Operator&gt;
                    [&lt;action-extension&gt; ]
					
  &lt;action-extension&gt; ::= &lt;i2rs-action-extension&gt; |                     
                              ...
							  
  &lt;local-policy-rule&gt; ::= (&lt;local-policy-rule&gt;...)
  &lt;local-policy-rule&gt; ::= &lt;Identity&gt;
                              &lt;priority&gt;
                              &lt;precedence&gt;
                              &lt;Role&gt;
                             (&lt;Condition&gt;
                             (&lt;Action&gt;...)
                             &lt;Security-Model&gt;
							 
  &lt;Scope&gt; ::= (&lt;Read&gt; [&lt;read-scope&gt;]) |
              (&lt;Write&gt; [&lt;write-scope&gt;])

  &lt;Role&gt; ::= &lt;Resource&gt; | &lt;Scope&gt;

  &lt;Security-Model&gt; ::= &lt;First-Matching&gt;|
                           &lt;All-Matching&gt;
                           ...

  &lt;condition&gt; ::= &lt;variable&gt;
                 (&lt;value&gt;...)
                 [&lt;Match-Operator&gt;]
                 [&lt;condition-extension&gt;]

&lt;Match-Operator&gt; ::= &lt;IS-SET-MEMBER'&gt;
                     |&lt;IN-INTEGER-RANGE&gt;
                     |&lt;IP-ADDRESS-AS-RESOLVED-BY-DNS&gt;
                     |&lt;Match-Operator-extension&gt;

&lt;condition-extension&gt; ::= &lt;i2rs-condition-extension&gt; |
                           ...
&lt;action&gt; ::= &lt;variable&gt;         
             &lt;value&gt;
             &lt;Set-Operator&gt;
             [&lt;action-extension&gt;]

&lt;action-extension&gt; ::= &lt;i2rs-action-extension&gt; |
                        ...
 </artwork>
 </figure>
  <t> The elements of the Policy Group information model are as follows:
    <list style="symbols">
     <t>Each policy group is captured in its own list, distinguished
        via a identity, role, priority, precedence.</t>
     <t>A policy group has a certain role, such as resource or scope. A
        policy group can even have multiple roles simultaneously. The
        role, are captured in the list of "role" component. </t>
     <t>A policy role has a certain Scope, such as read scope or write=
         scope. A policy group can even have multiple scope simultaneously.
         The scope, or scopes, are captured in the list of "scope"
            components. </t>
      <t>A policy has a certain priority, such as priority 0-255. A
            policy can only have one priority. The priority is captured in the
            list of "priority" component.</t>
       <t>A policy rule can inherit properties (e.g., identity,role,priority, precedence) 
             from policy group. A policy
             rule also can have its own properties, e.g., enabled, mandatory,
            usage.</t>
       <t>The policy group elements can be extended with
            policy-specific components (policy-extensions, 
			policy-group-extension respectively).</t>
  </list></t>

 <t>The elements of the Network-Policy Rule information model are as
        follows: 
      <list style="symbols">
      <t>A policy can in turn be part of a hierarchy of policies,
         building on top of other policies. Each policy is captured in its
         own level, distinguished via a policy-identity. </t>

      <t>Policy rule inherit scope from policy group. A policy role has
            a certain Scope, such as read scope or write scope. A policy rule
            can even have multiple scope simultaneously. The scope, or scopes,
            are captured in the list of "scope" components. </t>
       <t>Furthermore, a policy rule contains conditions and actions,
            each captured in their own list. </t>
        <t>A condition contains a variable and a value and use a match
            operator, to connect variable with value. An examples of an
            operator might be a” IP ADDRESS AS RESOLVED BYDNS” or “Set to a
            member”. Also, a condition can in turn map onto other condition in
            an underlay policy. This is captured in list"supporting-condition".</t>
         <t>An action contains a variable and a value. An action uses Set
            operator to connect variable with value. Analogous to a node, an
            action can in turn map onto other actions in an underlay policy.
            This is captured in list "supporting-action".</t>
         <t>The policy, condition, action and operator elements can be
            extended with policy-specific components (policy-extensions,
            condition-extension, action-extension and operator-extension
            respectively).</t>
          </list></t>
 
 <t> The local network-policy model extends the Network-Policy Rule information model. 
 The elements of the local network-policy model are the local network-policy model as follows:
    <list style="symbols">
       <t>A local policy rule can in turn be part of a hierarchy of
            policies, building on top of other policies. Each local
            configuration policy is captured in its own level, distinguished
            via a policy identity. </t>
       <t>A local policy rule inherit scope from policy group. A local
             policy rule has a certain Scope, such as read scope or write
            scope. A local policy rule can even have multiple scope
            simultaneously. The scope, or scopes, are captured in the list of
            "scope" components. </t>
        <t>Furthermore, a local policy contains conditions and actions,
            each captured in their own list.</t>

        <t>A condition contains a variable and a value and use a match
            operator, to connect variable with value. An examples of an
            operator might be a” IP ADDRESS AS RESOLVED BYDNS” or
           “Set to a member”. Also, a condition can in turn map onto
            other condition in an underlay policy. This is captured in list
            "supporting-condition".</t>


        <t>An action contains a variable and a value. An action uses Set
            operator to connect variable with value. Analogous to a node, an
            action can in turn map onto other actions in an underlay policy.
            This is captured in list "supporting-action".</t>

         <t>The local policy, condition, action and operator elements can
            be extended with policy-specific components (condition-extension,
            action-extension and operator-extension respectively).</t>
      
   </list></t>
      
</section>
    
</section>
<section anchor="IANA" title="IANA Considerations">
      <t>This draft includes no request to IANA.</t>
    </section>

 <section title="Security Considerations">

      <t>TBD.</t>
    
</section>
  
</middle>

  
<back>
    
<references title="Informative References">
   &RFC2119;
   &RFC3060;
   &RFC3644;
   &RFC5394;
   &RFC4655;
   &RFC5511;
   &I-D.ietf-i2rs-architecture;
   &I-D.ietf-i2rs-rib-info-model; 
   &I-D.ietf-pce-stateful-pce;
   &I-D.keyupate-i2rs-bgp-usecases;
   &I-D.hares-i2rs-info-model-policy;
   &I-D.ji-i2rs-usecases-ccne-service;
   &I-D.keyupate-i2rs-bgp-usecases;
   &I-D.white-i2rs-use-case;
   </references>
  
</back>

</rfc>

