idnits 2.17.1 draft-voit-netmod-peer-mount-requirements-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 14, 2015) is 3147 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 943 -- Looks like a reference, but probably isn't: '2' on line 945 -- Looks like a reference, but probably isn't: '3' on line 947 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETCONF Data Modeling Language Working Group (netmod) E. Voit 2 Internet-Draft A. Clemm 3 Intended status: Informational Cisco Systems 4 Expires: March 17, 2016 S. Mertens 5 Prismtech 6 September 14, 2015 8 Requirements for mounting of local and remote YANG subtrees 9 draft-voit-netmod-peer-mount-requirements-03 11 Abstract 13 Network integrated applications want simple ways to reference and 14 access YANG objects and subtrees. These simplifications might 15 include aliasing of local YANG information. These simplifications 16 might include remote referencing of YANG information distributed 17 across network. 19 For such applications, development complexity must be minimized. 20 Specific aspects of complexity developers want to ignore include: 22 o whether multiple aliases and paths for the same information are 23 exposed on a single device, 25 o whether authoritative information is actually sourced from local 26 or remote datastores, 28 o the overhead of session establishment and maintenance which is 29 needed in order to access information on remote datastores, 31 o whether objects have been locally cached or not, and 33 o whether there is a mix of controllers, NMSs, and/or CLI which have 34 access permission to update the primary copy of a particular 35 object. 37 The solution requirements described in this document detail what is 38 needed to support application access to authoritative network YANG 39 objects locally (via aliasing), or remotely from controllers or 40 peering network devices in such a way to meet these goals. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on March 17, 2016. 59 Copyright Notice 61 Copyright (c) 2015 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Business Problem . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Solution Context . . . . . . . . . . . . . . . . . . . . . . 5 79 3.1. YANG Mount . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.2. Eventual Consistency and YANG . . . . . . . . . . . . . . 8 81 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 82 4.1. Cloud Policer . . . . . . . . . . . . . . . . . . . . . . 9 83 4.2. DDoS Thresholding . . . . . . . . . . . . . . . . . . . . 10 84 4.3. Service Chain Classification, Load Balancing and Capacity 85 Management . . . . . . . . . . . . . . . . . . . . . . . 11 86 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 87 5.1. Application Simplification . . . . . . . . . . . . . . . 12 88 5.2. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 5.3. Subscribing to Remote Object Updates . . . . . . . . . . 14 90 5.4. Lifecycle of the Mount Topology . . . . . . . . . . . . . 14 91 5.5. Mount Filter . . . . . . . . . . . . . . . . . . . . . . 15 92 5.6. Auto-Negotiation of Peer Mount Client QoS . . . . . . . . 15 93 5.7. Datastore Qualification . . . . . . . . . . . . . . . . . 16 94 5.8. Mount Cascades . . . . . . . . . . . . . . . . . . . . . 16 95 5.9. Transport . . . . . . . . . . . . . . . . . . . . . . . . 16 96 5.10. Security Considerations . . . . . . . . . . . . . . . . . 16 97 5.11. High Availability . . . . . . . . . . . . . . . . . . . . 17 98 5.12. Configuration . . . . . . . . . . . . . . . . . . . . . . 19 99 5.13. Assurance and Monitoring . . . . . . . . . . . . . . . . 19 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 104 8.2. Informative References . . . . . . . . . . . . . . . . . 20 105 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 108 1. Business Problem 110 Instrumenting Physical and Virtual Network Elements purely along 111 device boundaries and via a fully normalized object representation is 112 insufficient for today's requirements. Instead, users, applications, 113 and operators are asking for the ability to interact with local and 114 remote information exposed as simply as possible from a familiar 115 local datastore. 117 Achieving an easy, local abstract representation of any remote 118 information can be difficult since a running network is comprised of 119 a distributed mesh of object ownership. Solutions require the 120 transparent assembly of local and remote objects in order to provide 121 context specific, time synchronized, and consistent views required 122 for a simple local abstraction. 124 Ultimately network application programming must be simplified. To do 125 this: 127 o we must allow local and remote aliasing of network objects so that 128 programmers can work against models which have been tuned for 129 their development environment, structured in ways that best make 130 sense to them 132 o we must provide APIs to both controller and network element based 133 applications in a way which allows access to these objects, 135 o we must hide the mesh of interdependencies and consistency 136 enforcement mechanisms between devices which will underpin a 137 particular abstraction, 139 o we must enable flexible deployment models, in which applications 140 are able to run not only on controller and OSS frameworks but also 141 on network devices without requiring heavy middleware with large 142 footprints, and 144 o we need to maintain clear authoritative ownership of individual 145 data items while not burdening applications with the need to 146 reconcile and synchronize information replicated in different 147 systems, nor needing to maintain redundant data models that 148 operate on the same underlying data. 150 These steps will eliminate much unnecessary overhead currently 151 required of today's network programmer. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 Alias Mount - A type of YANG Mount performed against a subtree 160 located in a local datastore. 162 Authoritative Datastore - A datastore containing the authoritative 163 copy of an object, i.e. the source and the "owner" of the object. 165 Client Datastore - a datastore containing an object whose source and 166 "owner" is a remote datastore. 168 Data Node - An instance of management information in a YANG 169 datastore. 171 Datastore - A conceptual store of instantiated information, with 172 individual data items represented by data nodes which are arranged in 173 hierarchical manner. 175 Data Subtree - An instantiated data node and the data nodes that are 176 hierarchically contained within it. 178 Mount Client - The system at which the mount point resides, into 179 which one or more subtrees may be mounted. 181 Mount Binding - An instance of YANG mount from a specific Mount Point 182 to a datastore. Types include: 184 o On-demand: Mount Client only pulls information when application 185 requests 187 o Periodic: Mount Server pushes current state at a pre-defined 188 interval 190 o Unsolicited: Mount Server maintains active bindings and sends to 191 client cache upon change 193 Mount Point - Point in the local data store which may reference a 194 single remote subtree 196 Mount Server - The server with which the Mount Client communicates 197 and which provides the Mount Client with access to the mounted 198 information. Can be used synonymously with Mount Target. 200 Peer Mount - A method of YANG Mount which enables the representation 201 of remote objects within a local datastore. 203 Target Data Node - Data Node on Mount Server against which a Mount 204 Binding is established 206 YANG Mount - A method of including YANG data node from another 207 location as part of a specific YANG model and on a specific path in 208 the data tree via an explicit reference to a subtree to be included. 209 Two subtypes are Alias Mount and Peer Mount. 211 3. Solution Context 213 YANG modeling has emerged as a preferred way to offer network 214 abstractions. The requirements in this document can be enabled by 215 expanding of the syntax of YANG capabilities embodied within RFC 6020 216 [RFC6020] and YANG 1.1 [rfc6020bis]. A companion draft to this one 217 which details a potential set of YANG technology extensions which can 218 support key requirements within this document are contained in . 219 [draft-clemm-mount]. 221 To date systems built upon YANG models have been missing two 222 capabilities: 224 1. YANG Datastore Mount: Datastores have not been able to proxy 225 objects located elsewhere on the same device, or upon a different 226 device. This puts additional burden upon applications which then 227 need to find and access multiple locations and which may be on 228 remote systems. 230 2. Eventual Consistency: YANG Datastore implementations have 231 typically assumed ACID [1] transaction models. There is nothing 232 inherent in YANG itself which demands ACID transactional 233 guarantees. YANG models can also expose information which might 234 be in the process of undergoing convergence. Since IP networking 235 has been designed with convergence in mind, this is a useful 236 capability since some types of applications must participate 237 where there is dynamically changing state. 239 3.1. YANG Mount 241 First this document will dive deeper into YANG Datastore Mount 242 (a.k.a., "YANG Mount"). Two subtypes of YANG Mount are "Alias Mount" 243 and "Peer Mount". 245 Alias Mount allows access to the same YANG data node along different 246 paths within the same YANG datastore, allowing a given subtree to 247 subtend from different YANG models within the same system. This 248 provides a means to: 250 o Provide application developers with custom and consolidated YANG 251 objects that expose only the needed objects. 253 o Expose the objects organized into alternative structures, 254 referenced via alternative application-intuitive paths. (This may 255 include aliasing additional hierarchy layers to get to existing 256 objects, including objects that had hitherto been right under 257 root.) 259 o Accomplishing this without requiring mirroring or replication of 260 the underlying data across various datastores. 262 Considering there are YANG models incorporating intersected and 263 replicated information today, adding an Alias Mount capability should 264 reduce YANG model development and model mapping requirements. 266 For Peer Mount, we need the capability to refer to managed resources 267 that reside on different systems. This allows applications on the 268 same system as the YANG datastore server, as well as remote clients 269 that access the datastore through a management protocol such as 270 NETCONF, to access all data from a familiar local YANG model. 272 o This is done in a manner that is transparent to users and 273 applications. 275 o This is done in a way which does not require a user or application 276 to be aware of the fact that some data resides in a different 277 location and have them directly access that other system 279 In this way, an application developer is projected an image of one 280 virtual consolidated datastore. Peer Mount builds on Alias Mount by 281 allowing to incorporate redirection to remote systems into the 282 structure. 284 The value in YANG Mount comes from its under-the-covers federation. 285 The datastore transparently exposes information about objects that 286 can be reached along multiple paths, allowing to make the same data 287 nodes part of multiple concurrent hierarchies. The user does not 288 need to be aware of the precise distribution and ownership of data 289 themselves, nor is there a need for the application to discover those 290 data sources, maintain separate associations with them, and partition 291 its operations to fit along remote system boundaries. The effect is 292 that a network device can broaden and customize the information 293 available for local access. Life for the application is easier. 295 At the same time, the authoritative ownership of a data node is never 296 in question. The original hierarchy and path that was defined when 297 the data node was first defined in a YANG module remain in effect, 298 and any validation involved in creating, modifying, or deleting the 299 data node always occurs in the same context in which it was 300 originally introduced. All that YANG Mount allows to do is to define 301 alternative, additional paths and hierarchies to which the object 302 could also be accessed. 304 Any Object or subtree type can be exposed via such a reference. This 305 can include configuration data that is either persistent or 306 ephemeral, and which is valid within only a single device or across a 307 domain of devices. This can include operational data that represents 308 state across a single device or across a multiple devices. 310 Another useful aspect of YANG Mount is its ability to embed 311 information from existing into newly defined models without requiring 312 additional normalization effort. Normalization is a good thing, but 313 the massive human efforts invested in uber-data-models have never 314 gained industry traction due to the resulting models' brittle nature 315 and complexity. By mounting subtrees/objects into local datastores 316 it is possible to expose objects under a locally optimized hierarchy 317 without having to transpose remote objects into a separate local 318 model. 320 It should be noted that YANG Mount does not require knowledge of the 321 entire subtree being mounted. For example, there might be 322 augmentations of that subtree, or even mounted information in the 323 subtree itself. Likewise, mounted objects might dynamically change, 324 or even come into being. These dynamic changes can be reflected as 325 needed under the "attachment points" within the namespace hierarchy 326 where the data subtrees from remote systems have been mounted. In 327 this case, the precise details of what these subtrees exactly contain 328 does not need to be understood by the system implementing the 329 attachment point, it simply acts as a single point of entry and 330 "proxy" for the attached data. . 332 3.2. Eventual Consistency and YANG 334 The CAP theorem [2] states that it is impossible for a distributed 335 computer system to simultaneously provide Consistency, Availability, 336 and Partition tolerance. (I.e., distributed network state management 337 is hard.) Mostly for this reason YANG implementations have shied 338 away from distributed datastore implementations where ACID 339 transactional guarantees cannot be given. This of course limits the 340 universe of applicability for YANG technology. 342 Leveraging YANG concepts, syntax, and models for objects which might 343 be happening to undergo network convergence is valuable. Such reuse 344 greatly expands the universe of information visible to networking 345 applications. The good news is that there is nothing in YANG syntax 346 that prohibits its reapplication for distributed datastores. 347 Extensions are needed however. 349 Requirements described within this document can be used to define 350 technology extensions to YANG 1.1 for remote datastore mounting. 351 Because of the CAP theorem, it must be recognized that systems built 352 upon these extensions MAY choose to support eventual consistency 353 rather than ACID guarantees. Some applications do not demand ACID 354 guarantees (examples are contained in this document's Use Case 355 section). Therefore for certain classes of applications, eventual 356 consistency [3] should be viewed as a cornerstone feature capability 357 rather than a bug. 359 Other industries have been able to identify and realize the value in 360 such model. The Object Management Group Data-Distribution Service 361 for Real-Time Systems has even standardized these capabilities for 362 non-YANG deployments [OMG-DDS]. Commercial deployments exist. 364 4. Example Use Cases 366 Example Use Cases for Alias Mount can easily be seen from the 367 description within Section 3.1. Therefore these are not detailed 368 within this document. In general, those use cases involve imposing 369 an alternative structure over YANG data models. YANG allows to 370 extend and augment data models, allowing to add new data nodes as 371 child nodes or as siblings to existing data nodes. However, YANG 372 does not allow to superimpose a new data node on top of an existing 373 one, or move an existing node under a newly defined node. Peer Mount 374 closes that gap and allows to define models with alternative 375 hierarchies and insert existing data nodes into that hierarchy. 377 For Peer Mount, many types of applications can benefit from the 378 simple and quick availability of objects from peer network devices. 379 Because network management and orchestration systems have been 380 fulfilling a subset of the requirements for decades, it is important 381 to focus on what has changed. Changes include: 383 o SDN applications wish to interact with local datastore(s) as if 384 they represent the real-time state of the distributed network. 386 o Independent sets of applications and SDN controllers might care 387 about the same authoritative data node or subtree. 389 o Changes in the real-time state of objects can announce themselves 390 to subscribing applications. 392 o The union of an ever increasing number of abstractions provided 393 from different layers of the network are assumed to be consistent 394 with each other (at least once a reasonable convergence time has 395 been factored in). 397 o CPU and VM improvements makes running Linux based applications on 398 network elements viable. 400 Such changes can enable a new class of applications. These 401 applications are built upon fast-feedback-loops which dynamically 402 tune the network based on iterative interactions upon a distributed 403 datastore. 405 4.1. Cloud Policer 407 A Cloud Policer enables a single aggregated data rate to tenants/ 408 users of a data center cloud that applies across their VMs; a rate 409 independent of where specific VMs are physically hosted. This works 410 by having edge router based traffic counters available to a 411 centralized application, which can then maintain an aggregate across 412 those counters. Based on the sum of the counters across the set of 413 edge routers, new values for each device based Policer can be 414 recalculated and installed. Effectively policing rates are 415 continuously rebalanced based on the most recent traffic offered to 416 the aggregate set of edge devices. 418 The cloud policer provides a very simple cloud QoS model. Many other 419 QoS models could also be implemented. Example extensions include: 421 o CIR/PIR guarantees for a tenant, 423 o hierarchical QoS treatment, 425 o providing traffic delivery guarantees for specific enterprise 426 branch offices, and 428 o adjusting the prioritization of one application based on the 429 activity of another application which perhaps is in a completely 430 different location. 432 It is possible to implement such a cloud policer application with 433 maximum application developer simplicity using peer mount. To do 434 this the application accesses a local datastore which in turn does a 435 peer mount from edge routers the objects which house current traffic 436 counter statistics. These counters are accessed as if they were part 437 of the local datastore structures, without concern for the fact that 438 the actual authoritative copies reside on remote systems. 440 Beyond this centralized counter collection peer mount, it is also 441 possible to have distributed edge routers mount information in the 442 reverse direction. In this case local edge routers can peer mount 443 centrally calculated policer rates for the device, and access these 444 objects as if they were locally configured. 446 For both directions of mounting, the authoritative copy resides in a 447 single system and is mounted by peers. Therefore issues with regards 448 to inconsistent configuration of the same redundant data across the 449 network are avoided. Also as can be seen in this use case, the same 450 system can act as a mount client of some objects while acting as 451 server for other objects. 453 4.2. DDoS Thresholding 455 Another extension of the "Cloud Policer" application is the creation 456 of additional action thresholds at bandwidth rates far greater than 457 might be expected. If these higher thresholds are hit, it is 458 possible to connect in DDoS scrubbers to ingress traffic. This can 459 be done in seconds after a bandwidth spike. This can also be done if 460 non-bandwidth counters are available. For example, if TCP flag 461 counts are available it is possible to look for changes in SYN/ACK 462 ratios which might signal a different type of attack. In all cases, 463 when network counters indicate a return to normal traffic profiles 464 the DDoS Scrubbers can be automatically disconnected. 466 Benefits of only connecting a DDoS scrubber in the rare event an 467 attack might be underway include: 469 o marking down traffic for an out-of-profile tenant so that an 470 potential attack doesn't adversely impact others, 472 o applying DDoS Scrubbing across many devices when an attack is 473 detected in one, 475 o reducing DDoS scrubber CPU, power, and licensing requirements 476 (during the vast majority of time, spikes are not occurring), and 478 o dynamic management and allocation of scarce platform resources 479 (such as optimizing span port usage, or limiting IP-FIX reporting 480 to levels where devices can do full flow detail exporting). 482 4.3. Service Chain Classification, Load Balancing and Capacity 483 Management 485 Service Chains will dynamically change ingress classification 486 filters, allocate paths from many ingress devices across shared 487 resources. This information needs to be updated in real time as 488 available capacity is allocated or failures are discovered. It is 489 possible to simplify service chain configuration and dynamic topology 490 maintenance by transparently updating remote cached topologies when 491 an authoritative object is changed within a central repository. For 492 example if the CPU in one VM spikes, you might want to recalculate 493 and adjust many chained paths to relieve the pressure. Or perhaps 494 after the recalculation you want to spin up a new VM, and then adjust 495 chains when that capacity is on-line. 497 A key value here is central calculation and transparent auto- 498 distribution. In other words, a change only need be updated by an 499 application in a single location, and the infrastructure will 500 automatically synchronize changes across any number of subscribing 501 devices without application involvement. In fact, the application 502 need not even know many devices are monitoring the object which has 503 been changed. 505 Beyond 1:n policy distribution, applications can step back from 506 aspects of failure recovery. What happens if a device is rebooting 507 or simply misses a distribution of new information? With peer mount 508 there is no doubt as to where the authoritative information resides 509 if things get out of synch. 511 While this ability is certainly useful for dynamic service chain 512 filtering classification and next hop mapping, this use case has more 513 general applicability. With a distributed datastore, diverse 514 applications and hosts can locally access a single device's current 515 VM CPU and Bandwidth values. They can do it without needing to 516 explicitly query that remote machine. Updates from a device would 517 come from a periodic push of stats to a transparent cache to 518 subscribed, or via an unsolicited update which is only sent when 519 these value exceed established norms. 521 5. Requirements 523 To achieve the objectives described above, the network needs to 524 support a number of requirements 526 5.1. Application Simplification 528 A major obstacle to network programmability are any requirements 529 which force applications to use abstractions more complicated than 530 the developer cares to touch. To simplify applications development 531 and reduce unnecessary code, the following needs must be met. 533 Applications MUST be able to access a local datastore which includes 534 objects whose authoritative source perhaps is located in a elsewhere 535 in some datastore. 537 Local datastores MUST be able to provide a hierarchical view of 538 objects assembled from objects whose authoritative source may 539 potentially originate from different and overlapping namespaces. 541 Applications MUST be able to access all objects of a datastore 542 without concern where the actual object is located, i.e. whether the 543 authoritative copy of the object is hosted on the same system as the 544 local datastore or whether it is hosted in a remote datastore. 546 A datastore's application facing interfaces MUST make no 547 differentiation whether individual objects exposed are 548 authoritatively owned by the datastore or mounted from elsewhere 550 When a change is made to an object, that change will be reflected in 551 any datastore in which the object is included. 553 A datastore supporting YANG Mount MUST allow the same object to be 554 mounted from multiple places. 556 Applications SHOULD be able to extract a time synchronized set of 557 operational data from the datastore. (In other words, the 558 application asks for a subset of network state at time-stamp or time- 559 range "X". The datastore would then deliver time synchronized 560 snapshots of the network state per the request. The datastore may 561 work with NTP and operational counter to optimize the synchronization 562 results of such a query. It is understood that some types of data 563 might be undergoing convergence conditions.) 565 Authoritative datastore retain full ownership of "their" objects. 566 This means that while remote datastores may access the data, any 567 modifications to objects that are initiated at those remote 568 datastores need to be authorized by the authoritative owner of the 569 data. Likewise, the authoritative owner of the data may make changes 570 to objects, including modifications, additions, and deletions, 571 without needing to first ask for permission from remote clients. 573 Applications MUST be designed to deal with incomplete data if remote 574 objects are not accessible, e.g. due to temporal connectivity issues 575 preventing access to the authoritative source. (This will be true 576 for many protocols and programming languages. Mount is unlikely to 577 add anything new here unless applications have extra error handling 578 routines to deal with when there is no response from a remote 579 system.). 581 5.2. Caching 583 Remote objects in a datastore can be accessed "on demand", when the 584 application interacting with the datastore demands it. In that case, 585 a request made to the local datastore is forwarded to the remote 586 system. The response from the remote system, e.g. the retrieved 587 data, is subsequently merged and collated with the other data to 588 return a consolidated response to the invoking application. 590 A downside of a datastore which is distributed across devices can be 591 the latency induced when remote object acquisition is necessary. 592 There are plenty of applications which have requirements which simply 593 cannot be served when latency is introduced. The good news is that 594 the concept of caching lends itself well to distributed datastores. 595 It is possible to transparently store some types of objects locally 596 even when the authoritative copy is remote. Instead of fetching data 597 on demand when an application demands it, the application is simply 598 provided with the local copy. It is then up to the datastore 599 infrastructure to keep selected replicated info in synch, e.g. by 600 prefetching information, or by having the remote system publish 601 updates which are then locally stored. At this point, it is expected 602 that a preferred method of subscribing to and publishing updates will 603 be accomplished via [i2rs-pub-sub-reqts] and 604 [draft-clemm-datastore-push]. Other methods could work equally well 605 . 607 This is not a new idea. Caching and Content Delivery Networks (CDN) 608 have sped read access for objects within the Internet for years. 609 This has enabled greater performance and scale for certain content. 610 Just as important, these technologies have been employed without end 611 user applications being explicitly aware of their involvement. Such 612 concepts are applicable for scaling the performance of a distributed 613 datastore. 615 Where caching occurs, it MUST be possible for the Mount Client to 616 store object copies of a remote data node or subtree in such a way 617 that applications are unaware that any caching is occurring. 618 However, the interface to a datastore MAY provide applications with a 619 special mode/flag to allow them to force a read-through. 621 Where caching occurs, system administration facilities SHOULD allow 622 facilities to flush either the entire cache, or information 623 associated with select Mount Points. 625 5.3. Subscribing to Remote Object Updates 627 When caching occurs, data can go stale. [draft-clemm-datastore-push] 628 provides a mechanism where changes in an authoritative data node or 629 subtree can be monitored. If changes occur, these changes can be 630 delivered to any subscribing datastores. In this way remote caches 631 can be kept up-to-date. In this way, directly monitoring remote 632 applications can quickly receive notifications without continuous 633 polling. 635 A Mount Server SHOULD support [draft-clemm-datastore-push] Periodic 636 and/or On-Change pub/sub capabilities in which one or more remote 637 clients subscribe to updates of a target data node / subtree, which 638 are then automatically published by the Mount Server. 640 It MUST be possible for Applications to bind to subscribed Data Node 641 / Subtrees so that upon Mount Client receipt of subscribed 642 information, it is immediately passed to the application. 644 It MUST be possible for a Target Data Node to support 1:n Mount 645 Bindings to many subscribed Mount Points. 647 5.4. Lifecycle of the Mount Topology 649 Mount can drive a dynamic and richly interconnected mesh of peer-to- 650 peer of object relationships. Each of these Mounts will be 651 independently established by a Mount Client. 653 It MUST be possible to bootstrap the Mount Client by providing the 654 YANG paths to resources on the Mount Server. 656 There SHOULD be the ability to add Mount Client bindings during run- 657 time. 659 A Mount Client MUST be able to be able to create, delete, and timeout 660 Mount Bindings. 662 Any Subscription MUST be able to inform the Mount Client of an 663 intentional/graceful disconnect. 665 A Mount Client MUST be able to verify the status of Subscriptions, 666 and drive re-establishment if it has disappeared. 668 5.4.1. Discovery and Creation of Mount Topology 670 Application visibility into an ever-changing set of network objects 671 is not trivial. While some applications can be easily configured to 672 know the Devices and available Mount Points of interest, other 673 applications will have to balance many aspects of dynamic device 674 availability, capabilities, and interconnectedness. Maintenance of 675 these dynamic elements can be done on the YANG objects themselves 676 without anything needed new for YANG Mount. 678 5.4.2. Restrictions on the Mount Topology 680 Mount Clients MUST NOT create recursive Mount bindings (i.e., the 681 Mount Client should not load any object or subtree which it has 682 already delivered to another in the role of a Mount Server.) Note: 683 Objects mounted from a controller as part of orchestration are *not* 684 considered the same objects as those which might be mounted back from 685 a network device showing the actual running config. 687 5.5. Mount Filter 689 The Mount Server default MUST be to deliver the same Data Node / 690 Subtree that would have been delivered via direct YANG access. 692 It SHOULD be possible for a Mount Client to request something less 693 than the full subtree or a target node as defined in 694 [i2rs-pub-sub-reqts]. 696 5.6. Auto-Negotiation of Peer Mount Client QoS 698 The interest that a Mount Client expresses in a particular subtree 699 SHOULD include the non-functional data delivery requirements (QoS) on 700 the data that is being mounted. Additionally, Mount Servers SHOULD 701 advertise their data delivery capabilities. With this information 702 the Mount Client can decide whether the quality of the delivered data 703 is sufficient to serve applications residing above the Mount Client. 705 An example here is reliability. A reliable protocol might be 706 overkill for a state that is republished with high frequency. 707 Therefore a Mount Server may sometimes choose to not provide a 708 reliable method of communication for certain objects. It is up to 709 the Mount Client to determine whether what is offered is sufficiently 710 reliable for its application. Only when the Mount Server is offering 711 data delivery QoS better or equal to what is requested, shall a mount 712 binding be established. 714 Another example is where subscribed objects must be pushed from the 715 Mount Server within a certain interval from when an object change is 716 identified. In such a scenario the interval period of the Mount 717 Server must be equal or smaller than what is requested by a Mount 718 Client. If this "deadline" is not met by the Mount Server the 719 infrastructure MAY take action to notify clients. 721 5.7. Datastore Qualification 723 It is conceivable to differentiate between different datastores on 724 the remote server, that is, to designate the name of the actual 725 datastore to mount, e.g. "running" or "startup". If on the target 726 node there are multiple datastores available, but there has no 727 specific datastore identified by the Mount Client, then the running 728 or "effective" datastore is the assumed target. 730 It is conceivable to use such Datastore Qualification in conjunction 731 with ephemeral datastores, to address requirements being worked in 732 the I2RS WG [draft-i2rs-ephemeral]. 734 5.8. Mount Cascades 736 It is possible for the mounted subtree to in turn contain a 737 mountpoint. However, circular mount relationships MUST NOT be 738 introduced. For this reason, a mounted subtree MUST NOT contain a 739 mountpoint that refers back to a mount target that directly or 740 indirectly contains the originating mountpoint. As part of a mount 741 operation, the mount points of the mounted system need to be checked 742 accordingly. 744 5.9. Transport 746 Many secured transports are viable assuming transport, data security, 747 scale, and performance objectives are met. Netconf and/or Restconf 748 should be considered as starting points. Other transports may be 749 proposed over time. 751 It MUST be possible to support Netconf or Restconf Transport of 752 subscribed Nodes and Subtrees. 754 5.10. Security Considerations 756 Many security mechanisms exist to protect data access for CLI and API 757 on network devices. To the degree possible these mechanisms should 758 transparently protect data when performing a Peer Mount. 760 The same mechanisms used to determine whether a remote host has 761 access to a particular YANG Data Node or Subtree MUST be invoked to 762 determine whether a Mount Client has access to that information. 764 The same traditional transport level security mechanism security used 765 for YANG over a particular transport MUST be used for the delivery of 766 objects from a Mount Server to a Mount Client. 768 A Mount Server implementation MUST NOT change any credentials passed 769 by the Mount Client system for any Mount Binding request. 771 The Mount Server MUST deliver no more objects from a Data Node or 772 Subtree than allowable based on the security credentials provided by 773 the Mount Client. 775 To ensure the ensuring maximum scale limits, it MUST be possible to 776 for a Mount Server to limit the number of bindings and transactional 777 limits 779 It SHOULD be possible to prioritize which Mount Binding instances 780 should be serviced first if there is CPU, bandwidth, or other 781 capacity constraints. 783 5.11. High Availability 785 A key intent for YANG Mount is to allow access to an authoritative 786 copy of an object for a particular domain. Of course system and 787 software failures or scheduled upgrades might mean that the primary 788 copy is not consistently accessible from a single device. In 789 addition, system failovers might mean that the authoritative copy 790 might be housed on a different device than the one where the binding 791 was originally established. YANG Mount architectures must be built 792 to enable Mount Clients to transparently provide access to objects 793 where the authoritative copy moves due to dynamic network 794 reconfigurations . 796 A YANG Mount architecture MUST guarantee that mount bindings between 797 a Mount Server and Mount Clients drive system behavior which is at 798 least eventually consistent. The infrastructure providing this level 799 of consistency MUST be able to operate in scenarios where a system is 800 (temporarily) not fully connected. Furthermore, Mount Clients MAY 801 have various requirements on the boundaries under which eventual 802 consistency is allowed to take place. This subject can be decomposed 803 in the following items: 805 5.11.1. Reliability 807 A scenario that deserves attention in particular is when a subset of 808 Mount Clients receive and cache a pushed subscription update. If a 809 Mount Server loses connectivity, cross network element consistency 810 can be lost. In such a scenario Mount Clients MAY elect a new 811 designated Mount Server from the set of Mount Clients which have 812 received the latest state. 814 5.11.2. Alignment to late joining peers 816 When a mount binding is established a Mount Server SHOULD provide the 817 Mount Client with the latest state of the requested data. In order 818 to increase availability and fault tolerance an infrastructure MAY 819 support the capability to have multiple alignment sources. In 820 (temporary) absence of a Mount Server, Mount Clients MAY elect a 821 temporary Mount Server to service late joining Mount Clients. 823 5.11.3. Liveliness 825 Upon losing liveliness and being unable to refresh cached data 826 provided from a Mount Server, a Mount Client MAY decide to purge the 827 mount bindings of that server. Purging mount bindings under such 828 conditions however makes a system vulnerable to losing network-wide 829 consistency. A Mount Client can take proactive action based on the 830 assumption that the Mount Server is no longer available. When 831 connectivity is only temporarily lost, this assumption could be false 832 for other datastores. This can introduce a potential for decision- 833 making based on semantical disagreement. To properly handle these 834 scenarios, application behavior MUST be designed accordingly and 835 timeouts with regards to liveliness detection MUST be carefully 836 determined. 838 5.11.4. Merging of datasets 840 A traditional problem with merging replicated datasets during the 841 failover and recovery of Mount Servers is handling the corresponding 842 target data node lifecycle management. When two replicas of a 843 dataset experienced a prolonged loss of connectivity a merge between 844 the two is required upon re-establishing connectivity. A replica 845 might have been modifying contents of the set, including deletion of 846 objects. A naive merge of the two replicas would discard these 847 deletes by aligning the now stale, deleted objects to the replica 848 that deleted them. 850 Authoritative ownership is an elegant solution to this problem since 851 modifications of content can only take place at the owner. Therefore 852 a Mount Client SHOULD, upon reestablishing connectivity with a newly 853 authoritative Mount Server, replace any existing cache contents from 854 a mount binding with the latest version. 856 5.11.5. Distributed Mount Servers 858 For selected objects, Mount Bindings SHOULD be allowed to Anycast 859 addresses so that a Distributed Mount Server implementation can 860 transparently provide (a) availability during failure events to Mount 861 Clients, and (b) load balancing on behalf of Mount Clients. 863 5.12. Configuration 865 At the Mount Client, it MUST be possible for all Mount bindings to 866 configure the following such that the application needs no knowledge. 867 This will include a diverse list of elements such as the YANG URI 868 path to the remote subtree. 870 5.13. Assurance and Monitoring 872 API usage for YANG should be tracked via existing mechanisms. There 873 is no intent to require additional transaction tracking than would 874 have been provided normally. However there are additional 875 requirements which should allow the state of existing and historical 876 bindings to be provided. 878 A Mount Client MUST be able to poll a Mount Server for the state of 879 Subsciptions maintained between the two devices. 881 A Mount Server MUST be able to publish the set of Subscriptions which 882 are currently established on or below any identified data node. 884 6. IANA Considerations 886 This document makes no request of IANA. 888 7. Acknowledgements 890 We wish to acknowledge the helpful contributions, comments, and 891 suggestions that were received from Ambika Prasad Tripathy. Shashi 892 Kumar Bansal, Prabhakara Yellai, Dinkar Kunjikrishnan, Harish 893 Gumaste, Rohit M., Shruthi V. , Sudarshan Ganapathi, and Swaroop 894 Shastri. 896 8. References 897 8.1. Normative References 899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 900 Requirement Levels", BCP 14, RFC 2119, 901 DOI 10.17487/RFC2119, March 1997, 902 . 904 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 905 the Network Configuration Protocol (NETCONF)", RFC 6020, 906 DOI 10.17487/RFC6020, October 2010, 907 . 909 8.2. Informative References 911 [draft-clemm-datastore-push] 912 Clemm, A., "Subscribing to datastore push updates", July 913 2015, . 916 [draft-clemm-mount] 917 Clemm, Alexander., "Mounting YANG-Defined Information from 918 Remote Datastores", April 2015, . 921 [draft-i2rs-ephemeral] 922 Haas, J., "I2RS Ephemeral State Requirements", June 2015, 923 . 926 [i2rs-pub-sub-reqts] 927 Voit, Eric., Clemm, Alexander., and Alberto. Gonzalez 928 Prieto, "Requirements for Subscription to YANG 929 Datastores", March 2015, . 932 [OMG-DDS] "Data Distribution Service for Real-time Systems, version 933 1.2", January 2007, . 935 [rfc6020bis] 936 Bjorklund, Martin., "YANG - A Data Modeling Language for 937 the Network Configuration Protocol (NETCONF)", May 2015, 938 . 941 8.3. URIs 943 [1] http://en.wikipedia.org/wiki/ACID 945 [2] http://robertgreiner.com/2014/08/cap-theorem-revisited/ 947 [3] http://guide.couchdb.org/draft/consistency.html 949 Authors' Addresses 951 Eric Voit 952 Cisco Systems 954 Email: evoit@cisco.com 956 Alexander Clemm 957 Cisco Systems 959 Email: alex@cisco.com 961 Sander Mertens 962 Prismtech 964 Email: sander.mertens8@gmail.com