One document matched: draft-hares-i2rs-protocol-strawman-02.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 RFC4107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4107.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.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 RFC6244 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6244.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-netconf-server-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-server-model.xml">
<!ENTITY I-D.ietf-netconf-call-home SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-call-home.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-rfc6020bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-rfc6020bis.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.ietf-netmod-syslog-model
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-syslog-model.xml">
<!ENTITY I-D.ietf-netmod-schema-mount
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-schema-mount.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-02.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 strawman proposal for the I2RS protocol supports
I2RS requirements for ephemeral data store, management data flows,
and protocol security. It proposes additions to the NETCONF,
RESTCONF, and YANG for these requirements.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This is a strawman proposal for the first version of the I2RS protocol.
This draft is input to a NETCONF Working Group which
standardizes extensions to the NETCONF and RESTCONF protocol,
and to the NETMOD Working Group which standardizes extensions to
YANG.
</t>
<t>
The I2RS protocol is a higher level protocol comprised of a set
of existing protocols which have been extended to work together to
support a new interface to the routing system.
The I2RS protocol is a "reuse" management protocol which creates new management protocols
by reusing existing protocols and extending these protocols for new
uses. The first version of the I2RS protocols is comprised of extensions of the
NETCONF <xref target="RFC6241"></xref> and
RESTCONF <xref target="I-D.ietf-netconf-restconf"></xref>.
</t>
<t>This strawman proposal supports I2RS requirements for
ephemeral data store, management data flows, and protocol security.
It proposes extensions to the following:
<list style="symbols">
<t>YANG 1.1 <xref target="I-D.ietf-netmod-rfc6020bis"></xref>,</t>
<t>NETCONF <xref target="RFC6241"></xref>, </t>
<t> RESTCONF <xref target="I-D.ietf-netconf-restconf"></xref>
</t>
<t>Network Access Control Model <xref target="RFC6536"></xref>
</t>
</list>
</t>
<t>This protocol strawman utilizes the following existing
proposed features for NETCONF and RESTCONF
<list style="symbols">
<t>Call Home <xref target="I-D.ietf-netconf-call-home"></xref>,
</t>
<t>Server Configuratino Module <xref target="I-D.ietf-netconf-server-model"></xref>,
</t>
<t>Module library <xref target="I-D.ietf-netconf-yang-library"></xref>,
</t>
<t>Publication/Subscription via Push <xref target="I-D.ietf-netconf-yang-push"></xref>,
</t>
<t>Patch <xref target="I-D.ietf-netconf-yang-patch"></xref>,
</t>
<t>syslog yang module (both <xref target="RFC5424"></xref>
and <xref target="I-D.ietf-netmod-syslog-model"></xref>
</t>
</list>
</t>
<t>
Section 2 provides definitions for terms in this document.
Section 3 summarizes the changes to configuration data store, NETCONF,
RESTCONF, and YANG.
Section 4 details the changes to Yang.
Section 5 summarizes the changes to transport support for RESTCONF and NETCONF.
Section 6 details the changes to NETCONF.
Section 7 details the changes to RESTCONF.
Section 8 provides a simple example of
I2RS protocol support for the ephemeral data store using
a simple temperature model. Section 9 provides a simple
example of the I2RS protocol with an ephemeral route updating
an existing route. Section 10 provides information on the
security considerations for the I2RS protocol.
</t>
</section>
<section title="Definitions Related to Ephemeral Configuration">
<t> This section reviews definitions from I2RS architecture
<xref target="I-D.ietf-i2rs-architecture"></xref> and
NETCONF operational state <xref target="I-D.ietf-netmod-opstate-reqs"></xref>
before using these to construct a definition of the ephemeral data store.
</t>
<section title="I2RS Definitions">
<t>The I2RS architecture <xref target="I-D.ietf-i2rs-architecture"></xref>
defines the following terms:
<list style="hanging">
<t hangText="ephemeral data: "> is data which does not persist across a
reboot (software or hardware) or a power on/off condition. Ephemeral
data can be configured data or data recorded from operations of the router.
Ephemeral configuration data also has the property that a system
cannot roll back to a previous ephemeral configuration state.
</t>
<t hangText="local configuration: ">is the data on a routing system
which does persist across a reboot (software or hardware) and a
power on/off condition. Local configuration has the ability to
roll back to a pervious configuration state. </t>
<t hangText="operator-applied policy: "> is a policy that
an operator sets that determines how ephemeral configuration
interacts with local configuration. One could consider these
policy knobs that the operator sets to determine how the
I2RS agent will act. Two policy knobs are necessary:
<list style="symbols">
<t>policy knob 1: Ephemeral configuration overwrites local configuration, </t>
<t>policy knob 2: Updated configuration overwrites ephemeral configuration</t>
</list>
</t>
</list>
</t>
<t>
Three possible setting for the above knobs are:
<list style="hanging">
<t hangText="Policy knob 1=false and policy knob 2=true: ">
I2RS software is installed, but the operator does not want it
to overwrite write any configuration variables. This might be valid
if I2RS is only suppose to monitor data on this node.
</t>
<t hangText="Policy knob 1=true and policy Knob 2=false: ">
This is the normal case for the I2RS Agent where the
ephemeral configuration data overwrites the local configuration data,
and the ephemeral data stays even when the local configuration value changes.
When the ephemeral data is removed by the I2RS agent, the
most recent local configuration value is set.
</t>
<t hangText="Policy knob 1=true and Policy Knob 2=true: ">
This case can occur if the ephemeral write is only suppose to
take place until the next configuration cycle from a centralized
system. Suppose the local configuration is get by the centralized
system at 11:00pm each night. The I2RS Client writes
temporary changes to the routing system via the I2RS agent
ephemeral write. At 11:00pm, the local configuration update
overwrite the ephemeral. The I2RS Agent notifies the
I2RS Client which is tracking which of the ephemeral changes
are being overwritten.
</t>
</list>
</t>
</section>
<section title="Operational State definitions">
<t>
The <xref target="I-D.ietf-netmod-opstate-reqs"></xref>
defines the following to augment <xref target="RFC6244"></xref>
to define how configuration state and operational state are different.
<list style="hanging">
<t hangText="Applied Configuration: "> This data represents the
configuration state that the server is actually in.
</t>
<t hangText=" Derived State: "> This data represents information which is generated
as part of the server's own interactions.
</t>
<t hangText="Intended Configuration: "> This data is the configuration state
that the network operator intends the server to be in, and that
has been accepted by the server as valid configuration.
</t>
<t hangText="Operational State: "> is the current state of the
system as known to the various components of the system (e.g.,
control plane daemons, operating system kernels, line cards).
The operational state includes both applied configuration and
derived state.
</t>
</list>
</t>
<t>
In each of these definitions, the "server" is the routing system.
</t>
<t>
The <xref target="I-D.ietf-netmod-opstate-reqs"></xref>
defines two actions that update the intended and the applied configuration:
<list style="hanging">
<t hangText="Asynchronous Configuration Operation: "> the server
MUST update its intended configuration before replying to the
client indicating whether the request will be processed. The
server's applied configuration state is updated after
the configuration change has been fully
effected to all impacted components in the server.
</t>
<t hangText="Synchronous Configuration Operation: "> the server
MUST fully attempt to apply the configuration change
to all impacted components in the server, updating
both its intended configuration and the
applied configuration, before replying to the client.
</t>
</list>
</t>
<t>
In a system without ephemeral data, the
structure of the routing systems local
intended configuration, applied configuration,
and derived state is shown in figure 1.
</t>
<t>
<figure>
<artwork>
| Synchronous
| or Asychronous updsate
|
===========================
| local |
| intended configuration |
===========================
|| read/write
-----------------||-------------------
|| read only
+-------------||------+
| operational || |
| state || |
| =========||== |
| | Applied | |
config | | config | |
true | ============= |
******************************
config | _____________ |
false | | derived | |
| | state | |
| |___________| |
+---------------------+
Figure 1
</artwork>
</figure>
</t>
</section>
<section title="Requirements language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
</section>
<section title="Summary of Protocol Changes">
<t>This section provides a summary of requirements for
changes to support the I2RS protocol features of
ephemeral data, a secure protocol, management data
flows, and I2RS error handling. Management data flows
may be large data flows for notifications, events, and
protocol events. Management flows could also be tracing
the routing system's operation or OAM operations.
</t>
<section title="Ephemeral Data">
<t>
This section provides an overview of the ephemeral data store,
I2RS agent caching support, and ephemeral requirements
(from <xref target="I-D.ietf-i2rs-ephemeral-state"></xref>).
</t>
<section title="Overview of Ephemeral Data Store">
<t>This section augments the <xref target="I-D.ietf-netmod-opstate-reqs"></xref>
with definitions for ephemeral state. NETCONF provides
the concept of a data store, but RESTCONF only defines the concept of a
"context". The logical description of ephemeral additions to
the NETCONF data store below still
fits the general concepts of the RESTCONF context.
</t>
<t>This approach to the ephemeral datastore is two panes-of-glass model
one pane of glass is the "local configuration" within the Intended configuration
and the other pane of glass is the "ephemeral data". The two panes of
glass are pressed together to create the intended configuration
which then applied to the routing node and generates
derived state as shown in figure 2.
</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
(normal and ephemeral). Therefore derived state may be defined
in local configuration or ephemeral portions of a data model
(or data models).
</t>
<t>
The ephemeral data store has the following general 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 portion of the intended configuration,
applied state, and derived state does not persist over a reboot,
</t>
<t>an ephemeral node cannot roll-back to its previous value,
</t>
<t>Since ephemeral data store is just data that does not presist
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.
<list style="symbols">
<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 management protocol (NETCONF/RESTCONF) needs to signal which
poritons of a data model(node, tree, or data model) are ephemeral
in the module library <xref target="I-D.ietf-netconf-yang-library"></xref>.
</t>
</list>
</t>
<t>
<figure>
<artwork>
| Synchronous
| or Asychronous updsate
|
================================
| Local | Ephemeral |=====I2RS Agent
| configuration | Confguration |
|''''''''''''''''''''''''''''''|
| Intended configuration |
=============||=================
|| read/write
-||-------------------
|| read only
+-------------||-------------+
| operational || |
| state || |
| =========||========== |
| | Local * ephemeral| |
| | config * config | |
config | | Applied config | |
true | ===================== |
****************************************
config | ______________________ |
false | | local * ephemeral | |
| | state * state | |
| | derived state | |
| |_____________________ |
+----------------------------+
Figure 2
</artwork>
</figure>
</t>
</section>
<section title="I2RS Agent Caching of Ephemeral Data ">
<t> I2RS does not support caching of ephemeral
data the I2RS Agents. Future I2RS work may support
caching of data in the I2RS Agents.
</t>
</section>
<section title="Ephemeral Requirements for NETCONF/RESTCONF">
<t>
<xref target="I-D.ietf-i2rs-ephemeral-state"></xref>
defines the following requirements for ephemeral datastore:
<list style="symbols">
<t>Ephemeral-REQ-01: I2RS requires ephemeral state
which does not persist across a reboot,</t>
<t>Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer
to ephemeral state for constraint purposes; it SHALL
be considered a validation error if it does.
</t>
<t>Ephemeral-REQ-03: Ephemeral state must be able to
uitlize temporary operational state (eg. MPLS LSP-ID) as a constraint.</t>
<t>Ephemeral-REQ-04: Ephemeral state MAY refer to
non-ephemeral state for purpose of implementing constraints.
The designer of ephemeral state modules are advised that such
constraints may impact the speed of processing ephemeral state commits
and should avoid them when speed is essential. </t>
<t>Ephemeral-REQ-05: The ability to add on an object (or a
hierarchy of objects) that have the propoerty of being ephemeral.</t>
<t>Ephemeral-REQ-06: YANG MUST have a way of indicating in a data model
that nodes have the following properties: ephemera, writeable/nonwritable,
status/configuration, and secure/non-secure transport. Proposed changes to
Yang for I2RS protocol version 1 are:
<list style="symbols">
<t>i2rs-version 1;</t>
<t>ephemeral true; </t>
<t>ephemeral-validation nocheck; </t>
<t>protocol [RESTCONF | NETCONF] </t>
<t>protocol-transport [ssh, tls, tcp]</t>
<t>i2rs-transport-nonsecure ok;</t>
</list>
</t>
<t>Ephemeral-REQ-07: The minimal changes to NETCONF for
I2RS protocol version 1 are:
<list style="symbols">
<t>protocol version support - "i2rs-version 1;".</t>
<t>ephemeral model scope allowed - ephemeral modules, mixed config
module (ephemeral and config), mixed derived state (ephemeral
and config).</t>
<t>multiple message support - "all or nothing" (see Ephemeral-REQ-13).
This mean ephemeral data stores only support "roll-back-on-error"
for messages, URL capability, and XPATH cpability in source or target.
</t>
<t>pane of glass support - "single ephemeral only". </t>
<t>protocol support - "NETCONF" <xref target="RFC6241"></xref>,
"RESTCONF <xref target="I-D.ietf-netconf-restconf"></xref>,
yang pub-sub push <xref target="I-D.ietf-netconf-yang-push"></xref>,
yang module library <xref target="I-D.ietf-netconf-yang-library"></xref>,
call-home <xref target="I-D.ietf-netconf-call-home"></xref>,
and server modules <xref target="I-D.ietf-netconf-server-model"></xref>
(server module must be augmented to support mutual authentication).
</t>
<t>encoding support - XML or JSON,
</t>
<t>transports protocols supported: "SSH","TLS","TCP" (non-secure)
</t>
<t>mandatory transports supported: "TLS", "TCP" (non-secure)
</t>
<t>ability to select insecure transport for portion of data model.
</t>
<t>dependencies include:
<list style="numbers">
<t>Yang data models, sub-modules, or modules
must be flagged with ephemeral data store flag,
</t>
<t>Yang modules must support notification of write conflicts.</t>
<t>yang modules syntax changes described in section 3.4.
</t>
<t>Yang modules must support the following NETCONF/RESTCONF
features:
<list>
<t>The yang module library feature <xref target="I-D.ietf-netconf-yang-library"></xref>,
</t>
<t> Publication-Subscription model found in
<xref target="I-D.ietf-netconf-yang-push"></xref>
</t>
<t>Server initiated connection to a client
<xref target="I-D.ietf-netconf-call-home"></xref>
</t>
<t> data models to configure RESTCONF/NETCONF servers
<xref target="I-D.ietf-netconf-server-model"></xref>,</t>
</list>
</t>
</list>
</t>
<t>modified NETCONF operations for ephemeral are
<get-config>, <edit-config>, <copy-config>,
<delete-config>, <get>, <close-session>,
<kill-session></t>
<t>unsupported NETCONF operation for ephemeral are:
<lock> and <unlock> plus interactions with
writable-running, candidate data store, confirmed commit, and
distinct start-up. </t>
</list>
</t>
<t>Ephemeral-REQ-08: The minimal changes to RESTCONF for the
I2RS protocol version 1 are:
<list style="symbols">
<t>I2rs protocol version support - "i2rs-version 1"</t>
<t>ephemeral model scope allowed - ephemeral modules, mixed config
module (ephemeral and config), mixed derived state (ephemeral
and config)</t>
<t>multiple message support - "all or nothing".
This mean ephemeral data stores only support "roll-back-on-error"
for messages, URL capability, and XPATH cpability in source or target.
</t>
<t>pane of glass support - "single ephemeral only", </t>
<t>RESTCONF protocol features support required -
"RESTCONF <xref target="I-D.ietf-netconf-restconf"></xref>,
yang pub-sub push <xref target="I-D.ietf-netconf-yang-push"></xref>,
yang module library <xref target="I-D.ietf-netconf-yang-library"></xref>,
call-home <xref target="I-D.ietf-netconf-call-home"></xref>,
and server modules <xref target="I-D.ietf-netconf-server-model"></xref>
(server module must be augmented to support mutual authentication).
</t>
<t>encoding support - XML or JSON,
</t>
<t>transports protocols supported: "HTTP 1.1 over TLS"
</t>
<t>mandatory transports supported: "TLS", TCP (non-secure)
</t>
<t>ability to select transports data model is available.
Insecure portions of data model must be able to selet an insecure transport.
</t>
<t>dependencies are the following:
<list>
<t>yang changes (see above) supported,
</t>
<t>support notification of changes or write conflicts
(see Ephemeral-REQ-09 to Ephemeral-REQ-12),
</t>
<t>support I2RS publication-subscription requirements specified in
<xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref> and
implemented in <xref target="I-D.ietf-netconf-yang-push"></xref>,
</t>
<t>yang patch feature specified in
<xref target="I-D.ietf-netconf-yang-patch"></xref>,
</t>
<t>yang module library specified in
<xref target="I-D.ietf-netconf-yang-library"></xref>.
</t>
</list>
</t>
<t>modifications to context: Support ephemeral data in
ephemeral data context that supports "edit-collision" features
that include timestamp, Entity tag, and the ability to
compare I2RS priorities (see Ephemeral-REQ-09 to Ephemeral-REQ-12).
</t>
<t>modification to existing RESTCONF operations:
<list style="symbols">
<t>OPTIONS - provide indication if ephemeral is in data modules,
</t>
<t>HEAD - be able to get HEAD of ephemeral module, config module,
or the head of groups of ephemeral, or groups of config.</t>
<t>GET, POST, PUT, PATCH, DELETE, QUERY parameters - must be able to
handle "context=ephemeral",
</t>
<t>Ephemeral data modules must be able to support publication of
notification or errors as event stream, and allow subscription to
portions of the event stream (see <xref target="I-D.ietf-netconf-yang-push"></xref>),
</t>
</list>
</t>
</list>
</t>
<t>Ephemeral-REQ-09: I2RS clients MUST have identifiers and secondsary
identifiers. I2RS Agents shall have identifiers. </t>
<t>Ephemeral-REQ-10: Data nodes MAY store I2RS client identity rather
than the effective priority of the I2RS client writing the data
at the time the data node is stored. I2RS Clients MUST have one
priority at a TIME. I2RS Client's priority MAY change dyanmically as
long as the requirements in Ephemeral-REQ-11, Ephemeral-REQ-12, and Ephemeral-REQ-13
are fulfilled.
</t>
<t>Ephemeral-REQ-11: When a collision occurs as two I2RS clients
are trying to write the same data node, this collision is considered an error
and priorities are created to give a deterministic result.
The I2RS client with the highest priority wins the ability to write the
data. When there is a collision, a notification MUST be sent to the original client
to give the original client a chance to deal with the issues surrounding
the collision. The original client may need to fix their state.
</t>
<t>Ephemeral-REQ-12: The requirement to support multi-headed control is
required to collisions and the priority resolution of collisions.
Multi-headed control is not tied to ephemeral state.
</t>
<t>Ephemeral-REQ-13: If two clients have the same priority, the
I2RS architecture says the first one wins. The I2RS protocol has this
requirement to prevent oscillation between clients. If the last one
wins, you may oscillate. </t>
<t>Ephemeral-REQ-14: Section 7.9 of <xref target="I-D.ietf-i2rs-architecture"></xref>
states the I2RS architecture does not include multi-message atomicity and
roll-back mechanisms. It also notes performing multiple operatinos in one or
more messages can cause errors within the set of operations inmany ways. No
multi-message commands SHOULD cause errors to be inserted in the I2RS ephemeral
data store.
</t>
</list>
</t>
<t>(Editor's note: This section provides a complete list of the
ephemeral data store requirements. This section may
be removed as it is covered in
<xref target="I-D.ietf-i2rs-ephemeral-state"></xref>,
and only provided here for convenience of the reader.)
</t>
</section>
</section>
<section title="Protocol Security">
<t>
The I2RS protocol requires the ability to run over
secure transport connections for the I2RS protocol to run over.
Each secure transport must provide data confidentiality, data integrity, and
replay prevention. NETCONF running over TLS or SSH over TCP, and
RESTCONF running over HTTP 1.1 over TLS over TCP provide these features.
However, the I2RS protocol requires extensions to this protocol security.
This section provides an overview these changes.
</t>
<section title="Summary of Protocol Security Changes">
<t>The I2RS protocol requires the following new security features:
<list style="symbols">
<t>mutual identification of I2RS Client and Agents via unique identifiers,
</t>
<t>the I2RS client identifier to be associated with a priority and
a secondary identity
</t>
<t>data access (read/write) for each data model to be associated
with I2RS client roles,
</t>
<t>the ability to send some data over an insecure section
as specified in a data model.
</t>
</list>
This section describes these new features.
</t>
<section title="Multiple secure transports">
<t>The I2RS protocol MAY operate over a set of secure
transports (1 to many transports) which provide data
confidentiality, data integrity, and replay prevention.
The key management that distributes keys MUST
guarantee that only the entities having sufficient privileges
can get the keys to encrypt/decrypt the sensitive data.
NETCONF's operatoring over TLS or SSH protocols, both of which run over TCP,
provide such a secure transport as does RESTCONF operating over HTTP 1.1
operating over TLS which runs over TCP also fits this description.
</t>
</section>
<section title="Mutual Identification ">
<t>I2RS protocol security requires mutual identification of
I2RS client and agent via a unique identifier. The identity of each
I2RS client must be represented by at least one unique I2RS client identifier,
and the identity of an I2RS Agent must be represented by
at least one unique I2RS agent identifier. The I2RS protocol
must perform mutual identification of the I2RS client and the I2RS agent.
The I2RS client-agent security association is valid for a single transport session
or a set of parallel transport sessions. The I2RS client-agent security association
does not need to have an active transport session to remain active.
The I2RS agent and client unique identifiers are created and distributed
outside the I2RS protocol.
</t>
</section>
<section title="I2RS Client has Identifier + Priority + Secondary Identifier">
<t>
Each I2RS client identifier will have one priority and
one secondary identifier during a particular I2RS transaction
(read/write sequence), but the priority and the secondary
identity associated with a I2RS client identity may change during
a I2RS client-agent association.
</t>
</section>
<section title="I2RS Role Based Access">
<t>
Certain data within routing elements is sensitive and read/write operations on
such data SHOULD be controlled as to which I2RS client can access the
data for read/write based on the I2RS client's roles in order to
protect its confidentiality. A I2RS Client's role describe
which data models and which data within those data models
the I2RS client can have read access, write access, or both (read/write).
</t>
</section>
<section title="Insecure Transport">
<t>An I2RS data model with ephemeral state MAY
require the passage of I2RS data will require the some data to be
be sent from the I2RS agent to a I2RS client via an insecure transport.
Examples of this transport could be the I2RS agent agent opening up
a TCP connection to an I2RS Client via TCP.
The yang data model specifying this MUST indicate what
data is able to be passed over an insecure transport connection.
Insecure transport must still support traceability and
publication/subscription of the insecure data.
</t>
</section>
</section>
<section title="I2RS Protocol Security Requirements">
<t>
<xref target="I-D.ietf-i2rs-protocol-security-requirements"></xref>
specifies the following requirements:
<list style="symbols">
<t>SEC-REQ-01: All I2RS clients and I2RS agents MUST have an identity, and at least one unique
identifier that uniquely identifies each party in the I2RS protocol context. </t>
<t>SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for mutual identification of
the I2RS client and I2RS agent. </t>
<t>SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a
I2RS client, MUST confirm that the I2RS client has a valid identifier.</t>
<t>SEC-REQ-04: The I2RS client, upon receiving an I2RS message from an
I2RS agent, MUST confirm the I2RS agent has a valid identifier.</t>
<t>SEC-REQ-05: Identifier distribution and the loading of these identifiers into I2RS agent
and I2RS Client SHOULD occur outside the I2RS protocol. </t>
<t>SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF or private) will
distribute or load identifiers so that the I2RS client/agent has these
identifiers prior to the I2RS protocol establishing a connection
between I2RS client and I2RS agent. </t>
<t> SEC-REQ-07: Each Identifier MUST have just one priority.</t>
<t> SEC-REQ-08: Each Identifier is associated with one secondary identifier during a
particular I2RS transaction (e.g. read/write sequence), but the secondary
identifier may vary during the time a connection between the I2RS client and
I2RS agent is active. Since a single I2RS client may be use by multiple
applications, the secondary identifier may vary as the I2RS client is
utilize by different application each of whom have a unique secondary identity
and identifier. </t>
<t>SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
secure transport and optionally MAY be able to transfer data over a
non-secure transport. A secure transport MUST provide data
confidentiality, data integrity, and replay prevention.
</t>
<t>SEC-REQ-10: A secure transport MUST be associated with a key management
solution that can guarantee that only the entities having sufficient privileges
can get the keys to encrypt/decrypt the sensitive data.
Per <xref target="RFC4107">BCP107</xref> this key management system SHOULD be automatic,
but MAY be manual in the following scenarios:
<list>
<t>a) The environment has limited bandwidth or high round-trip times.</t>
<t>b) The information being protected has low value.</t>
<t>c) The total volume of traffic over the entire lifetime of the long-term session key will be very low.</t>
<t>d) The scale of the deployment is limited.</t>
</list>
</t>
<t> SEC-REQ-11: The I2RS protocol MUST be able to support multiple secure transport
sessions providing protocol and data communication between an I2RS Agent
and an I2RS client. However, a single I2RS Agent to I2RS client connection MAY
elect to use a single secure transport session or a single
non-secure transport session. </t>
<t>SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement
mechanisms that mitigate DoS attacks.</t>
<t>SEC-REQ-13: In a critical infrastructure, certain data within routing elements is
sensitive and read/write operations on such data SHOULD be controlled in order to protect
its confidentiality. To achieve this, access control to sensitive
data needs to be provided, and the confidentiality protection on
such data during transportation needs to be enforced.
</t>
<t> SEC-REQ-14: An integrity protection mechanism for I2RS SHOULD be able to ensure the following:
<list style="numbers">
<t>the data being protected is not modified without detection during
its transportation,
</t>
<t>the data is actually from where it is expected to come from, and
</t>
<t>the data is not repeated from some earlier interaction of the protocol.
(That is, when both confidentiality and integrity of data is properly protected, it
is possible to ensure that encrypted data is not modified
or replayed without detection.)
</t>
</list>
</t>
<t>SEC-REQ-15: The integrity that the message data is not repeated
means that I2RS client to I2RS agent transport SHOULD protect against replay attack
</t>
<t>SEC-REQ-16: The I2RS message traceability and notification requirements
requirements found in <xref target="I-D.ietf-i2rs-traceability"></xref> and
<xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref> SHOULD be supported
in communication channel that is non-secure to trace or notify about potential
security issues.</t>
<t> SEC-REQ-17: The rules around what role is permitted to access and manipulate what
information plus a secure transport (which protects the data in transit)
SHOULD ensure that data of any level of sensitivity is
reasonably protected from being observed by those without permission
to view it, so that privacy requirements are met.
</t>
<t> SEC-REQ-18: Role security MUST work when multiple transport connections are being used
between the I2RS client and I2RS agent as the <xref target="I-D.ietf-i2rs-architecture">I2RS architecture</xref> states.
These transport message streams may start/stop without affecting the existence of the client/agent
data exchange. TCP supports a single stream of data. SCTP <xref target="RFC4960" /> provides
security for multiple streams plus end-to-end transport of data.
</t>
<t> SEC-REQ-19: I2RS clients MAY be used by multiple applications to configure routing
via I2RS agents, receive status reports, turn on the I2RS audit stream, or turn
on I2RS traceability. Application software using I2RS client functions
may host multiple secure identities, but each connection will use
only one identifier with one priority. Therefore, the security of each
I2RS Client to I2RS Agent connection is unique.
</t>
<t>Sec-REQ-20: If an I2RS agents or an I2RS client is tightly
correlated with a person, then the I2RS protocol and data models
should provide additional security that protects the person's privacy.
</t>
</list>
</t>
<t>
(Editor's note: Since <xref target="I-D.ietf-i2rs-protocol-security-requirements"></xref>
specifies these requirements, this section may be dropped. It is included
in this version for the convenience of the reader.)
</t>
</section>
</section>
<section title="Data Flow">
<t> The data flow requirements are in
<xref target="I-D.hares-i2rs-dataflow-req"></xref>.
</t>
<t>Large amounts of data can flow from the I2RS agent
to the I2RS client, or from the I2RS client to the I2RS Agent.
OAM functions in a router can require large data flows plus system
resources (cpu, memory, data storage). Future versions of
the I2RS protocol (after protocol version 1) should be able to
support IPFIX protocol as one of ways an I2RS Agent send data.
This section describes the changes to NETCONF/RESTCONF to
support these new features.
</t>
<t>Data flow requirements specify that the transports
used between an I2RS client and I2RS agent be negotiated.
This negotiation between I2RS client and I2RS agent can be simple.
The I2RS client could query the I2RS Agent over a mandatory protocol
(E.g. NETCONF over TLS over TCP on standard port) for other
mandatory parameters for I2RS Client can use to communicate or
I2RS Agent outbound communication via call-home
(<xref target="I-D.ietf-netconf-call-home"></xref>.
</t>
<t>
The I2RS Data flow requirements specify
that the following should be able to be negotiated:
<list style="symbols">
<t>I2RS protocol encodings (XML or JSON) (I2RS-DF-REQ-02), </t>
<t>secure transports from mandatory list (I2RS-DF-REQ-03),
</t>
<t>alternate transports during outages or attacks (I2RS-DF-REQ-04) with
different resource contraints (I2RS-DF-REQ-06) </t>
<t>ports the secure transports or alternate transports use (I2RS-DF-REQ-06), </t>
<t>insecure transports from mandatory list based on the
requirements of supported yang data models (I2RS-DF-REQ-04, I2RS-DF-REQ-09), </t>
</list>
</t>
<section title="Data Flows From the I2RS Agent">
<t> Large data flows can be required by the I2RS agent to
publish large data for protocol state, virtual topologies,
events, and notifications from a routing system.
<xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref>
specify the I2RS requirements for publication of large data flows
from the I2RS Agent via a publication/subscription (aka pub-sub) mechanism.
The pub-sub mechanisms has been specified for the "push" service
in <xref target="I-D.ietf-netconf-yang-push"></xref>.
</t>
<t>Large data flows can also be required to trace the
actions of a routing system. These requirements
are listed in the <xref target="I-D.ietf-i2rs-traceability"></xref>.
These traceability requirements specify mandatory fields in
the trace log including an end of message marker for a record
plus handling of the trace logs. This handling includes
creation of trace logs, limits on trace logs, trace log rotation,
and trace log retrieval by syslog <xref target="RFC5424"></xref>,
the pub-sub mechanism or a large data push. This large
data push can be a pull in a large write.
</t>
<t>Large data flows from the I2RS client also mean that
some of the data flows from the I2RS Agent
may be prioritized over other data flows
(I2RS-DF-REQ-07). This priorization will be based on
what the data is, what the operator-applied policy knobs
are for reporting, and the current resource constraints
(I2RS-DF-REQ-05).
</t>
</section>
<section title="Data Flows to I2RS agent">
<t>I2RS protocol may write specific data such as routes or flow-filters in a
specific rpc actions. Writing large numbers of flow filters or routes
may require a great deal of processing by the I2RS agent and the remote
I2RS client. In some cases, I2RS client may the I2RS agent to trust
the validation the I2RS client does for an rpc that writes a route (or routes)
or a flow filter (or flow filters). This trust in the I2RS client
validation speeds up the processing of the rpc at risk of invalid data
(see I2RS-DF-REQ-01).
</t>
</section>
<section title="OAM Constraints">
<t>OAM actions in a router may require extra
processing, extra memory or data storage, or extra
data flows to/from the I2RS agent. The OAM functions
SHOULD not impact the routing functions so it cannot
perform its main task of guiding the traffic.
OAM functions must be able to be limited in terms of
processing power, memory, data storage, or data flows
to/from network (I2RS-DF-REQ-05).
</t>
</section>
<section title="IPFIX as Transport for traffic monitoring">
<t>Due to the potentially large data flow the traffic measurment
statistics generate, these statistics are best handled by
publication techniques within NETCONF or a separate protocol such as IPFIX.
In the future version of the I2RS protocol may desire to
support a data stream outbound from the I2RS Agent to an I2RS
client via the IPFIX protocol.
</t>
</section>
<section title="Data Flow Requirements">
<t> The following are the data flow related requirements
from <xref target="I-D.hares-i2rs-dataflow-req"></xref>
for I2RS protocol version 1:
<list style="hanging">
<t hangText="I2RS-DF-REQ-01:No Validation RPCs "> I2RS generic interfaces
in I2RS protocol independent modules or I2RS protocol dependent modules
should be able to optionally create rpcs which store configuration data in the I2RS
ephemeral data store without the normal configuration checking.
The only thing check will be the syntax within the protocol packets.
The data models allowing must provide a "no-checking flag" at
the level the rpc stores the data. For example, the
I2RS RIB could create a rpc for a route-add that allowed
a flag that indicates validation status ("full or no-checks")
</t>
<t hangText="I2RS-DF-REQ-02: XML and JSON: "> encoding formats
SHOULD be supported in RESTCONF and NETCONF.
</t>
<t hangText="I2RS-DF-REQ-03: Transport Protocols: ">MAY be negotiated
between I2RS client and I2RS agent from a list of mandatory
transports and optional transports.
</t>
<t hangText="I2RS-DF-REQ-04: Insecure Transport: ">For a few select
data models, the communication between the I2RS client and I2RS agent
MAY run over an insecure transports. The I2RS client and I2RS agent
should negotiate this insecure protocol, and the portion of the
data model which can be sent via the insecure transport SHOULD
be marked in YANG data model with "i2rs-insecure-transport ok".
</t>
<t hangText="I2RS-DF-REQ-05: Resource Contraints on the I2RS Agent: ">
should have the ability to constraints for OAM functions operating
to limit CPU processing, data rate across a transport,
the rate of publication of data in a subscription,
and logging rates.
</t>
<t hangText="I2RS-DF-REQ-06: Alternative Transport protocols or ports: ">
The I2RS should be able to support an OAM actions that select
alternate transports from available list of transports,
and to support selection of alternate ports for these protocols.
The alternate transports may have constraints
specified for security levels, sizes of messages, or data flow priorities.
</t>
<t hangText="I2RS-DF-REQ-07: Priorization of Data Flows: ">
The I2RS Agent should be able to prioritize some of the
management data flows in the I2RS Agent-I2RS Client data flows.
This prioriziation can for data schedule for publication,
data flows within a single transport, or data flows
flows within a single transport, or between multiple
data flow streams an I2RS Agent is sending.
This priorization may be for the data flows the
I2RS Agent is receiving.
</t>
<t hangText="DF-REQ-08: Yang indicates rpc with no validation:">
Yang MUST have a way to indicate rpc can write without validating
data except for syntax of data because I2RS client has validated
data.
<list>
<t>ephemeral-validation nocheck;"</t>
</list>
</t>
<t hangText="DF-REQ-09: Yang for Data sent over insecure transport :">
Yang MUST have a way to indicate in a data model that insecure transmission is
ok.
<list>
<t>i2rs-transport-insecure ok;"</t>
</list>
</t>
</list>
</t>
<t>(Editor's note: This section provides a complete list of the
ephemeral data store requirements. This section may
be removed as it is covered in
<xref target="I-D.hares-i2rs-dataflow-req"></xref>,
and only provided here for convenience of the reader.)
</t>
</section>
</section>
<section title="Error handling">
<t>This section reviews I2RS normal error handling and
error handling for rpc with no validation checks.
</t>
<section title="Normal validation checks ">
<t>
An I2RS agent validates an I2RS client's information
by examining the following:
<list style="symbols">
<t>message syntax validation, </t>
<t>syntax validation for nodes of data model,</t>
<t>referential checks (leafref checks
MUST clauses, and instance indentifier), </t>
<t>checks groups of data within a data model or
groups of data across data models, </t>
<t>write access to data, </t>
<t>if write access and values already exist, if I2RS client
write access is higher than existing priority.</t>
</list>
</t>
<section title="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
an 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>
<t>The I2RS protocol security requires that
each I2RS client has a identity that has a unique identifier
which has one priority and one secondary identitifer associated it during
a write sequence (singel write or multiple group actions (see below).
</t>
<t>
An I2RS client's unique identifier is distributed along with valid roles and
a valid priority via exterior mechanisms (AAA, administrative interface)
to the I2RS agent. The secondary identifier is passed as an opaque
meta value in the I2RS Client write. The exterior mechanism may
change the the valid roles and priority associated with an I2RS client's
identifier. If a change occurs after the I2RS client data has written
information, the I2RS agent must revaluate the writes associate with this
I2RS client (including rpcs). The I2RS agent may schedule this evaluation,
but it should provide the following notifications to the I2RS client:
<list style="symbol">
<t>I2RS agent had received change of priority for I2RS client,</t>
<t>I2RS agent is beginning reevaluation of writes or rpcs associated
with the client due to priority change, </t>
<t>I2RS agent has completed the revaluation due to priority change.</t>
</list>
</t>
</section>
<section title="Multiple Action Messages ">
<t> An I2RS agent receiving multiple action to write data within a message from
an I2RS client must validate the data and check to make sure
this I2RS client has permission and priority to change all the values.
If one of the values in the multiple action messages
fails one of these tests, then error handling must decide
what to do with the rest of the values.
</t>
<t>Error handling in I2RS protocol version 1 simply remove all changed
nodes and restores the previous values (all-or-nothing). In this case,
the short term ephemeral values are kept until the message is processed.
</t>
<t>
Error handling on writes of the ephemeral datastore could be 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,
but the writes do not have to be "all-or-nothing."
</t>
<section title="Grouping and Error handling">
<t>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 title="Why All-or-Nothing ">
<t>NETCONF does not support a mandated sequencing of
edit functions or write functions. Without this
mandated sequences, NETCONF cannot support partial edits.
</t>
<t>RESTCONF has a complete set of operations per message.
The RESTCONF patch <xref target="I-D.ietf-netconf-yang-patch"></xref>
could support partial edit functions per messages. </t>
<t>Since version 1 of I2RS protocol desires to support
NETCONF and RESTCONF equally, the partial
</t>
</section>
<section title="Future Error Handling of Multiple Write Messages">
<t>
The <xref target="I-D.ietf-i2rs-architecture"></xref> specifies three types
of error handling for a partial write operation of orthogonal data:
<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>
Grouped data must only use "all-or-nothing."
</t>
<t>Future I2RS protocol versions will mandate "stop-on-error"
handling or "continue-on-error" handling of multiple orthongal actions
if a RESTCONF "patch" like facility is defined for NETCONF.
</t>
</section>
</section>
</section>
<section title="No Validation for rpcs">
<t>In some circumstances, the I2RS client-agent
communication may be considered almost perfect (99.999%), and
the speed of update critical. In such cases,
the operator may choose to have the I2RS client do
all the validation within a group and between groups
prior to downloading the data, and the I2RS agent
to simply upload the data.
</t>
<t>
The "no validation" feature requires:
<list style="symbols">
<t>operator-applied policy knob enabling this feature;
</t>
<t>rpc in a data model with the yang
"ephemeral-validation no-check;"
</t>
</list>
</t>
</section>
</section>
</section>
<section title="Yang Changes">
<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 Proposed changes to
Yang for I2RS protocol version 1 are:
<list style="symbols">
<t>i2rs:version 1;</t>
<t>i2rs:transport-nonsecure ok;</t>
<t>i2rs:ephemeral-validation nocheck; </t>
<t>ephemeral true; </t>
<t>encoding [XML | JSON] </t>
<t>protocol [RESTCONF | NETCONF] </t>
<t>protocol-transport [ssh, tls, tcp]</t>
<t>transport-ports [ports] </t>
</list>
</t>
<t>Since ephemeral data store, encoding methods,
protocols, protocol transport, and transport ports
are features of the general protocols, these are not
tagged with the "i2rs:" key word.
</t>
</section>
<section title="Transport Protocol Changes">
<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> with
extensions supporting ephemeral, non-secure transport, and
rpcs with no validation checks might look like:
<figure>
<artwork>
extension 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."
}
extension ephemeral-validation-nocheck {
description "if present in rpc definition
the data received in the rpc is considered to
not require validation checks.
}
</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 data store is a part of the intended configuration datastore,
applied configuration datastore, and the derived state store whose
components are not survive a reboot. </t>
<t>The ephemeral capability is signalled as a capability of
a leaf, grouping, a sub-module, or module that is stored as a feature of
the module in the netconf yang module library
(<xref target="I-D.ietf-netconf-yang-library"></xref>) used by Yang 1.1 and
RESTCONF and NETCONF.
</t>
<t>ephemeral data will be noted by an "ephemeral" statement in for a leaf,
grouping, sub-module, or module. </t>
<t>The ephemeral datastore is never locked. </t>
<t>The ephemeral data store is one pane of glass that overrides the local configuration
(which is considered one pane of glass) in the intended config based on
operator-applied policy knobs (see section 2.1).
</t>
<t>Ephemeral data 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 within the module.
Ephemeral modules cannot have non-ephemeral sub-modules or nodes within the module.
Yang 1.1 <xref target="I-D.ietf-netmod-rfc6020bis"></xref> augmented
by ephemeral state must enforce this restriction.
Similarly, the Yang mount schema <xref target="I-D.ietf-netmod-schema-mount"></xref>
must check for this restriction.
</t>
<t>Ephemeral writes should enforce the normal validation checks, priority
pre-emption error handling if multiple I2RS clients write the same data, and
"all-or-nothing" error handling for multiple actions in a write
for data in groupings or orthogonal data (see section 3.4).
The I2RS agent should send the I2RS client requesting write
the notification of any type of error during the write process:
failure of normal validation, priority pre-emption
causing failure to write, multiple actions causing failure to
sustain write (aka all-or-nothing roll-back).
If the I2RS agent allows a priority pre-emption of the write of
data model value by an I2RS client (e.g. client 1) of another
I2RS client (e.g. client 2), then the I2RS agent must send a
notification of the I2RS pre-emption to the previous I2RS
client (e.g. client 2).
</t>
<t>Ephemeral writes as part of an rpc should allow the rpc
to skip normal validation checks if data model specifies
"ephemeral-validation nocheck;". The rpc which skips
the normal validation MUST resolve the
pre-emption write error handling for any data being
written without normal validation check, and MUST
only all the data within a grouping rather than orthogonal data.
</t>
</list>
</t>
</section>
<section title="Dependencies">
<t>The following are the dependencies for ephemeral support:
<list style="symbols">
<t>The Yang definitions specified in section 6. </t>
<t>The Yang modules must support the event notification
write and read errors as well as data model errors.
</t>
<t> The following features must be supported by NETCONF
<list style="symbols">
<t>Call Home <xref target="I-D.ietf-netconf-call-home"></xref>,
</t>
<t>Server Configuratino Module <xref target="I-D.ietf-netconf-server-model"></xref>,
</t>
<t>Module library <xref target="I-D.ietf-netconf-yang-library"></xref>,
</t>
<t>Publication/Subscription via Push <xref target="I-D.ietf-netconf-yang-push"></xref>,
</t>
<t>Patch <xref target="I-D.ietf-netconf-yang-patch"></xref>,
</t>
<t>syslog yang module (both <xref target="RFC5424"></xref>
and <xref target="I-D.ietf-netmod-syslog-model"></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 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>The validation function operates normally with
one addition with one addition for any
data handled by an rpc with
"ephemeral-validation nocheck".
</t>
<t>
The rpc specifying ephemeral-validation nocheck
MUST specify within the ephemeral data written by
the rpc function the following grouping:
<figure>
<artwork>
grouping ephemeral-validation-notcheck {
leaf rpc {
type string rpc-id;
description "rpc wrote
the non-check data";
}
leaf rpc-seq {
type uint32 rpc-id;
description "sequence number of
rpc that wrote non-check data";
}
leaf client-id {
type uint64 client-id;
description "client identifier
that wrote non-checking rpc;"
}
description "Tracking on rpc with
no validation checking so validation
failure can send note to client.";
};
</artwork>
</figure>
If the data validation finds an error in
a component that was non-check, the
notification should include
the data module, submodule
(if valid).
</t>
<t>
(Editor's note: Initial experiments on this type of
rpc for I2RS RIB routes and I2RS FB-RIB filters
will be done before IETF 96.
</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 style="symbols">
<t>The Yang definitions specified in section 6. </t>
<t>The Yang modules must support the event notification
write and read errors as well as data model errors.
</t>
<t> The following features must be supported by RESTCONF
<list style="symbols">
<t>Call Home <xref target="I-D.ietf-netconf-call-home"></xref>,
</t>
<t>Server Configuratino Module <xref target="I-D.ietf-netconf-server-model"></xref>,
</t>
<t>Module library <xref target="I-D.ietf-netconf-yang-library"></xref>,
</t>
<t>Publication/Subscription via Push <xref target="I-D.ietf-netconf-yang-push"></xref>,
</t>
<t>Patch <xref target="I-D.ietf-netconf-yang-patch"></xref>,
</t>
<t>syslog yang module (both <xref target="RFC5424"></xref>
and <xref target="I-D.ietf-netmod-syslog-model"></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 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.
The desired-temp is local configuration node
that has an ephemeral
The actual temperature is a derived state
node that records the actual temperature of
the room.
</t>
<t>
Figure 6 shows two I2RS clients.
I2RS client 1 has one connection to write the
ephemeral copy of the desired temperature at
priority 1. I2RS client 2 writes
to the intended configuration with priority 10.
I2RS client 1 has a second connetion to read
the actual temperature, and I2RS client 2
also has a second connection to read the actual
temperature.
</t>
<t>The NETCONF example shows a simple
write of the ephemeral state value
over the local configuration
</t>
<t>
<figure>
<artwork>
........... ................... ...........
:Candidate :---:running config :--: start-up :
: : :desired-temp (cfg): : :
........... .................. ...........
|
| ==========
| | I2RS |
| +-|Client 1|
| | |=========
.........|..................... |
Intended . '''''''|''''''''''''''''''' . | =========
Config . 'local config|ephemeral '<--| |I2RS |
. 'desired-temp|desired-temp'<----|Client 2|
. ''''''''''''|'''''''''''''' . ==========
..............|................
| read-write data
-------------------|----------------------------------------
| read only data
|
======|====== ---------------
| Actual |-----|I2RS client 1|
Config true | Config | ---------------
| desired- | |
| temp |==============
============= | ||
******************************** | ||
config false | derived |------+ ||
| state | ===============
| actual- |=======|I2RS Client 2 |
| temp | ===============
-------------
Policy Knob 1:Ephemeral overwrites local config (TRUE)
Policy Knob 2:Updated local config overwrite ephemeral (FALSE)
Figure 6 - Two I2RS clients
</artwork>
</figure>
</t>
<section title="YANG data model">
<t>
<figure>
<artwork>
module thermostat {
..
leaf desired-temp {
type int32;
config true;
ephemeral true;
units "degrees Celsius";
description "The desired temperature";
}
....
leaf actual-temp {
type int32;
config false;
units "degrees Celsius";
description "The measured
temperature is derived state.
}
}
Figure 6 - Simple thermostat YANG Model
</artwork>
</figure>
</t>
<t>The changes in each step are shown in the
figure 7. In step 1, the running configuration
desired-temp is change to 68 degress.
In step 2, the intended configuration
value for desired-temp is updated, and asynchronously
the applied configuration is updated in step 4.
The actual temperature begins to rise to meet the
desired temperature, and reaches it in step 4.
In step 5, I2RS client 1 update the intended
configuration with a desired-temp=70.
In step 6 this value is updated to the applied
configuration, and the actual temperature begins
to rise (actual-temp = 69). In step 7,
the actual temperature has reached 70 degrees.
In step 8, I2RS Client 1 removes the ephemeral
state from the intended configuration
and the local configuration value is reasserted.
In step 9, the intended desired-temp is
synchronously moved to applied configuration
and the actual temperature drops.
</t>
<t>
<figure>
<artwork>
Step Running Intended Config Applied Config Derived
state
======================================================
1 desired- actual-
temp=68 temp=65
------------------------------------------------------
2 desired- from running actual-
temp=68 desired-temp temp=65
temp = 68
------------------------------------------------------
3 Desired Desired Desired Actual-
temp=68 temp=68 temp=68 temp=67
-------------------------------------------------------
4 Desired Desired Desired Actual-
temp=68 temp=68 temp=68 temp=68
------------------------------------------------------
from I2RS
client 1
5 Desired Desired Desired Actual-
temp=68 temp=70 temp=68 temp=68
------------------------------------------------------
6 Desired Desired Desired Actual-
temp=68 temp=70 temp=70 temp=69
------------------------------------------------------
7 Desired Desired Desired Actual-
temp=68 temp=70 temp=70 temp=70
------------------------------------------------------
I2RS client 1
removes state
8 Desired Desired Desired Actual-
temp=68 temp=68 temp=70 temp=70
-----------------------------------------------------
9 Desired Desired Desired Actual-
temp=68 temp=68 temp=68 temp=68
======================================================
Figure 7
</artwork>
</figure>
</t>
<t>
I2RS Client 1 handle the normal lowering
and raising of the temperature during different
time periods in the day. I2RS Client 2 has the
ability for individuals to request the room warms
up rapidly to a maximum of 72 degrees. Figure 8
shows a simple example of the two clients interaction.
Steps 1-6 are the same as in figure 7. In step 7,
I2RS Client 2 sets the desired-temp in the
intended configuration to 72. In step 8,
this intended configuration is passed to the
applied configuration and the actual temperature
reaches 72.
</t>
<t>In step 9, I2RS client 2 removes
its state. The I2RS Client 1 is notified of
the removal, and the I2RS Client 1 re-write
the desired value of 70 degrees (desired-temp=70),
and this is passed to the applied state.
The actual temperature drops to 70 degress
(actual-temp=70). In step 10, I2RS Client 1
removes its ephemeral state and desired-temp
reverts to the local configuration value
(desired=temp=68). This value is installed
in applied temperature and the actual temperature
goes to 68 (actual-temp=68.)
</t>
<t>
<figure>
<artwork>
Step Running Intended Config Applied Config Derived
state
======================================================
1 desired- actual-
temp=68 temp=65
------------------------------------------------------
2 Desired from running actual-
temp=68 desired-temp temp=65
temp = 68
------------------------------------------------------
3 Desired Desired Desired Actual-
temp=68 temp=68 temp=68 temp=67
-------------------------------------------------------
4 Desired Desired Desired Actual-
temp=68 temp=68 temp=68 temp=68
------------------------------------------------------
from I2rs
client 1
5 Desired Desired Desired Actual-
temp=68 temp=70 temp=68 temp=68
------------------------------------------------------
6 Desired Desired Desired Actual-
temp=68 temp=70 temp=70 temp=69
------------------------------------------------------
I2RS Client 2
sets
7 Desired Desired Desired Actual-
temp=68 temp=72 temp=70 temp=70
------------------------------------------------------
8 Desired Desired Desired Actual-
temp=68 temp=72 temp=72 temp=72
-----------------------------------------------------
I2RS client 2 removes state
reverts to I2RS client 1
9 Desired Desired Desired Actual-
temp=68 temp=70 temp=70 temp=70
-----------------------------------------------------
I2RS client 1 removes state
10 Desired Desired Desired Actual-
temp=68 temp=68 temp=68 temp=68
======================================================
Figure 8
</artwork>
</figure>
</t>
</section>
<section title="NETCONF Changes" >
<t>
The NETCONF way of writing the ephemeral data to
the intended configuratino 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> 70 </desired-temp>
</top>
</config>
</edit-config>
</rpc>
figure 9 NETCONF setting of desired-temp
</artwork>
</figure>
</t>
</section>
<section title="RESTCONF Initial Write">
<t>
Figure 10 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 ephemeral datastore
PUT /restconf/data/thermostat:desired-temp?context=ephemeral
{"desired-temp":19 }
Figure 8 - RESTCONF setting of ephemeral state
</artwork>
</figure>
</t>
</section>
</section>
<section title="Simple Route Add">
<t>
In this discussion of ephemeral configuration,
this draft utilizes the I2RS RIB data model
<xref target="I-D.ietf-i2rs-rib-data-model"></xref>
where one client adds an route
via a rpc to the I2RS ephemeral data model.
</t>
<t>
Figure 9 shows two I2RS clients. I2RS client 1
writes ephemeral routes with priority 1,
and I2RS client 2 writes ephemeral routes with
priority 5. I2RS Client 1 and I2RS client can read
the I2RS RIB With its status of installation.
For ease of display the I2RS client 1 is show
as two separate boxes, but these boxes are logically
one client. Client 2 is also shown as two boxes, but
has only one box.
<figure>
<artwork>
........... ................... ...........
:Candidate :---:running config :--: start-up :
: : :desired-temp (cfg): : :
........... .................. ...........
|
| ==========
| | I2RS |
| +-|Client 1|
| | |=========
.........|................... |
Intended . '''''''|''''''''''''''''' . | =========
Config . 'local config|ephemeral '<--| |I2RS |
. ' route | route '<----|Client 2|
. ''''''''''''|''''''''''' . ==========
..............|.............
read-write data
------------------------------------------------------------
| read only data
|
============= ---------------
| Actual |-----|I2RS client 1|
Config true | Config | ---------------
| route | |
| |==============
============= | ||
******************************** | ||
config false | derived |------+ ||
| state | ===============
| route |=======|I2RS Client 2 |
| active | ===============
-------------
Policy Knob 1:Ephemeral overwrites local config (TRUE)
Policy Knob 2:Updated local config overwrite ephemeral (FALSE)
Figure 11 - Two I2RS clients
</artwork>
</figure>
</t>
<t>
Figure 10 shows the addition of routes to
a IPv4 RIB using the rpc-add route function
in the I2RS RIB <xref target="I-D.ietf-i2rs-rib-data-model"></xref>.
Step 1 shows the route being configured
via netconf as a static route, and step
2 shows how this static route is installed in the
intended configuration. Step 3 shows
how this static route is installed in the applied
configuration and the derived status "installed"
is added to the routing devices route table.
Step 4 shows how the I2RS Client 1 adds
the same route with a different next hop.
In this example, there is only one nexthop per
route so the ephemeral route replaces static
route configuration and is synchronously installed
in the applied configuration. Due to the
installation, the "installed" state is recorded in
the kernel and associated with the I2RS RIB route.
</t>
<t>In step 5, I2RS client 2 adds the same
route to the intended configuration with a
different next hop which replaces the route
added by I2RS client 1 because I2RS Client 2
has a higher priority that client 1.
</t>
<t>In step 6, I2RS client 2 removes the route.
and the I2RS client 1 is notified of the removal.
The I2RS client 1 re-write the route with
a nexthop of 192.11.1.2, and the applied configuration
is updasted.
</t>
<t>
In step 7, the I2RS Client 1 removes route and
the local configuration is restored in the intended
configuration. The intended configuration sent to
applied configuration as part of the restoration.
</t>
<t>
<figure>
<artwork>
Step Running Intended Config Applied Config Derived
state
======================================================
1 route=
128.2/16
nexthop=
192.11.1.1
------------------------------------------------------
2 route= route=
128.2/16 128.2/16
nexthop= nexthop=
192.11.1.1 192.11.1.1
------------------------------------------------------
3 route= route= route= route-
128.2/16 128.2/16 128.2/16 128.2/16
nexthop= nexthop= nexthop= nexthop=
192.11.1.1 192.11.1.1 192.11.1.1 192.11.1.1
status-installed
-------------------------------------------------------
I2RS
client 1
rpc route-add
4 route= route= route= route-
128.2/16 128.2/16 128.2/16 128.2/16
nexthop= nexthop= nexthop= nexthop=
192.11.1.1 192.11.1.2 192.11.1.2 192.11.1.2
status-installed
---------------------------------------------------------------
from I2RS client 2
5 route= route= route= route-
128.2/16 128.2/16 128.2/16 128.2/16
nexthop= nexthop= nexthop= nexthop=
192.11.1.1 192.11.1.3 192.11.1.3 192.11.1.3
status-installed
---------------------------------------------------------------
I2RS Client2 removes route
and I2RS agent notifies
I2RS Client of change.
I2RS client 1 re-writes route.
6 route= route= route= route-
128.2/16 128.2/16 128.2/16 128.2/16
nexthop= nexthop= nexthop= nexthop=
192.11.1.1 192.11.1.2 192.11.1.2 192.11.1.2
status-installed
---------------------------------------------------------------
I2RS client 1
removes route
local configuration is restored
7 route= route= route= route-
128.2/16 128.2/16 128.2/16 128.2/16
nexthop= nexthop= nexthop= nexthop=
192.11.1.1 192.11.1.1 192.11.1.1 192.11.1.1
status-installed
================================================================
Figure 12
</artwork>
</figure>
</t>
<section title="Portions of I2RS YANG data model">
<t>
<figure>
<artwork>
module I2rs-RIB {
..
module i2rs-rib {
container routing-instance {
…
list rib-list {
…
list route-list {
key “route-index”;
uses route;
}
}
....
grouping route {
description
“The common attribute used for all routes;”
uses routeg-prefix;
container nexthop {
uses nexthop;
}
container route-statistics {
leaf route-state {
type route-state-def;
config false; /* operational state */
}
leaf route-installed state {
type route-installed-state def;
config false;
}
leaf route-reason {
type route-reason-def;
config false;
}
}
container router-attributes {
uses router-attributes;
}
container route-vendor-attributes
uses route-vendor attributes;
}
}
Figure 13 - Simplified I2RS Route Model
</artwork>
</figure>
</t>
</section>
<section title="NETCONF Changes" >
<t>
The NETCONF way of writing the ephemeral I2RS data would be:
<figure>
<artwork>
(TBD)
Figure 14
</artwork>
</figure>
</t>
</section>
<section title="RESTCONF Changes">
<t>
Figure 8 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 ephemeral datastore
(TBD)
Figure 15 - RESTCONF Route change
</artwork>
</figure>
</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:">
&RFC2119;
&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-netconf-yang-patch;
&I-D.ietf-netconf-yang-push;
&I-D.ietf-netconf-restconf;
&I-D.ietf-netconf-yang-library;
&I-D.ietf-netconf-server-model;
&I-D.ietf-netconf-call-home;
&I-D.ietf-netmod-rfc6020bis;
&I-D.ietf-netmod-opstate-reqs;
&I-D.ietf-netmod-yang-metadata;
&I-D.ietf-netmod-syslog-model;
&I-D.ietf-netmod-schema-mount;
&RFC5424;
&RFC6241;
&RFC6244;
&RFC7158;
&RFC7589;
</references>
<references title="Informative References">
&RFC4107;
&RFC4960;
&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:36:11 |