[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         I. Bryskin
Internet-Draft                                       Huawei Technologies
Intended status: Informational                                    X. Liu
Expires: April 30, 2018                                            Jabil
                                                               V. Beeram
                                                        Juniper Networks
                                                                 T. Saad
                                                       Cisco Systems Inc
                                                        October 27, 2017


         ONF/T-API Services vs. IETF/YANG Models and Interfaces
                 draft-bryskin-teas-yang-ietf-vs-onf-01

Abstract

   This document compares IETF YANG TE (Traffic Engineering) data model
   and ONF/T-API model.

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/.

   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 April 30, 2018.

Copyright Notice

   Copyright (c) 2017 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



Bryskin, et al.          Expires April 30, 2018                 [Page 1]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Topology Service  . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Constrained Nodes . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Intra-node Metrics  . . . . . . . . . . . . . . . . . . .   5
     2.3.  Topology Updates  . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Topology Telemetry Collection . . . . . . . . . . . . . .   9
     2.5.  Topology Name/Address Spaces  . . . . . . . . . . . . . .  10
     2.6.  Topology Relationships  . . . . . . . . . . . . . . . . .  12
     2.7.  Topology Attributes . . . . . . . . . . . . . . . . . . .  15
     2.8.  Topology Service Relationships with Other Services  . . .  16
     2.9.  Topology Negotiation and (Re-)configuration . . . . . . .  16
     2.10. Integration with IP/MPLS  . . . . . . . . . . . . . . . .  18
   3.  Connectivity Service  . . . . . . . . . . . . . . . . . . . .  18
     3.1.  Connectivity Service Protection . . . . . . . . . . . . .  19
     3.2.  Hierarchical Connectivity Service . . . . . . . . . . . .  21
     3.3.  Connectivity Service Re-optimization  . . . . . . . . . .  24
     3.4.  Connectivity Service Templates  . . . . . . . . . . . . .  24
     3.5.  Connectivity Service Attribute Change Update
           Notifications and Telemetry Streaming . . . . . . . . . .  24
     3.6.  Connectivity Scheduling . . . . . . . . . . . . . . . . .  25
     3.7.  Potential Connectivity Service  . . . . . . . . . . . . .  25
   4.  Path Computation Service  . . . . . . . . . . . . . . . . . .  26
   5.  Virtual Network Service . . . . . . . . . . . . . . . . . . .  27
   6.  Data Modeling Language  . . . . . . . . . . . . . . . . . . .  28
   7.  Security Framework  . . . . . . . . . . . . . . . . . . . . .  29
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  30
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  30
     11.2.  Informative References . . . . . . . . . . . . . . . . .  31
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

1.  Introduction

   The success of T-SDN as an architecture depends to a large degree on
   the quality and widespread adoption of open standardized interfaces
   to/from T-SDN controllers, linking them flexibly into various
   hierarchies and confederations.  Currently, the two most popular such
   interfaces are:

   1.  T-API developed by ONF;




Bryskin, et al.          Expires April 30, 2018                 [Page 2]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   2.  RESTCONF/YANG [RFC7950] based on TE Topology and TE Tunnels
       models defined in [I-D.ietf-teas-yang-te-topo] and
       [I-D.ietf-teas-yang-te] documents respectively, the product of
       IETF TEAS WG.

   The two interfaces have the close attention of network operators and
   vendors.  There is a lot of confusion about their respective
   technical merits and "marketing" strengths, applications they can
   support, use cases they cover, and so on.  Do they compete or could
   they somehow complement each other?

   This memo is limited to a strictly technical comparison with the
   special focus on the models supporting the two interfaces, in
   particular, the semantics, relationships, informational flows and
   services they define.  Our analysis suggests that the IETF models
   provide for implementation of powerful hierarchical T-SDN controller
   systems, supporting a broad range of client systems and use cases,
   and that in some identifiable respects, T-API appears to fall
   relatively shorter.  This memo is largely organized around
   considering the identified "gaps".

2.  Topology Service

2.1.  Constrained Nodes

   The T-API Topology service does not support the notion of blocking/
   constrained nodes.  This means that if a T-API Topology service
   provider exposes to a client a topology with at least one node with
   constrained connectivity, e.g. the node can switch a potential TE
   path/connection, say, from interface (NodeEdge point) A to B, but not
   from A to C; there is no way for the provider to communicate the
   connection limitations to the client, thus making the provided TE
   topology unfit for the client's path computations.  This is a serious
   issue because many transport physical switches and virtually all
   abstract composite nodes should be treated as blocking nodes.

   Likewise, if a potential path source/destination node is constrained
   in such a way that the path may leave/enter the source/destination
   node over a link from a subset of (but not all) same-layer links
   connected to the node, the T-API Topology service provider has no way
   of communicating such a circumstance to the client.

   The described issue is addressed in the IETF TE Topology model.  A TE
   node's Connectivity Matrix attribute (Figure 1) fully describes the
   node's TE path/connection switching limitations, while a TE Tunnel
   Termination Point's (TTP's) Local Link Connectivity List attribute
   (Figure 2) describes the node's TE path/connection termination
   limitations with respect to each TTP hosted by the node in question.



Bryskin, et al.          Expires April 30, 2018                 [Page 3]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   Basic Connectivity Matrix:           Detailed Connectivity Matrix:

   LTP-6/label-x <=> LTP-1/label-y      LTP-6/label-x <=> LTP-1/label-y
                                         (Cost c, Delay d, SRLB s, ...)
   LTP-5/label-x <=> LTP-2/label-y      LTP-5/label-x <=> LTP-2/label-y
                                         (Cost c, Delay d, SRLB s, ...)
   LTP-5/label-x <=> LTP-4/label-y      LTP-5/label-x <=> LTP-4/label-y
                                         (Cost c, Delay d, SRLB s, ...)
   LTP-4/label-x <=> LTP-1/label-y      LTP-4/label-x <=> LTP-1/label-y
                                         (Cost c, Delay d, SRLB s, ...)
   LTP-3/label-x <=> LTP-2/label-y      LTP-3/label-x <=> LTP-2/label-y
   ...                                  ...

                               +------------+
                               |            |
                          LTP-6|            |LTP-1
                        -------o************o-------
                               |          * |
                          LTP-5|        *   |LTP-2
                        -------o************o-------
                               | *   *    * |
                               |  **     *  |
                               +--o------o--+
                                LTP-4  LTP-3

                   Figure 1: TE Node Connectivity Matrix

























Bryskin, et al.          Expires April 30, 2018                 [Page 4]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   TTP-1 Basic LLCL:                   TTP-1 Detailed LLCL:

   TTP-1 <=> {LTP-5/label-x,           TTP-1 <=> {
              LTP-2/label-y}            LTP-5/label-x,
                                         (Cost c, Delay d, SRLB s, ...),
                                        LTP-2/label-y,
                                         (Cost c, Delay d, SRLB s, ...)
                                        }

                               +------------+
                               |    TTP-1   |
                               |     __     |
                          LTP-6|     \/     |LTP-1
                        -------o    *  *    o-------
                               |   *    *   |
                               |  * TTP-2*  |
                          LTP-5| *   __   * |LTP-2
                        -------o*    \/    *o-------
                               |    *  *    |
                               |   *    *   |
                               +--o------o--+
                                LTP-4  LTP-3

                Figure 2: TTP Local Link Connectivity List

2.2.  Intra-node Metrics

   There is no good way for a T-API Topology service provider to
   articulate to the client what it would cost for a potential path
   (e.g., in terms of delay) to cross a node from interface (NodeEdge
   point) A to interface B.  Because nodes (especially composite
   abstract nodes) may contribute to overall path costs much more than
   links connecting the nodes along the path, this fact makes the
   provided topology unfit for the client's path selection
   optimizations.  [Note: To be fair, the T-API Topology service does
   allow a composite abstract node (representing a group of inter-
   connected nodes) to refer to the topology describing the abstract
   node's internals (node's encapTopology attribute).  Hence the client
   may in theory apply path computation algorithms on the abstract
   node's internal/encapsulated topology to figure out whether the
   abstract node can switch a path between a given pair of the abstract
   node's NodeEdge points, as well as the cost penalties the path will
   accrue by doing so.  However, such a technique defeats the whole
   purpose of creating the abstract node in the first place, which is
   hiding multiple topological elements behind the abstract node, so
   that the top level topology becomes smaller and easier to use in path
   computations.  In other words, if the client has to "dive" into the
   abstract node's internal topology every time the client needs to



Bryskin, et al.          Expires April 30, 2018                 [Page 5]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   understand whether and how a path can cross the abstract node, the
   client would be better off if the abstract node were not provided,
   and instead, the node's internals were presented directly in the top
   level topology.]

   This issue does not exist in the IETF TE Topology model.  A TE node's
   Detailed Connectivity Matrix attribute (Figure 1, upper right)
   associates with each (abstract or physical) node's connectivity
   matrix entry a vector of costs (in terms of generic TE cost, delay,
   intra-node SRLGs, etc.) that a potential TE path will have to add to
   its end-to-end costs should the path select the entry to cross the
   node.  Likewise, a TE path's source/destination TTP's Detailed Local
   Link Connectivity List attribute (Figure 2, upper right) indicates
   what it would cost for the path to start/stop on a given first/last
   link.  [Note: In the IETF TE topology model an abstract TE node also
   points to the encapsulated TE topology describing the node's
   internals.  However, the client is expected to peruse the node's
   encapsulated TE topology only in exceptional situations (e.g. during
   trouble shooting), rather than under normal conditions, such as
   routine path computations.]

2.3.  Topology Updates

   Suppose that a T-API Topology service client has requested and
   received a topology from one of its providers (for example, the
   topology presented in Figure 3).  It is imperative that as soon as
   this done the provider starts updating the client (continuously and
   in unsolicited way) with changes happening to the topological
   elements and their attributes that the client has expressed interest
   in - otherwise, the client would be forced to make decisions on stale
   information.




















Bryskin, et al.          Expires April 30, 2018                 [Page 6]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


                       |
                       | L2x
                     +---+                    +---+
                     |N2 | L23            L32 |N3 | L3x
                     |   |--------------------|   |----
                L21 /+---+\ L24               +---+
                   /       \               L34 / \ L36
                  /         \                 /   \
             L12 /           \ L42           /     \
       L1x +---+/ L14     L41 \+---+ L43    /       \
       ----|N1 |---------------|N4 |--------         \
           |   |\ L15     L45 /|   |                  \
           +---+ \           / +---+                   \
                  \         /                           \ L63
                   \   L54 /                             \
                    \+---+/ L56                     L65 +---+
                 L51 |N5 |------------------------------|N6 | L5x
                     |   |------------------------------|   |-----
                     +---+  L156                   L165 +---+

       Figure 3: Topology presented to T-API Topology service client

   The only way this could be done in T-API is via using T-API
   Notification service, specifically, the Attribute Value Change (AVC)
   Notification service, which in a nutshell works as follows:

   o  Provider registers with the service the types of pre-defined AVC
      events it is willing and capable of providing notifications for,
      along with the set of pre-defined object types that may comprise
      the notification contents;

   o  Client discovers the registered notifications it can subscribe to
      and subscribes to some of them, specifying filters to tailor the
      notifications to its needs.

   There are two problems with this paradigm:

   1.  The client has a very limited way to express which notifications
       it is interested in, as well as the contents, triggers and
       frequency of such notifications.  Note that even for the same
       topology element type (e.g., link) different clients may need to
       know different things, at different scopes and granularities,
       with respect to the attribute changes.  For example, one client
       may want to hear about links that experienced changes in any
       attribute, while another client may be interested only in links
       with changes in specific attribute(s).  One client may want to
       learn about link attribute modifications across all provided
       topologies, while another client may want to know only about such



Bryskin, et al.          Expires April 30, 2018                 [Page 7]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


       links that belong to one or more specific (but not other)
       topologies.  One client may want to receive in the notification
       the entire set of link attributes, while another client would
       want to learn only about incremental changes (i.e., changes that
       happened since the previous notification); some clients are
       interested not in just any attribute change, but rather, want to
       know when the attribute has reached a specific threshold, etc.
       As mentioned, a T-API client has only the option to discover what
       the provider is willing to offer (without the provider really
       knowing what their clients want to learn) and to subscribe to a
       subset of that;

   2.  In order for the client to understand/interpret the notifications
       registered by the provider, all notification event types, as well
       as the types of objects comprising the notification content, must
       be explicitly pre-defined.  Considering the sheer number of, say,
       link attributes (especially, combinations of them) that different
       clients may be interested in, and the possible scopes,
       granularities and triggers of the notifications; explicit pre-
       definition of notifications is awkward, limited and impractical
       (if not infeasible).

   In sharp contrast, the IETF TE topology model requires no explicit
   definition of notifications.  When the client subscribes to a TE
   topology update notification it:

   a.  defines the notification event type by specifying the YANG XPath
       from the TE topology data store root to the data store node(s)
       associated with link attribute(s) encompassing the client's
       points of interest;

   b.  specifies another XPath pointing to the data store's sub-tree,
       node or group of nodes to identify the content of the
       notification and whether the entire new state or incremental
       changes must be provided;

   c.  defines the trigger for the notification, which could be any
       change in the node(s) of interest or a specific increment in
       value or the value hitting a specific threshold;

   d.  optionally defines the highest notification frequency at which
       the client wants to receive the notifications.

   To illustrate this assume that the IETF TE Topology model client
   wants to be notified about all TE links whose available capacity has
   dropped below 10G, with the notification carrying the actual link's
   available capacity.  In this case the client will:




Bryskin, et al.          Expires April 30, 2018                 [Page 8]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   a.  specify root->all TE topologies -> all TE
       links->linkAttributes->bandwidth XPath as the notification type;

   b.  specify the same XPath to define the desired notification
       content;

   c.  define the notification trigger by specifying the low and high
       thresholds (e.g. 10G and 15 G respectively);

   d.  optionally specify the highest frequency of updates the client is
       capable/willing to consume.

   Note that no explicit definitions for the notification were required.
   After the client registers with the provider the defined
   subscription, the latter knows exactly what the former wants to be
   notified about and how.  Similar notifications are possible to
   register with the provider with respect to any TE topology element
   attribute or combination of thereof.

2.4.  Topology Telemetry Collection

   Topology service clients (which in the T-SDN context could be various
   controllers or applications, such as multi-domain coordinators, IP/
   transport integrators, orchestrators, big data collectors, analytics
   processors, network planners, etc.) are hungry for accurate real time
   network state information (a.k.a. network telemetry).  This knowledge
   is instrumental for a client in keeping the network under its control
   healthy, stable and optimized under conditions of fiber cuts,
   hardware and software failures.  In particular, network telemetry
   streams provided by the client's providers allow for the client to
   identify/predict failing network resources and route the provided
   transport/connectivity services away from them; to identify/predict
   points of congestion and eliminate/mitigate the congestion by
   deploying extra network capacity in a timely manner and so forth.
   Network telemetry is a valuable source of information useful for
   network planning, trouble shooting and many other things.  Network
   telemetry is especially important for topology service clients
   because topologies represent - in an abstracted way - the physical
   network resources.

   [Note: At the time of writing of this memo there were no known TAPI
   design/modeling activities related to telemetry streaming for any of
   the T-API services].

   Topology telemetry collection is similar in nature to receiving
   updates on topology attribute changes.  Per the description in
   section 1.3, T-API Notification service, State Change (SC)
   Notification service is the only mechanism theoretically (i.e. after



Bryskin, et al.          Expires April 30, 2018                 [Page 9]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   all the necessary modeling concepts and attributes, such as
   statistics counters, are in place) available for the client to
   subscribe and for the provider to stream the requested network
   telemetry.  T-API SC Notification service has the same drawbacks as
   the AVC Notification service, specifically:

   a.  limited capability for the client to articulate what telemetry
       (event type, content, granularity, etc.) it seeks to receive;

   b.  necessity for explicit definition of the telemetry events and
       notification messages.

   These issues do not exist in the network telemetry streaming
   machinery offered by the IETF Topology model.  Let's consider, for
   example, that the client wants to identify "flipping" TE links (i.e.
   TE links frequently changing their UP/DOWN operational status) and
   obtain in the notification the entire state information for such TE
   links.  In order to achieve this the client needs to:

   a.  specify root->all TE topologies -> all TE
       links->linkStatistics->linkUPCounter XPath as the notification
       type;

   b.  specify root->all TE topologies -> all TE links->linkState XPath
       to describe the desired notification content;

   c.  define the notification trigger by specifying the number the
       model data state node of interest (the linkUPCounter) must
       increment by for the next notification to be issued;

   d.  optionally specify the highest frequency of notifications of this
       type the client is capable/willing to consume.

2.5.  Topology Name/Address Spaces

   T-API topologies are required to have each node and link assigned a
   globally unique UUID.  This means that all T-API Topology service
   clients and providers have to resolve potential UUID collisions via
   allocating the UUIDs from a universal name space governed by a
   centralized authority (in a similar way to how global IP addresses
   are assigned in IP networks).

   The IETF TE Topology model allows for all TE topologies to have
   independent name spaces for the TE node, link and SRLG IDs, which not
   only eliminates the problem of ID collisions, but also greatly
   simplifies the design and implementation of network applications such
   as L0/L1 VPNs.




Bryskin, et al.          Expires April 30, 2018                [Page 10]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   In Figure 4 a TE topology provider exposes its native (i.e. real,
   physical) TE topology as separate abstract TE topologies to two
   clients, each one customized separately on per client basis.
   According to the IETF TE Topology model each of the three depicted TE
   topologies may have an independent name space for their respective TE
   node, link and SRLG IDs.

    +------------------------------+   +------------------------------+
    |   Customized TE Topology     |   |   Customized TE Topology     |
    |      for Client Blue         |   |      for Client Red          |
    |                              |   |                              |
    |    +---+      +---+          |   |    +---+                     |
    | ---|s3'|------|S5'|---       |   | ---|s3"|--------             |
    |    +---+\     +---+          |   |    +---+\       \            |
    |          \                   |   |          \       \           |
    |           \                  |   |           \       \          |
    |            \        +---+    |   |            \       \+---+    |
    |             --------|S8'|--- |   | \           \       |S8"|--- |
    |                     +---+    |   |  \           \      +---+    |
    |    +---+     +----+          |   |   \+---+     +----+          |
    | ---|S9'|-----|S11'|---       |   | ---|S9"|-----|S11"|---       |
    |    +---+     +----+          |   |    +---+     +----+          |
    | C-B1->S3->S4->S5->C-B2       |   | C-R1->S3->S1->S2->S5->S8     |
    | C-B1->S3->S6->S10->S11->S7   |   |     ->C-R3                   |
    |     ->S8->C-B3               |   | C-R1->S3->S4->S5->S7->S11    |
    | C-B1->S9->S10-S11->C-B3      |   |     ->C-R3                   |
    |                              |   | C-R1->S9->S10->S11->C-R3     |
    |                              |   | C-R2->S9->S10->S11->C-R3     |
    +------------------------------+   +------------------------------+

                     +---+                 +---+
                     |S1 |-----------------|S2 |
                     +---+                 +---+
                      /                       \
                     /                         \
    /----\    +---+ /               +---+       \ +---+         /----\
    |C-B1|----|s3 |-----------------|S4 |---------|S5 |---------|C-B2|
    \----/   /+---+\                +---+         +---+         \----/
            /       \                   \             \
    /----\ /         \                   \             \
    |C-R1|/           \+---+              +---+         +---+    /----\
    \----/ \          /|S6 |\             |S7 |---------|S8 |----|C-B3|
            \        / +---+ \            +---+\       /+---+\  /\----/
    /----\   \+---+ /         \ +---+           +---+ /       \/ /----\
    |C-R2|----|S9 |-------------|S10|-----------|S11|/--------/\-|C-R3|
    \----/    +---+             +---+           +---+            \----/

     Figure 4: Abstract TE topologies customized for different clients



Bryskin, et al.          Expires April 30, 2018                [Page 11]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


2.6.  Topology Relationships

   An IETF TE Topology model provider may expose to the same client
   multiple TE topologies, which:

   o  could be native (as known to the provider, unmodified) or abstract
      (generated by the provider as overlays based on native or lower
      level abstract TE topologies);

   o  could describe different layer networks in accordance with
      distinct layer-specific model augmentations;

   o  abstract TE topologies could be of a different type (e.g. single
      node, link mesh, etc.) and of a different hierarchy level;

   o  abstract TE topologies could be optimized based on different
      optimization criteria (e.g. smallest cost, shortest delay, best
      link protection, etc.)

   The provider can convey to the client the TE topology optimization
   criteria, as well as the provider's preference as to the order in
   which the provided TE topologies are to be used via topology scope
   attributes specifically designed for this purpose.  Furthermore, the
   TE Topology model defines various inter-topology relationships
   designed to describe abstract TE topology hierarchies, client-server
   layer network (vertical) relationships and domain neighboring
   (horizontal) relationships.  The defined inter-topology relationships
   are as follows:

   o  TE node underlay topology: A composite abstract TE node of a
      higher hierarchy level TE topology X, representing a group of
      inter-connected TE nodes that belong to a lower hierarchy level TE
      topology Y, has an attribute pointing to Y (i.e., ID of the
      abstract TE node's internal/encapsulated TE topology);

   o  TE link underlay topology: A TE link of a TE topology X can point
      to TE Topology Y which was used by the provider to compute primary
      and backup TE paths that are (or are to be) used by the actual or
      potential TE tunnel (transport connectivity) supporting the TE
      link in question.  The TE paths themselves could be provided in
      the same TE link attribute;

   o  Supporting node/link topology: A given TE node or link may show up
      in multiple TE topologies catered by the provider to the client.
      In order for the provider not to provide/update (and for the
      client not to consume) multiple identical sets of attributes, the
      model allows for providing/updating only for one (original) TE
      node/link, and having the "twins" point to the original TE mode/



Bryskin, et al.          Expires April 30, 2018                [Page 12]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


      link, as well as to the TE topology where the original TE node/
      link could be found;

   o  Source node/link topology: A given TE node or link catered by the
      provider as a part of a TE topology to the client may be provided
      to the provider by one of its own providers.  In such case the TE
      node/link in question can point to the original TE node/link, as
      well as to the TE topology where the original is defined, thus
      allowing for multi-level multi-provider TE topology hierarchies
      (see Figure 5);

   o  Inter-layer lock: This is the relationship/attribute that
      associates TE links of a higher layer network TE topology with TE
      Tunnel Termination Points (TTPs) of one or more lower layer
      network TE topology(ies) to articulate to the client inter-
      topology /inter-layer adaptation capabilities, to lock the TE
      topologies describing separate layer networks vertically, thus
      allowing for client multi-layer path computations and other multi-
      layer TE applications;

   o  Inter-domain plug: This is a relationship modeled via an inter-
      domain TE link attribute that allows for a client managing
      interconnected multi-domain networks (with each domain served by a
      separate provider) to identify neighboring domains and to lock the
      TE topologies provided by all providers horizontally, thus
      producing TE topologies homogeneously describing the entire multi-
      domain network and allowing for end-to-end path computations
      across the network.























Bryskin, et al.          Expires April 30, 2018                [Page 13]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   +-------------------------------------------------------------------+
   | Domain higher        +---+             +---+                      |
   | level abstract     --| B |-------------| C |--                    |
   | TE topology       /  +---+             +---+  \                   |
   | (Blue)      +---+/                             \+---+             |
   |             | A |                               | D |             |
   |             +---+\                             /+---+             |
   |                   \  +---+             +---+  / TE link E-F is    |
   |                    --| E |-------------| F |--  catered to by     |
   |                     .+---+             +---+.   M-P-Q-N-F' in Red |
   +--------------------.-------------------------.--------------------+
                       .                           .
   +------------------.-----------------------------.------------------+
   | Domain      +---+    +---+             +---+    +---+             |
   | lower level | E'|----| M |-------------| N |----| F'|             |
   | abstract TE +---+@@@@+---+             +---+@@@@+---+             |
   | topology      |     @  |                 |  @     |   TE link P-Q |
   | (Red)         |     @@@|@@@@@@@@@@@@@@@@@|@@@     |   is catered  |
   |             +---+    +---+             +---+    +---+ to P'-X-Q'  |
   |             | O |----| P |-------------| Q |----| R | in Black    |
   |             +---+    +---+             +---+    +---+             |
   +------------------------.-----------------.------------------------+
                            .                 .
   +------------------------.-----------------.------------------------+
   | Domain native        +---+@@         @@+---+                      |
   | TE topology          | P'|--@       @--| Q'|                      |
   | (Black)              +---+  \@@@@@@@/  +---+                      |
   |             +---+            \+---+/            +---+             |
   |             | V |-------------| X |-------------| Z |             |
   |             +---+            /+---+\            +---+             |
   |                      +---+  /       \  +---+                      |
   |                      | W |--         --| Y |                      |
   |                      +---+             +---+                      |
   +-------------------------------------------------------------------+

       Figure 5: Hierarchical multi-provider abstract TE topologies

   A T-API Topology service provider is also allowed to expose multiple
   topologies to the client.  The only inter-topology relationship
   defined is the Node's encapTopology (which is effectively the same as
   the IETF's TE node underlay topology relationship described above).
   Otherwise, all the provided topologies are independent.  It is not
   clear for the client what is the purpose of each of them, what is the
   provider's preference as to how and in which order they are supposed
   to be used, and why several same layer topologies, rather than one,
   were provided to the client in the first place.





Bryskin, et al.          Expires April 30, 2018                [Page 14]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


2.7.  Topology Attributes

   Compared to the IETF TE Topology model, T-API Topology nodes and
   links are missing some important attributes.  Specifically, T-API
   nodes, as mentioned in section 1.1, have no analogs to the
   Connectivity matrix attribute and the TE TTP container describing
   nodes switching and termination capabilities/limitations
   respectively.  Furthermore, the T-API Topology service does not have
   a concept of TTP, which in the context of the IETF TE Topology model
   conveys to the client various important edge characteristics for a TE
   tunnel that could be provided by the network described by a given TE
   topology.  Such characteristics include:

   o  Potential TE tunnel protection capabilities (e.g., whether 1+1
      protection could or could not be supported for the tunnel edge);

   o  Adaptation capacities (i.e., which higher layer network payload
      types and from which higher layer link termination points can be
      adopted on the TE tunnel edge, the amount of adaptation bandwidth
      still available, etc.);

   o  Technology-specific TTPs describe technology specific properties
      (e.g.  TTP representing an OCh layer transponder can announce
      whether the transponder's receiver/transmitter is fixed or
      tunable, and in the latter case what is the range and resolution
      of the tunability; supported FECs and signal modulation modes,
      transmit/acceptable optical signal power levels and OSNRs, etc.)

   The T-API Topology link is missing the following attributes:

   o  Administrative groups (administrative colors) - an attribute
      describing the link's association with pre-defined groups of
      links; such groups could be used as constraints in the client's
      path selection/optimization algorithms to mandate/disallow or
      encourage/discourage the resulting paths to follow/avoid links
      related to the specified groups;

   o  Link protection/restoration capability - an attribute that could
      be also used as a path computation constraint or path optimization
      criterion, for example, to force or encourage the resulting paths
      to follow sufficiently protected links;

   o  Link properties defining whether the link is:

      A.  actual (with committed network resources) or potential;

      B.  static (with pre-established and always-in-place server layer
          connectivity supporting the link) or dynamic (for which the



Bryskin, et al.          Expires April 30, 2018                [Page 15]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


          connectivity is dynamically put in place if/when the link is
          used by at least one client connection and is dynamically
          released as soon as the link is used by none of the client's
          connections);

   o  Link's underlay primary and backup paths and ID of the topology
      used for their computations.

2.8.  Topology Service Relationships with Other Services

   IETF TE topology and TE tunnel models are related.  For example, a TE
   link can point via the Supporting Tunnel ID attribute to the lower
   layer network TE tunnel providing the transport connectivity for the
   TE link.  Likewise, a TE tunnel has an attribute pointing to the TE
   link it supports, as well as the TE topology which the TE link is
   part of.  These cross-references are instrumental for the client in
   terms of understanding which network resources a given TE link
   represents, especially useful at the times of trouble shooting.
   Additionally, IETF TE tunnel defines and supports the concept of
   Hierarchical TE links and tunnels.  Hierarchical TE tunnels
   automatically insert dynamic hierarchical TE links into the specified
   TE topologies as soon as the tunnels are successfully set up (and
   remove the hierarchical TE links from the respective TE topologies
   when released).  [Note: Hierarchical TE tunnels and links are
   instrumental in multi-layer traffic engineering].

   Furthermore, both TE topology and TE tunnel models are tightly
   coupled with the IETF YANG based notification machinery, which allows
   the client to retrieve any telemetry or attribute change updates as
   long as those telemetry/attribute changes are defined as data state
   nodes or sub-trees in the respective models.

   In contrast, all T-API services (i.e.  Topology, Connectivity, Path
   computation, Virtual Network and Notification) are independent from
   each other.

2.9.  Topology Negotiation and (Re-)configuration

   When a client of the IETF TE Topology model/interface receives one or
   more abstract TE topologies from one of its providers, it may accept
   the topologies as-is and merge then into one or more of its own
   native TE topologies.  Alternatively, the client may choose to
   request a re-configuration of one, some or all abstract TE topologies
   provided by the providers.  Specifically, with respect to a given
   abstract TE topology, some of its TE nodes/links may be requested to
   be removed, while additional ones may be requested to be added.  It
   is also possible that existing TE nodes/links may be asked to be re-
   configured (e.g., TE links may be requested to be SRLG disjoint).



Bryskin, et al.          Expires April 30, 2018                [Page 16]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   Furthermore, the topology-wide optimization criteria may be requested
   to be changed.  For example, underlay TE paths supporting the
   abstract TE links, currently optimized to be shortest (least-cost)
   paths, may be requested to be re-optimized based on the minimal delay
   criteria.  Additionally, the client may request the providers to
   configure entirely new abstract TE topologies and/or to remove
   existing ones.  Furthermore, future periodic or one-time additions,
   removals and/or re-configurations of abstract TE topologies,
   topological elements and/or their attributes could be (re-)scheduled
   by the client ahead of time.

   It is the responsibility of the client to implement the logic behind
   the above-described abstract TE topology negotiation.  It is expected
   that the logic is influenced by the client's local configuration/
   templates, policies conveyed by the client's clients, input from the
   network planning process, telemetry processor, analytics systems and/
   or direct human operator commands.  Figure 6 exemplifies the abstract
   TE topology negotiation process.  As shown in the Figure, the
   original abstract TE topology exposed by a provider was requested to
   be re-configured.  Specifically, one of the abstract TE links was
   asked to be removed, while three new ones were asked to be added to
   the abstract TE topology.

   The ONF T-API Topology service client has no say as to how the
   abstract topologies exposed to the client by its providers should
   look like.  The only option for the client is to consume the provided
   topologies as offered.  This is a serious disadvantage because it is
   the client (not providers) that knows which topologies suite best the
   client's needs.






















Bryskin, et al.          Expires April 30, 2018                [Page 17]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


                                  Client

                                  /\  ||
                                  ||  ||
     Original abstract TE         ||  || Abstract TE topology
     topology by Provider         ||  || re-configured by Client
                                  ||  ||
        +---+      +---+          ||  ||    +---+      +---+
     ---|s3 |------|S5 |---       ||  || ---|s3 |------|S5 |---
        +---+\     +---+          ||  ||    +---+\ \  /+---+
              \                   ||  ||      |   \ \/    \
               \                  ||  ||      |    \/\     \
                \        +---+    ||  ||      |    /\ \     \+---+
                 --------|S8 |--- ||  || \    |   /  \ ------|S8 |---
                         +---+    ||  ||  \   |  /    \      +---+
        +---+      +---+          ||  ||   \+---+      +---+
     ---|S9 |------|S7 |---       ||  || ---|S9 |------|S7 |---
        +---+      +---+          ||  ||    +---+      +---+
                                  ||  \/

                                 Provider

        Figure 6: Provider-Client abstract TE topology negotiation

2.10.  Integration with IP/MPLS

   The IETF TE Topology model is naturally and intimately integrated
   with IP/MPLS layer models defined for IP/MPLS layer traffic
   engineering.  For example, currently Segment Routing (SR) and Service
   Function Chaining (SFC) technologies heavily rely on and actively use
   the TE Topology model.  Specifically, SR combines the TE topology
   model with layer 3 (IP reachability) topology model to facilitate
   path computations that account for either or both TE and IP
   reachability information.  Likewise, SFC makes use of the TE topology
   model for computing service function chains optimized according to
   the combined criteria of real/virtual network function location and
   best available (possibly in different layers) TE paths to connect the
   network functions.

   It is not clear how the ONF T-API Topology service can fit in and to
   what extent it can be integrated into the IP/MPLS layer traffic
   engineering.

3.  Connectivity Service







Bryskin, et al.          Expires April 30, 2018                [Page 18]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


3.1.  Connectivity Service Protection

   It is not possible for a T-API Connectivity service client to request
   from a provider a protected service like, for example, the one
   presented in Figure 7.  In the Figure a connectivity service is
   supported by two disjoint connections - primary (solid blue) and
   backup (broken yellow), with the client traffic normally carried over
   the primary connection, but which could be quickly and dynamically
   switched onto the backup connection as soon as a network failure
   affecting the primary connection is detected.

   The inability to request protected connectivity services from a
   provider leaves the T-API Connectivity service client with the
   problem of protecting its own traffic against the network's failures.
   Admittedly, the client can address this with the following sequence
   of operations:

   1.  The client requests a primary connectivity service connecting the
       desired pair of client device ports over the network managed by
       the T-API Connectivity service provider;

   2.  The client requests a secondary connectivity service connecting
       the same pair of client device ports, which is sufficiently
       diverse from the primary service (incidentally, this could be
       problematic due to the independent nature of the path
       computations carried out by the provider.  Specifically, the path
       selected for the primary service may block disjoint paths for the
       secondary service.  This is a known issue related to sequential/
       independent path computations, which could be solved via
       concurrent path computation for both services);

   3.  The client binds at both ends the two connectivity services in
       accordance with the desired protection scheme;

   4.  From then on the client is constantly monitoring the performance
       and health of both services;

   5.  In case the primary service is affected by a network failure
       (while the secondary service remaining healthy), the client
       coordinates the protection switchover;

   6.  In case it is detected that the previously broken primary
       connectivity service is repaired, the client coordinates the
       protection reversion (i.e. reversion to the normal forwarding of
       the client traffic).






Bryskin, et al.          Expires April 30, 2018                [Page 19]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   Customer                                                     Customer
   domain 1                                                     domain 3
           +----------------------------+ +---------------------+
           |Network  +---+$$$$$$$$+---+ | |Network              |
           |domain 1 |S1 |--------|S2 |\| |domain 3             |
           |        $+---+        +---+$\ |                     |
           |       $/               |   $\|                     |
           |     $$/                |   |$\                     |
    /----\ | +---+/         +---+   |   | $\        +---+       | /----\
    |C-R1|-+-|S3 |----------|S4 |   |   | |$\-------|S36|-------+-|C-R7|
    \----/ | +---+\         +---+   |   | | $$$$$$$ +---+       | \----/
           |      $\           \    |   | |        /   $\       |
    /----\ |       $\           \   |   | |       /     $\      |
    |C-R2| |       $+---+        \  |   | | +---+/       $+---+ | /----\
    \----/\|       $|S6 |         \ |   | --|S37|         |S38|-+-|C-R8|
           \     $$/+---+\         \|   |/| +---+\       /+---+ | \----/
    /----\ |\+---+/@@@@@@ \+---+  +---+ / |   |   \+---+/$      |
    |C-R3|-+-|S9 |-------@-|S10|--|S11|/| |   |    |S39|$       |
    \----/ | +---+        @+---+  +---+ | |   |    +---+        |
           +-------------@/------------\+ +---|------|$---------+
                        @/              \     |      |$
           +-----------@/----------------\----|------|$-------+
           |Network  +---+                \+---+     |$       |
           |domain 2 |S21|-----------------|S22|     |$       | Customer
           |         +---+                 +---+     |$       | domain 2
           |         @/                       \      |$       |
           |        @/                         \     |$       |
           |  +---+@/               +---+       \ +---+       | /----\
           |  |s23|-----------------|S24|---------|S25|-------+-|C-R4|
           |  +---+\@             @/+---+         +---+       | \----/
           |        \@           @/     \@            \$      |
           |         \@         @/       \@            \$     |
           |          \+---+@@@@/         +---+         +---+ |  /----\
           |          /|S26|----          |S27|--------@|S28|-+--|C-R5|
           |         / +---+ \            +---+\@     @/+---+ |  \----/
           |  +---+ /         \ +---+           +---+@/       |  /----\
           |  |S29|-------------|S30|-----------|S31|/--------+--|C-R6|
           |  +---+             +---+           +---+         |  \----/
           +--------------------------------------------------+

                 Figure 7: Protected connectivity service

   In contrast, an IETF TE tunnel model client normally delegates all
   the described above operations to the provider by simply configuring
   the requested transport service (i.e.  TE tunnel or a single-domain
   segment of a multi-domain TE tunnel) to be protected.  In doing so
   the client specifies the required protection type, as well as the
   level of primary/backup connections disjointedness.  Additionally,



Bryskin, et al.          Expires April 30, 2018                [Page 20]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   the client may specify a set of constraints common for both
   connections, as well as constraints (e.g. inclusions, exclusions,
   etc) specific to each connection.  Furthermore, the client may even
   specify, for a given transport service, multiple sets of such
   constraints in descending preference order for the provider to try
   before notifying the client about the setup failure.  For example,
   the client may request in this way for a TE tunnel that the primary
   and backup connections must be SRLG disjoint, and, if this proves to
   be not possible, to relax the disjointedness criterion to link-
   disjoint.

3.2.  Hierarchical Connectivity Service

   A transport network provider may control a multi-layer (e.g.
   Ethernet/ODUk/OCh) network.  On such a network the provider has
   flexibility to dynamically set up connectivity/transport services in
   one or more lower layer networks to augment a higher layer topology
   that is otherwise insufficient for provisioning of a connectivity
   service requested by the client.

   In the top-to-bottom approach the client simply requests a
   connectivity service in the desired layer network.  While processing
   the request, the provider:

   o  performs its internal multi-layer path computation,

   o  identifies one or more lower layer connectivity services required
      for the successful provisioning of the requested service;

   o  dynamically (and unknowingly to the client) sets up the so-
      identified lower layer connections;

   o  sets up the connection(s) supporting the connectivity service
      requested by the client.

   Both T-API Connectivity service and IETF TE Topology model/interface
   support the described top-to-bottom multi-layer connectivity
   services.  The approach is simple for the client; however it does not
   work in many multi-domain use cases.  Consider, for example, a multi-
   domain transport network presented in Figure 8.  Consider further
   that a Multi-Domain Service Coordinator is requested to set up
   Ethernet layer connectivity service (marked in blue) across three
   domains, each of which is controlled by a separate provider.  Assume
   also that in order to satisfy the request an underlay ODUk layer TE
   tunnel (marked as red) also spanning multiple domains needs to be
   provisioned.  This could be achieved via a bottom-to-top multi-layer
   connectivity service provisioning approach, which includes the
   following:



Bryskin, et al.          Expires April 30, 2018                [Page 21]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   o  the client (i.e. the Multi-Domain Coordinator) performs its own
      multi-layer path computation on a network wide TE topology (a
      product of merging the TE topologies exposed by all providers);

   o  the client identifies one or more lower layer TE tunnels required
      for the successful provisioning of the requested service;

   o  the client coordinates the multi-domain setup of each of the
      identified lower layer TE tunnels;

   o  the client instructs each lower layer TE tunnel's first and last
      domain provider to add a dynamic TE link in their respective
      higher layer TE topologies;

   o  the client triggers and coordinates the setup of the connection(s)
      supporting the requested connectivity service, constraining the
      connection path(s) to follow the dynamic TE links supported by the
      lower layer TE tunnels;

   o  the client adds into its own (network-wide) TE topology, dynamic
      TE links supported by the lower layer TE tunnels to make the
      remaining capacity on the tunnels available for path computations
      for other higher layer connectivity services.




























Bryskin, et al.          Expires April 30, 2018                [Page 22]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   Customer                                                     Customer
   domain 1                                                     domain 3
           +----------------------------+ +---------------------+
           |Network  +---+        +---+ | |Network              |
           |domain 1 |S1 |--------|S2 |\| |domain 3             |
           |         +---+        +---+ \ |                     |
           |        /               |   |\|                     |
           |       /                |   | \                     |
    /----\ | +---+/         +---+   |   | |\        +---+       | /----\
    |C-R1|-+-|S3 |----------|S4 |   |   | | \-------|S36|-------+-|C-R7|
    \----/ | +---+\         +---+   |   | |         +---+       | \----/
           |       \           \    |   | |        /    \       |
    /----\ |        \           \   |   | |       /      \      |
    |C-R2|b|        +---+        \  |   | b +---+/        +---+ | /----\
    \----/\b        |S6 |         \ |   |b--|S37|         |S38|-+-|C-R8|
           \b      /+---+\         \|   b/r +---+\bb     /+---+ | \----/
    /----\ |\+---+/ bbbbb \+---+bb+---+ /r|   | rr\+---+/       |
    |C-R3|-+-|S9 |---------|S10|--|S11|/r |   |    |S39|        |
    \----/ | +---+ rrrrrrr +---+rr+---+ | |   |    +---+        |
           +--------------/------------\+ +---|-----r|b---------+
                         /              \     |     r|b
           +------------/----------------\----|-----r|b-------+
           |Network  +---+                \+---+    r|b       |
           |domain 2 |S21|-----------------|S22|    r|b       | Customer
           |         +---+                 +---+    r|b       | domain 2
           |          /                       \     r|b       |
           |         /                         \    r|b       |
           |  +---+ /               +---+       \ +---+       | /----\
           |  |s23|-----------------|S24|---------|S25|-------+-|C-R4|
           |  +---+\               /+---+         +---+       | \----/
           |        \             /     \            r\b      |
           |         \           /       \            r\b     |
           |          \+---+    /         +---+        r+---+bbbb/----\
           |          /|S26|----          |S27|---------|S28|-+--|C-R5|
           |         / +---+ \            +---+\       /+---+ |  \----/
           |  +---+ /         \ +---+           +---+ /       |  /----\
           |  |S29|-------------|S30|-----------|S31|/--------+--|C-R6|
           |  +---+             +---+           +---+         |  \----/
           +--------------------------------------------------+

                Figure 8: Hierarchical connectivity service

   The IETF TE topology model supports the described bottom-to-top
   multi-layer connectivity service provisioning paradigm via Hierarchy
   TE tunnels.  A hierarchy TE tunnel, once successfully set up,
   automatically adds into the specified TE topology a TE link it
   supports and withdraws the TE link from the TE topology if/when
   released.



Bryskin, et al.          Expires April 30, 2018                [Page 23]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   T-API Connectivity and Topology services do not support the concept
   of hierarchical connectivity/dynamic links.

3.3.  Connectivity Service Re-optimization

   An IETF TE tunnel model/interface client, when requesting a transport
   service from a provider, can control - via a designed for this
   purpose knob (lockDown attribute) - whether the connection(s)
   supporting the service must be "pinned" to their respective original
   paths (the paths selected at the setup stage), or whether the
   provider may occasionally perform a service re-optimization,
   resulting in service connection replacement toward more optimal
   paths.  This knob is especially useful in conjunction with a
   connectivity scheduling service (see section 2.6), allowing for the
   client to specify time intervals at which the re-optimization of a
   given transport service (and subsequent potential traffic hits) is
   acceptable for the client.  For example, the client may configure a
   transport service to get "unpinned" every Saturday at 1 am for
   service re-optimization procedures and to get "re-pinned" after that
   for another week.

   T-API Connectivity service clients have no way of controlling of
   connectivity service re-optimization operations.

3.4.  Connectivity Service Templates

   The IETF TE tunnel model defines containers of named transport
   service configuration sets that could be shared by multiple services.
   This not only simplifies for the client the process of transport
   service configuration, but also allows manipulation of multiple
   services by a single configuration change.  For example, a client may
   define a set of constraints named Foo that forces a transport service
   primary path to go through a node X.  If, later, the client modifies
   Foo by substituting node X with node Y, all transport services
   configured with the constraint set Foo will (be attempted to) be re-
   placed onto path(s) going through node Y.

   The T-API Connectivity service model does not have a similar concept.

3.5.  Connectivity Service Attribute Change Update Notifications and
      Telemetry Streaming

   Both T-API and IETF modeling rely on respective notification tools
   universal across all interfaces.  Therefore, connectivity service
   attribute change notifications and telemetry streaming is no
   different from the topology notifications and telemetry streaming
   discussed in sections 2.3 and 2.4




Bryskin, et al.          Expires April 30, 2018                [Page 24]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


3.6.  Connectivity Scheduling

   T-API Connectivity service has the _schedule attribute that includes
   just two parameters: startTime and endTime.  This allows for a client
   to schedule at a specified time and for a specified period of time a
   one-time kickoff of a service configured initially (presumably) as
   disabled.  It is not possible to schedule multi-time (periodic)
   kickoffs.  Furthermore, the scheduling granularity is connectivity
   service as a whole.  In particular, it is not possible to schedule
   re-configurations of one or several service parameters (e.g.
   bandwidth requirement, inclusion/exclusion path, etc.).

   There is an ongoing effort in IETF to produce a generic scheduling
   tool that could be applied to any of YANG models.  Similar to the
   notification subscription tool - allowing for the client to subscribe
   on notifications with respect to any data state (CONFIG=FALSE) node
   defined in any supported by the provider data store - the scheduling
   tool will allow for the client to schedule periodic and/or one-time
   modification of any configuration (CONFIG=TRUE) leaf of any supported
   data store.  For example, if it is required to schedule a re-
   configuration of the bandwidth requirement for one or more selected
   services, the client will specify an XPath pointing to the configured
   bandwidth attribute of the services of interest and convey the new
   bandwidth requirement and the timetable for the service bandwidth re-
   configuration.  [Note: At time intervals outside of the scheduled
   range, the service configured bandwidth will remain/be restored to
   the value provided during initial service configuration.]

3.7.  Potential Connectivity Service

   The IETF TE topology model defines a number of "unconventional"
   configuration modes to be specified by a client and supported by a
   provider of transport services.  One of those modes is the
   COMPUTE_ONLY mode.  When a provider processes a request for a
   transport service configured in the COMPUTE_ONLY mode, it performs
   the normal path computation for the service, but does not trigger
   setup of the connection(s) supporting the service.  Instead, the
   computed paths are returned to the client as a part of normal service
   attribute change notification.  Furthermore, when the provider
   detects a change in the managed network potentially affecting the
   returned paths, it may re-evaluate the paths and notify the client if
   they have become infeasible or more optimal paths are available.

   The concept of COMPUTE_ONLY transport services makes a good
   foundation for Path computation service/interface between the Client
   and the Provider (see more in section 4).





Bryskin, et al.          Expires April 30, 2018                [Page 25]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


4.  Path Computation Service

   A client of a transport network can discover the network resources
   available for the client in one of the two ways:

   o  by requesting from the network provider , via a topology
      interface, one or more topologies describing the network with
      respect to its availability to the client;

   or

   o  by requesting, via a path computation interface, that the provider
      identify potential paths that could connect various client device
      ports across the network.

   To support the latter option, ONF T-API has introduced a Path
   computation service dedicated to the purpose.  A T-API Path
   computation service client can issue a path computation request
   specifying the identities of the required path source and destination
   end points, the layer network in which the paths are to be
   determined, the required mutual diversity of the resulting paths,
   various path computation constraints (e.g., bandwidth requirements,
   inclusions, exclusions, etc.) and path selection optimization
   criteria (e.g., smallest cost, shortest delay, etc.).  A T-API Path
   computation service provider is expected to satisfy the request by
   running a path computation algorithm and responding to the client
   with zero, one or more resulting paths.

   In contrast, IETF modeling does not offer a dedicated mechanism/model
   to support the Client<=>Provider path computation interface.
   Instead, it is suggested to use the YANG TE tunnel model and request
   and manipulate path computations in the form of COMPUTE_ONLY TE
   tunnels as described in section 2.7.  This approach has some
   important advantages as compared to the T-API Path computation
   service:

   Simplicity:  provided that both the client and the provider know how
      to request, manipulate and support transport services, there is no
      additional interface/model for the client to learn how to use and
      functionality for the provider to support;

   Accuracy:  T-API Path computation and Connectivity services are not
      related.  It cannot be guaranteed that the set of path computation
      constraints conveyed by a T-API Path computation service client
      will match the set of path computation constraints internally
      generated by a T-API Connectivity service provider even when the
      configuration parameters - source/destination, layer network,




Bryskin, et al.          Expires April 30, 2018                [Page 26]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


      bandwidth and others - match.  There are many reasons for that,
      including:

      A.  additional constraints could be imposed by the provider based
          on some internal and possibly proprietary knowledge about the
          network (unknown to the client);

      B.  various internal policies could relax, harden or overwrite
          other constraints;

      C.  various internal policies could modify or overwrite the
          requested optimization criteria;

      D.  etc.

      Furthermore, the provider may even use different path computation
      engines to provide the Path computation and connectivity services.
      All this may result in the paths returned to the Path computation
      service client being different from the paths taken by the
      corresponding (same source/destination and other constraints)
      connectivity services.  The difference may be in path costs, delay
      and fate sharing characteristics, etc.  In extreme cases the Path
      computation service client may even receive unprovisionable and
      hence useless paths.

      IETF COMPUTE_ONLY TE tunnels, on the other hand, do not have such
      problems.  It is inherently guaranteed that the client will be
      notified/updated with paths which are exactly the same as the ones
      that would be taken by connections of "conventional" TE tunnels
      for the same configuration inputs;

   Path staleness:  paths returned to the T-API Path computation service
      client may become unfeasible at some later time because of changes
      in the network's state.  There is no way for the Path computation
      service provider to convey this fact to the client.  In contrast,
      IETF COMPUTE_ONLY TE tunnel provider can use the intrinsic
      attribute change notifications to let the client know that
      previously provided paths have changed, have become unfeasible or
      that better, more optimal paths have become available.

5.  Virtual Network Service

   A client of a transport network may want to limit the transport
   network connectivity of a particular type and quality to defined
   subsets of its device ports interconnected across the network.
   Furthermore, a given transport network may serve more than one
   client.  In this case some or all clients may want to ensure the
   availability of transport network resources in case dynamic



Bryskin, et al.          Expires April 30, 2018                [Page 27]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   (re-)connection of their device ports across the network is
   envisioned.  In all such cases a client may want to set up one or
   more Virtual Networks over the provided transport network.

   ONF T-API has introduced a dedicated service for this purpose - the
   Virtual Network service (VNS).  A VNS client can request creation of
   a VNS specifying the layer network of the VNS and the Traffic Matrix
   requirement.  The client has no control over the requested VN beyond
   that.  In particular, it is up to the provider to decide which
   network resources will support the VN in question.  The client has no
   say as to how the underlying network topology should look, how the
   topology needs to be optimized for the VN (e.g. shortest delay rather
   than smallest cost), what is the required level of the topology link
   protection and mutual diversity, and so forth.

   As in case of the path computation interface, IETF modeling does not
   offer a separate model to support VNS.  Instead, it encourages using
   the TE topology model - leveraging the IETF abstract TE topology's
   ability to be configured by the client.  In a nutshell, the client
   configures and manipulates a VN as a customized abstract TE topology
   based on the TE topologies already exposed by the provider.  In the
   simplest case the client requests a single node ("black box")
   abstract TE topology with desired attributes.  In more complex cases
   the client may opt to construct, for the VN, a separate multi-node/
   link arbitrary abstract TE topology.  In doing so, the client may
   "borrow" into the VN's topology TE nodes and links from other
   topologies.  Additionally the client may add new composite abstract
   TE nodes specifying the IDs of TE topologies the nodes will
   encapsulate, connected by abstract TE links pointing to the
   respective underlay TE topologies to be used for computation and
   provisioning of the TE tunnels supporting them.  The client/provider
   negotiation of a"so-cooked" TE topology is described in 1.9.  In
   short, the client is able to manipulate the VN's topology at the
   granularity of individual topological elements (such as TE nodes and
   links).

6.  Data Modeling Language

   Today YANG is a very popular data modeling language.  It is a product
   of IETF NETMOD WG.  It is not the only data modeling language
   produced by IETF (for example, FORCES WG has developed one of its
   own, arguably - in some aspects - superior to YANG).  YANG is neither
   stable nor perfect.  It is constantly evolving with the sole
   objective to make IETF models more scalable, efficient, inclusive,
   information-rich: better in all aspects.  Supporting non-IETF (e.g.
   ONF) data models is not a priority.  Therefore It is not clear why
   ONF, while investing a lot of effort in designing Core Information
   Models, is devoting no effort to designing a data modeling language



Bryskin, et al.          Expires April 30, 2018                [Page 28]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   of its own that would closely suit support of its CIM.  Nor it is
   clear what would happen if the IETF NETMOD WG decides, for whatever
   reason to obsolete some of the YANG features/properties/capabilities
   that ONF models rely upon.

   Furthermore, writing CIMs in UML and having them mechanically
   translated into YANG has its own issues, which includes the
   following:

   o  Many useful YANG features that do not have analogs in UML are not
      used.  For example, T-API YANG models use only non-extendible
      enumeration type, rather than extendible identity type.  This
      prevents T-API YANG models from being easily extendible via
      augmentation;

   o  T-API YANG models heavily overuse and often misuse YANG RPCs for
      operations that could be handled simpler and more efficiently by
      NETCONF/RESTCONF protocol via native edit-config and get
      operations;

   o  T-API YANG models unnecessarily define their own notification
      subscription/streaming and scheduling mechanisms, instead of
      leveraging the NETCONF/RESTCONF machinery easily applicable to all
      YANG models;

   o  T-API YANG models make no use of YANG templates and defaults
      designed to simplify for the client the provider's data store
      (re-)configuration;

   o  T-API YANG models follow the conventions inherited from UML and
      previously defined REST APIs.  As a consequence. the models
      sometimes are not compatible with the current best practices
      recommended for YANG model writers and do not always follow YANG
      model guidelines defined in [I-D.ietf-netmod-rfc6087bis]

7.  Security Framework

   ONF T-API does not have a security framework of its own.  It simply
   assumes that the proper security could be inherently provided by the
   underlying protocols.  IETF TEAS interfaces, on the other hand, take
   the security considerations very seriously.  They rely on the generic
   framework ([RFC6241], [RFC8040], [RFC6536], and
   [I-D.ietf-netconf-rfc6536bis]) allowing for the provider to configure
   in a universal way various strength AAA protection for any YANG
   modeled data store accessible via NETCONF or RESTCONF protocol.  In
   particular, said framework allows for the client authentication,
   identification of the client's privileges with respect to the




Bryskin, et al.          Expires April 30, 2018                [Page 29]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   information access, required filtering and scoping of the provided
   information, as well as secure client-provider communication.

8.  IANA Considerations

   This document has no actions for IANA.

9.  Security Considerations

   This document does not define networking protocols and data, hence
   are not directly responsible for security risks.

   This document compares two interface technologies of T-SDN
   controllers.  For each specific technology discussed in the document,
   security framework has been described and compared in the
   corresponding section.

10.  Acknowledgements

   The authors would like to thank Christopher Jenz, Diego Caviglia,
   Aihua Guo, Fatai Zhang, and Italo Busi for their helpful comments and
   valuable contributions.

11.  References

11.1.  Normative References

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
              editor.org/info/rfc6536>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.







Bryskin, et al.          Expires April 30, 2018                [Page 30]


Internet-Draft            YANG TE IETF vs. ONF              October 2017


   [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-12 (work in progress), July 2017.

   [I-D.ietf-teas-yang-te]
              Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and
              I. Bryskin, "A YANG Data Model for Traffic Engineering
              Tunnels and Interfaces", draft-ietf-teas-yang-te-08 (work
              in progress), July 2017.

   [I-D.ietf-netconf-rfc6536bis]
              Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Module", draft-ietf-netconf-rfc6536bis-08
              (work in progress), October 2017.

11.2.  Informative References

   [I-D.ietf-netmod-rfc6087bis]
              Bierman, A., "Guidelines for Authors and Reviewers of YANG
              Data Model Documents", draft-ietf-netmod-rfc6087bis-14
              (work in progress), September 2017.

Authors' Addresses

   Igor Bryskin
   Huawei Technologies

   EMail: Igor.Bryskin@huawei.com


   Xufeng Liu
   Jabil

   EMail: Xufeng_Liu@jabil.com


   Vishnu Pavan Beeram
   Juniper Networks

   EMail: vbeeram@juniper.net


   Tarek Saad
   Cisco Systems Inc

   EMail: tsaad@cisco.com




Bryskin, et al.          Expires April 30, 2018                [Page 31]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/