| I2RS working group | S. Hares |
| Internet-Draft | Huawei |
| Intended status: Informational | A. Dass |
| Expires: September 13, 2017 | Ericsson |
| March 12, 2017 |
NETCONF Changes to Support I2RS Protocol
draft-hares-netconf-i2rs-netconf-01.txt
This document describes a NETCONF capabiilty to support the Interface to Routing system (I2RS) protocol requirements for I2RS protocol version 1. The I2RS protocol is a re-use higher layer protocol which defines extensions to other protocols (NETCONF and RESTCONf) and extensions to the Yang Data Modeling language.
The I2RS protocol supports ephemeral state datastores as control plane datastores. Initial versions of this document contain descriptions of the ephemeral datastore. Future versions may move this description to NETMOD datastore description documents.
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 13, 2017.
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.
This a proposal for Yang additions to support the first version of the I2RS protocol.
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].
The first version of the I2RS protocol is comprised of extensions to existing features of NETCONF [RFC6241] and RESTCONF [I-D.ietf-netconf-restconf]. The data modeling language for the I2RS protocol will be Yang [RFC7950] with features and extensions proposed in this draft.
The structure of this document is:
This section reviews definitions from I2RS architecture [RFC7921] and NETCONF operational state definitions [I-D.ietf-netmod-revised-datastores] before using these to construct a definition of the ephemeral data store.
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].
The I2RS architecture [RFC7921] defines the following terms:
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 are described in [I-D.ietf-i2rs-security-environment-reqs].
This oveview reviews the following:
capability-name: control-plane
This capability defines the NETCONF protocol extensions for use with control plane protocols.
A control plane datastore is not part of the configuration datastore per [I-D.ietf-netmod-revised-datastores]. The control plane datastore many contain configuration and operational state. A router implementation may merge the configuration from a control plane datastore with configuration data from the configuration datastore. A query of the applied datastore will provide a list of the installed configuration from all datastores with meta data. The current architectural provides an origin identityref with the following mappimg to datastores for the
Clearly, the dynamic origin title is not enough to uniquely identify a control plane datastore entry in the applied datastore. Additional definitions will need to be added to the architectural model, but this will be specified in another document.
The control plane datastores do not restrict multiple access via the locking mechanisms (<lock> and <unlock>), but use a priority scheme to handle multiple clients attempting to write the same data. The default validation within a control plane datastore's config objects (e.g. config=TRUE) is the configuration datastore validation, but if Yang data modules specify different validation for the datastore or specific nodes then the control plane datastores will use this validation.
Some data modules may be used for both a control plane datastore and the configuration datastore. If additional validation is used for these modules, it is recommend that these modules use the "rpc" function for the additional validation rather than the <write-data> functions.
The following are the dependencies for the :control-plane capability
The controlplane-datastore capability is identified by the following capability string: (:control-plane (uri-tbd)) where the uri-tbd is to be assigned by IANA.
The following are additional protocol operations NETCONF [RFC6241] to support the following queries based on a datastore source/target datastore being specified:
The <target-datastore> must be registered with IANA.
The get-data command has obtains configuration and operational data. The parameters the following:
Example - retrieve route1 in route list.
wfrom control plane datastore (cp-alpha)
and gets both configuration and ephemeral data.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-data/
<source>
<cp-alpha/>
</source>
<filter type="subtree">
<top xmlns:t=
"http://example.com/schema/1.0/i2rs/tiny-rt-instance">
<route-list>
<route-index>1</route-index>
</route-list<
</filter>
</get-data>
</rpc>
<rpc-rply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-data<
<source>
<cp-alpha/>
</source>
<filter type="subtree">
<top xmlns:t=
"http://example.com/schema/1.0/i2rs/tiny-rt-instance">
<route-list>
<route-index>1</route-index>
<prefix-match>192.2/8 /16<prefix-match>
<nexthop>129.1.5.1</nexthop>
<if-outgoing>Eth0</if-outgoing>
<installed>true</installed>
</route-list<
</filter>
</get-data>
</rpc>
Figure 1
Example 2 - retrieve users subtree from the ephemeral database
which has example control plane datastore (cp-alpha)
and gets only config=true data;
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-data/
<source>
<cp-alpha/>
</source>
<filter type="subtree">
<top xmlns:t=
"http://example.com/schema/1.0/i2rs/tiny-rt-instance">
<route-list>
<route-index>1</route-index>
</route-list<
type="state" select "config";
</filter>
</get-data>
</rpc>
<rpc-rply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-data<
<source>
<cp-alpha/>
</source>
<filter type="subtree">
<top xmlns:t=
"http://example.com/schema/1.0/i2rs/tiny-rt-instance">
<route-list>
<route-index>1</route-index>
<prefix-match>192.2/8 /16<prefix-match>
<nexthop>129.1.5.1</nexthop>
<if-outgoing>Eth0</if-outgoing>
</route-list<
</filter>
</get-data>
</rpc>
Figure 2 - get config data
The write data operationals has the attributes of operation parameters, and parameters of target datastore, default-operations, test-option, error-option, a priority, secondary-id, config, and opstate. The attributes of the operation for individual nodes wutg "config-true" are: create, delete, merge, remove, and replace. The attributes for all-datastore operations are create-datastore, copy-datastore, delete-datastore. The operations handle multiple-client writes by using priority values rather than a locking mechanism. If two or more clients interact over changing the data node, the priority values arbitrate between the the clients where the greatest priority (1=lowest) wins. The following operations can enact changes in opstate data nodes: create, delete, remove, reset.
The default-operations parameter flags are: merge, replace, or none. The test-option parameters flags are: test-then-set, set, and test-only. The error-option oarameter flags are: stop-on-error, continue-on-error, and rollback-on-error. The priority parameter is a integer giving the priority (range 1..5000).
The test-option parameters MAY only be set if the device advertises the :validate:1.1 capability. If test-option is set without the :validate:1.1 capability, an error is returned "no support for test-option".
The error-option subparameter "rollback-on-error" is enabled only if the :rollback-on-error capability is set and the data is under the config parameter.
A URL is accepted within the <source> or <target> parameters if the :url capability is set. An XPATH is accepted within the <source> or <target> parameters if the :xpath capability is set.
The following are the defaults:
The NETCONF priority for the "write data" function is simply the Netconf priority range. If implementations have an internal priority, the precedence between the local configuration and the NETCONF supplied configuration is set by a operator applied knob. For example, an implementation could indicate that the local configuration priority can range from 0-10 and the NETCONF priority is 10 plus the value of the priority parameter.
The target is a datastore whose name is registered with IANA.
Example Write data
dsname = i2rs-agent
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<write data>
<target><i2rs-agent></target>
<operation>merge</operation>
<priority>50<</priority>
<error-option>all-or-nothing</error-option>
<config>
<top xmlns:t=
"http://example.com/schema/1.0/i2rs/tiny-rt-instance">
<route-list>
<route-index>1</route-index>
<prefix-match>192.2/8 /16<prefix-match>
<nexthop>129.1.5.1</nexthop>
<if-outgoing>Eth0</if-outgoing>
</route-list<
</top>
</config>
</write data>
The description of each operation is below:
The priority parameter sets a integer value for the priority as shown in figure x.
The <test-option> parameter performs basic function it does in the <edit-config> basic function. Just in [RFC6241], the <test-option> parameter MAY be specified only if the device advertises the ":validate:1.1" capability. The only difference is that the validation specified by the data model may augment the validation test and the valdiation will also include the ability of the client to set this element. If a validation error occurs, the test-then-set will not perform the write-data function.
<error-option> has the following attributes
This option requires the server to support the :rollback-on-error capability.
This operation associates a secondary identifier with a set of write-data operations. The secondary identifier is an opaque string.
The following protocol operations are not supported in the control plane datastore:
The <close-session> is modified to take a target of a control plane datastore name (registered with IANA). Since no locks are set, none should be released.
The <kill-session> is modified to take a target of a control plane datastore name (registered with IANA). Since no locks are set, none should be released.
The following capabilities are not supported:
The rollback-on-error allows the error handling to be roll-back-on-error (all-or-nothing in I2RS terms) for the control plane datastore. The control plane datastore name is a valid target if the rollback-on-error capability is combined with the control plane datastore capability.
The validation capability engated with the control plane capability operates to validate the config portion of the control plane datastore. Therefore, the <target> is allowed to have a datstore name which is registered with IANA.
The validation of the configuration portion may contain the "validation" yang command which provides alternative validation mechanisms for specific data objects.
The URL capabilities specify a <url> in the <source> and <target> operate as normal, but are allowed to specify a module within a control plane datastore.
capability-name: control-plane
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]. Many of these require fulfilled by the NETCONF control-plane capabilty(Ephemeral-REQ-07, Ephemeral-REQ-11, Ephemeral-REQ-12, Ephemeral-REQ-13, Ephemeral-REQ-14, Ephemeral-REQ-16).
The key features include:
Ephemeral state is not supported in the configuration datstore. The ephemeral state capability depends on having the control-plane datastore capability enabled (with appropriate NETCONF capabilities described above), and an IANA registered datastore name.
Yang must support the ability to to denote that a datastore, module, submodule or object within a module can be denoted as ephemeral. This capbility depends on the yang additions described in [I-D.hares-netmod-i2rs-yang] for control plane datastores, ephemeral key word, and validation key word.
Ephemeral state operation depends on notification of events and traceability of errors. I2RS ephemeral state requires that
Note: One operation that is suggested for ephemeral state is to set resource limits. It does not seem to be an ephemeral state issue, but a control plane issue. This feature is placed here until future discussion for I2RS WG.
resource-limits
definition - TBD
The [I-D.ietf-i2rs-ephemeral-state] suggests setting these limits, but it does not seem to be an ephemeral function.
The ephemeral state only works as an augment to the control-plane datastore. Therefore, the following protocol operations, which are not supported in the control-plane datastore capability, are also not supported in the ephemeral capability:
The ephemeral state only works as an augment to the control-plane datastore with specific ephemeral validations. Therefore, the <close-session> and <kill-session> are modified as described in the sections below.
The <close-session> is modified to take a target of a control plane datastore name (registered with IANA). Since no locks are set, none should be released.
The <kill-session> is modified to take a target of a control plane datastore name (registered with IANA). Since no locks are set, none should be released.
The ephemeral state may require validation to determine if the constraints obey ephemeral-state rules. If the :validate capability is used, the following parameter requires ephemeral-state contraints (Ephemeral-REQ-02, Ephemeral-REQ-03, and Ephemeral-REQ-04). If the ephemeral-constraint parameter is engaged for a module or object that is not ephemeral, the parameter is silently ignored. Error information is forwarded to the event notification processes and the traceability functions.
Additional Parameter
ephemeral-constraint
datastoredef cp-alpha {
dstype control-plane;
description {
"example control plane datastore ";
}
module-list tiny-rt-instance;
precedence applied {
precedenceval 5;
}
precedence opstate {
precedenceval 5;
}
}
datastoredef cp-beta {
dstype control-plane i2rs-v0;
description {
"example control plane datastore ";
}
module-list tiny-rib;
ephemeral true;
precedence applied {
precedenceval 50;
}
precedence opstate {
precedenceval 50;
}
}
module cp-example-1 {
namespace "http://exaple.com/schema/cp-examples/1.1/tiny-rib";
prefix trib;
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix yang;
}
grouping trib-rt {
description "tiny rib route";
leaf route-index {
type uint64;
mandatory true;
description "route index";
}
leaf v4-prefix-match {
type inet:ipv4-prefix;
mandatory true;
}
leaf v4-nexthop {
type inet:ipv4
mandatory true;
}
leaf if-outgoing {
type if:interface-ref;
mandatory true;
description {
"Name of outgoing interface";
}
leaf installed {
type boolean;
config false;
description "rt install status ";
}
}
container tiny-rt-instance {
description
"Tiny routing instance for
example purposes";
leaf name {
type string;
description
"The name of routing instance
which must be unique. ";
}
list route-list {
key "route-index";
description
"a list of routes of rib"
uses trib-rt;
}
}
rpc trib-add {
description "add route to tiny rib";
input {
leaf datastore {
type string; //iana registered
mandatory true;
description
"iana datastore name";
}
container trib-routes {
description
"Tiny rib routes to be added
to tiny rib";
list route-list {
key "route-index";
users trib-rt;
}
}
}
output {
container trib-add-status {
leaf success {
type boolean;
description "add succeded";
}
leaf failure-reason {
type string;
description "reason for failure ";
}
}
}
}
TBD
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.
TBD
| [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-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-rfc6536bis] | Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", Internet-Draft draft-ietf-netconf-rfc6536bis-00, January 2017. |
| [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. |