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