idnits 2.17.1 draft-ietf-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 are 26 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 183: '...These constraints SHOULD be measurable...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 23, 2019) is 1886 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'TE-Service-Mapping' is defined on line 716, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS WG Young Lee 2 Haomian Zheng 3 Internet Draft Huawei 4 Intended status: Informational 5 Daniele Ceccarelli 6 Expires: February 23, 2019 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 February 23, 2019 22 Applicability of YANG models for Abstraction and Control of Traffic 23 Engineered Networks 25 draft-ietf-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 August 23, 2019. 49 Copyright Notice 51 Copyright (c) 2019 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 .. 3 85 3. Service Models .............................................. 5 86 4. Service Model Mapping to ACTN ............................... 7 87 4.1. Customer Service Models in the ACTN Architecture (CMI).. 7 88 4.2. Service Delivery Models in ACTN Architecture ........... 8 89 4.3. Network Configuration Models in ACTN Architecture (MPI). 8 90 4.4. Device Models in ACTN Architecture (SBI) ............... 9 91 5. Examples of Using Different Types of YANG Models ........... 10 92 5.1. Topology Collection ................................... 10 93 5.2. Connectivity over Two Nodes ........................... 10 94 5.3. VN service example .................................... 11 95 5.4. Data Center-Interconnection Example ................... 12 96 5.4.1. CMI (CNC-MDSC Interface) ......................... 14 97 5.4.2. MPI (MDSC-PNC Interface) ......................... 14 98 5.4.3. SBI (Southbound interface between PNC and devices) 14 99 6. Security ................................................... 15 100 7. Acknowledgements ........................................... 15 101 8. References ................................................. 15 102 8.1. Informative References................................. 15 103 9. Contributors ............................................... 17 104 Authors' Addresses ............................................ 18 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 [RFC6241] 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 [RFC8199] and [RFC8309]. 124 This document shows how the ACTN architecture can be satisfied using 125 various classes of data model that have already been defined, and 126 discusses the applicability of specific data models that are under 127 development. It also highlights where new data models may need to be 128 developed. 130 2. Abstraction and Control of TE Networks (ACTN) Architecture 132 [RFC8453] describes the architecture model for ACTN including the 133 entities (Customer Network Controller (CNC), Multi-domain Service 134 Coordinator (MDSC), and Provisioning Network Controller (PNC)) and 135 their interfaces. 137 Figure 1 depicts a high-level control and interface architecture for 138 ACTN and is a reproduction of Figure 3 from [RFC8453]. A number of 139 key ACTN interfaces exist for deployment and operation of ACTN-based 140 networks. These are highlighted in Figure 1 (ACTN Interfaces) below: 142 +--------------+ +---------------+ +--------------+ 143 | CNC-A | | CNC-B | | CNC-C | 144 |(DC provider) | | (ISP) | | (MVNO) | 145 +--------------+ +---------------+ +--------------+ 146 \ | / 147 Business \ | / 148 Boundary =======\========================|=========================/======= 149 Between \ | CMI / 150 Customer & ----------- | -------------- 151 Network Provider \ | / 152 +-----------------------+ 153 | MDSC | 154 +-----------------------+ 155 / | \ 156 ------------ |MPI ---------------- 157 / | \ 158 +-------+ +-------+ +-------+ 159 | PNC | | PNC | | PNC | 160 +-------+ +-------+ +-------+ 161 | GMPLS / | / \ 162 | trigger / |SBI SBI / \ 163 -------- ----- | / \ 164 ( ) ( ) | / \ 165 - - ( Phys. ) | / ----- 166 ( GMPLS ) ( Net ) | / ( ) 167 ( Physical ) ---- | / ( Phys. ) 168 ( Network ) ----- ----- ( Net ) 169 - - ( ) ( ) ----- 170 ( ) ( Phys. ) ( Phys. ) 171 -------- ( Net ) ( Net ) 172 ----- ----- 174 Figure 1 : ACTN Interfaces 176 The interfaces and functions are described below (without modifying 177 the definitions) in [RFC8453]: 179 The CNC-MDSC Interface (CMI) is an interface between a CNC and 180 an MDSC. This interface is used to communicate the service 181 request or application demand. A request will include specific 182 service properties, for example, services type, bandwidth and 183 constraint information. These constraints SHOULD be measurable 184 by MDSC and therefore visible to CNC via CMI. The CNC can also 185 request the creation of the virtual network service based on 186 underlying physical resources to provide network services for 187 the applications. The CNC can provide the end-point 188 information/characteristics together with traffic matrix 189 specifying specific customer constraints. The MDSC may also 190 report potential network topology availability if queried for 191 current capability from the Customer Network Controller. 192 Performance monitoring is also applicable in CMI, which enables 193 the MDSC to report network parameters/telemetries that may 194 guide the CNC to create/change their services. 196 The MDSC-PNC Interface (MPI) is an interface between a MDSC and 197 a PNC. It allows the MDSC to communicate requests to 198 create/delete connectivity or to modify bandwidth reservations 199 in the physical network. In multi-domain environments, each PNC 200 is responsible for a separate domain. The MDSC needs to 201 establish multiple MPIs, one for each PNC and perform 202 coordination between them to provide cross-domain connectivity. 203 MPI plays an important role for multi-vendor mechanism, inter- 204 operability can be achieved by standardized interface modules. 206 The South-Bound Interface (SBI) is the provisioning interface 207 for creating forwarding state in the physical network, 208 requested via the PNC. The SBI is not in the scope of ACTN, 209 however, it is included in this document so that it can be 210 compared to models in [RFC8309]. 212 3. Service Models 214 [RFC8309] introduces a reference architecture to explain the nature 215 and usage of service YANG models in the context of service 216 orchestration. Figure 2 below depicts this relationship and is a 217 reproduction of Figure 2 from [RFC8309]. Four models depicted in 218 Figure 2 are defined as follows: 220 Customer Service Model: A customer service model is used to 221 describe a service as offer or delivered to a customer by a 222 network operator. 223 Service Delivery Model: A service delivery model is used by a 224 network operator to define and configure how a service is 225 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 [RFC6241][RFC8040] provides solutions for the ACTN framework. This 275 section explains which types of YANG models apply to each of the 276 ACTN interfaces. 278 Refer to Figure 5 of [RFC8453] for details of the mapping between 279 ACTN functions and service models. In summary, the following 280 mappings are held between and Service Yang Models in [RFC8309] and 281 the ACTN interfaces in [RFC8453]. 283 o Customer Service Model <-> CMI 284 o Network Configuration Model <-> MPI 285 o Device Configuration Model <-> SBI 287 4.1. Customer Service Models in the ACTN Architecture (CMI) 289 Customer Service Models, which are used between a customer and a 290 service orchestrator as in [RFC8309], should be used between the CNC 291 and MDSC (e.g., CMI) serving as providing a simple intent-like 292 model/interface. 294 Among the key functions of Customer Service Models on the CMI is the 295 service request. A request will include specific service properties, 296 including: service type and its characteristics, bandwidth, 297 constraint information, and end-point characteristics. 299 The following table provides a list of functions needed to build the 300 CMI. They are mapped with Customer Service Models. 302 Function Yang Model 303 ----------------------------------------------------------- 304 VN Service Request [ACTN-VN-YANG] 305 VN Computation Request [ACTN-VN-YANG]* 306 TE & Service Mapping [TE-Service-Mapping]** 307 VN Performance Monitoring Telemetry [ACTN-PM-Telemetry]*** 308 Topology Abstraction [TE-topology]**** 309 Layer 1 Connectivity Service Model [L1CSM] 310 Layer 2 VPN Service Model [RFC8466] 311 Layer 3 VPN Service Model [RFC8299] 313 *VN computation request in the CMI context means network path 314 computation request based on customer service connectivity request 315 constraints prior to the instantiation of a VN creation. 317 **[TE-Service-Mapping] provides a mapping and cross-references 318 between service models (e.g., L3SM, L2SM, L1CSM) and TE model via 319 [ACTN-VN-YANG] and [TE-topology]. This model can be used as either 320 Customer Service Models, or Service Delivery model described in 321 Section 4.2. 323 ***ietf-actn-te-kpi-telemetry model in [ACTN-PM-Telemetry] describes 324 performance telemetry for ACTN VN model. This module also allows 325 autonomic traffic engineering scaling intent configuration mechanism 326 on the VN level. Scale in/out criteria might be used for network 327 autonomics in order the controller to react to a certain set of 328 variations in monitored parameters. Moreover, this module also 329 provides mechanism to define aggregated telemetry parameters as a 330 grouping of underlying VN level telemetry parameters. 332 ****TE-Topology's Connectivity Matrices/Matrix construct can be used 333 to instantiate VN Service via a suitable referencing and mapping 334 with [ACTN-VN-YANG]. 336 4.2. Service Delivery Models in ACTN Architecture 338 The Service Delivery Models where the service orchestration and the 339 network orchestration could be implemented as separate components as 340 seen in [RFC8309]. On the other hand, from an ACTN architecture 341 point of view, the service delivery model between the service 342 orchestrator and the network orchestrator is an internal interface 343 between sub-components of the MDSC in a single MDSC model. 345 In the MDSC hierarchical model where there are multiple MDSCs, the 346 interface between the top MDSC and the bottom MDSC can be mapped to 347 service delivery models. 349 4.3. Network Configuration Models in ACTN Architecture (MPI) 351 The Network Configuration Models is used between the network 352 orchestrator and the controller in [RFC8309]. In ACTN, this model is 353 used primarily between a MDSC and a PNC. The Network Configuration 354 Model can be also used for the foundation of more advanced models, 355 like hierarchical MDSCs (see Section 4.5) 357 The Network Configuration Model captures the parameters which are 358 network wide information. 360 The following table provides a list of functions needed to build the 361 MPI. They are mapped with Network Configuration Yang Models. Note 362 that various Yang models are work in progress. 364 Function Yang Model 365 -------------------------------------------------------- 366 Configuration Scheduling [Schedule] 367 Path computation [PATH_COMPUTATION-API] 368 Tunnel/LSP Provisioning [TE-tunnel] 369 Topology Abstraction [TE-topology] 370 Client Signal Description [Client-signal] 371 Service Provisioning [Client-signal]&[TE-tunnel]* 373 OTN Topology Abstraction [OTN-topo] 374 WSON Topology Abstraction [WSON-topo] 375 Flexi-grid Topology Abstraction [Flexi-topo] 376 Microwave Topology Abstraction [MW-topo] 377 OTN Tunnel Model [OTN-Tunnel] 378 WSON TE Tunnel Model [WSON-Tunnel] 379 Flexi-grid Tunnel Model [Flexigrid-Tunnel] 381 * This function is a combination of tunnel set up and client signal 382 description. Usually a tunnel is setting up first to get prepared to 383 carry a client signal, in order to do the service provisioning. Then 384 the client signal is adapted to the established tunnel. It is worth 385 noting that various tunnel models such as [OTN-Tunnel] and [WSON- 386 Tunnel] can be used together with the [TE-tunnel] model to construct 387 technology-specific tunnels, and carry different types of client 388 signals. More details can be found in [Client-signal]. 390 [TE-topo-tunnel] provides the clarification and example usage for TE 391 topology model [TE-topology] and TE tunnel model [TE-tunnel]. [T-NBI 392 Applicability] provides a summary on the applicability of existing 393 YANG model usage in the current network configuration, especially 394 for transport network. 396 4.4. Device Models in ACTN Architecture (SBI) 398 Note that SBI is not in the scope of ACTN, as there is already 399 mature protocol solutions for various purpose on the device level of 400 ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The 401 interworking of such protocols and ACTN controller hierarchies can 402 be found in [gmpls-controller-inter-work]. 404 For the device YANG models are used for per-device configuration 405 purpose, they can be used between the PNC and the physical 406 network/devices. One example of Device Models is ietf-te-device yang 407 module defined in [TE-tunnel]. 409 5. Examples of Using Different Types of YANG Models 411 This section provides some examples on the usage of IETF YANG models 412 in the network operation. A few typical generic scenarios are 413 involved. In [T-NBI Applicability], there are more transport-related 414 scenarios and examples. 416 5.1. Topology Collection 418 Before any connection is requested and delivered, the controller 419 needs to understand the network topology. The topology information 420 is exchanged among controllers with topology models, such as [TE- 421 topology]. Moreover, technology-specific topology reporting may use 422 the model described in [OTN-topo] [WSON-topo], and [Flexi-topo] for 423 OTN, WSON and Flexi-grid, respectively. By collecting the network 424 topology, each controller can therefore construct a local database, 425 which can be used for the further service deployment. 427 There can be different types of abstraction applied between each 428 pair of controllers, corresponding method can be found in [RFC8453]. 429 The technology-specific features may be hidden after abstraction, to 430 make the network easier for the user to operate. 432 When there is a topology change in the physical network, the PNC 433 should report the change to upper level of controllers via updating 434 messages using topology models. Accordingly, such changes is 435 propagated between different controllers for further 436 synchronization. 438 5.2. Connectivity over Two Nodes 440 The service models, such as described in [RFC8299], [RFC8466] and 441 [L1CSM] provide a customer service model which can be used in 442 provider networks. 444 It would be used as follows in the ACTN architecture: 446 A CNC uses the service models to specify the two client nodes 447 that are to be connected, and also indicates the amount of 448 traffic (i.e., the bandwidth required) and payload type. What 449 may be additionally specified is the SLA that describes the 450 required quality and resilience of the service. 452 The MDSC uses the information in the request to pick the right 453 network (domain) and also to select the provider edge nodes 454 corresponding to the customer edge nodes. 456 If there are multiple domains, then the MDSC needs to 457 coordinate across domains to set up network tunnels to deliver 458 a service. Thus coordination includes, but is not limited to, 459 picking the right domain sequence to deliver a service. 461 Additionally, an MDSC can initiate the creation of a tunnel (or 462 tunnel segment) in order to fulfill the service request from 463 CNC based on path computation upon the overall topology 464 information it synthesized from different PNCs. The based model 465 that can cater this purpose is the TE tunnel model specified in 466 [TE-tunnel]. Technology-specific tunnel configuration may use 467 the model described in [OTN-Tunnel] [WSON-Tunnel], and 468 [Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively. 470 Then, the PNCs need to decide the explicit route of such a 471 tunnel or tunnel segment (in case of multiple domains) for each 472 domain, and then create such a tunnel using protocols such as 473 PCEP and RSVP-TE or using per-hop configuration. 475 5.3. VN service example 477 The service model defined in [ACTN-VN-YANG] describes a virtual 478 network (VN) as a service which is a set of multiple connectivity 479 services: 481 A CNC will request VN to the MDSC by specifying a list of VN 482 members. Each VN member specifies either a single connectivity 483 service, or a source with multiple potential destination points 484 in the case that the precise destination sites are to be 485 determined by MDSC. 487 o In the first case, the procedure is the same as the 488 connectivity service, except that in this case, there is a 489 list of connections requested. 491 o In the second case, where the CNC requests the MDSC to 492 select the right destination out of a list of candidates, 493 the MDSC needs to evaluate each candidate and then choose 494 the best one and reply with the chosen destination for a 495 given VN member. After this is selected, the connectivity 496 request setup procedure is the same as in the connectivity 497 example in section 5.2. 499 After the VN is set up, a successful reply message is sent from MDSC 500 to CNC, indicating the VN is ready. This message can also be 501 achieved by using the model defined in [ACTN-VN-YANG]. 503 5.4. Data Center-Interconnection Example 505 This section describes more concretely how existing YANG models 506 described in Section 4 map to an ACTN data center interconnection 507 use case. Figure 3 shows a use-case which shows service policy- 508 driven Data Center selection and is a reproduction of Figure A.1 509 from [RFC8454]. 511 +----------------+ 512 | CNC | 513 | (Global DC | 514 | Operation | 515 | Control) | 516 +--------+-------+ 517 | | VN Requirement/Policy: 518 CMI: | | - Endpoint/DC location info 519 Service model | | - Endpoint/DC dynamic 520 | | selection policy 521 | | (for VM migration, DR, LB) 522 | v 523 +---------+---------+ 524 | Multi-domain | Service policy-driven 525 |Service Coordinator| dynamic DC selection 526 MPI: +-----+---+---+-----+ 527 Network Configuration | | | 528 Model | | | 529 +----------------+ | +---------------+ 530 | | | 531 +-----+-----+ +------+-----+ +------+-----+ 532 | PNC for | | PNC for | | PNC for | 533 | Transport | | Transport | | Transport | 534 | Network A | | Network B | | network C | 535 +-----------+ +------------+ +------------+ 536 Device | | | 537 Model | | | 538 | | | 539 +---+ ------ ------ ------ +---+ 540 |DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5| 541 +---+ | | | | | | +---+ 542 | TN A +-----+ TN B +----+ TN C | 543 / | | | | | 544 / \\\\ //// / \\\\ //// \\\\ //// 545 +---+ ------ / ------ \ ------ \ 546 |DC2| / \ \+---+ 547 +---+ / \ |DC6| 548 +---+ \ +---+ +---+ 549 |DC3| \|DC4| 550 +---+ +---+ 552 DR: Disaster Recovery 553 LB: Load Balancing 555 Figure 3: Service Policy-driven Data Center Selection 557 Figure 3 shows how VN policies from the CNC (Global Data Center 558 Operation) are incorporated by the MDSC to support multi-destination 559 applications. Multi-destination applications refer to applications 560 in which the selection of the destination of a network path for a 561 given source needs to be decided dynamically to support such 562 applications. 564 Data Center selection problems arise for VM mobility, disaster 565 recovery and load balancing cases. VN's policy plays an important 566 role for virtual network operation. Policy can be static or dynamic. 567 Dynamic policy for data center selection may be placed as a result 568 of utilization of data center resources supporting VMs. The MDSC 569 would then incorporate this information to meet the objective of 570 this application. 572 5.4.1. CMI (CNC-MDSC Interface) 574 [ACTN-VN-YANG] is used to express the definition of a VN, its VN 575 creation request, the service objectives (metrics, QoS parameters, 576 etc.), dynamic service policy when VM needs to be moved from one 577 Data Center to another Data Center, etc. This service model is used 578 between the CNC and the MDSC (CMI). The CNC in this use-case is an 579 external entity that wants to create a VN and operates on the VN. 581 5.4.2. MPI (MDSC-PNC Interface) 583 The Network Configuration Model is used between the MDSC and the 584 PNCs. Based on the Customer Service Model's request, the MDSC will 585 need to translate the service model into the network configuration 586 model to instantiate a set of multi-domain connections between the 587 prescribed sources and the destinations. The MDSC will also need to 588 dynamically interact with the CNC for dynamic policy changes 589 initiated by the CNC. Upon the determination of the multi-domain 590 connections, the MDSC will need to use the network configuration 591 model such as [TE-tunnel] to interact with each PNC involved on the 592 path. [TE-topology] is used to for the purpose of underlying domain 593 network abstraction from the PNC to the MDSC. 595 5.4.3. SBI (Southbound interface between PNC and devices) 597 The Device Model can be used between the PNC and its underlying 598 devices that are controlled by the PNC. The PNC will need to trigger 599 signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to 600 provision its domain path segment. There can be a plethora of 601 choices how to control/manage its domain network. The PNC is 602 responsible to abstract its domain network resources and update it 603 to the MDSC. Note that this interface is not in the scope of ACTN. 604 This section is provided just for an illustration purpose. 606 6. Security 608 This document is an informational draft. When the models mentioned 609 in this draft are implemented, detailed security consideration will 610 be given in such work. 612 How security fits into the whole architecture has the following 613 components: 615 - the use of Restconf security between components 617 - the use of authentication and policy to govern which services can 618 be requested by different parties. 620 - how security may be requested as an element of a service and 621 mapped down to protocol security mechanisms as well as separation 622 (slicing) of physical resources) 624 7. Acknowledgements 626 We thank Adrian Farrel for providing useful comments and suggestions 627 for this draft. 629 8. References 631 8.1. Informative References 633 [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", 634 RFC 8309. 636 [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module 637 Classification", RFC 8199. 639 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 641 and A. Bierman, Ed., "Network Configuration Protocol 643 (NETCONF)", RFC 6241. 645 [RFC8040] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 646 Protocol", RFC 8040. 648 [RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and 649 Control of Traffic Engineered Networks", RFC8453. 651 [TE-topology] X. Liu, et. al., "YANG Data Model for TE Topologies", 652 draft-ietf-teas-yang-te-topo, work in progress. 654 [TE-tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 655 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 656 te, work in progress. 658 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 659 Operation", draft-lee-teas-actn-vn-yang, work in progress. 661 [L1CSM] G. Fioccola, K. Lee, Y. Lee, D. Dhody, O. Gonzalez de-Dios, 662 D. Ceccarelli, "A Yang Data Model for L1 Connectivity 663 Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work 664 in progress. 666 [RFC8466] B. Wen, G. Fioccola, C. Xie, L. Jalil, "A YANG Data Model 667 for L2VPN Service Delivery", RFC8466. 669 [RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, K.Ogaki, "YANG Data 670 Model for L3VPN Service Delivery", RFC8299. 672 [RFC8454] Y. Lee & S. Belotti, "Information Model for Abstraction 673 and Control of TE Networks (ACTN)", RFC8454. 675 [RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource 676 Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp, 677 work in progress. 679 [Schedule] X. Liu, et. al., "A YANG Data Model for Configuration 680 Scheduling", draft-liu-netmod-yang-schedule, work in 681 progress. 683 [OTN-topo] H. Zheng, et. al., "A YANG Data Model for Optical 684 Transport Network Topology", draft-ietf-ccamp-otn-topo- 685 yang, work in progress. 687 [WSON-topo] Y. Lee, et. al., "A Yang Data Model for WSON Optical 688 Networks", draft-ietf-ccamp-wson-yang, work in progress. 690 [Flexi-topo] J.E. Lopez de Vergara, et. al., "YANG data model for 691 Flexi-Grid Optical Networks", draft-vergara-ccamp-flexigrid- 692 yang, work in progress. 694 [MW-topo] M. Ye, et. al., "A YANG Data Model for Microwave 695 Topology", draft-ietf-ccamp-mw-topo-yang, work in 696 progress. 698 [OTN-Tunnel] H. Zheng, et. al., "OTN Tunnel YANG Model", draft- 699 ietf-ccamp-otn-tunnel-model, work in progress. 701 [ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D. 702 King, and D. Ceccarelli, "YANG models for ACTN TE 703 Performance Monitoring Telemetry and Network Autonomics", 704 draft-lee-teas-actn-pm-telemetry-autonomics, work in 705 progress. 707 [WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R. 708 Vilalta, "A Yang Data Model for WSON Tunnel", draft-ietf- 709 ccamp-wson-tunnel-model, work in progress. 711 [Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de 712 Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model 713 for Flexi-Grid media-channels", draft-ietf-ccamp- 714 flexigrid-media-channel-yang, work in progress. 716 [TE-Service-Mapping] Y. Lee, et al, "Traffic Engineering and Service 717 Mapping Yang Model", draft-lee-teas-te-service-mapping- 718 yang, work in progress. 720 [Client-signal] H. Zheng, et al, "A YANG Data Model for Optical 721 Transport Network Client Signals", draft-zheng-ccamp- 722 client-signal-yang, work in progress. 724 [TE-topo-tunnel] I.Bryskin, et. al., "TE Topology and Tunnel 725 Modeling for Transport Networks", draft-ietf-teas-te-topo- 726 and-tunnel-modeling, work in progress. 728 [T-NBI Applicability] I. Busi, et al, "Transport Northbound 729 Interface Applicability Statement and Use Cases", draft- 730 ietf-ccamp-transport-nbi-app-statement, work in progress. 732 [gmpls-controller-inter-work] H. Zheng, et al, "Interworking of 733 GMPLS Control and Centralized Controller System", draft- 734 zheng-teas-gmpls-controller-inter-work, work in progress. 736 9. Contributors 738 Contributor's Addresses 739 Dhruv Dhody 740 Huawei Technologies 742 Email: dhruv.ietf@gmail.com 744 Xian Zhang 745 Huawei Technologies 747 Email: zhang.xian@huawei.com 749 Authors' Addresses 751 Young Lee 752 Huawei Technologies 753 5340 Legacy Drive 754 Plano, TX 75023, USA 755 Phone: (469)277-5838 757 Email: leeyoung@huawei.com 759 Haomian Zheng 760 Huawei Technologies 762 Email: zhenghaomian@huawei.com 764 Daniele Ceccarelli 765 Ericsson 766 Torshamnsgatan,48 767 Stockholm, Sweden 769 Email: daniele.ceccarelli@ericsson.com 771 Bin Yeong Yoon 772 ETRI 774 Email: byyun@etri.re.kr 776 Oscar Gonzalez de Dios 777 Telefonica 779 Email: oscar.gonzalezdedios@telefonica.com 781 Jong Yoon Shin 782 SKT 784 Email: jongyoon.shin@sk.com 786 Sergio Belotti 787 Nokia 789 Email: sergio.belotti@nokia.com