One document matched: draft-hares-i2rs-protocol-strawman-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY RFC6536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6536.xml">
<!ENTITY RFC7158 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7158.xml">
<!ENTITY RFC7589 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7589.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-i2rs-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-data-model.xml">
<!ENTITY I-D.ietf-i2rs-traceability SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-traceability.xml">
<!ENTITY I-D.ietf-i2rs-ephemeral-state SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-ephemeral-state.xml">
<!ENTITY I-D.ietf-i2rs-usecase-reqs-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-usecase-reqs-summary.xml">
<!ENTITY I-D.ietf-i2rs-pub-sub-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-pub-sub-requirements.xml">
<!ENTITY I-D.ietf-i2rs-protocol-security-requirements
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-protocol-security-requirements.xml">
<!ENTITY I-D.ietf-i2rs-security-environment-reqs
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-security-environment-reqs.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf.xml">
<!ENTITY I-D.ietf-netconf-yang-patch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-yang-patch.xml">
<!ENTITY I-D.ietf-netconf-yang-push SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-yang-push.xml">
<!ENTITY I-D.ietf-netconf-yang-library SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-yang-library.xml">
<!ENTITY I-D.ietf-netmod-opstate-reqs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-opstate-reqs.xml">
<!ENTITY I-D.ietf-netmod-yang-metadata SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-yang-metadata.xml">
<!ENTITY I-D.hares-i2rs-dataflow-req SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-dataflow-req.xml">
<!ENTITY I-D.hares-i2nsf-mgtflow-reqs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2nsf-mgtflow-reqs.xml">
<!ENTITY I-D.hares-i2rs-bgp-dm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-bgp-dm.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-i2rs-protocol-strawman-01.txt" ipr="trust200902">
<front>
<title abbrev="I2RS Protocol Strawman">I2RS protocol strawman</title>
<author fullname="Susan Hares" initials="S." surname="Hares">
<organization> Huawei </organization>
<address>
<postal>
<street></street>
<city>Saline</city>
<country>US</country>
</postal>
<email>shares@ndzh.com </email>
</address>
</author>
<author fullname="Andy Bierman" initials="A." surname="Beirman">
<organization>YumaWorks</organization>
<address>
<postal>
<street></street>
<city> </city>
<country></country>
</postal>
<email>andy@yumaworks.com </email>
</address>
</author>
<author fullname="Amit Daas" initials="A." surname="Dass">
<organization> Ericsson </organization>
<address>
<email>amit.dass@ericsson.com</email>
</address>
</author>
<date year="2016" />
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t>This document provides a strawman proposal for the I2RS protocol covering
the ephemeral data store and data flow requirements not covered by I2RS
publication/subscription service or traceability. It also proposes
additions to YANG for the ephemeral data store and for additional
data flow requirements. It proposes additions to the NETCONF
and RESTCONF for these additions. Future versions of this document
will propose changes to support the I2RS protocol security requirements.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This documents is a strawman for I2RS higher level protocol.
The I2RS protocol is a higher level protocol comprised of a set existing protocols
which have been extended to work together to support a new interface to the routing system.
Some people are suggesting only two protocols should be defined: NETCONF <xref target="RFC6241"></xref>,
and RESTCONF <xref target="I-D.ietf-netconf-restconf"></xref>. Others are suggesting
we should include other data protocols.
</t>
<t>This draft is input to a NETCONF review and design team.
Many items have been settled on. Some items are in debate and those
titles of those sections are marked.
</t>
<t>
This strawman proposal for the I2RS protocol covers
the ephemeral data store and data flow requirements not covered by I2RS
publication/subscription service or traceability. It also proposes
additions to YANG for the ephemeral data store and for these additional
data flow requirements. It also proposes extensions to NETCONF
and RESTCONF to support ephemeral state and I2RS.
</t>
<t> draft-hares-i2rs-protocol-strawman-examples (pending)
provides examples of this strawman protocol use for I2RS. This
draft uses a simple thermostat model to illustrate commands.
</t>
<section title="Ephemeral Changes">
<t>
This document proposes additions to support ephemeral state in the
datastores supported by NETCONF and RESTCONF, and in the YANG modules
that define these data stores. The requirements for the I2RS ephemeral
state are covered in <xref target="I-D.ietf-i2rs-ephemeral-state"></xref>
</t>
<t> This draft provides suggests the following additions to support the I2RS ephemeral state:
<list style="symbols">
<t>Yang ephemeral statement,</t>
<t>NETCONF (<xref target="RFC6241"></xref>) protocol extensions for the ephemeral data store,</t>
<t>RESTCONF (<xref target="I-D.ietf-netconf-restconf"></xref>) protocol extensions for the ephemeral data store </t>
</list>
</t>
</section>
<section title="Data Flow Changes">
<t> This document proposes additions to support data flows from
different data models for large data flows, traffic monitoring, actions and OAM interaction,
and flows during outages or attacks. The requirements for these changes are
define in <xref target="I-D.hares-i2rs-dataflow-req"></xref>.
</t>
<t>Most large data flows will be handled utilizing the publication/subscription service
define in the I2RS publication/subscription service requirements specified in
<xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref>. Extensions to
NETCONF to support a push publication/subscription service have been defined in
<xref target="I-D.ietf-netconf-yang-push"></xref>.
This document does not propose a pull publication/subscription (pull pub-sub) service for the first
set of component protocols for the I2RS higher level protocol. If deployments require
the pull pub-sub service, then an expansion of the push service can provide
one mechanism.
</t>
<t> This document does provide support for the I2RS protocol to:
<list>
<t> Support large data transfers in a data agnostic format (DF-REQ-02) supporting transfers
of data in any format (E.g. XML, JSON, MTL, protobuf, ASCII) over any transport (DF-REQ-03).
</t>
<t>Support the use of IPFIX as a component protocol to send traffic monitoring data or
any type of large data flow from I2RS agent to I2RS client (DF-REQ-04),
</t>
<t>Support exporting traffic statistics for filter-based policy usage (BGP-FS, I2RS FB-FIB,
policy routing), IPPM, SFLOW and other traffic statistics using either yang models or
IPFIX template formats over any data encapsulation format over any transport (DF-REQ-05).
</t>
</list>
</t>
</section>
</section>
<section title="Definitions Related to Ephemeral Configuration">
<t>
Currently the configuration systems managed by NETCONF (<xref target="RFC6241"></xref>) or
RESTCONF (<xref target="I-D.ietf-netconf-restconf"></xref>) have three
types of configuration: candidate, running, and startup running under the config=true flag.
<list style="symbols">
<t>The candidate receives configuration changes from NETCONF/RESTCONF.</t>
<t>The running configuration is the configuration currently operating on a devices </t>
<t>The start-up configuration is the configuration that survives a reboot. </t>
</list>
</t>
<t>
The config=false flag has operational data which exists alongside the config=true data.
However, at this point there is no datastored defined for configuration false.
</t>
<t>
<figure>
<artwork>
........... ........... ...........
:Candidate : --> : running : --> :start-up :
........... ........... ...........
config true
---------------------------------------------
config false
Figure 1
</artwork>
</figure>
</t>
<t>
The <xref target="I-D.ietf-netmod-opstate-reqs"></xref>
defines new terms to clarify how this works.
In reality, the running configuration becomes the intended
configuration that is intended to be loaded into a device.
The loading of the update into the system can be
either asynchronous or synchronous.
In the asynchronous case, the NETCONF server responds to the client
after the intended has been updated, but the applied
configuration is only updated later when the configuration
change has full impacted all components on the device.
The synchronous configuration operation occurs when
both the intent configuration has been updated and the
actual configuration has been loaded after resolving
the necessary things to load in a box.
</t>
<t>
This document will use the terms defined in
<xref target="I-D.ietf-netmod-opstate-reqs"></xref>.
</t>
<t>
<figure>
<artwork>
........... ........... ...........
:Candidate : --> : running : --> :start-up :
........... ......||... ...........
||
=======||========
| Intended |
| configuration |
======||=========
config true ||
----------------------||-------------------
config false ||
+----------------||------+
| operational || |
| state || |
| =========||== |
| | Applied | |
| | config | |
| ============= |
| _____________ |
| | derived | |
| | state | |
| |___________| |
+------------------------+
Figure 2
</artwork>
</figure>
</t>
</section>
<section title="Definition of ephemeral datastore for NETCONF/RESTCONF">
<t>
This section describes the properties of the ephemeral datastore.
The ephemeral datastore is not unique to I2RS. This approach to the
ephemeral datastore is a panes-of-glass model. This definition of
I2RS does not support caching in the I2RS Agents. Future I2RS
work may reconsidered supporting caching.
</t>
<t>
<figure>
<artwork>
............ ............... ...........
:Candidate :-->: running :-->:start-up :
............ ..|............ ...........
:ephemeral : |
|
|
===========|====================
| Intended Ephemeral |==[I2RS Agent]
| configuration Intended | asynchronous/
| Configuration| synchronous write
|===========||==================
||
config true ||
-------------------||----------------------
config false ||
||
+-------------||--------------------+
| operational || |
| state || |
| ======||=================== |
| | Applied Configuration | |
| |(from normal + ephemeral)| |
| | | |
| ========================== |
| _________________________ |
| | derived state | |
| |from normal + ephemeral)| |
| | RIB and protocols | |
| |________________________| |
+-----------------------------------+
Figure 3
</artwork>
</figure>
</t>
<t>
The ephemeral data store has the following qualities:
<list style="numbers">
<t> Ephemeral state is not unique to I2RS work.</t>
<t>The ephemeral datastore is never locked.
</t>
<t> The ephemeral datastore is really a portion
of the intended configuration that does not persist over a reboot.
<list style="symbols">
<t>Since Ephemeral is just about data not presisting over a reboot, then
in theory any node or group of nodes in a YANG data model could be ephemeral.
The YANG data module must indicate what portion of the data model (if any)
is ephemeral.
</t>
<t>A YANG data module could be all ephemeral (e.g. <xref target="I-D.ietf-i2rs-rib-data-model"></xref>)
with no directly associated configuration models,
</t>
<t>A YANG model could be all ephemeral but associated with a configuration model
(E.g. <xref target="I-D.hares-i2rs-bgp-dm"></xref>,</t>
<t>or a single data node or data tree could be made ephemeral.</t>
</list>
</t>
<t>The applied configuration is the result of the
the intent configuration (normal and ephemeral). Similarly,
the derived data is a result of the applied configuration.
</t>
<t>Ephemeral portions (node, tree, or data model) need to be
signalled in the conformance portions of the
NETCONF and RESTCONF work. Conformance is signalled in the following ways:
<list style="symbols">
<t>The conformance portion of NETCONF (<xref target="RFC6241"></xref>) is currently
signalled in the <hello>. </t>
<t>Yang 1.1 and RESTCONF uses the module library (<xref target="I-D.ietf-netconf-yang-library"></xref>)
</t>
<t>NETCONF may use the module library in the future.
</t>
<t> The ephemeral status in a module will be listed as "all, none or partial". Optionally
the module may provide a list of nodes.
</t>
</list>
</t>
<t>The ephemeral data store is treated as one pane of glass that an I2RS client(s) may read/write which
has the following implications:
<list style="symbols">
<t> The ephemeral datastore overlays the configuration datastore at the
intended configuration. By overlays, the I2RS write overwrites a previous configuration value, but
if a local configuration value changes after that over-write the default
is to have the local-config win. [aka Last Write wins.]
<list>
<t>An example may help to illustrate this default rule. Say a configuration
specifies a local route of 128.2/16 with a nexthop of
192.5.10.1. Afterwards an ephemeral route is added for 128.2/16 with nexthop of 192.5.10.2.
This ephemeral route would replace the first route. If the configuration changes the underlying
route (128.2/16 with nexthop of 192.5.10.1) and the default rule of local configuration is
in effect, the local configuration value (128.2/16 with nexthop of 192.5.10.1) would take effect.
This follows the normal netconf concept that Last configured wins. The I2RS agent
would notify the I2RS Client that the ephemeral route (128.2/16 with nexthop of 192.5.10.2) had been
overwritten by the local configuration.
</t>
</list>
</t>
<t>The default of local can be changed by operator-applied policy to allow
ephemeral to always win or local configuration to always win, but the
status of the operator applied policy must be queryable in the I2RS agent
(if that scope) or in the I2RS ephemeral data model.
I2RS clients are required to understand and handle if the
an I2RS agent supports something different than the default (aka Last write wins).
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Error handling">
<t>This section will go over I2RS normal error handling,
error handling when multiple I2RS clients write to the same node,
and suggested alterations to the validation process for nodes.
</t>
<t>Editor's note: The requirement for alterations to validation
needs to be confirmed.
</t>
<section title="Error handling: I2RS Normal handling ">
<t>
Normal error handling of I2RS Agent for an I2RS client's information examines the following:
<list style="symbols">
<t>message syntax validation, </t>
<t>syntax validation for nodes of data model,</t>
<t>removes referential requirements for leafref checking,
MUST clauses, and instance indentifier, </t>
<t>grouping of data within a data model or across data models
to accomplish tasks,</t>
<t>permission to write nodes of data model, </t>
<t>grouping, </t>
<t>priority to write nodes of data model being higher than
existing priority</t>
</list>
</t>
<t>
The full error handling status includes all
checks included for any normal YANG data module
used by NETCONF/RESTCONF. This includes referential
checks for leafref checks, MUST clauses, and instance identifiers.
</t>
<t>
If the I2RS protocol allows agents to set permissible range of error handling for writes
on a data model (none, I2RS normal, full), then those stating
this requirement want to be able to change this with
operator-applied settings (e.g. always request full validation).
</t>
</section>
<section title="Error Handling: Multiple I2RS Clients Write Same Node">
<t>Multiple I2RS clients writing to the same variable
is considered an "error condition" in the I2RS architecture
<xref target="I-D.ietf-i2rs-architecture"></xref>, but
the I2RS Agent must handle this error condition.
Upon multiple I2RS clients writing, the ephemeral data store
allows for priority pre-emption of the write operation.
Priority pre-emption means each I2RS client of the
ephemeral I2RS agent (netconf server) is associated with a priority.
Priority pre-emption occurs when a I2RS client with a higher priority
writes a node which has been written by an I2RS client (with the lower priority).
At this point, the I2RS agent (netconf server) allows the write and
provides a notification indication to the notification publication/subscription
service.
</t>
</section>
<section title="Error handling: Basic Impact on functions">
<section title="Initial Support of Parital Writes">
<t>The initial releases of I2RS will only require "all-or-nothing"
in the I2RS Agent. </t>
<section title="NETCONF Support of Partial Writes">
<t>NETCONF does not support a mandated sequencing of
edit functions or write functions. Without this
mandated sequences, NETCONF cannot support partial edits.
</t>
</section>
<section title="RESTCONF Support of Partial Writes">
<t>RESTCONF has a complete set of operations per message.
The RESTCONF patch can support write functions per messages. </t>
</section>
</section>
<section title="Future Scope of multiple message writes">
<t>
Error handling on writes of the ephemeral datastore is different for nodes
that are grouped versus orthogonal. Group nodes may need to be all changed
or all removed (all-or-nothing). In contrast, writing orthogonal data nodes
in the same data module or between data models need to be added or deleted in sync.
</t>
<t>
The <xref target="I-D.ietf-i2rs-architecture"></xref> specifies three types
of error handling for a partial write operation: "all-or-nothing",
"stop-on-error", or "continue-on-error". Partial write operations
of "stop-on-error" or "continue-on-error" are allowed only for data writes
which are not a part of a grouping within a data model.
The definition of the I2RS error conditions are:
<list style="symbols">
<t>stop-on-error - means that the configuration process stops when a write
to the configuration detects an error due to write conflict.</t>
<t>continue-on-error - means the configuration process continues when a
write to the configuration detects an error due to write process, and
error reports are transmitted back to the client writing the error. </t>
<t>all-or-nothing - means that all of the configuration process is
correctly applied or no configuration process is applied.
(Inherent in all-or-nothing is the concept of checking all changes
before applying.)</t>
</list>
</t>
</section>
<section title="Grouping and Error handling">
<t>Yang 1.0 and Yang 1.1 provide the ability to group data in
groupings, leafref lists, lists, and containers. Grouping of
data within a model links to data that is logically associated with one another.
Data models may logical group data across models. One example of such an association
is the association of a static route with an interface. The concepts of
groupings apply to both ephemeral and non-ephemeral nodes within a data model.
</t>
</section>
</section>
<section title="Error Handling: Different levels of Validation (Debate topic)">
<t> The requirement for Ephemeral nodes level of validation/error handling in
the I2RS protocol have been suggested to have three types of
validation based on an operator-applied policy for I2RS protocol.
<list style="symbols">
<t>syntax validation only, </t>
<t>Ephemeral data store allows for reduced error handling that removes the
requirements for referential checks [I2RS normal error handling]
</t>
<t>ephemeral data store handling that uses normal NETCONF/RESTCONF
error handling with syntax and referential [full],
</t>
</list>
</t>
<t>Editor's note: Andy Bierman believes that only full-validation will work.
Kent Watsen suggested the "no-referential checks".
Jan Medved suggested the "syntax only checks".
Three excellent engineers who are implementing I2RS suggested
these three features. The editor needs aid to
discuss the details of this requirement and proposal.
</t>
<t>
The first step is to see if we can confirm the requirement.
After we've confirmed the requirement, the second step is
to have a detailed discussion about the
pro/cons of this validation. We expect to do this at IETF95.
</t>
<section title="Validation during security outage">
<t><xref target="I-D.hares-i2rs-dataflow-req"></xref> indicates that higher
levels of validity need to occur during security attacks.
Network security controllers communicate with routing devices with
network security functions such as basic firewalls in order
change firewall settings during attacks. The I2NSF
WG is defining communication bewteen the network security
controllers and the NSF/vNSF functions in the routers and
other network devices. <xref target="I-D.hares-i2nsf-mgtflow-reqs"></xref>
describes the challenges to management information flow between
NSF controllers and NSF/vNSF devices operating correctly or
effective during DDoS or network security attacks.
</t>
<t>Higher referential checks may be useful during these
periods of security attacks (DDoS or others).
</t>
</section>
<section title="Solution ideas">
<t>This section is written to
provide ideas for that discussion.
</t>
<t>If the I2RS protocol is required to have three levels of
error handling (syntax only, no-referential, full),
the following are ideas for solutions:
<list style="numbers">
<t>only allow full validation, </t>
<t>allow a particular set of validation (syntax checks,
no-referential, all-checks) per deployments
of an I2RS Agent (operator-applied selection of error checking on the
whole system),
</t>
<t>Restrict the use of the "syntax only to operator-applied error
checking" (argument: if the operator wants to shoot himself in the foot, fine).
Note any module, submodule, or node that has this feature.
</t>
<t>Restrict the the use of "no-referential checking to I2RS independent
protocol modules, and provide error resports of referential checks,
</t>
</list>
</t>
</section>
<section title="Impact on NETCONF/RESTCONF functions">
<t>This section describes the ephemeral data stores handling
for each of the functions.
</t>
<section title="Syntax validation">
<t>Syntax validation of the message should be done according to the
NETCONF or RESTCONF protocol features. New features for ephemeral
datastore should provide the error handling with the feature.
Message syntax validation can be for read, write, or rpc functions.
</t>
<t>Syntax validation of the data model included in the
ephemeral data store should be done by I2RS Agent. </t>
</section>
<section title="Referential validation">
<t> The ephemeral data store normal processing does not do
the following referencial checks: leafref, MUST, instance identifier.
The removal of these validations allows for intelligent I2RS clients
to rapidly read or write data, and handle error conditions at a higher level.
</t>
</section>
<section title="Grouping and Error handling">
<t>Yang 1.0 and Yang 1.1 provide the ability to group data in
groupings, leafref lists, lists, and containers. Adding
the ephemeral data store will add these rules to references
between data stores:
<list style="numbers">
<t>Ephemeral node can refer to config nodes, or derived state nodes (e.g. LSP), </t>
<t>config nodes cannot refer to ephemeral intended configuration nodes, and </t>
<t>derived state nodes can refer to ephemeral configuration or configuratino nodes.</t>
<t>derived state nodes are "non-persistent" and may disappear if a protocol event occurs
</t>
<t>ephemeral datastore nodes are "non-presistent" and will disappear upon a reboot
of the software/hardware. </t>
</list>
</t>
<t>Referential checks require the above rules. Not doing referential checks
could cause one or more broken references to exist in the ephemeral data base.
An ephemeral data bases with broken references may crash, given faulty information,
or perform wrong protocol actions.
</t>
</section>
<section title="Priority preemption">
<t> I2RS protocol uses priority to resolve two I2RS clients having
permissions to write the same pieces of data in an I2RS agent (NETCONF server).
If two (or more) I2RS clients attempt to write the same data,
the the one with the highest priority is enable to write the data.
In the case of two clients with the sample priority attempting to write data,
the the first one to request write wins.
</t>
<t>
Each client has a unique priority. Client identities and priorities are
assigned outside of I2RS by exterior mechanisms such as AAA or adminstrative interfaces.
A valid I2RS client must have both an identity and a priority.
</t>
<t>A client-id and priority must be saved per node.
</t>
<t>A sample container for I2RS client information is shown below.
<figure>
<artwork>
container i2rs-clients {
leaf max-clients {
config false;
mandatory true;
type uint32 {
range "1 .. max";
}
}
list i2rs-client {
key name;
unique priority;
leaf name { ... }
leaf priority { ... }
}
}
Figure 4
</artwork>
</figure>
</t>
<section title="Andy Bierman Priority Comment">
<t>(Andy)This priority is not required to be densely numbered.
Whether there are 1 pane per client or 1 pane per priority or
1 giant blob full of everything, the code will be the same.
The goal of "unique priority" is to require that only priority be saved
in the meta-data for the ephemeral datastore. Without that, client-id and priority
must be saved (per data node).
</t>
</section>
</section>
</section>
</section>
</section>
<section title="transport protocol">
<section title="Secure Protocols">
<t>NETCONF's XML-based protocol (<xref target="RFC6241"></xref>) can operate over
the following secure and encrypted transport layer protocols:
<list>
<t>SSH as defined in <xref target="RFC6242"></xref>,</t>
<t>TLS with X.509 authentication <xref target="RFC7589"></xref></t>
</list>
</t>
<t>RESTCONF's XML-based or JSON <xref target="RFC7158"></xref>
data encodings of Yang functions are passed over HTTOS with (GET, POST,
PUT, PATCH, DELETE, OPTIONS, and HEAD).
</t>
</section>
<section title="Insecure Protocol ">
<t> The ephemeral database may support insecure protocols
for information which is ephemeral state which
does not engage in configuration. The insecure protocol
must be defined in conjunction with a data model or
a subdata model.
</t>
<t><xref target="RFC6536"></xref> has two
extensions for security. Two extensions supporting ephemeral
and insecure might look like:
<figure>
<artwork>
extenson ephemeral {
description "if present in a data definition statement
then the object is considered OK for editing as ephemeral data."
}
extension non-secure-ok {
description "if present in data definition statement
then the object is considered OK for non-secure transport."}
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
T declare a local config and ephemeral edit:
leaf both {
i2rs:ephemeral;
type string;
config true;
// Yang allows leafref/XPATH to point at config=true only
}
To declare an object ephemeral edit only
leaf eph {
i2rs:ephemeral;
type string;
config false;
}
To declare a non-secure leaf
leaf in-octets {
i2rs:nonsecure-ok;
type yang:counter64;
config false;
}
</artwork>
</figure>
</t>
</section>
</section>
<section title="Yang Library Use by Ephemeral">
<t>
The data modules supporting the ephemeral datastore
can use the Yang module library to describe their datastore.
Figure 5 shows the module library data structure
as found <xref target="I-D.ietf-netconf-yang-library"></xref>.
</t>
<t>
The I2RS modules will provide features for I2RS ephemeral
state and protocol of:
<list style="symbols">
<t>protocol version support - "version 1", </t>
<t>ephemeral model scope - ephemeral modules,
mixed config module (ephemeral and config),
mixed derived state (ephemeral and config).
</t>
<t>multiple message support - "all or nothing",
</t>
<t>pane of glass support - "single only".</t>
<t>protocol supported - "NETCONF", "RESTCONF",
"NETCONF pub-sub push",</t>
<t>encoding support - XML or JSON</t>
<t>transports protocol supported: "TCP", "SSH", "TLS",
non-secure, and othrs.
</t>
<t>configuration for non-secure transport
(An example is
<list>
<t>i2rs:nonsecure-ok; </t>
</list>
)
</t>
</list>
</t>
<t>
<figure>
<artwork>
+--ro modules
+--ro module*[name revision]
+--ro name yang: yang-identifier
+--ro revision union;
+--ro schema? inet:uri
+--ro namespace inet:uri
+--ro feature* yang:yang-identifier
+--ro deviation* [name revision]
| +-- ro name yang:yang-identifier
| +-- ro revision union
+--ro conformance enumeration
+--ro submodules
+--ro submodule*[name revision]
+--ro name yang:yang-identifier
+--ro revision union
+--ro schema? inet:uri
Figure 5
</artwork>
</figure>
</t>
<t>Editor's Note: One feature under debate is data
modules providing different levels of
check on rpc or writes.
<list>
<t>ephemeral checking - syntax only,
no-referential, and full checking.</t>
</list>
</t>
</section>
<section title="Simple Thermostat Model">
<t>
In this discussion of ephemeral configuration,
this draft utilizes a simple thermostat model with the
YANG configuration found in figure 6.
</t>
<t>
<figure>
<artwork>
module thermostat {
..
leaf desired-temp {
type int32;
units "degrees Celsius";
description "The desired temperature";
}
leaf actual-temp {
type int32;
config false;
units "degrees Celsius";
description "The measured temperature
(operational state).";
}
}
Figure 6 - Simple thermostat YANG Model
</artwork>
</figure>
</t>
<t>
Figure 6 shows two I2RS clients talking to this model: scheduler and hold-temp.
Scheduler has a schedule set of temperatures to put in the thermostat.
Hold-temp holds the temperature at the same value. The hold-temp
I2RS client has a higher priority than the scheduler client.
<figure>
<artwork>
........... ................... ...........
:Candidate :---:running config :--: start-up :
: : :desired-temp (cfg): : :
........... .................. ...........
|
|
|
|
| =============
| |I2rs Client|
| /|scheduler |
| | ============
.........|.......... |
Intended . '''''''V''''''' . | ==============
Config . 'desired-temp'' | |I2RS Client |
. '''''''''^''''''<---+ | hold temp |
. 'ephemeral-temp'<========| |
...........|.......
config true |
------------------------|-------------
config false | (config down,
V status of config up)
=============
| Actual |============ I2RS clients
| config |
=============
______________
| actual temp |========== I2RS Clients
| (op-state) |
----------------
Figure 6 - Two I2RS clients
</artwork>
</figure>
</t>
<section title="Yang changes">
<t>
<figure>
<artwork>
module thermostat {
..
leaf desired-temp {
type int32;
units "degrees Celsius";
ephemeral true;
description "The desired temperature";
}
leaf actual-temp {
type int32;
config false;
units "degrees Celsius";
description "The measured temperature";
}
}
Figure 7 - Simple Thermostat Yang with ephemeral
</artwork>
</figure>
</t>
</section>
<section title="RESTCONF sequence">
<t>
Figure 7 shows the thermostat model has ephemeral variable desired-temp in the
running configuration and the ephemeral data store. The RESTCONF way of
addressing is below:
<figure>
<artwork>
RESTCONF running data store
PUT /restconf/data/thermostat:desired-temp
{"desired-temp":18}
RESTCONF ephemeral datastore
PUT /restconf/data/thermostat:desired-temp?datastore=ephemeral
{"desired-temp":19 }
Figure 8 - RESTCONF setting of ephemeral state
</artwork>
</figure>
</t>
</section>
<section title="NETCONF messages" >
<t>
The NETCONF way of transmitting this data would be
<figure>
<artwork>
<rpc-message-id=101
xmlns="urn:ietf:params:xml:ns:base:1.0">
<edit-config>
<target>
<ephemeral >
true
</ephemeral >
</target>
<config>
<top xmlsns="http:://example.com/schema/1.0/thermostat/config>
<desired-temp> 18 </desired-temp>
</top>
</config>
</edit-config>
</rpc>
Note: config=TRUE; datastore = ephemeral
ephemeral-validation=full-check;
figure 8 NETCONF setting of desired-temp
</artwork>
</figure>
</t>
</section>
</section>
<section title="NETCONF protocol extensions for the ephemeral datastore">
<t>
capability-name: ephemeral-datastore
</t>
<section title="Overview">
<t>
This capability defines the NETCONF protocol extensions for the ephemeral state.
The ephemeral state has the following features:
<list style="symbols">
<t>the ephemeral datastore is a datastore that holds configuration information
(Config=true) that is intended to not survive a reboot. </t>
<t>The ephemeral capbility is signalled as a capability for
a node, a sub-module, or a module either in the conformance portion of
NETCONF (<hello>) or via netconf yang module library
(<xref target="I-D.ietf-netconf-yang-library"></xref>) used by Yang 1.1 and
RESTCONF.
</t>
<t>ephemeral data will be noted by an "ephemeral statement at the
node or module "</t>
<t>The ephemeral datastore is never locked. </t>
<t>The ephemeral data store is one pane of glass that overrides
the intended config which is normally the running datastore, but can be designated
as the candidate config. </t>
<t>Ephemeral data nodes can occur as part of protocol or protocol independent modules.
However, ephemeral data nodes cannot have non-ephemeral data nodes within the
subtree. Ephemeral sub-modules cannot have non-ephemeral data nodes wihin the module.
Ephemeral modules cannot have non-ephemeral sub-modules or nodes within the module.
</t>
<t>ephemeral writes have two checks: error validation and
priority premption between two I2RS client writes to the same data.
</t>
<t>ephemeral error checking has the following three levels
<list style="symbols">
<t>syntax only - message and data module syntax,</t>
<t>reduced error checking that remove the requirement for
leafref checking, MUST clauses, and instance identifier validation. </t>
</list>
The default is reduced error checking.
</t>
<t>The write operation with a priority pre-emption by a higher priority
client of the lower priority clients write where the
overwrite triggers a notification by the I2RS agent to the lower
priority client.</t>
</list>
</t>
</section>
<section title="Dependencies">
<t>The following are the dependencies for ephemeral support:
<list>
<t>The Yang data modules must be flag with the ephemeral data store at
the node, sub-module and model. </t>
<t>(under debate) Yang data models must specify ephemeral validation if
the models desire validation other reduced error checking. </t>
<t>The Yang modules must support the notification of write-conflicts.
</t>
</list>
</t>
</section>
<section title="Capability identifier">
<t>
The ephemeral-datastore capability is identified by the following capability
string: (capability uri)</t>
</section>
<section title="New Operations">
<section title="Bulk-Write">
<t>Bulk Write allows for large scale writes with
error handling that is specified as syntax or
reduced or full. Alternatively, the data modules
can utilize an RPC to do bulk reads/writes. The
bulk write will be first check for other I2RS clients
having a higher priority write value for any
of the values.
</t>
<t>Editor: Do we need something beyond
rpc for bulk data writes? </t>
</section>
</section>
<section title="Modification to existing operations">
<t>The capability for :ephemeral-datastore modifies the
target for existing operations. </t>
<section title="<get-config>">
<t>The :ephemeral-datastore capability modifies the <edit-config>
to accept the <ephemeral> as a target for source, and allows
the filters focused on a particular module, submodule, or node.
</t>
<t> The positive and negative responses remain the same.
</t>
<t>
<figure>
<artwork>
Example - retrieve users subtree from
ephemeral database
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<emphemeral-datastore/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.0/thermostat/config">
<desired-temp>
</top>
</filter>
</get-config>
</rpc>
</artwork>
</figure>
</t>
</section>
<section title="<edit-config>">
<t>The :ephemeral-datastore capability modifies the <edit-config>
to accept the <ephemeral> as a target for source with filters.
The operations of merge, replace, create, delete, and remove are available,
but each of these operations is modified by the priority write as follows:
<list>
<t><merge> parameter is replaced by <merge-priority>
The current data is modified by the new data in a merge
fashion only if existing data either does not exist, or is owned by a lower priority client.
If any data is replaced, this event is passed to the notification function
within the pub/sub and traceability.
</t>
<t><replace> is replaced by <replace-priority>
for ephemeral datastore which replaces data if the existing
data is owned by a lower priority client. If data any data is replaced,
this event is passed to the notification function within pub/sub
and traceability for notification to the previous client.
The success or failure of the event is passed to traceabilty.
</t>
<t><create> - the creation of the data node works as in
<xref target="RFC6241"></xref> except that the success or failure is
passed to pub/sub and traceability functions.
</t>
<t><deletion> - the deletion of the data node works as in
<xref target="RFC6241"></xref> except event that the success or
the error event is passed to the notiication services in the pub/sub
and traceability functions.
</t>
<t><remove> - the remove of the data node works as in
<xref target="RFC6241"></xref> except that all results are
forwarded to traceabilty.
</t>
</list>
</t>
<t>
The existing parameters are modified as follows:
<list>
<t><target> - add a target of :emphemeral-datastore
</t>
<t><default-operation> -allows only <merge-priority> or
<replace-priority></t>
<t><error-option> - the I2RS agent agent supports only the
a"all-or-nothing" equivalent to a "rollback-on-error" function. </t>
<t>positive response - the <ok> is sent for a positive response
within an <rpc-reply>. </t>
<t>negative response - the <rpc-error> is sent for a negative response
within an <rpc-reply>. Note a negative respones may
evoke a publication of an event. </t>
</list>
</t>
</section>
<section title="<copy-config>">
<t>Copy config allows for the complete replacement
of all the ephemeral nodes within a target.
The alternation is that source is the :ephemeral datastore
with the filtering to match the datastore.
The following existing parameters are modified as follows:
<list>
<t><target> - add a target of :emphemeral-datastore
</t>
<t><error-option> - the I2RS agent agent supports only the
a"all-or-nothing" equivalent to a "rollback-on-error" function. </t>
<t>positive response - the <ok> is sent for a positive response
within an <rpc-reply>. </t>
<t>negative response - the <rpc-error> is sent for a negative response
within an <rpc-reply>. </t>
</list>
</t>
</section>
<section title="<delete-config>">
<t>The delete will delete all ephemeral nodes out of a datastore.
The target parameter must be changed to allow :ephemeral-datastore.
and filters. </t>
</section>
<section title="<lock> and <unlock>">
<t>Lock and unlock are not supported with a target of :ephemeral-datastore.
</t>
</section>
<section title="<get>">
<t>The <get> is altered to allow a target of :ephemeral-datastore and
with the filters.
</t>
</section>
<section title="<close-session> and <kill-session>">
<t>The close session is modified to take a target of :ephemeral-datastore,
Since no locks are set, none should be released.
</t>
<t>The kill session is modified to take a target of "ephemeral-datastore.
Since no locks are set, none should be released. </t>
</section>
</section>
<section title="Interactions with Capabilities">
<t>
<xref target="RFC6241"></xref> defines NETCONF capabilities for
writeable-running datastore, candidate config data store,
confirmed commit, rollback-on-error, validate, distinct start-up,
URL capability, and XPATH capability. I2RS ephemeral state
does not impact the writeable-running data store or the
candiate config datastore.
</t>
<section title="writable-running and candidate datastore">
<t>
The writeable-running and the candidate datastore cannot be used in conjunction
with the ephemeral data store. Ephemeral database overlays
an intended configuration, and does not impact the writable-running
or candidate data store.
</t>
</section>
<section title="confirmed commmit">
<t>Confirmed commit capability is not supported for the ephemeral
datastore. </t>
</section>
<section title="rollback-on-error">
<t> The rollback-on-error when included with ephemeral state
allows the error handling to be "all-or-nothing" (roll-back-on-error).
</t>
</section>
<section title="validate">
<t>
Editorial: Andy Bierman feels that any validation except full
is going to leave the ephemeral datastore unusable.
Kent Watsen suggested a "no-referential" validation as
the default for I2RS protocol.
Jan Medved indicated that many of the ODL Route updates are
validated on the I2RS client extensively, so that
the update can occur quickly with a "syntax only".
Three operations people have indicated 3 different
implementations. This needs to be discussed at IETF.
</t>
<t>The text below is only a command that
would provide a key word to allow three different types of
validation. The command gives form to the requirements
and comments from others, but it may also be broken.
</t>
<t>The <validate> key word is expanded to support the following:
<list>
<t>source: ephemeral-datastore</t>
<t>validate: (syntax, no-referential, full) with the following definitions:
<list style="symbols">
<t>syntax - validates only the message syntax and the
data base syntax.</t>
<t>no-referentail - skips referential test (leafref, MUST clauses, and
instance identifiers). </t>
<t>full - all normal netconf/restconf module error chcking </t>
</list>
</t>
</list>
</t>
</section>
<section title="Distinct Startup Capability">
<t>This NETCONF capability appears to operate to load write-able running config,
running-config, or candidate datastore. The ephemeral state does not
change the environment based on this command.
</t>
</section>
<section title="URL capability and XPATH capability">
<t>The URL capabilities specify a <url> in the <source>
and <target>. The initial suggestion to allow both of these
features to work with ephemeral datastore. </t>
</section>
</section>
</section>
<section title="RESTCONF protocol extensions for the ephemeral datastore">
<t>
capability-name: ephemeral-datastore
</t>
<section title="Overview">
<t>
This capability defines the RESTCONF protocol extensions for the ephemeral state.
The ephemeral state has the features described in the previous section on NETCONF.
</t>
</section>
<section title="Dependencies">
<t>The ephemeral capabilities have the following dependencies:
<list>
<t>Yang data nodes, sub-modules, or modules must be flaged with the
config datastore flag;
</t>
<t>The Yang modules must support the notification of write-conflicts.
</t>
<t>The I2RS Yang modules must support the following:
<list>
<t> the yang-patch features as specified in
<xref target="I-D.ietf-netconf-yang-patch"></xref>.</t>
<t>The yang module library feature <xref target="I-D.ietf-netconf-yang-library"></xref>,
</t>
<t> the equivalent of the netconf pub/subscription push service found in
<xref target="I-D.ietf-netconf-yang-push"></xref>
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Capability identifier">
<t>
The ephemeral-datastore capability is identified by the following capability
string: (capability uri)</t>
</section>
<section title="New Operations">
<t>none</t>
</section>
<section title="modification to data resources">
<t>RESTCONF must be able to support the ephemeral
datstore as a context with its rules as part of the "{+restconf}/data"
subtree. The "edit collision" features in RESTCONF
must be able to provide notification to I2RS read functions
or to rpc functions. The "timestamp" with a
last modified features must support the traceability function.
</t>
<t>
The "Entity Tag" could support saving a client-priority
tuple as a opaque string, but it is important that
that additions be made to restore client-priority so it
can be compared with strimgs can be done to determine
the comparison of two I2RS client-priorities.
</t>
</section>
<section title="Modification to existing operations">
<t>The current operations in RESTCONF are: OPTIONS,
HEAD, GET, POST, PUT, PATCH, and DELETE. This section
describes the modification to these exiting operations.</t>
<section title="OPTIONS changes">
<t>
The options methods should be augmented by the
<xref target="I-D.ietf-netconf-yang-library"></xref> information
that will provide an indication of what ephemeral state exists
in a data modules, or a data modules sub-modules or nodes.
</t>
</section>
<section title="HEAD changes">
<t>
The HEAD in retrieving the headers of a resources. It would
be useful to changes these headers to indicate the datastore
a node or submodule or module is in (ephemeral or normal), and
allow filtering on ephemeral nodes or trees, submodules or module.
</t>
</section>
<section title="GET changes">
<t>
GET must be able to read from the URL and a context ("?context=ephemeral").
Similarly, it is important the Get be able to determine if
the context=ephemeral.
</t>
</section>
<section title="POST changes">
<t>
POST must simply be able to create resources in ephemeral datastores
("context=ephemeral") and invoke operations defined in ephemeral
data models.
</t>
</section>
<section title="PUT changes">
<t>
PUT must be able to reference an ephemeral module,
sub-module, and nodes ("?context=ephemeral").
</t>
</section>
<section title="PATCH changes">
<t>
Plain PATCH must be able to update or create child resources in an
ephemeral context ("?context=ephemeral") The PATCH for the ephemeral state must be
change to provide a merge or update of the original data only
if the client's using the patch has a higher priority than an existing
datastore's client, or if PATCH requests to create a new node,
sub-module or module in the datastore.
</t>
</section>
<section title="DELETE changes">
<t>
The phrase "?context=ephemeral" following an element will specify
the ephemeral data store when deleting an entry.
</t>
</section>
<section title="Query Parameters">
<t>The query parameters (content, depth, fields,
insert, point, start-time, stop-time, and with-defaults (report-all,
trim, explicit, report-all-tagged) must support ephemeral context
("?context=ephemeral") described above. </t>
</section>
</section>
<section title="Interactions with Notifications">
<t>The ephemeral database must support the ability to publish
notifications as events and the I2RS clients being able to
receiving notifications as Event stream. The event error stream
processing should support the publication/subscription mechanisms
for ephemeral state defined in
<xref target="I-D.ietf-netconf-yang-push"></xref>.
</t>
</section>
<section title="Interactions with Error Reporting">
<t>The ephemeral database must support in RESTCONF must also support passing error information regarding
ephemeral data access over to RESTCONF equivalent of the and traceability client.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This is a protocol strawman - nothing is going to IANA. </t>
</section>
<section title="Security Considerations">
<t>
The security requirements for the I2RS protocol are
covered in <xref target="I-D.ietf-i2rs-protocol-security-requirements"></xref>.
The security environment the I2RS protocol is covered in
<xref target="I-D.ietf-i2rs-security-environment-reqs"></xref>.
Any person implementing or deploying the I2RS protocol
should consider both security requirements.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
This document is an attempt to distill lengthy conversations on
the I2RS proto design team from August
</t>
<t> Here's the list of the I2RS protocol design team members
<list style="symbols">
<t>Alia Atlas</t>
<t>Ignas Bagdonas</t>
<t>Andy Bierman</t>
<t>Alex Clemm</t>
<t>Eric Voit</t>
<t>Kent Watsen </t>
<t>Jeff Haas</t>
<t>Keyur Patel</t>
<t>Hariharan Ananthakrishnan</t>
<t>Dean Bogdanavich</t>
<t>Anu Nair</t>
<t>Juergen Schoenwaelder</t>
<t>Kent Watsen</t>
</list>
</t>
</section>
<section title="Major Contributors">
<t>
<list style="symbols">
<t>Andy Bierman (Yuman Networks) - andy@yumaworks.com </t>
<t>Kent Watson (Juniper) (kwatsent@juniper.net)</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References:">
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-traceability;
&I-D.ietf-i2rs-ephemeral-state;
&I-D.ietf-i2rs-pub-sub-requirements;
&I-D.ietf-i2rs-protocol-security-requirements;
&I-D.ietf-i2rs-security-environment-reqs;
&I-D.hares-i2rs-dataflow-req;
&I-D.ietf-i2rs-rib-info-model;
&I-D.ietf-i2rs-rib-data-model;
&I-D.ietf-netmod-opstate-reqs;
&I-D.ietf-netmod-yang-metadata;
&I-D.ietf-netconf-yang-patch;
&I-D.ietf-netconf-yang-push;
&I-D.ietf-netconf-restconf;
&I-D.ietf-netconf-yang-library;
&RFC6241;
&RFC7158;
&RFC7589;
</references>
<references title="Informative References">
&RFC2119;
&RFC6020;
&RFC6242;
&RFC6536;
&I-D.hares-i2nsf-mgtflow-reqs;
&I-D.hares-i2rs-bgp-dm;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 20:34:46 |