--- 1/draft-ietf-i2rs-ephemeral-state-19.txt 2016-10-27 05:16:07.718579691 -0700 +++ 2/draft-ietf-i2rs-ephemeral-state-20.txt 2016-10-27 05:16:07.746580365 -0700 @@ -1,19 +1,19 @@ I2RS working group J. Haas Internet-Draft Juniper Intended status: Informational S. Hares -Expires: April 8, 2017 Huawei - October 5, 2016 +Expires: April 30, 2017 Huawei + October 27, 2016 I2RS Ephemeral State Requirements - draft-ietf-i2rs-ephemeral-state-19.txt + draft-ietf-i2rs-ephemeral-state-20.txt Abstract The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 8, 2017. + This Internet-Draft will expire on April 30, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -49,46 +49,49 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Review of Requirements from I2RS architecture document . . . 3 3. Ephemeral State Requirements . . . . . . . . . . . . . . . . 4 3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Ephemeral Configuration overlapping Local Configuration . 5 - 4. YANG Features for Ephemeral State . . . . . . . . . . . . . . 5 + 4. YANG Features for Ephemeral State . . . . . . . . . . . . . . 6 5. NETCONF Features for Ephemeral State . . . . . . . . . . . . 6 6. RESTCONF Features for Ephemeral State . . . . . . . . . . . . 6 7. Requirements regarding Supporting Multi-Head Control via client Priority . . . . . . . . . . . . . . . . . . . . . . . 6 8. Multiple Message Transactions . . . . . . . . . . . . . . . . 8 9. Pub/Sub Requirements Expanded for Ephemeral State . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 13.1. Normative References: . . . . . . . . . . . . . . . . . 9 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 13.1. Normative References: . . . . . . . . . . . . . . . . . 10 13.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The Interface to the Routing System (I2RS) Working Group is chartered with providing architecture and mechanisms to inject into and retrieve information from the routing system. The I2RS Architecture document [RFC7921] abstractly documents a number of requirements for - implementing the I2RS requirements. Section 2 reviews 10 key - requirements related to ephemeral state. + implementing the I2RS requirements. Section 2 reviews key + requirements related to ephemeral state. [RFC7921] defines ephemeral + state as "state which does not survive the reboot of a routing device + or the reboot of the software handling the I2RS software on a routing + device" (see section 1.1 of [RFC7921]). The I2RS Working Group has chosen to use the YANG data modeling language [RFC6020] as the basis to implement its mechanisms. Additionally, the I2RS Working group has chosen to re-use two existing protocols, NETCONF [RFC6241] and its similar but lighter- weight relative RESTCONF [I-D.ietf-netconf-restconf], as the protocols for carrying I2RS. What does re-use of a protocol mean? Re-use means that while YANG, @@ -126,49 +129,56 @@ "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 the I2RS protocol. The following are requirements distilled from [RFC7921] that provide context for the ephemeral data state requirements given in sections 3-8: - 1. The I2RS protocol SHOULD support a high bandwidth, asynchronous - interface, with real-time guarantees on getting data from an I2RS - agent by an I2RS client. + 1. The I2RS protocol SHOULD support an interface asynchronous + programmatic interface interface with properties of described in + section 5 of [RFC7920] (e.g. high throughput) with support for + target information streams, filtered evens, and thresholded + events (real-time events) sent by an I2RS agent to an I2RS Client + (Key points from section 1.1 of [RFC7921]). 2. I2RS agent MUST record the client identity when a node is created or modified. The I2RS agent SHOULD to be able to read the client identity of a node and use the client identity's associated priority to resolve conflicts. The secondary identity is useful - for traceability and may also be recorded. + for traceability and may also be recorded. (Key points from + section 4 of [RFC7921].) 3. An I2RS Client identity MUST have only one priority for the client's identifier. A collision on writes is considered an error, but the priority associated with each client identifier is utilized to compare requests from two different clients in order to modify an existing node entry. Only an entry from a client which is higher priority can modify an existing entry (First - entry wins). Priority only has meaning at the time of use. + entry wins). Priority only has meaning at the time of use. (Key + points from section 7.8 of [RFC7921].) 4. I2RS Client's secondary identity data is read-only meta-data that is recorded by the I2RS agent associated with a data model's node is written. Just like the primary client identity, the secondary identity SHOULD only be recorded when the data node is written. + (Key points from sections 7.4 of [RFC7921].) 5. I2RS agent MAY have a lower priority I2RS client attempting to modify a higher priority client's entry in a data model. The filtering out of lower priority clients attempting to write or modify a higher priority client's entry in a data model SHOULD be effectively handled and not put an undue strain on the I2RS - agent. + agent. (See section 7.8 of [RFC7921] augmented by the resource + limitation language in section 8 [RFC7921].) 3. Ephemeral State Requirements 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 @@ -280,27 +290,27 @@ ability to have data nodes store I2RS client identity and not the effective priority of the I2RS client at the time the data node is stored. o The priority MAY be dynamically changed by AAA, but the exact actions are part of the protocol definition as long as collisions are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, and Ephemeral-REQ-14. Ephemeral-REQ-12: When a collision occurs as two clients are trying - to write the same data node, this collision is considered an error - and priorities were created to give a deterministic result. When - there is a collision, and the data node is changed, a notification - (which includes indicating data node the collision occurred on) MUST - BE sent to the original client to give the original client a chance - to deal with the issues surrounding the collision. The original - client may need to fix their state. + to write the same data node, this collision is considered an error. + The I2RS priorities are used to provide a deterministic resolution to + the conflict. When there is a collision, and the data node is + changed, a notification (which includes indicating data node the + collision occurred on) MUST BE sent to the original client to give + the original client a chance to deal with the issues surrounding the + collision. The original client may need to fix their state. Explanation: RESTCONF and NETCONF updates can come in concurrently from alternative sources. Therefore the collision detection and comparison of priority needs to occur for any type of update. For example, RESTCONF tracks the source of configuration change via the entity-Tag (section 3.5.2 of [I-D.ietf-netconf-restconf]) which the server returns to the client along with the value in GET or HEAD methods. RESTCONF requires that this resource entity-tag be updated whenever a resource or configuration resource within the resource is @@ -361,21 +371,21 @@ o Pub-Sub-REQ-01: The Subscription Service MUST support subscriptions against ephemeral state in operational data stores, configuration data stores or both. o Pub-Sub-REQ-02: The Subscription Service MUST support filtering so that subscribed updates under a target node might publish only ephemeral state in operational data or configuration data, or publish both ephemeral and operational data. - o Pub-Sub-REQ-03: The subscription service must support + o Pub-Sub-REQ-03: The subscription service MUST support subscriptions which are ephemeral. (E.g. An ephemeral data model which has ephemeral subscriptions.) 10. IANA Considerations There are no IANA requirements for this document. 11. Security Considerations The security requirements for the I2RS protocol are covered in @@ -440,20 +450,25 @@ [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, . [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . + [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem + Statement for the Interface to the Routing System", + RFC 7920, DOI 10.17487/RFC7920, June 2016, + . + [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, . [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", RFC 7922, DOI 10.17487/RFC7922, June 2016, .