draft-ietf-i2rs-ephemeral-state-12.txt | draft-ietf-i2rs-ephemeral-state-13.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: January 1, 2017 Huawei | Expires: January 2, 2017 Huawei | |||
June 30, 2016 | July 1, 2016 | |||
I2RS Ephemeral State Requirements | I2RS Ephemeral State Requirements | |||
draft-ietf-i2rs-ephemeral-state-12 | draft-ietf-i2rs-ephemeral-state-13 | |||
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 January 1, 2017. | This Internet-Draft will expire on January 2, 2017. | |||
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 21 ¶ | skipping to change at page 2, line 21 ¶ | |||
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 . . . . . . . . . . . . . . 6 | 4. YANG Features for Ephemeral State . . . . . . . . . . . . . . 6 | |||
5. NETCONF Features for Ephemeral State . . . . . . . . . . . . 6 | 5. NETCONF Features for Ephemeral State . . . . . . . . . . . . 6 | |||
6. RESTCONF Features for Ephemeral State . . . . . . . . . . . . 6 | 6. RESTCONF Features for Ephemeral State . . . . . . . . . . . . 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 . . . . . . 8 | |||
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 . . . . . . . . . . . . . . . . . 11 | 13.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
1. Introduction | 1. Introduction | |||
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 | In requirements Ephemeral-REQ-01 to Ephemeral-15, Ephemeral state is | |||
defined as potentially including both ephemeral configured state and | defined as potentially including both ephemeral configured state and | |||
operational state. | 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. If state must be restored, it should be | not persist across reboots. If state must be restored, it should be | |||
done solely by replay actions from the I2RS client via the I2RS | done solely by replay actions from the I2RS client via the I2RS | |||
agent. | agent. | |||
skipping to change at page 5, line 34 ¶ | skipping to change at page 5, line 34 ¶ | |||
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 may have constraints that refer to | Ephemeral-REQ-03: Ephemeral state may have constraints that refer to | |||
operational state, this includes potentially fast changing or short | operational state, this includes potentially fast changing or short | |||
lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB. | lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB. | |||
Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- | Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- | |||
ephemeral state as a constraint. | ephemeral state as a constraint. Non-ephemeral state can be | |||
configuration state or operational state. | ||||
Ephemeral-REQ-05: I2RS 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. | |||
3.3. Hierarchy | 3.3. Hierarchy | |||
skipping to change at page 6, line 15 ¶ | skipping to change at page 6, line 18 ¶ | |||
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 | 4. YANG Features for Ephemeral State | |||
Ephemeral-REQ-08: YANG MUST have a way to indicate in a data model | Ephemeral-REQ-08:In addition to config true/false, there MUST be a | |||
that schema nodes have the following properties: ephemeral, writable/ | way to indicate that YANG schema nodes represent ephemeral state. It | |||
not-writable, and status/configuration. | is desirable to allow for, and have to way to indicate, config false | |||
YANG schema nodes that are writable operational state. | ||||
5. NETCONF Features for Ephemeral State | 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 | |||
skipping to change at page 7, line 25 ¶ | skipping to change at page 7, line 27 ¶ | |||
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 (which includes indicating data | there is a collision, a notification (which includes indicating data | |||
node the collision occurred on) MUST BE sent to the original client | node the collision occurred on) MUST BE sent to the original client | |||
to give the original client a chance to deal with the issues | 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 | Note:RESTCONF and NETCONF posts can come in concurrently from | |||
required for collisions and the priority resolution of collisions. | alternative sources (see ETag in [I-D.ietf-netconf-restconf] section | |||
Multi-headed control is not tied to ephemeral state. I2RS is not | 3.4.1.2 usage). Therefore the collision detection and comparison of | |||
mandating how AAA supports priority. Mechanisms which prevent | priority needs to occur both for both type of updates (POST or edit- | |||
collisions of two clients trying to modify the same node of data are | config) at the point of comparison. | |||
the focus. | ||||
Ephemeral-REQ-13: Multi-headed control is required for collisions and | ||||
the priority resolution of collisions. Multi-headed control is not | ||||
tied to ephemeral state. I2RS is not mandating how AAA supports | ||||
priority. Mechanisms which prevent collisions of two clients trying | ||||
to modify the same node of data are the focus. | ||||
Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST | Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST | |||
be provided to handle the error scenario that two clients, with the | be provided to handle the error scenario that two clients, with the | |||
same priority, update the same configuration data node. The I2RS | same priority, update the same configuration data node. The I2RS | |||
architecture gives one way that this could be achieved, by specifying | architecture gives one way that this could be achieved, by specifying | |||
that the first update wins. Other solutions, that prevent | that the first update wins. Other solutions, that prevent | |||
oscillation of the config data node, are also acceptable. | oscillation of the config data node, are also acceptable. | |||
8. Multiple Message Transactions | 8. Multiple Message Transactions | |||
skipping to change at page 8, line 19 ¶ | skipping to change at page 8, line 26 ¶ | |||
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. | |||
The publication/subscription requirements for I2RS are in | The publication/subscription requirements for I2RS are in | |||
[I-D.ietf-i2rs-pub-sub-requirements], and the following general | [I-D.ietf-i2rs-pub-sub-requirements], and the following general | |||
requirements SHOULD be understood to be expanded to to include | requirements SHOULD be understood to be expanded to to include | |||
ephemeral state: | ephemeral state: | |||
o Pub-Sub-REQ-01: The Subscription Service MUST support | o Pub-Sub-REQ-01: The Subscription Service MUST support | |||
subscriptions against ephemeral data in operational data stores, | subscriptions against ephemeral state in operational data stores, | |||
configuration data stores or both. | configuration data stores or both. | |||
o Pub-Sub-REQ-02: The Subscription Service MUST support filtering so | o Pub-Sub-REQ-02: The Subscription Service MUST support filtering so | |||
that subscribed updates under a target node might publish only | that subscribed updates under a target node might publish only | |||
ephemeral data in operational data or configuration data, or | ephemeral state in operational data or configuration data, or | |||
publish both ephemeral and operational data. | publish both ephemeral and operational data. | |||
10. IANA Considerations | 10. IANA Considerations | |||
There are no IANA requirements for this document. | There are no IANA requirements for this document. | |||
11. Security Considerations | 11. Security Considerations | |||
The security requirements for the I2RS protocol are covered in | The security requirements for the I2RS protocol are covered in | |||
[I-D.ietf-i2rs-protocol-security-requirements] document. The | [I-D.ietf-i2rs-protocol-security-requirements] document. The | |||
End of changes. 10 change blocks. | ||||
18 lines changed or deleted | 25 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/ |