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