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

Filter-Based RIB Information Model
draft-ietf-i2rs-fb-rib-info-model-00

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 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 December 18, 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

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:

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:

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

1.2. I2RS Use Cases Suported by Filter-Based RIB

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

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

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:

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

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:

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.

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 
	 

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:

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:

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 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:

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

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   		

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

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

 

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

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   		

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

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]

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

 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   

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

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

	

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
 

The three levels of policy are expressed as:

		
	
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.  			  
 

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

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 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., Krishnan, R., Bogdanovic, D. and R. White, "Filter-Based RIB Data Model", Internet-Draft draft-hares-i2rs-fb-rib-data-model-03, March 2016.
[I-D.hares-i2rs-pkt-eca-data-model] Hares, S., Wu, Q. and R. White, "Filter-Based Packet Forwarding ECA Policy", Internet-Draft draft-hares-i2rs-pkt-eca-data-model-02, February 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", Internet-Draft draft-ietf-i2rs-architecture-15, April 2016.
[I-D.ietf-i2rs-ephemeral-state] Haas, J. and S. Hares, "I2RS Ephemeral State Requirements", Internet-Draft draft-ietf-i2rs-ephemeral-state-09, May 2016.
[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)", Internet-Draft draft-ietf-i2rs-rib-data-model-05, March 2016.
[I-D.ietf-i2rs-rib-info-model] Bahadur, N., Kini, S. and J. Medved, "Routing Information Base Info Model", Internet-Draft draft-ietf-i2rs-rib-info-model-08, 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.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014.

6.2. Informative References

[I-D.hares-i2rs-usecase-reqs-summary] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", Internet-Draft draft-hares-i2rs-usecase-reqs-summary-02, May 2015.
[I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", Internet-Draft draft-ietf-netconf-restconf-13, April 2016.
[I-D.ietf-netmod-acl-model] Bogdanovic, D., Koushik, K., Huang, L. and D. Blair, "Network Access Control List (ACL) YANG Data Model", Internet-Draft draft-ietf-netmod-acl-model-07, March 2016.
[I-D.ietf-netmod-routing-cfg] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", Internet-Draft draft-ietf-netmod-routing-cfg-21, March 2016.
[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.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011.

Authors' Addresses

Sriganesh Kini Ericsson EMail: sriganesh.kini@ericsson.com
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