--- 1/draft-ietf-i2rs-ephemeral-state-17.txt 2016-09-20 13:16:11.392822223 -0700 +++ 2/draft-ietf-i2rs-ephemeral-state-18.txt 2016-09-20 13:16:11.424822787 -0700 @@ -1,19 +1,19 @@ I2RS working group J. Haas Internet-Draft Juniper -Intended status: Standards Track S. Hares +Intended status: Informational S. Hares Expires: March 24, 2017 Huawei September 20, 2016 I2RS Ephemeral State Requirements - draft-ietf-i2rs-ephemeral-state-17 + draft-ietf-i2rs-ephemeral-state-18.txt Abstract The I2RS (interface to routing system) Architecture document (RFC7920) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet I2RS needs has to provide. This document describes in detail requirements for ephemeral state for those implementing the I2RS higher-protocol. @@ -112,24 +112,24 @@ Support for ephemeral state is an I2RS protocol requirement that requires datastore changes (see section 3), YANG additions (see section 4), NETCONF additions (see section 5), and RESTCONF additions (see section 6). Sections 7-9 provide details that expand upon the changes in sections 3-6 to clarify requirements discussed by the I2RS and NETCONF working groups. Section 7 provided additional requirements that detail how write-conflicts should be resolved if two I2RS client write the same - data. Section 8 details an additional requirement that details on - I2RS support of multiple message transactions. Section 9 highlights - two requirements in the I2RS publication/subscription requirements - [RFC7923] that must be expanded for ephemeral state. + data. Section 8 describes I2RS requirements for support of multiple + message transactions. Section 9 highlights two requirements in the + I2RS publication/subscription requirements [RFC7923] that must be + expanded for ephemeral state. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 2. Review of Requirements from I2RS architecture document The I2RS architecture defines important high-level requirements for @@ -185,22 +185,22 @@ agent. 10. The I2RS protocol MUST support the use of a secure transport. However, certain functions such as notifications MAY use a non- secure transport. Each model or service (notification, logging) must define within the model or service the valid uses of a non- secure transport. 3. Ephemeral State Requirements - In requirements Ephemeral-REQ-01 to Ephemeral-15, Ephemeral state is - defined as potentially including in a data model ephemeral + In requirements Ephemeral-REQ-01 to Ephemeral-REQ-15, Ephemeral state + is defined as potentially including in a data model ephemeral configuration and operational state which is flagged as ephemeral. 3.1. Persistence Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does not persist across reboots. If state must be restored, it should be done solely by replay actions from the I2RS client via the I2RS agent. While at first glance this may seem equivalent to the writable- @@ -212,28 +212,28 @@ 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. Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints that refer to operational state, this includes potentially fast changing or short lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB. Ephemeral state constraints should be assessed when the ephemeral state is written, and if any of the constraints change - to make the constraints invalid after that time the I2RS agent should + to make the constraints invalid after that time the I2RS agent SHOULD notify the I2RS client. Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- ephemeral state as a constraint. Non-ephemeral state can be configuration state or operational state. - Ephemeral-REQ-05: I2RS pub-sub [RFC7923], tracing ([RFC7922], RPC or + Ephemeral-REQ-05: I2RS pub-sub [RFC7923], tracing [RFC7922], RPC or other mechanisms may lead to undesirable or unsustainable resource consumption on a system implementing an I2RS agent. It is RECOMMENDED that mechanisms be made available to permit prioritization of I2RS operations, when appropriate, to permit implementations to shed work load when operating under constrained resources. An example of such a work shedding mechanism is rate- limiting. 3.3. Hierarchy @@ -335,23 +335,22 @@ processing of the configuration change for two I2RS clients must detect an I2RS collision and resolve the collision using the priority mechanism. 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 protocol MUST NOT mandate the internal mechanism for how AAA protocols (E.g. Radius or Diameter) or mechanisms distribute priority per identity except that any AAA protocols MUST operate over a secure transport layer (See Radius - [RFC6614] and Diameter [RFC6733]. distribute priority per identity. - Mechanisms which prevent collisions of two clients trying to modify - the same node of data are the focus. + [RFC6614] and Diameter [RFC6733]. Mechanisms that 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 be provided to handle the error scenario that two clients, with the same priority, update the same configuration data node. The I2RS architecture gives one way that this could be achieved, by specifying that the first update wins. Other solutions, that prevent oscillation of the config data node, are also acceptable. 8. Multiple Message Transactions @@ -429,21 +428,21 @@ o Joel Halpern, o Thomas Nadeau, o Juergen Schoenwaelder, o Kent Watsen, o Robert Wilton, and - o Joe Clark, + o Joe Clarke, 13. References 13.1. Normative References: [I-D.ietf-i2rs-protocol-security-requirements] Hares, S., Migault, D., and J. Halpern, "I2RS Security Related Requirements", draft-ietf-i2rs-protocol-security- requirements-11 (work in progress), September 2016.