idnits 2.17.1 draft-cheng-supa-applicability-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 44 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 13, 2017) is 2599 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-supa-generic-policy-data-model' is defined on line 742, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-supa-generic-policy-info-model' is defined on line 748, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-supa-generic-policy-data-model-02 == Outdated reference: A later version (-03) exists of draft-ietf-supa-generic-policy-info-model-02 == Outdated reference: A later version (-03) exists of draft-ietf-supa-policy-based-management-framework-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUPA Y. Cheng 3 Internet-Draft China Unicom 4 Intended status: Informational D. Liu 5 Expires: September 14, 2017 Alibaba Group 6 B. Fu 7 China Telecom 8 D. Zhang 9 Freelancer 10 N. Vadrevu 11 VN Telecom Consultancy 12 March 13, 2017 14 Applicability of SUPA 15 draft-cheng-supa-applicability-01 17 Abstract 19 SUPA will define a generic policy model, an imperative ECA (Event 20 Condition Action) policy information model and a declarative (intent- 21 based) policy information model which is the extension of the generic 22 model, and a set of policy data models which will make use of the 23 common concepts defined in the generic model. This memo will explore 24 some typical use cases and demonstrate the applicability of SUPA 25 policy models. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 14, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Network Manager/Controller . . . . . . . . . . . . . . . 6 65 4. Use Cases of SUPA . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Use Case 1: SNMP blocking . . . . . . . . . . . . . . . . 8 67 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 8 68 4.1.2. Solution Approach . . . . . . . . . . . . . . . . . . 9 69 4.2. Use Case 2: VPC . . . . . . . . . . . . . . . . . . . . . 10 70 4.2.1. Generic . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.2.2. Example 1 . . . . . . . . . . . . . . . . . . . . . . 12 72 4.2.3. Example 2 . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3. Use Case 3: Instant VPN . . . . . . . . . . . . . . . . . 14 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 79 8.2. Informative References . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 One of the ways for network service automation is using network 85 management and operation software applications. The applications may 86 not be able to directly communicate with each network element; a 87 hierarchical and extensible framework should be considered to hide 88 the protocol specific and/or vendor specific details, high level 89 network and service abstraction, and standardized programming API 90 will be necessary. 92 SUPA will define policy generic models and data models, for service 93 management and operation applications. [I-D.ietf-supa-generic- 94 policy-info-model] defines a common set of concepts for various data 95 models which may use different languages, protocols, and 96 repositories. The generic policy information model (GPIM)[I-D.ietf- 97 supa-generic-policy-info-model] is defined for use in network 98 operations and management applications. The ECA Policy Rule 99 Information Model (EPRIM) [I-D.ietf-supa-generic-policy- info-model] 100 extends the GPIM to define how to build policy rules according to the 101 event-condition-action paradigm. The GPIM and the EPRIM will both be 102 translated into corresponding YANG modules that define policy 103 concepts, terminology, and rules in a generic and interoperable 104 manner; additional YANG modules may also be defined from the GPIM 105 and/or EPRIM to manage specific Functions, see [I-D.ietf-supa- 106 generic-policy-data-model]. 108 The generic data models will be used for domain or service specific 109 data model. And there is no interoperability requirement for domain 110 specific data models. The interoperability is guaranteed at the 111 generic data model level via the common concepts. 113 2. Terminology 115 DC Data Center 117 PCE Path Computation Element 119 SP Service Provider 121 SUPA Simplified Use of Policy Abstractions 123 VM Virtual Machine 125 VPC Virtual Private Cloud 127 3. Framework 129 The SUPA Policy-based Management Framework is described in [I-D.ietf- 130 supa -policy-based-management-framework]. Figure 1 is copied from 131 [I-D.ietf-supa-policy-based-management-framework], for clarity 132 reasons. 134 + 135 | SUPA Policy Model 136 | 137 | +----------------------------------+ 138 | | Generic Policy Information Model | 139 | +----------------------------------+ 140 | D D 141 | D +-------------v-------------+ 142 +----------------------+ | D | ECAPolicyRule Information | 143 | OSS/BSS/Orchestrator <--+ | D | Model (EPRIM) | 144 +----------^-----------+ | | D +---------------------------+ 145 C | | +----+D+------------------------+D+---+ 146 C +-----+ D SUPA Policy DM D | 147 +----------v-----------+ | | ----v-----------------------+ D | 148 | EMS/NMS/Controller <--------+ | Generic Policy Data Model | D | 149 +----------^-----------+ | | ----------------------------+ D | 150 C +-----+ D D | 151 C | | | +--------v-----------------v--+ | 152 +----------v-----------+ | | | | ECA PolicyRule Data Model | | 153 | Network Element <--+ | | +-----------------------------+ | 154 +----------------------+ | +-------------------------------------+ 155 | 156 + 158 Figure 1: SUPA Policy Model Framework, copied from 159 [I-D.ietf-supa-policy-based-management-framework] 161 In Figure 1: 163 The double-headed arrow with Cs means communication; 165 The arrow with Ds means derived from. 167 The components within this framework are: 169 SUPA Policy Model: represents one or more policy modules that contain 170 the following entities: 172 Generic Policy Information Model: a model for defining policy rules 173 that are independent of data repository, data definition, query, 174 implementation languages, and protocol. This model is abstract and 175 is used for design; it MUST be turned into a data model for 176 implementation. 178 Generic Policy Data Model: a model of policy rules that are dependent 179 on data repository, data definition, query, implementation languages, 180 and protocol. 182 ECA Policy Rule Information Data Model (EPRIM): represents a policy 183 rule as a statement that consists of an event clause, a condition 184 clause, and an action clause. This type of Policy Rule explicitly 185 defines the current and desired states of the system being managed. 186 This model is abstract and is used for design; it MUST be turned into 187 a data model for implementation. 189 ECA Policy Rule Data Model: a model of policy rules, derived from 190 EPRIM, that consist of an event clause, a condition clause, and an 191 action clause. 193 EMS/NMS/Controller: represents one or more entities that are able to 194 control the operation and management of a network infrastructure 195 (e.g., a network topology that consists of Network Elements). 197 Network Service and Resource Data Models: models of the service as 198 well as physical and virtual network topology including the resource 199 attributes (e.g., data rate or latency of links) and operational 200 parameters needed to support service deployment over the network 201 topology. 203 Network Element (NE), which can interact with local or remote 204 EMS/NMS/Controller in order to exchange information, such as 205 configuration information, policy enforcement capabilities, and 206 network status. 208 As shown in Figure 1, SUPA will define generic policy models, which 209 are independent of services and use cases. Policy data models can be 210 derived from the generic models. The data model will define high 211 level, maybe network-wide policies. Policy data model will be used 212 in conjunction with service data models to generate configurations 213 for network elements. The service data model is use case specific 214 and will be developed by operators or third parties, which is out the 215 scope of SUPA. 217 The service management applications will send SUPA data models to the 218 service management system, where policy making and automated policy 219 enforcement will be performed, and the data models will be mapped to 220 configuration of network elements. Configuration of network elements 221 is vendor specific, using various protocols, such Netconf, Restconf, 222 etc. 224 SUPA also make use of information collected from network elements. 225 The information may include warning or fault event, load status, 226 traffic statistics, etc, which can be used to adjust network 227 configurations. This kind of automation is done through ECA data 228 models. 230 3.1. Network Manager/Controller 232 +------------------------+ +---------------+ 233 | SUPA Generic Model | | Administrator | 234 +------------------------+ +---------------+ 235 | | 236 | | Policy Update 237 V V 238 +---------------------------------------------------------------+ 239 | +-------------------+ +-------------------+ | 240 | | SUPA Data Model A | ... | SUPA Data Model N | | 241 | +-------------------+ +-------------------+ | 242 | | 243 | Network Management / Controller | 244 | | 245 | +----------------------------+ +-------------------------+ | 246 | | Network Resources | | Information Collecting | | 247 | | (Topology, inventory, etc) | | (Event, Statistic, etc) | | 248 | +----------------------------+ +---------^---------------+ | 249 +--------------------------------------------|------------------+ 250 | | SNMP TRAP 251 | NETCONF | Syslog 252 | RESTCONF | Netconf Notification 253 V | 254 +--------------------------------+ 255 | Network Infrastructure | 256 +--------------------------------+ 257 Figure 2: Network Manager / Controller 259 The internal details of the network manager / controller may be out 260 of the scope of SUPA, but explaining how it works may help people to 261 understand and implement SUPA. 263 Network administrator can send service deployment and management 264 request to network manager / controller via SUPA data models. The 265 data models will be converted into network elements configuration 266 snippets. The configuration change may be performed instantly, or 267 later triggered by events. The network manager / controller has the 268 intelligence to decide which network devices should be configured, 269 and what the configuration will be, which is derived from the actions 270 specific in the data models explicitly or implicitly. 272 Network management related resources and information are stored in 273 the network manager/controller, which contains the network topology 274 (physical and virtual interconnection of network elements, etc), 275 inventory (database of network elements, ports, device type, 276 capabilities, etc.), protocol specific information, etc. 278 SUPA will make use of the existing work of other IETF WGs and other 279 SDOs, such as if the topology data model is already defined in 280 another IETF WG, SUAP will reference it rather than trying to define 281 it again. 283 The network manager / controller will find out the list of network 284 devices which should be configured for a specific demand or service. 286 For example, there is a configuration request: 288 All edge routers shall have SSH disabled. 290 An edge router is a router with connection to network(s) outside of 291 the current network domain. The controller will query the topology 292 database and find out all the routers with the attribute of "device- 293 role == edge", or the controller may use more complicated algorithms 294 to find out if a router is an edge route, which is implementation 295 specific. 297 Similarly, another example is, the controller can make use of PCE 298 engine to plan the links between DCs, and make sure the links are 299 disjoint for better availability in case of failure. The PCE engine 300 will be used in conjunction with the topology database to find out 301 possible disjoint links. 303 The network manager / controller will also have other information, 304 such as protocol specific information, traffic with TCP destination 305 port 22 is SNMP traffic. 307 The network manager / controller also collect information from the 308 network device, such events, logs, statistics, etc. The information 309 may come from SNMP TRAP, Syslog, NETCONF notification, and other 310 sources such as vendor specific protocols or extensions. The 311 collected information may be used in conjunction with SUPA ECA data 312 models for dynamic configuration change. An example use of the 313 information is, if the load on a link between two DC exceeds a 314 threshold, and there are multiple disjoint links between the two DCs, 315 traffic steering will be triggered. 317 Event: link_load > threshold 319 Condition: there are disjoint links 321 Action: perform traffic steering 323 Some of the events are already standardized, such SNMP TRAP and 324 NETCONF notification; some are implementation specific. 326 SUPA data models explicitly or implicitly specify network actions, 327 and the actions may be expanded into more detail actions if 328 necessary, and finally converted into protocol specific, vendor 329 specific network element configuration snippets. 331 In the previous example shown below again: 333 All edge routers shall have SSH disabled. 335 The action in this case is "disable SSH traffic", the network manager 336 / controller should converted this action into configuration "disable 337 traffic on TCP port 22" in the IP stack, or an ACL rule which will 338 drop traffic with TCP destination port 22. 340 The network manager / controller can support various types of 341 southbound interface, such as NETCONF, RESTCONF, SNMP, OpenFLow, etc, 342 which make it possible to support devices from different vendors. 343 This is implementation specific and out of the scope of SUPA. 345 4. Use Cases of SUPA 347 4.1. Use Case 1: SNMP blocking 349 4.1.1. Introduction 351 This example will illustrate how to use the SUPA information model to 352 block inbound and outbound SNMP traffic. 354 The following exemplar policy was posted to the SUPA mailing list: 356 ensures that SNMP is blocked on ports at the edge 358 of the administrative domain to prevent SNMP going 360 out or coming in from outside the enterprise. (1) 362 While this is simple for a human to understand, it is actually quite 363 difficult for a machine to understand in its original form. This is 364 because: 366 1) the text must be translated to a form that the device can 367 understand 369 2) the nature of the policy is not clear (due to the inherent 370 ambiguity of English) 372 4.1.2. Solution Approach 374 First, let's assume the following context: 376 +-----------------------------+ +--------------+ 377 | Enterprise Domain | | Other Domain | 378 | | | | 379 | +-----+ +-----+ +-----+ |/ \| | 380 | | NE1 | | NE2 | | NE3 +--+-------+ | 381 | +-----+ +-----+ +-----+ |\ /| | 382 +-----------------------------+ +--------------+ 383 Figure 3: Blocking inbound and outbound SNMP traffic 385 In the above example, the only "edge" interface is that of NE3. This 386 enables us to simplify (1) to: 388 block SNMP on NE3 (2) 390 This assumes that NE3 exists and is operational. This is a **big** 391 assumption. This leads to the observation that in both (1) and (2), 392 there are at least two different interpretations for each: 394 1) apply a set of actions directly to a SUPAPolicyTarget, assuming 395 that the SUPAPolicyTarget understands SUPAPolicies, or 397 2) apply a set of desired actions that are already translated to a 398 form that a SUPAPolicyTarget can understand 400 Note that a SUPAPolicyTarget could be the network device or a proxy 401 for the network device. 403 The difference between these interpretations is whether a SUPAPolicy 404 applies one or more SUPAPolicyActions **directly** to a 405 SUPAPolicyTarget (that is without translation to, for example, CLI or 406 YANG) versus whether a SUPAPolicy, as part of its action(s), produces 407 something that the device (or its proxy) can understand. 409 Put another way, the first alternative shows how SUPAPolicies can 410 directly control behavior, while the second alternative shows how a 411 SUPAPolicy can invoke a set of actions that the device (or its proxy) 412 can understand. Thus, policy (1) can be formulated as either: 414 - IF any network element has a port that meets the criterion of the 415 role "edge interface", AND it is inside the EnterpriseDomain, then 416 block SNMP traffic (3) 418 - IF a network element is added within the EnterpriseDomain 419 IF any of its ports take on the role "edge interface" 421 Add a filter to block SNMP traffic for that port (4) 423 The first case is the simplest, and likely what most people thought. 424 Conceptually, it could look as follows: 426 Event: SNMP traffic is sent or received 428 Condition: IF this port implements the "edgeInterface" role 430 AND IF this port is IN the EnterpriseDomain 432 Action: Block SNMP traffic (5) 434 (We will define "edgeInterface" role and "EnterpriseDomain" later in 435 this note.) 437 A possible drawback of (5) is that it is activated by the arrival of 438 a packet event. Such events will be VERY common, meaning that the 439 Policy Engine will be doing a lot of work when most of the time, no 440 policy action is needed. 442 The second case could be addressed as follows: 444 Event: A new port is going to be enabled 446 Condition: IF this interface implements the "edgeInterface" role AND 447 IF this port is IN the EnterpriseDomain 449 Action: InstallFilter("SNMP traffic filter", "block") (6) 451 4.2. Use Case 2: VPC 453 4.2.1. Generic 455 In practice, a public cloud operator can virtualize the cloud 456 resources into multiple isolated virtualized private clouds and 457 provide them to different tenants. Such a Virtualized Private Cloud 458 is referred to as a VPC. In a typical VPC provided by, e.g., Alibaba 459 or Amazon, through a control portal, tenants can establish and manage 460 their VPC networks easily, for instance, deploying or removing 461 virtualized network devices (e.g., virtualized routers and 462 virtualized switches), adjusting the topologies of VPC networks, 463 specifying packet forwarding policies, and deploying or removing 464 virtual services (e.g., load balancers, firewalls, databases, DNS, 465 etc.). The network functionalities that the tenant can access are 466 virtualized and actually could be performed by the VMs located on the 467 servers connected through physical or overlay networks. Note that 468 the servers may be located in different data centers which are 469 geographically distributed. 471 The manipulation of the virtualized VPC network may also affect the 472 configuration of physical networks. For instance, when a tenant 473 cloud networks and specify the policies to steer the traffics through 474 different VPNs in different conditions. Note that the VPCs that the 475 tenant may be located in different geographic regions and the VPNs to 476 those VPCs may need to be generated at run time. newly deploys two 477 VMs in the VPC which are located in different DCs, the VPC control 478 mechanism may have to generate a VPN between two DCs for the internal 479 VPC communication. Therefore, the control mechanism for a VPC should 480 be able to adjust the underlying network when a tenant changes the 481 network or service deployment of the virtual VPC network. 483 In addition, a VPC, often provides other value added services (e.g., 484 database Services, DNS) for VMs in certain VPCs. The VMs and the 485 value added services could be located in different DCs, or even 486 provided by different vendors. VPNs are configured for the VPCs to 487 provide connection to the internal services in a tenant's own DC or 488 organization. The access of such services should be controlled. For 489 instance, the VMs in a VPC can access the database services only when 490 the tenant has deployed a database within its VPC through the control 491 portal. 493 In many cases, a tenant may need to specify how the VPCs are 494 connected to its enterprise cloud networks. For instance, a tenant 495 wants to deploy multiple VPNs to connect the VPC with its private 496 cloud networks and specify the policies to steer the traffics through 497 different VPNs in different conditions. Note that the VPCs that the 498 tenant may be located in different geographic regions and the VPNs to 499 those VPCs may need to be generated at run time. 501 In addition, a VPC, often provides other value added services (e.g., 502 database Services, DNS) for VMs in certain VPCs. The VMs and the 503 value added services could be located in different DCs, or even 504 provided by different vendors. VPNs are configured for the VPCs to 505 provide connection to the internal services in tenant's own DC or 506 organization, and to create and manage VPNs to internal services. 507 The access of VMs to data resources should be controlled. For 508 instance, the VMs in a VPC can access a database service only when 509 the tenant has deployed a database service into its VPC through the 510 control portal. 512 4.2.2. Example 1 514 +--------------------+ 515 | DC2 | 516 | +----------------+ | 517 | |Tenant x (vDC) | | 518 | +----------------+ | 519 | | 520 | +----------------+ | 521 | | Tenant 1 (vDC) | | 522 | +----------------+ | 523 +----------|---------+ 524 | 525 | 526 +-------------+ 527 | Cloud | 528 /| |\ 529 / +-------------+ \ 530 / \ 531 / \ 532 +-----------------/--+ +----\---------------+ 533 | DC1 / | | DC3 \ | 534 | +----------------+ | | +----------------+ | 535 | | Tenant 1 (vDC) | | | | Tenant 1 (vDC) | | 536 | +----------------+ | | +----------------+ | 537 | | | | 538 | +----------------+ | | +----------------+ | 539 | | Tenant n (VDC) | | | | Tenant k (vDC) | | 540 | +----------------+ | | +----------------+ | 541 +--------------------+ +--------------------+ 542 Figure 4: Resource Inter-connection for a VPC Tenant 544 When a cloud / DC operator signs a contract with customers, resource 545 information such as network bandwidth, storage size, number of CPU, 546 memory size, etc, will be specified. 548 But in deployment, the resources may be located in multiple 549 distributed data centers, and tunnels will be created to connect 550 these resources, which makes it look like one seamless entity - a 551 virtual DC. There could be quite a number of tunnels, and the 552 tunnels are dynamic, either for the reason of load balancing purpose 553 or VM migration, or other reasons. This will make it difficult to 554 configure the service statically or manually, service automation is 555 very necessary. 557 The service management system will have a repository of available 558 resources, including the topology. And also the management system 559 will have the customer specific information (location, SLA, agreed 560 resources, etc). 562 The administrator can send the service requirement to the management 563 system by a high level data model, which can further be mapped to low 564 level detail data models, then finally mapped to configurations of 565 network devices. 567 Target: Provide VPC service to customer A with specified resources 568 and function (storage, computing, DNS, etc) 570 Declarative policy: 572 1. Allocate the required services on DCs according to a user's 573 profile 575 2. Services located in multiple distributed DCs must be 576 interconnected via VPNs 578 3. The VPNs associated to the services provided for a user must 579 match the user's profile in terms of latency, speed and bandwidth 581 4.2.3. Example 2 583 +----------+ Tenant move to +----------+ 584 | Tenant A | ------------------> | Tenant A | 585 +----------+ another location +----------+ 586 | | 587 | | 588 | | 589 +--------V-------+ _+--------V-------+ 590 | +----------+ | | +----------+ | 591 | | VM for | | VM Migration | | VM for | | 592 | | Tenant A | | -----------------> | | Tenant A | | 593 | +----------+ | if network load | +----------+ | 594 | DC-Location1 | between DCs is low | DC-Location2 | 595 +----------------+ +----------------+ 596 Figure 5: VM Migration if Tenant Move 598 As shown in the above figure, when a VPC tenant move from one 599 location to another, where it is near to another DC, and the network 600 load between the new DC and the previous DC is low, the tenant's VM 601 should be migrated to the new DC in order for better user experience. 602 After the VM is moved to the new DC, the network related to the VM 603 must be updated accordingly. 605 Target: Perform VM migration when user location changed and the 606 network load between the DCs is low. 608 ECA Policy: 610 Event: a VPC user's location is changed (near to another DC). 612 Condition: network_load(DC_old, DC_new) < threshold. 614 Action: 616 1. Migrate the VM to the new data center (DC_new). 618 2. Update the VPNs connecting the user's services. 620 In the above model it is assumed that the network management/ 621 controller has the network topology, including attributes of the 622 links, such as bandwidth. The network management/controller also 623 monitors the real-time load on the links in the network topology. 625 The user's location can be identified by the user's IP address. When 626 a user login, the network management/controller will check the user's 627 IP address against an IP address database, such as the IP address 628 assignments by IANA. 630 The network management/controller also maintain a mapping of DCs and 631 IP address segments, say, a DC should serve users in a near location 632 which can be identified by IP address segments. Though this is not 633 always the case, sometimes the geographical distribution of network 634 resource will also need to be considered besides the location (IP 635 address). But, anyway, a mapping of DC and the IP address it should 636 serve should be maintained. 638 If the controller detects a location change and a new DC is possible 639 for the user, and the network load between the new DC and the old DC 640 is low, then VM migration will be triggered and related network 641 configuration will be performed. 643 4.3. Use Case 3: Instant VPN 644 +------------------------+ 645 | SUPA Generic Model | 646 +------------------------+ 647 | 648 | 649 +-------------------------------+ 650 | +---------------------------+ | 651 | | SUPA Data Model | | 652 | +---------------------------+ | 653 | +---------------------------+ | 654 | | SUPA Translation Function | | 655 | +---------------------------+ | 656 +-------------------------------+ 657 / 658 /VPN Req Forwarded to Management System 659 / 660 +------+ VPN +------+ +------+ +------+ 661 | CE |-------| PE |------| PE |------| PE | 662 +------+ Req +------+ +------+ +------+ 663 | | | 664 | | | 665 +------+ +------+ +------+ 666 | PE |------| PE |------| PE | 667 +------+ +------+ +------+ 668 Figure 6: Instant VPN 670 Traditionally, when an operator needs to deploy VPN services for an 671 enterprise customer, they will send a service staff to the customer 672 site and make the wire connection between the CE and PE. The service 673 staff will also collect the configuration information, e.g. 674 port/frame/slot of PE, PE ID, etc, and then send the collected 675 information back to the management system. The management system 676 will configure the network according to this information as well as 677 the customer' information (such as bandwidth, SLA, etc). The problem 678 of this approach is that the service staff needs to collect the 679 connection information and feedback to the management system, and 680 MUST make sure the information matches the actual connection. This 681 process is error prone. 683 New approach should not count on the physical / geographical 684 information feedback by the service staff, minimize the operation 685 procedures. The CE should send authentication (with credentials) 686 request to the PE, and PE should forward the request to the 687 management system together with port/frame/slot on which the request 688 is received, the PE ID etc. 690 Target: Configure VPN for an enterprise customer to connect its 691 enterprise network with VPC 692 ECA Policy: 694 Event: service management system receive a CE request for VPN 695 creation (forwarded by PE). 697 Condition: Authentication and Authorization results are OK. 699 Action: Configure VPN based on received request, including the user's 700 grade and physical info (port/slot/frame/route id, etc, from which 701 the request is received). 703 5. IANA Considerations 705 This document makes no request of IANA. 707 Note to RFC Editor: this section may be removed on publication as an 708 RFC. 710 6. Security Considerations 712 Since SUPA models can be used to generate configurations for network 713 elements, the management applications which send models to service 714 management system must go through authentication and authorization. 716 The handling of confliction of different polcies is out of scope of 717 this memo. 719 7. Acknowledgements 721 This document has benefited from reviews, suggestions, comments and 722 proposed text provided by the following members, listed in 723 alphabetical order: Joel M. Halpern, Juergen Schoenwaelder, John 724 Strassner, James Huang, Georgios Karagiannis. 726 8. References 728 8.1. Normative References 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, 732 DOI 10.17487/RFC2119, March 1997, 733 . 735 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 736 the Network Configuration Protocol (NETCONF)", RFC 6020, 737 DOI 10.17487/RFC6020, October 2010, 738 . 740 8.2. Informative References 742 [I-D.ietf-supa-generic-policy-data-model] 743 Halpern, J. and J. Strassner, "Generic Policy Data Model 744 for Simplified Use of Policy Abstractions (SUPA)", draft- 745 ietf-supa-generic-policy-data-model-02 (work in progress), 746 October 2016. 748 [I-D.ietf-supa-generic-policy-info-model] 749 Strassner, J., Halpern, J., and S. Meer, "Generic Policy 750 Information Model for Simplified Use of Policy 751 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 752 model-02 (work in progress), January 2017. 754 [I-D.ietf-supa-policy-based-management-framework] 755 LIU, S., Strassner, J., Karagiannis, G., Klyus, M., Bi, 756 J., and C. Xie, "SUPA policy-based management framework", 757 draft-ietf-supa-policy-based-management-framework-00 (work 758 in progress), August 2016. 760 Authors' Addresses 762 Ying Cheng (Editor) 763 China Unicom 764 No.21 Financial Street, XiCheng District 765 Beijing 100033 766 China 768 Phone: +86-010-66259394 769 Email: chengying10@chinaunicom.cn 771 Dapeng Liu 772 Alibaba Group 773 Beijing 100022 774 China 776 Email: max.ldp@alibaba-inc.com 778 Borui Fu (Editor) 779 China Telecom 780 Beijing 781 China 783 Email: fubr@ctbri.com.cn 784 Dacheng Zhang 785 Freelancer 786 Beijing 787 China 789 Email: Dacheng.zhang@gmail.com 791 Narasimha Vadrevu 792 VN Telecom Consultancy 794 Email: vadrevun@von20.com