idnits 2.17.1 draft-ietf-teas-actn-yang-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS WG Young Lee 2 Internet Draft Samsung 3 Intended status: Informational Haomian Zheng 4 Expires: August 22, 2021 Huawei Technologies 5 Daniele Ceccarelli 6 Ericsson 7 Bin Yeong Yoon 8 ETRI 9 Sergio Belotti 10 Nokia 12 February 22, 2021 14 Applicability of YANG models for Abstraction and Control of Traffic 15 Engineered Networks 17 draft-ietf-teas-actn-yang-07 19 Abstract 21 Abstraction and Control of TE Networks (ACTN) refers to the set of 22 virtual network operations needed to orchestrate, control and manage 23 large-scale multi-domain TE networks, so as to facilitate network 24 programmability, automation, efficient resource sharing, and end-to- 25 end virtual service aware connectivity and network function 26 virtualization services. 28 This document explains how the different types of YANG models 29 defined in the Operations and Management Area and in the Routing 30 Area are applicable to the ACTN framework. This document also shows 31 how the ACTN architecture can be satisfied using classes of data 32 model that have already been defined, and discusses the 33 applicability of specific data models that are under development. It 34 also highlights where new data models may need to be developed. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with 39 the provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Draft ACTN YANG February 20211 48 Internet-Drafts are draft documents valid for a maximum of six 49 months and may be updated, replaced, or obsoleted by other documents 50 at any time. It is inappropriate to use Internet-Drafts as 51 reference material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/ietf/1id-abstracts.txt 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html. 59 This Internet-Draft will expire on August 22, 2021. 61 Copyright Notice 63 Copyright (c) 2021 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with 71 respect to this document. Code Components extracted from this 72 document must include Simplified BSD License text as described in 73 Section 4.e of the Trust Legal Provisions and are provided without 74 warranty as described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction ................................................. 3 79 1.1. Conventions Used in This Document ....................... 3 80 2. Abstraction and Control of TE Networks (ACTN) Architecture ... 3 81 3. Service Models ............................................... 5 82 4. Service Model Mapping to ACTN ................................ 7 83 4.1. Customer Service Models in the ACTN Architecture (CMI) .. 7 84 4.2. Service Delivery Models in ACTN Architecture ............ 8 85 4.3. Network Configuration Models in ACTN Architecture (MPI) . 8 86 4.4. Device Models in ACTN Architecture (SBI) ................ 9 87 5. Examples of Using Different Types of YANG Models ............ 10 88 5.1. Topology Collection .................................... 10 89 5.2. Connectivity over Two Nodes ............................ 10 90 5.3. VN example ............................................. 11 91 5.4. Data Center-Interconnection Example .................... 12 93 Internet-Draft ACTN YANG February 20211 95 5.4.1. CMI (CNC-MDSC Interface) .......................... 14 96 5.4.2. MPI (MDSC-PNC Interface) .......................... 14 97 5.4.3. SBI (Southbound interface between PNC and devices). 14 98 6. Security .................................................... 15 99 7. IANA Considerations ......................................... 15 100 8. Acknowledgements ............................................ 15 101 9. References .................................................. 15 102 9.1. Informative References ................................. 15 103 10. Contributors ............................................... 18 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 for customers of the TE network. The services 112 provided can be tuned to meet the requirements (such as traffic 113 patterns, quality, and reliability) of the applications hosted by 114 the customers. More details about ACTN can be found in Section 2. 116 Data models are a representation of objects that can be configured 117 or monitored within a system. Within the IETF, YANG [RFC6241] is the 118 language of choice for documenting data models, and YANG models have 119 been produced to allow configuration or modelling of a variety of 120 network devices, protocol instances, and network services. YANG data 121 models have been classified in [RFC8199] and [RFC8309]. 123 This document shows how the ACTN architecture can be satisfied using 124 various classes of data model that have already been defined, and 125 discusses the applicability of specific data models that are under 126 development. It also highlights where new data models may need to be 127 developed. 129 1.1. Conventions Used in This Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in 134 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 2. Abstraction and Control of TE Networks (ACTN) Architecture 139 [RFC8453] describes the architecture model for ACTN including the 140 entities (Customer Network Controller (CNC), Multi-domain Service 142 Internet-Draft ACTN YANG February 20211 144 Coordinator (MDSC), and Provisioning Network Controller (PNC)) and 145 their interfaces. 147 Figure 1 depicts a high-level control and interface architecture for 148 ACTN and is a reproduction of Figure 3 from [RFC8453]. A number of 149 key ACTN interfaces exist for deployment and operation of ACTN-based 150 networks. These are highlighted in Figure 1 (ACTN Interfaces) below: 152 +--------------+ +---------------+ +--------------+ 153 | CNC-A | | CNC-B | | CNC-C | 154 |(DC provider) | | (ISP) | | (MVNO) | 155 +--------------+ +---------------+ +--------------+ 156 \ | / 157 Business \ | / 158 Boundary =====\======================|=======================/====== 159 Between \ | CMI / 160 Customer & ----------- | -------------- 161 Network Provider \ | / 162 +---------------------+ 163 | MDSC | 164 +---------------------+ 165 / | \ 166 ---------- |MPI ------------- 167 / | \ 168 +-------+ +-------+ +-------+ 169 | PNC | | PNC | | PNC | 170 +-------+ +-------+ +-------+ 171 | GMPLS / | / \ 172 | trigger / |SBI SBI / \ 173 -------- ----- | / \ 174 ( ) ( ) | / \ 175 - - ( Phys. ) | / ----- 176 ( GMPLS ) ( Net ) | / ( ) 177 ( Physical ) ---- | / ( Phys. ) 178 ( Network ) ----- ----- ( Net ) 179 - - ( ) ( ) ----- 180 ( ) ( Phys. ) ( Phys. ) 181 -------- ( Net ) ( Net ) 182 ----- ----- 184 Figure 1 : ACTN Interfaces 186 The interfaces and functions are described below (without modifying 187 the definitions) in [RFC8453]: 189 Internet-Draft ACTN YANG February 20211 191 The CNC-MDSC Interface (CMI) is an interface between a CNC and 192 an MDSC. This interface is used to communicate the service 193 request or application demand. A request will include specific 194 service properties, for example, services type, bandwidth and 195 constraint information. These constraints SHOULD be measurable 196 by MDSC and therefore visible to CNC via CMI. The CNC can also 197 request the creation of the virtual network based on underlying 198 physical resources to provide network services for the 199 applications. The CNC can provide the end-point 200 information/characteristics together with traffic matrix 201 specifying specific customer constraints. The MDSC may also 202 report potential network topology availability if queried for 203 current capability from the Customer Network Controller. 204 Performance monitoring is also applicable in CMI, which enables 205 the MDSC to report network parameters/telemetries that may 206 guide the CNC to create/change their services. 208 The MDSC-PNC Interface (MPI) is an interface between a MDSC and 209 a PNC. It allows the MDSC to communicate requests to 210 create/delete connectivity or to modify bandwidth reservations 211 in the physical network. In multi-domain environments, each PNC 212 is responsible for a separate domain. The MDSC needs to 213 establish multiple MPIs, one for each PNC and perform 214 coordination between them to provide cross-domain connectivity. 215 MPI plays an important role for multi-vendor mechanism, inter- 216 operability can be achieved by standardized interface modules. 218 The South-Bound Interface (SBI) is the provisioning interface 219 for creating forwarding state in the physical network, 220 requested via the PNC. The SBI is not in the scope of ACTN, 221 however, it is included in this document so that it can be 222 compared to models in [RFC8309]. 224 3. Service Models 226 [RFC8309] introduces a reference architecture to explain the nature 227 and usage of service YANG models in the context of service 228 orchestration. Figure 2 below depicts this relationship and is a 229 reproduction of Figure 2 from [RFC8309]. Four models depicted in 230 Figure 2 are defined as follows: 232 Customer Service Model: A customer service model is used to 233 describe a service as offer or delivered to a customer by a 234 network operator. 235 Service Delivery Model: A service delivery model is used by a 236 network operator to define and configure how a service is 237 provided by the network. 239 Internet-Draft ACTN YANG February 20211 241 Network Configuration Model: A network configuration model is 242 used by a network orchestrator to provide network-level 243 configuration model to a controller. 244 Device Configuration Model: A device configuration model is 245 used by a controller to configure physical network elements. 247 Customer 248 ------------------ Service ---------- 249 | | Model | | 250 | Service |<-------->| Customer | 251 | Orchestrator | | | 252 | | ---------- 253 ------------------ 254 . . ----------- 255 . . ......|Application| 256 . . : | BSS/OSS | 257 . . : ----------- 258 . Service Delivery . : 259 . Model . : 260 ------------------ ------------------ 261 | | | | 262 | Network | | Network | 263 | Orchestrator | | Orchestrator | 264 | | | | 265 .------------------ ------------------. 266 . : : . 267 . : Network Configuration : . 268 . : Model : . 269 ------------ ------------ ------------ ------------ 270 | | | | | | | | 271 | Controller | | Controller | | Controller | | Controller | 272 | | | | | | | | 273 ------------ ------------ ------------ ------------ 274 : . . : : 275 : . . Device : : 276 : . . Configuration : : 277 : . . Model : : 278 --------- --------- --------- --------- --------- 279 | Network | | Network | | Network | | Network | | Network | 280 | Element | | Element | | Element | | Element | | Element | 281 --------- --------- --------- --------- --------- 283 Figure 2: An SDN Architecture with a Service Orchestrator 285 Internet-Draft ACTN YANG February 20211 287 4. Service Model Mapping to ACTN 289 YANG models coupled with the RESTCONF/NETCONF protocol 290 [RFC6241][RFC8040] provides solutions for the ACTN framework. This 291 section explains which types of YANG models apply to each of the 292 ACTN interfaces. 294 Refer to Figure 5 of [RFC8453] for details of the mapping between 295 ACTN functions and service models. In summary, the following 296 mappings are held between and Service Yang Models in [RFC8309] and 297 the ACTN interfaces in [RFC8453]. 299 o Customer Service Model <-> CMI 300 o Network Configuration Model <-> MPI 301 o Device Configuration Model <-> SBI 303 4.1. Customer Service Models in the ACTN Architecture (CMI) 305 Customer Service Models, which are used between a customer and a 306 service orchestrator as in [RFC8309], should be used between the CNC 307 and MDSC (e.g., CMI) serving as providing a simple intent-like 308 model/interface. 310 Among the key functions of Customer Service Models on the CMI is the 311 service request. A request will include specific service properties, 312 including: service type and its characteristics, bandwidth, 313 constraint information, and end-point characteristics. 315 The following table provides a list of functions needed to build the 316 CMI. They are mapped with Customer Service Models. 318 Function Yang Model 319 ----------------------------------------------------------- 320 VN Service Request [ACTN-VN-YANG] 321 VN Computation Request [ACTN-VN-YANG]* 322 TE & Service Mapping [TE-Service-Mapping]** 323 VN Performance Monitoring Telemetry [ACTN-PM-Telemetry]*** 324 Topology Abstraction [RFC8795]**** 325 Layer 1 Connectivity Service Model [L1CSM] 326 Layer 2 VPN Service Model [RFC8466] 327 Layer 3 VPN Service Model [RFC8299] 329 Internet-Draft ACTN YANG February 20211 331 *VN computation request in the CMI context means network path 332 computation request based on customer service connectivity request 333 constraints prior to the instantiation of a VN creation. 335 **[TE-Service-Mapping] provides a mapping and cross-references 336 between service models (e.g., L3SM, L2SM, L1CSM) and TE model via 337 [ACTN-VN-YANG] and [RFC8795]. This model can be used as either 338 Customer Service Models, or Service Delivery model described in 339 Section 4.2. 341 ***ietf-actn-te-kpi-telemetry model in [ACTN-PM-Telemetry] describes 342 performance telemetry for ACTN VN model. This module also allows 343 autonomic traffic engineering scaling intent configuration mechanism 344 on the VN level. Scale in/out criteria might be used for network 345 autonomics in order the controller to react to a certain set of 346 variations in monitored parameters. Moreover, this module also 347 provides mechanism to define aggregated telemetry parameters as a 348 grouping of underlying VN level telemetry parameters. 350 ****RFC8795's Connectivity Matrices/Matrix construct can be used to 351 instantiate VN Service via a suitable referencing and mapping with 352 [ACTN-VN-YANG]. 354 4.2. Service Delivery Models in ACTN Architecture 356 The Service Delivery Models where the service orchestration and the 357 network orchestration could be implemented as separate components as 358 seen in [RFC8309]. On the other hand, from an ACTN architecture 359 point of view, the service delivery model between the service 360 orchestrator and the network orchestrator is an internal interface 361 between sub-components of the MDSC in a single MDSC model. 363 In the MDSC hierarchical model where there are multiple MDSCs, the 364 interface between the top MDSC and the bottom MDSC can be mapped to 365 service delivery models. 367 4.3. Network Configuration Models in ACTN Architecture (MPI) 369 The Network Configuration Models is used between the network 370 orchestrator and the controller in [RFC8309]. In ACTN, this model is 371 used primarily between a MDSC and a PNC. The Network Configuration 372 Model can be also used for the foundation of more advanced models, 373 like hierarchical MDSCs (see Section 4.5) 375 The Network Configuration Model captures the parameters which are 376 network wide information. 378 Internet-Draft ACTN YANG February 20211 380 The following table provides a list of functions needed to build the 381 MPI. They are mapped with Network Configuration Yang Models. Note 382 that various Yang models are work in progress. 384 Function Yang Model 385 -------------------------------------------------------- 386 Configuration Scheduling [Schedule] 387 Path computation [PATH_COMPUTATION-API] 388 Tunnel/LSP Provisioning [TE-tunnel] 389 Topology Abstraction [RFC8795] 390 Service Provisioning [Client-signal]&[TE-tunnel]* 392 Client Topology Abstraction [Client-topo] 393 OTN Topology Abstraction [OTN-topo] 394 WSON Topology Abstraction [WSON-topo] 395 Flexi-grid Topology Abstraction [Flexi-topo] 396 Microwave Topology Abstraction [MW-topo] 397 Client Signal Description [Client-signal] 398 OTN Tunnel Model [OTN-Tunnel] 399 WSON TE Tunnel Model [WSON-Tunnel] 400 Flexi-grid Tunnel Model [Flexigrid-Tunnel] 402 * This function is a combination of tunnel set up and client signal 403 description. Usually a tunnel is setting up first to get prepared to 404 carry a client signal, in order to do the service provisioning. Then 405 the client signal is adapted to the established tunnel. It is worth 406 noting that various tunnel models such as [OTN-Tunnel] and [WSON- 407 Tunnel] can be used together with the [TE-tunnel] model to construct 408 technology-specific tunnels, and carry different types of client 409 signals. More details can be found in [Client-signal]. 411 [TE-topo-tunnel] provides the clarification and example usage for TE 412 topology model [RFC8795] and TE tunnel model [TE-tunnel]. [T-NBI 413 Applicability] provides a summary on the applicability of existing 414 YANG model usage in the current network configuration, especially 415 for transport network. 417 4.4. Device Models in ACTN Architecture (SBI) 419 Note that SBI is not in the scope of ACTN, as there is already 420 mature protocol solutions for various purpose on the device level of 421 ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The 422 interworking of such protocols and ACTN controller hierarchies can 423 be found in [gmpls-controller-inter-work]. 425 Internet-Draft ACTN YANG February 20211 427 For the device YANG models are used for per-device configuration 428 purpose, they can be used between the PNC and the physical 429 network/devices. One example of Device Models is ietf-te-device yang 430 module defined in [TE-tunnel]. 432 5. Examples of Using Different Types of YANG Models 434 This section provides some examples on the usage of IETF YANG models 435 in the network operation. A few typical generic scenarios are 436 involved. In [T-NBI Applicability], there are more transport-related 437 scenarios and examples. 439 5.1. Topology Collection 441 Before any connection is requested and delivered, the controller 442 needs to understand the network topology. The topology information 443 is exchanged among controllers with topology models, such as 444 [RFC8795]. Moreover, technology-specific topology reporting may use 445 the model described in [OTN-topo] [WSON-topo], and [Flexi-topo] for 446 OTN, WSON and Flexi-grid, respectively. By collecting the network 447 topology, each controller can therefore construct a local database, 448 which can be used for the further service deployment. 450 There can be different types of abstraction applied between each 451 pair of controllers, corresponding method can be found in [RFC8453]. 452 The technology-specific features may be hidden after abstraction, to 453 make the network easier for the user to operate. 455 When there is a topology change in the physical network, the PNC 456 should report the change to upper level of controllers via updating 457 messages using topology models. Accordingly, such changes is 458 propagated between different controllers for further 459 synchronization. 461 5.2. Connectivity over Two Nodes 463 The service models, such as described in [RFC8299], [RFC8466] and 464 [L1CSM] provide a customer service model which can be used in 465 provider networks. 467 It would be used as follows in the ACTN architecture: 469 A CNC uses the service models to specify the two client nodes 470 that are to be connected, and also indicates the amount of 471 traffic (i.e., the bandwidth required) and payload type. What 473 Internet-Draft ACTN YANG February 20211 475 may be additionally specified is the SLA that describes the 476 required quality and resilience of the service. 478 The MDSC uses the information in the request to pick the right 479 network (domain) and also to select the provider edge nodes 480 corresponding to the customer edge nodes. 482 If there are multiple domains, then the MDSC needs to 483 coordinate across domains to set up network tunnels to deliver 484 a service. Thus coordination includes, but is not limited to, 485 picking the right domain sequence to deliver a service. 487 Additionally, an MDSC can initiate the creation of a tunnel (or 488 tunnel segment) in order to fulfill the service request from 489 CNC based on path computation upon the overall topology 490 information it synthesized from different PNCs. The based model 491 that can cater this purpose is the TE tunnel model specified in 492 [TE-tunnel]. Technology-specific tunnel configuration may use 493 the model described in [OTN-Tunnel] [WSON-Tunnel], and 494 [Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively. 496 Then, the PNCs need to decide the explicit route of such a 497 tunnel or tunnel segment (in case of multiple domains) for each 498 domain, and then create such a tunnel using protocols such as 499 PCEP and RSVP-TE or using per-hop configuration. 501 5.3. VN example 503 The service model defined in [ACTN-VN-YANG] describes a virtual 504 network (VN) as a service which is a set of multiple connectivity 505 services: 507 A CNC will request VN to the MDSC by specifying a list of VN 508 members. Each VN member specifies either a single connectivity 509 service, or a source with multiple potential destination points 510 in the case that the precise destination sites are to be 511 determined by MDSC. 513 o In the first case, the procedure is the same as the 514 connectivity service, except that in this case, there is a 515 list of connections requested. 517 o In the second case, where the CNC requests the MDSC to 518 select the right destination out of a list of candidates, 519 the MDSC needs to evaluate each candidate and then choose 520 the best one and reply with the chosen destination for a 521 given VN member. After this is selected, the connectivity 523 Internet-Draft ACTN YANG February 20211 525 request setup procedure is the same as in the connectivity 526 example in section 5.2. 528 After the VN is set up, a successful reply message is sent from MDSC 529 to CNC, indicating the VN is ready. This message can also be 530 achieved by using the model defined in [ACTN-VN-YANG]. 532 5.4. Data Center-Interconnection Example 534 This section describes more concretely how existing YANG models 535 described in Section 4 map to an ACTN data center interconnection 536 use case. Figure 3 shows a use-case which shows service policy- 537 driven Data Center selection and is a reproduction of Figure A.1 538 from [RFC8454]. 540 Internet-Draft ACTN YANG February 20211 542 +----------------+ 543 | CNC | 544 | (Global DC | 545 | Operation | 546 | Control) | 547 +--------+-------+ 548 | | VN Requirement/Policy: 549 CMI: | | - Endpoint/DC location info 550 Service model | | - Endpoint/DC dynamic 551 | | selection policy 552 | | (for VM migration, DR, LB) 553 | v 554 +---------+---------+ 555 | Multi-domain | Service policy-driven 556 |Service Coordinator| dynamic DC selection 557 MPI: +-----+---+---+-----+ 558 Network Configuration | | | 559 Model | | | 560 +----------------+ | +---------------+ 561 | | | 562 +-----+-----+ +------+-----+ +------+-----+ 563 | PNC for | | PNC for | | PNC for | 564 | Transport | | Transport | | Transport | 565 | Network A | | Network B | | network C | 566 +-----------+ +------------+ +------------+ 567 Device | | | 568 Model | | | 569 | | | 570 +---+ ------ ------ ------ +---+ 571 |DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5| 572 +---+ | | | | | | +---+ 573 | TN A +-----+ TN B +----+ TN C | 574 / | | | | | 575 / \\\\ //// / \\\\ //// \\\\ //// 576 +---+ ------ / ------ \ ------ \ 577 |DC2| / \ \+---+ 578 +---+ / \ |DC6| 579 +---+ \ +---+ +---+ 580 |DC3| \|DC4| 581 +---+ +---+ 583 DR: Disaster Recovery 584 LB: Load Balancing 586 Figure 3: Service Policy-driven Data Center Selection 588 Internet-Draft ACTN YANG February 20211 590 Figure 3 shows how VN policies from the CNC (Global Data Center 591 Operation) are incorporated by the MDSC to support multi-destination 592 applications. Multi-destination applications refer to applications 593 in which the selection of the destination of a network path for a 594 given source needs to be decided dynamically to support such 595 applications. 597 Data Center selection problems arise for VM mobility, disaster 598 recovery and load balancing cases. VN's policy plays an important 599 role for virtual network operation. Policy can be static or dynamic. 600 Dynamic policy for data center selection may be placed as a result 601 of utilization of data center resources supporting VMs. The MDSC 602 would then incorporate this information to meet the objective of 603 this application. 605 5.4.1. CMI (CNC-MDSC Interface) 607 [ACTN-VN-YANG] is used to express the definition of a VN, its VN 608 creation request, the service objectives (metrics, QoS parameters, 609 etc.), dynamic service policy when VM needs to be moved from one 610 Data Center to another Data Center, etc. This service model is used 611 between the CNC and the MDSC (CMI). The CNC in this use-case is an 612 external entity that wants to create a VN and operates on the VN. 614 5.4.2. MPI (MDSC-PNC Interface) 616 The Network Configuration Model is used between the MDSC and the 617 PNCs. Based on the Customer Service Model's request, the MDSC will 618 need to translate the service model into the network configuration 619 model to instantiate a set of multi-domain connections between the 620 prescribed sources and the destinations. The MDSC will also need to 621 dynamically interact with the CNC for dynamic policy changes 622 initiated by the CNC. Upon the determination of the multi-domain 623 connections, the MDSC will need to use the network configuration 624 model such as [TE-tunnel] to interact with each PNC involved on the 625 path. [RFC8795] is used to for the purpose of underlying domain 626 network abstraction from the PNC to the MDSC. 628 5.4.3. SBI (Southbound interface between PNC and devices) 630 The Device Model can be used between the PNC and its underlying 631 devices that are controlled by the PNC. The PNC will need to trigger 632 signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to 633 provision its domain path segment. There can be a plethora of 634 choices how to control/manage its domain network. The PNC is 635 responsible to abstract its domain network resources and update it 637 Internet-Draft ACTN YANG February 20211 639 to the MDSC. Note that this interface is not in the scope of ACTN. 640 This section is provided just for an illustration purpose. 642 6. Security 644 This document is an informational draft. When the models mentioned 645 in this draft are implemented, detailed security consideration will 646 be given in such work. 648 How security fits into the whole architecture has the following 649 components: 651 - the use of Restconf security between components 653 - the use of authentication and policy to govern which services can 654 be requested by different parties. 656 - how security may be requested as an element of a service and 657 mapped down to protocol security mechanisms as well as separation 658 (slicing) of physical resources) 660 7. IANA Considerations 662 This document requires no IANA actions. 664 8. Acknowledgements 666 We thank Adrian Farrel for providing useful comments and suggestions 667 for this draft. 669 9. References 671 9.1. Informative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, DOI 675 10.17487/RFC2119, March 1997, 676 . 678 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 679 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 680 May 2017, . 682 [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", 683 RFC 8309. 685 Internet-Draft ACTN YANG February 20211 687 [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module 688 Classification", RFC 8199. 690 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 691 and A. Bierman, Ed., "Network Configuration Protocol 692 (NETCONF)", RFC 6241. 694 [RFC8040] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 695 Protocol", RFC 8040. 697 [RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and 698 Control of Traffic Engineered Networks", RFC8453. 700 [RFC8466] B. Wen, G. Fioccola, C. Xie, L. Jalil, "A YANG Data Model 701 for L2VPN Service Delivery", RFC8466. 703 [RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, K.Ogaki, "YANG Data 704 Model for L3VPN Service Delivery", RFC8299. 706 [RFC8454] Y. Lee & S. Belotti, "Information Model for Abstraction 707 and Control of TE Networks (ACTN)", RFC8454. 709 [RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource 710 Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp, 711 work in progress. 713 [RFC8795] X. Liu, et. al., "YANG Data Model for TE Topologies", 714 RFC8795. 716 [TE-tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 717 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 718 te, work in progress. 720 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 721 Operation", draft-lee-teas-actn-vn-yang, work in progress. 723 [L1CSM] G. Fioccola, K. Lee, Y. Lee, D. Dhody, O. Gonzalez de-Dios, 724 D. Ceccarelli, "A Yang Data Model for L1 Connectivity 725 Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work 726 in progress. 728 [Schedule] X. Liu, et. al., "A YANG Data Model for Configuration 729 Scheduling", draft-liu-netmod-yang-schedule, work in 730 progress. 732 Internet-Draft ACTN YANG February 20211 734 [OTN-topo] H. Zheng, et. al., "A YANG Data Model for Optical 735 Transport Network Topology", draft-ietf-ccamp-otn-topo- 736 yang, work in progress. 738 [WSON-topo] Y. Lee, et. al., "A Yang Data Model for WSON Optical 739 Networks", draft-ietf-ccamp-wson-yang, work in progress. 741 [Flexi-topo] J.E. Lopez de Vergara, et. al., "YANG data model for 742 Flexi-Grid Optical Networks", draft-ietf-ccamp-flexigrid- 743 yang, work in progress. 745 [MW-topo] M. Ye, et. al., "A YANG Data Model for Microwave 746 Topology", draft-ietf-ccamp-mw-topo-yang, work in 747 progress. 749 [OTN-Tunnel] H. Zheng, et. al., "OTN Tunnel YANG Model", draft- 750 ietf-ccamp-otn-tunnel-model, work in progress. 752 [ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D. 753 King, and D. Ceccarelli, "YANG models for ACTN TE 754 Performance Monitoring Telemetry and Network Autonomics", 755 draft-ietf-teas-actn-pm-telemetry-autonomics, work in 756 progress. 758 [WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R. 759 Vilalta, "A Yang Data Model for WSON Tunnel", draft-ietf- 760 ccamp-wson-tunnel-model, work in progress. 762 [Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de 763 Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model 764 for Flexi-Grid media-channels", draft-ietf-ccamp- 765 flexigrid-media-channel-yang, work in progress. 767 [Client-signal] H. Zheng, et al, "A YANG Data Model for Optical 768 Transport Network Client Signals", draft-ietf-ccamp- 769 client-signal-yang, work in progress. 771 [Client-topo] H. Zheng, et al, "A YANG Data Model for Ethernet TE 772 Topology", draft-zheng-ccamp-client-topo-yang, work in 773 progress. 775 [TE-topo-tunnel] I.Bryskin, et. al., "TE Topology and Tunnel 776 Modeling for Transport Networks", draft-ietf-teas-te-topo- 777 and-tunnel-modeling, work in progress. 779 Internet-Draft ACTN YANG February 20211 781 [T-NBI Applicability] I. Busi, et al, "Transport Northbound 782 Interface Applicability Statement and Use Cases", draft- 783 ietf-ccamp-transport-nbi-app-statement, work in progress. 785 [gmpls-controller-inter-work] H. Zheng, et al, "Interworking of 786 GMPLS Control and Centralized Controller System", draft- 787 ietf-teas-gmpls-controller-inter-work, work in progress. 789 10. Contributors 791 Contributor's Addresses 793 Dhruv Dhody 794 Huawei Technologies 796 Email: dhruv.ietf@gmail.com 798 Xian Zhang 799 Huawei Technologies 801 Email: zhang.xian@huawei.com 803 Oscar Gonzalez de Dios 804 Telefonica 805 Email: oscar.gonzalezdedios@telefonica.com 807 Jong Yoon Shin 808 SKT 809 Email: jongyoon.shin@sk.com 811 Authors' Addresses 813 Young Lee 814 Samsung 815 Korea 816 Email: younglee.tx@gmail.com 818 Haomian Zheng 819 Huawei Technologies 820 Email: zhenghaomian@huawei.com 822 Internet-Draft ACTN YANG February 20211 824 Daniele Ceccarelli 825 Ericsson 826 Torshamnsgatan,48 827 Stockholm, Sweden 828 Email: daniele.ceccarelli@ericsson.com 830 Bin Yeong Yoon 831 ETRI 832 Email: byyun@etri.re.kr 834 Sergio Belotti 835 Nokia 836 Email: sergio.belotti@nokia.com