draft-ietf-i2rs-ephemeral-state-00.txt | draft-ietf-i2rs-ephemeral-state-01.txt | |||
---|---|---|---|---|
I2RS working group J. Haas | I2RS working group J. Haas | |||
Internet-Draft Juniper | Internet-Draft Juniper | |||
Intended status: Standards Track S. Hares | Intended status: Standards Track S. Hares | |||
Expires: December 25, 2015 Huawei | Expires: February 29, 2016 Huawei | |||
June 23, 2015 | August 28, 2015 | |||
I2RS Ephemeral State Requirements | I2RS Ephemeral State Requirements | |||
draft-ietf-i2rs-ephemeral-state-00 | draft-ietf-i2rs-ephemeral-state-01 | |||
Abstract | Abstract | |||
This document covers requests to the netmod and netconf Working | This document covers requests to the netmod and netconf Working | |||
Groups for functionality to support the ephemeral state requirements | Groups for functionality to support the ephemeral state requirements | |||
to implement the I2RS architecture. | to implement the I2RS architecture. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 33 | skipping to change at page 1, line 33 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on December 25, 2015. | This Internet-Draft will expire on February 29, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 12 | skipping to change at page 2, line 12 | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Review of Requirements from I2RS architecture document . . . 3 | 2. Review of Requirements from I2RS architecture document . . . 3 | |||
3. Ephemeral State Requirements . . . . . . . . . . . . . . . . 4 | 3. Ephemeral State Requirements . . . . . . . . . . . . . . . . 4 | |||
3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. changes to YANG . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.4. changes to YANG . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Changes to NETCONF . . . . . . . . . . . . . . . . . . . . . 5 | 3.5. Minimal sub-set of Changes . . . . . . . . . . . . . . . 5 | |||
6. Requirements regarding Identity, Secondary-Identity and | 3.6. Requirements regarding Identity, Secondary-Identity and | |||
Priority . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | Priority . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
6.1. Identity Requirements . . . . . . . . . . . . . . . . . . 6 | 3.6.1. Identity Requirements . . . . . . . . . . . . . . . . 5 | |||
6.2. Priority Requirements . . . . . . . . . . . . . . . . . . 6 | 3.6.2. Priority Requirements . . . . . . . . . . . . . . . . 5 | |||
6.3. Representing I2RS Attributes in ephemeral configuration | 3.6.3. Transactions . . . . . . . . . . . . . . . . . . . . 6 | |||
state . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.6.4. Subscriptions to Changed State Requirements . . . . . 7 | |||
6.4. Semantics around storing and managing of priority and | 4. Previously Considered Ideas . . . . . . . . . . . . . . . . . 8 | |||
client ID. . . . . . . . . . . . . . . . . . . . . . . . 7 | 4.1. A Separate Ephemeral Datastore . . . . . . . . . . . . . 8 | |||
7. Subscriptions to Changed State Requirements . . . . . . . . . 9 | 4.2. Panes of Glass/Overlay . . . . . . . . . . . . . . . . . 8 | |||
8. Transactions . . . . . . . . . . . . . . . . . . . . . . . . 10 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
9. Previously Considered Ideas . . . . . . . . . . . . . . . . . 10 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
9.1. A Separate Ephemeral Datastore . . . . . . . . . . . . . 10 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | |||
9.2. Panes of Glass/Overlay . . . . . . . . . . . . . . . . . 11 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
10. Actions Required to Implement this Draft . . . . . . . . . . 11 | 8.1. Normative References: . . . . . . . . . . . . . . . . . . 10 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 8.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
14.1. Normative References: . . . . . . . . . . . . . . . . . 12 | ||||
14.2. Informative References . . . . . . . . . . . . . . . . . 13 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
1. Introduction | 1. Introduction | |||
The Interface to the Routing System (I2RS) Working Group is chartered | The Interface to the Routing System (I2RS) Working Group is chartered | |||
with providing architecture and mechanisms to inject into and | with providing architecture and mechanisms to inject into and | |||
retrieve information from the routing system. The I2RS Architecture | retrieve information from the routing system. The I2RS Architecture | |||
document [I-D.ietf-i2rs-architecture] abstractly documents a number | document [I-D.ietf-i2rs-architecture] abstractly documents a number | |||
of requirements for implementing the I2RS requirements. | of requirements for implementing the I2RS requirements. | |||
The I2RS Working Group has chosen to use the YANG data modeling | The I2RS Working Group has chosen to use the YANG data modeling | |||
language [RFC6020] as the basis to implement its mechanisms. | language [RFC6020] as the basis to implement its mechanisms. | |||
Additionally, the I2RS Working group has chosen to use the NETCONF | Additionally, the I2RS Working group has chosen to use the NETCONF | |||
[RFC6241] and its similar but lighter-weight relative RESTCONF | [RFC6241] and its similar but lighter-weight relative RESTCONF | |||
[I-D.bierman-netconf-restconf] as the protocols for carrying I2RS. | [I-D.ietf-netconf-restconf] as the protocols for carrying I2RS. | |||
While YANG, NETCONF and RESTCONF are a good starting basis for I2RS, | While YANG, NETCONF and RESTCONF are a good starting basis for I2RS, | |||
there are some things needed from each of them in order for I2RS to | there are some things needed from each of them in order for I2RS to | |||
be implemented. | be implemented. | |||
2. Review of Requirements from I2RS architecture document | 2. Review of Requirements from I2RS architecture document | |||
The following are ten requirements that [I-D.ietf-i2rs-architecture] | The following are ten requirements that [I-D.ietf-i2rs-architecture] | |||
contains which are important high level requirements: | contains which are important high level requirements: | |||
skipping to change at page 4, line 26 | skipping to change at page 4, line 22 | |||
10. The I2RS protocol MUST support the use of a secure transport. | 10. The I2RS protocol MUST support the use of a secure transport. | |||
However, certain functions such as notifications MAY use a non- | However, certain functions such as notifications MAY use a non- | |||
secure transport. Each model or service (notification, logging) | secure transport. Each model or service (notification, logging) | |||
must define within the model or service the valid uses of a non- | must define within the model or service the valid uses of a non- | |||
secure transport. | secure transport. | |||
3. Ephemeral State Requirements | 3. Ephemeral State Requirements | |||
3.1. Persistence | 3.1. Persistence | |||
I2RS requires ephemeral state; i.e. state that does not persist | Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does | |||
across reboots. If state must be restored, it should be done solely | not persist across reboots. If state must be restored, it should be | |||
by replay actions from the I2RS client via the I2RS agent. | done solely by replay actions from the I2RS client via the I2RS | |||
agent. | ||||
While at first glance this may seem equivalent to the writable- | While at first glance this may seem equivalent to the writable- | |||
running datastore in NETCONF, running-config can be copied to a | running datastore in NETCONF, running-config can be copied to a | |||
persistant data store, like startup config. I2RS ephemeral state | persistant data store, like startup config. I2RS ephemeral state | |||
MUST NOT be persisted. | MUST NOT be persisted. | |||
3.2. Constraints | 3.2. Constraints | |||
Ephemeral state MAY refer to non-ephemeral state for purposes of | Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral | |||
implementing constraints. The designer of ephemeral state modules | state for constraint purposes; it SHALL be considered a validation | |||
are advised that such constraints may impact the speed of processing | error if it does. | |||
ephemeral state commits and should avoid them when speed is | ||||
essential. | ||||
Non-ephemeral state MUST NOT refer to ephemeral state for constraint | ||||
purposes; it SHALL be considered a validation error if it does. | ||||
3.3. Hierarchy | ||||
Similar to configuration state (config true, see [RFC6020], section | ||||
7.19.1), ephemeral state is not permitted to be configured underneath | ||||
nodes that are "config false" (state data). | ||||
Configuration of ephemeral state underneath "config true" is | ||||
permitted. This permits augmentation of configuration state with | ||||
ephemeral nodes. | ||||
Configuration of "config true" state underneath ephemeral state MUST | ||||
NOT be done. | ||||
State data, "config false", is permitted underneath ephemeral state. | ||||
This state data is part of the ephemeral module and should become | ||||
inaccessible if the ephemeral module reboots. | ||||
4. changes to YANG | Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary | |||
operational state which (MPLS LSP-ID or a BGP IN-RIB) as a | ||||
constraints. | ||||
The YANG "config" keyword ([RFC6020], section 7.19.1) is extended to | Ephemeral-REQ-04> Ephemeral state MAY refer to non-ephemeral state | |||
support the keyword "ephemeral" in addition to "true" and "false". | for purposes of implementing constraints. The designer of ephemeral | |||
"config ephemeral" declares the nodes underneath to be ephemeral | state modules are advised that such constraints may impact the speed | |||
configuration. | of processing ephemeral state commits and should avoid them when | |||
speed is essential. | ||||
5. Changes to NETCONF | 3.3. Hierarchy | |||
A capability is registered declaring that the server supports | Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of | |||
ephemeral configuration. E.g.: | objects) that have the property of being ephemeral. An object needs | |||
to be able to have (both) the property of being writable and the | ||||
property of the data being ephemeral (or non-ephemeral). | ||||
:ephemeral-config | 3.4. changes to YANG | |||
urn:ietf:params:netconf:capability:ephemeral-config:1.0 | ||||
<get-config> will normally return "config ephemeral" nodes as it is a | Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model | |||
form of configuration. It is further extended to add a new | that nodes have the following properties: ephemeral, writable/not- | |||
parameter, "filter-ephemeral". This parameter accepts the following | writable, status/configuration. | |||
arguments: | ||||
o none (default): No filtering of persistent or ephemeral state is | 3.5. Minimal sub-set of Changes | |||
done. | ||||
o ephemeral-only: Only nodes representing ephemeral state are | Ephemeral-REQ-07: The minimal set is ... | |||
returned. | ||||
o exclude-ephemeral: Only persistent configuration is returned. | Potential set: | |||
<get> is similarly extended to support "filter-ephemeral". | 3.6. Requirements regarding Identity, Secondary-Identity and Priority | |||
When a <copy-config> is done, regardless of datastore, nodes that are | 3.6.1. Identity Requirements | |||
"config ephemeral" are excluded from the target output. | ||||
6. Requirements regarding Identity, Secondary-Identity and Priority | Ephemeral-REQ-08:Clients shall have identities, and secondary | |||
identities. | ||||
6.1. Identity Requirements | Explanation | |||
I2RS requires clients to have an identity. This identity will be | I2RS requires clients to have an identity. This identity will be | |||
used by the Agent authentication mechanism over the appropriate | used by the Agent authentication mechanism over the appropriate | |||
protocol. | protocol. | |||
I2RS also permits clients to have a secondary identity which may be | The Secondary identities can be carried as part of RPC or meta-data. | |||
used for troubleshooting. This secondary identity is an opaque | The primary purpose of the secondary identity is for traceability | |||
value. [I-D.ietf-i2rs-traceability] provides an example of how the | information which logs (who modifies certain nodes). This secondary | |||
secondary identity can be used for traceability. | identity is an opaque value. [I-D.ietf-i2rs-traceability] provides | |||
an example of how the secondary identity can be used for | ||||
The secondary identity is carried in the configuration operation | traceability. | |||
using a new parameter to <edit-config>. E.g.: | ||||
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> | ||||
<edit-config> | ||||
<i2rs:irs-secondary-identity>user1</i2rs> | ||||
<target> | ||||
<running/> | ||||
</target> | ||||
<config> | ||||
<top xmlns="http://example.com/schema/1.2/config"> | ||||
<interface> | ||||
<name>Ethernet0/0</name> | ||||
<mtu>1500</mtu> | ||||
</interface> | ||||
</top> | ||||
</config> | ||||
</edit-config> | ||||
</rpc> | ||||
"config ephemeral" nodes that are created or altered as part of the | ||||
config operation will carry the secondary-identity as read-only | ||||
metadata. | ||||
6.2. Priority Requirements | 3.6.2. Priority Requirements | |||
To support Multi-Headed Control, I2RS requires that there be a | To support Multi-Headed Control, I2RS requires that there be a | |||
decidable means of arbitrating the correct state of data when | decidable means of arbitrating the correct state of data when | |||
multiple clients attempt to manipulate the same piece of data. This | multiple clients attempt to manipulate the same piece of data. This | |||
is done via a priority mechanism with the highest priority winning. | is done via a priority mechanism with the highest priority winning. | |||
This priority is per-client. | This priority is per-client. | |||
This further implies that priority is an attribute that is stored in | Ephemeral-REQ-09: The data nodes MAY store I2RS client identity and | |||
the NETCONF Access Control Model [RFC6536] as part of the group. | not the effective priority at the time the data node is stored. The | |||
E.g.: | I2RS Client MUST have one priority at a time. The priority MAY be | |||
dynamically changed by AAA, but the exact actions are part of the | ||||
protocol definition as long as Collisions are handled as described in | ||||
Ephemeral-REQ-10, Ephemeral-REQ-11, and Ephemeral-REQ-12. | ||||
+--rw nacm | Ephemeral-REQ-10: When a collision occurs as two clients are trying | |||
+--rw enable-nacm? boolean | to write the same data node, this collision is considered an error | |||
+--rw read-default? action-type | and priorities were created to give a deterministic result. When | |||
+--rw write-default? action-type | there is a collision, a notification MUST BE sent to the original | |||
+--rw exec-default? action-type | client to give the original client a chance to deal with the issues | |||
+--rw enable-external-groups? boolean | surrounding the collision. The original client may need to fix their | |||
+--ro denied-operations yang:zero-based-counter32 | state. | |||
+--ro denied-data-writes yang:zero-based-counter32 | ||||
+--ro denied-notifications yang:zero-based-counter32 | Ephemeral-REQ-11: The requirement to support multi-headed control is | |||
+--rw groups | required for collisions and the priority resolution of collisions. | |||
| +--rw group [name] | Multi-headed control is not tied to ephemeral state. I2RS is not | |||
| +--rw name group-name-type | mandating how AAA supports priority. Mechanisms which prevent | |||
| +--rw user-name* user-name-type | collisions of two clients trying the same node of data are the focus. | |||
| +--rw i2rs:i2rs-priority i2rs-priority-type | ||||
Ephemeral-REQ-12: If two clients have the same priority, the | ||||
architecture says the first one wins. The I2RS protocol has this | ||||
requirement to prevent was the oscillation between clients. If one | ||||
uses the last wins scenario, you may oscillate. That was our | ||||
opinion, but a design which prevents oscillation is the key point. | ||||
Hints for Implementation | ||||
Ephemeral configuration state nodes that are created or altered by | Ephemeral configuration state nodes that are created or altered by | |||
users that match a rule carrying i2rs-priority will have those nodes | users that match a rule carrying i2rs-priority will have those nodes | |||
annotated with metadata. Additionally, during commit processing, if | annotated with metadata. Additionally, during commit processing, if | |||
nodes are found where i2rs-priority is already present, and the | nodes are found where i2rs-priority is already present, and the | |||
priority is better than the transaction's user's priority for that | priority is better than the transaction's user's priority for that | |||
node, the commit SHALL fail. An appropriate error should be returned | node, the commit should fail. An appropriate error should be | |||
to the user stating the nodes where the user had insufficient | returned to the user stating the nodes where the user had | |||
priority to override the state. | insufficient priority to override the state. | |||
6.3. Representing I2RS Attributes in ephemeral configuration state | ||||
I2RS attributes may be modeled as meta-data, | ||||
[I-D.ietf-netmod-yang-metadata]. This meta-data MUST be read-only; | ||||
operations attempting to alter it MUST be silently ignored. An I2RS | ||||
module will be defined to document this meta data. An example of its | ||||
use: | ||||
<foo xmlns:i2rs="https://ietf.example.com/i2rs" | ||||
i2rs:i2rs-secondary-identity="user1" i2rs:i2rs-priority="47"> | ||||
... | ||||
</foo> | ||||
6.4. Semantics around storing and managing of priority and client ID. | ||||
The semantics and desired behavior around the storing and managing of | ||||
priority and client ID have the following properties: | ||||
1. First - the priority mechanism is intended to handle "error cases | ||||
of colliding writes" in a predictable way that results in a | ||||
consistent mechanism. It is true that the same mechanism could | ||||
be used if they were not considered "errors", but it is important | ||||
to minimize the need and impact of the priority mechanism | ||||
2. Second, if there is a priority conflict where both clients | ||||
(Client_A and Client_B) share the same priority, the client that | ||||
wrote first wins. This is to avoid network oscillation if two | ||||
clients are "fighting" over writing the same state. When there | ||||
are multiple clients and the time arrival of the messages may not | ||||
be predictable (network transit differences, which socket is | ||||
read, software differences), basing state on last arrival time | ||||
doesn't give consistent and predictable behavior. That gives | ||||
behavior ont the following time-line | ||||
1. Time_1: Client_A writes X=N with priority 10 | ||||
2. Time_2: Client_B attempts to write X=K with priority 10 and | ||||
is rejected | ||||
3. Time_3: Client_A writes X=P with priority 10 and succeeds | ||||
For the I2RS Agent to properly handle these actions, it is | ||||
necessary to know that X is owned by Client_A. Priority alone is | ||||
not sufficient because the basis for rejecting Client_B's write | ||||
but accepting Client_A's write is that Client_A is the owner. | ||||
Thus it is necessary to store the Client Identity with the nodes | ||||
that it owns. This could be in an I2RS-specific overlay that is | ||||
only used by the I2RS agent and only contains the nodes that have | ||||
been written by I2RS. | ||||
3. Third, a question has come up regarding what the behavior of | ||||
priority is if a client's priority changes and whether priority | ||||
needs to be stored with each node when that node is written. In | ||||
my "keep-it-simple" perspective, priority is associated with a | ||||
Client and is only used on a conflict. This would mean that | ||||
priority is not stored with a node when that node is written. | ||||
Instead, the Client Identity is stored with the node and the | ||||
Client's priority is looked up in a client table that the I2RS | ||||
Agent can access. That client table could be populated via | ||||
configuration, via a AAA protocol, via NACM, etc. The sematic | ||||
implications are as follows: | ||||
1. Time_1: Client_A writes X=N with priority 10 | ||||
2. Time_2: Client_A's priority is changed (UNUSUAL) to priority | ||||
6 | ||||
3. Time_3: Client_B writes X=K with priority 8 (succeeds since 8 | ||||
> 6) | ||||
4. Time_4: Client_A attempts to write X=N with priority 6 (fails | ||||
b/c 8 > > 6) | ||||
5. Time_5: Client_B's priority is changed (UNUSUAL) to priority | ||||
7 | ||||
6. Time_6 Client_B writes X=P with priority 7 and succeeds (same | ||||
> owner, no priority check) | ||||
The alternate approach would have store the priority with which a | 3.6.3. Transactions | |||
node was written. That is more like a priority lock that could | ||||
only be changed by a client with higher priority or by the same | ||||
client, regardless of priority. This approach would require | ||||
storing a priority per node and the semantic implications would | ||||
be as follows: | ||||
1. Time_1:Client_A writes X=N with priority 10 | Ephemeral-REQ-13: Section 7.9 of the [I-D.ietf-i2rs-architecture] | |||
states the I2RS architecture does not include multi-message atomicity | ||||
and roll-back mechanisms, but suggests an I2RS client may indicates | ||||
one of the following error handling techniques for a given message | ||||
sent to the I2RS client: | ||||
2. Time_2:Client_A's priority is changed (UNUSUAL) to priority 6 | 1. Perform all or none: All operations succeed or none of them will | |||
be applied. This useful when there are mutual dependencies. | ||||
3. Time_3: Client_B attempts to write X=K with priority 8 and | 2. Perform until error: Operations are applied in order, and when | |||
fails (10 > 8) | error occurs the processing stops. This is useful when | |||
dependencies exist between multiple-message operations, and order | ||||
is important. | ||||
4. Time_4: Client_A writes X=N with priority 6 and succeeds | 3. Perform all storing errors: Perform all actions storing error | |||
(same owner, no priority check) | indications for errors. This method can be used when there are | |||
no dependencies between operations, and the client wants to sort | ||||
it out. | ||||
5. Time_5: Client_B's priority is changed (UNUSUAL) to priority | I2RS-REQ-XX: None of these three error handling for multi-message | |||
7 | cases SHOULD cause errors into be insert the I2RS ephemeral data- | |||
store. | ||||
6. Time_6 Client_B writes X=P with priority 7 and succeeds (7 > | Discussion of Current NETCONF/RESTCONF versus | |||
6) | ||||
The behavior for these two models is different at Time_3 and | RESTCONF does an atomic action within a http session, and NETCONF has | |||
Time_4. | atomic actions within a commit. These features may be used to | |||
perform these features. | ||||
The initial preference was that the priority is not stored with the | I2RS processing is dependent on the I2RS model. The I2RS model must | |||
node, but if it necessary to store it with the node additional | consider the dependencies within multiple operations work within a | |||
discussion may be needed with the I2RS WG. | model. | |||
7. Subscriptions to Changed State Requirements | 3.6.4. Subscriptions to Changed State Requirements | |||
I2RS clients require the ability to monitor changes to ephemeral | I2RS clients require the ability to monitor changes to ephemeral | |||
state. While subscriptions are well defined for receiving | state. While subscriptions are well defined for receiving | |||
notifications, the need to create a notification set for all | notifications, the need to create a notification set for all | |||
ephemeral configuration state may be overly burdensome to the user. | ephemeral configuration state may be overly burdensome to the user. | |||
There is thus a need for a general subscription mechanism that can | There is thus a need for a general subscription mechanism that can | |||
provide notification of changed state, with sufficient information to | provide notification of changed state, with sufficient information to | |||
permit the client to retrieve the impacted nodes. This should be | permit the client to retrieve the impacted nodes. This should be | |||
doable without requiring the notifications to be created as part of | doable without requiring the notifications to be created as part of | |||
every single I2RS module. | every single I2RS module. | |||
8. Transactions | The following requirements from the | |||
[I-D.ietf-i2rs-pub-sub-requirements] apply to ephemeral state: | ||||
Section 7.9 of the [I-D.ietf-i2rs-architecture] states the I2RS | o PubSub-REQ-1: The I2RS interface SHOULD support user subscriptions | |||
architecture does not include multi-message atomicity and rollback | to data with the following parameters: push of data synchronously | |||
mechanisms, but suggests an I2RS client may inidicate one of the | or asynchronously via registered subscriptions. | |||
following error handling techniques for a given message sent to the | ||||
I2RS client: | ||||
1. Perform all or none: All operations succeed or none of them will | o PubSSub-REQ-2: Real time for notifications SHOULD BEdefined | |||
be applied. This useful when there are mutual dependencies. | defined by the data models. | |||
2. Perform until error: Operations are applied in order, and when | o PubSub-REQ-3: Security of the pub/sub data stream SHOULD be able | |||
error occurs the processing stops. This is useful when | to be model dependent. | |||
dependencies exist between multiple-message operations, and order | ||||
is important. | ||||
3. Perform all storing errors: Perform all actions storing error | o PubSub-REQ-4: The Pub/Sub mechanism SHOULD allow subscription to | |||
indications for errors. This method can be used when there are | critical Node Events. Examples of critical node events are BGP | |||
no dependencies between operations, and the client wants to sort | peers down or ISIS protocol overload bits. | |||
it out. | ||||
None of these three cases insert known errors into the I2RS ephemeral | o PubSub-REQ-5:I2RS telemetry data for certain protocols (E.g. BGP) | |||
datastore. | will require a hierarchy of filters or XPATHs. The I2RS protocol | |||
design MUST balance security against the throughput of the | ||||
telemetry data. | ||||
RESTCONF does an atomic action within a http session, and NETCONF has | o PubSub-REQ-6: I2RS Filters SHOULD be able to be dynamic. | |||
atomic actions within a commit. These features may be used to | ||||
perform these features. | ||||
I2RS processing is dependent on the I2RS model. The I2RS model must | o Pub-Sub-REQ-7: I2rs protocol MUST be able to allow I2RS agent to | |||
consider the dependencies within multiple operations work within a | set limits on the data models it will support for pub/sub and | |||
model. | within data models to support knobs for maximum frequency or | |||
resolution of pub/sub data. | ||||
9. Previously Considered Ideas | 4. Previously Considered Ideas | |||
9.1. A Separate Ephemeral Datastore | 4.1. A Separate Ephemeral Datastore | |||
The primary advantage of a fully separate datastore is that the | The primary advantage of a fully separate datastore is that the | |||
semantics of its contents are always clearly ephemeral. It also | semantics of its contents are always clearly ephemeral. It also | |||
provides strong segregation of I2RS configuration and operational | provides strong segregation of I2RS configuration and operational | |||
state from the rest of the system within the network element. | state from the rest of the system within the network element. | |||
The most obvious disadvantage of such a fully separate datastore is | The most obvious disadvantage of such a fully separate datastore is | |||
that interaction with the network element's operational or | that interaction with the network element's operational or | |||
configuration state becomes significantly more difficult. As an | configuration state becomes significantly more difficult. As an | |||
example, a BGP I2RS use case would be the dynamic instantiation of a | example, a BGP I2RS use case would be the dynamic instantiation of a | |||
skipping to change at page 11, line 13 | skipping to change at page 8, line 48 | |||
groupings from an IETF-standardized BGP module in such an I2RS | groupings from an IETF-standardized BGP module in such an I2RS | |||
ephemeral datastore's modules, one cannot currently reference state | ephemeral datastore's modules, one cannot currently reference state | |||
from one datastore to anothe | from one datastore to anothe | |||
For example, XPath queries are done in the context document of the | For example, XPath queries are done in the context document of the | |||
datastore in question and thus it is impossible for an I2RS model to | datastore in question and thus it is impossible for an I2RS model to | |||
fulfil a "must" or "when" requirement in the BGP module in the | fulfil a "must" or "when" requirement in the BGP module in the | |||
standard data stores. To implement such a mechanism would require | standard data stores. To implement such a mechanism would require | |||
appropriate semantics for XPath. | appropriate semantics for XPath. | |||
9.2. Panes of Glass/Overlay | 4.2. Panes of Glass/Overlay | |||
I2RS ephemeral configuration state is generally expected to be | I2RS ephemeral configuration state is generally expected to be | |||
disjoint from persistent configuration. In some cases, extending | disjoint from persistent configuration. In some cases, extending | |||
persistent configuration with ephemeral attributes is expected to be | persistent configuration with ephemeral attributes is expected to be | |||
useful. A case that is considered potentially useful but problematic | useful. A case that is considered potentially useful but problematic | |||
was explored was the ability to "overlay" persistent configuration | was explored was the ability to "overlay" persistent configuration | |||
with ephemeral configuration. | with ephemeral configuration. | |||
In this overlay scenario, persistent configuration that was not | In this overlay scenario, persistent configuration that was not | |||
shadowed by ephemeral configuration could be "read through". | shadowed by ephemeral configuration could be "read through". | |||
There were two perceived disadvantages to this mechanism: | There were two perceived disadvantages to this mechanism: | |||
The general complexity with managing the overlay mechanism itself. | The general complexity with managing the overlay mechanism itself. | |||
Consistency issues with validation should the ephemeral state be | Consistency issues with validation should the ephemeral state be | |||
lost, perhaps on reboot. In such a case, the previously shadowed | lost, perhaps on reboot. In such a case, the previously shadowed | |||
persistent state may no longer validate. | persistent state may no longer validate. | |||
10. Actions Required to Implement this Draft | 5. IANA Considerations | |||
o Draft for adding "config ephemeral" to YANG. | ||||
o Draft defining NETCONF changes including capability, RPC operation | ||||
changes and support of secondary identity, RPC changes to support | ||||
priority. | ||||
o I2RS draft to define meta-data for priority and secondary- | ||||
identity. | ||||
11. IANA Considerations | ||||
TBD. | There are no IANA requirements for this document. | |||
12. Security Considerations | 6. Security Considerations | |||
TBD. | The security requirements for the I2RS protocol are covered in | |||
[I-D.hares-i2rs-auth-trans] document. | ||||
13. Acknowledgements | 7. Acknowledgements | |||
This document is an attempt to distill lengthy conversations on the | This document is an attempt to distill lengthy conversations on the | |||
I2RS mailing list for an architecture that was for a long period of | I2RS mailing list for an architecture that was for a long period of | |||
time a moving target. Some individuals in particular warrant | time a moving target. Some individuals in particular warrant | |||
specific mention for their extensive help in providing the basis for | specific mention for their extensive help in providing the basis for | |||
this document: | this document: | |||
o Alia Atlas | o Alia Atlas | |||
o Andy Bierman | o Andy Bierman | |||
skipping to change at page 12, line 32 | skipping to change at page 10, line 4 | |||
o Dean Bogdanavich | o Dean Bogdanavich | |||
o Rex Fernando | o Rex Fernando | |||
o Joel Halpern | o Joel Halpern | |||
o Thomas Nadeau | o Thomas Nadeau | |||
o Juergen Schoenwaelder | o Juergen Schoenwaelder | |||
o Kent Watsen | o Kent Watsen | |||
14. References | 8. References | |||
14.1. Normative References: | 8.1. Normative References: | |||
[I-D.hares-i2rs-auth-trans] | ||||
Hares, S., Migault, D., and J. Halpern, "I2RS Security | ||||
Related Requirements", draft-hares-i2rs-auth-trans-05 | ||||
(work in progress), August 2015. | ||||
[I-D.ietf-i2rs-architecture] | [I-D.ietf-i2rs-architecture] | |||
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. | Atlas, A., Halpern, J., Hares, S., Ward, D., and T. | |||
Nadeau, "An Architecture for the Interface to the Routing | Nadeau, "An Architecture for the Interface to the Routing | |||
System", draft-ietf-i2rs-architecture-09 (work in | System", draft-ietf-i2rs-architecture-09 (work in | |||
progress), March 2015. | progress), March 2015. | |||
[I-D.ietf-i2rs-pub-sub-requirements] | ||||
Voit, E., Clemm, A., and A. Prieto, "Requirements for | ||||
Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- | ||||
requirements-02 (work in progress), March 2015. | ||||
[I-D.ietf-i2rs-rib-info-model] | [I-D.ietf-i2rs-rib-info-model] | |||
Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing | Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing | |||
Information Base Info Model", draft-ietf-i2rs-rib-info- | Information Base Info Model", draft-ietf-i2rs-rib-info- | |||
model-06 (work in progress), March 2015. | model-06 (work in progress), March 2015. | |||
[I-D.ietf-i2rs-traceability] | [I-D.ietf-i2rs-traceability] | |||
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to | Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to | |||
the Routing System (I2RS) Traceability: Framework and | the Routing System (I2RS) Traceability: Framework and | |||
Information Model", draft-ietf-i2rs-traceability-03 (work | Information Model", draft-ietf-i2rs-traceability-03 (work | |||
in progress), May 2015. | in progress), May 2015. | |||
[I-D.ietf-netmod-yang-metadata] | [I-D.ietf-netmod-yang-metadata] | |||
Lhotka, L., "Defining and Using Metadata with YANG", | Lhotka, L., "Defining and Using Metadata with YANG", | |||
draft-ietf-netmod-yang-metadata-01 (work in progress), | draft-ietf-netmod-yang-metadata-01 (work in progress), | |||
June 2015. | June 2015. | |||
14.2. Informative References | 8.2. Informative References | |||
[I-D.bierman-netconf-restconf] | [I-D.ietf-netconf-restconf] | |||
Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, | Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | |||
"RESTCONF Protocol", draft-bierman-netconf-restconf-04 | Protocol", draft-ietf-netconf-restconf-07 (work in | |||
(work in progress), February 2014. | progress), July 2015. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | ||||
<http://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the | [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | |||
Network Configuration Protocol (NETCONF)", RFC 6020, | the Network Configuration Protocol (NETCONF)", RFC 6020, | |||
October 2010. | DOI 10.17487/RFC6020, October 2010, | |||
<http://www.rfc-editor.org/info/rfc6020>. | ||||
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. | [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | |||
Bierman, "Network Configuration Protocol (NETCONF)", RFC | and A. Bierman, Ed., "Network Configuration Protocol | |||
6241, June 2011. | (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | |||
<http://www.rfc-editor.org/info/rfc6241>. | ||||
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration | [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration | |||
Protocol (NETCONF) Access Control Model", RFC 6536, March | Protocol (NETCONF) Access Control Model", RFC 6536, | |||
2012. | DOI 10.17487/RFC6536, March 2012, | |||
<http://www.rfc-editor.org/info/rfc6536>. | ||||
Authors' Addresses | Authors' Addresses | |||
Jeff Haas | Jeff Haas | |||
Juniper | Juniper | |||
Email: jhaas@juniper.net | Email: jhaas@juniper.net | |||
Susan Hares | Susan Hares | |||
Huawei | Huawei | |||
End of changes. 61 change blocks. | ||||
291 lines changed or deleted | 181 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |