idnits 2.17.1 draft-bryskin-teas-yang-ietf-vs-onf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2594 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-06 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-05 == Outdated reference: A later version (-09) exists of draft-ietf-netconf-rfc6536bis-01 == Outdated reference: A later version (-20) exists of draft-ietf-netmod-rfc6087bis-12 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Bryskin 3 Internet-Draft Huawei Technologies 4 Intended status: Informational X. Liu 5 Expires: September 14, 2017 Jabil 6 V. Beeram 7 Juniper Networks 8 T. Saad 9 Cisco Systems Inc 10 March 13, 2017 12 ONF/T-API Services vs. IETF/YANG Models and Interfaces 13 draft-bryskin-teas-yang-ietf-vs-onf-00 15 Abstract 17 This document compares IETF YANG TE (Traffic Engineering) data model 18 and ONF/T-API model. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 14, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Topology Service . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Intra-node Metrics . . . . . . . . . . . . . . . . . . . 5 58 2.3. Topology Updates . . . . . . . . . . . . . . . . . . . . 6 59 2.4. Topology Telemetry Collection . . . . . . . . . . . . . . 9 60 2.5. Topology Name/Address Spaces . . . . . . . . . . . . . . 10 61 2.6. Topology Relationships . . . . . . . . . . . . . . . . . 12 62 2.7. Topology Attributes . . . . . . . . . . . . . . . . . . . 15 63 2.8. Topology Service Relationships with Other Services . . . 16 64 2.9. Topology Negotiation and (Re-)configuration . . . . . . . 16 65 2.10. Integration with IP/MPLS . . . . . . . . . . . . . . . . 18 66 3. Connectivity Service . . . . . . . . . . . . . . . . . . . . 18 67 3.1. Connectivity Service Protection . . . . . . . . . . . . . 19 68 3.2. Hierarchical Connectivity Service . . . . . . . . . . . . 21 69 3.3. Connectivity Service Re-optimization . . . . . . . . . . 24 70 3.4. Connectivity Service Templates . . . . . . . . . . . . . 24 71 3.5. Connectivity Service Attribute Change Update 72 Notifications and Telemetry Streaming . . . . . . . . . . 24 73 3.6. Connectivity Scheduling . . . . . . . . . . . . . . . . . 25 74 3.7. Potential Connectivity Service . . . . . . . . . . . . . 25 75 4. Path Computation Service . . . . . . . . . . . . . . . . . . 26 76 5. Virtual Network Service . . . . . . . . . . . . . . . . . . . 27 77 6. Data Modeling Language . . . . . . . . . . . . . . . . . . . 28 78 7. Security Framework . . . . . . . . . . . . . . . . . . . . . 29 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 84 11.2. Informative References . . . . . . . . . . . . . . . . . 31 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 87 1. Introduction 89 The success of T-SDN as an architecture depends to a large degree on 90 the quality and widespread adoption of open standardized interfaces 91 to/from T-SDN controllers, linking them flexibly into various 92 hierarchies and confederations. Currently, the two most popular such 93 interfaces are: 95 1. T-API developed by ONF; 96 2. RESTCONF/YANG [RFC7950] based on TE Topology and TE Tunnels 97 models defined in [I-D.ietf-teas-yang-te-topo] and 98 [I-D.ietf-teas-yang-te] documents respectively, the product of 99 IETF TEAS WG. 101 The two interfaces have the close attention of network operators and 102 vendors. There is a lot of confusion about their respective 103 technical merits and "marketing" strengths, applications they can 104 support, use cases they cover, and so on. Do they compete or could 105 they somehow complement each other? 107 This memo is limited to a strictly technical comparison with the 108 special focus on the models supporting the two interfaces, in 109 particular, the semantics, relationships, informational flows and 110 services they define. Our analysis suggests that the IETF models 111 provide for implementation of powerful hierarchical T-SDN controller 112 systems, supporting a broad range of client systems and use cases, 113 and that in some identifiable respects, T-API appears to fall 114 relatively shorter. This memo is largely organized around 115 considering the identified "gaps". 117 2. Topology Service 119 2.1. Constrained Nodes 121 The T-API Topology service does not support the notion of blocking/ 122 constrained nodes. This means that if a T-API Topology service 123 provider exposes to a client a topology with at least one node with 124 constrained connectivity, e.g. the node can switch a potential TE 125 path/connection, say, from interface (NodeEdge point) A to B, but not 126 from A to C; there is no way for the provider to communicate the 127 connection limitations to the client, thus making the provided TE 128 topology unfit for the client's path computations. This is a serious 129 issue because many transport physical switches and virtually all 130 abstract composite nodes should be treated as blocking nodes. 132 Likewise, if a potential path source/destination node is constrained 133 in such a way that the path may leave/enter the source/destination 134 node over a link from a subset of (but not all) same-layer links 135 connected to the node, the T-API Topology service provider has no way 136 of communicating such a circumstance to the client. 138 The described issue is addressed in the IETF TE Topology model. A TE 139 node's Connectivity Matrix attribute (Figure 1) fully describes the 140 node's TE path/connection switching limitations, while a TE Tunnel 141 Termination Point's (TTP's) Local Link Connectivity List attribute 142 (Figure 2) describes the node's TE path/connection termination 143 limitations with respect to each TTP hosted by the node in question. 145 Basic Connectivity Matrix: Detailed Connectivity Matrix: 147 LTP-6/label-x <=> LTP-1/label-y LTP-6/label-x <=> LTP-1/label-y 148 (Cost c, Delay d, SRLB s, ...) 149 LTP-5/label-x <=> LTP-2/label-y LTP-5/label-x <=> LTP-2/label-y 150 (Cost c, Delay d, SRLB s, ...) 151 LTP-5/label-x <=> LTP-4/label-y LTP-5/label-x <=> LTP-4/label-y 152 (Cost c, Delay d, SRLB s, ...) 153 LTP-4/label-x <=> LTP-1/label-y LTP-4/label-x <=> LTP-1/label-y 154 (Cost c, Delay d, SRLB s, ...) 155 LTP-3/label-x <=> LTP-2/label-y LTP-3/label-x <=> LTP-2/label-y 156 ... ... 158 +------------+ 159 | | 160 LTP-6| |LTP-1 161 -------o************o------- 162 | * | 163 LTP-5| * |LTP-2 164 -------o************o------- 165 | * * * | 166 | ** * | 167 +--o------o--+ 168 LTP-4 LTP-3 170 Figure 1: TE Node Connectivity Matrix 172 TTP-1 Basic LLCL: TTP-1 Detailed LLCL: 174 TTP-1 <=> {LTP-5/label-x, TTP-1 <=> { 175 LTP-2/label-y} LTP-5/label-x, 176 (Cost c, Delay d, SRLB s, ...), 177 LTP-2/label-y, 178 (Cost c, Delay d, SRLB s, ...) 179 } 181 +------------+ 182 | TTP-1 | 183 | __ | 184 LTP-6| \/ |LTP-1 185 -------o * * o------- 186 | * * | 187 | * TTP-2* | 188 LTP-5| * __ * |LTP-2 189 -------o* \/ *o------- 190 | * * | 191 | * * | 192 +--o------o--+ 193 LTP-4 LTP-3 195 Figure 2: TTP Local Link Connectivity List 197 2.2. Intra-node Metrics 199 There is no good way for a T-API Topology service provider to 200 articulate to the client what it would cost for a potential path 201 (e.g., in terms of delay) to cross a node from interface (NodeEdge 202 point) A to interface B. Because nodes (especially composite 203 abstract nodes) may contribute to overall path costs much more than 204 links connecting the nodes along the path, this fact makes the 205 provided topology unfit for the client's path selection 206 optimizations. [Note: To be fair, the T-API Topology service does 207 allow a composite abstract node (representing a group of inter- 208 connected nodes) to refer to the topology describing the abstract 209 node's internals (node's encapTopology attribute). Hence the client 210 may in theory apply path computation algorithms on the abstract 211 node's internal/encapsulated topology to figure out whether the 212 abstract node can switch a path between a given pair of the abstract 213 node's NodeEdge points, as well as the cost penalties the path will 214 accrue by doing so. However, such a technique defeats the whole 215 purpose of creating the abstract node in the first place, which is 216 hiding multiple topological elements behind the abstract node, so 217 that the top level topology becomes smaller and easier to use in path 218 computations. In other words, if the client has to "dive" into the 219 abstract node's internal topology every time the client needs to 220 understand whether and how a path can cross the abstract node, the 221 client would be better off if the abstract node were not provided, 222 and instead, the node's internals were presented directly in the top 223 level topology.] 225 This issue does not exist in the IETF TE Topology model. A TE node's 226 Detailed Connectivity Matrix attribute (Figure 1, upper right) 227 associates with each (abstract or physical) node's connectivity 228 matrix entry a vector of costs (in terms of generic TE cost, delay, 229 intra-node SRLGs, etc.) that a potential TE path will have to add to 230 its end-to-end costs should the path select the entry to cross the 231 node. Likewise, a TE path's source/destination TTP's Detailed Local 232 Link Connectivity List attribute (Figure 2, upper right) indicates 233 what it would cost for the path to start/stop on a given first/last 234 link. [Note: In the IETF TE topology model an abstract TE node also 235 points to the encapsulated TE topology describing the node's 236 internals. However, the client is expected to peruse the node's 237 encapsulated TE topology only in exceptional situations (e.g. during 238 trouble shooting), rather than under normal conditions, such as 239 routine path computations.] 241 2.3. Topology Updates 243 Suppose that a T-API Topology service client has requested and 244 received a topology from one of its providers (for example, the 245 topology presented in Figure 3). It is imperative that as soon as 246 this done the provider starts updating the client (continuously and 247 in unsolicited way) with changes happening to the topological 248 elements and their attributes that the client has expressed interest 249 in - otherwise, the client would be forced to make decisions on stale 250 information. 252 | 253 | L2x 254 +---+ +---+ 255 |N2 | L23 L32 |N3 | L3x 256 | |--------------------| |---- 257 L21 /+---+\ L24 +---+ 258 / \ L34 / \ L36 259 / \ / \ 260 L12 / \ L42 / \ 261 L1x +---+/ L14 L41 \+---+ L43 / \ 262 ----|N1 |---------------|N4 |-------- \ 263 | |\ L15 L45 /| | \ 264 +---+ \ / +---+ \ 265 \ / \ L63 266 \ L54 / \ 267 \+---+/ L56 L65 +---+ 268 L51 |N5 |------------------------------|N6 | L5x 269 | |------------------------------| |----- 270 +---+ L156 L165 +---+ 272 Figure 3: Topology presented to T-API Topology service client 274 The only way this could be done in T-API is via using T-API 275 Notification service, specifically, the Attribute Value Change (AVC) 276 Notification service, which in a nutshell works as follows: 278 o Provider registers with the service the types of pre-defined AVC 279 events it is willing and capable of providing notifications for, 280 along with the set of pre-defined object types that may comprise 281 the notification contents; 283 o Client discovers the registered notifications it can subscribe to 284 and subscribes to some of them, specifying filters to tailor the 285 notifications to its needs. 287 There are two problems with this paradigm: 289 1. The client has a very limited way to express which notifications 290 it is interested in, as well as the contents, triggers and 291 frequency of such notifications. Note that even for the same 292 topology element type (e.g., link) different clients may need to 293 know different things, at different scopes and granularities, 294 with respect to the attribute changes. For example, one client 295 may want to hear about links that experienced changes in any 296 attribute, while another client may be interested only in links 297 with changes in specific attribute(s). One client may want to 298 learn about link attribute modifications across all provided 299 topologies, while another client may want to know only about such 300 links that belong to one or more specific (but not other) 301 topologies. One client may want to receive in the notification 302 the entire set of link attributes, while another client would 303 want to learn only about incremental changes (i.e., changes that 304 happened since the previous notification); some clients are 305 interested not in just any attribute change, but rather, want to 306 know when the attribute has reached a specific threshold, etc. 307 As mentioned, a T-API client has only the option to discover what 308 the provider is willing to offer (without the provider really 309 knowing what their clients want to learn) and to subscribe to a 310 subset of that; 312 2. In order for the client to understand/interpret the notifications 313 registered by the provider, all notification event types, as well 314 as the types of objects comprising the notification content, must 315 be explicitly pre-defined. Considering the sheer number of, say, 316 link attributes (especially, combinations of them) that different 317 clients may be interested in, and the possible scopes, 318 granularities and triggers of the notifications; explicit pre- 319 definition of notifications is awkward, limited and impractical 320 (if not infeasible). 322 In sharp contrast, the IETF TE topology model requires no explicit 323 definition of notifications. When the client subscribes to a TE 324 topology update notification it: 326 a. defines the notification event type by specifying the YANG XPath 327 from the TE topology data store root to the data store node(s) 328 associated with link attribute(s) encompassing the client's 329 points of interest; 331 b. specifies another XPath pointing to the data store's sub-tree, 332 node or group of nodes to identify the content of the 333 notification and whether the entire new state or incremental 334 changes must be provided; 336 c. defines the trigger for the notification, which could be any 337 change in the node(s) of interest or a specific increment in 338 value or the value hitting a specific threshold; 340 d. optionally defines the highest notification frequency at which 341 the client wants to receive the notifications. 343 To illustrate this assume that the IETF TE Topology model client 344 wants to be notified about all TE links whose available capacity has 345 dropped below 10G, with the notification carrying the actual link's 346 available capacity. In this case the client will: 348 a. specify root->all TE topologies -> all TE 349 links->linkAttributes->bandwidth XPath as the notification type; 351 b. specify the same XPath to define the desired notification 352 content; 354 c. define the notification trigger by specifying the low and high 355 thresholds (e.g. 10G and 15 G respectively); 357 d. optionally specify the highest frequency of updates the client is 358 capable/willing to consume. 360 Note that no explicit definitions for the notification were required. 361 After the client registers with the provider the defined 362 subscription, the latter knows exactly what the former wants to be 363 notified about and how. Similar notifications are possible to 364 register with the provider with respect to any TE topology element 365 attribute or combination of thereof. 367 2.4. Topology Telemetry Collection 369 Topology service clients (which in the T-SDN context could be various 370 controllers or applications, such as multi-domain coordinators, IP/ 371 transport integrators, orchestrators, big data collectors, analytics 372 processors, network planners, etc.) are hungry for accurate real time 373 network state information (a.k.a. network telemetry). This knowledge 374 is instrumental for a client in keeping the network under its control 375 healthy, stable and optimized under conditions of fiber cuts, 376 hardware and software failures. In particular, network telemetry 377 streams provided by the client's providers allow for the client to 378 identify/predict failing network resources and route the provided 379 transport/connectivity services away from them; to identify/predict 380 points of congestion and eliminate/mitigate the congestion by 381 deploying extra network capacity in a timely manner and so forth. 382 Network telemetry is a valuable source of information useful for 383 network planning, trouble shooting and many other things. Network 384 telemetry is especially important for topology service clients 385 because topologies represent - in an abstracted way - the physical 386 network resources. 388 [Note: At the time of writing of this memo there were no known TAPI 389 design/modeling activities related to telemetry streaming for any of 390 the T-API services]. 392 Topology telemetry collection is similar in nature to receiving 393 updates on topology attribute changes. Per the description in 394 section 1.3, T-API Notification service, State Change (SC) 395 Notification service is the only mechanism theoretically (i.e. after 396 all the necessary modeling concepts and attributes, such as 397 statistics counters, are in place) available for the client to 398 subscribe and for the provider to stream the requested network 399 telemetry. T-API SC Notification service has the same drawbacks as 400 the AVC Notification service, specifically: 402 a. limited capability for the client to articulate what telemetry 403 (event type, content, granularity, etc.) it seeks to receive; 405 b. necessity for explicit definition of the telemetry events and 406 notification messages. 408 These issues do not exist in the network telemetry streaming 409 machinery offered by the IETF Topology model. Let's consider, for 410 example, that the client wants to identify "flipping" TE links (i.e. 411 TE links frequently changing their UP/DOWN operational status) and 412 obtain in the notification the entire state information for such TE 413 links. In order to achieve this the client needs to: 415 a. specify root->all TE topologies -> all TE 416 links->linkStatistics->linkUPCounter XPath as the notification 417 type; 419 b. specify root->all TE topologies -> all TE links->linkState XPath 420 to describe the desired notification content; 422 c. define the notification trigger by specifying the number the 423 model data state node of interest (the linkUPCounter) must 424 increment by for the next notification to be issued; 426 d. optionally specify the highest frequency of notifications of this 427 type the client is capable/willing to consume. 429 2.5. Topology Name/Address Spaces 431 T-API topologies are required to have each node and link assigned a 432 globally unique UUID. This means that all T-API Topology service 433 clients and providers have to resolve potential UUID collisions via 434 allocating the UUIDs from a universal name space governed by a 435 centralized authority (in a similar way to how global IP addresses 436 are assigned in IP networks). 438 The IETF TE Topology model allows for all TE topologies to have 439 independent name spaces for the TE node, link and SRLG IDs, which not 440 only eliminates the problem of ID collisions, but also greatly 441 simplifies the design and implementation of network applications such 442 as L0/L1 VPNs. 444 In Figure 4 a TE topology provider exposes its native (i.e. real, 445 physical) TE topology as separate abstract TE topologies to two 446 clients, each one customized separately on per client basis. 447 According to the IETF TE Topology model each of the three depicted TE 448 topologies may have an independent name space for their respective TE 449 node, link and SRLG IDs. 451 +------------------------------+ +------------------------------+ 452 | Customized TE Topology | | Customized TE Topology | 453 | for Client Blue | | for Client Red | 454 | | | | 455 | +---+ +---+ | | +---+ | 456 | ---|s3'|------|S5'|--- | | ---|s3"|-------- | 457 | +---+\ +---+ | | +---+\ \ | 458 | \ | | \ \ | 459 | \ | | \ \ | 460 | \ +---+ | | \ \+---+ | 461 | --------|S8'|--- | | \ \ |S8"|--- | 462 | +---+ | | \ \ +---+ | 463 | +---+ +----+ | | \+---+ +----+ | 464 | ---|S9'|-----|S11'|--- | | ---|S9"|-----|S11"|--- | 465 | +---+ +----+ | | +---+ +----+ | 466 | C-B1->S3->S4->S5->C-B2 | | C-R1->S3->S1->S2->S5->S8 | 467 | C-B1->S3->S6->S10->S11->S7 | | ->C-R3 | 468 | ->S8->C-B3 | | C-R1->S3->S4->S5->S7->S11 | 469 | C-B1->S9->S10-S11->C-B3 | | ->C-R3 | 470 | | | C-R1->S9->S10->S11->C-R3 | 471 | | | C-R2->S9->S10->S11->C-R3 | 472 +------------------------------+ +------------------------------+ 474 +---+ +---+ 475 |S1 |-----------------|S2 | 476 +---+ +---+ 477 / \ 478 / \ 479 /----\ +---+ / +---+ \ +---+ /----\ 480 |C-B1|----|s3 |-----------------|S4 |---------|S5 |---------|C-B2| 481 \----/ /+---+\ +---+ +---+ \----/ 482 / \ \ \ 483 /----\ / \ \ \ 484 |C-R1|/ \+---+ +---+ +---+ /----\ 485 \----/ \ /|S6 |\ |S7 |---------|S8 |----|C-B3| 486 \ / +---+ \ +---+\ /+---+\ /\----/ 487 /----\ \+---+ / \ +---+ +---+ / \/ /----\ 488 |C-R2|----|S9 |-------------|S10|-----------|S11|/--------/\-|C-R3| 489 \----/ +---+ +---+ +---+ \----/ 491 Figure 4: Abstract TE topologies customized for different clients 493 2.6. Topology Relationships 495 An IETF TE Topology model provider may expose to the same client 496 multiple TE topologies, which: 498 o could be native (as known to the provider, unmodified) or abstract 499 (generated by the provider as overlays based on native or lower 500 level abstract TE topologies); 502 o could describe different layer networks in accordance with 503 distinct layer-specific model augmentations; 505 o abstract TE topologies could be of a different type (e.g. single 506 node, link mesh, etc.) and of a different hierarchy level; 508 o abstract TE topologies could be optimized based on different 509 optimization criteria (e.g. smallest cost, shortest delay, best 510 link protection, etc.) 512 The provider can convey to the client the TE topology optimization 513 criteria, as well as the provider's preference as to the order in 514 which the provided TE topologies are to be used via topology scope 515 attributes specifically designed for this purpose. Furthermore, the 516 TE Topology model defines various inter-topology relationships 517 designed to describe abstract TE topology hierarchies, client-server 518 layer network (vertical) relationships and domain neighboring 519 (horizontal) relationships. The defined inter-topology relationships 520 are as follows: 522 o TE node underlay topology: A composite abstract TE node of a 523 higher hierarchy level TE topology X, representing a group of 524 inter-connected TE nodes that belong to a lower hierarchy level TE 525 topology Y, has an attribute pointing to Y (i.e., ID of the 526 abstract TE node's internal/encapsulated TE topology); 528 o TE link underlay topology: A TE link of a TE topology X can point 529 to TE Topology Y which was used by the provider to compute primary 530 and backup TE paths that are (or are to be) used by the actual or 531 potential TE tunnel (transport connectivity) supporting the TE 532 link in question. The TE paths themselves could be provided in 533 the same TE link attribute; 535 o Supporting node/link topology: A given TE node or link may show up 536 in multiple TE topologies catered by the provider to the client. 537 In order for the provider not to provide/update (and for the 538 client not to consume) multiple identical sets of attributes, the 539 model allows for providing/updating only for one (original) TE 540 node/link, and having the "twins" point to the original TE mode/ 541 link, as well as to the TE topology where the original TE node/ 542 link could be found; 544 o Source node/link topology: A given TE node or link catered by the 545 provider as a part of a TE topology to the client may be provided 546 to the provider by one of its own providers. In such case the TE 547 node/link in question can point to the original TE node/link, as 548 well as to the TE topology where the original is defined, thus 549 allowing for multi-level multi-provider TE topology hierarchies 550 (see Figure 5); 552 o Inter-layer lock: This is the relationship/attribute that 553 associates TE links of a higher layer network TE topology with TE 554 Tunnel Termination Points (TTPs) of one or more lower layer 555 network TE topology(ies) to articulate to the client inter- 556 topology /inter-layer adaptation capabilities, to lock the TE 557 topologies describing separate layer networks vertically, thus 558 allowing for client multi-layer path computations and other multi- 559 layer TE applications; 561 o Inter-domain plug: This is a relationship modeled via an inter- 562 domain TE link attribute that allows for a client managing 563 interconnected multi-domain networks (with each domain served by a 564 separate provider) to identify neighboring domains and to lock the 565 TE topologies provided by all providers horizontally, thus 566 producing TE topologies homogeneously describing the entire multi- 567 domain network and allowing for end-to-end path computations 568 across the network. 570 +-------------------------------------------------------------------+ 571 | Domain higher +---+ +---+ | 572 | level abstract --| B |-------------| C |-- | 573 | TE topology / +---+ +---+ \ | 574 | (Blue) +---+/ \+---+ | 575 | | A | | D | | 576 | +---+\ /+---+ | 577 | \ +---+ +---+ / TE link E-F is | 578 | --| E |-------------| F |-- catered to by | 579 | .+---+ +---+. M-P-Q-N-F' in Red | 580 +--------------------.-------------------------.--------------------+ 581 . . 582 +------------------.-----------------------------.------------------+ 583 | Domain +---+ +---+ +---+ +---+ | 584 | lower level | E'|----| M |-------------| N |----| F'| | 585 | abstract TE +---+@@@@+---+ +---+@@@@+---+ | 586 | topology | @ | | @ | TE link P-Q | 587 | (Red) | @@@|@@@@@@@@@@@@@@@@@|@@@ | is catered | 588 | +---+ +---+ +---+ +---+ to P'-X-Q' | 589 | | O |----| P |-------------| Q |----| R | in Black | 590 | +---+ +---+ +---+ +---+ | 591 +------------------------.-----------------.------------------------+ 592 . . 593 +------------------------.-----------------.------------------------+ 594 | Domain native +---+@@ @@+---+ | 595 | TE topology | P'|--@ @--| Q'| | 596 | (Black) +---+ \@@@@@@@/ +---+ | 597 | +---+ \+---+/ +---+ | 598 | | V |-------------| X |-------------| Z | | 599 | +---+ /+---+\ +---+ | 600 | +---+ / \ +---+ | 601 | | W |-- --| Y | | 602 | +---+ +---+ | 603 +-------------------------------------------------------------------+ 605 Figure 5: Hierarchical multi-provider abstract TE topologies 607 A T-API Topology service provider is also allowed to expose multiple 608 topologies to the client. The only inter-topology relationship 609 defined is the Node's encapTopology (which is effectively the same as 610 the IETF's TE node underlay topology relationship described above). 611 Otherwise, all the provided topologies are independent. It is not 612 clear for the client what is the purpose of each of them, what is the 613 provider's preference as to how and in which order they are supposed 614 to be used, and why several same layer topologies, rather than one, 615 were provided to the client in the first place. 617 2.7. Topology Attributes 619 Compared to the IETF TE Topology model, T-API Topology nodes and 620 links are missing some important attributes. Specifically, T-API 621 nodes, as mentioned in section 1.1, have no analogs to the 622 Connectivity matrix attribute and the TE TTP container describing 623 nodes switching and termination capabilities/limitations 624 respectively. Furthermore, the T-API Topology service does not have 625 a concept of TTP, which in the context of the IETF TE Topology model 626 conveys to the client various important edge characteristics for a TE 627 tunnel that could be provided by the network described by a given TE 628 topology. Such characteristics include: 630 o Potential TE tunnel protection capabilities (e.g., whether 1+1 631 protection could or could not be supported for the tunnel edge); 633 o Adaptation capacities (i.e., which higher layer network payload 634 types and from which higher layer link termination points can be 635 adopted on the TE tunnel edge, the amount of adaptation bandwidth 636 still available, etc.); 638 o Technology-specific TTPs describe technology specific properties 639 (e.g. TTP representing an OCh layer transponder can announce 640 whether the transponder's receiver/transmitter is fixed or 641 tunable, and in the latter case what is the range and resolution 642 of the tunability; supported FECs and signal modulation modes, 643 transmit/acceptable optical signal power levels and OSNRs, etc.) 645 The T-API Topology link is missing the following attributes: 647 o Administrative groups (administrative colors) - an attribute 648 describing the link's association with pre-defined groups of 649 links; such groups could be used as constraints in the client's 650 path selection/optimization algorithms to mandate/disallow or 651 encourage/discourage the resulting paths to follow/avoid links 652 related to the specified groups; 654 o Link protection/restoration capability - an attribute that could 655 be also used as a path computation constraint or path optimization 656 criterion, for example, to force or encourage the resulting paths 657 to follow sufficiently protected links; 659 o Link properties defining whether the link is: 661 A. actual (with committed network resources) or potential; 663 B. static (with pre-established and always-in-place server layer 664 connectivity supporting the link) or dynamic (for which the 665 connectivity is dynamically put in place if/when the link is 666 used by at least one client connection and is dynamically 667 released as soon as the link is used by none of the client's 668 connections); 670 o Link's underlay primary and backup paths and ID of the topology 671 used for their computations. 673 2.8. Topology Service Relationships with Other Services 675 IETF TE topology and TE tunnel models are related. For example, a TE 676 link can point via the Supporting Tunnel ID attribute to the lower 677 layer network TE tunnel providing the transport connectivity for the 678 TE link. Likewise, a TE tunnel has an attribute pointing to the TE 679 link it supports, as well as the TE topology which the TE link is 680 part of. These cross-references are instrumental for the client in 681 terms of understanding which network resources a given TE link 682 represents, especially useful at the times of trouble shooting. 683 Additionally, IETF TE tunnel defines and supports the concept of 684 Hierarchical TE links and tunnels. Hierarchical TE tunnels 685 automatically insert dynamic hierarchical TE links into the specified 686 TE topologies as soon as the tunnels are successfully set up (and 687 remove the hierarchical TE links from the respective TE topologies 688 when released). [Note: Hierarchical TE tunnels and links are 689 instrumental in multi-layer traffic engineering]. 691 Furthermore, both TE topology and TE tunnel models are tightly 692 coupled with the IETF YANG based notification machinery, which allows 693 the client to retrieve any telemetry or attribute change updates as 694 long as those telemetry/attribute changes are defined as data state 695 nodes or sub-trees in the respective models. 697 In contrast, all T-API services (i.e. Topology, Connectivity, Path 698 computation, Virtual Network and Notification) are independent from 699 each other. 701 2.9. Topology Negotiation and (Re-)configuration 703 When a client of the IETF TE Topology model/interface receives one or 704 more abstract TE topologies from one of its providers, it may accept 705 the topologies as-is and merge then into one or more of its own 706 native TE topologies. Alternatively, the client may choose to 707 request a re-configuration of one, some or all abstract TE topologies 708 provided by the providers. Specifically, with respect to a given 709 abstract TE topology, some of its TE nodes/links may be requested to 710 be removed, while additional ones may be requested to be added. It 711 is also possible that existing TE nodes/links may be asked to be re- 712 configured (e.g., TE links may be requested to be SRLG disjoint). 714 Furthermore, the topology-wide optimization criteria may be requested 715 to be changed. For example, underlay TE paths supporting the 716 abstract TE links, currently optimized to be shortest (least-cost) 717 paths, may be requested to be re-optimized based on the minimal delay 718 criteria. Additionally, the client may request the providers to 719 configure entirely new abstract TE topologies and/or to remove 720 existing ones. Furthermore, future periodic or one-time additions, 721 removals and/or re-configurations of abstract TE topologies, 722 topological elements and/or their attributes could be (re-)scheduled 723 by the client ahead of time. 725 It is the responsibility of the client to implement the logic behind 726 the above-described abstract TE topology negotiation. It is expected 727 that the logic is influenced by the client's local configuration/ 728 templates, policies conveyed by the client's clients, input from the 729 network planning process, telemetry processor, analytics systems and/ 730 or direct human operator commands. Figure 6 exemplifies the abstract 731 TE topology negotiation process. As shown in the Figure, the 732 original abstract TE topology exposed by a provider was requested to 733 be re-configured. Specifically, one of the abstract TE links was 734 asked to be removed, while three new ones were asked to be added to 735 the abstract TE topology. 737 The ONF T-API Topology service client has no say as to how the 738 abstract topologies exposed to the client by its providers should 739 look like. The only option for the client is to consume the provided 740 topologies as offered. This is a serious disadvantage because it is 741 the client (not providers) that knows which topologies suite best the 742 client's needs. 744 Client 746 /\ || 747 || || 748 Original abstract TE || || Abstract TE topology 749 topology by Provider || || re-configured by Client 750 || || 751 +---+ +---+ || || +---+ +---+ 752 ---|s3 |------|S5 |--- || || ---|s3 |------|S5 |--- 753 +---+\ +---+ || || +---+\ \ /+---+ 754 \ || || | \ \/ \ 755 \ || || | \/\ \ 756 \ +---+ || || | /\ \ \+---+ 757 --------|S8 |--- || || \ | / \ ------|S8 |--- 758 +---+ || || \ | / \ +---+ 759 +---+ +---+ || || \+---+ +---+ 760 ---|S9 |------|S7 |--- || || ---|S9 |------|S7 |--- 761 +---+ +---+ || || +---+ +---+ 762 || \/ 764 Provider 766 Figure 6: Provider-Client abstract TE topology negotiation 768 2.10. Integration with IP/MPLS 770 The IETF TE Topology model is naturally and intimately integrated 771 with IP/MPLS layer models defined for IP/MPLS layer traffic 772 engineering. For example, currently Segment Routing (SR) and Service 773 Function Chaining (SFC) technologies heavily rely on and actively use 774 the TE Topology model. Specifically, SR combines the TE topology 775 model with layer 3 (IP reachability) topology model to facilitate 776 path computations that account for either or both TE and IP 777 reachability information. Likewise, SFC makes use of the TE topology 778 model for computing service function chains optimized according to 779 the combined criteria of real/virtual network function location and 780 best available (possibly in different layers) TE paths to connect the 781 network functions. 783 It is not clear how the ONF T-API Topology service can fit in and to 784 what extent it can be integrated into the IP/MPLS layer traffic 785 engineering. 787 3. Connectivity Service 788 3.1. Connectivity Service Protection 790 It is not possible for a T-API Connectivity service client to request 791 from a provider a protected service like, for example, the one 792 presented in Figure 7. In the Figure a connectivity service is 793 supported by two disjoint connections - primary (solid blue) and 794 backup (broken yellow), with the client traffic normally carried over 795 the primary connection, but which could be quickly and dynamically 796 switched onto the backup connection as soon as a network failure 797 affecting the primary connection is detected. 799 The inability to request protected connectivity services from a 800 provider leaves the T-API Connectivity service client with the 801 problem of protecting its own traffic against the network's failures. 802 Admittedly, the client can address this with the following sequence 803 of operations: 805 1. The client requests a primary connectivity service connecting the 806 desired pair of client device ports over the network managed by 807 the T-API Connectivity service provider; 809 2. The client requests a secondary connectivity service connecting 810 the same pair of client device ports, which is sufficiently 811 diverse from the primary service (incidentally, this could be 812 problematic due to the independent nature of the path 813 computations carried out by the provider. Specifically, the path 814 selected for the primary service may block disjoint paths for the 815 secondary service. This is a known issue related to sequential/ 816 independent path computations, which could be solved via 817 concurrent path computation for both services); 819 3. The client binds at both ends the two connectivity services in 820 accordance with the desired protection scheme; 822 4. From then on the client is constantly monitoring the performance 823 and health of both services; 825 5. In case the primary service is affected by a network failure 826 (while the secondary service remaining healthy), the client 827 coordinates the protection switchover; 829 6. In case it is detected that the previously broken primary 830 connectivity service is repaired, the client coordinates the 831 protection reversion (i.e. reversion to the normal forwarding of 832 the client traffic). 834 Customer Customer 835 domain 1 domain 3 836 +----------------------------+ +---------------------+ 837 |Network +---+$$$$$$$$+---+ | |Network | 838 |domain 1 |S1 |--------|S2 |\| |domain 3 | 839 | $+---+ +---+$\ | | 840 | $/ | $\| | 841 | $$/ | |$\ | 842 /----\ | +---+/ +---+ | | $\ +---+ | /----\ 843 |C-R1|-+-|S3 |----------|S4 | | | |$\-------|S36|-------+-|C-R7| 844 \----/ | +---+\ +---+ | | | $$$$$$$ +---+ | \----/ 845 | $\ \ | | | / $\ | 846 /----\ | $\ \ | | | / $\ | 847 |C-R2| | $+---+ \ | | | +---+/ $+---+ | /----\ 848 \----/\| $|S6 | \ | | --|S37| |S38|-+-|C-R8| 849 \ $$/+---+\ \| |/| +---+\ /+---+ | \----/ 850 /----\ |\+---+/@@@@@@ \+---+ +---+ / | | \+---+/$ | 851 |C-R3|-+-|S9 |-------@-|S10|--|S11|/| | | |S39|$ | 852 \----/ | +---+ @+---+ +---+ | | | +---+ | 853 +-------------@/------------\+ +---|------|$---------+ 854 @/ \ | |$ 855 +-----------@/----------------\----|------|$-------+ 856 |Network +---+ \+---+ |$ | 857 |domain 2 |S21|-----------------|S22| |$ | Customer 858 | +---+ +---+ |$ | domain 2 859 | @/ \ |$ | 860 | @/ \ |$ | 861 | +---+@/ +---+ \ +---+ | /----\ 862 | |s23|-----------------|S24|---------|S25|-------+-|C-R4| 863 | +---+\@ @/+---+ +---+ | \----/ 864 | \@ @/ \@ \$ | 865 | \@ @/ \@ \$ | 866 | \+---+@@@@/ +---+ +---+ | /----\ 867 | /|S26|---- |S27|--------@|S28|-+--|C-R5| 868 | / +---+ \ +---+\@ @/+---+ | \----/ 869 | +---+ / \ +---+ +---+@/ | /----\ 870 | |S29|-------------|S30|-----------|S31|/--------+--|C-R6| 871 | +---+ +---+ +---+ | \----/ 872 +--------------------------------------------------+ 874 Figure 7: Protected connectivity service 876 In contrast, an IETF TE tunnel model client normally delegates all 877 the described above operations to the provider by simply configuring 878 the requested transport service (i.e. TE tunnel or a single-domain 879 segment of a multi-domain TE tunnel) to be protected. In doing so 880 the client specifies the required protection type, as well as the 881 level of primary/backup connections disjointedness. Additionally, 882 the client may specify a set of constraints common for both 883 connections, as well as constraints (e.g. inclusions, exclusions, 884 etc) specific to each connection. Furthermore, the client may even 885 specify, for a given transport service, multiple sets of such 886 constraints in descending preference order for the provider to try 887 before notifying the client about the setup failure. For example, 888 the client may request in this way for a TE tunnel that the primary 889 and backup connections must be SRLG disjoint, and, if this proves to 890 be not possible, to relax the disjointedness criterion to link- 891 disjoint. 893 3.2. Hierarchical Connectivity Service 895 A transport network provider may control a multi-layer (e.g. 896 Ethernet/ODUk/OCh) network. On such a network the provider has 897 flexibility to dynamically set up connectivity/transport services in 898 one or more lower layer networks to augment a higher layer topology 899 that is otherwise insufficient for provisioning of a connectivity 900 service requested by the client. 902 In the top-to-bottom approach the client simply requests a 903 connectivity service in the desired layer network. While processing 904 the request, the provider: 906 o performs its internal multi-layer path computation, 908 o identifies one or more lower layer connectivity services required 909 for the successful provisioning of the requested service; 911 o dynamically (and unknowingly to the client) sets up the so- 912 identified lower layer connections; 914 o sets up the connection(s) supporting the connectivity service 915 requested by the client. 917 Both T-API Connectivity service and IETF TE Topology model/interface 918 support the described top-to-bottom multi-layer connectivity 919 services. The approach is simple for the client; however it does not 920 work in many multi-domain use cases. Consider, for example, a multi- 921 domain transport network presented in Figure 8. Consider further 922 that a Multi-Domain Service Coordinator is requested to set up 923 Ethernet layer connectivity service (marked in blue) across three 924 domains, each of which is controlled by a separate provider. Assume 925 also that in order to satisfy the request an underlay ODUk layer TE 926 tunnel (marked as red) also spanning multiple domains needs to be 927 provisioned. This could be achieved via a bottom-to-top multi-layer 928 connectivity service provisioning approach, which includes the 929 following: 931 o the client (i.e. the Multi-Domain Coordinator) performs its own 932 multi-layer path computation on a network wide TE topology (a 933 product of merging the TE topologies exposed by all providers); 935 o the client identifies one or more lower layer TE tunnels required 936 for the successful provisioning of the requested service; 938 o the client coordinates the multi-domain setup of each of the 939 identified lower layer TE tunnels; 941 o the client instructs each lower layer TE tunnel's first and last 942 domain provider to add a dynamic TE link in their respective 943 higher layer TE topologies; 945 o the client triggers and coordinates the setup of the connection(s) 946 supporting the requested connectivity service, constraining the 947 connection path(s) to follow the dynamic TE links supported by the 948 lower layer TE tunnels; 950 o the client adds into its own (network-wide) TE topology, dynamic 951 TE links supported by the lower layer TE tunnels to make the 952 remaining capacity on the tunnels available for path computations 953 for other higher layer connectivity services. 955 Customer Customer 956 domain 1 domain 3 957 +----------------------------+ +---------------------+ 958 |Network +---+ +---+ | |Network | 959 |domain 1 |S1 |--------|S2 |\| |domain 3 | 960 | +---+ +---+ \ | | 961 | / | |\| | 962 | / | | \ | 963 /----\ | +---+/ +---+ | | |\ +---+ | /----\ 964 |C-R1|-+-|S3 |----------|S4 | | | | \-------|S36|-------+-|C-R7| 965 \----/ | +---+\ +---+ | | | +---+ | \----/ 966 | \ \ | | | / \ | 967 /----\ | \ \ | | | / \ | 968 |C-R2|b| +---+ \ | | b +---+/ +---+ | /----\ 969 \----/\b |S6 | \ | |b--|S37| |S38|-+-|C-R8| 970 \b /+---+\ \| b/r +---+\bb /+---+ | \----/ 971 /----\ |\+---+/ bbbbb \+---+bb+---+ /r| | rr\+---+/ | 972 |C-R3|-+-|S9 |---------|S10|--|S11|/r | | |S39| | 973 \----/ | +---+ rrrrrrr +---+rr+---+ | | | +---+ | 974 +--------------/------------\+ +---|-----r|b---------+ 975 / \ | r|b 976 +------------/----------------\----|-----r|b-------+ 977 |Network +---+ \+---+ r|b | 978 |domain 2 |S21|-----------------|S22| r|b | Customer 979 | +---+ +---+ r|b | domain 2 980 | / \ r|b | 981 | / \ r|b | 982 | +---+ / +---+ \ +---+ | /----\ 983 | |s23|-----------------|S24|---------|S25|-------+-|C-R4| 984 | +---+\ /+---+ +---+ | \----/ 985 | \ / \ r\b | 986 | \ / \ r\b | 987 | \+---+ / +---+ r+---+bbbb/----\ 988 | /|S26|---- |S27|---------|S28|-+--|C-R5| 989 | / +---+ \ +---+\ /+---+ | \----/ 990 | +---+ / \ +---+ +---+ / | /----\ 991 | |S29|-------------|S30|-----------|S31|/--------+--|C-R6| 992 | +---+ +---+ +---+ | \----/ 993 +--------------------------------------------------+ 995 Figure 8: Hierarchical connectivity service 997 The IETF TE topology model supports the described bottom-to-top 998 multi-layer connectivity service provisioning paradigm via Hierarchy 999 TE tunnels. A hierarchy TE tunnel, once successfully set up, 1000 automatically adds into the specified TE topology a TE link it 1001 supports and withdraws the TE link from the TE topology if/when 1002 released. 1004 T-API Connectivity and Topology services do not support the concept 1005 of hierarchical connectivity/dynamic links. 1007 3.3. Connectivity Service Re-optimization 1009 An IETF TE tunnel model/interface client, when requesting a transport 1010 service from a provider, can control - via a designed for this 1011 purpose knob (lockDown attribute) - whether the connection(s) 1012 supporting the service must be "pinned" to their respective original 1013 paths (the paths selected at the setup stage), or whether the 1014 provider may occasionally perform a service re-optimization, 1015 resulting in service connection replacement toward more optimal 1016 paths. This knob is especially useful in conjunction with a 1017 connectivity scheduling service (see section 2.6), allowing for the 1018 client to specify time intervals at which the re-optimization of a 1019 given transport service (and subsequent potential traffic hits) is 1020 acceptable for the client. For example, the client may configure a 1021 transport service to get "unpinned" every Saturday at 1 am for 1022 service re-optimization procedures and to get "re-pinned" after that 1023 for another week. 1025 T-API Connectivity service clients have no way of controlling of 1026 connectivity service re-optimization operations. 1028 3.4. Connectivity Service Templates 1030 The IETF TE tunnel model defines containers of named transport 1031 service configuration sets that could be shared by multiple services. 1032 This not only simplifies for the client the process of transport 1033 service configuration, but also allows manipulation of multiple 1034 services by a single configuration change. For example, a client may 1035 define a set of constraints named Foo that forces a transport service 1036 primary path to go through a node X. If, later, the client modifies 1037 Foo by substituting node X with node Y, all transport services 1038 configured with the constraint set Foo will (be attempted to) be re- 1039 placed onto path(s) going through node Y. 1041 The T-API Connectivity service model does not have a similar concept. 1043 3.5. Connectivity Service Attribute Change Update Notifications and 1044 Telemetry Streaming 1046 Both T-API and IETF modeling rely on respective notification tools 1047 universal across all interfaces. Therefore, connectivity service 1048 attribute change notifications and telemetry streaming is no 1049 different from the topology notifications and telemetry streaming 1050 discussed in sections 2.3 and 2.4 1052 3.6. Connectivity Scheduling 1054 T-API Connectivity service has the _schedule attribute that includes 1055 just two parameters: startTime and endTime. This allows for a client 1056 to schedule at a specified time and for a specified period of time a 1057 one-time kickoff of a service configured initially (presumably) as 1058 disabled. It is not possible to schedule multi-time (periodic) 1059 kickoffs. Furthermore, the scheduling granularity is connectivity 1060 service as a whole. In particular, it is not possible to schedule 1061 re-configurations of one or several service parameters (e.g. 1062 bandwidth requirement, inclusion/exclusion path, etc.). 1064 There is an ongoing effort in IETF to produce a generic scheduling 1065 tool that could be applied to any of YANG models. Similar to the 1066 notification subscription tool - allowing for the client to subscribe 1067 on notifications with respect to any data state (CONFIG=FALSE) node 1068 defined in any supported by the provider data store - the scheduling 1069 tool will allow for the client to schedule periodic and/or one-time 1070 modification of any configuration (CONFIG=TRUE) leaf of any supported 1071 data store. For example, if it is required to schedule a re- 1072 configuration of the bandwidth requirement for one or more selected 1073 services, the client will specify an XPath pointing to the configured 1074 bandwidth attribute of the services of interest and convey the new 1075 bandwidth requirement and the timetable for the service bandwidth re- 1076 configuration. [Note: At time intervals outside of the scheduled 1077 range, the service configured bandwidth will remain/be restored to 1078 the value provided during initial service configuration.] 1080 3.7. Potential Connectivity Service 1082 The IETF TE topology model defines a number of "unconventional" 1083 configuration modes to be specified by a client and supported by a 1084 provider of transport services. One of those modes is the 1085 COMPUTE_ONLY mode. When a provider processes a request for a 1086 transport service configured in the COMPUTE_ONLY mode, it performs 1087 the normal path computation for the service, but does not trigger 1088 setup of the connection(s) supporting the service. Instead, the 1089 computed paths are returned to the client as a part of normal service 1090 attribute change notification. Furthermore, when the provider 1091 detects a change in the managed network potentially affecting the 1092 returned paths, it may re-evaluate the paths and notify the client if 1093 they have become infeasible or more optimal paths are available. 1095 The concept of COMPUTE_ONLY transport services makes a good 1096 foundation for Path computation service/interface between the Client 1097 and the Provider (see more in section 4). 1099 4. Path Computation Service 1101 A client of a transport network can discover the network resources 1102 available for the client in one of the two ways: 1104 o by requesting from the network provider , via a topology 1105 interface, one or more topologies describing the network with 1106 respect to its availability to the client; 1108 or 1110 o by requesting, via a path computation interface, that the provider 1111 identify potential paths that could connect various client device 1112 ports across the network. 1114 To support the latter option, ONF T-API has introduced a Path 1115 computation service dedicated to the purpose. A T-API Path 1116 computation service client can issue a path computation request 1117 specifying the identities of the required path source and destination 1118 end points, the layer network in which the paths are to be 1119 determined, the required mutual diversity of the resulting paths, 1120 various path computation constraints (e.g., bandwidth requirements, 1121 inclusions, exclusions, etc.) and path selection optimization 1122 criteria (e.g., smallest cost, shortest delay, etc.). A T-API Path 1123 computation service provider is expected to satisfy the request by 1124 running a path computation algorithm and responding to the client 1125 with zero, one or more resulting paths. 1127 In contrast, IETF modeling does not offer a dedicated mechanism/model 1128 to support the Client<=>Provider path computation interface. 1129 Instead, it is suggested to use the YANG TE tunnel model and request 1130 and manipulate path computations in the form of COMPUTE_ONLY TE 1131 tunnels as described in section 2.7. This approach has some 1132 important advantages as compared to the T-API Path computation 1133 service: 1135 Simplicity: provided that both the client and the provider know how 1136 to request, manipulate and support transport services, there is no 1137 additional interface/model for the client to learn how to use and 1138 functionality for the provider to support; 1140 Accuracy: T-API Path computation and Connectivity services are not 1141 related. It cannot be guaranteed that the set of path computation 1142 constraints conveyed by a T-API Path computation service client 1143 will match the set of path computation constraints internally 1144 generated by a T-API Connectivity service provider even when the 1145 configuration parameters - source/destination, layer network, 1146 bandwidth and others - match. There are many reasons for that, 1147 including: 1149 A. additional constraints could be imposed by the provider based 1150 on some internal and possibly proprietary knowledge about the 1151 network (unknown to the client); 1153 B. various internal policies could relax, harden or overwrite 1154 other constraints; 1156 C. various internal policies could modify or overwrite the 1157 requested optimization criteria; 1159 D. etc. 1161 Furthermore, the provider may even use different path computation 1162 engines to provide the Path computation and connectivity services. 1163 All this may result in the paths returned to the Path computation 1164 service client being different from the paths taken by the 1165 corresponding (same source/destination and other constraints) 1166 connectivity services. The difference may be in path costs, delay 1167 and fate sharing characteristics, etc. In extreme cases the Path 1168 computation service client may even receive unprovisionable and 1169 hence useless paths. 1171 IETF COMPUTE_ONLY TE tunnels, on the other hand, do not have such 1172 problems. It is inherently guaranteed that the client will be 1173 notified/updated with paths which are exactly the same as the ones 1174 that would be taken by connections of "conventional" TE tunnels 1175 for the same configuration inputs; 1177 Path staleness: paths returned to the T-API Path computation service 1178 client may become unfeasible at some later time because of changes 1179 in the network's state. There is no way for the Path computation 1180 service provider to convey this fact to the client. In contrast, 1181 IETF COMPUTE_ONLY TE tunnel provider can use the intrinsic 1182 attribute change notifications to let the client know that 1183 previously provided paths have changed, have become unfeasible or 1184 that better, more optimal paths have become available. 1186 5. Virtual Network Service 1188 A client of a transport network may want to limit the transport 1189 network connectivity of a particular type and quality to defined 1190 subsets of its device ports interconnected across the network. 1191 Furthermore, a given transport network may serve more than one 1192 client. In this case some or all clients may want to ensure the 1193 availability of transport network resources in case dynamic 1194 (re-)connection of their device ports across the network is 1195 envisioned. In all such cases a client may want to set up one or 1196 more Virtual Networks over the provided transport network. 1198 ONF T-API has introduced a dedicated service for this purpose - the 1199 Virtual Network service (VNS). A VNS client can request creation of 1200 a VNS specifying the layer network of the VNS and the Traffic Matrix 1201 requirement. The client has no control over the requested VN beyond 1202 that. In particular, it is up to the provider to decide which 1203 network resources will support the VN in question. The client has no 1204 say as to how the underlying network topology should look, how the 1205 topology needs to be optimized for the VN (e.g. shortest delay rather 1206 than smallest cost), what is the required level of the topology link 1207 protection and mutual diversity, and so forth. 1209 As in case of the path computation interface, IETF modeling does not 1210 offer a separate model to support VNS. Instead, it encourages using 1211 the TE topology model - leveraging the IETF abstract TE topology's 1212 ability to be configured by the client. In a nutshell, the client 1213 configures and manipulates a VN as a customized abstract TE topology 1214 based on the TE topologies already exposed by the provider. In the 1215 simplest case the client requests a single node ("black box") 1216 abstract TE topology with desired attributes. In more complex cases 1217 the client may opt to construct, for the VN, a separate multi-node/ 1218 link arbitrary abstract TE topology. In doing so, the client may 1219 "borrow" into the VN's topology TE nodes and links from other 1220 topologies. Additionally the client may add new composite abstract 1221 TE nodes specifying the IDs of TE topologies the nodes will 1222 encapsulate, connected by abstract TE links pointing to the 1223 respective underlay TE topologies to be used for computation and 1224 provisioning of the TE tunnels supporting them. The client/provider 1225 negotiation of a"so-cooked" TE topology is described in 1.9. In 1226 short, the client is able to manipulate the VN's topology at the 1227 granularity of individual topological elements (such as TE nodes and 1228 links). 1230 6. Data Modeling Language 1232 Today YANG is a very popular data modeling language. It is a product 1233 of IETF NETMOD WG. It is not the only data modeling language 1234 produced by IETF (for example, FORCES WG has developed one of its 1235 own, arguably - in some aspects - superior to YANG). YANG is neither 1236 stable nor perfect. It is constantly evolving with the sole 1237 objective to make IETF models more scalable, efficient, inclusive, 1238 information-rich: better in all aspects. Supporting non-IETF (e.g. 1239 ONF) data models is not a priority. Therefore It is not clear why 1240 ONF, while investing a lot of effort in designing Core Information 1241 Models, is devoting no effort to designing a data modeling language 1242 of its own that would closely suit support of its CIM. Nor it is 1243 clear what would happen if the IETF NETMOD WG decides, for whatever 1244 reason to obsolete some of the YANG features/properties/capabilities 1245 that ONF models rely upon. 1247 Furthermore, writing CIMs in UML and having them mechanically 1248 translated into YANG has its own issues, which includes the 1249 following: 1251 o Many useful YANG features that do not have analogs in UML are not 1252 used. For example, T-API YANG models use only non-extendible 1253 enumeration type, rather than extendible identity type. This 1254 prevents T-API YANG models from being easily extendible via 1255 augmentation; 1257 o T-API YANG models heavily overuse and often misuse YANG RPCs for 1258 operations that could be handled simpler and more efficiently by 1259 NETCONF/RESTCONF protocol via native edit-config and get 1260 operations; 1262 o T-API YANG models unnecessarily define their own notification 1263 subscription/streaming and scheduling mechanisms, instead of 1264 leveraging the NETCONF/RESTCONF machinery easily applicable to all 1265 YANG models; 1267 o T-API YANG models make no use of YANG templates and defaults 1268 designed to simplify for the client the provider's data store 1269 (re-)configuration; 1271 o T-API YANG models follow the conventions inherited from UML and 1272 previously defined REST APIs. As a consequence. the models 1273 sometimes are not compatible with the current best practices 1274 recommended for YANG model writers and do not always follow YANG 1275 model guidelines defined in [I-D.ietf-netmod-rfc6087bis] 1277 7. Security Framework 1279 ONF T-API does not have a security framework of its own. It simply 1280 assumes that the proper security could be inherently provided by the 1281 underlying protocols. IETF TEAS interfaces, on the other hand, take 1282 the security considerations very seriously. They rely on the generic 1283 framework ([RFC6241], [RFC8040], [RFC6536], and 1284 [I-D.ietf-netconf-rfc6536bis]) allowing for the provider to configure 1285 in a universal way various strength AAA protection for any YANG 1286 modeled data store accessible via NETCONF or RESTCONF protocol. In 1287 particular, said framework allows for the client authentication, 1288 identification of the client's privileges with respect to the 1289 information access, required filtering and scoping of the provided 1290 information, as well as secure client-provider communication. 1292 8. IANA Considerations 1294 This document has no actions for IANA. 1296 9. Security Considerations 1298 This document does not define networking protocols and data, hence 1299 are not directly responsible for security risks. 1301 This document compares two interface technologies of T-SDN 1302 controllers. For each specific technology discussed in the document, 1303 security framework has been described and compared in the 1304 corresponding section. 1306 10. Acknowledgements 1308 The authors would like to thank Christopher Jenz, Diego Caviglia, 1309 Aihua Guo, Fatai Zhang, and Italo Busi for their helpful comments and 1310 valuable contributions. 1312 11. References 1314 11.1. Normative References 1316 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1317 and A. Bierman, Ed., "Network Configuration Protocol 1318 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1319 . 1321 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1322 Protocol (NETCONF) Access Control Model", RFC 6536, 1323 DOI 10.17487/RFC6536, March 2012, 1324 . 1326 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1327 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1328 . 1330 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1331 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1332 . 1334 [I-D.ietf-teas-yang-te-topo] 1335 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1336 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 1337 teas-yang-te-topo-06 (work in progress), October 2016. 1339 [I-D.ietf-teas-yang-te] 1340 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., 1341 Bryskin, I., Chen, X., Jones, R., and B. Wen, "A YANG Data 1342 Model for Traffic Engineering Tunnels and Interfaces", 1343 draft-ietf-teas-yang-te-05 (work in progress), October 1344 2016. 1346 [I-D.ietf-netconf-rfc6536bis] 1347 Bierman, A. and M. Bjorklund, "Network Configuration 1348 Protocol (NETCONF) Access Control Model", draft-ietf- 1349 netconf-rfc6536bis-01 (work in progress), March 2017. 1351 11.2. Informative References 1353 [I-D.ietf-netmod-rfc6087bis] 1354 Bierman, A., "Guidelines for Authors and Reviewers of YANG 1355 Data Model Documents", draft-ietf-netmod-rfc6087bis-12 1356 (work in progress), March 2017. 1358 Authors' Addresses 1360 Igor Bryskin 1361 Huawei Technologies 1363 EMail: Igor.Bryskin@huawei.com 1365 Xufeng Liu 1366 Jabil 1368 EMail: Xufeng_Liu@jabil.com 1370 Vishnu Pavan Beeram 1371 Juniper Networks 1373 EMail: vbeeram@juniper.net 1375 Tarek Saad 1376 Cisco Systems Inc 1378 EMail: tsaad@cisco.com