Internet DRAFT - draft-pentikousis-supa-mapping

draft-pentikousis-supa-mapping







Network Working Group                                     K. Pentikousis
Internet-Draft                                                 EICT GmbH
Intended status: Informational                                  D. Zhang
Expires: November 12, 2015                                  May 11, 2015


 Simplified Use of Policy Abstractions (SUPA): Configuration and Policy
                                Mapping
                   draft-pentikousis-supa-mapping-05

Abstract

   Nowadays, the underlying network infrastructure grows in scale and
   complexity, which make it challenging for network operators to manage
   and configure the network.  Deploying policy or configuration based
   on an abstract view of the underlying network is much better than
   manipulating each individual network element, however, in this case,
   the policy and configuration cannot be recognized by the network
   elements.  This document describes guidelines for mapping said
   abstract configuration and policy into device-level configuration and
   the way in which such models will be processed by software to produce
   configuration details for actual devices.  The Simplified Use of
   Policy Abstractions (SUPA) framework overview, exemplary mechanism
   for exchanging service polices among the different elements
   participating in their deployment and enforcement, and primary
   procedures of mapping are described.  Moreover, an exemplary mapping
   scenario is provided to illustrate the defined mechanism.

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 November 12, 2015.







Pentikousis & Zhang     Expires November 12, 2015               [Page 1]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


Copyright Notice

   Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Configuration and Policy Mapping  . . . . . . . . . . . . . .   3
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Mapping Procedure . . . . . . . . . . . . . . . . . . . .   5
     4.3.  SUPA Mapping Example  . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  informative References  . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   As the underlying network infrastructure grows, new services are
   introduced, and traffic volumes increase rapidly, it becomes
   significantly more challenging and complicated to maintain the
   network and deploy new services than in the past.  Configuration
   automation can provide significant benefits in deployment agility.
   Simplified Use of Policy Abstractions (SUPA)
   [I-D.zhou-supa-framework] aims to improve configuration automation by
   introducing multi-level abstractions.  In SUPA, a generic policy
   information model [I-D.strassner-supa-generic-policy-info-model]is
   defined, which defines a generic framework for representing policy
   rules of any type, with this model, SUPA is capable to define a
   common framework for representing different types of policies,
   although the syntax and semantics of these policies are very
   different.  Based on the generic policy model, several policy data



Pentikousis & Zhang     Expires November 12, 2015               [Page 2]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


   models are defined to express different manners of policy
   enforcement, such as ECA and intent-based polices.  The information
   models of various network services is also utilized in SUPA to allow
   network operators to manipulate their infrastructure as a whole
   rather than individual devices.  Well-designed abstractions are able
   to provide a wide range of granularity for various applications
   needs.  However, these information models cannot be directly utilized
   by network elements, thus a mapping mechanism is necessary to bridge
   the gap between these information models and network element-
   recognized configuration.

   SUPA employs Network Manager/Controller.  Network Manager/Controllers
   represent one or more entities that are able to control the operation
   and management of a network infrastructure and mediate between the
   Service Management and the network elements to provide, maintain and
   deploy network services and policies.  Each Network Manager/
   Controller supports the SUPA interface/protocol and is a software
   repository, which stores the information associated with each network
   element.  The mapping mechanism could be part of the Network Manager/
   Controller implementation in order to map the SUPA model(s) into
   specified configuration models (or so-called southbound interfaces),
   which can be recognized by the network element(s).

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "Network Manager/Controller",
   and "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

3.  Terminology

   This document uses the following terms:

   Network element (NE):  a physical or virtual entity that can be
             locally managed and operated

   SUPA:     Simplified Use of Policy Abstractions

4.  Configuration and Policy Mapping

   This section introduces a framework for mapping configuration and
   policy in the context of a network with several network elements and
   one or more Service Managements.







Pentikousis & Zhang     Expires November 12, 2015               [Page 3]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


4.1.  Overview

   The SUPA framework for mapping network-level configuration into
   specific network management and controlling policies is illustrated
   in Figure 1.  It consists of i) Service Management, ii) Network
   Manager/Controller and iii) NEs.



                   +------------------------+ -------------------------
                   |   Service Management   |                       |
                   | +--------------------+ |                       |
                   | |      Policy        | |                       |
                   | +--------------------+ |                       |
                   | +--------------------+ |                       |
                   | | Service Management | |                       |
                   | |                    | |                       |
                   | +--------------------+ |                       |
                   +------------------------+                       |
                               | NetConf/RestConf                   |
                               |                                 Network
             +-----------------v--------------+                  Level
             |    +------------------------+  |                     |
             |    |    Network Resource    |  |                     |
             |    |                        |  |                     |
             |    +------------------------+  |                     |
             |             Network            |                     |
             |      Management/Controller     -------------------------
             |         +-----------------+    |                     |
             |         |protocol-specific|    |                     |
             |         |  configuration  |    |                     |
             |         +-----------------+    |                     |
             +-----------------^--------------+                   Device
                               |                                   Level
             +-----------------+--------------------+               |
    CLI/I2RS |                                      | CLI/I2RS      |
             |                                      |               |
             |                                      |               |
     +---------------+                      +---------------+       |
     |               |                      |               |       |
     |      NE       |           ...        |      NE       |       |
     |               |                      |               |       |
     +---------------+                      +---------------+----------




         Figure 1: SUPA configuration and policy mapping overview



Pentikousis & Zhang     Expires November 12, 2015               [Page 4]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


   Service Management manages and programs the underlying network
   elements indirectly based on the abstract view of the network
   infrastructure.  In practice, this means that Service Management can,
   among others, configure the underlying network as a whole rather than
   as a set of individual network elements.  As a result, the diversity
   of the actual network elements in active operation is abstracted,
   which allows Service Management to manage and program the network in
   a simpler, more maintainable and efficient manner.  On the other end
   of the spectrum, the NEs can continue their regular operation without
   having to become cognizant of the fact that configuration is applied
   at the network level.

   In order to bridge the gap between configuration set by Service
   Management and that required by the NEs, the Network Management and
   Network Manager/Controller has to provide a mapping mechanism which
   translates the configuration settings with high level of abstractions
   to device-level configurations.  This document considers three
   modules in the SUPA framework to support such a mapping mechanism, as
   follows.

   First, a network resource module maintains the resource of the
   infrastructure, such as topology of the network.  It provides the
   information of the resource, which maybe with high level of
   abstraction to Service Management for management, and it also
   provides the necessary information of each network element, which
   with low level of abstraction, when mapping configuration from the
   network-level to device-level.  Second, the service management and
   policy module, which is responsible for transmitting (send/receive)
   and process the network-level configuration.  Third, the protocol-
   specific configuration produces the output of the mapping mechanism
   and is responsible for distributing the device- level configuration
   to the corresponding network elements.

   In this framework, one would expect the introduction and use of
   algorithms/strategies for specific network services which can
   automatically generate device-level configuration based on the
   Service Management policies/configurations.  Note, however, that said
   algorithms and strategies are out of the scope of this document.

4.2.  Mapping Procedure

   From the view point of Service Management:

   Firstly, the operators or network administrators use a policy editor
   GUI to generates a set of policies based on application requirements,
   and sends these policies to the service management.  It should be
   noted that, the policies here maybe generated with different views,
   such as business view and system view, for different users, however,



Pentikousis & Zhang     Expires November 12, 2015               [Page 5]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


   these polices and the interfaces between the application and the
   Service Management are out of the scope of SUPA.

   Secondly, in the Service Management, based on the generic policy
   information model the policies generated in the previous step are
   translated into the policy data models defined in SUPA.  And then,
   policy conflict analysis may be processed to verify the new policy
   won't conflict the predefined policies.

   Thirdly, if the new policy is valid, Service Management begin to
   enforce this policy, in this step, it needs some context of the
   underlying network if necessary, especially the infrastructure
   (physical or logical) of the network, before it deploys a policy/
   service to the network.  For example, if Service Management attempts
   to steer traffic from one path to another, it should have the
   information of the existing paths first.  Service Management requests
   this context information from the network resource block of Network
   Manager/Controller.  This procedure does not have to be processed
   every time Service Management deploys a policy/service.

   Fourthly, service Management can obtain the current status of the
   service, which will be affected by the new policy, for reference
   before it deploys a new policy.  In such a case, Service Management
   sends a "GET" request to the Network Manager/Controller, and the
   Network Manager/Controller encapsulates this information with the
   models specified by SUPA network service models.

   Thirdly, Based on the service and policy configuration, and also
   service/network status if necessary, Service Management deploys the
   action of the policy by sending a "POST" request to the Network
   Manager/Controller.

   From the view point of Network Manager/Controller:

   Firstly, the Network Manager/Controller is responsible for
   maintaining the infrastructure information, and it provides
   information to Service Managements with the network resource models,
   such as topology information model.

   Secondly, once the Network Manager/Controller receives actions of a
   policy from Service Managements, it maps these actions to protocol-
   specific models.  The intelligence/algorithms of how to do the
   mapping is implementation-specific and out of the scope of this
   specification, as are the protocol-specific models.

   Thirdly, with the protocol-specific models, the device-level
   configurations for heterogeneous devices can be generated and
   conveyed by the Network Manager/Controller using, for example,



Pentikousis & Zhang     Expires November 12, 2015               [Page 6]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


   [RFC6020], [I-D.bierman-netconf-restconf],
   [I-D.atlas-i2rs-architecture] and CLI, to the corresponding NEs.

4.3.  SUPA Mapping Example

                    +-----------------------+
                    |     +---------+       |
                    |     |TE Policy|       |
                    |     +---------+       |
                    |   Service Management  |
                    +----------^------------+
                               |
                               | NETCONF/RESTCONF
                               |
                +--------------v---------------+
                |                              |
                |  Network Manager/Controller  |
                |                              |
                +--------------^---- ----------+
                               |  CLI/I2RS/NETCONF
                               |
              +----------------v--------------------+
              |                                     |

           192.0.2.1                              192.0.2.2
          +------+          +------+            +------+
          |  A   +----------+  C   +------------+  B   +-----+
          +-+--+-+          +------+            +---+--+     |
            |  |             192.0.2.3              |        |
           ++  |                                    |        |
           |   |                                    |    +---+--+
           |   |                                    |    |   G  |
       +---+--+|                                    |    +---+--+
       |  F   ||                                    |        |
       +------+|       +--+---+                 +---+--+     |
               +-------+  D   +-----------------+  E   +-----+
                       +------+                 +------+
                       192.0.2.4                   192.0.2.5


        Figure 2: Bandwidth use optimization for DC Interconnection

   Figure 2 illustrates a simple example in which interoperability
   between Service Management and Network Manager/Controller in an
   inter-data center (inter-DC) environment is considered.

   For the purposes of this example, let us focus on the dynamic
   configuration of the IP path between the seven illustrated DCs,



Pentikousis & Zhang     Expires November 12, 2015               [Page 7]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


   labeled A, B, C, D, E, F and G, based on the policies.  First of all,
   we would like the IP path to be created based on certain constraints.
   Secondly, we would like to map it to the device-level connections.
   In this scenario, there are two paths from DC A to DC B.  Typical IP
   shortest-path routing would choose path A(192.0.2.1)-C(192.0.2.3) >
   B(192.0.2.2).  However, under certain conditions, such as, for
   instance, when the bandwidth utiliaztion between A and B is beyond 80
   percents, the Service Management can decide that is better to steer
   traffic from path (A, C, B) to a new path which goes through a
   specific node.  This is a policy from business view, and it can be
   expressed by the ECA policy data model defined in
   [I-D.bi-supa-policy-model] but in this example, how this policy
   translated into the ECA policy is not provided, because it is too
   dependant on the implementation.

   Figure 2 depicts the layer 3 topology of the underlying network.

   First, Service Management needs some information about A, B, C, D and
   the links between them.  This information can be obtained from
   Network Manager/Controller, and it is listed in the fragment below.
   This information is derived from the Topology YANG model described in
   [I-D.contreras-supa-yang-network-topo].


        <topologies>
         <topology>
           <topoId>1111111100000000</topoId>
           <topoName>mapping_topo</topoName>
           <layer>ip</layer>
         </topology>
         <nodes>
           <node>
             <nodeID>192.0.2.1</nodeID>
             <nodeName>A</nodeName>
             <nodeType>physical</nodeType>
             <adminStatus>adminUp</adminStatus>
             <operStatus>up</operStatus>
             <parentTopoID>1111111100000000</parentTopoID>
           </node>
           <node>
             <nodeID>192.0.2.2</nodeID>
             <nodeName>B</nodeName>
             <nodeType>physical</nodeType>
             <adminStatus>adminUp</adminStatus>
             <operStatus>up</operStatus>
             <parentTopoID>1111111100000000</parentTopoID>
           </node>




Pentikousis & Zhang     Expires November 12, 2015               [Page 8]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


        ... skip ...

           <node>
             <nodeID>192.0.2.3</nodeID>
             <nodeName>C</nodeName>
             <nodeType>physical</nodeType>
             <adminStatus>adminUp</adminStatus>
             <operStatus>up</operStatus>
             <parentTopoID>1111111100000000</parentTopoID>
           </node>
         </nodes>
         <links>
           <link>
             <linkId>1</linkId>
             <linkName>A2C</linkName>
             <linkType>telink</linkType>
             <direction>bidrectional</direction>
             <adminStatus>adminUp</adminStatus>
             <operStatus>up</operStatus>
             <sourceNodeId>192.0.2.1</sourceNodeId>
             <destinationNodeId>192.0.2.3</destinationNodeId>
             <parentTopoID>1111111100000000<parentTopoID>
             <linkTeAttrCfg>
               <maxReservableBandwidth>2000</maxReservableBandwidth>
             </linkTeAttrCfg>
           </link>

        ... skip ...

           <link>
             <linkId>2</linkId>
             <linkName>C2B</linkName>
             <linkType>telink</linkType>
             <direction>bidrectional</direction>
             <adminStatus>adminUp</adminStatus>
             <operStatus>up</operStatus>
             <sourceNodeId>192.0.2.3</sourceNodeId>
             <destinationNodeId>192.0.2.2</destinationNodeId>
             <parentTopoID>1111111100000000<parentTopoID>
             <linkTeAttrCfg>
               <maxReservableBandwidth>50000</maxReservableBandwidth>
             </linkTeAttrCfg>
           </link>
         </links>
        </topologies>


              Figure 3: Information of the underlying network



Pentikousis & Zhang     Expires November 12, 2015               [Page 9]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


   Secondly, Service Management defines the policy using policy policy
   models defined in SUPA, and then sends the steering information
   derived from service and policy information to Network Manager/
   Controller using a protocol such as [RFC6020], and
   [I-D.bierman-netconf-restconf].  Figure 4 presents the policy for
   traffic steering: the traffic (supaflow) with destination IP address
   192.0.2.11/24 needs to be steered to DC B, the new path must go
   through DC D.  This configuration is derived from the YANG model
   described in [I-D.bi-supa-policy-model].  An example of the steering
   information is list in Figure 5, it specfies the traffic flow which
   will be steered, and the constrains of the new path.








































Pentikousis & Zhang     Expires November 12, 2015              [Page 10]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


   <supa-ddc-policy>
     <adjust-flow-path-policy>
       <adjust-flow-path>
         <vpn-name>supa_vpn</vpn-name>
         <vpn-type>L3VPN</vpn-type>
             <flow-name>supa_flow</flow-name>
             <traffic-steering-policy-rule>
           <policy-rule-deploy-status>
             4
           </policy-rule-deploy-status>
           <policy-rule-exec-status>
             3
           </policy-rule-exec-status>
           <policy-event>
               <bandwidth>
                 bandwidth
               </bandwidth>
           </policy-event>
           <policy-condition>
               <bandwidth-utilization>
                 utilization
               </bandwidth-utilization>
               <operator>
                 above
               </operator>
               <value>
                 80
               </value>
           </policy-condition>
               <policy-action-adjust-path>
                     <constraint-nodes>
                       <constraint-node>
                             <nodeId>192.0.2.4</nodeId>
                             <constraint-type>
                                   pass
                             </constraint-type>
                       </constraint-node>
                     </constraint-nodes>
               </policy-action-adjust-path>
             </traffic-steering-policy-rule>
           </adjust-flow-path>
     </adjust-flow-path-policy>
   </supa-ddc-policy>


                 Figure 4: Example traffic steering policy





Pentikousis & Zhang     Expires November 12, 2015              [Page 11]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


   <ipteFlow>
     <ipteFlowName>supa_flow</ipteFlowName>
     <bandwidth>10000</bandwidth>
     <pathPrefixs>
           <pathPrefix>
             <prefix>192.0.2.0</prefix>
             <maskLength>24</maskLength>
           </pathPrefix>
     </pathPrefixs>
     <paths>
           <path>
             <pathName>path_1</pathName >
             <pathType>auto</pathType >
             <pathNodes>
                   <pathNode>
                     <nodeId>192.0.2.1</nodeId>
                     <nodeRole>ingress</nodeRole>
                     <sequence>1</sequence>
                   </pathNode>
                   <pathNode>
                     <nodeId>192.0.2.5</nodeId>
                     <nodeRole> transit </nodeRole>
                     <sequence>2</sequence>
                   </pathNode>
                   <pathNode>
                     <nodeId>192.0.2.2</nodeId>
                     <nodeRole> egress </nodeRole>
                     <sequence>3</sequence>
                   </pathNode>
             </pathNodes>
       </path>
     </paths>
   </ipteFlow>


              Figure 5: Example traffic steering information

   Based on the steering information, the Network Manager/Controller
   generates a path which meets the requirements: in this example, the
   computed path is (A, D, E, B).  Network Manager/Controller also has
   to configure each device on the new path, not only the devices
   specified by the configuration such as node D, but also the devices
   in the underlying network which must be reconfigured, such as node E.
   The topology information is also necessary when Network Manager/
   Controller decides which device ought to be configured.

   With the assistance of other information in Network Manager/
   Controller, such as topology information, service/policy



Pentikousis & Zhang     Expires November 12, 2015              [Page 12]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


   configuration can be translated into protocol-specific yang models
   (or southbound interface) first.  Taking node D as an example, the
   configuration expressed in the YANG model defined in
   [I-D.lhotka-netmod-routing-cfg]could be as follows:

         <rt:routing>
         <rt:routing-instance>
           <rt:name>rtr0</rt:name>
           <rt:description>Router D</rt:description>
           <rt:routing-protocols>
             <rt:routing-protocol>
               <rt:type>rt:static</rt:type>
               <rt:name>st0</rt:name>
               <rt:description>
                 Static routing is used for the internal network.
               </rt:description>
               <rt:static-routes>
                 <v4ur:ipv4>
                   <v4ur:route>
                     <v4ur:destination-prefix>
                       192.0.2.0/24
                     </v4ur:destination-prefix>
                     <v4ur:next-hop>
                       <v4ur:next-hop-address>
                         192.0.2.5
                       </v4ur:next-hop-address>
                     </v4ur:next-hop>
                   </v4ur:route>
                 </v4ur:ipv4>
               </rt:static-routes>
             </rt:routing-protocol>
           </rt:routing-protocols>
         </rt:routing-instance>
        </rt:routing>


              Figure 6: Example traffic steering requirements

   The configuration of other nodes is similar.  Based on this vendor-
   neutral device-level configuration and the features of each NE, the
   NE-specific configuration can be generated.  Once nodes A, C, D and E
   have received their respective NE-specific configurations, the
   device-level configuration could be deployed and then, the traffic is
   steered as Service Management specified.







Pentikousis & Zhang     Expires November 12, 2015              [Page 13]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


5.  Security Considerations

   Security considerations will be discussed in an upcoming revision of
   this document.

6.  IANA Considerations

   TBD

7.  Acknowledgements

   This document has benefited comments, suggestions, and proposed text
   provided by Cathy Zhou and Will Liu (listed in alphabetical order).
   Junru Lin and Zhayiyong contributed to an earlier version of this
   draft.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

8.2.  informative References

   [I-D.atlas-i2rs-architecture]
              Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", draft-atlas-i2rs-architecture-02 (work in
              progress), August 2013.

   [I-D.bi-supa-policy-model]
              Bi, J., Tadepalli, R., and M. Hayashi, "DDC Service Policy
              YANG Data Model", draft-bi-supa-policy-model-01 (work in
              progress), March 2015.

   [I-D.bierman-netconf-restconf]
              Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
              "RESTCONF Protocol", draft-bierman-netconf-restconf-04
              (work in progress), February 2014.







Pentikousis & Zhang     Expires November 12, 2015              [Page 14]

Internet-Draft    SUPA Configuration and Policy Mapping         May 2015


   [I-D.contreras-supa-yang-network-topo]
              Contreras, L., Qu, A., and Y. Zha, "A YANG Data Model for
              Network Topologies", draft-contreras-supa-yang-network-
              topo-02 (work in progress), January 2015.

   [I-D.lhotka-netmod-routing-cfg]
              Lhotka, L., "A YANG Data Model for Routing Configuration",
              draft-lhotka-netmod-routing-cfg-00 (work in progress),
              March 2011.

   [I-D.strassner-supa-generic-policy-info-model]
              Strassner, J., "Generic Policy Model for Simplified Use of
              Policy Abstractions (SUPA)", draft-strassner-supa-generic-
              policy-info-model-00 (work in progress), April 2015.

   [I-D.zhou-supa-framework]
              Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The
              Framework of Shared Unified Policy Automation (SUPA)",
              draft-zhou-supa-framework-00 (work in progress), January
              2015.

Authors' Addresses

   Kostas Pentikousis
   EICT GmbH
   Torgauer Strasse 12-15
   Berlin  10829
   Germany

   Email: k.pentikousis@eict.de


   Dacheng Zhang
   Chaoyang Dist
   Beijing  100000
   P.R. China

   Email: Dacheng.zhang@gmail.com













Pentikousis & Zhang     Expires November 12, 2015              [Page 15]