draft-ietf-netmod-arch-06.txt   draft-ietf-netmod-arch-07.txt 
Network Working Group P. Shafer Network Working Group P. Shafer
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational June 16, 2010 Intended status: Informational June 23, 2010
Expires: December 18, 2010 Expires: December 25, 2010
An Architecture for Network Management using NETCONF and YANG An Architecture for Network Management using NETCONF and YANG
draft-ietf-netmod-arch-06 draft-ietf-netmod-arch-07
Abstract Abstract
NETCONF gives access to native capabilities of the devices within a NETCONF gives access to native capabilities of the devices within a
network, defining methods for manipulating configuration databases, network, defining methods for manipulating configuration databases,
retrieving operational data, and invoking specific operations. YANG retrieving operational data, and invoking specific operations. YANG
provides the means to define the content carried via NETCONF, both provides the means to define the content carried via NETCONF, both
data and operations. Using both technologies, standard modules can data and operations. Using both technologies, standard modules can
be defined to give interoperability and commonality to devices, while be defined to give interoperability and commonality to devices, while
still allowing devices to express their unique capabilities. still allowing devices to express their unique capabilities.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2010. This Internet-Draft will expire on December 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . 4 1.1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . 4
2. Elements of the Architecture . . . . . . . . . . . . . . . . . 6 2. Elements of the Architecture . . . . . . . . . . . . . . . . . 6
2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 8 2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 8
2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 11 2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 12 2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12 2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12
2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13 2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13
2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 14 2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 14
2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 15 2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 14
3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 16 3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Building NETCONF- and YANG-based Solutions . . . . . . . . 16 3.1. Building NETCONF- and YANG-based Solutions . . . . . . . . 15
3.2. Addressing Operator Requirements . . . . . . . . . . . . . 17 3.2. Addressing Operator Requirements . . . . . . . . . . . . . 16
3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 19 3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 18
3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 20 3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 19
3.3.4. Application Developer . . . . . . . . . . . . . . . . 21 3.3.4. Application Developer . . . . . . . . . . . . . . . . 20
4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 24 4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 23
4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 24 4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 26 4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 25
4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 26 4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 25
4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 27 4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 26
4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 28 4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7. Normative References . . . . . . . . . . . . . . . . . . . . . 32 7. Normative References . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
1.1. Origins of NETCONF and YANG 1.1. Origins of NETCONF and YANG
Networks are increasing in complexity and capacity, as well as the Networks are increasing in complexity and capacity, as well as the
density of the services deployed upon them. Uptime, reliability, and density of the services deployed upon them. Uptime, reliability, and
predictable latency requirements drive the need for automation. The predictable latency requirements drive the need for automation. The
problems with network management are not simple. They are complex problems with network management are not simple. They are complex
and intricate. But these problems must be solved for networks to and intricate. But these problems must be solved for networks to
skipping to change at page 4, line 26 skipping to change at page 4, line 26
supply of qualified networking engineers. supply of qualified networking engineers.
In June of 2002, Internet Architecture Board (IAB) held a workshop on In June of 2002, Internet Architecture Board (IAB) held a workshop on
Network Management ([RFC3535]). The members of this workshop made a Network Management ([RFC3535]). The members of this workshop made a
number of observations and recommendations for the IETF's number of observations and recommendations for the IETF's
consideration concerning the issues operators were facing in their consideration concerning the issues operators were facing in their
network management-related work as well as issues they were having network management-related work as well as issues they were having
with the direction of the IETF activities in this area. with the direction of the IETF activities in this area.
The output of this workshop was focused on current problems. The The output of this workshop was focused on current problems. The
operator's needs were reasonable and straight forward, including the observations were reasonable and straight forward, including the need
need for transactions, rollback, low implementation costs, and the for transactions, rollback, low implementation costs, and the ability
ability to save and restore the device's configuration data. Many of to save and restore the device's configuration data. Many of the
the observations give insight into the problems operators were having observations give insight into the problems operators were having
with existing network management solutions, such as the lack of full with existing network management solutions, such as the lack of full
coverage of device capabilities and the ability to distinguish coverage of device capabilities and the ability to distinguish
between configuration data and other types of data. between configuration data and other types of data.
Based on these directions, the NETCONF working group was formed and Based on these directions, the NETCONF working group was formed and
the Network Configuration (NETCONF) protocol was created. This the Network Configuration (NETCONF) protocol was created. This
protocol defines a simple mechanism where network management protocol defines a simple mechanism where network management
applications, acting as clients, can invoke operations on the applications, acting as clients, can invoke operations on the
devices, which act as servers. The NETCONF specification defines a devices, which act as servers. The NETCONF specification defines a
small set of operations, but goes out of its way to avoid making any small set of operations, but goes out of its way to avoid making any
skipping to change at page 8, line 5 skipping to change at page 8, line 5
"startup" configuration datastore, whether the current or "running" "startup" configuration datastore, whether the current or "running"
datastore is directly writable, or whether there is a "candidate" datastore is directly writable, or whether there is a "candidate"
configuration datastore where configuration changes can be made that configuration datastore where configuration changes can be made that
will not affect the device until a "commit-configuration" operation will not affect the device until a "commit-configuration" operation
is invoked. is invoked.
NETCONF defined operations that are invoked as RPCs from the client NETCONF defined operations that are invoked as RPCs from the client
(the application) to the server (running on the device). The (the application) to the server (running on the device). The
following table lists these operations: following table lists these operations:
+----------------------+--------------------------------------------+ +-------------+----------------------------------------------------+
| Operation | Description | | Operation | Description |
+----------------------+--------------------------------------------+ +-------------+----------------------------------------------------+
| commit-configuration | Commits the "candidate" configuration to | | commit | Commits the "candidate" configuration to "running" |
| | "running" | | copy-config | Copy one configuration datastore to another |
| copy-configuration | Copy one configuration datastore to | | edit-config | Change the contents of a configuration database |
| | another | | get-config | Retrieve all or part of a configuration datastore |
| edit-configuration | Change the contents of a configuration | | lock | Prevent changes to a datastore from another party |
| | database | | unlock | Release a lock on a datastore |
| get-configuration | Retrieve all or part of a configuration | +-------------+----------------------------------------------------+
| | datastore |
| lock-configuration | Prevent changes to a datastore from |
| | another party |
| unlock-configuration | Release a lock on a datastore |
+----------------------+--------------------------------------------+
NETCONF's "capability" mechanism allows the device to announce the NETCONF's "capability" mechanism allows the device to announce the
set of capabilities that the device supports, including protocol set of capabilities that the device supports, including protocol
operations, datastores, data models, and other abilities. These are operations, datastores, data models, and other abilities. These are
announced during session establishment as part of the <hello> announced during session establishment as part of the <hello>
message. A client can inspect the hello message to determine what message. A client can inspect the hello message to determine what
the device is capable of and how to interact with the device to the device is capable of and how to interact with the device to
perform the desired tasks. perform the desired tasks.
NETCONF also defines a means of sending asynchronous notifications NETCONF also defines a means of sending asynchronous notifications
 End of changes. 8 change blocks. 
47 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/