idnits 2.17.1 draft-hares-netconf-i2rs-protocol-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 == Line 180 has weird spacing: '...tastore are c...' == Line 227 has weird spacing: '...ges win the p...' == Line 245 has weird spacing: '... update the p...' -- The document date (November 15, 2016) is 2690 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7921' is mentioned on line 1011, but not defined == Missing Reference: 'RFC6241' is mentioned on line 969, but not defined == Missing Reference: 'RFC7950' is mentioned on line 1026, but not defined == Missing Reference: 'RFC2119' is mentioned on line 941, but not defined == Missing Reference: 'RFC7920' is mentioned on line 1006, but not defined == Missing Reference: 'RFC7922' is mentioned on line 1016, but not defined == Missing Reference: 'RFC7923' is mentioned on line 1021, but not defined == Missing Reference: 'RFC7803' is mentioned on line 997, but not defined == Missing Reference: 'RFC6536' is mentioned on line 982, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC7589' is mentioned on line 991, but not defined == Missing Reference: 'RFC7895' is mentioned on line 1002, but not defined ** Obsolete undefined reference: RFC 7895 (Obsoleted by RFC 8525) == Missing Reference: 'RFC5424' is mentioned on line 960, but not defined == Missing Reference: 'RFC4107' is mentioned on line 946, but not defined == Missing Reference: 'RFC4960' is mentioned on line 950, but not defined ** Obsolete undefined reference: RFC 4960 (Obsoleted by RFC 9260) == Missing Reference: 'RFC5339' is mentioned on line 954, but not defined == Missing Reference: 'RFC6020' is mentioned on line 964, but not defined == Missing Reference: 'RFC6242' is mentioned on line 974, but not defined == Missing Reference: 'RFC6244' is mentioned on line 978, but not defined == Missing Reference: 'RFC7158' is mentioned on line 987, but not defined ** Obsolete undefined reference: RFC 7158 (Obsoleted by RFC 7159) == Missing Reference: 'RFC7952' is mentioned on line 1030, but not defined == Missing Reference: 'RFC7958' is mentioned on line 1034, but not defined == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 1058, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-i2rs-ephemeral-state-22 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-rib-data-model-06 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-09 == Outdated reference: A later version (-06) exists of draft-ietf-i2rs-security-environment-reqs-01 == Outdated reference: A later version (-16) exists of draft-ietf-i2rs-yang-l3-topology-04 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-00 == Outdated reference: A later version (-22) exists of draft-ietf-netconf-netconf-event-notifications-01 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-01 == Outdated reference: A later version (-14) exists of draft-ietf-netconf-yang-patch-13 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-04 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-11 == Outdated reference: A later version (-12) exists of draft-ietf-netmod-schema-mount-03 == Outdated reference: A later version (-32) exists of draft-ietf-netmod-syslog-model-11 Summary: 4 errors (**), 0 flaws (~~), 39 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Huawei 4 Intended status: Informational A. Dass 5 Expires: May 19, 2017 Ericsson 6 November 15, 2016 8 NETCONF Changes to Support I2RS Protocol 9 draft-hares-netconf-i2rs-protocol-00.txt 11 Abstract 13 This document describes a NETCONF capabiilty to support the Interface 14 to Routing system (I2RS) protocol requirements for I2RS protocol 15 version 1. The I2RS protocol is a re-use higher layer protocol which 16 defines extensions to other protocols (NETCONF and RESTCONf) and 17 extensions to the Yang Data Modeling language. 19 The I2RS protocol supports ephemeral state datastores as control 20 plane datastores. Initial versions of this document contain 21 descriptions of the ephemeral datastore. Future versions may move 22 this description to NETMOD datastore description documents. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 19, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions Related to Ephemeral Configuration . . . . . . . 4 60 2.1. Requirements language . . . . . . . . . . . . . . . . . . 4 61 2.2. I2RS Definitions . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview of Changes . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. I2RS protocol requirements . . . . . . . . . . . . . . . 6 64 3.2. NETCONF Features and Extensions . . . . . . . . . . . . . 7 65 3.3. RESTCONF features and Extensions . . . . . . . . . . . . 8 66 3.4. Assumptions on Data Store Model Melee . . . . . . . . . . 8 67 4. NETCONF protocol extensions for the ephemeral datastore . . . 9 68 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . 10 70 4.3. Capability identifier . . . . . . . . . . . . . . . . . . 11 71 4.4. New Operations . . . . . . . . . . . . . . . . . . . . . 11 72 4.5. Modification to existing operations . . . . . . . . . . . 11 73 4.5.1. . . . . . . . . . . . . . . . . . . . . 11 74 4.5.2. . . . . . . . . . . . . . . . . . . . . 12 75 4.5.3. . . . . . . . . . . . . . . . . . . . . 13 76 4.5.4. . . . . . . . . . . . . . . . . . . . 13 77 4.5.5. and . . . . . . . . . . . . . . . . . 13 78 4.5.6. . . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.5.7. and . . . . . . . . . 13 80 4.6. Interactions with Capabilities . . . . . . . . . . . . . 13 81 4.6.1. writable-running and candidate datastore . . . . . . 14 82 4.6.2. confirmed commmit . . . . . . . . . . . . . . . . . . 14 83 4.6.3. rollback-on-error . . . . . . . . . . . . . . . . . . 14 84 4.6.4. validate . . . . . . . . . . . . . . . . . . . . . . 14 85 4.6.5. Distinct Startup Capability . . . . . . . . . . . . . 15 86 4.6.6. URL capability and XPATH capability . . . . . . . . . 15 87 5. Ephemeral Data (Background) . . . . . . . . . . . . . . . . . 15 88 5.1. Ephemeral Control Plane Datastore . . . . . . . . . . . . 16 89 5.2. Qualities of Ephemeral Datastore . . . . . . . . . . . . 17 90 5.3. I2RS Agent Caching of Ephemeral Data . . . . . . . . . . 18 91 5.4. Massive Amounts of Configuration Data . . . . . . . . . . 18 92 5.5. Write Error handling . . . . . . . . . . . . . . . . . . 19 93 5.5.1. Normal validation checks . . . . . . . . . . . . . . 19 94 5.6. IPFIX for traffic monitoring . . . . . . . . . . . . . . 20 95 5.7. Binary encoding of RESTCONF/NETCONF . . . . . . . . . . . 20 96 5.8. Ephemeral state in DDoS environments . . . . . . . . . . 20 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 100 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 102 9.1. Normative References: . . . . . . . . . . . . . . . . . . 21 103 9.2. Informative References . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 106 1. Introduction 108 This a proposal for yang additions to support the first version of 109 the I2RS protocol. 111 The I2RS architecture [RFC7921] defines the I2RS interface "a 112 programmatic interface for state transfer in and out of the Internet 113 routing system". The I2RS protocol is a protocol designed to a 114 higher level protocol comprised of a set of existing protocols which 115 have been extended to work together to support a new interface to the 116 routing system. The I2RS protocol is a "reuse" management protocol 117 which creates new management protocols by reusing existing protocols 118 and extending these protocols for new uses, and has been designed to 119 be implemented in phases [RFC7921]. 121 The first version of the I2RS protocol is comprised of extensions to 122 existing features of NETCONF [RFC6241] and RESTCONF 123 [I-D.ietf-netconf-restconf]. The data modeling language for the I2RS 124 protocol will be Yang [RFC7950] with features and extensions proposed 125 in this draft. 127 The structure of this document is: 129 Section 2 provides definitions for terms in this document. 131 Section 3 summarizes the changes to configuration data store, 132 NETCONF, RESTCONF, and YANG. 134 [I-D.ietf-i2rs-ephemeral-state] specifies the I2RS requirements 135 for the ephemeral state. Section 4 discusses how these 136 requirements might be implemented in a control plane datastore. 138 Section 5 describes the one required Yang model addition for I2RS 139 (ephemeral key word). This section also describes elements of 140 information in the NETCONF/RESTCONF implementations that must be 141 queryable by the I2RS protocol implementations. 143 2. Definitions Related to Ephemeral Configuration 145 This section reviews definitions from I2RS architecture [RFC7921] and 146 NETCONF operational state definitions 147 [I-D.nmdsdt-netmod-revised-datastores] before using these to 148 construct a definition of the ephemeral data store. 150 2.1. Requirements language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 2.2. I2RS Definitions 158 The I2RS architecture [RFC7921] defines the following terms: 160 ephemeral data: is data which does not persist across a reboot 161 (software or hardware) or a power on/off condition. Ephemeral 162 data can be configured data or data recorded from operations of 163 the router. Ephemeral configuration data also has the property 164 that a system cannot roll back to a previous ephemeral 165 configuration state. (See [RFC7921] for an architectural 166 overview, [I-D.ietf-i2rs-ephemeral-state] for requirements, and 167 [I-D.nmdsdt-netmod-revised-datastores] for discussion of how the 168 ephemeral datastore as a control plane datastore interacts with 169 intended datstore and dynamic configuration protocols to form the 170 applied datastore". 172 local configuration: is the data on a routing system which does 173 persist across a reboot (software or hardware) and a power on/off 174 condition. Local configuration has the ability to roll back to a 175 pervious configuration state. Local configuration is defined as 176 the intended datastore [I-D.nmdsdt-netmod-revised-datastores] 177 which is modified by dynamic configuration protocols (such as 178 DHCP) and the I2RS ephemeral data store 180 dynamic configuration protocols datastore are configuration 181 protocols such as DHCP that interact with the intended datastore 182 (which does persist across a reboot (software or hardware) power 183 on/off condition), and the I2RS ephemeral state control plane 184 datastore. 186 operator-applied policy: is a policy that an operator sets that 187 determines how the ephemeral datastore as a control plane data 188 store interacts with applied datastore (as defined in 189 [I-D.nmdsdt-netmod-revised-datastores]). This operator policy 190 consists of policy knobs that the operator sets to determine how 191 the I2RS agent control plane ephemeral state datastore will 192 interact with the intended configuration datastor and the dynamic 193 configuration protocol datastore. Three policy knobs could be 194 used to implement this policy: 196 * policy knob 1: I2RS Ephemeral control-plane datastore takes 197 takes precedence over the intended datastore in the routing 198 protocols. 200 * policy knob 2: Updated intended configuration datastore takes 201 precedence over the I2RS ephemeral control-plane data store in 202 the routing protocols 204 * policy knob 3: Ephemeral control plane datastore takes 205 precedence over any other dynamic configuration protocols 206 datastore. 208 An practical example for three states of the operator-applied policy 209 may help the reader understand the concept. Consider the following 210 three desired outcomes with their policy knob states: 212 Monitoring Features only The policy knob settings are: 214 Policy knob 1=false, 216 policy knob 2=true, 218 Policy knob 3=false, 220 Action: I2RS protocol software feature is installed, but the 221 operator does not want the I2RS ephemarl datastore to take 222 precedence (that is be used) on any variables in the applied 223 configuration datastore. This policy set might be valid if I2RS 224 is only suppose to monitor data on this node through newly defined 225 parameters. 227 I2RS Agent Changes win the policy knob settings would be: 229 Policy knob 1=true, 231 policy knob 2=false, 233 Policy knob 3=false, 235 Action: This is the normal case for the I2RS Agent where the 236 ephemeral control-plane datastore takes precedence over the 237 intended configuration datastore and dynamic configuration 238 datastores. The values from the I2RS ephemearl datastore are used 239 rather than the intended configuration datastore and the dynamic 240 configuration protocol datastore. When the ephemeral data is 241 removed by the I2RS agent, the dyanmic configuration datastore and 242 the intended configuration datastore state is restored, combined 243 and passed to the routing protocols for application. 245 Just change until next configuration update the policy knob settings 246 would be: 248 Policy knob 1=true, 250 policy knob 2=true, 252 Policy knob 3=false, 254 Action: This case can occur if the I2RS Client write to the 255 ephemeral control plane data store is only suppose to take 256 precedence until the next configuration cycle from a centralized 257 system. Suppose the local configuration is get by the centralized 258 system at 11:00pm each night. The I2RS Client writes temporary 259 changes to the routing system via the I2RS agent ephemeral write. 260 At 11:00pm, the local configuration update overwrite the 261 ephemeral. The I2RS Agent notifies the I2RS Client which is 262 tracking which of the ephemeral changes are being overwritten. 264 3. Overview of Changes 266 This oveview reviews the following: 268 o What NETCONF [RFC6241] protocol existing features required for 269 I2RS protocol and what extension for these extension features that 270 are needed for the I2RS protocol version 1, 272 o What RESTCONF [I-D.ietf-netconf-restconf] protocol existing 273 features are required for the I2RS protocol and what extensions 274 are needed for I2RS protocol version 1. 276 o An overview of the Yang 1.1 data modeling language[RFC7950] 277 features are needed for I2RS protocol version 1. 279 o An overview of the extensions to Yang 1.1 data modeling language 280 [RFC7950] that are needed for the I2RS protocol version 1. 282 3.1. I2RS protocol requirements 284 The requirements for the I2RS protocol are defined in the following 285 documents: 287 o I2RS Problem Statement [RFC7920], 289 o I2RS Architecture [RFC7921], 291 o I2RS Traceability [RFC7922], 293 o Publication and Subscription [RFC7923], 295 o I2RS Ephemeral State Requrements, , 296 [I-D.ietf-i2rs-ephemeral-state] 298 o I2RS Protocol Security Requirements, 299 [I-D.ietf-i2rs-protocol-security-requirements] 301 The Interface to the routing System (I2RS) creates a new capability 302 for the routing systems, and with greater capaiblities come a greater 303 need for security. The requirements for a secure environment for 304 I2RS is described in [I-D.ietf-i2rs-security-environment-reqs]. 306 3.2. NETCONF Features and Extensions 308 The features the I2RS protocol requires are: 310 o NETCONF [RFC6241] with its updates [RFC7803], 312 o Network Access Control Model [RFC6536] with update (draft-bierman- 313 netconf-rf6536bis) 315 o Running NETCONF over TLS with mutually X.509 authentication 316 [RFC7589] 318 o Keystore Model [I-D.ietf-netconf-keystore], 320 o Subscribing to Yang Datastore updates 321 [I-D.ietf-netconf-yang-push], 323 o NETCONF support for Event Notifications 324 [I-D.ietf-netconf-netconf-event-notifications], 326 o Subscribing to NETCONF Events (updated) 327 [I-D.ietf-netconf-rfc5277bis] 329 o Yang Patch Media type [I-D.ietf-netconf-yang-patch], 331 o NETCONF/RESTCONF Zero Touch provisioning 332 [I-D.ietf-netconf-zerotouch], 334 o TLS Client and Server Models [I-D.ietf-netconf-tls-client-server] 335 o Call Home [I-D.ietf-netconf-call-home], 337 o Module library [RFC7895], 339 o NETCONF/RESTCONF Zero Touch provisioning 340 [I-D.ietf-netconf-zerotouch], 342 3.3. RESTCONF features and Extensions 344 This protocol strawman utilizes the following existing proposed 345 features for NETCONF and RESTCONF 347 o RESTCONF [I-D.ietf-netconf-restconf] 349 o Module library [RFC7895], 351 o Publication/Subscription via Push [I-D.ietf-netconf-yang-push], 353 o Patch [I-D.ietf-netconf-yang-patch], 355 o syslog yang module (both [RFC5424] and 356 [I-D.ietf-netmod-syslog-model] 358 3.4. Assumptions on Data Store Model Melee 360 The NETMOD Working Group has been working to create new definitions 361 of datastores based on feedback from operators on desiring a split 362 between operational state and configuration state. 364 This document takes [I-D.nmdsdt-netmod-revised-datastores] as the 365 current status of the datastore discussion on configuration state, 366 operational state, ephemeral state changes (via I2RS), and routing 367 protocol state. The following things need to be carefully defined in 368 this work: 370 What is a dynamic configuration protocol (is it I2RS or DHCP) 372 What is a control-plane datastore - (ephemeral state only or 373 others? ) 375 How to express the policy knobs that provide preference between 376 intended configuration, control plane datstore, and dynamic 377 configuration protocols 379 How does operational state allow for operational state to be 380 defined by ephemeral-only data models, and mixed (ephemeral + 381 intended configuration) 383 [I-D.nmdsdt-netmod-revised-datastores] is making good progress, but 384 these additional details need to be tied down. 386 4. NETCONF protocol extensions for the ephemeral datastore 388 capability-name: ephemeral-datastore 390 4.1. Overview 392 This capability defines the NETCONF protocol extensions for the 393 ephemeral state. The ephemeral state has the following features: 395 o the ephemeral data store is a part of the intended configuration 396 datastore, applied configuration datastore, and the derived state 397 store whose components are not survive a reboot. 399 o The ephemeral capability is signalled as a capability of a leaf, 400 grouping, a sub-module, or module that is stored as a feature of 401 the module in the netconf yang module library ([RFC7895]) used by 402 Yang 1.1 and RESTCONF and NETCONF. 404 o ephemeral data will be noted by an "ephemeral" statement in for a 405 leaf, grouping, sub-module, or module. 407 o The ephemeral datastore is never locked. 409 o The ephemeral data store is one pane of glass that overrides the 410 local configuration (which is considered one pane of glass) in the 411 intended config based on operator-applied policy knobs (see 412 section 2.1). 414 o Ephemeral data can occur as part of protocol or protocol 415 independent modules. However, ephemeral data nodes cannot have 416 non-ephemeral data nodes within the subtree. Ephemeral sub- 417 modules cannot have non-ephemeral data nodes within the module. 418 Ephemeral modules cannot have non-ephemeral sub-modules or nodes 419 within the module. Yang 1.1 [RFC7950] augmented by ephemeral 420 state must enforce this restriction. Similarly, the Yang mount 421 schema [I-D.ietf-netmod-schema-mount] must check for this 422 restriction. 424 o Ephemeral writes should enforce the normal validation checks, 425 priority pre-emption error handling if multiple I2RS clients write 426 the same data, and "all-or-nothing" error handling for multiple 427 actions in a write for data in groupings or orthogonal data (see 428 section 3.4). The I2RS agent should send the I2RS client 429 requesting write the notification of any type of error during the 430 write process: failure of normal validation, priority pre-emption 431 causing failure to write, multiple actions causing failure to 432 sustain write (aka all-or-nothing roll-back). If the I2RS agent 433 allows a priority pre-emption of the write of data model value by 434 an I2RS client (e.g. client 1) of another I2RS client (e.g. client 435 2), then the I2RS agent must send a notification of the I2RS pre- 436 emption to the previous I2RS client (e.g. client 2). 438 o Ephemeral writes as part of an rpc should allow the rpc to skip 439 normal validation checks if data model specifies "ephemeral- 440 validation nocheck;". The rpc which skips the normal validation 441 MUST resolve the pre-emption write error handling for any data 442 being written without normal validation check, and MUST only all 443 the data within a grouping rather than orthogonal data. 445 4.2. Dependencies 447 The following are the dependencies for ephemeral support: 449 o The Yang "ephemeral definition" 451 o The following NETCONF features: 453 * NETCONF [RFC6241] with its updates [RFC7803], 455 * Network Access Control Model [RFC6536] with update by (daft- 456 bierman-netconf-rf6536bis) 458 * Running NETCONF over TLS with mutually X.509 authentication 459 [RFC7589] 461 * Keystore Model [I-D.ietf-netconf-keystore], 463 * Subscribing to Yang Datastore updates 464 [I-D.ietf-netconf-yang-push], 466 * NETCONF support for Event Notifications 467 [I-D.ietf-netconf-netconf-event-notifications], 469 * Subscribing to NETCONF Events (updated) 470 [I-D.ietf-netconf-rfc5277bis] 472 * Yang Patch Media type [I-D.ietf-netconf-yang-patch], 474 * NETCONF/RESTCONF Zero Touch provisioning 475 [I-D.ietf-netconf-zerotouch], 477 * TLS Client and Server Models 478 [I-D.ietf-netconf-tls-client-server] 480 * Call Home [I-D.ietf-netconf-call-home], 482 * Module library [RFC7895], 484 * NETCONF/RESTCONF Zero Touch provisioning 485 [I-D.ietf-netconf-zerotouch], 487 4.3. Capability identifier 489 The ephemeral-datastore capability is identified by the following 490 capability string: (capability uri) 492 4.4. New Operations 494 None 496 4.5. Modification to existing operations 498 The capability for :ephemeral-datastore modifies the target for 499 existing operations. 501 4.5.1. 503 The :ephemeral-datastore capability modifies the to 504 accept the as a target for source, and allows the filters 505 focused on a particular module, submodule, or node. 507 The positive and negative responses remain the same. 509 Example - retrieve users subtree from 510 ephemeral database 512 514 515 516 517 518 519 520 521 522 523 524 526 4.5.2. 528 The :ephemeral-datastore capability modifies the to 529 accept the as a target for source with filters. The 530 operations of merge, replace, create, delete, and remove are 531 available, but each of these operations is modified by the priority 532 write as follows: 534 parameter is replaced by The current data 535 is modified by the new data in a merge fashion only if existing 536 data either does not exist, or is owned by a lower priority 537 client. If any data is replaced, this event is passed to the 538 notification function within the pub/sub and traceability. 540 is replaced by for ephemeral 541 datastore which replaces data if the existing data is owned by a 542 lower priority client. If data any data is replaced, this event 543 is passed to the notification function within pub/sub and 544 traceability for notification to the previous client. The success 545 or failure of the event is passed to traceabilty. 547 - the creation of the data node works as in [RFC6241] 548 except that the success or failure is passed to pub/sub and 549 traceability functions. 551 - the deletion of the data node works as in [RFC6241] 552 except event that the success or the error event is passed to the 553 notiication services in the pub/sub and traceability functions. 555 - the remove of the data node works as in [RFC6241] 556 except that all results are forwarded to traceabilty. 558 The existing parameters are modified as follows: 560 - add a target of :emphemeral-datastore 562 -allows only or 565 - the I2RS agent agent supports only the a"all-or- 566 nothing" equivalent to a "rollback-on-error" function. 568 positive response - the is sent for a positive response 569 within an . 571 negative response - the is sent for a negative 572 response within an . Note a negative respones may 573 evoke a publication of an event. 575 4.5.3. 577 Copy config allows for the complete replacement of all the ephemeral 578 nodes within a target. The alternation is that source is the 579 :ephemeral datastore with the filtering to match the datastore. The 580 following existing parameters are modified as follows: 582 - add a target of :emphemeral-datastore 584 - the I2RS agent agent supports only the a"all-or- 585 nothing" equivalent to a "rollback-on-error" function. 587 positive response - the is sent for a positive response 588 within an . 590 negative response - the is sent for a negative 591 response within an . 593 4.5.4. 595 The delete will delete all ephemeral nodes out of a datastore. The 596 target parameter must be changed to allow :ephemeral-datastore. and 597 filters. 599 4.5.5. and 601 Lock and unlock are not supported with a target of :ephemeral- 602 datastore. 604 4.5.6. 606 The is altered to allow a target of :ephemeral-datastore and 607 with the filters. 609 4.5.7. and 611 The close session is modified to take a target of :ephemeral- 612 datastore, Since no locks are set, none should be released. 614 The kill session is modified to take a target of "ephemeral- 615 datastore. Since no locks are set, none should be released. 617 4.6. Interactions with Capabilities 619 [RFC6241] defines NETCONF capabilities for writeable-running 620 datastore, candidate config data store, confirmed commit, rollback- 621 on-error, validate, distinct start-up, URL capability, and XPATH 622 capability. I2RS ephemeral state does not impact the writeable- 623 running data store or the candiate config datastore. 625 4.6.1. writable-running and candidate datastore 627 The writeable-running and the candidate datastore cannot be used in 628 conjunction with the ephemeral data store. Ephemeral database 629 overlays an intended configuration, and does not impact the writable- 630 running or candidate data store. 632 4.6.2. confirmed commmit 634 Confirmed commit capability is not supported for the ephemeral 635 datastore. 637 4.6.3. rollback-on-error 639 The rollback-on-error when included with ephemeral state allows the 640 error handling to be "all-or-nothing" (roll-back-on-error). 642 4.6.4. validate 644 The validation function operates normally with one addition with one 645 addition for any data handled by an rpc with "ephemeral-validation 646 nocheck". 648 The rpc specifying ephemeral-validation nocheck MUST specify within 649 the ephemeral data written by the rpc function the following 650 grouping: 652 grouping ephemeral-validation-notcheck { 653 leaf rpc { 654 type string rpc-id; 655 description "rpc wrote 656 the non-check data"; 657 } 658 leaf rpc-seq { 659 type uint32 rpc-id; 660 description "sequence number of 661 rpc that wrote non-check data"; 662 } 663 leaf client-id { 664 type uint64 client-id; 665 description "client identifier 666 that wrote non-checking rpc;" 667 } 668 description "Tracking on rpc with 669 no validation checking so validation 670 failure can send note to client."; 671 }; 673 If the data validation finds an error in a component that was non- 674 check, the notification should include the data module, submodule (if 675 valid). 677 (Editor's note: Initial experiments on this type of rpc for I2RS RIB 678 routes and I2RS FB-RIB filters will be done before IETF 96. 680 4.6.5. Distinct Startup Capability 682 This NETCONF capability appears to operate to load write-able running 683 config, running-config, or candidate datastore. The ephemeral state 684 does not change the environment based on this command. 686 4.6.6. URL capability and XPATH capability 688 The URL capabilities specify a in the and . 689 The initial suggestion to allow both of these features to work with 690 ephemeral datastore. 692 5. Ephemeral Data (Background) 694 Note: This section probably goes with the definition of ephemeral 695 state or as its own Draft 697 This section provides an overview of the ephemeral data store as a 698 control plane datastore and discusses several concepts that 699 implementers need to consider and provide feedback on. The concepts 700 include basic ephemeral datastore concepts, I2RS caching of ephemeral 701 data, issues for massive data flow, error handling (normal and 702 reduced), use of IPFIX or Binary for carrying I2RS ephemeral data, 703 and ephemeral state 705 This section augments [I-D.nmdsdt-netmod-revised-datastores] to begin 706 to discuss how the ephemeral state comtrol-plane datastore might be 707 implemented. The purpose of this section is to gather implementer 708 wisdom on the ephemeral datastore into one place. This section 709 discusses: 711 Ephemeral state as a control plane data store 713 Qualities of ephemeral datastores 715 Need to support Massive amounts of configuration data, 717 Two types of Error handling (regular, reduced) 719 Should we support link to IPFIX in I2RS protocol and ephemeral 720 state? 722 Binary encoding for RESTCONF/NETCONF 724 Ephemeral state in DDoS environments. 726 [I-D.ietf-i2rs-ephemeral-state] describes the requirements for I2RS 727 ephemeral state. 729 This section augments [I-D.nmdsdt-netmod-revised-datastores] to begin 730 to discuss how the ephemeral state comtrol-plane datastore might be 731 implemented. This initial draft refines the general description so 732 that early I2RS ephemeral state implementations may progress. 734 5.1. Ephemeral Control Plane Datastore 736 [I-D.nmdsdt-netmod-revised-datastores] architecture suggests that the 737 applied configuration is the combination of intended datastore, the 738 dynamic configuration protocols, and the control-plane datastores. 739 As described above, there are policy knobs which allow the I2RS Agent 740 to handle deciding what specific configuration variables is installed 741 in protocols (E.g BGP) or protocol independent functions (RIB or 742 Filters). In addition, the control-plane datastore may store the 743 parameters need to provide publication of events, statistics, 744 telementry within the ephemeral control-plane datastore. 746 The ephemeral data-store may have models which learn operational 747 state and augment it by configuration. For example 748 [I-D.ietf-i2rs-yang-l3-topology] uploads ospf and isis topology 749 information from the routing system and allows configuration of 750 additional links or nodes. 752 This new architecture is a multiple panes-of-glass model where the 753 decision on what value is chosen is based on policy. The extension 754 of this model is that it is possible for two or more of the control- 755 plane datastores to be ephemeral. If this occurs, then the policy 756 knobs must define the how the 2+ ephemeral datastores interact with 757 each other and the configuration state. 759 5.2. Qualities of Ephemeral Datastore 761 Note: The requirements for ephemeral state are in: 762 [I-D.ietf-i2rs-ephemeral-state]). 764 This section provides a discussion so that implementers writing code 765 for these datastores can discuss what needs to be standardized and 766 what does not need to be standardized. 768 The ephemeral data store has the following general qualities: 770 1. Ephemeral state is not unique to I2RS work. 772 2. The ephemeral datastore is never locked. 774 3. The ephemeral portion of the intended configuration, applied 775 state, and derived state does not persist over a reboot, 777 4. an ephemeral node cannot roll-back to its previous value, 779 5. Since ephemeral data store is just data that does not presist 780 over a reboot, then in theory any node or group of nodes in a 781 YANG data model could be ephemeral. The YANG data module must 782 indicate what portion of the data model (if any) is ephemeral. 784 * A YANG data module could be all ephemeral (e.g. 785 [I-D.ietf-i2rs-rib-data-model]) with no directly associated 786 configuration models, 788 * A YANG model could be all ephemeral but associated with a 789 configuration model 791 * or a single data node or data tree could be made ephemeral. 793 6. The management protocol (NETCONF/RESTCONF) needs to signal which 794 poritons of a data model(node, tree, or data model) are ephemeral 795 in the module library [RFC7895]. 797 5.3. I2RS Agent Caching of Ephemeral Data 799 The multiple control-plane datastore model 800 [I-D.nmdsdt-netmod-revised-datastores] architecture allows multiple 801 datastores which could allow an implementation of caching of 802 ephemeral data in the I2RS Agent by having a main and a backup I2RS 803 agent. Early implementations should at least support the single 804 ephemeral data model, but MAY support the multiple datastore mode. 805 It is important that these early implementations provide feedback for 806 standardization on the following: 808 the policy knobs needed to make single ephemeral control planes 809 datastores function, 811 the policy knobs neeed to make multiple ephemeral control plane 812 datastores which support caching work. 814 5.4. Massive Amounts of Configuration Data 816 Large amounts of data can flow from the I2RS agent to the I2RS 817 client, or from the I2RS client to the I2RS Agent. The I2RS client 818 may set or query ephemeral configuration in the routing system via 819 the I2RS agent and receive operational state, notifications, or 820 logging from the I2RS Agent on behalf of the I2RS routing system. 821 I2RS Clients can send large amount of ephemeral configuration data to 822 the I2RS Agent. The writes may be done via NETCONF ( or 823 an rpc function), or via RESTCONF (PUT, PATCH, POST). Reads can be 824 done via NETCONF or RESTCONF GET or query. 826 The I2RS RIB Data Model [I-D.ietf-i2rs-rib-data-model] also supports 827 the use of rpc to add/delete RIBs, add/delete/update routes, and add/ 828 delete nexthops. If the I2RS client does a small to medium number of 829 writes to the I2RS ephemeral state in the I2RS Agent in a routing 830 system, the full validation that NETCONF or RESTCONF does will be 831 able to be done without any reduction in speed to the I2RS high- 832 performance system. For example, if the I2RS RIB Data Model has adds 833 a 1000 routes, the I2RS RIB use of rpc to add/delete/update routes 834 should be able to provide a high-performance system. Alternatively 835 the NETCONF could update these 1000 routes with a 836 write, or the RESTCONF POST, PUT or PATCH should be able to add the 837 1000 routes. 839 If a large number of ephemeral routes or filters are written (updates 840 or new) by the I2RS Client to the ephemeral state in the I2RS agent, 841 one of the key issues for a high performance interface is the time it 842 takes to validate routes. Due to this concern, the I2RS architecture 843 was design to allow less than the full NETCONF or RESTCONF 844 validation. The concept is that the I2RS routes would be validated 845 within the I2RS client and sent via a 99.999% reliable connection. 846 In this scenario, the I2RS Agent would trust the validation that the 847 I2RS Client did, and the communication of the route additions via the 848 network connection. 850 An experiment regarding this has been done with the ODL code base 851 update of ephemeral routes, but additional experimentation needs to 852 be done prior to finalizing this design. Section 3.4.2 reviews how 853 this process might be done, but many open issues exist in 854 implementing this "low-validation" interface. Without additional 855 experimentation and prototype code, this type of "low-validation", 857 5.5. Write Error handling 859 This section reviews I2RS normal error handling and error handling 860 for rpc with no validation checks. 862 5.5.1. Normal validation checks 864 An I2RS agent validates an I2RS client's information by examining the 865 following: 867 o message syntax validation, 869 o syntax validation for nodes of data model, 871 o referential checks (leafref checks MUST clauses, and instance 872 indentifier), 874 o checks groups of data within a data model or groups of data across 875 data models, 877 o write access to data, 879 o if write access and values already exist, if I2RS client write 880 access is higher than existing priority. 882 5.5.1.1. Reduced Validation (Experimental) 884 Can the I2RS protocol allow for reduced error checking? The need for 885 speed in the I2RS protocol insertions in to the I2RS RIB suggest that 886 it is worth experimenting for reduced validation in order to obtain 887 high levels of throughput. If NETCONF or RESTCONf streams pre- 888 checked routes to the datastore, what happens? Implementation 889 experience is needed to determine the feasibility of this approach. 891 This feature may require a operator-applied policy knob swith a "no 892 validation" feature 894 o operator-applied policy knob enabling this feature; 896 o rpc in a data model with the yang "ephemeral-validation no-check;" 898 5.6. IPFIX for traffic monitoring 900 Due to the potentially large data flow the traffic measurment 901 statistics generate, these statistics are best handled by publication 902 techniques within NETCONF or a separate protocol such as IPFIX. In 903 the future version of the I2RS protocol may desire to support a data 904 stream outbound from the I2RS Agent to an I2RS client via the IPFIX 905 protocol. 907 5.7. Binary encoding of RESTCONF/NETCONF 909 The binary encoding of JSON or XML encodnig in RESTCONF or NETCONF 910 may provide a better throughput. Research needs to be done on what 911 is the appropriate binary encoding. 913 5.8. Ephemeral state in DDoS environments 915 I2RS ephemeral state may operate in places where there is a DDoS 916 attacks where the network devices are attacked. Is one attack plane 917 the ability to remove all tracing if the I2RS reboots an attack 918 vector? 920 6. IANA Considerations 922 This is a protocol strawman - nothing is going to IANA. 924 7. Security Considerations 926 The security requirements for the I2RS protocol are covered in 927 [I-D.ietf-i2rs-protocol-security-requirements]. The security 928 environment the I2RS protocol is covered in 929 [I-D.ietf-i2rs-security-environment-reqs]. Any person implementing 930 or deploying the I2RS protocol should consider both security 931 requirements. 933 8. Acknowledgements 935 TBD 937 9. References 939 9.1. Normative References: 941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 942 Requirement Levels", BCP 14, RFC 2119, 943 DOI 10.17487/RFC2119, March 1997, 944 . 946 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 947 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 948 June 2005, . 950 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 951 RFC 4960, DOI 10.17487/RFC4960, September 2007, 952 . 954 [RFC5339] Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation 955 of Existing GMPLS Protocols against Multi-Layer and Multi- 956 Region Networks (MLN/MRN)", RFC 5339, 957 DOI 10.17487/RFC5339, September 2008, 958 . 960 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 961 DOI 10.17487/RFC5424, March 2009, 962 . 964 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 965 the Network Configuration Protocol (NETCONF)", RFC 6020, 966 DOI 10.17487/RFC6020, October 2010, 967 . 969 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 970 and A. Bierman, Ed., "Network Configuration Protocol 971 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 972 . 974 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 975 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 976 . 978 [RFC6244] Shafer, P., "An Architecture for Network Management Using 979 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 980 2011, . 982 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 983 Protocol (NETCONF) Access Control Model", RFC 6536, 984 DOI 10.17487/RFC6536, March 2012, 985 . 987 [RFC7158] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 988 Interchange Format", RFC 7158, DOI 10.17487/RFC7158, March 989 2014, . 991 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 992 NETCONF Protocol over Transport Layer Security (TLS) with 993 Mutual X.509 Authentication", RFC 7589, 994 DOI 10.17487/RFC7589, June 2015, 995 . 997 [RFC7803] Leiba, B., "Changing the Registration Policy for the 998 NETCONF Capability URNs Registry", BCP 203, RFC 7803, 999 DOI 10.17487/RFC7803, February 2016, 1000 . 1002 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 1003 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 1004 . 1006 [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem 1007 Statement for the Interface to the Routing System", 1008 RFC 7920, DOI 10.17487/RFC7920, June 2016, 1009 . 1011 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1012 Nadeau, "An Architecture for the Interface to the Routing 1013 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 1014 . 1016 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1017 the Routing System (I2RS) Traceability: Framework and 1018 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 1019 2016, . 1021 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 1022 for Subscription to YANG Datastores", RFC 7923, 1023 DOI 10.17487/RFC7923, June 2016, 1024 . 1026 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1027 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1028 . 1030 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1031 RFC 7952, DOI 10.17487/RFC7952, August 2016, 1032 . 1034 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, 1035 "DNSSEC Trust Anchor Publication for the Root Zone", 1036 RFC 7958, DOI 10.17487/RFC7958, August 2016, 1037 . 1039 9.2. Informative References 1041 [I-D.ietf-i2rs-ephemeral-state] 1042 Haas, J. and S. Hares, "I2RS Ephemeral State 1043 Requirements", draft-ietf-i2rs-ephemeral-state-22 (work in 1044 progress), November 2016. 1046 [I-D.ietf-i2rs-protocol-security-requirements] 1047 Hares, S., Migault, D., and J. Halpern, "I2RS Security 1048 Related Requirements", draft-ietf-i2rs-protocol-security- 1049 requirements-17 (work in progress), September 2016. 1051 [I-D.ietf-i2rs-rib-data-model] 1052 Wang, L., Ananthakrishnan, H., Chen, M., 1053 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 1054 YANG Data Model for Routing Information Base (RIB)", 1055 draft-ietf-i2rs-rib-data-model-06 (work in progress), July 1056 2016. 1058 [I-D.ietf-i2rs-rib-info-model] 1059 Bahadur, N., Kini, S., and J. Medved, "Routing Information 1060 Base Info Model", draft-ietf-i2rs-rib-info-model-09 (work 1061 in progress), July 2016. 1063 [I-D.ietf-i2rs-security-environment-reqs] 1064 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 1065 Security Requirements", draft-ietf-i2rs-security- 1066 environment-reqs-01 (work in progress), April 2016. 1068 [I-D.ietf-i2rs-yang-l3-topology] 1069 Clemm, A., Medved, J., Varga, R., Tkacik, T., Liu, X., 1070 Bryskin, I., Guo, A., Ananthakrishnan, H., Bahadur, N., 1071 and V. Beeram, "A YANG Data Model for Layer 3 Topologies", 1072 draft-ietf-i2rs-yang-l3-topology-04 (work in progress), 1073 September 2016. 1075 [I-D.ietf-netconf-call-home] 1076 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1077 draft-ietf-netconf-call-home-17 (work in progress), 1078 December 2015. 1080 [I-D.ietf-netconf-keystore] 1081 Watsen, K. and G. Wu, "Keystore Model", draft-ietf- 1082 netconf-keystore-00 (work in progress), October 2016. 1084 [I-D.ietf-netconf-netconf-event-notifications] 1085 Prieto, A., Clemm, A., Voit, E., Nilsen-Nygaard, E., 1086 Tripathy, A., Chisholm, S., and H. Trevino, "NETCONF 1087 Support for Event Notifications", draft-ietf-netconf- 1088 netconf-event-notifications-01 (work in progress), October 1089 2016. 1091 [I-D.ietf-netconf-restconf] 1092 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1093 Protocol", draft-ietf-netconf-restconf-18 (work in 1094 progress), October 2016. 1096 [I-D.ietf-netconf-rfc5277bis] 1097 Clemm, A., Prieto, A., Voit, E., Nilsen-Nygaard, E., 1098 Tripathy, A., Chisholm, S., and H. Trevino, "Subscribing 1099 to Event Notifications", draft-ietf-netconf-rfc5277bis-01 1100 (work in progress), October 2016. 1102 [I-D.ietf-netconf-tls-client-server] 1103 Watsen, K., "TLS Client and Server Models", draft-ietf- 1104 netconf-tls-client-server-01 (work in progress), November 1105 2016. 1107 [I-D.ietf-netconf-yang-patch] 1108 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 1109 Media Type", draft-ietf-netconf-yang-patch-13 (work in 1110 progress), November 2016. 1112 [I-D.ietf-netconf-yang-push] 1113 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1114 Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to 1115 YANG datastore push updates", draft-ietf-netconf-yang- 1116 push-04 (work in progress), October 2016. 1118 [I-D.ietf-netconf-zerotouch] 1119 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 1120 for NETCONF or RESTCONF based Management", draft-ietf- 1121 netconf-zerotouch-11 (work in progress), October 2016. 1123 [I-D.ietf-netmod-schema-mount] 1124 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 1125 ietf-netmod-schema-mount-03 (work in progress), October 1126 2016. 1128 [I-D.ietf-netmod-syslog-model] 1129 Wildes, C. and K. Koushik, "A YANG Data Model for Syslog 1130 Configuration", draft-ietf-netmod-syslog-model-11 (work in 1131 progress), November 2016. 1133 [I-D.nmdsdt-netmod-revised-datastores] 1134 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1135 and R. Wilton, "A Revised Conceptual Model for YANG 1136 Datastores", draft-nmdsdt-netmod-revised-datastores-00 1137 (work in progress), October 2016. 1139 Authors' Addresses 1141 Susan Hares 1142 Huawei 1143 Saline 1144 US 1146 Email: shares@ndzh.com 1148 Amit Daas 1149 Ericsson 1151 Email: amit.dass@ericsson.com