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