draft-ietf-i2rs-ephemeral-state-10.txt | draft-ietf-i2rs-ephemeral-state-11.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 23, 2016 Huawei | Expires: December 27, 2016 Huawei | |||
June 21, 2016 | June 25, 2016 | |||
I2RS Ephemeral State Requirements | I2RS Ephemeral State Requirements | |||
draft-ietf-i2rs-ephemeral-state-10 | draft-ietf-i2rs-ephemeral-state-11 | |||
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 23, 2016. | This Internet-Draft will expire on December 27, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 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 15 ¶ | skipping to change at page 2, line 15 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2. Review of Requirements from I2RS architecture document . . . 3 | 2. Review of Requirements from I2RS architecture document . . . 3 | |||
3. Ephemeral State Requirements . . . . . . . . . . . . . . . . 5 | 3. Ephemeral State Requirements . . . . . . . . . . . . . . . . 5 | |||
3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4. Ephemeral Configuration overlapping Local Configuration . 6 | 3.4. Ephemeral Configuration overlapping Local Configuration . 6 | |||
4. YANG Features for Ephemeral State for I2RS Protocol version 1 6 | 4. YANG Features for Ephemeral State . . . . . . . . . . . . . . 6 | |||
5. NETCONF Features for Ephemeral State for I2RS Protocol | 5. NETCONF Features for Ephemeral State . . . . . . . . . . . . 6 | |||
version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 6. RESTCONF Features for Ephemeral State . . . . . . . . . . . . 6 | |||
6. RESTCONF Features for Ephemeral State for I2RS Protocol | ||||
version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | ||||
7. Requirements regarding Supporting Multi-Head Control via | 7. Requirements regarding Supporting Multi-Head Control via | |||
Client Priority . . . . . . . . . . . . . . . . . . . . . . . 6 | Client Priority . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
8. Multiple Message Transactions . . . . . . . . . . . . . . . . 7 | 8. Multiple Message Transactions . . . . . . . . . . . . . . . . 7 | |||
9. Pub/Sub Requirements Expanded for Ephemeral State . . . . . . 7 | 9. Pub/Sub Requirements Expanded for Ephemeral State . . . . . . 7 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
13.1. Normative References: . . . . . . . . . . . . . . . . . 9 | 13.1. Normative References: . . . . . . . . . . . . . . . . . 9 | |||
13.2. Informative References . . . . . . . . . . . . . . . . . 10 | 13.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
skipping to change at page 5, line 7 ¶ | skipping to change at page 5, line 7 ¶ | |||
agent. | agent. | |||
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 | |||
In requirements Ephemeral-REQ-01 to Ephemeral-05, Ephemeral state is | ||||
defined as potentially including both ephemeral configured state and | ||||
operational state. | ||||
3.1. Persistence | 3.1. Persistence | |||
Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does | Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does | |||
not persist across reboots. Ephemeral state may consists of | not persist across reboots. If state must be restored, it should be | |||
ephemeral configured state and operational state. If state must be | done solely by replay actions from the I2RS client via the I2RS | |||
restored, it should be done solely by replay actions from the I2RS | agent. | |||
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 data store in NETCONF, running-config can be copied to a | running data store in NETCONF, running-config can be copied to a | |||
persistent data store, like startup config. I2RS ephemeral state | persistent data store, like startup config. I2RS ephemeral state | |||
MUST NOT be persisted. | MUST NOT be persisted. | |||
3.2. Constraints | 3.2. Constraints | |||
Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral | Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral | |||
state for constraint purposes; it SHALL be considered a validation | state for constraint purposes; it SHALL be considered a validation | |||
error if it does. | error if it does. | |||
Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary | Ephemeral-REQ-03: Ephemeral state may have constraints that refer to | |||
operational state (e.g. MPLS LSP-ID or a BGP IN-RIB) as a | operational state, this includes potentially fast changing or short | |||
constraints. | lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB. | |||
Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state | Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- | |||
for purposes of implementing constraints. | ephemeral state as a constraint. | |||
Ephemeral-REQ-05: 2RS pub-sub, logging, RPC or other mechanisms may | Ephemeral-REQ-05: I2RS pub-sub, logging, RPC or other mechanisms may | |||
lead to undesirable or unsustainable resource consumption on a system | lead to undesirable or unsustainable resource consumption on a system | |||
implementing an I2RS Agent. It is RECOMMENDED that mechanisms be | implementing an I2RS Agent. It is RECOMMENDED that mechanisms be | |||
made available to permit prioritization of I2RS operations, when | made available to permit prioritization of I2RS operations, when | |||
appropriate, to permit implementations to shed work load when | appropriate, to permit implementations to shed work load when | |||
operating under constrained resources. An example of such a work | operating under constrained resources. An example of such a work | |||
shedding mechanism is rate-limiting. | shedding mechanism is rate-limiting. | |||
Note: Ephemeral-REQ-05 is part of the yang-push and event | ||||
notification technology drafts being worked out in NETCONF WG. It is | ||||
included here to indicate that these features are necessary for | ||||
ephemeral state. | ||||
3.3. Hierarchy | 3.3. Hierarchy | |||
Ephemeral-REQ-06: The ability to augment an object with appropriate | Ephemeral-REQ-06: The ability to augment Yang schema nodes with | |||
YANG structures that have the property of being ephemeral. An object | additional Yang Schema nodes that have the property of being | |||
defined as any one of the following: yang module, submodule or | ephemeral. | |||
components of submodule, or schema node. | ||||
3.4. Ephemeral Configuration overlapping Local Configuration | 3.4. Ephemeral Configuration overlapping Local Configuration | |||
Ephemeral-REQ-07: Ephemeral configuration state could override | Ephemeral-REQ-07: Ephemeral configuration state could override | |||
overlapping local configuration state, or vice-versa. | overlapping local configuration state, or vice-versa. | |||
Implementations MUST provide a mechanism to choose which takes | Implementations MUST provide a mechanism to choose which takes | |||
precedence. This mechanism MUST include local configuration (policy) | precedence. This mechanism MUST include local configuration (policy) | |||
and MAY be provided via the I2RS protocol mechanisms. | and MAY be provided via the I2RS protocol mechanisms. | |||
4. YANG Features for Ephemeral State for I2RS Protocol version 1 | 4. YANG Features for Ephemeral State | |||
Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model | Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model | |||
that nodes have the following properties: ephemeral, writable/not- | that schema nodes have the following properties: ephemeral, writable/ | |||
writable, and status/configuration. | not-writable, and status/configuration. | |||
5. NETCONF Features for Ephemeral State for I2RS Protocol version 1 | 5. NETCONF Features for Ephemeral State | |||
Ephemeral-REQ-09: The conceptual changes to NETCONF | Ephemeral-REQ-09: The conceptual changes to NETCONF | |||
1. Support for communication mechanisms to enable an I2RS client to | 1. Support for communication mechanisms to enable an I2RS client to | |||
determine that an I2RS agent supports the mechanisms needed for | determine that an I2RS agent supports the mechanisms needed for | |||
I2RS operation. | I2RS operation. | |||
2. The ephemeral state must support notification of write conflicts | 2. The ephemeral state must support notification of write conflicts | |||
using the priority requirements defined in section 7 below in | using the priority requirements defined in section 7 below in | |||
requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). | requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). | |||
6. RESTCONF Features for Ephemeral State for I2RS Protocol version 1 | 6. RESTCONF Features for Ephemeral State | |||
Ephemeral-REQ-10: The conceptual changes to RESTCONF are: | Ephemeral-REQ-10: The conceptual changes to RESTCONF are: | |||
1. Support for communication mechanisms to enable an I2RS client to | 1. Support for communication mechanisms to enable an I2RS client to | |||
determine that an I2RS agent supports the mechanisms needed for | determine that an I2RS agent supports the mechanisms needed for | |||
I2RS operation. | I2RS operation. | |||
2. The ephemeral state must support notification of write conflicts | 2. The ephemeral state must support notification of write conflicts | |||
using the priority requirements defined in section 7 below in | using the priority requirements defined in section 7 below in | |||
requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). | requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). | |||
skipping to change at page 7, line 14 ¶ | skipping to change at page 7, line 14 ¶ | |||
Ephemeral-REQ-11: The data nodes MAY store I2RS client identity and | Ephemeral-REQ-11: The data nodes MAY store I2RS client identity and | |||
not the effective priority at the time the data node is stored. Per | not the effective priority at the time the data node is stored. Per | |||
SEC-REQ-07 in section 3.1 of | SEC-REQ-07 in section 3.1 of | |||
[I-D.ietf-i2rs-protocol-security-requirements], an identifier must | [I-D.ietf-i2rs-protocol-security-requirements], an identifier must | |||
have just one priority. Therefore, the data nodes MAY store I2RS | have just one priority. Therefore, the data nodes MAY store I2RS | |||
client identity and not the effective priority of the I2RS client at | client identity and not the effective priority of the I2RS client at | |||
the time the data node is stored. The priority MAY be dynamically | the time the data node is stored. The priority MAY be dynamically | |||
changed by AAA, but the exact actions are part of the protocol | changed by AAA, but the exact actions are part of the protocol | |||
definition as long as collisions are handled as described in | definition as long as collisions are handled as described in | |||
Ephemeral-REQ-10, Ephemeral-REQ-11, and Ephemeral-REQ-12. | Ephemeral-REQ-12, Ephemeral-REQ-13, and Ephemeral-REQ-14. | |||
Ephemeral-REQ-12: When a collision occurs as two clients are trying | Ephemeral-REQ-12: When a collision occurs as two clients are trying | |||
to write the same data node, this collision is considered an error | to write the same data node, this collision is considered an error | |||
and priorities were created to give a deterministic result. When | and priorities were created to give a deterministic result. When | |||
there is a collision, a notification MUST BE sent to the original | 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 | client to give the original client a chance to deal with the issues | |||
surrounding the collision. The original client may need to fix their | surrounding the collision. The original client may need to fix their | |||
state. | state. | |||
Ephemeral-REQ-13: The requirement to support multi-headed control is | Ephemeral-REQ-13: The requirement to support multi-headed control is | |||
required for collisions and the priority resolution of collisions. | required for collisions and the priority resolution of collisions. | |||
Multi-headed control is not tied to ephemeral state. I2RS is not | Multi-headed control is not tied to ephemeral state. I2RS is not | |||
mandating how AAA supports priority. Mechanisms which prevent | mandating how AAA supports priority. Mechanisms which prevent | |||
collisions of two clients trying the same node of data are the focus. | collisions of two clients trying the same node of data are the focus. | |||
Ephemeral-REQ-14: If two clients have the same priority, the | Ephemeral-REQ-14: If two clients have the same priority, the | |||
architecture says the first one wins. The I2RS protocol has this | architecture says the first one wins. The I2RS protocol has this | |||
requirement to prevent was the oscillation between clients. If one | requirement to prevent oscillations between clients. If one uses the | |||
uses the last wins scenario, you may oscillate. That was our | last wins scenario, you may oscillate. That was our opinion, but a | |||
opinion, but a design which prevents oscillation is the key point. | design which prevents oscillation is the key point. | |||
8. Multiple Message Transactions | 8. Multiple Message Transactions | |||
Ephemeral-REQ-15: Section 7.9 of the [I-D.ietf-i2rs-architecture] | Ephemeral-REQ-15: Section 7.9 of the [I-D.ietf-i2rs-architecture] | |||
states the I2RS architecture does not include multi-message atomicity | states the I2RS architecture does not include multi-message atomicity | |||
and roll-back mechanisms. I2RS notes multiple operations in one or | and roll-back mechanisms. I2RS notes multiple operations in one or | |||
more messages handling can handle errors within the set of operations | more messages handling can handle errors within the set of operations | |||
in many ways. No multi-message commands SHOULD cause errors to be | in many ways. No multi-message commands SHOULD cause errors to be | |||
inserted into the I2RS ephemeral data-store. | inserted into the I2RS ephemeral data-store. | |||
End of changes. 17 change blocks. | ||||
37 lines changed or deleted | 32 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |