[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
CCAMP Working Group                                        X. Zhang, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Informational                            A. Sharma, Ed.
Expires: May 4, 2017                                            Infinera
                                                              S. Belotti
                                                                   Nokia
                                                             T. Cummings
                                                                Ericsson
                                                        October 31, 2016


    YANG Models for the Northbound Interface of a Transport Network
               Controller: Requirements and Gap Analysis
            draft-zhang-ccamp-transport-yang-gap-analysis-01

Abstract

   A transport network is a lower-layer network designed to provide
   connectivity services for a higher-layer network to carry the traffic
   opaquely across the lower-layer network resources.  A transport
   network may be constructed from equipment utilizing any of a number
   of different transport technologies such as the optical transport
   infrastructure (Synchronous Optical Networking (SONET) / Synchronous
   Digital Hierarchy (SDH) and Optical Transport Network (OTN)) or
   packet transport as epitomized by the MPLS Transport Profile (MPLS-
   TP).

   All transport networks have high benchmarks for reliability and
   operational simplicity.  This suggests a common, technology-
   independent management/control paradigm that can be extended to
   represent and configure specific technology attributes.

   This document describes the high-level requirements facing transport
   networks in order to provide open interfaces for resource
   programmability and control/management automation.  Furtheremore, gap
   analysis against existing models are also provided so that it can
   used as the guidance to separate efforts/drafts proposing new models
   or augmentation models based on existing models.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.



Zhang, et al.              Expires May 4, 2017                  [Page 1]


Internet-Draft         Transport NBI Gap Analysis           October 2016


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 4, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  High-level Modeling Requirements  . . . . . . . . . . . . . .   5
     3.1.  Generic Requirements  . . . . . . . . . . . . . . . . . .   5
     3.2.  Transport Network and TE Topology Requirements  . . . . .   6
       3.2.1.  Topological Link Requirements . . . . . . . . . . . .   6
       3.2.2.  Topology Node Requirements  . . . . . . . . . . . . .   6
       3.2.3.  Termination Point Requirements  . . . . . . . . . . .   6
     3.3.  Transport Service Requirements  . . . . . . . . . . . . .   7
     3.4.  Tunnel/LSP Requirements . . . . . . . . . . . . . . . . .   7
   4.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Single-domain Scenario  . . . . . . . . . . . . . . . . .   7
     4.2.  Multi-domain Scenario . . . . . . . . . . . . . . . . . .   9
     4.3.  Multi-layer Scenario  . . . . . . . . . . . . . . . . . .  11
     4.4.  Function Summary and Related YANG Models  . . . . . . . .  11
   5.  Function Gap Analysis on YANG Model Level . . . . . . . . . .  12
     5.1.  Topology Related Functions  . . . . . . . . . . . . . . .  12
       5.1.1.  Obtaining Access Point Info . . . . . . . . . . . . .  13
       5.1.2.  Obtaining Topology  . . . . . . . . . . . . . . . . .  13
       5.1.3.  Virtual Network Operations  . . . . . . . . . . . . .  13
     5.2.  Tunnel Operations . . . . . . . . . . . . . . . . . . . .  14
     5.3.  Service Requests  . . . . . . . . . . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14



Zhang, et al.              Expires May 4, 2017                  [Page 2]


Internet-Draft         Transport NBI Gap Analysis           October 2016


   8.  Manageability Considerations  . . . . . . . . . . . . . . . .  15
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   10. Contributing Authors  . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   A transport network is a server-layer network designed to provide
   connectivity services, or more advanced services like Virtual Private
   Networks (VPN) for a client-layer network to carry the client traffic
   opaquely across the server-layer network resources.  It acts as a
   pipe provider for upper-layer networks, such as IP network and mobile
   networks.

   Transport networks, such as Synchronous Optical Networking (SONET) /
   Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN),
   Wavelength Division Multiplexing (WDM), and flexi-grid networks, are
   often built using equipments from a single vendor and are managed
   using proprietary interfaces to dedicated Element Management Systems
   (EMS) / Network Management Systems (NMS).  All transport networks
   have high benchmarks for reliability and operational simplicity.
   This suggests a common, technology-independent management/control
   paradigm that is extended to represent and configure specific
   technology attributes.

   Network providers need a common way to manage multi-vendor and multi-
   domain transport networks (where each domain is an island of
   equipments from a single supplier) and this requirement has been
   further stressed by the expansion in network size.  At the same time,
   applications such as data center interconnection require larger and
   more dynamic connectivities.  Therefore, transport networks face new
   challenges going beyond automatic provisioning of tunnel setup
   enabled by GMPLS (Generalized Multi-Protocol Label Switching)
   protocols to achieve automatic service provisioning, as well as
   address opportunities enabled by partitioning the transport network
   through the process of resource slicing.  With a reduction in
   operational expenditure (OPEX) and capital expenditure (CAPEX) as the
   usual objectives, a common interface to transport network controllers
   are considered by network providers as a way to meet the
   requirements.  The concept of Software Defined Networking (SDN)
   leverages these ideas.

   The YANG language [RFC6020] is currently the data modeling language
   of choice within the IETF and has been adopted by a number of
   industry-wide open management and control initiatives.  YANG may be



Zhang, et al.              Expires May 4, 2017                  [Page 3]


Internet-Draft         Transport NBI Gap Analysis           October 2016


   used to model both configuration and operational states; it is
   vendor-neutral and supports extensible APIs for control and
   management of elements.

   This document first specifies the scope and provides high-level
   requirements for transport network open interface modelling.
   Furthermore, detailed gap analysis of the typical scenarios with the
   existing model are provided.  Thus, this document can used as a
   reference of existing models, and provides information of the missing
   ones which suggest further work.

2.  Scope

   For this draft, we use the domain controller as the reference point,
   with South Bound Interface (SBI) to the transport devices and North
   Bound Interface (NBI) to the orchestrator.

   Transport networks have been evolving and deploying for decades,
   making them very heterogeneous.  New and legacy transport devices
   support many protocols such as Path Computation Element Protocol
   (PCEP), TL1, SNMP, CLI, XML, NETCONF, Openflow etc.  Domain
   controllers interfacing with transport devices need to support these
   protocols on its SBI, making the southbound fragmented.  Domain
   controllers abstract the fragmented southbound view for its
   northbound clients by normalizing the NBI across various
   technologies, protocols, and vendors.  The focus of this document is
   not to go into various southbound protocols to interface with the
   transport devices.  Instead, this document focuses on the models that
   can be used by the domain controller and the orchestrator for various
   use cases identified in later sections of this document.

   There is an ongoing unofficial weekly meeting among a group of
   individuals (see the github files [Transport-modeling-github] for
   more meeting minutes and materials produced), focusing on the efforts
   of analyzing the IETF models against a list of well known use cases
   to identify gaps.  This document captures this efforts and summarized
   the main work and key findings of this group work.

   YANG models are currently developed not only in IETF, but also in
   other Standard Development Organizations (SDO) such as ONF and MEF,
   which can be used on the interfaces of a domain controller and an
   orchestrator.  Each domain controller and orchestrator can use models
   developed by different SDOs.  Therefore it is important to ensure
   that deployment use cases and related funcionalities are supported by
   all models to allow a seamless translation/mediation between systems
   using different models.





Zhang, et al.              Expires May 4, 2017                  [Page 4]


Internet-Draft         Transport NBI Gap Analysis           October 2016


   If the Abstraction and Control of Traffic-Engineered Networks (ACTN)
   defined in [I-D.ceccarelli-teas-actn-framework] is used as a
   reference architcture, then the focus is equivalent to MPI (MDSC-PNC
   Interface) and CMI (CNC-MDSC Interface).  More details about the
   relationship of the type of models and the type of ACTN interfaces
   can be found in [I-D.zhang-teas-actn-yang].

3.  High-level Modeling Requirements

   This section covers various high-level modeling requirements for
   transport networks.

3.1.  Generic Requirements

   The following are generic requirements for transport models:

   o  User Intent: Transport models should maintain separation between
      high level user intent and the operational state of the network.
      For example, maintaining separation between user service request,
      including all constraints, and the actual service and connection
      state in the network.

   o  State Management: Network and service objects should support the
      following states: administrative state, operational state, and
      lifecycle state.  Administrative state and operational states are
      well understood.  Lifecycle state is defined in the ONF and it is
      used to track the planned deployment allocation of the related
      entity in the model as well as withdrawal of resources.  Here the
      lifecylce state includes planned state, potential state, installed
      state, and pending removal state.

   o  Identifiers: Network and service objects should support the
      following identifier:

      *  ID: A unique entity ID provided by the controller.  The
         identifier SHOULD be chosen such that the same entity in a real
         network topology will always be identified through the same ID,
         even if the model is instantiated in separate datastores.
         Controller may choose to capture semantics in the identifier,
         for example to indicate the type of entity and/or the type of
         the parent identity.

      *  Name: A unique name provided by the client for the entity.  The
         name can be modified, if required, by the client.

      *  User Labels: A list of freeform strings that can be used as
         alias for the entity by the client.  Multiple user labels are




Zhang, et al.              Expires May 4, 2017                  [Page 5]


Internet-Draft         Transport NBI Gap Analysis           October 2016


         permitted for the entity, and client can edit these user
         labels.  User labels do not need to be unique.

3.2.  Transport Network and TE Topology Requirements

3.2.1.  Topological Link Requirements

   The model should support the following Topological Links:

   o  Physical Links

   o  Abstract Links [RFC7926]

   o  Compound Link which are are internally aggregated lower level
      links

   o  Access Links which connect the router port to the client port of
      the transport system

   o  Transitional Links which provide adaptation capability between
      layers within a network element

   The Link should support various link related attributes like cost,
   latency, capacity, risk characteristics (including shared risk).  The
   model should provide clear association between Link and its topology
   (including virtual topology), nodes and termination points.

   The model should provide association between the link and any
   underlay circuit / service supporting the Link.

3.2.2.  Topology Node Requirements

   The model should support the following Topology Node:

   o  Physical Node

   o  Abstract Node

   o  Chassis / Forwarding Domain

   [Editors' note: more details will be added later, which can be found
   in [Transport-requirements-github].]

3.2.3.  Termination Point Requirements

   [Editors' note: this will be added later, which can be found in
   [Transport-requirements-github].]




Zhang, et al.              Expires May 4, 2017                  [Page 6]


Internet-Draft         Transport NBI Gap Analysis           October 2016


3.3.  Transport Service Requirements

   [Editors' note: this will be added later, which can be found in
   [Transport-requirements-github].]

3.4.  Tunnel/LSP Requirements

   [Editors' note: this will be added later which can be found in
   [Transport-requirements-github].]

4.  Scenarios

   There are several scenarios (a.k.a., use cases) where an open
   interface via domain controller to access server-layer (transport)
   network resources would be useful.  Three scenarios are provided and
   can be used for model instantiation exercise to identify missing
   pieces of existing models.  Note the models provided in this draft is
   for explanation purpose, the group effort actually uses slight
   different network examples for gap analysis exercise (see
   [Transport-usecases-github] for more details).

4.1.  Single-domain Scenario

   The first scenario is depicted as below (Figure 1 ):



























Zhang, et al.              Expires May 4, 2017                  [Page 7]


Internet-Draft         Transport NBI Gap Analysis           October 2016


        /--\   +------+                  +------+     /--\
       | 1  ~~~|  A   +------------------|  B   |~~~~~  3 |
        \--/   +-----++                  +--+---+     \--/
                     |                      |
                     |                      |
                     |                      |
                    ++-----+            +---+--+
                    |   F  +------------+  C   |
                    ++-----+            +--+---+
                     |                     |
                     |                     |
                     |                     |
                     |                     |
                     |                     |
                 +---+-+               +---+-+    /---\
                 |  E  +---------------+  D  |~~~~  4  |
        /--\~~~~~+-----+               +-----+    \---/
       | 2  |
        \--/

          +----+                      /--\
          |    |  Transport NE       |    |   DC
          +----+                      \--/

              -----   Transport Link      ~~~   Transport-DC link

           (a)     Data Centers interconnected via a transport network

                  +---------------------+
                  | Data Center Network |
                  |   Controller        |
                  +---------+-----------+
                            |
                            |
                            |
                            | Open Interface
                            |
                            |
                  +---------+-----------+
                  |  Transport Network  |
                  |    Controller       |
                  +---------------------+
      (b)  The controller architecture for data center interconnection


     Figure 1: Scenario 1: Data centers interconnected via a transport
                  network and the controller architecture




Zhang, et al.              Expires May 4, 2017                  [Page 8]


Internet-Draft         Transport NBI Gap Analysis           October 2016


   For the data center operator, as a client of the transport network,
   assuming the objective is to trigger the transport network to provide
   connectivity on demand, the following capabilities, at a minimum,
   would be required on the common interface between the two controllers
   illustrated in Figure 1:

   o  The ability to obtain information about a set of access points of
      the transport network, including information such as access point
      identifiers, capabilities, etc.; for instance, transport-network-
      side end point identifiers related to the access link between DC1
      and Transport NE A.

   o  The capability to send a request for a service using the
      aforementioned access point information, as well as the ability to
      retrieve a list of service requests and their status.  In this
      request, it should at least be possible to include source node,
      destination node, and requested bandwidth to request the transport
      network to set up tunnels/paths so as to provide the requested
      connectivity for the service request.

   o  Note that in this case, the acquisition of the topology, be it
      physical or logical, of the transport network is not a compulsory
      requirement, but it may indeed be able to give data center
      providers more control over the transport resource usage.
      Furthermore, the client controller can impose a virtual network of
      its own choice by requesting a slice of network resource with its
      choice of network parameters (such as network topology type,
      bandwidth etc.).

4.2.  Multi-domain Scenario

   The second scenario, more complicated than the first, is depicted as
   below (Figure 2).  In this example, we focus on the management and
   control via common interfaces for multi-domain networks with
   homogeneous technologies (such as OTN), but it can be extended
   further to multi-domain networks with heterogeneous technologies with
   higher complexity.














Zhang, et al.              Expires May 4, 2017                  [Page 9]


Internet-Draft         Transport NBI Gap Analysis           October 2016


                  +-------------------------------------------------+
                  |              Orchestrator/Coordinator           |
                  +---------+--------------+-------------------+----+
                                    |              |                   |
                                    |              |                   |
           +------------+--+           |        +----------+----------+
           | Controller 1  |           |        |   Controller 2      |
           +---------+-----+           |        +-------+-------------+
                                 #        +----------------+        #
                                 #Qx      | Controller 3   |        #
                                 #        +----------------+        #TL1
                                 #                #                 #
                         ----+-----           #             ----+-----
            ____/          \____      #        ____/          \____
           |                    |     #       |                    |
          |                      |    #      |                      |
          |    Network Domain    +***********+   Network Domain     |
          |          1          |     #      |          2           |
           |____            ___|      #       |____             ___|
                    \           /         #PCEP        \           /
                         -----------          #            *----------
                           *       *          #           *       *
                            *       *         #          *       *
                                 *       *        #         *       *
                                  *       *       #        *       *
                                   *       *      #       *       *
                                    *       *     #      *       *
                                         *       *----+-----*       *
                                          *  ____/          \____  *
                                           *|                   |*
                                           |                     |
                                           |    Network Domain    |
                                           |          3          |
                                            |____            ___|
                                                         \           /
                                                          ----------

                                 *****  inter-domain links
                                 -----  Open Interfaces
                                 #####  Controller-device interfaces



     Figure 2: Scenario 2: Multi-domain network control and management

   For the second scenario, the orchestrator controls and manages three
   distinct network domains, each controlled/managed by their domain
   controller.  This scenario is of interest not only to transport-only



Zhang, et al.              Expires May 4, 2017                 [Page 10]


Internet-Draft         Transport NBI Gap Analysis           October 2016


   networks, but also to heretegenous network orchestration such as
   coordinating the transport, the radio (5G) and packet core domains.
   But to keep the functions explanation later accurate, only transport-
   only multi-domain networks are considered.

   In order to orchestrate across domains/layers, besides the
   capabilities mentioned for the first scenario, the orchestrator needs
   its interface between domain controllers to be equipped with the
   following additional functions:

   o  Access to the topologies reported by each domain controller,
      including cross-domain links for the purpose of planning and
      requesting the paths of end-to-end tunnels.  Depending on the
      abstraction level of the reported topology, the orchestrator has
      different control granularities.

   o  Alterntively, the capability for the orchestrator to request "path
      computation" to a domain controller in order to create an end-to-
      end tunnel stitched together by different connection contribution
      obtained by consulting to each domain controller.

   o  The ability to set up, delete and modify tunnels, be it within one
      domain or across multiple domains.  Furthermore, it should have
      the abilty to view the tunnels created within each domain as well
      as those that cross domains as reported by each domain controller.

4.3.  Multi-layer Scenario

   In the first use case, if there are multiple technologies invovled,
   then it can be considered as a multi-layer case.  [Editors' note:
   more details to be added later, some can be found in
   [Transport-usecases-github].]

4.4.  Function Summary and Related YANG Models

   For the common interface of a transport controller towards a
   northbound client, six main functions are derived from the scenarios
   explained in the last section.  They are summarized in the table
   below and we also match these functions with YANG models that are
   being developed in existing drafts.











Zhang, et al.              Expires May 4, 2017                 [Page 11]


Internet-Draft         Transport NBI Gap Analysis           October 2016


         +-------------+-----------------------+---------------------------+
         | Functions   |     Description       |     Related Existing      |
         |             |                       |     YANG Models           |
         |-------------+-----------------------+---------------------------+
         | Obtaining   |Getting the necessary  |  ietf-network.yang        |
         | Access      |access points info     | ietf-network-topology.yang|
         | Point Info  |                       | ietf-te-topology.yang     |
         +-------------+-----------------------+---------------------------+
         | Obtaining   |Getting the topology   | ietf-te-topology.yang     |
         | Topology    |info                   | ietf-otn-topology.yang    |
         |             |                       | ietf-wson-topology.yang   |
         +-------------+-----------------------+---------------------------+
         | Tunnel      |Tunnel Setup, Deletion |                           |
         | Operations  |Modification and Info  |   ietf-te.yang            |
         |             |Retrieval              |  ietf-otn-tunnel.yang     |
         +-------------+-----------------------+---------------------------+
         | Service     |Requesting connectivity|                           |
         | Request     |service and retrieval  |ietf-transport-service.yang|
         |             |the list of service    | ietf-actn-vn.yang              |
         |             |request                |                           |
         +-------------+-----------------------+---------------------------+
         |Path Comp.   | Path Computation pre  |                           |
         |             | service provisioning  |     ietf-te.yang          |
         +-------------+-----------------------+---------------------------+
         | Virtual     |Requesting a virtual   |                           |
         | Network     |network and related    | ietf-te-topology.yang     |
         | Operations  |control operations,    |  ietf-actn-vn.yang        |
         |             |(e.g.,update, deletion)|                           |
         +-------------+-----------------------+---------------------------+


   Analysis and descriptions of whether and how these functions are
   supported by the YANG models are provided in more detail in
   Section 5.

5.  Function Gap Analysis on YANG Model Level

5.1.  Topology Related Functions

   As shown in the previous section, the functions of obtaining access
   point information, obtaining topology, and imposing virtual network
   operations can take advantages of the same set of topology YANG
   models.  These functions are briefly explained further in the
   following sub-sections.







Zhang, et al.              Expires May 4, 2017                 [Page 12]


Internet-Draft         Transport NBI Gap Analysis           October 2016


5.1.1.  Obtaining Access Point Info

   For cases such as scenario 1, a client may have no interest in
   directly controlling network resources, but might want an automated
   common control interface for initiating service requests.  In this
   case, a transport domain controller may provide the access point
   information.  This information can then be used in service request
   sent over the common interface.

   The TE Topology YANG model provided in [TE-topo]
   [I-D.ietf-teas-yang-te-topo]  can be used to provide a list of links.
   If the remote node and termination point information is unknown, it
   is omitted from the reported information.  If the client-side node
   and termination point information is obtained via configuration or a
   distributed discovery mechanism, then it can also be added into the
   reported information.  Technology-specific details might also be
   needed to further express the constraints/attributes associated with
   the access points.  Note that all of this information is usually read
   only.

5.1.2.  Obtaining Topology

   Refer to [I-D.ietf-teas-yang-te-topo] for explanations and examples
   on how to obtain the topology.  For technology specific topology
   information, other models such as those provided in [WDM-Topo]
   [I-D.ietf-ccamp-wson-yang] and [ODU-Topo]
   [I-D.zhang-ccamp-l1-topo-yang] may be used.

   There are two ways provided in [I-D.ietf-teas-yang-te-topo] in terms
   of how to present a multi-layer topology, discussions have been
   carried out among the unofficial group in terms of how the
   transitional link approach can work and the discussion material will
   be available soon in the github [Transport-modeling-github].

5.1.3.  Virtual Network Operations

   There are two ways to request the creation of a virtual network.  One
   is to define the topology explicitly using the model provided in the
   topology YANG drafts listed in previous section.  The other way is to
   provide an estimated traffic information (a traffic matrix) and ask
   for a domain controller of the provider network to provide a virtual
   network that can fulfill the demand.  This second approach is
   supported by the YANG model in [I-D.lee-teas-actn-vn-yang].








Zhang, et al.              Expires May 4, 2017                 [Page 13]


Internet-Draft         Transport NBI Gap Analysis           October 2016


5.2.  Tunnel Operations

   The current [TE-Tunnel] [I-D.ietf-teas-yang-te] provides a technology
   agnostic Traffic-Engineered (TE) to manage and configure tunnel.  The
   model included in that draft is currently being developed to make it
   generic for both controller and device usage.  In the latest version,
   it already provides such a generic TE tunnel model that can cater to
   the base requirementss for tunnel operations but it may need to be
   augmented to support controller-specific operations.

   Furthermore, technology-specific augmentations of the base generic TE
   tunnel models are needed.  For example, for Optical Channel (OCh)
   (note: ITU is updating this term as OTSi.) tunnels in WDM networks,
   information such as the lambda resource usage is needed.  Similarly,
   for ODU tunnels, information such as ODU-specific client signal,
   tributary slot information etc. is needed.

   For path computation, [I-D.busibel-teas-yang-path-computation]
   presents now only use cases but YANG model work is also under
   consideration to provide statelss path computation RPC.  There is
   currently ongoing discussions on how to provide such a function using
   the TE tunnel model defined in [I-D.ietf-teas-yang-te] as a base.

5.3.  Service Requests

   Service model is an important type of models, such as the one
   provided in [I-D.zhang-teas-transport-service-model], that enables
   automated operations between a client controller or an orchestrator
   and a domain controller.  This transport connectivity service model
   is different from the model of a tunnel since the transport
   connectivity service model are enforced over the client-server
   interfaces, and it hides unnecessary provider network details from a
   client.

6.  IANA Considerations

   This document requests no IANA actions.

7.  Security Considerations

   Clearly modifying server-layer resources will have a significant
   impact on network infrastructure.  More specifically they will
   provide the services and applications running across client-layers,
   which the server-layer is supporting.  Therefore, security must be an
   important consideration when implementing the architecture, models
   and protocol mechanisms discussed in this document.





Zhang, et al.              Expires May 4, 2017                 [Page 14]


Internet-Draft         Transport NBI Gap Analysis           October 2016


   Communicating service and network information (including access point
   identifiers, capabilities, topologies, etc.) across external
   interfaces represents a security risk.  Thus, mechanisms to encrypt
   or preserve the domain topology confidentiality should be used.

   A key consideration are the external protocols (those shown as
   entering or leaving the orchestrator and controllers shown in
   Figure 2 (Scenario 2: Multi-domain network control and management))
   which must be appropriately secured.  This security should include
   authentication and authorization to control access to different
   functions that the orchestrator may perform to modify or create state
   in the server-layer, and the establishment and management of the
   orchestrator to controller relationship.

   The orchestrator will contain significant data about the network
   domains, the services carried by each domain, and customer type
   information.  Therefore, access to information held in the
   orchestrator must be secured.  Since such access will be largely
   through external mechanisms, it may be pertinent to apply policy-
   based controls to restrict access and functions.

8.  Manageability Considerations

   The core objectives of this document are to assist in the deployment
   and operation of transport services across server-layer network
   infrastructure.  The model-driven management/control principles,
   which are vendor-neutral and supported by extensible APIs, should be
   utilized.

   The open models described in this document are based on YANG
   [RFC6020] and the RESTCONF [RESTCONF] messaging protocol, a REST-like
   protocol running over HTTP for accessing data defined in YANG, may
   also be used.

9.  Acknowledgements

   We would like to thank Young Lee, Igor Bryskin and Aihua Guo for
   their comments and discussions.

10.  Contributing Authors

   The following people all contributed to this document and are listed
   below:

   Ruiquan Jing
   China Telecom
   Email: jingrq@ctbri.com.cn




Zhang, et al.              Expires May 4, 2017                 [Page 15]


Internet-Draft         Transport NBI Gap Analysis           October 2016


   Yan Shi
   China Unicom
   Email: shiyan49@chinaunicom.cn

   Jeong-dong Ryoo
   ETRI
   Email: ryoo@etri.re.kr

   Yunbin Xu
   CAICT
   Email: xuyunbin@ritt.cn

   Daniel King
   Lancaster University
   Email: d.king@lancaster.ac.uk

11.  References

11.1.  Normative References

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-13 (work in
              progress), April 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <http://www.rfc-editor.org/info/rfc6020>.

11.2.  Informative References

   [I-D.busibel-teas-yang-path-computation]
              Busi, I., Belotti, S., Lopezalvarez, V., Dios, O.,
              ansharma@infinera.com, a., Shi, Y., Vilata, R., and K.
              Sethuraman, "Yang model for requesting Path Computation",
              draft-busibel-teas-yang-path-computation-00 (work in
              progress), October 2016.

   [I-D.ceccarelli-teas-actn-framework]
              Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
              Control of Traffic Engineered Networks", draft-ceccarelli-
              teas-actn-framework-02 (work in progress), April 2016.



Zhang, et al.              Expires May 4, 2017                 [Page 16]


Internet-Draft         Transport NBI Gap Analysis           October 2016


   [I-D.ietf-ccamp-wson-yang]
              Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V.,
              King, D., and B. Yoon, "A Yang Data Model for WSON Optical
              Networks", draft-ietf-ccamp-wson-yang-01 (work in
              progress), April 2016.

   [I-D.ietf-teas-yang-te]
              Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., Chen,
              X., Jones, R., and B. Wen, "A YANG Data Model for Traffic
              Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
              te-02 (work in progress), October 2015.

   [I-D.ietf-teas-yang-te-topo]
              Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
              O. Dios, "YANG Data Model for TE Topologies", draft-ietf-
              teas-yang-te-topo-04 (work in progress), March 2016.

   [I-D.lee-teas-actn-vn-yang]
              Lee, Y., Ceccarelli, D., Miyasaka, T., Park, P., and B.
              Yoon, "A Yang Data Model for ACTN VN Operation", draft-
              lee-teas-actn-vn-yang-01 (work in progress), July 2016.

   [I-D.zhang-ccamp-l1-topo-yang]
              Zhang, X., Rao, B., and X. Liu, "A YANG Data Model for
              Layer 1 Network Topology", draft-zhang-ccamp-l1-topo-
              yang-01 (work in progress), December 2015.

   [I-D.zhang-teas-actn-yang]
              Lee, Y., Zhang, X., Yoon, B., and O. Dios, "Applicability
              of YANG models for Abstraction and Control of Traffic
              Engineered Networks", draft-zhang-teas-actn-yang-01 (work
              in progress), October 2016.

   [I-D.zhang-teas-transport-service-model]
              Zhang, X. and J. Ryoo, "A Service YANG Model for
              Connection-oriented Transport Networks", draft-zhang-teas-
              transport-service-model-00 (work in progress), July 2016.

   [RFC7926]  Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
              Ceccarelli, D., and X. Zhang, "Problem Statement and
              Architecture for Information Exchange between
              Interconnected Traffic-Engineered Networks", BCP 206,
              RFC 7926, DOI 10.17487/RFC7926, July 2016,
              <http://www.rfc-editor.org/info/rfc7926>.

   [Transport-modeling-github]
              "https://github.com/TransportModels/IETF-Transport-
              Modeling", IETF-Transport-Modeling-GITHUB , October 2016.



Zhang, et al.              Expires May 4, 2017                 [Page 17]


Internet-Draft         Transport NBI Gap Analysis           October 2016


   [Transport-requirements-github]
              "https://github.com/TransportModels/IETF-Transport-
              Modeling/tree/master/Transport-Requirements", IETF-
              Transport-Modeling-GITHUB , October 2016.

   [Transport-usecases-github]
              "https://github.com/TransportModels/IETF-Transport-
              Modeling/tree/master/Transport-UseCases", IETF-Transport-
              Modeling-GITHUB , October 2016.

Authors' Addresses

   Xian Zhang (editor)
   Huawei Technologies
   F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
   Shenzhen, Guangdong  518129
   P.R.China

   Email: zhang.xian@huawei.com


   Anurag Sharma (editor)
   Infinera
   US

   Email: ansharma@infinera.com


   Sergio Belotti
   Nokia
   Italy

   Email: sergio.belotti@nokia.com


   Tara Cummings
   Ericsson

   Email: tara.cummings@ericsson.com












Zhang, et al.              Expires May 4, 2017                 [Page 18]