--- 1/draft-ietf-i2rs-ephemeral-state-13.txt 2016-07-06 02:16:01.199128041 -0700 +++ 2/draft-ietf-i2rs-ephemeral-state-14.txt 2016-07-06 02:16:01.223128642 -0700 @@ -1,19 +1,19 @@ I2RS working group J. Haas Internet-Draft Juniper Intended status: Standards Track S. Hares -Expires: January 2, 2017 Huawei - July 1, 2016 +Expires: January 7, 2017 Huawei + July 6, 2016 I2RS Ephemeral State Requirements - draft-ietf-i2rs-ephemeral-state-13 + draft-ietf-i2rs-ephemeral-state-14 Abstract This document covers requests to the NETMOD and NETCONF Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,21 +22,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 January 2, 2017. + This Internet-Draft will expire on January 7, 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 @@ -47,35 +47,35 @@ 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 . . . . . . . . . . . . . . . . 5 3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Ephemeral Configuration overlapping Local Configuration . 6 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 . . . . . . . . . . . . . . . . 7 + Client Priority . . . . . . . . . . . . . . . . . . . . . . . 7 + 8. Multiple Message Transactions . . . . . . . . . . . . . . . . 8 9. Pub/Sub Requirements Expanded for Ephemeral State . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 13.1. Normative References: . . . . . . . . . . . . . . . . . 9 - 13.2. Informative References . . . . . . . . . . . . . . . . . 11 + 13.2. Informative References . . . . . . . . . . . . . . . . . 10 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 [I-D.ietf-i2rs-architecture] abstractly documents a number of requirements for implementing the I2RS requirements. Section 2 reviews 10 key requirements related to ephemeral state. @@ -99,21 +99,21 @@ the I2RS protocol for key functions (ephemeral state, protocol security, publication/subscription service, traceability), 3. suggest protocol strawman (e.g. [I-D.hares-i2rs-protocol-strawman]) as ideas for the NETCONF, RESTCONF, and YANG changes. The purpose of these requirements and the suggested protocol straw man is to provide a quick turnaround on creating the I2RS protocol. - Support for ephemeral state is I2RS protocol requirement that + 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. Sections 7 provide additional requirements that detail how write-conflicts should be resolved if two I2RS client write the same data. Section 8 provides an additional requirement that details on I2RS support of multiple message transactions. Section 9 highlights @@ -207,20 +207,24 @@ 3.2. Constraints 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 may 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 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, logging, 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 @@ -353,20 +357,24 @@ 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 + 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 [I-D.ietf-i2rs-protocol-security-requirements] document. The security requirements for the I2RS protocol environment are in [I-D.ietf-i2rs-security-environment-reqs]. @@ -423,61 +431,25 @@ Migault, D., Halpern, J., and S. Hares, "I2RS Environment Security Requirements", draft-ietf-i2rs-security- environment-reqs-01 (work in progress), April 2016. [I-D.ietf-i2rs-traceability] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", draft-ietf-i2rs-traceability-11 (work in progress), May 2016. - [I-D.ietf-netconf-call-home] - Watsen, K., "NETCONF Call Home and RESTCONF Call Home", - draft-ietf-netconf-call-home-17 (work in progress), - December 2015. - [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-14 (work in progress), June 2016. - [I-D.ietf-netconf-server-model] - Watsen, K. and J. Schoenwaelder, "NETCONF Server and - RESTCONF Server Configuration Models", draft-ietf-netconf- - server-model-09 (work in progress), March 2016. - - [I-D.ietf-netconf-yang-library] - Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module - Library", draft-ietf-netconf-yang-library-06 (work in - progress), April 2016. - - [I-D.ietf-netconf-yang-patch] - Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch - Media Type", draft-ietf-netconf-yang-patch-09 (work in - progress), June 2016. - - [I-D.ietf-netconf-yang-push] - Clemm, A., Prieto, A., Voit, E., Tripathy, A., and E. - Nilsen-Nygaard, "Subscribing to YANG datastore push - updates", draft-ietf-netconf-yang-push-03 (work in - progress), June 2016. - - [I-D.ietf-netconf-zerotouch] - Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning - for NETCONF or RESTCONF based Management", draft-ietf- - netconf-zerotouch-08 (work in progress), April 2016. - - [I-D.ietf-netmod-yang-metadata] - Lhotka, L., "Defining and Using Metadata with YANG", - draft-ietf-netmod-yang-metadata-07 (work in progress), - March 2016. - [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . 13.2. Informative References [I-D.hares-i2rs-protocol-strawman] Hares, S., Bierman, A., and a. amit.dass@ericsson.com, "I2RS protocol strawman", draft-hares-i2rs-protocol- @@ -486,25 +458,20 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . - [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration - Protocol (NETCONF) Access Control Model", RFC 6536, - DOI 10.17487/RFC6536, March 2012, - . - Authors' Addresses Jeff Haas Juniper Email: jhaas@juniper.net Susan Hares Huawei Saline