idnits 2.17.1 draft-zhang-ccamp-transport-yang-gap-analysis-01.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 : ---------------------------------------------------------------------------- ** There are 29 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 31, 2016) is 2732 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TE-topo' is mentioned on line 538, but not defined == Missing Reference: 'WDM-Topo' is mentioned on line 553, but not defined == Missing Reference: 'ODU-Topo' is mentioned on line 554, but not defined == Missing Reference: 'TE-Tunnel' is mentioned on line 575, but not defined == Missing Reference: 'RESTCONF' is mentioned on line 650, but not defined == Unused Reference: 'I-D.ietf-netconf-restconf' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 692, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-13 == Outdated reference: A later version (-03) exists of draft-busibel-teas-yang-path-computation-00 == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-wson-yang-01 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-02 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-04 == Outdated reference: A later version (-13) exists of draft-lee-teas-actn-vn-yang-01 == Outdated reference: A later version (-07) exists of draft-zhang-ccamp-l1-topo-yang-01 == Outdated reference: A later version (-05) exists of draft-zhang-teas-actn-yang-01 == Outdated reference: A later version (-01) exists of draft-zhang-teas-transport-service-model-00 Summary: 1 error (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group X. Zhang, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Informational A. Sharma, Ed. 5 Expires: May 4, 2017 Infinera 6 S. Belotti 7 Nokia 8 T. Cummings 9 Ericsson 10 October 31, 2016 12 YANG Models for the Northbound Interface of a Transport Network 13 Controller: Requirements and Gap Analysis 14 draft-zhang-ccamp-transport-yang-gap-analysis-01 16 Abstract 18 A transport network is a lower-layer network designed to provide 19 connectivity services for a higher-layer network to carry the traffic 20 opaquely across the lower-layer network resources. A transport 21 network may be constructed from equipment utilizing any of a number 22 of different transport technologies such as the optical transport 23 infrastructure (Synchronous Optical Networking (SONET) / Synchronous 24 Digital Hierarchy (SDH) and Optical Transport Network (OTN)) or 25 packet transport as epitomized by the MPLS Transport Profile (MPLS- 26 TP). 28 All transport networks have high benchmarks for reliability and 29 operational simplicity. This suggests a common, technology- 30 independent management/control paradigm that can be extended to 31 represent and configure specific technology attributes. 33 This document describes the high-level requirements facing transport 34 networks in order to provide open interfaces for resource 35 programmability and control/management automation. Furtheremore, gap 36 analysis against existing models are also provided so that it can 37 used as the guidance to separate efforts/drafts proposing new models 38 or augmentation models based on existing models. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on May 4, 2017. 57 Copyright Notice 59 Copyright (c) 2016 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. High-level Modeling Requirements . . . . . . . . . . . . . . 5 77 3.1. Generic Requirements . . . . . . . . . . . . . . . . . . 5 78 3.2. Transport Network and TE Topology Requirements . . . . . 6 79 3.2.1. Topological Link Requirements . . . . . . . . . . . . 6 80 3.2.2. Topology Node Requirements . . . . . . . . . . . . . 6 81 3.2.3. Termination Point Requirements . . . . . . . . . . . 6 82 3.3. Transport Service Requirements . . . . . . . . . . . . . 7 83 3.4. Tunnel/LSP Requirements . . . . . . . . . . . . . . . . . 7 84 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 4.1. Single-domain Scenario . . . . . . . . . . . . . . . . . 7 86 4.2. Multi-domain Scenario . . . . . . . . . . . . . . . . . . 9 87 4.3. Multi-layer Scenario . . . . . . . . . . . . . . . . . . 11 88 4.4. Function Summary and Related YANG Models . . . . . . . . 11 89 5. Function Gap Analysis on YANG Model Level . . . . . . . . . . 12 90 5.1. Topology Related Functions . . . . . . . . . . . . . . . 12 91 5.1.1. Obtaining Access Point Info . . . . . . . . . . . . . 13 92 5.1.2. Obtaining Topology . . . . . . . . . . . . . . . . . 13 93 5.1.3. Virtual Network Operations . . . . . . . . . . . . . 13 94 5.2. Tunnel Operations . . . . . . . . . . . . . . . . . . . . 14 95 5.3. Service Requests . . . . . . . . . . . . . . . . . . . . 14 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 98 8. Manageability Considerations . . . . . . . . . . . . . . . . 15 99 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 100 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 103 11.2. Informative References . . . . . . . . . . . . . . . . . 16 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 106 1. Introduction 108 A transport network is a server-layer network designed to provide 109 connectivity services, or more advanced services like Virtual Private 110 Networks (VPN) for a client-layer network to carry the client traffic 111 opaquely across the server-layer network resources. It acts as a 112 pipe provider for upper-layer networks, such as IP network and mobile 113 networks. 115 Transport networks, such as Synchronous Optical Networking (SONET) / 116 Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), 117 Wavelength Division Multiplexing (WDM), and flexi-grid networks, are 118 often built using equipments from a single vendor and are managed 119 using proprietary interfaces to dedicated Element Management Systems 120 (EMS) / Network Management Systems (NMS). All transport networks 121 have high benchmarks for reliability and operational simplicity. 122 This suggests a common, technology-independent management/control 123 paradigm that is extended to represent and configure specific 124 technology attributes. 126 Network providers need a common way to manage multi-vendor and multi- 127 domain transport networks (where each domain is an island of 128 equipments from a single supplier) and this requirement has been 129 further stressed by the expansion in network size. At the same time, 130 applications such as data center interconnection require larger and 131 more dynamic connectivities. Therefore, transport networks face new 132 challenges going beyond automatic provisioning of tunnel setup 133 enabled by GMPLS (Generalized Multi-Protocol Label Switching) 134 protocols to achieve automatic service provisioning, as well as 135 address opportunities enabled by partitioning the transport network 136 through the process of resource slicing. With a reduction in 137 operational expenditure (OPEX) and capital expenditure (CAPEX) as the 138 usual objectives, a common interface to transport network controllers 139 are considered by network providers as a way to meet the 140 requirements. The concept of Software Defined Networking (SDN) 141 leverages these ideas. 143 The YANG language [RFC6020] is currently the data modeling language 144 of choice within the IETF and has been adopted by a number of 145 industry-wide open management and control initiatives. YANG may be 146 used to model both configuration and operational states; it is 147 vendor-neutral and supports extensible APIs for control and 148 management of elements. 150 This document first specifies the scope and provides high-level 151 requirements for transport network open interface modelling. 152 Furthermore, detailed gap analysis of the typical scenarios with the 153 existing model are provided. Thus, this document can used as a 154 reference of existing models, and provides information of the missing 155 ones which suggest further work. 157 2. Scope 159 For this draft, we use the domain controller as the reference point, 160 with South Bound Interface (SBI) to the transport devices and North 161 Bound Interface (NBI) to the orchestrator. 163 Transport networks have been evolving and deploying for decades, 164 making them very heterogeneous. New and legacy transport devices 165 support many protocols such as Path Computation Element Protocol 166 (PCEP), TL1, SNMP, CLI, XML, NETCONF, Openflow etc. Domain 167 controllers interfacing with transport devices need to support these 168 protocols on its SBI, making the southbound fragmented. Domain 169 controllers abstract the fragmented southbound view for its 170 northbound clients by normalizing the NBI across various 171 technologies, protocols, and vendors. The focus of this document is 172 not to go into various southbound protocols to interface with the 173 transport devices. Instead, this document focuses on the models that 174 can be used by the domain controller and the orchestrator for various 175 use cases identified in later sections of this document. 177 There is an ongoing unofficial weekly meeting among a group of 178 individuals (see the github files [Transport-modeling-github] for 179 more meeting minutes and materials produced), focusing on the efforts 180 of analyzing the IETF models against a list of well known use cases 181 to identify gaps. This document captures this efforts and summarized 182 the main work and key findings of this group work. 184 YANG models are currently developed not only in IETF, but also in 185 other Standard Development Organizations (SDO) such as ONF and MEF, 186 which can be used on the interfaces of a domain controller and an 187 orchestrator. Each domain controller and orchestrator can use models 188 developed by different SDOs. Therefore it is important to ensure 189 that deployment use cases and related funcionalities are supported by 190 all models to allow a seamless translation/mediation between systems 191 using different models. 193 If the Abstraction and Control of Traffic-Engineered Networks (ACTN) 194 defined in [I-D.ceccarelli-teas-actn-framework] is used as a 195 reference architcture, then the focus is equivalent to MPI (MDSC-PNC 196 Interface) and CMI (CNC-MDSC Interface). More details about the 197 relationship of the type of models and the type of ACTN interfaces 198 can be found in [I-D.zhang-teas-actn-yang]. 200 3. High-level Modeling Requirements 202 This section covers various high-level modeling requirements for 203 transport networks. 205 3.1. Generic Requirements 207 The following are generic requirements for transport models: 209 o User Intent: Transport models should maintain separation between 210 high level user intent and the operational state of the network. 211 For example, maintaining separation between user service request, 212 including all constraints, and the actual service and connection 213 state in the network. 215 o State Management: Network and service objects should support the 216 following states: administrative state, operational state, and 217 lifecycle state. Administrative state and operational states are 218 well understood. Lifecycle state is defined in the ONF and it is 219 used to track the planned deployment allocation of the related 220 entity in the model as well as withdrawal of resources. Here the 221 lifecylce state includes planned state, potential state, installed 222 state, and pending removal state. 224 o Identifiers: Network and service objects should support the 225 following identifier: 227 * ID: A unique entity ID provided by the controller. The 228 identifier SHOULD be chosen such that the same entity in a real 229 network topology will always be identified through the same ID, 230 even if the model is instantiated in separate datastores. 231 Controller may choose to capture semantics in the identifier, 232 for example to indicate the type of entity and/or the type of 233 the parent identity. 235 * Name: A unique name provided by the client for the entity. The 236 name can be modified, if required, by the client. 238 * User Labels: A list of freeform strings that can be used as 239 alias for the entity by the client. Multiple user labels are 240 permitted for the entity, and client can edit these user 241 labels. User labels do not need to be unique. 243 3.2. Transport Network and TE Topology Requirements 245 3.2.1. Topological Link Requirements 247 The model should support the following Topological Links: 249 o Physical Links 251 o Abstract Links [RFC7926] 253 o Compound Link which are are internally aggregated lower level 254 links 256 o Access Links which connect the router port to the client port of 257 the transport system 259 o Transitional Links which provide adaptation capability between 260 layers within a network element 262 The Link should support various link related attributes like cost, 263 latency, capacity, risk characteristics (including shared risk). The 264 model should provide clear association between Link and its topology 265 (including virtual topology), nodes and termination points. 267 The model should provide association between the link and any 268 underlay circuit / service supporting the Link. 270 3.2.2. Topology Node Requirements 272 The model should support the following Topology Node: 274 o Physical Node 276 o Abstract Node 278 o Chassis / Forwarding Domain 280 [Editors' note: more details will be added later, which can be found 281 in [Transport-requirements-github].] 283 3.2.3. Termination Point Requirements 285 [Editors' note: this will be added later, which can be found in 286 [Transport-requirements-github].] 288 3.3. Transport Service Requirements 290 [Editors' note: this will be added later, which can be found in 291 [Transport-requirements-github].] 293 3.4. Tunnel/LSP Requirements 295 [Editors' note: this will be added later which can be found in 296 [Transport-requirements-github].] 298 4. Scenarios 300 There are several scenarios (a.k.a., use cases) where an open 301 interface via domain controller to access server-layer (transport) 302 network resources would be useful. Three scenarios are provided and 303 can be used for model instantiation exercise to identify missing 304 pieces of existing models. Note the models provided in this draft is 305 for explanation purpose, the group effort actually uses slight 306 different network examples for gap analysis exercise (see 307 [Transport-usecases-github] for more details). 309 4.1. Single-domain Scenario 311 The first scenario is depicted as below (Figure 1 ): 313 /--\ +------+ +------+ /--\ 314 | 1 ~~~| A +------------------| B |~~~~~ 3 | 315 \--/ +-----++ +--+---+ \--/ 316 | | 317 | | 318 | | 319 ++-----+ +---+--+ 320 | F +------------+ C | 321 ++-----+ +--+---+ 322 | | 323 | | 324 | | 325 | | 326 | | 327 +---+-+ +---+-+ /---\ 328 | E +---------------+ D |~~~~ 4 | 329 /--\~~~~~+-----+ +-----+ \---/ 330 | 2 | 331 \--/ 333 +----+ /--\ 334 | | Transport NE | | DC 335 +----+ \--/ 337 ----- Transport Link ~~~ Transport-DC link 339 (a) Data Centers interconnected via a transport network 341 +---------------------+ 342 | Data Center Network | 343 | Controller | 344 +---------+-----------+ 345 | 346 | 347 | 348 | Open Interface 349 | 350 | 351 +---------+-----------+ 352 | Transport Network | 353 | Controller | 354 +---------------------+ 355 (b) The controller architecture for data center interconnection 357 Figure 1: Scenario 1: Data centers interconnected via a transport 358 network and the controller architecture 360 For the data center operator, as a client of the transport network, 361 assuming the objective is to trigger the transport network to provide 362 connectivity on demand, the following capabilities, at a minimum, 363 would be required on the common interface between the two controllers 364 illustrated in Figure 1: 366 o The ability to obtain information about a set of access points of 367 the transport network, including information such as access point 368 identifiers, capabilities, etc.; for instance, transport-network- 369 side end point identifiers related to the access link between DC1 370 and Transport NE A. 372 o The capability to send a request for a service using the 373 aforementioned access point information, as well as the ability to 374 retrieve a list of service requests and their status. In this 375 request, it should at least be possible to include source node, 376 destination node, and requested bandwidth to request the transport 377 network to set up tunnels/paths so as to provide the requested 378 connectivity for the service request. 380 o Note that in this case, the acquisition of the topology, be it 381 physical or logical, of the transport network is not a compulsory 382 requirement, but it may indeed be able to give data center 383 providers more control over the transport resource usage. 384 Furthermore, the client controller can impose a virtual network of 385 its own choice by requesting a slice of network resource with its 386 choice of network parameters (such as network topology type, 387 bandwidth etc.). 389 4.2. Multi-domain Scenario 391 The second scenario, more complicated than the first, is depicted as 392 below (Figure 2). In this example, we focus on the management and 393 control via common interfaces for multi-domain networks with 394 homogeneous technologies (such as OTN), but it can be extended 395 further to multi-domain networks with heterogeneous technologies with 396 higher complexity. 398 +-------------------------------------------------+ 399 | Orchestrator/Coordinator | 400 +---------+--------------+-------------------+----+ 401 | | | 402 | | | 403 +------------+--+ | +----------+----------+ 404 | Controller 1 | | | Controller 2 | 405 +---------+-----+ | +-------+-------------+ 406 # +----------------+ # 407 #Qx | Controller 3 | # 408 # +----------------+ #TL1 409 # # # 410 ----+----- # ----+----- 411 ____/ \____ # ____/ \____ 412 | | # | | 413 | | # | | 414 | Network Domain +***********+ Network Domain | 415 | 1 | # | 2 | 416 |____ ___| # |____ ___| 417 \ / #PCEP \ / 418 ----------- # *---------- 419 * * # * * 420 * * # * * 421 * * # * * 422 * * # * * 423 * * # * * 424 * * # * * 425 * *----+-----* * 426 * ____/ \____ * 427 *| |* 428 | | 429 | Network Domain | 430 | 3 | 431 |____ ___| 432 \ / 433 ---------- 435 ***** inter-domain links 436 ----- Open Interfaces 437 ##### Controller-device interfaces 439 Figure 2: Scenario 2: Multi-domain network control and management 441 For the second scenario, the orchestrator controls and manages three 442 distinct network domains, each controlled/managed by their domain 443 controller. This scenario is of interest not only to transport-only 444 networks, but also to heretegenous network orchestration such as 445 coordinating the transport, the radio (5G) and packet core domains. 446 But to keep the functions explanation later accurate, only transport- 447 only multi-domain networks are considered. 449 In order to orchestrate across domains/layers, besides the 450 capabilities mentioned for the first scenario, the orchestrator needs 451 its interface between domain controllers to be equipped with the 452 following additional functions: 454 o Access to the topologies reported by each domain controller, 455 including cross-domain links for the purpose of planning and 456 requesting the paths of end-to-end tunnels. Depending on the 457 abstraction level of the reported topology, the orchestrator has 458 different control granularities. 460 o Alterntively, the capability for the orchestrator to request "path 461 computation" to a domain controller in order to create an end-to- 462 end tunnel stitched together by different connection contribution 463 obtained by consulting to each domain controller. 465 o The ability to set up, delete and modify tunnels, be it within one 466 domain or across multiple domains. Furthermore, it should have 467 the abilty to view the tunnels created within each domain as well 468 as those that cross domains as reported by each domain controller. 470 4.3. Multi-layer Scenario 472 In the first use case, if there are multiple technologies invovled, 473 then it can be considered as a multi-layer case. [Editors' note: 474 more details to be added later, some can be found in 475 [Transport-usecases-github].] 477 4.4. Function Summary and Related YANG Models 479 For the common interface of a transport controller towards a 480 northbound client, six main functions are derived from the scenarios 481 explained in the last section. They are summarized in the table 482 below and we also match these functions with YANG models that are 483 being developed in existing drafts. 485 +-------------+-----------------------+---------------------------+ 486 | Functions | Description | Related Existing | 487 | | | YANG Models | 488 |-------------+-----------------------+---------------------------+ 489 | Obtaining |Getting the necessary | ietf-network.yang | 490 | Access |access points info | ietf-network-topology.yang| 491 | Point Info | | ietf-te-topology.yang | 492 +-------------+-----------------------+---------------------------+ 493 | Obtaining |Getting the topology | ietf-te-topology.yang | 494 | Topology |info | ietf-otn-topology.yang | 495 | | | ietf-wson-topology.yang | 496 +-------------+-----------------------+---------------------------+ 497 | Tunnel |Tunnel Setup, Deletion | | 498 | Operations |Modification and Info | ietf-te.yang | 499 | |Retrieval | ietf-otn-tunnel.yang | 500 +-------------+-----------------------+---------------------------+ 501 | Service |Requesting connectivity| | 502 | Request |service and retrieval |ietf-transport-service.yang| 503 | |the list of service | ietf-actn-vn.yang | 504 | |request | | 505 +-------------+-----------------------+---------------------------+ 506 |Path Comp. | Path Computation pre | | 507 | | service provisioning | ietf-te.yang | 508 +-------------+-----------------------+---------------------------+ 509 | Virtual |Requesting a virtual | | 510 | Network |network and related | ietf-te-topology.yang | 511 | Operations |control operations, | ietf-actn-vn.yang | 512 | |(e.g.,update, deletion)| | 513 +-------------+-----------------------+---------------------------+ 515 Analysis and descriptions of whether and how these functions are 516 supported by the YANG models are provided in more detail in 517 Section 5. 519 5. Function Gap Analysis on YANG Model Level 521 5.1. Topology Related Functions 523 As shown in the previous section, the functions of obtaining access 524 point information, obtaining topology, and imposing virtual network 525 operations can take advantages of the same set of topology YANG 526 models. These functions are briefly explained further in the 527 following sub-sections. 529 5.1.1. Obtaining Access Point Info 531 For cases such as scenario 1, a client may have no interest in 532 directly controlling network resources, but might want an automated 533 common control interface for initiating service requests. In this 534 case, a transport domain controller may provide the access point 535 information. This information can then be used in service request 536 sent over the common interface. 538 The TE Topology YANG model provided in [TE-topo] 539 [I-D.ietf-teas-yang-te-topo] can be used to provide a list of links. 540 If the remote node and termination point information is unknown, it 541 is omitted from the reported information. If the client-side node 542 and termination point information is obtained via configuration or a 543 distributed discovery mechanism, then it can also be added into the 544 reported information. Technology-specific details might also be 545 needed to further express the constraints/attributes associated with 546 the access points. Note that all of this information is usually read 547 only. 549 5.1.2. Obtaining Topology 551 Refer to [I-D.ietf-teas-yang-te-topo] for explanations and examples 552 on how to obtain the topology. For technology specific topology 553 information, other models such as those provided in [WDM-Topo] 554 [I-D.ietf-ccamp-wson-yang] and [ODU-Topo] 555 [I-D.zhang-ccamp-l1-topo-yang] may be used. 557 There are two ways provided in [I-D.ietf-teas-yang-te-topo] in terms 558 of how to present a multi-layer topology, discussions have been 559 carried out among the unofficial group in terms of how the 560 transitional link approach can work and the discussion material will 561 be available soon in the github [Transport-modeling-github]. 563 5.1.3. Virtual Network Operations 565 There are two ways to request the creation of a virtual network. One 566 is to define the topology explicitly using the model provided in the 567 topology YANG drafts listed in previous section. The other way is to 568 provide an estimated traffic information (a traffic matrix) and ask 569 for a domain controller of the provider network to provide a virtual 570 network that can fulfill the demand. This second approach is 571 supported by the YANG model in [I-D.lee-teas-actn-vn-yang]. 573 5.2. Tunnel Operations 575 The current [TE-Tunnel] [I-D.ietf-teas-yang-te] provides a technology 576 agnostic Traffic-Engineered (TE) to manage and configure tunnel. The 577 model included in that draft is currently being developed to make it 578 generic for both controller and device usage. In the latest version, 579 it already provides such a generic TE tunnel model that can cater to 580 the base requirementss for tunnel operations but it may need to be 581 augmented to support controller-specific operations. 583 Furthermore, technology-specific augmentations of the base generic TE 584 tunnel models are needed. For example, for Optical Channel (OCh) 585 (note: ITU is updating this term as OTSi.) tunnels in WDM networks, 586 information such as the lambda resource usage is needed. Similarly, 587 for ODU tunnels, information such as ODU-specific client signal, 588 tributary slot information etc. is needed. 590 For path computation, [I-D.busibel-teas-yang-path-computation] 591 presents now only use cases but YANG model work is also under 592 consideration to provide statelss path computation RPC. There is 593 currently ongoing discussions on how to provide such a function using 594 the TE tunnel model defined in [I-D.ietf-teas-yang-te] as a base. 596 5.3. Service Requests 598 Service model is an important type of models, such as the one 599 provided in [I-D.zhang-teas-transport-service-model], that enables 600 automated operations between a client controller or an orchestrator 601 and a domain controller. This transport connectivity service model 602 is different from the model of a tunnel since the transport 603 connectivity service model are enforced over the client-server 604 interfaces, and it hides unnecessary provider network details from a 605 client. 607 6. IANA Considerations 609 This document requests no IANA actions. 611 7. Security Considerations 613 Clearly modifying server-layer resources will have a significant 614 impact on network infrastructure. More specifically they will 615 provide the services and applications running across client-layers, 616 which the server-layer is supporting. Therefore, security must be an 617 important consideration when implementing the architecture, models 618 and protocol mechanisms discussed in this document. 620 Communicating service and network information (including access point 621 identifiers, capabilities, topologies, etc.) across external 622 interfaces represents a security risk. Thus, mechanisms to encrypt 623 or preserve the domain topology confidentiality should be used. 625 A key consideration are the external protocols (those shown as 626 entering or leaving the orchestrator and controllers shown in 627 Figure 2 (Scenario 2: Multi-domain network control and management)) 628 which must be appropriately secured. This security should include 629 authentication and authorization to control access to different 630 functions that the orchestrator may perform to modify or create state 631 in the server-layer, and the establishment and management of the 632 orchestrator to controller relationship. 634 The orchestrator will contain significant data about the network 635 domains, the services carried by each domain, and customer type 636 information. Therefore, access to information held in the 637 orchestrator must be secured. Since such access will be largely 638 through external mechanisms, it may be pertinent to apply policy- 639 based controls to restrict access and functions. 641 8. Manageability Considerations 643 The core objectives of this document are to assist in the deployment 644 and operation of transport services across server-layer network 645 infrastructure. The model-driven management/control principles, 646 which are vendor-neutral and supported by extensible APIs, should be 647 utilized. 649 The open models described in this document are based on YANG 650 [RFC6020] and the RESTCONF [RESTCONF] messaging protocol, a REST-like 651 protocol running over HTTP for accessing data defined in YANG, may 652 also be used. 654 9. Acknowledgements 656 We would like to thank Young Lee, Igor Bryskin and Aihua Guo for 657 their comments and discussions. 659 10. Contributing Authors 661 The following people all contributed to this document and are listed 662 below: 664 Ruiquan Jing 665 China Telecom 666 Email: jingrq@ctbri.com.cn 667 Yan Shi 668 China Unicom 669 Email: shiyan49@chinaunicom.cn 671 Jeong-dong Ryoo 672 ETRI 673 Email: ryoo@etri.re.kr 675 Yunbin Xu 676 CAICT 677 Email: xuyunbin@ritt.cn 679 Daniel King 680 Lancaster University 681 Email: d.king@lancaster.ac.uk 683 11. References 685 11.1. Normative References 687 [I-D.ietf-netconf-restconf] 688 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 689 Protocol", draft-ietf-netconf-restconf-13 (work in 690 progress), April 2016. 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, 694 DOI 10.17487/RFC2119, March 1997, 695 . 697 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 698 the Network Configuration Protocol (NETCONF)", RFC 6020, 699 DOI 10.17487/RFC6020, October 2010, 700 . 702 11.2. Informative References 704 [I-D.busibel-teas-yang-path-computation] 705 Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., 706 ansharma@infinera.com, a., Shi, Y., Vilata, R., and K. 707 Sethuraman, "Yang model for requesting Path Computation", 708 draft-busibel-teas-yang-path-computation-00 (work in 709 progress), October 2016. 711 [I-D.ceccarelli-teas-actn-framework] 712 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 713 Control of Traffic Engineered Networks", draft-ceccarelli- 714 teas-actn-framework-02 (work in progress), April 2016. 716 [I-D.ietf-ccamp-wson-yang] 717 Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V., 718 King, D., and B. Yoon, "A Yang Data Model for WSON Optical 719 Networks", draft-ietf-ccamp-wson-yang-01 (work in 720 progress), April 2016. 722 [I-D.ietf-teas-yang-te] 723 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., Chen, 724 X., Jones, R., and B. Wen, "A YANG Data Model for Traffic 725 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 726 te-02 (work in progress), October 2015. 728 [I-D.ietf-teas-yang-te-topo] 729 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 730 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 731 teas-yang-te-topo-04 (work in progress), March 2016. 733 [I-D.lee-teas-actn-vn-yang] 734 Lee, Y., Ceccarelli, D., Miyasaka, T., Park, P., and B. 735 Yoon, "A Yang Data Model for ACTN VN Operation", draft- 736 lee-teas-actn-vn-yang-01 (work in progress), July 2016. 738 [I-D.zhang-ccamp-l1-topo-yang] 739 Zhang, X., Rao, B., and X. Liu, "A YANG Data Model for 740 Layer 1 Network Topology", draft-zhang-ccamp-l1-topo- 741 yang-01 (work in progress), December 2015. 743 [I-D.zhang-teas-actn-yang] 744 Lee, Y., Zhang, X., Yoon, B., and O. Dios, "Applicability 745 of YANG models for Abstraction and Control of Traffic 746 Engineered Networks", draft-zhang-teas-actn-yang-01 (work 747 in progress), October 2016. 749 [I-D.zhang-teas-transport-service-model] 750 Zhang, X. and J. Ryoo, "A Service YANG Model for 751 Connection-oriented Transport Networks", draft-zhang-teas- 752 transport-service-model-00 (work in progress), July 2016. 754 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 755 Ceccarelli, D., and X. Zhang, "Problem Statement and 756 Architecture for Information Exchange between 757 Interconnected Traffic-Engineered Networks", BCP 206, 758 RFC 7926, DOI 10.17487/RFC7926, July 2016, 759 . 761 [Transport-modeling-github] 762 "https://github.com/TransportModels/IETF-Transport- 763 Modeling", IETF-Transport-Modeling-GITHUB , October 2016. 765 [Transport-requirements-github] 766 "https://github.com/TransportModels/IETF-Transport- 767 Modeling/tree/master/Transport-Requirements", IETF- 768 Transport-Modeling-GITHUB , October 2016. 770 [Transport-usecases-github] 771 "https://github.com/TransportModels/IETF-Transport- 772 Modeling/tree/master/Transport-UseCases", IETF-Transport- 773 Modeling-GITHUB , October 2016. 775 Authors' Addresses 777 Xian Zhang (editor) 778 Huawei Technologies 779 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 780 Shenzhen, Guangdong 518129 781 P.R.China 783 Email: zhang.xian@huawei.com 785 Anurag Sharma (editor) 786 Infinera 787 US 789 Email: ansharma@infinera.com 791 Sergio Belotti 792 Nokia 793 Italy 795 Email: sergio.belotti@nokia.com 797 Tara Cummings 798 Ericsson 800 Email: tara.cummings@ericsson.com