draft-ietf-i2rs-ephemeral-state-17.txt   draft-ietf-i2rs-ephemeral-state-18.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: Informational S. Hares
Expires: March 24, 2017 Huawei Expires: March 24, 2017 Huawei
September 20, 2016 September 20, 2016
I2RS Ephemeral State Requirements I2RS Ephemeral State Requirements
draft-ietf-i2rs-ephemeral-state-17 draft-ietf-i2rs-ephemeral-state-18.txt
Abstract Abstract
The I2RS (interface to routing system) Architecture document The I2RS (interface to routing system) Architecture document
(RFC7920) abstractly describes a number of requirements for ephemeral (RFC7920) abstractly describes a number of requirements for ephemeral
state (in terms of capabilities and behaviors) which any protocol state (in terms of capabilities and behaviors) which any protocol
suite attempting to meet I2RS needs has to provide. This document suite attempting to meet I2RS needs has to provide. This document
describes in detail requirements for ephemeral state for those describes in detail requirements for ephemeral state for those
implementing the I2RS higher-protocol. implementing the I2RS higher-protocol.
skipping to change at page 3, line 30 skipping to change at page 3, line 30
Support for ephemeral state is an I2RS protocol requirement that Support for ephemeral state is an I2RS protocol requirement that
requires datastore changes (see section 3), YANG additions (see requires datastore changes (see section 3), YANG additions (see
section 4), NETCONF additions (see section 5), and RESTCONF additions section 4), NETCONF additions (see section 5), and RESTCONF additions
(see section 6). (see section 6).
Sections 7-9 provide details that expand upon the changes in sections Sections 7-9 provide details that expand upon the changes in sections
3-6 to clarify requirements discussed by the I2RS and NETCONF working 3-6 to clarify requirements discussed by the I2RS and NETCONF working
groups. Section 7 provided additional requirements that detail how groups. Section 7 provided additional requirements that detail how
write-conflicts should be resolved if two I2RS client write the same write-conflicts should be resolved if two I2RS client write the same
data. Section 8 details an additional requirement that details on data. Section 8 describes I2RS requirements for support of multiple
I2RS support of multiple message transactions. Section 9 highlights message transactions. Section 9 highlights two requirements in the
two requirements in the I2RS publication/subscription requirements I2RS publication/subscription requirements [RFC7923] that must be
[RFC7923] that must be expanded for ephemeral state. expanded for ephemeral state.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Review of Requirements from I2RS architecture document 2. Review of Requirements from I2RS architecture document
The I2RS architecture defines important high-level requirements for The I2RS architecture defines important high-level requirements for
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-15, Ephemeral state is In requirements Ephemeral-REQ-01 to Ephemeral-REQ-15, Ephemeral state
defined as potentially including in a data model ephemeral is defined as potentially including in a data model ephemeral
configuration and operational state which is flagged as ephemeral. configuration and operational state which is flagged as ephemeral.
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.
While at first glance this may seem equivalent to the writable- While at first glance this may seem equivalent to the writable-
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 MUST be able to have constraints Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints
that refer to operational state, this includes potentially fast that refer to operational state, this includes potentially fast
changing or short lived operational state nodes, such as MPLS LSP-ID changing or short lived operational state nodes, such as MPLS LSP-ID
or a BGP IN-RIB. Ephemeral state constraints should be assessed when or a BGP IN-RIB. Ephemeral state constraints should be assessed when
the ephemeral state is written, and if any of the constraints change 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. notify the I2RS client.
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. Non-ephemeral state can be ephemeral state as a constraint. Non-ephemeral state can be
configuration state or operational state. 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 other mechanisms may lead to undesirable or unsustainable resource
consumption on a system implementing an I2RS agent. It is consumption on a system implementing an I2RS agent. It is
RECOMMENDED that mechanisms be made available to permit RECOMMENDED that mechanisms be made available to permit
prioritization of I2RS operations, when appropriate, to permit prioritization of I2RS operations, when appropriate, to permit
implementations to shed work load when operating under constrained implementations to shed work load when operating under constrained
resources. An example of such a work shedding mechanism is rate- resources. An example of such a work shedding mechanism is rate-
limiting. limiting.
3.3. Hierarchy 3.3. Hierarchy
skipping to change at page 8, line 14 skipping to change at page 8, line 14
processing of the configuration change for two I2RS clients must processing of the configuration change for two I2RS clients must
detect an I2RS collision and resolve the collision using the priority detect an I2RS collision and resolve the collision using the priority
mechanism. mechanism.
Ephemeral-REQ-13: Multi-headed control is required for collisions and Ephemeral-REQ-13: Multi-headed control is required for collisions and
the priority resolution of collisions. Multi-headed control is not the priority resolution of collisions. Multi-headed control is not
tied to ephemeral state. I2RS protocol MUST NOT mandate the internal tied to ephemeral state. I2RS protocol MUST NOT mandate the internal
mechanism for how AAA protocols (E.g. Radius or Diameter) or mechanism for how AAA protocols (E.g. Radius or Diameter) or
mechanisms distribute priority per identity except that any AAA mechanisms distribute priority per identity except that any AAA
protocols MUST operate over a secure transport layer (See Radius protocols MUST operate over a secure transport layer (See Radius
[RFC6614] and Diameter [RFC6733]. distribute priority per identity. [RFC6614] and Diameter [RFC6733]. Mechanisms that prevent collisions
Mechanisms which prevent collisions of two clients trying to modify of two clients trying to modify the same node of data are the focus.
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 10, line 12 skipping to change at page 10, line 12
o Joel Halpern, o Joel Halpern,
o Thomas Nadeau, o Thomas Nadeau,
o Juergen Schoenwaelder, o Juergen Schoenwaelder,
o Kent Watsen, o Kent Watsen,
o Robert Wilton, and o Robert Wilton, and
o Joe Clark, o Joe Clarke,
13. References 13. References
13.1. Normative References: 13.1. Normative References:
[I-D.ietf-i2rs-protocol-security-requirements] [I-D.ietf-i2rs-protocol-security-requirements]
Hares, S., Migault, D., and J. Halpern, "I2RS Security Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", draft-ietf-i2rs-protocol-security- Related Requirements", draft-ietf-i2rs-protocol-security-
requirements-11 (work in progress), September 2016. requirements-11 (work in progress), September 2016.
 End of changes. 8 change blocks. 
14 lines changed or deleted 13 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/