idnits 2.17.1 draft-zhang-teas-actn-yang-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 date (October 31, 2016) is 2732 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6020' is mentioned on line 118, but not defined == Missing Reference: 'Service-Yang' is mentioned on line 211, but not defined == Missing Reference: 'TE-topology' is mentioned on line 432, but not defined == Missing Reference: 'ODU-Tunnel' is mentioned on line 768, but not defined == Missing Reference: 'TE-tunnel' is mentioned on line 465, but not defined -- No information found for draft-lee-tease-actn-abstraction - is the name correct? -- No information found for draft-vergara-ccamp-flexigrid- - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS WG Young Lee 2 Xian Zhang 3 Internet Draft Huawei 4 Intended status: Informational 5 Daniel Ceccarrelli 6 Expires: February 2017 Ericsson 8 Bin Yeong Yoon 9 ETRI 11 Oscar Gonzalez de Dios 12 Telefonica 14 Jong Yoon Shin 15 SKT 17 Sergio Belotti 18 Nokia 20 October 31, 2016 22 Applicability of YANG models for Abstraction and Control of Traffic 23 Engineered Networks 25 draft-zhang-teas-actn-yang-03 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with 30 the provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on January 31, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Abstract 66 Abstraction and Control of TE Networks (ACTN) refers to the set of 67 virtual network operations needed to orchestrate, control and manage 68 large-scale multi-domain TE networks, so as to facilitate network 69 programmability, automation, efficient resource sharing, and end-to- 70 end virtual service aware connectivity and network function 71 virtualization services. 73 This document explains how the different types of YANG models 74 defined in the Operations and Management Area and in the Routing 75 Area are applicable to the ACTN framework. This document also shows 76 how the ACTN architecture can be satisfied using classes of data 77 model that have already been defined, and discusses the 78 applicability of specific data models that are under development. It 79 also highlights where new data models may need to be developed. 81 Table of Contents 83 1. Introduction...................................................3 84 2. Abstraction and Control of TE Networks (ACTN) Architecture.....4 85 3. Service Models.................................................6 86 4. Service Model Mapping to ACTN..................................7 87 4.1. Customer Service Models in the ACTN Architecture (CMI)...10 88 4.2. Service Delivery Models in ACTN Architecture.............10 89 4.3. Network Configuration Models in ACTN Architecture (MPI)..11 90 4.4. Device Models in ACTN Architecture (SBI).................12 91 4.5. Advanced Models..........................................12 92 5. Examples of Using Different Types of YANG Models..............13 93 5.1. Simple Connectivity Examples.............................13 94 5.2. VN service example.......................................14 95 5.3. Data Center-Interconnection Example......................14 96 5.3.1. CMI (CNC-MDSC Interface)............................16 97 5.3.2. MPI (MDSC-PNC Interface)............................16 98 5.3.3. PDI (PNC-Device interface)..........................16 99 6. Security......................................................17 100 7. Acknowledgements..............................................17 101 8. References....................................................17 102 8.1. Informative References...................................17 103 9. Contributors..................................................19 104 Authors' Addresses...............................................20 106 1. Introduction 108 Abstraction and Control of TE Networks (ACTN) describes a method for 109 operating a Traffic Engineered (TE) network (such as an MPLS-TE 110 network or a layer 1 transport network) to provide connectivity and 111 virtual network services for customers of the TE network. The 112 services provided can be tuned to meet the requirements (such as 113 traffic patterns, quality, and reliability) of the applications 114 hosted by the customers. More details about ACTN can be found in 115 Section 2. 117 Data models are a representation of objects that can be configured 118 or monitored within a system. Within the IETF, YANG [RFC6020] is the 119 language of choice for documenting data models, and YANG models have 120 been produced to allow configuration or modelling of a variety of 121 network devices, protocol instances, and network services. YANG data 122 models have been classified in [Netmod-Yang-Model-Classification] 123 and [Service-YANG]. 125 This document shows how the ACTN architecture can be satisfied using 126 classes of data model that have already been defined, and discusses 127 the applicability of specific data models that are under 128 development. It also highlights where new data models may need to be 129 developed. 131 2. Abstraction and Control of TE Networks (ACTN) Architecture 133 [ACTN-Requirements] describes the high-level ACTN requirements. 134 [ACTN-Frame] describes the architecture model for ACTN including the 135 entities (Customer Network Controller (CNC), Multi-domain Service 136 Coordinator (MDSC), and Physical Network Controller (PNC)) and their 137 interfaces. 139 Figure 1 depicts a high-level control and interface architecture for 140 ACTN and is a reproduction of Figure 7 from [ACTN-Frame]. A number 141 of key ACTN interfaces exist for deployment and operation of ACTN- 142 based networks. These are highlighted in Figure 1 (ACTN Interfaces) 143 below: 145 .-------------- 146 ------------- | 147 | Application |-- 148 ------------- 149 ^ 150 | I/F A -------- 151 v ( ) 152 -------------- - - 153 | Customer | ( Customer ) 154 | Network |--------->( Network ) 155 | Controller | ( ) 156 -------------- - - 157 ^ ( ) 158 | I/F B -------- 159 v 160 -------------- 161 | MultiDomain | 162 | Service | 163 | Coordinator| -------- 164 -------------- ( ) 165 ^ - - 166 | I/F C ( Physical ) 167 v ( Network ) 168 --------------- ( ) -------- 169 | |<----> - - ( ) 170 -------------- | ( ) - - 171 | Physical |-- -------- ( Physical ) 172 | Network |<---------------------->( Network ) 173 | Controller | I/F D ( ) 174 -------------- - - 175 ( ) 176 -------- 178 Figure 1 : ACTN Interfaces 180 The interfaces and functions are described below (without modifying 181 the definitions) in [ACTN-Frame]: 183 . Interface A: This is out of scope of this draft. 185 . Interface B: The CNC-MDSC Interface (CMI) is an interface 186 between a Customer Network Controller and a Multi Domain 187 Service Controller. The interface will communicate the service 188 request or application demand. A request will include specific 189 service properties, including: services, bandwidth and 190 constraint information. The CNC can also request the creation 191 of the virtual network based on underlying physical resources 192 to provide network services for the applications. The CNC can 193 provide the end-point information/characteristics, traffic 194 matrix specifying specific customer constraints. The MDSC may 195 also report potential network topology availability if queried 196 for current capability from the Customer Network Controller. 198 . Interface C: The MDSC-PNC Interface (MPI) is an interface 199 between a Multi Domain Service Coordinator and a Physical 200 Network Controller. It allows the MDSC to communicate requests 201 to create connectivity or to modify bandwidth reservations in 202 the physical network. In multi-domain environments, each PNC is 203 responsible for a separate domain and so the MDSC needs to 204 establish multiple MPIs, one for each PNC and perform 205 coordination between them. 207 . Interface D: The provisioning interface for creating forwarding 208 state in the physical network, requested via the Physical 209 Network Controller. Interface D is not in the scope of ACTN, 210 however, it is included in this document so that it can be 211 compared to models in [Service-Yang]. 213 3. Service Models 215 [Service-YANG] introduces a reference architecture to explain the 216 nature and usage of service YANG models in the context of service 217 orchestration. Figure 2 below depicts this relationship and is a 218 reproduction of Figure 2 from [Service-YANG]. Four models depicted 219 in Figure 2 are defined as follows: 221 . Customer Service Model: A customer service model is used to 222 describe a service as offer or delivered to a customer by a 223 network operator. 224 . Service Delivery Model: A service delivery model is used by a 225 network operator to define and configure how a service is 226 provided by the network. 227 . Network Configuration Model: A network configuration model is 228 used by a network orchestrator to provide network-level 229 configuration model to a controller. 230 . Device Configuration Model: A device configuration model is 231 used by a controller to configure physical network elements. 233 Customer 234 ------------------ Service ---------- 235 | | Model | | 236 | Service |<-------->| Customer | 237 | Orchestrator | | | 238 | | ---------- 239 ------------------ 240 . . ----------- 241 . . ......|Application| 242 . . : | BSS/OSS | 243 . . : ----------- 244 . Service Delivery . : 245 . Model . : 246 ------------------ ------------------ 247 | | | | 248 | Network | | Network | 249 | Orchestrator | | Orchestrator | 250 | | | | 251 .------------------ ------------------. 252 . : : . 253 . : Network Configuration : . 254 . : Model : . 255 ------------ ------------ ------------ ------------ 256 | | | | | | | | 257 | Controller | | Controller | | Controller | | Controller | 258 | | | | | | | | 259 ------------ ------------ ------------ ------------ 260 : . . : : 261 : . . Device : : 262 : . . Configuration : : 263 : . . Model : : 264 --------- --------- --------- --------- --------- 265 | Network | | Network | | Network | | Network | | Network | 266 | Element | | Element | | Element | | Element | | Element | 267 --------- --------- --------- --------- --------- 269 Figure 2: An SDN Architecture with a Service Orchestrator 271 4. Service Model Mapping to ACTN 273 YANG models coupled with the RESTCONF/NETCONF protocol 274 [Netconf][Restconf] are solutions for the ACTN framework. This 275 section explains which types of YANG models apply to each of the 276 ACTN interfaces. 278 +-------------------------------------------------------------+ 279 | | 280 | +-----------+ +-------+ | 281 | | Customer | | CNC | | 282 | +-----------+ +-------+ | 283 | /|\ /|\ | 284 +---------|-------------------------------------------|-------+ 285 | Customer Service Model | CMI 286 | | 287 +------ --|-------------------------------------------|--------+ 288 | \|/ | | 289 | +------------+ | | 290 | | Service | \|/ | 291 | |Orchestrator| +----------+ | 292 | +------------+ | | | 293 | /|\ | MDSC | | 294 | | Service Delivery Model | | | 295 | \|/ | | | 296 | +------------+ +----------+ | 297 | | Network | /|\ | 298 | |Orchestrator| | | 299 | +------------+ | | 300 | /|\ | | 301 | | | | 302 +---------|-------------------------------------------|--------+ 303 | | MPI 304 | Network Configuration Model | 305 +---------|-------------------------------------------|--------+ 306 | \|/ \|/ | 307 | +----------+ +-----------+ | 308 | | Domain | | PNC | | 309 | |Controller| +-----------+ | 310 | +----------+ /|\ /|\ | 311 | /|\ /|\ | | | 312 | | | | | | 313 +------|-----|-------------------------------------|-----|-----+ 314 | | Device Configuration Model | | SBI 315 \|/ \|/ \|/ \|/ 316 --- --- --- --- 317 / \ / \ / \ / \ 318 \ / \ / \ / \ / 319 --- --- --- --- 321 Figure 3 : Mapping between Service Model and ACTN Architecture 323 As shown in Figure 3, the architecture described in [Service-YANG] 324 can be mapped to the ACTN architecture well. A point worth noting is 325 that here the functions of the MDSC can include: 327 A. Customer mapping/translation 329 This function is to map customer intent-like commands into network 330 provisioning requests to the Physical Network Controller (PNC) 331 according to business OSS/NMS provisioned static or dynamic policy. 332 Specifically, it provides mapping and translation of customer's 333 service request into a set of parameters that are specific to a 334 network type and technology such that network configuration process 335 is made possible. 337 B. Service/Virtual service coordination 339 This function translates customer service-related information into 340 the virtual network service operations in order to seamlessly 341 operate virtual networks while meeting customer's service 342 requirements. In the context of ACTN, service/virtual service 343 coordination includes a number of service orchestration functions 344 such as multi-destination load balancing, guarantees of service 345 quality, bandwidth and throughput and notification for service fault 346 and performance degradation and so forth. 348 C. Multi domain coordination 350 This function oversees the specific aspects of the different domains 351 and builds a single abstracted end-to-end network topology in order 352 to coordinate end-to-end path computation and path/service 353 provisioning. Domain sequence path calculation/determination is also 354 a part of this function. 356 D. Virtualization/Abstraction 358 This function provides an abstracted view of the underlying network 359 resources towards customer, being it the client or a higher level 360 controller entity. It includes network path computation based on 361 customer service connectivity request constraints, based on the 362 global network-wide abstracted topology and the creation of an 363 abstracted view of network slices allocated to each customer, 364 according to customer-specific network objective functions, and to 365 the customer traffic profile. 367 The first two of these functions (A and B) are related to service 368 orchestration while function C is related to network orchestration 369 and function D is related to both service and network orchestration. 371 4.1. Customer Service Models in the ACTN Architecture (CMI) 373 Customer Service Models, which are used between a customer and a 374 service orchestrator as in [Service-YANG], should be used between 375 the CNC and MDSC (e.g., CMI) serving as providing a simple intent- 376 like model/interface. 378 Among the key functions of Customer Service Models on the CMI is the 379 service request. A request will include specific service properties, 380 including: service type and its characteristics, bandwidth, 381 constraint information, and end-point characteristics. 383 The following table provides a list of functions needed to build the 384 CMI. They are mapped with Customer Service Models. 386 Function Yang Model 387 ----------------------------------------------------------- 388 Transport Service Request [Transport-Service-Model] 389 VN Service Request [ACTN-VN-YANG] 390 VN Path Computation Request* [PATH-COMPUTATION-API] 391 [ACTN-VN-YANG] 393 *VN Path computation request in the CMI context means network path 394 computation request based on customer service connectivity request 395 constraints prior to the instantiation of a VN creation. 397 4.2. Service Delivery Models in ACTN Architecture 399 The Service Delivery Models (as shown in Figure 3) where the service 400 orchestration and the network orchestration could be implemented as 401 separate components as seen in [Service-YANG]. This is also known as 402 Network Service Models. On the other hand, from an ACTN architecture 403 point of view, the service delivery model between the service 404 orchestrator and the network orchestrator is an internal interface 405 between sub-components of the MDSC in a single MDSC model. 407 In the MDSC hierarchical model where there are multiple MDSCs, the 408 interface between the top MDSC and the bottom MDSC (which is known 409 as the MMI) can be mapped to service delivery models. See Section 410 4.5 for detailed discussions. 412 4.3. Network Configuration Models in ACTN Architecture (MPI) 414 The Network Configuration Models is used between the network 415 orchestrator and the controller in [Service-YANG]. In ACTN, this 416 model is used primarily between a MDSC and a PNC. The Network 417 Configuration Model can be also used for the foundation of more 418 advanced models, like hierarchical MDSCs (see Section 4.5) 420 The Network Configuration Model captures the parameters which are 421 network wide information. 423 The following table provides a list of functions needed to build the 424 MPI. They are mapped with Network Configuration Yang Models. Note 425 that various Yang models are work in progress. 427 Function Yang Model 428 -------------------------------------------------------- 429 Configuration Scheduling [Schedule] 430 Path computation [PATH_COMPUTATION-API]* 431 Path Provisioning [TE-Tunnel]** 432 Topology Abstraction [TE-topology] 433 Telemetry TBD 434 Service Provisioning TBD*** 436 OTN Topology Abstraction [OTN-YANG] 437 WSON Topology Abstraction [WSON-YANG] 438 Flexi-grid Topology Abstraction [Flexi-YANG] 439 ODU Tunnel Model [ODU-Tunnel] 440 Other Tech specific Tunnel Model TBD 442 * Related draft is presenting use cases for path computation API, 443 and Yang related model is foreseen to be added. 445 ** Note that path provisioning function is provided by ietf-te 446 module in [TE-Tunnel]. 448 *** This function needs to be investigated further. This can be a 449 part of [TE-Tunnel] which is to be determined. Service provisioning 450 is an optional function that builds on top the path provisioning 451 one. 453 Path provisioning and Topology abstraction functions are mandatory 454 in any case, while Path Computation may be mandatory or optional 455 depending on the type of topology abstraction used. Details of this 456 topic are discussed in [ACTN-Abstraction]. 458 Telemetry may also be an optional function. 460 4.4. Device Models in ACTN Architecture (SBI) 462 For the device YANG models are used for per-device configuration 463 purpose, they can be used between the PNC and the physical 464 network/devices. An example of Device Models is ietf-te-device yang 465 module defined in [TE-tunnel]. Note that SBI is not in the scope of 466 ACTN. This section is provided to give some examples of YANG-based 467 Device Models. 469 4.5. Advanced Models 471 There may be some variation of interface C whereby there may be 472 MDSC-MDSC interface (MMI) in case where there may be a recursive 473 hierarchy among the MDSCs. This is a variation of ACTN architecture. 474 See Figure 4 for this. 476 +-------+ +-------+ +-------+ 477 | CNC-A | | CNC-B | | CNC-C | 478 +-------+ +-------+ +-------+ 479 \ | / 480 ---------- | ---------- 481 \ | / 482 +-----------------------+ 483 | MDSC | 484 +-----------------------+ 485 / | \ 486 ---------- | ----------- 487 / | \ 488 +----------+ +----------+ +--------+ 489 | MDSC | | MDSC | | MDSC | 490 +----------+ +----------+ +--------+ 491 | / | / \ 492 | / | / \ 493 +-----+ +-----+ +-----+ +-----+ +-----+ 494 | PNC | | PNC | | PNC | | PNC | | PNC | 495 +-----+ +-----+ +-----+ +-----+ +-----+ 497 Figure 4: MDSC Controller Hierarchy 499 The MDSC-MDSC interface can be viewed as a recursive network 500 configuration model which is similar to the MDSC-PNC interface. 502 On the other hand, in some implementations, the MMI can be viewed as 503 the interface that fulfills the Service Delivery Model (See Figure 504 3). In this case, the top MDSC assumes service orchestration 505 functions while the lower MDSC network orchestration functions. 507 5. Examples of Using Different Types of YANG Models 509 5.1. Simple Connectivity Examples 511 The data model in [Transport-Service-Model] provides an intent-like 512 connectivity service model which can be used in connection-oriented 513 transport networks. 515 It would be used as follows in the ACTN architecture: 517 . A CNC uses this service model to specify the two client nodes 518 that are to be connected, and also indicates the amount of 519 traffic (i.e., the bandwidth required) and payload type. What 520 may be additionally specified is the SLA that describes the 521 required quality and resilience of the service. 523 . The MDSC uses the information in the request to pick the right 524 network (domain) and also to select the provider edge nodes 525 corresponding to the customer edge nodes. 527 If there are multiple domains, then the MDSC needs to 528 coordinate across domains to set up network tunnels to deliver 529 a service. Thus coordination includes, but is not limited to, 530 picking the right domain sequence to deliver a service. Before 531 it can perform such functions, it needs to get the topology 532 information from each PNC, be it abstract or not, using 533 topology YANG models such as [te-topology]. 535 Additionally, an MDSC can initiate the creation of a tunnel (or 536 tunnel segment) in order to fulfill the service request from 537 CNC based on path computation upon the overall topology 538 information it synthesized from different PNCs. The based model 539 that can cater this purpose is the te-tunnel model specified in 540 [te-tunnel]. 542 . Then, the PNC needs to decide the explicit route of such a 543 tunnel or tunnel segment (in case of multiple domains), and 544 create such a tunnel using protocols such as PCEP and RSVP-TE 545 or using per-hop configuration. 547 5.2. VN service example 549 The service model defined in [ACTN-VN-YANG] describes a virtual 550 network (VN) as a service which is a set of multiple connectivity 551 services: 553 . A CNC will specify to the MDSC a list of VN members. Each VN 554 member specifies either a single connectivity service, or a 555 source with multiple potential destination points in the case 556 that the precise destination sites are to be determined by 557 MDSC. 559 o In the first case, the procedure is the same as the 560 connectivity service, except that in this case, there is a 561 list of connections requested. 563 o In the second case, where the CNC requests the MDSC to 564 select the right destination out of a list of candidates, 565 the MDSC needs to choose the best candidate and reply with 566 the chosen destination for a given VN member. After this 567 is selected, the connectivity request setup procedure is 568 the same as in the connectivity-as-a-service example. 570 5.3. Data Center-Interconnection Example 572 This section describes more concretely how existing YANG models 573 described in Section 4 map to an ACTN data center interconnection 574 use case. Figure 5 shows a use-case which shows service policy- 575 driven Data Center selection and is a reproduction of Figure A.1 576 from [ACTN-Info]. 578 +----------------+ 579 | CNC | 580 | (Global DC | 581 | Operation | 582 | Control) | 583 +--------+-------+ 584 | | VN Requirement/Policy: 585 CMI: | | - Endpoint/DC location info 586 Service model | | - Endpoint/DC dynamic 587 | | selection policy 588 | | (for VM migration, DR, LB) 589 | v 590 +---------+---------+ 591 | Multi-domain | Service policy-driven 592 |Service Coordinator| dynamic DC selection 593 MPI: +-----+---+---+-----+ 594 Network Configuration | | | 595 Model | | | 596 +----------------+ | +---------------+ 597 | | | 598 +-----+-----+ +------+-----+ +------+-----+ 599 | PNC for | | PNC for | | PNC for | 600 | Transport | | Transport | | Transport | 601 | Network A | | Network B | | network C | 602 +-----------+ +------------+ +------------+ 603 Device | | | 604 Model | | | 605 | | | 606 +---+ ------ ------ ------ +---+ 607 |DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5| 608 +---+ | | | | | | +---+ 609 | TN A +-----+ TN B +----+ TN C | 610 / | | | | | 611 / \\\\ //// / \\\\ //// \\\\ //// 612 +---+ ------ / ------ \ ------ \ 613 |DC2| / \ \+---+ 614 +---+ / \ |DC6| 615 +---+ \ +---+ +---+ 616 |DC3| \|DC4| 617 +---+ +---+ 619 DR: Disaster Recovery 620 LB: Load Balancing 622 Figure 5: Service Policy-driven Data Center Selection 624 Figure 5 shows how VN policies from the CNC (Global Data Center 625 Operation) are incorporated by the MDSC to support multi-destination 626 applications. Multi-destination applications refer to applications 627 in which the selection of the destination of a network path for a 628 given source needs to be decided dynamically to support such 629 applications. 631 Data Center selection problems arise for VM mobility, disaster 632 recovery and load balancing cases. VN's policy plays an important 633 role for virtual network operation. Policy can be static or dynamic. 634 Dynamic policy for data center selection may be placed as a result 635 of utilization of data center resources supporting VMs. The MDSC 636 would then incorporate this information to meet the objective of 637 this application. 639 5.3.1. CMI (CNC-MDSC Interface) 641 [ACTN-VN-YANG] is used to express the definition of a VN, its VN 642 creation request, the service objectives (metrics, QoS parameters, 643 etc.), dynamic service policy when VM needs to be moved from one 644 Data Center to another Data Center, etc. This service model is used 645 between the CNC and the MDSC (CMI). The CNC in this use-case is an 646 external entity that wants to create a VN and operates on the VN. 648 5.3.2. MPI (MDSC-PNC Interface) 650 The Network Configuration Model is used between the MDSC and the 651 PNCs. Based on the Customer Service Model's request, the MDSC will 652 need to translate the service model into the network configuration 653 model to instantiate a set of multi-domain connections between the 654 prescribed sources and the destinations. The MDSC will also need to 655 dynamically interact with the CNC for dynamic policy changes 656 initiated by the CNC. Upon the determination of the multi-domain 657 connections, the MDSC will need to use the network configuration 658 model such as [TE-Tunnel] to interact with each PNC involved on the 659 path. [TE-Topology] is used to for the purpose of underlying domain 660 network abstraction from the PNC to the MDSC. 662 5.3.3. PDI (PNC-Device interface) 664 The Device Model can be used between the PNC and its underlying 665 devices that are controlled by the PNC. The PNC will need to trigger 666 signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to 667 provision its domain path segment. There can be a plethora of 668 choices how to control/manage its domain network. The PNC is 669 responsible to abstract its domain network resources and update it 670 to the MDSC. Note that this interface is not in the scope of ACTN. 671 This section is provided just for an illustration purpose. 673 6. Security 675 This document is an informational draft. When the models mentioned 676 in this draft are implemented, detailed security consideration will 677 be given in such work. 679 How security fits into the whole architecture has the following 680 components: 682 - the use of Restconf security between components 684 - the use of authentication and policy to govern which services can 685 be requested by different parties. 687 - how security may be requested as an element of a service and 688 mapped down to protocol security mechanisms as well as separation 689 (slicing) of physical resources) 691 7. Acknowledgements 693 We thank Adrian Farrel for providing useful comments and suggestions 694 for this draft. 696 8. References 698 8.1. Informative References 700 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 701 Explained", draft-wu-opsawg-service-model-explained, work 702 in progress. 704 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. 705 Moberg, "YANG Module Classification", draft-ietf-netmod- 706 yang-model-classification, work in progress. 708 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 710 and A. Bierman, Ed., "Network Configuration Protocol 712 (NETCONF)", RFC 6241. 714 [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 715 Protocol", draft-ietf-netconf-restconf, work in progress. 717 [ACTN-Requirements] Y. Lee, et al., "ACTN Requirements for 718 Abstraction and Control of TE Networks", draft-ietf-teas- 719 actn-requirements, work in progress. 721 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and 722 Control of Traffic Engineered Networks", draft-ietf-teas- 723 actn-framework, work in progress. 725 [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies", 726 draft-ietf-teas-yang-te-topo, work in progress. 728 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 729 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 730 te, work in progress. 732 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 733 Operation", draft-lee-teas-actn-vn-yang, work in progress. 735 [ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction 736 and Control of TE Networks (ACTN)", draft-leebelotti-teas- 737 actn-info, work in progress. 739 [Transport-Service-Model] X. Zhang (Editor), "A Service YANG Model 740 for Connection-oriented Transport Networks", draft-zhang- 741 teas-transport-service-model, work in progress. 743 [PATH-COMPUTATION-API] I.Busi/S.Belotti et al. "Path Computation 744 API", draft-busibel-ccamp-path-computation-api-00.txt, 745 work in progress 747 [RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource 748 Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp, 749 work in progress. 751 [Schedule] X. Liu, et. al., "A YANG Data Model for Configuration 752 Scheduling", draft-liu-netmod-yang-schedule, work in 753 progress. 755 [ACTN-Abstraction] Y. Lee, D. Dhody, and D. Ceccarelli, "ACTN 756 Abstraction Methods", draft-lee-tease-actn-abstraction, 757 work in progress. 759 [OTN-YANG] X. Zhang, A. Sharma, and X. Liu, "A YANG Data Model for 760 Optical Transport Network Topology", draft-zhang-ccamp-l1- 761 topo-yang, work in progress. 763 [WSON-YANG] Y. Lee, et. al., "A Yang Data Model for WSON Optical 764 Networks", draft-ietf-ccamp-wson-yang, work in progress. 766 [Flexi-YANG] J.E. Lopez de Vergara, et. al., "YANG data model for 767 Flexi-Grid Optical Networks", draft-vergara-ccamp-flexigrid- 768 yang, work in progress.[ODU-Tunnel] Sharma, R. Rao, and 769 X. Zhang, "OTN Service YANG Model", draft-sharma-ccamp- 770 otn-service-model, work in progress. 772 9. Contributors 774 Contributor's Addresses 776 Dhruv Dhody 777 Huawei Technologies 779 Email: dhruv.ietf@gmail.com 781 Haomian Zheng 782 Huawei Technologies 784 Email: zhenghaomian@huawei.com 786 Authors' Addresses 788 Young Lee 789 Huawei Technologies 790 5340 Legacy Drive 791 Plano, TX 75023, USA 792 Phone: (469)277-5838 794 Email: leeyoung@huawei.com 796 Xian Zhang 797 Huawei Technologies 799 Email: zhang.xian@huawei.com 801 Daniele Ceccarelli 802 Ericsson 803 Torshamnsgatan,48 804 Stockholm, Sweden 806 Email: daniele.ceccarelli@ericsson.com 808 Bin Yeong Yoon 809 ETRI 811 Email: byyun@etri.re.kr 813 Oscar Gonzalez de Dios 814 Telefonica 816 Email: oscar.gonzalezdedios@telefonica.com 818 Jong Yoon Shin 819 SKT 821 Email: jongyoon.shin@sk.com 823 Sergio Belotti 824 Nokia 826 Email: sergio.belotti@nokia.com