Network Working Group I. Bryskin Internet-Draft Huawei Technologies Intended status: Informational X. Liu Expires: September 14, 2017 Jabil V. Beeram Juniper Networks T. Saad Cisco Systems Inc March 13, 2017 ONF/T-API Services vs. IETF/YANG Models and Interfaces draft-bryskin-teas-yang-ietf-vs-onf-00 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 September 14, 2017. 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 September 14, 2017 [Page 1] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 2] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 3] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 4] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 5] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 6] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 7] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 8] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 9] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 10] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 11] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 12] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 13] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 14] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 15] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 16] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 17] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 18] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 19] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 20] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 21] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 22] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 23] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 24] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 25] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 26] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 27] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 28] Internet-Draft YANG TE IETF vs. ONF March 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 September 14, 2017 [Page 29] Internet-Draft YANG TE IETF vs. ONF March 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, . [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . Bryskin, et al. Expires September 14, 2017 [Page 30] Internet-Draft YANG TE IETF vs. ONF March 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-06 (work in progress), October 2016. [I-D.ietf-teas-yang-te] Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., Bryskin, I., Chen, X., Jones, R., and B. Wen, "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang-te-05 (work in progress), October 2016. [I-D.ietf-netconf-rfc6536bis] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", draft-ietf- netconf-rfc6536bis-01 (work in progress), March 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-12 (work in progress), March 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 September 14, 2017 [Page 31]