I2RS working group S. Hares
Internet-Draft Huawei
Intended status: Informational A. Dass
Expires: September 14, 2017 Ericsson
March 13, 2017

RESTCONF Changes to Support I2RS Protocol
draft-hares-netconf-i2rs-restconf-01.txt

Abstract

This document describes two RESTCONF optional capabilities (control plane datastore capability, ephemeral state capabilities) that are needed to support the I2RS protocol needs. The I2RS protocol requirese an ephemeral control plane datastore. as control plane datastores.

The purpose of this draft is to kick-start the discussions with NETCONF on these two capabilities.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 September 14, 2017.

Copyright Notice

Copyright (c) 2017 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

This a proposal for the following two RESTCONF capabilities to augment RESTCONF [RFC8040] to support the first version of the I2RS protocol: Control plane datstore capability and ephemeral state capability. The yang that supports this proposal is described in [I-D.hares-netmod-i2rs-yang]. This work is based on the datastore definitions in [I-D.ietf-netmod-revised-datastores].

This draft parallels a similar proposal for NETCONF [RFC6241] is described in [I-D.hares-netconf-i2rs-protocol]. The difference is the original design is to embedded the I2RS multi-headed collision resolution in the "control plane data store capability". However RESTCONF has edit-collision capability already which only needs a usage description. Therefore, this document has a I2RS Edit-Collision capability.

Caveat: This work is an individual draft (not an I2RS WG effort)

1.1. Background on I2RS

The I2RS architecture [RFC7921] defines the I2RS interface "a programmatic interface for state transfer in and out of the Internet routing system". The I2RS protocol is a protocol designed to a higher level protocol comprised of a set of existing protocols which have been extended to work together to support a new interface to the routing system. The I2RS protocol is a "reuse" management protocol which creates new management protocols by reusing existing protocols and extending these protocols for new uses, and has been designed to be implemented in phases [RFC7921].

1.2. Structure of draft

The structure of this document is:

2. Definitions and Background on I2RS

This section reviews definitions from I2RS architecture, and provides background on I2RS work for the reader.

2.1. IETF 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.2. I2RS Definitions

The I2RS architecture [RFC7921] defines the following terms:

ephemeral data:
is data which does not persist across a reboot (software or hardware) or a power on/off condition. Ephemeral data can be configured data or data recorded from operations of the router. Ephemeral configuration data also has the property that a system cannot roll back to a previous ephemeral configuration state. (See [RFC7921] for an architectural overview, [I-D.ietf-i2rs-ephemeral-state] for requirements, and [I-D.ietf-netmod-revised-datastores] for discussion of how the ephemeral datastore as a control plane datastore interacts with intended datstore and dynamic configuration protocols to form the applied datastore".
local configuration:
is the data on a routing system which does persist across a reboot (software or hardware) and a power on/off condition. Local configuration has the ability to roll back to a pervious configuration state. Local configuration is defined as the intended datastore [I-D.ietf-netmod-revised-datastores] which is modified by dynamic configuration protocols (such as DHCP) and the I2RS ephemeral data store
dynamic configuration protocols datastore
are configuration protocols such as DHCP that interact with the intended datastore (which does persist across a reboot (software or hardware) power on/off condition), and the I2RS ephemeral state control plane datastore.
control plane protocols datastore
is a datastore which is loaded by control plane protocols (e.g. I2RS protocol) rather than system configuration protocols. (see [I-D.ietf-netmod-revised-datastores]).
operator-applied policy:
is a policy that an operator sets that determines how the ephemeral datastore as a control plane data store interacts with applied datastore (as defined in [I-D.ietf-netmod-revised-datastores]). This operator policy consists of policy knobs that the operator sets to determine how the I2RS agent control plane ephemeral state datastore will interact with the intended configuration datastor and the dynamic configuration protocol datastore. Three policy knobs could be used to implement this policy:

2.3. Example for operator-applied policy

An practical example for three states of the operator-applied policy may help the reader understand the concept. Consider the following three desired outcomes with their policy knob states:

Monitoring Features only
The policy knob settings are:
Policy knob 1=false,
policy knob 2=true,
Policy knob 3=false,

Action: I2RS protocol software feature is installed, but the operator does not want the I2RS ephemarl datastore to take precedence (that is be used) on any variables in the applied configuration datastore. This policy set might be valid if I2RS is only suppose to monitor data on this node through newly defined parameters.

I2RS Agent Changes win
the policy knob settings would be:
Policy knob 1=true,
policy knob 2=false,
Policy knob 3=false,

Action: This is the normal case for the I2RS Agent where the ephemeral control-plane datastore takes precedence over the intended configuration datastore and dynamic configuration datastores. The values from the I2RS ephemearl datastore are used rather than the intended configuration datastore and the dynamic configuration protocol datastore. When the ephemeral data is removed by the I2RS agent, the dyanmic configuration datastore and the intended configuration datastore state is restored, combined and passed to the routing protocols for application.

Just change until next configuration update
the policy knob settings would be:
Policy knob 1=true,
policy knob 2=true,
Policy knob 3=false,

Action: This case can occur if the I2RS Client write to the ephemeral control plane data store is only suppose to take precedence until the next configuration cycle from a centralized system. Suppose the local configuration is get by the centralized system at 11:00pm each night. The I2RS Client writes temporary changes to the routing system via the I2RS agent ephemeral write. At 11:00pm, the local configuration update overwrite the ephemeral. The I2RS Agent notifies the I2RS Client which is tracking which of the ephemeral changes are being overwritten.

2.4. I2RS protocol requirements

The requirements for the I2RS protocol are defined in the following documents:

The Interface to the routing System (I2RS) creates a new capability for the routing systems, and with greater capaiblities come a greater need for security. The requirements for a secure environment for I2RS is described in [I-D.ietf-i2rs-security-environment-reqs].

3. RESTCONF control plane datastore capability

capability-name: control-plane datastore

3.1. Overview

The :control-plane datastore capability enables the RESTCONF to support the following:

3.2. Dependencies

This protocol strawman utilizes the following existing proposed features for NETCONF and RESTCONF

3.3. New Operations

none

3.4. Modified Operations

All RESTCONF methods (OPTIONS, HEAD, GET, POST, PT, PATCH, DELETE) need to work in the control plane datastores. config=TRUE data, and where appropriate config=FALSE data.

Editor's Note: Amazingly, RESTCONF is almost ready for the control plane data. The authors understanding of the I2RS protocol needs is why. The best situation is to ask the RESTCONF authors for help specifying what needs to change for the RESTCONF to allow references to datastore.

4. RESTCONF protocol extensions for the ephemeral datastore

capability-name: ephemeral-state

4.1. Overview

This capability defines the RESTCONF protocol extensions for control plane protocols that support control plane data stores with ephemeral data.

Ephemeral state is not unique to I2RS work.

The ephemeral capability is the ability to support control plane datastores which are entirely ephemeral or have ephemeral state modules, or ephemeral statements within objects in a modules. These objects can be configuration state (config=TRUE) or operational state (config=FALSE).

Ephemeral state in datastores, ephemeral modules or ephemeral objects within a module have one key characteristics: the data does not persist across reboots. The ephemeral configuration state must be restored by a client, and the operational state will need to be regenerated.

The entire requirements for ephemeral state for the I2RS control plane protocol are listed in [I-D.ietf-i2rs-ephemeral-state]. Compared to RESTCONF functionality there are 4 groups of additional changes:

Constraints
The ability to enforce the constraints for references (to/from) the {+restconf/data} datastore, and a {+restconf/cp-data} control plane datastore. ((see Ephemeral-REQ-02, Ephemeral-REQ-03, and Ephemeral-REQ-04 in [I-D.ietf-i2rs-ephemeral-state]). The "validation" yang statement in [I-D.hares-netmod-i2rs-yang] could encode specific validation for the ephemeral case per datatstore or per object. [Editor's note: Aid is needed from NETCONF authors to determine the best way to enforce the constraints.]
Library Tracking of Epheemral
Yang modules must identify Yang objects (modules, submodules or objects within yang modules which are ephemeral and augment other nodes) and allow an "ephemeral=TRUE" feature.
Roll-back
an ephemeral node cannot roll-back to its previous value,

4.2. Dependencies

The ephemeral capabilities have the following dependencies:

4.3. Capability identifier

The ephemeral-datastore capability is identified by the following capability string: ephemeral (TBD URI)

4.4. New Operations

none

4.5. modification to data resources

RESTCONF must be able to support the ephemeral data in a control plane datastore

RESTCONF library functions must be able to store an indication that a data module has ephemeral state.

4.6. Modification to existing operations

The current operations in RESTCONF are: OPTIONS, HEAD, GET, POST, PUT, PATCH, and DELETE.

Editor's note: From here is not solutions but a list of features to discuss with the RESTCONF team.

The operations must support the following things about ephemeral The ephemeral data store has the following general qualities:

  1. The ephemeral datastore is never locked. (RESTCONF does not use a locking mechanism.)
  2. The ephemeral portion of the intended configuration, applied state, and derived state does not persist over a reboot,
  3. an ephemeral node cannot roll-back to its previous value,
  4. Since ephemeral data store is just data that does not presist over a reboot, then in theory any node or group of nodes in a YANG data model could be ephemeral. The YANG data module must indicate what portion of the data model (if any) is ephemeral.

  5. The management protocol (NETCONF/RESTCONF) needs to signal which poritons of a data model(node, tree, or data model) are ephemeral in the module library [RFC7895].

5. IANA Considerations

This is a protocol strawman - nothing is going to IANA.

6. Security Considerations

The security requirements for the I2RS protocol are covered in [I-D.ietf-i2rs-protocol-security-requirements]. The security environment the I2RS protocol is covered in [I-D.ietf-i2rs-security-environment-reqs]. Any person implementing or deploying the I2RS protocol should consider both security requirements.

7. Acknowledgements

TBD

8. References

8.1. Normative References:

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007.
[RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 5339, DOI 10.17487/RFC5339, September 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011.
[RFC6244] Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012.
[RFC7158] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7158, DOI 10.17487/RFC7158, March 2014.
[RFC7589] Badra, M., Luchuk, A. and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, DOI 10.17487/RFC7589, June 2015.
[RFC7803] Leiba, B., "Changing the Registration Policy for the NETCONF Capability URNs Registry", BCP 203, RFC 7803, DOI 10.17487/RFC7803, February 2016.
[RFC7895] Bierman, A., Bjorklund, M. and K. Watsen, "YANG Module Library", RFC 7895, DOI 10.17487/RFC7895, June 2016.
[RFC7920] Atlas, A., Nadeau, T. 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.
[RFC7923] Voit, E., Clemm, A. and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, June 2016.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 7952, DOI 10.17487/RFC7952, August 2016.
[RFC7958] Abley, J., Schlyter, J., Bailey, G. and P. Hoffman, "DNSSEC Trust Anchor Publication for the Root Zone", RFC 7958, DOI 10.17487/RFC7958, August 2016.
[RFC8040] Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017.
[RFC8072] Bierman, A., Bjorklund, M. and K. Watsen, "YANG Patch Media Type", RFC 8072, DOI 10.17487/RFC8072, February 2017.

8.2. Informative References

[I-D.hares-netconf-i2rs-protocol] Hares, S. and a. amit.dass@ericsson.com, "NETCONF Changes to Support I2RS Protocol", Internet-Draft draft-hares-netconf-i2rs-protocol-00, November 2016.
[I-D.hares-netmod-i2rs-yang] Hares, S. and a. amit.dass@ericsson.com, "Yang for I2RS Protocol", Internet-Draft draft-hares-netmod-i2rs-yang-04, March 2017.
[I-D.ietf-i2rs-ephemeral-state] Haas, J. and S. Hares, "I2RS Ephemeral State Requirements", Internet-Draft draft-ietf-i2rs-ephemeral-state-23, November 2016.
[I-D.ietf-i2rs-protocol-security-requirements] Hares, S., Migault, D. and J. Halpern, "I2RS Security Related Requirements", Internet-Draft draft-ietf-i2rs-protocol-security-requirements-17, September 2016.
[I-D.ietf-i2rs-rib-data-model] Wang, L., Ananthakrishnan, H., Chen, M., amit.dass@ericsson.com, a., Kini, S. and N. Bahadur, "A YANG Data Model for Routing Information Base (RIB)", Internet-Draft draft-ietf-i2rs-rib-data-model-07, January 2017.
[I-D.ietf-i2rs-rib-info-model] Bahadur, N., Kini, S. and J. Medved, "Routing Information Base Info Model", Internet-Draft draft-ietf-i2rs-rib-info-model-10, December 2016.
[I-D.ietf-i2rs-security-environment-reqs] Migault, D., Halpern, J. and S. Hares, "I2RS Environment Security Requirements", Internet-Draft draft-ietf-i2rs-security-environment-reqs-03, March 2017.
[I-D.ietf-i2rs-yang-l3-topology] Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H. and N. Bahadur, "A YANG Data Model for Layer 3 Topologies", Internet-Draft draft-ietf-i2rs-yang-l3-topology-08, January 2017.
[I-D.ietf-netconf-call-home] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", Internet-Draft draft-ietf-netconf-call-home-17, December 2015.
[I-D.ietf-netconf-keystore] Watsen, K. and G. Wu, "Keystore Model", Internet-Draft draft-ietf-netconf-keystore-00, October 2016.
[I-D.ietf-netconf-netconf-event-notifications] Prieto, A., Clemm, A., Voit, E., Nilsen-Nygaard, E., Tripathy, A., Chisholm, S. and H. Trevino, "NETCONF Support for Event Notifications", Internet-Draft draft-ietf-netconf-netconf-event-notifications-01, October 2016.
[I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", Internet-Draft draft-ietf-netconf-restconf-18, October 2016.
[I-D.ietf-netconf-restconf-notif] Voit, E., Prieto, A., Tripathy, A., Nilsen-Nygaard, E., Clemm, A. and A. Bierman, "Restconf and HTTP Transport for Event Notifications", Internet-Draft draft-ietf-netconf-restconf-notif-02, March 2017.
[I-D.ietf-netconf-rfc5277bis] Clemm, A., Prieto, A., Voit, E., Nilsen-Nygaard, E., Tripathy, A., Chisholm, S. and H. Trevino, "Subscribing to Event Notifications", Internet-Draft draft-ietf-netconf-rfc5277bis-01, October 2016.
[I-D.ietf-netconf-tls-client-server] Watsen, K., "TLS Client and Server Models", Internet-Draft draft-ietf-netconf-tls-client-server-01, November 2016.
[I-D.ietf-netconf-yang-patch] Bierman, A., Bjorklund, M. and K. Watsen, "YANG Patch Media Type", Internet-Draft draft-ietf-netconf-yang-patch-14, November 2016.
[I-D.ietf-netconf-yang-push] Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen-Nygaard, E., Bierman, A. and B. Lengyel, "Subscribing to YANG datastore push updates", Internet-Draft draft-ietf-netconf-yang-push-05, March 2017.
[I-D.ietf-netconf-zerotouch] Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning for NETCONF or RESTCONF based Management", Internet-Draft draft-ietf-netconf-zerotouch-12, January 2017.
[I-D.ietf-netmod-revised-datastores] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K. and R. Wilton, "A Revised Conceptual Model for YANG Datastores", Internet-Draft draft-ietf-netmod-revised-datastores-00, December 2016.
[I-D.ietf-netmod-schema-mount] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", Internet-Draft draft-ietf-netmod-schema-mount-04, March 2017.
[I-D.ietf-netmod-syslog-model] Wildes, C. and K. Koushik, "A YANG Data Model for Syslog Configuration", Internet-Draft draft-ietf-netmod-syslog-model-12, February 2017.

Authors' Addresses

Susan Hares Huawei Saline, US EMail: shares@ndzh.com
Amit Daas Ericsson EMail: amit.dass@ericsson.com