Internet DRAFT - draft-frank-netconf-conformance
draft-frank-netconf-conformance
INTERNET-DRAFT Frank Feng
Intended Status: Proposed Standard ZTE
Xu Ye
ZTE
Expires: January 15, 2015 September 16, 2014
The mechanism to advertise schema conformance of NETCONF
draft-frank-netconf-conformance-00
Abstract
This document describes the unified mechanism to advertise schema
conformance of the Network Configuration Protocol (NETCONF).
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 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
frank Expires December 1, 2014 [Page 1]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Conformance Information of Schema . . . . . . . . . . . . . 3
4.2 <get-schema-conformance> Protocol Operation . . . . . . . . 4
4.2.1 <get-schema-conformance> input . . . . . . . . . . . . . 4
4.2.2 <get-schema-conformance> output . . . . . . . . . . . . 4
4.2.3 <get-schema-conformance> YANG Tree Diagram . . . . . . . 4
4.2.4 <get-schema-conformance> Examples . . . . . . . . . . . 5
4.3 "conformance-id" Capability . . . . . . . . . . . . . . . . 6
4.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3.1.1 conformance-id Capability Example . . . . . . . . . 7
4.3.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . 7
4.3.3 Capability Identifier . . . . . . . . . . . . . . . . . 7
4.3.4 New Operations . . . . . . . . . . . . . . . . . . . . . 8
4.3.5 Modifications to Existing Operations . . . . . . . . . . 8
4.3.6. Interactions with Other Capabilities . . . . . . . . . 8
4.4 NETCONF-CONFORMANCE YANG Module . . . . . . . . . . . . . . 8
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 12
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Normative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
frank Expires December 1, 2014 [Page 2]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
1 Introduction
There is a need for standard mechanism to advertise schema
conformance to allow NETCONF[RFC6241] client to know the conformance
information of schemas supported by server. YANG[RFC6020] has already
defined its conformance advertisement mechanism, but NETCONF is lack
of a unified way to advertise the schema's conformance.
1.1 Terminology
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 Problem Statement
YANG[RFC6020] has already define its conformance advertisement
mechanism in section 5.6.4, RFC6020. But it have several problems
listed below:
1. YANG is a data model language, it SHOULD NOT define how to
advertise conformance information in protocol(e.g. NETCONF).
2. If a server supports over hundreds of YANG modules, the hello
message will be very large.
3. client does not need always receive all modules' advertisement
in hello message, when it connects to NETCONF server. e.g., the TCP
connection is closed and client reconnects to NETCONF server, the
information of schema conformance has no any change.
4. schemas not based YANG have no any standard mechanism to
advertise their conformance information. So, NETCONF SHOULD provide
a standard way to advertise the conformance information of schemas,
include YANG and not YANG.
3 Solution
o remove the specification about advertisement of model conformance
from YANG. This is the Y54 in YANG1.1 issues list.
o use conformance-id instead of conformance information of all
schemas in NETCONF hello message.
o provide a standard RPC called get-schema-conformance for client
to get the conformance information when the client wants to know it.
4 Definitions
4.1 Conformance Information of Schema
Conformance is a measure of how accurately a device follows the
schema. Generally speaking, devices are responsible for implementing
the model faithfully, allowing applications to treat devices which
implement the model identically. But in real world, devices are
often not able or designed to realize all functions defined by
frank Expires December 1, 2014 [Page 3]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
schema. In order to avoid conflict, NETCONF server MUST have
capability to advertise conformance information. Conformance
information can be considered by three parts listed below:
o schemas supported by server schemas supported by NETCONF server
MUST be advertised when client requests it. The information includes
schema's name, revision and namespace.
o optional functions supported by server If a schema defined servral
optional functions, the server MUST define whether these functions
are supported. When client requests it, server MUST advertised all
identifiers of functions what server supported.
o deviations declared by server In an ideal world, all devices would
be required to implement the schema exactly as defined, and
deviations from the schema woucld not be allowed. But in the real
world, devices are often not able or designed to implement the schema
as written.
So, In order to keep consistent schemas between client and server,
server MUST have capability to declare the deviations from the schema
when client request it.
The information of deviation SHOULD include the deviated node's path
and the detail information of how implementation deviated from
schema.
4.2 <get-schema-conformance> Protocol Operation
This operation allows the client to get server Schemas information.
The operation can have filter parameters to get the schemas
information which the client concerned. If the operation hasn't any
parameter , it indicates that the server SHOULD reply all supported
schemas information.
4.2.1 <get-schema-conformance> input
o filter: A choice indicating the content filter specification for
the retrieval request.
4.2.2 <get-schema-conformance> output
Positive Response: A <data> element is returned which contains the
data corresponding to the input parameters specified in the request.
The child nodes of the <data> container correspond to Schemas
information module. The Schemas information are conformance
information of schema which introduced in section 4.1.
Negative Response: An <rpc-error> response is sent if the request
cannot be completed for any reason.
4.2.3 <get-schema-conformance> YANG Tree Diagram
+--x get-schema-conformance +--ro input
| +--ro filter?
| +--ro modules
| +--ro module* string
+--ro output
+--ro data
frank Expires December 1, 2014 [Page 4]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
+--ro modules
+--ro module*[name]
+--ro name string
+--ro namespace inet:uri
+--ro revision string
+--ro functions?
| +--ro function* string
+--ro deviations?
+--ro deviation*[target]
+--ro target string
+--ro deviates
+--ro deviate*
+--ro type enumeration
+--ro information? string
4.2.4 <get-schema-conformance> Examples
If the client want to get all Schemas information, can send the rpc
request below:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-schema-conformance />
</rpc>
The positive response by the server like:
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<modules>
<module>
<name>module1</name>
<namespace>http://test.com/ns/test1</namespace>
<revision>2014-08-01</revision>
<functions>
<function>function1</function>
<function>function2</function>
</functions>
</module>
<module>
<name>module2</name>
<namespace>http://test.com/ns/test2</namespace>
<revision>2014-08-03</revision>
<deviations>
<deviation>
<target>/configuration/ribs/rib</target>
<deviates>
<deviate>
<type>not-supported</type>
</deviate>
frank Expires December 1, 2014 [Page 5]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
</deviates>
</deviation>
<deviation>
<target>/configuration/ribs/rib-info</target>
<deviates>
<deviate>
<type>replace</type>
<information>config false</information>
</deviate>
</deviates>
</deviation>
</deviations>
</module>
</modules>
</data>
</rpc-reply>
If the client want to get the schema information for only concerned
module, it can send request with filter parameters, such as:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-schema-conformance>
<filter type="subtree">
<modules>
<module>ietf-netconf</module>
</modules>
</get-schema-conformance>
</rpc>
The response for the request is only the concerned module schema
information.
4.3 "conformance-id" Capability
4.3.1 Overview
The conformance-id capability indicates that the server maintains a
conformance ID for the schemas supported by the server.This
identifier value is selected by the server and it will be changed
when the conformance information of schemas changes. When the session
is created, server MUST send current conformance ID via hello message
if server support conformance-id capability. The client SHOULD treat
the conformance ID as an opaque string.
1) Client keeps a cache of server schemas information.
2) Server always sends its current conformance-id value in the
"conformance-id" <capability> URI.
frank Expires December 1, 2014 [Page 6]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
Client Server X <hello> message
+------------------+ +-----------------------------+
| | | conformance-id =1234 |
| Server Schemas | <---- | <capability> |
| Cache | | ... |
+------------------+ +------------------------------+
3) Client checks cache for server X, conformance-id =1234. If found,
then OK to use the cached Schemas information copy. If not found,
then send a < get-schema-conformance > for the current Schemas
information to create or update the cached copy.
The server SHOULD save the conformance ID for Schemas information in
non-volatile storage. When the server boots or restarts, the initial
conformance ID SHOULD be the same as the last instantiation.
4.3.1.1 conformance-id Capability Example
# Server starts session 2 with an abbreviated <hello>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:capability:conformance-
id1.0?id=1234
</capability>
// ... rest of <capability> elements
<capabilities>
<session-id>2</session-id>
</hello>
4.3.2 Dependencies
The conformance-id capability is not dependent on any other
capabilities.
4.3.3 Capability Identifier
The conformance-id capability is identified by the following
capability string:
urn:ietf:params:netconf:capability:conformance-id:1.0
This capability MUST be advertised in every server <hello> message,
if server support this capability. The conformance-id capability URI
MUST contain an "id" argument assigned an opaque string value
indicating the current conformance ID value for server schemas
information.
For example:
urn:ietf:params:netconf:capability:conformance-id:1.0?id=6882391
The current conformance ID value MUST be updated any time when the
server schemas information change.
frank Expires December 1, 2014 [Page 7]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
4.3.4 New Operations
The conformance-id capability does not introduce any new protocol
operations.
4.3.5 Modifications to Existing Operations
The conformance-id capability does not modify any existing protocol
operations.
4.3.6. Interactions with Other Capabilities
The conformance-id capability does not interact with any other
capabilities.
4.4 NETCONF-CONFORMANCE YANG Module
This module imports the "uri" typedef from module "ietf-inet-types"
[RFC 6991].
<CODE BEGINS> file "ietf-netconf-conformance@2014-09-16.yang
module ietf-netconf-conformance {
namespace "urn:ietf:params:xms:ns:yang:ietf-netconf-conformance";
prefix nccon;
import ietf-inet-types {
prefix "inet";
}
organization
"IETF NETCONF (Network Configuration Protocol) Working
Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf>
WG List: <mailto:netconf@ietf.org>
WG Chair: Bert Wijnen
<mailto:bertietf@bwijnen.net>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
Editor: Frank Feng
<mailto:feng.chong33@zte.com.cn>
Editor: Xu Ye
<mailto:ye.xu1@zte.com.cn>";
description
"This module contains a collection of YANG definitions for the
schema conformance advertisement of a NETCONF server.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
frank Expires December 1, 2014 [Page 8]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2014-09-16 {
description
"Initial revision.";
}
/*Features*/
feature conformance-id {
description
"The conformance-id capability indicates that the
server. maintains a conformance ID for the schemas supported
by the server. This identifier value is selected by the server
and it will be changed when the conformance information of
schemas changes. When the session is created, server MUST send
current conformance ID via hello message if server support
conformance-id capability. The client SHOULD treat the
conformance ID as an opaque string.";
}
/*RPCs*/
rpc get-schema-conformance {
description
"This operation allows the client to get server Schemas
information. The operation can have filter parameters to
get the schemas information which the client concerned. If
the operation hasn't any parameter s indicates that the
server SHOULD reply all supported schemas information.";
input {
container filter {
description
"A choice indicating the content filter
specification for the retrieval request.";
container modules {
leaf-list module {
description "The concerned module name list";
type string;
}
}
}
}
output {
container data {
description "The schemas conformance information.";
container modules {
frank Expires December 1, 2014 [Page 9]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
description
"The schemas conformance information of all
supported modules.";
list module {
key name;
leaf name {
description "The supported module name.";
type string;
}
leaf namespace {
description "the module's namespace.";
type inet:uri;
}
leaf revision {
description "the module's revision date.";
type string;
}
container functions {
description
"Functions what the module supported.";
leaf-list function {
description "The functions' name.";
type string;
}
}
container deviations {
description "All deviation information
about this module.";
list deviation {
description "a deviation declared by module.";
key target;
leaf target {
description
"The target node's absolute
schema node identifier.";
type string;
}
container deviates {
description
"All detail information about a
deviation."
list deviate {
description
"A detail information about
a deviation.";
leaf type {
description
frank Expires December 1, 2014 [Page 10]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
"The deviate type of
this deviate. e.g. add";
type enumeration {
enum not-supported;
enum add;
enum replace;
enum delete;
}
}
leaf information {
description
"The detail information of
this deviate.e.g.
'default 100;' or
'config true;'";
type string;
}
}
}
}
}
}
}
}
}
}
}
<CODE ENDS>
frank Expires December 1, 2014 [Page 11]
INTERNET DRAFT conformance advertisement mechanism August 1, 2014
5 Security Considerations
TBD.
4 IANA Considerations
TBD.
5 References
5.1 Normative References
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J.,
Ed., and A. Bierman, Ed., "Network Configuration
Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013.
Authors' Addresses
Frank Feng
Nanjing Institute of ZTE Corporation
No.68 Zijinghua Rd. Yuhuatai District, Nanjing, China
EMail: feng.chong33@zte.com.cn
Xu Ye
Nanjing Institute of ZTE Corporation
No.68 Zijinghua Rd. Yuhuatai District, Nanjing, China
EMail: ye.xu1@zte.com.cn
frank Expires December 1, 2014 [Page 12]
