draft-ietf-i2rs-ephemeral-state-01.txt   draft-ietf-i2rs-ephemeral-state-02.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: February 29, 2016 Huawei Expires: March 5, 2016 Huawei
August 28, 2015 September 2, 2015
I2RS Ephemeral State Requirements I2RS Ephemeral State Requirements
draft-ietf-i2rs-ephemeral-state-01 draft-ietf-i2rs-ephemeral-state-02
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 February 29, 2016. This Internet-Draft will expire on March 5, 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 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. changes to YANG . . . . . . . . . . . . . . . . . . . . . 5 3.4. changes to YANG . . . . . . . . . . . . . . . . . . . . . 5
3.5. Minimal sub-set of Changes . . . . . . . . . . . . . . . 5 3.5. Minimal sub-set of Changes to NETCONF . . . . . . . . . . 5
3.6. Requirements regarding Identity, Secondary-Identity and 3.6. Requirements regarding Identity, Secondary-Identity and
Priority . . . . . . . . . . . . . . . . . . . . . . . . 5 Priority . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6.1. Identity Requirements . . . . . . . . . . . . . . . . 5 3.6.1. Identity Requirements . . . . . . . . . . . . . . . . 5
3.6.2. Priority Requirements . . . . . . . . . . . . . . . . 5 3.6.2. Priority Requirements . . . . . . . . . . . . . . . . 5
3.6.3. Transactions . . . . . . . . . . . . . . . . . . . . 6 3.6.3. Transactions . . . . . . . . . . . . . . . . . . . . 6
3.6.4. Subscriptions to Changed State Requirements . . . . . 7 3.6.4. Subscriptions to Changed State Requirements . . . . . 7
4. Previously Considered Ideas . . . . . . . . . . . . . . . . . 8 4. Previously Considered Ideas . . . . . . . . . . . . . . . . . 8
4.1. A Separate Ephemeral Datastore . . . . . . . . . . . . . 8 4.1. A Separate Ephemeral Datastore . . . . . . . . . . . . . 8
4.2. Panes of Glass/Overlay . . . . . . . . . . . . . . . . . 8 4.2. Panes of Glass/Overlay . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References: . . . . . . . . . . . . . . . . . . 10 8.1. Normative References: . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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.
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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-
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 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 must be able to utilized temporary
operational state which (MPLS LSP-ID or a BGP IN-RIB) as a operational state which (MPLS LSP-ID or a BGP IN-RIB) as a
constraints. constraints.
Ephemeral-REQ-04> Ephemeral state MAY refer to non-ephemeral state Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
for purposes of implementing constraints. The designer of ephemeral for purposes of implementing constraints. The designer of ephemeral
state modules are advised that such constraints may impact the speed state modules are advised that such constraints may impact the speed
of processing ephemeral state commits and should avoid them when of processing ephemeral state commits and should avoid them when
speed is essential. speed is essential.
3.3. Hierarchy 3.3. Hierarchy
Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of
objects) that have the property of being ephemeral. An object needs objects) that have the property of being ephemeral. An object needs
to be able to have (both) the property of being writable and the to be able to have (both) the property of being writable and the
property of the data being ephemeral (or non-ephemeral). property of the data being ephemeral (or non-ephemeral).
3.4. changes to YANG 3.4. changes to YANG
Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model
that nodes have the following properties: ephemeral, writable/not- that nodes have the following properties: ephemeral, writable/not-
writable, status/configuration. writable, status/configuration.
3.5. Minimal sub-set of Changes 3.5. Minimal sub-set of Changes to NETCONF
Ephemeral-REQ-07: The minimal set is ... Ephemeral-REQ-07: The minimal set of changes are: (TBD).
Potential set: Potential set: TBD
Note: I2RS protocol design team is working to complete this set of
minimal changes.
3.6. Requirements regarding Identity, Secondary-Identity and Priority 3.6. Requirements regarding Identity, Secondary-Identity and Priority
3.6.1. Identity Requirements 3.6.1. Identity Requirements
Ephemeral-REQ-08:Clients shall have identities, and secondary Ephemeral-REQ-08:Clients shall have identifiers, and secondary
identities. identifiers.
Explanation Explanation:
I2RS requires clients to have an identity. This identity will be I2RS requires clients to have an identifier. This identifier will be
used by the Agent authentication mechanism over the appropriate used by the Agent authentication mechanism over the appropriate
protocol. protocol.
The Secondary identities can be carried as part of RPC or meta-data. The Secondary identities can be carried as part of RPC or meta-data.
The primary purpose of the secondary identity is for traceability The primary purpose of the secondary identity is for traceability
information which logs (who modifies certain nodes). This secondary information which logs (who modifies certain nodes). This secondary
identity is an opaque value. [I-D.ietf-i2rs-traceability] provides identity is an opaque value. [I-D.ietf-i2rs-traceability] provides
an example of how the secondary identity can be used for an example of how the secondary identity can be used for
traceability. traceability.
skipping to change at page 6, line 47 skipping to change at page 6, line 49
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 should fail. An appropriate error should be node, the commit should fail. An appropriate error should be
returned to the user stating the nodes where the user had returned to the user stating the nodes where the user had
insufficient priority to override the state. insufficient priority to override the state.
3.6.3. Transactions 3.6.3. Transactions
Ephemeral-REQ-13: Section 7.9 of the [I-D.ietf-i2rs-architecture] Ephemeral-REQ-13: 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, but suggests an I2RS client may indicates and roll-back mechanisms. I2RS notes multiple operations in one or
one of the following error handling techniques for a given message more messages handling can handle errors within the set of operations
sent to the I2RS client: in many ways. No multi-message commands SHOULD cause errors to be
inserted into the I2RS ephemeral data-store.
Explanation:
I2RS suggests the following are some of the potential error handling
techniques for multiple message sent to the I2RS client:
1. Perform all or none: All operations succeed or none of them will 1. Perform all or none: All operations succeed or none of them will
be applied. This useful when there are mutual dependencies. be applied. This useful when there are mutual dependencies.
2. Perform until error: Operations are applied in order, and when 2. Perform until error: Operations are applied in order, and when
error occurs the processing stops. This is useful when error occurs the processing stops. This is useful when
dependencies exist between multiple-message operations, and order dependencies exist between multiple-message operations, and order
is important. is important.
3. Perform all storing errors: Perform all actions storing error 3. Perform all storing errors: Perform all actions storing error
indications for errors. This method can be used when there are indications for errors. This method can be used when there are
no dependencies between operations, and the client wants to sort no dependencies between operations, and the client wants to sort
it out. it out.
I2RS-REQ-XX: None of these three error handling for multi-message Is important to reliability of the datastore that none of these error
cases SHOULD cause errors into be insert the I2RS ephemeral data- handling for multiple operations in one more multiple messages cause
store. errors into be insert the I2RS ephemeral data-store.
Discussion of Current NETCONF/RESTCONF versus Discussion of Current NETCONF/RESTCONF versus
RESTCONF does an atomic action within a http session, and NETCONF has RESTCONF does an atomic action within a http session, and NETCONF has
atomic actions within a commit. These features may be used to atomic actions within a commit. These features may be used to
perform these features. perform these features.
I2RS processing is dependent on the I2RS model. The I2RS model must I2RS processing is dependent on the I2RS model. The I2RS model must
consider the dependencies within multiple operations work within a consider the dependencies within multiple operations work within a
model. model.
skipping to change at page 7, line 49 skipping to change at page 8, line 12
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 following requirements from the The following requirements from the
[I-D.ietf-i2rs-pub-sub-requirements] apply to ephemeral state: [I-D.ietf-i2rs-pub-sub-requirements] apply to ephemeral state:
o PubSub-REQ-1: The I2RS interface SHOULD support user subscriptions o PubSub-REQ-1: The I2RS interface SHOULD support user subscriptions
to data with the following parameters: push of data synchronously to data with the following parameters: push of data synchronously
or asynchronously via registered subscriptions. or asynchronously via registered subscriptions.
o PubSSub-REQ-2: Real time for notifications SHOULD BEdefined o PubSSub-REQ-2: Real time for notifications SHOULD be defined by
defined by the data models. the data models.
o PubSub-REQ-3: Security of the pub/sub data stream SHOULD be able o PubSub-REQ-3: Security of the pub/sub data stream SHOULD be able
to be model dependent. to be model dependent.
o PubSub-REQ-4: The Pub/Sub mechanism SHOULD allow subscription to o PubSub-REQ-4: The Pub/Sub mechanism SHOULD allow subscription to
critical Node Events. Examples of critical node events are BGP critical Node Events. Examples of critical node events are BGP
peers down or ISIS protocol overload bits. peers down or ISIS protocol overload bits.
o PubSub-REQ-5:I2RS telemetry data for certain protocols (E.g. BGP) o PubSub-REQ-5:I2RS telemetry data for certain protocols (E.g. BGP)
will require a hierarchy of filters or XPATHs. The I2RS protocol will require a hierarchy of filters or XPATHs. The I2RS protocol
 End of changes. 17 change blocks. 
24 lines changed or deleted 33 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/