draft-ietf-netmod-arch-00.txt		draft-ietf-netmod-arch-01.txt
	Network Working Group P. Shafer		Network Working Group P. Shafer
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Informational March 3, 2009		Intended status: Informational May 26, 2009
	Expires: September 4, 2009		Expires: November 27, 2009
	An Architecture for Network Management		An NETCONF- and NETMOD-based Architecture for Network Management
	draft-ietf-netmod-arch-00		draft-ietf-netmod-arch-01
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32		skipping to change at page 1, line 32
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 4, 2009.		This Internet-Draft will expire on November 27, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document.
	to this document.
	Abstract		Abstract
	NETCONF and YANG are pieces of an ambitious plan to improve network		NETCONF gives access to native capabilities of the devices within a
	management. NETCONF gives access to native capabilities of the		network, defining methods for manipulating configuration databases,
	devices within a network, defining methods for manipulating		retrieving operational data, and invoking specific operations. YANG
	configuration databases, retrieving operational data, and invoking		provides the means to define the content carried via NETCONF, both
	specific operations. YANG provides the means to define the content		data and operations. Using both technologies, standard modules can
	trafficked via NETCONF, both data and operations. Using both		be defined to give interoperability and commonality to devices, while
	technologies, standard modules can be defined to give		still allowing devices to express their unique capabilities.
	interoperability and commonality to devices, while still allowing
	devices to express their unique capabilities.
	This document describes how NETCONF and YANG help build network		This document describes how NETCONF and YANG help build network
	management applications that meet the needs of network services		management applications that meet the needs of network operators.
	providers.
	Table of Contents		Table of Contents
	1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.3.1. Extensibility Model . . . . . . . . . . . . . . . . . 8		2.3.1. Extensibility Model . . . . . . . . . . . . . . . . . 8
	3. An Architecture for NETMOD . . . . . . . . . . . . . . . . . . 10		3. An Architecture for NETMOD . . . . . . . . . . . . . . . . . . 10
	skipping to change at page 2, line 43		skipping to change at page 2, line 40
	4.3. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14		4.3. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
	5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Device Developer . . . . . . . . . . . . . . . . . . . . . 15		5.1. Device Developer . . . . . . . . . . . . . . . . . . . . . 15
	5.2. Generic Content Support . . . . . . . . . . . . . . . . . 15		5.2. Generic Content Support . . . . . . . . . . . . . . . . . 15
	5.3. XML "over the wire" Definitions . . . . . . . . . . . . . 15		5.3. XML "over the wire" Definitions . . . . . . . . . . . . . 15
	5.4. Application Developer . . . . . . . . . . . . . . . . . . 15		5.4. Application Developer . . . . . . . . . . . . . . . . . . 15
	5.4.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 15		5.4.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 15
	5.4.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 16		5.4.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 16
	5.4.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 16		5.4.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 16
	6. Modeling Considerations . . . . . . . . . . . . . . . . . . . 17		6. Modeling Considerations . . . . . . . . . . . . . . . . . . . 17
	7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. Normative References . . . . . . . . . . . . . . . . . . . . . 19
	9. Normative References . . . . . . . . . . . . . . . . . . . . . 20		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Key Words		1. Key Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14, [RFC2119].		14, [RFC2119].
	2. Introduction		2. Introduction
	skipping to change at page 6, line 7		skipping to change at page 6, line 7
	NETCONF includes mechanisms for controlling configuration datastores,		NETCONF includes mechanisms for controlling configuration datastores,
	fetching state data, receiving notifications, and allows for		fetching state data, receiving notifications, and allows for
	additional RPC methods. Configuration operations include the ability		additional RPC methods. Configuration operations include the ability
	to lock datastores to isolate one application from the actions of		to lock datastores to isolate one application from the actions of
	others, the ability to save and restore configuration data sets, and		others, the ability to save and restore configuration data sets, and
	the ability to discover (via the <hello> message) the capabilities of		the ability to discover (via the <hello> message) the capabilities of
	the device.		the device.
	2.3. YANG		2.3. YANG
	YANG is a data model language for NETCONF that allows the description		YANG is the data model language for NETCONF that allows the
	of hierarchies of nodes and the constraints that exist amongst them.		description of hierarchies of data model nodes ("nodes") and the
	YANG defines data models and how to manipulate those models via		constraints that exist amongst them. YANG defines data models and
	NETCONF protocol operations.		how to manipulate those models via NETCONF protocol operations.
	Each yang module define a data model, uniquely identified by a		Each YANG module defines a data model, uniquely identified by a
	namespace URI. These data models are extensible in a manner that		namespace URI. These data models are extensible in a manner that
	allows tight integration of standard data models and proprietary data		allows tight integration of standard data models and proprietary data
	models. Models are built from organizational containers, lists of		models. Models are built from organizational containers, lists of
	data instances and leaf data values.		data instances and leaf data values.
	module ietf-ospf {		module ietf-ospf {
	namespace http://ns.ietf.org/netconf/ospf;		namespace http://ns.ietf.org/netconf/ospf;
	prefix ospf;		prefix ospf;
	import network-types { // Access another module's def'ns		import network-types { // Access another module's def'ns
	skipping to change at page 7, line 51		skipping to change at page 8, line 5
	}		}
	}		}
	}		}
	}		}
	A YANG module defines a data model in terms of the data, its		A YANG module defines a data model in terms of the data, its
	hierarchical organization, and the constraints on that data. YANG		hierarchical organization, and the constraints on that data. YANG
	defines how this data is represented in XML and how that data is used		defines how this data is represented in XML and how that data is used
	in NETCONF operations.		in NETCONF operations.
	Open source tools for YANG are available on
	http://www.yang-central.org.
	2.3.1. Extensibility Model		2.3.1. Extensibility Model
	XML includes the concept of namespaces, allowing XML elements from		XML includes the concept of namespaces, allowing XML elements from
	different sources to be combined in the same hierarchy without		different sources to be combined in the same hierarchy without
	risking collision. YANG modules define content for specific		risking collision. YANG modules define content for specific
	namespaces, but one module may augment the definition of another		namespaces, but one module may augment the definition of another
	module, introducing elements from that module's namespace into the		module, introducing elements from that module's namespace into the
	first module's hierarchy.		first module's hierarchy.
	Since one module can augment another module's definition, hierarchies		Since one module can augment another module's definition, hierarchies
	skipping to change at page 8, line 31		skipping to change at page 8, line 31
	vendor module may augment this with vendor-specific extensions.		vendor module may augment this with vendor-specific extensions.
	module vendorx-ospf {		module vendorx-ospf {
	namespace http://vendorx.example.com/ospf;		namespace http://vendorx.example.com/ospf;
	prefix vendorx;		prefix vendorx;
	import ietf-ospf {		import ietf-ospf {
	prefix ospf;		prefix ospf;
	}		}
			BL: need leading slash:
	augment ospf:ospf/ospf:area/ospf:interfaces {		augment ospf:ospf/ospf:area/ospf:interfaces {
	leaf no-neighbor-down-notification {		leaf no-neighbor-down-notification {
	type empty;		type empty;
	description "Don't inform other protocols about"		description "Don't inform other protocols about"
	+ " neighbor down events";		+ " neighbor down events";
	}		}
	}		}
	}		}
	The <no-neighbor-down-notification> element is then placed in the		The <no-neighbor-down-notification> element is then placed in the
	skipping to change at page 10, line 32		skipping to change at page 10, line 32
	Applications may take advantage of these specifics to give their		Applications may take advantage of these specifics to give their
	users complete control over the device.		users complete control over the device.
	When a NETCONF session begins, the namespaces for all supported		When a NETCONF session begins, the namespaces for all supported
	modules are announced as capabilities via the device's <hello>		modules are announced as capabilities via the device's <hello>
	message. The device should also support the schema discovery		message. The device should also support the schema discovery
	mechanism [ref], enabling applications to discover the location from		mechanism [ref], enabling applications to discover the location from
	which the modules may be downloaded.		which the modules may be downloaded.
	The schema discovery for standard YANG modules should list a common,		The schema discovery for standard YANG modules should list a common,
	standard location for these modules, assumably one set by the		standard location for these modules, presumably one set by the
	organization that defined the standard.		organization that defined the standard.
	When an application connects with a device, it receives the list of		When an application connects with a device, it receives the list of
	capabilities supported by that device. The application may compare		capabilities supported by that device. The application may compare
	the set of capabilities announced by the device with the set of		the set of capabilities announced by the device with the set of
	modules the application is aware of. Any new modules or new		modules the application is aware of. Any new modules or new
	revisions of known modules may be downloaded as needed from the		revisions of known modules may be downloaded as needed from the
	locations given via the schema discovery mechanism.		locations given via the schema discovery mechanism.
	Once the application has access to the YANG modules, it may		Once the application has access to the YANG modules, it may
	skipping to change at page 13, line 32		skipping to change at page 13, line 32
	4.1. YIN		4.1. YIN
	In some environments, incorporating a YANG parser may not be an		In some environments, incorporating a YANG parser may not be an
	acceptable option. For those scenarios, an XML grammar for YANG is		acceptable option. For those scenarios, an XML grammar for YANG is
	defined in YIN (YANG Independent Notation) [ref]. YIN allows the use		defined in YIN (YANG Independent Notation) [ref]. YIN allows the use
	of XML parsers which are readily available in both open source and		of XML parsers which are readily available in both open source and
	commercial versions. Conversion between YANG and YIN is direct,		commercial versions. Conversion between YANG and YIN is direct,
	loss-less and reversible. YANG statements are converted to XML		loss-less and reversible. YANG statements are converted to XML
	elements, preserving the structure and content of YANG, but enabling		elements, preserving the structure and content of YANG, but enabling
	the use of "off the shelf" XML parsers rather than requiring the		the use of off-the-shelf XML parsers rather than requiring the
	integration of a YANG parser. YIN maintains complete semantic		integration of a YANG parser. YIN maintains complete semantic
	equivalence with YANG.		equivalence with YANG.
			BL: use of xslt is a key use
	4.2. DSDL (Relax NG)		4.2. DSDL (Relax NG)
	Since NETCONF content is encoded in XML, it is natural to use XML		Since NETCONF content is encoded in XML, it is natural to use XML
	Schema Languages for their validation. To facilitate this, YANG		schema languages for their validation. To facilitate this, YANG
	offers a standardized mapping of YANG modules into Document Schema		offers a standardized mapping of YANG modules into Document Schema
	Description Languages (DSDL) [DSDL].		Description Languages (DSDL) [DSDL].
	DSDL is considered to be the best choice for the given purpose		DSDL is considered to be the best choice for the given purpose
	because it addresses not only grammar and datatypes of XML documents		because it addresses not only grammar and datatypes of XML documents
	but also semantic constraints and rules for modifying information set		but also semantic constraints and rules for modifying information set
	of the document.		of the document.
	In addition, DSDL offers formal means for coordinating multiple		In addition, DSDL offers formal means for coordinating multiple
	independent schemas and specifying how to apply the schemas to the		independent schemas and specifying how to apply the schemas to the
	various parts of the document. This is useful since YANG content is		various parts of the document. This is useful since YANG content is
	typically composed of multiple vocabularies.		typically composed of multiple vocabularies.
	4.3. YANG Types		4.3. YANG Types
			YANG supports a number of builtin types, and allows additional types
			to be derived from those types in an extensible manner. New types
			can add additional restrictions to allowable data values.
	A standard type library for use by YANG is available [ref]. These		A standard type library for use by YANG is available [ref]. These
	YANG modules define commonly used data types for IETF-related		YANG modules define commonly used data types for IETF-related
	standards.		standards.
	5. Applicability		5. Applicability
	The data model in a YANG module yields value in five specific areas.		The data model in a YANG module yields value in five specific areas.
	5.1. Device Developer		5.1. Device Developer
	skipping to change at page 16, line 26		skipping to change at page 16, line 26
	treating that data without specific understanding.		treating that data without specific understanding.
	YANG modules may be used to drive the operation of the YANG		YANG modules may be used to drive the operation of the YANG
	equivalent of a "MIB Browser". Such an application manipulates the		equivalent of a "MIB Browser". Such an application manipulates the
	device's configuration data based on the data organization contained		device's configuration data based on the data organization contained
	in the YANG module. For example, a GUI may present a straight-		in the YANG module. For example, a GUI may present a straight-
	forward visualization where elements of the YANG hierarchy are		forward visualization where elements of the YANG hierarchy are
	depicted in a hierarchy of folders or GUI panels. Clicking on a line		depicted in a hierarchy of folders or GUI panels. Clicking on a line
	expands to the contents of the matching content.		expands to the contents of the matching content.
			BL: GUI comments don't need to be here
	This type of GUI can easily be built by generating XSLT stylesheets		This type of GUI can easily be built by generating XSLT stylesheets
	from the YANG data models. An XSLT engine can then be used to turn		from the YANG data models. An XSLT engine can then be used to turn
	configuration data into a set of web pages.		configuration data into a set of web pages.
	The YANG modules allows the application to enforce a set of		The YANG modules allows the application to enforce a set of
	constraints without understanding the semantics of the YANG module.		constraints without understanding the semantics of the YANG module.
	5.4.3. Top Down		5.4.3. Top Down
	In contrast to the bottom-up approach, the top-down approach allows		In contrast to the bottom-up approach, the top-down approach allows
	skipping to change at page 17, line 23		skipping to change at page 17, line 23
	o [modeled deviations] behavior that follows within deviations		o [modeled deviations] behavior that follows within deviations
	allowed by the model		allowed by the model
	o [allowable deviations] behavior that falls outside the model, but		o [allowable deviations] behavior that falls outside the model, but
	can still be handled		can still be handled
	o [unacceptable deviations] behavior that is not at all consistent		o [unacceptable deviations] behavior that is not at all consistent
	with the model		with the model
	Once the model is published, an implementer may decide to make a		Once the model is published, an implementer may decide to make a
	particular node configurable, where the standard model describes it a		particular data model node configurable, where the standard model
	state data. The implementation reports the value normally and may		describes it a state data. The implementation reports the value
	have an "out of band" mechanism for reporting that this node behaves		normally and may have an "out of band" mechanism for reporting that
	in a different manner than the standard. Applications capable of		this device behaves in a different manner than the standard.
	discovering such behavior can make allowances, but applications that		Applications capable of discovering such behavior can make
	do not discover such behavior can continue treating the		allowances, but applications that do not discover such behavior can
	implementation as if it were compliant.		continue treating the implementation as if it were compliant.
	Rarely, implementations may make decisions that prevent compliance		Rarely, implementations may make decisions that prevent compliance
	with the standard. Such occasions are regrettable, but they remain a		with the standard. Such occasions are regrettable, but they remain a
	part of reality, and modelers and application writers ignore them at		part of reality, and modelers and application writers ignore them at
	their own risk. An implementation that emits an integer leaf as		their own risk. An implementation that emits an integer leaf as
	"cow" would be difficult to manage, but applications must expect to		"cow" would be difficult to manage, but applications must expect to
	encounter such misbehaving devices in the field.		encounter such misbehaving devices in the field.
	Despite this, both client and server should view the YANG module as a		Despite this, both client and server should view the YANG module as a
	contract, with both sides agreeing to abide by the terms. The		contract, with both sides agreeing to abide by the terms. The
	modeler should be explicit about the terms of such a contract, and		modeler should be explicit about the terms of such a contract, and
	both client and server implementations should strive to faithfully		both client and server implementations should strive to faithfully
	and accurately implement the data model described in the YANG module.		and accurately implement the data model described in the YANG module.
	7. Conclusion		7. Security Considerations
	The YANG design committee and the NETMOD working group have used the
	implementation experience of their members to build a data modeling
	language for NETCONF that balances simplicity, flexibility, and
	extensibility in a harmony unequaled since the dawn of the claw
	hammer. The development of multiple YANG implementations has given
	us early feedback on technical issues and helped crisp the wording of
	many issues in the YANG specification.
	8. Security Considerations
	This document defines a language with which to write and read		This document defines a language with which to write and read
	descriptions of management information. The language itself has no		descriptions of management information. The language itself has no
	security impact on the Internet.		security impact on the Internet.
	9. Normative References		8. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,		[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
	December 2006.		December 2006.
	[YANG] Bjorklund, M., Ed., "YANG - A data modeling language for		[YANG] Bjorklund, M., Ed., "YANG - A data modeling language for
	NETCONF", draft-ietf-netmod-yang-00 (work in progress).		NETCONF", draft-ietf-netmod-yang-05 (work in progress).
	Author's Address		Author's Address
	Phil Shafer		Phil Shafer
	Juniper Networks		Juniper Networks
	Email: phil@juniper.net		Email: phil@juniper.net
End of changes. 21 change blocks.
	56 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/