[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
SUPA                                                            Y. Cheng
Internet-Draft                                              China Unicom
Intended status: Informational                                    D. Liu
Expires: September 14, 2017                                Alibaba Group
                                                                   B. Fu
                                                           China Telecom
                                                                D. Zhang
                                                              Freelancer
                                                              N. Vadrevu
                                                  VN Telecom Consultancy
                                                          March 13, 2017


                         Applicability of SUPA
                   draft-cheng-supa-applicability-01

Abstract

   SUPA will define a generic policy model, an imperative ECA (Event
   Condition Action) policy information model and a declarative (intent-
   based) policy information model which is the extension of the generic
   model, and a set of policy data models which will make use of the
   common concepts defined in the generic model.  This memo will explore
   some typical use cases and demonstrate the applicability of SUPA
   policy models.

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 September 14, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Cheng, et al.          Expires September 14, 2017               [Page 1]


Internet-Draft            Applicability of SUPA               March 2017


   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Framework . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Network Manager/Controller  . . . . . . . . . . . . . . .   6
   4.  Use Cases of SUPA . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Use Case 1: SNMP blocking . . . . . . . . . . . . . . . .   8
       4.1.1.  Introduction  . . . . . . . . . . . . . . . . . . . .   8
       4.1.2.  Solution Approach . . . . . . . . . . . . . . . . . .   9
     4.2.  Use Case 2: VPC . . . . . . . . . . . . . . . . . . . . .  10
       4.2.1.  Generic . . . . . . . . . . . . . . . . . . . . . . .  10
       4.2.2.  Example 1 . . . . . . . . . . . . . . . . . . . . . .  12
       4.2.3.  Example 2 . . . . . . . . . . . . . . . . . . . . . .  13
     4.3.  Use Case 3: Instant VPN . . . . . . . . . . . . . . . . .  14
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   One of the ways for network service automation is using network
   management and operation software applications.  The applications may
   not be able to directly communicate with each network element; a
   hierarchical and extensible framework should be considered to hide
   the protocol specific and/or vendor specific details, high level
   network and service abstraction, and standardized programming API
   will be necessary.

   SUPA will define policy generic models and data models, for service
   management and operation applications.  [I-D.ietf-supa-generic-
   policy-info-model] defines a common set of concepts for various data
   models which may use different languages, protocols, and
   repositories.  The generic policy information model (GPIM)[I-D.ietf-



Cheng, et al.          Expires September 14, 2017               [Page 2]


Internet-Draft            Applicability of SUPA               March 2017


   supa-generic-policy-info-model] is defined for use in network
   operations and management applications.  The ECA Policy Rule
   Information Model (EPRIM) [I-D.ietf-supa-generic-policy- info-model]
   extends the GPIM to define how to build policy rules according to the
   event-condition-action paradigm.  The GPIM and the EPRIM will both be
   translated into corresponding YANG modules that define policy
   concepts, terminology, and rules in a generic and interoperable
   manner; additional YANG modules may also be defined from the GPIM
   and/or EPRIM to manage specific Functions, see [I-D.ietf-supa-
   generic-policy-data-model].

   The generic data models will be used for domain or service specific
   data model.  And there is no interoperability requirement for domain
   specific data models.  The interoperability is guaranteed at the
   generic data model level via the common concepts.

2.  Terminology

   DC Data Center

   PCE Path Computation Element

   SP Service Provider

   SUPA Simplified Use of Policy Abstractions

   VM Virtual Machine

   VPC Virtual Private Cloud

3.  Framework

   The SUPA Policy-based Management Framework is described in [I-D.ietf-
   supa -policy-based-management-framework].  Figure 1 is copied from
   [I-D.ietf-supa-policy-based-management-framework], for clarity
   reasons.















Cheng, et al.          Expires September 14, 2017               [Page 3]


Internet-Draft            Applicability of SUPA               March 2017


                                                                                                  +
                                                                          |  SUPA Policy Model
                                                                          |
                                                                          |  +----------------------------------+
                                                                          |  | Generic Policy Information Model |
                                                                          |  +----------------------------------+
                                                                          |        D                 D
                                                                          |        D   +-------------v-------------+
                 +----------------------+     |        D   | ECAPolicyRule Information |
                 | OSS/BSS/Orchestrator <--+  |        D   | Model (EPRIM)             |
                 +----------^-----------+  |  |        D   +---------------------------+
                                        C              |  |  +----+D+------------------------+D+---+
                                        C              +-----+     D   SUPA Policy DM         D    |
                 +----------v-----------+     |  | ----v-----------------------+  D    |
                 |  EMS/NMS/Controller  <--------+ | Generic Policy Data Model |  D    |
                 +----------^-----------+     |  | ----------------------------+  D    |
                                        C              +-----+              D                 D    |
                                        C              |  |  |     +--------v-----------------v--+ |
                 +----------v-----------+  |  |  |     |  ECA PolicyRule Data Model  | |
                 |  Network Element     <--+  |  |     +-----------------------------+ |
                 +----------------------+     |  +-------------------------------------+
                                                                          |
                                                                          +

      Figure 1: SUPA Policy Model Framework, copied from
                   [I-D.ietf-supa-policy-based-management-framework]

   In Figure 1:

   The double-headed arrow with Cs means communication;

   The arrow with Ds means derived from.

   The components within this framework are:

   SUPA Policy Model: represents one or more policy modules that contain
   the following entities:

   Generic Policy Information Model: a model for defining policy rules
   that are independent of data repository, data definition, query,
   implementation languages, and protocol.  This model is abstract and
   is used for design; it MUST be turned into a data model for
   implementation.

   Generic Policy Data Model: a model of policy rules that are dependent
   on data repository, data definition, query, implementation languages,
   and protocol.




Cheng, et al.          Expires September 14, 2017               [Page 4]


Internet-Draft            Applicability of SUPA               March 2017


   ECA Policy Rule Information Data Model (EPRIM): represents a policy
   rule as a statement that consists of an event clause, a condition
   clause, and an action clause.  This type of Policy Rule explicitly
   defines the current and desired states of the system being managed.
   This model is abstract and is used for design; it MUST be turned into
   a data model for implementation.

   ECA Policy Rule Data Model: a model of policy rules, derived from
   EPRIM, that consist of an event clause, a condition clause, and an
   action clause.

   EMS/NMS/Controller: represents one or more entities that are able to
   control the operation and management of a network infrastructure
   (e.g., a network topology that consists of Network Elements).

   Network Service and Resource Data Models: models of the service as
   well as physical and virtual network topology including the resource
   attributes (e.g., data rate or latency of links) and operational
   parameters needed to support service deployment over the network
   topology.

   Network Element (NE), which can interact with local or remote
   EMS/NMS/Controller in order to exchange information, such as
   configuration information, policy enforcement capabilities, and
   network status.

   As shown in Figure 1, SUPA will define generic policy models, which
   are independent of services and use cases.  Policy data models can be
   derived from the generic models.  The data model will define high
   level, maybe network-wide policies.  Policy data model will be used
   in conjunction with service data models to generate configurations
   for network elements.  The service data model is use case specific
   and will be developed by operators or third parties, which is out the
   scope of SUPA.

   The service management applications will send SUPA data models to the
   service management system, where policy making and automated policy
   enforcement will be performed, and the data models will be mapped to
   configuration of network elements.  Configuration of network elements
   is vendor specific, using various protocols, such Netconf, Restconf,
   etc.

   SUPA also make use of information collected from network elements.
   The information may include warning or fault event, load status,
   traffic statistics, etc, which can be used to adjust network
   configurations.  This kind of automation is done through ECA data
   models.




Cheng, et al.          Expires September 14, 2017               [Page 5]


Internet-Draft            Applicability of SUPA               March 2017


3.1.  Network Manager/Controller

         +------------------------+   +---------------+
         |   SUPA Generic Model   |   | Administrator |
         +------------------------+   +---------------+
                     |                        |
                     |                        | Policy Update
                     V                        V
     +---------------------------------------------------------------+
     |  +-------------------+                 +-------------------+  |
     |  | SUPA Data Model A |        ...      | SUPA Data Model N |  |
     |  +-------------------+                 +-------------------+  |
     |                                                               |
     |          Network Management / Controller                      |
     |                                                               |
     |  +----------------------------+  +-------------------------+  |
     |  |     Network Resources      |  | Information Collecting  |  |
     |  | (Topology, inventory, etc) |  | (Event, Statistic, etc) |  |
     |  +----------------------------+  +---------^---------------+  |
     +--------------------------------------------|------------------+
                          |                       | SNMP TRAP
                          | NETCONF               | Syslog
                          | RESTCONF              | Netconf Notification
                          V                       |
                     +--------------------------------+
                     |     Network Infrastructure     |
                     +--------------------------------+
      Figure 2: Network Manager / Controller

   The internal details of the network manager / controller may be out
   of the scope of SUPA, but explaining how it works may help people to
   understand and implement SUPA.

   Network administrator can send service deployment and management
   request to network manager / controller via SUPA data models.  The
   data models will be converted into network elements configuration
   snippets.  The configuration change may be performed instantly, or
   later triggered by events.  The network manager / controller has the
   intelligence to decide which network devices should be configured,
   and what the configuration will be, which is derived from the actions
   specific in the data models explicitly or implicitly.

   Network management related resources and information are stored in
   the network manager/controller, which contains the network topology
   (physical and virtual interconnection of network elements, etc),
   inventory (database of network elements, ports, device type,
   capabilities, etc.), protocol specific information, etc.




Cheng, et al.          Expires September 14, 2017               [Page 6]


Internet-Draft            Applicability of SUPA               March 2017


   SUPA will make use of the existing work of other IETF WGs and other
   SDOs, such as if the topology data model is already defined in
   another IETF WG, SUAP will reference it rather than trying to define
   it again.

   The network manager / controller will find out the list of network
   devices which should be configured for a specific demand or service.

   For example, there is a configuration request:

   All edge routers shall have SSH disabled.

   An edge router is a router with connection to network(s) outside of
   the current network domain.  The controller will query the topology
   database and find out all the routers with the attribute of "device-
   role == edge", or the controller may use more complicated algorithms
   to find out if a router is an edge route, which is implementation
   specific.

   Similarly, another example is, the controller can make use of PCE
   engine to plan the links between DCs, and make sure the links are
   disjoint for better availability in case of failure.  The PCE engine
   will be used in conjunction with the topology database to find out
   possible disjoint links.

   The network manager / controller will also have other information,
   such as protocol specific information, traffic with TCP destination
   port 22 is SNMP traffic.

   The network manager / controller also collect information from the
   network device, such events, logs, statistics, etc.  The information
   may come from SNMP TRAP, Syslog, NETCONF notification, and other
   sources such as vendor specific protocols or extensions.  The
   collected information may be used in conjunction with SUPA ECA data
   models for dynamic configuration change.  An example use of the
   information is, if the load on a link between two DC exceeds a
   threshold, and there are multiple disjoint links between the two DCs,
   traffic steering will be triggered.

   Event: link_load > threshold

   Condition: there are disjoint links

   Action: perform traffic steering

   Some of the events are already standardized, such SNMP TRAP and
   NETCONF notification; some are implementation specific.




Cheng, et al.          Expires September 14, 2017               [Page 7]


Internet-Draft            Applicability of SUPA               March 2017


   SUPA data models explicitly or implicitly specify network actions,
   and the actions may be expanded into more detail actions if
   necessary, and finally converted into protocol specific, vendor
   specific network element configuration snippets.

   In the previous example shown below again:

   All edge routers shall have SSH disabled.

   The action in this case is "disable SSH traffic", the network manager
   / controller should converted this action into configuration "disable
   traffic on TCP port 22" in the IP stack, or an ACL rule which will
   drop traffic with TCP destination port 22.

   The network manager / controller can support various types of
   southbound interface, such as NETCONF, RESTCONF, SNMP, OpenFLow, etc,
   which make it possible to support devices from different vendors.
   This is implementation specific and out of the scope of SUPA.

4.  Use Cases of SUPA

4.1.  Use Case 1: SNMP blocking

4.1.1.  Introduction

   This example will illustrate how to use the SUPA information model to
   block inbound and outbound SNMP traffic.

   The following exemplar policy was posted to the SUPA mailing list:

   ensures that SNMP is blocked on ports at the edge

   of the administrative domain to prevent SNMP going

   out or coming in from outside the enterprise.  (1)

   While this is simple for a human to understand, it is actually quite
   difficult for a machine to understand in its original form.  This is
   because:

   1) the text must be translated to a form that the device can
   understand

   2) the nature of the policy is not clear (due to the inherent
   ambiguity of English)






Cheng, et al.          Expires September 14, 2017               [Page 8]


Internet-Draft            Applicability of SUPA               March 2017


4.1.2.  Solution Approach

   First, let's assume the following context:

        +-----------------------------+       +--------------+
        |      Enterprise Domain      |       | Other Domain |
        |                             |       |              |
        |    +-----+ +-----+ +-----+  |/     \|              |
        |    | NE1 | | NE2 | | NE3 +--+-------+              |
        |    +-----+ +-----+ +-----+  |\     /|              |
        +-----------------------------+       +--------------+
                    Figure 3: Blocking inbound and outbound SNMP traffic

   In the above example, the only "edge" interface is that of NE3.  This
   enables us to simplify (1) to:

   block SNMP on NE3 (2)

   This assumes that NE3 exists and is operational.  This is a **big**
   assumption.  This leads to the observation that in both (1) and (2),
   there are at least two different interpretations for each:

   1) apply a set of actions directly to a SUPAPolicyTarget, assuming
   that the SUPAPolicyTarget understands SUPAPolicies, or

   2) apply a set of desired actions that are already translated to a
   form that a SUPAPolicyTarget can understand

   Note that a SUPAPolicyTarget could be the network device or a proxy
   for the network device.

   The difference between these interpretations is whether a SUPAPolicy
   applies one or more SUPAPolicyActions **directly** to a
   SUPAPolicyTarget (that is without translation to, for example, CLI or
   YANG) versus whether a SUPAPolicy, as part of its action(s), produces
   something that the device (or its proxy) can understand.

   Put another way, the first alternative shows how SUPAPolicies can
   directly control behavior, while the second alternative shows how a
   SUPAPolicy can invoke a set of actions that the device (or its proxy)
   can understand.  Thus, policy (1) can be formulated as either:

   - IF any network element has a port that meets the criterion of the
   role "edge interface", AND it is inside the EnterpriseDomain, then
   block SNMP traffic (3)

   - IF a network element is added within the EnterpriseDomain




Cheng, et al.          Expires September 14, 2017               [Page 9]


Internet-Draft            Applicability of SUPA               March 2017


   IF any of its ports take on the role "edge interface"

   Add a filter to block SNMP traffic for that port (4)

   The first case is the simplest, and likely what most people thought.
   Conceptually, it could look as follows:

   Event: SNMP traffic is sent or received

   Condition: IF this port implements the "edgeInterface" role

   AND IF this port is IN the EnterpriseDomain

   Action: Block SNMP traffic (5)

   (We will define "edgeInterface" role and "EnterpriseDomain" later in
   this note.)

   A possible drawback of (5) is that it is activated by the arrival of
   a packet event.  Such events will be VERY common, meaning that the
   Policy Engine will be doing a lot of work when most of the time, no
   policy action is needed.

   The second case could be addressed as follows:

   Event: A new port is going to be enabled

   Condition: IF this interface implements the "edgeInterface" role AND
   IF this port is IN the EnterpriseDomain

   Action: InstallFilter("SNMP traffic filter", "block") (6)

4.2.  Use Case 2: VPC

4.2.1.  Generic

   In practice, a public cloud operator can virtualize the cloud
   resources into multiple isolated virtualized private clouds and
   provide them to different tenants.  Such a Virtualized Private Cloud
   is referred to as a VPC.  In a typical VPC provided by, e.g., Alibaba
   or Amazon, through a control portal, tenants can establish and manage
   their VPC networks easily, for instance, deploying or removing
   virtualized network devices (e.g., virtualized routers and
   virtualized switches), adjusting the topologies of VPC networks,
   specifying packet forwarding policies, and deploying or removing
   virtual services (e.g., load balancers, firewalls, databases, DNS,
   etc.).  The network functionalities that the tenant can access are
   virtualized and actually could be performed by the VMs located on the



Cheng, et al.          Expires September 14, 2017              [Page 10]


Internet-Draft            Applicability of SUPA               March 2017


   servers connected through physical or overlay networks.  Note that
   the servers may be located in different data centers which are
   geographically distributed.

   The manipulation of the virtualized VPC network may also affect the
   configuration of physical networks.  For instance, when a tenant
   cloud networks and specify the policies to steer the traffics through
   different VPNs in different conditions.  Note that the VPCs that the
   tenant may be located in different geographic regions and the VPNs to
   those VPCs may need to be generated at run time. newly deploys two
   VMs in the VPC which are located in different DCs, the VPC control
   mechanism may have to generate a VPN between two DCs for the internal
   VPC communication.  Therefore, the control mechanism for a VPC should
   be able to adjust the underlying network when a tenant changes the
   network or service deployment of the virtual VPC network.

   In addition, a VPC, often provides other value added services (e.g.,
   database Services, DNS) for VMs in certain VPCs.  The VMs and the
   value added services could be located in different DCs, or even
   provided by different vendors.  VPNs are configured for the VPCs to
   provide connection to the internal services in a tenant's own DC or
   organization.  The access of such services should be controlled.  For
   instance, the VMs in a VPC can access the database services only when
   the tenant has deployed a database within its VPC through the control
   portal.

   In many cases, a tenant may need to specify how the VPCs are
   connected to its enterprise cloud networks.  For instance, a tenant
   wants to deploy multiple VPNs to connect the VPC with its private
   cloud networks and specify the policies to steer the traffics through
   different VPNs in different conditions.  Note that the VPCs that the
   tenant may be located in different geographic regions and the VPNs to
   those VPCs may need to be generated at run time.

   In addition, a VPC, often provides other value added services (e.g.,
   database Services, DNS) for VMs in certain VPCs.  The VMs and the
   value added services could be located in different DCs, or even
   provided by different vendors.  VPNs are configured for the VPCs to
   provide connection to the internal services in tenant's own DC or
   organization, and to create and manage VPNs to internal services.
   The access of VMs to data resources should be controlled.  For
   instance, the VMs in a VPC can access a database service only when
   the tenant has deployed a database service into its VPC through the
   control portal.







Cheng, et al.          Expires September 14, 2017              [Page 11]


Internet-Draft            Applicability of SUPA               March 2017


4.2.2.  Example 1

                              +--------------------+
                              | DC2                |
                              | +----------------+ |
                              | |Tenant x (vDC)  | |
                              | +----------------+ |
                              |                    |
                              | +----------------+ |
                              | | Tenant 1 (vDC) | |
                              | +----------------+ |
                              +----------|---------+
                                         |
                                        |
                                  +-------------+
                                  |    Cloud    |
                                 /|             |\
                                / +-------------+ \
                               /                   \
                              /                     \
           +-----------------/--+               +----\---------------+
           | DC1            /   |               | DC3 \              |
           | +----------------+ |               | +----------------+ |
           | | Tenant 1 (vDC) | |               | | Tenant 1 (vDC) | |
           | +----------------+ |               | +----------------+ |
           |                    |               |                    |
           | +----------------+ |               | +----------------+ |
           | | Tenant n (VDC) | |               | | Tenant k (vDC) | |
           | +----------------+ |               | +----------------+ |
           +--------------------+               +--------------------+
          Figure 4: Resource Inter-connection for a VPC Tenant

   When a cloud / DC operator signs a contract with customers, resource
   information such as network bandwidth, storage size, number of CPU,
   memory size, etc, will be specified.

   But in deployment, the resources may be located in multiple
   distributed data centers, and tunnels will be created to connect
   these resources, which makes it look like one seamless entity - a
   virtual DC.  There could be quite a number of tunnels, and the
   tunnels are dynamic, either for the reason of load balancing purpose
   or VM migration, or other reasons.  This will make it difficult to
   configure the service statically or manually, service automation is
   very necessary.

   The service management system will have a repository of available
   resources, including the topology.  And also the management system




Cheng, et al.          Expires September 14, 2017              [Page 12]


Internet-Draft            Applicability of SUPA               March 2017


   will have the customer specific information (location, SLA, agreed
   resources, etc).

   The administrator can send the service requirement to the management
   system by a high level data model, which can further be mapped to low
   level detail data models, then finally mapped to configurations of
   network devices.

   Target: Provide VPC service to customer A with specified resources
   and function (storage, computing, DNS, etc)

   Declarative policy:

   1.  Allocate the required services on DCs according to a user's
   profile

   2.  Services located in multiple distributed DCs must be
   interconnected via VPNs

   3.  The VPNs associated to the services provided for a user must
   match the user's profile in terms of latency, speed and bandwidth

4.2.3.  Example 2

              +----------+      Tenant move to         +----------+
              | Tenant A |    ------------------>      | Tenant A |
              +----------+     another location        +----------+
                   |                                         |
                   |                                         |
                   |                                         |
          +--------V-------+                       _+--------V-------+
          |  +----------+  |                        |  +----------+  |
          |  | VM for   |  |     VM Migration       |  | VM for   |  |
          |  | Tenant A |  |   ----------------->   |  | Tenant A |  |
          |  +----------+  |   if network load      |  +----------+  |
          |  DC-Location1  |   between DCs is low   |  DC-Location2  |
          +----------------+                        +----------------+
          Figure 5: VM Migration if Tenant Move

   As shown in the above figure, when a VPC tenant move from one
   location to another, where it is near to another DC, and the network
   load between the new DC and the previous DC is low, the tenant's VM
   should be migrated to the new DC in order for better user experience.
   After the VM is moved to the new DC, the network related to the VM
   must be updated accordingly.






Cheng, et al.          Expires September 14, 2017              [Page 13]


Internet-Draft            Applicability of SUPA               March 2017


           Target: Perform VM migration when user location changed and the
           network load between the DCs is low.


           ECA Policy:

           Event: a VPC user's location is changed (near to another DC).

           Condition: network_load(DC_old, DC_new) < threshold.

           Action:

           1.  Migrate the VM to the new data center (DC_new).

           2.  Update the VPNs connecting the user's services.


   In the above model it is assumed that the network management/
   controller has the network topology, including attributes of the
   links, such as bandwidth.  The network management/controller also
   monitors the real-time load on the links in the network topology.

   The user's location can be identified by the user's IP address.  When
   a user login, the network management/controller will check the user's
   IP address against an IP address database, such as the IP address
   assignments by IANA.

   The network management/controller also maintain a mapping of DCs and
   IP address segments, say, a DC should serve users in a near location
   which can be identified by IP address segments.  Though this is not
   always the case, sometimes the geographical distribution of network
   resource will also need to be considered besides the location (IP
   address).  But, anyway, a mapping of DC and the IP address it should
   serve should be maintained.

   If the controller detects a location change and a new DC is possible
   for the user, and the network load between the new DC and the old DC
   is low, then VM migration will be triggered and related network
   configuration will be performed.

4.3.  Use Case 3: Instant VPN










Cheng, et al.          Expires September 14, 2017              [Page 14]


Internet-Draft            Applicability of SUPA               March 2017


                              +------------------------+
                              |   SUPA Generic Model   |
                              +------------------------+
                                           |
                                           |
                           +-------------------------------+
                           | +---------------------------+ |
                           | |      SUPA Data Model      | |
                           | +---------------------------+ |
                           | +---------------------------+ |
                           | | SUPA Translation Function | |
                           | +---------------------------+ |
                           +-------------------------------+
                                /
                               /VPN Req Forwarded to Management System
                              /
           +------+  VPN  +------+      +------+      +------+
           |  CE  |-------|  PE  |------|  PE  |------|  PE  |
           +------+  Req  +------+      +------+      +------+
                             |              |             |
                             |              |             |
                          +------+      +------+      +------+
                          |  PE  |------|  PE  |------|  PE  |
                          +------+      +------+      +------+
          Figure 6: Instant VPN

   Traditionally, when an operator needs to deploy VPN services for an
   enterprise customer, they will send a service staff to the customer
   site and make the wire connection between the CE and PE.  The service
   staff will also collect the configuration information, e.g.
   port/frame/slot of PE, PE ID, etc, and then send the collected
   information back to the management system.  The management system
   will configure the network according to this information as well as
   the customer' information (such as bandwidth, SLA, etc).  The problem
   of this approach is that the service staff needs to collect the
   connection information and feedback to the management system, and
   MUST make sure the information matches the actual connection.  This
   process is error prone.

   New approach should not count on the physical / geographical
   information feedback by the service staff, minimize the operation
   procedures.  The CE should send authentication (with credentials)
   request to the PE, and PE should forward the request to the
   management system together with port/frame/slot on which the request
   is received, the PE ID etc.

   Target: Configure VPN for an enterprise customer to connect its
   enterprise network with VPC



Cheng, et al.          Expires September 14, 2017              [Page 15]


Internet-Draft            Applicability of SUPA               March 2017


   ECA Policy:

   Event: service management system receive a CE request for VPN
   creation (forwarded by PE).

   Condition: Authentication and Authorization results are OK.

   Action: Configure VPN based on received request, including the user's
   grade and physical info (port/slot/frame/route id, etc, from which
   the request is received).

5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

6.  Security Considerations

   Since SUPA models can be used to generate configurations for network
   elements, the management applications which send models to service
   management system must go through authentication and authorization.

   The handling of confliction of different polcies is out of scope of
   this memo.

7.  Acknowledgements

   This document has benefited from reviews, suggestions, comments and
   proposed text provided by the following members, listed in
   alphabetical order: Joel M.  Halpern, Juergen Schoenwaelder, John
   Strassner, James Huang, Georgios Karagiannis.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <http://www.rfc-editor.org/info/rfc6020>.




Cheng, et al.          Expires September 14, 2017              [Page 16]


Internet-Draft            Applicability of SUPA               March 2017


8.2.  Informative References

   [I-D.ietf-supa-generic-policy-data-model]
              Halpern, J. and J. Strassner, "Generic Policy Data Model
              for Simplified Use of Policy Abstractions (SUPA)", draft-
              ietf-supa-generic-policy-data-model-02 (work in progress),
              October 2016.

   [I-D.ietf-supa-generic-policy-info-model]
              Strassner, J., Halpern, J., and S. Meer, "Generic Policy
              Information Model for Simplified Use of Policy
              Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
              model-02 (work in progress), January 2017.

   [I-D.ietf-supa-policy-based-management-framework]
              LIU, S., Strassner, J., Karagiannis, G., Klyus, M., Bi,
              J., and C. Xie, "SUPA policy-based management framework",
              draft-ietf-supa-policy-based-management-framework-00 (work
              in progress), August 2016.

Authors' Addresses

   Ying Cheng (Editor)
   China Unicom
   No.21 Financial Street, XiCheng District
   Beijing  100033
   China

   Phone: +86-010-66259394
   Email: chengying10@chinaunicom.cn


   Dapeng Liu
   Alibaba Group
   Beijing  100022
   China

   Email: max.ldp@alibaba-inc.com


   Borui Fu (Editor)
   China Telecom
   Beijing
   China

   Email: fubr@ctbri.com.cn





Cheng, et al.          Expires September 14, 2017              [Page 17]


Internet-Draft            Applicability of SUPA               March 2017


   Dacheng Zhang
   Freelancer
   Beijing
   China

   Email: Dacheng.zhang@gmail.com


   Narasimha Vadrevu
   VN Telecom Consultancy

   Email: vadrevun@von20.com







































Cheng, et al.          Expires September 14, 2017              [Page 18]