draft-atlas-i2rs-architecture-00.txt		draft-atlas-i2rs-architecture-01.txt
	Network Working Group A. Atlas		Network Working Group A. Atlas
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Informational J. Halpern		Intended status: Informational J. Halpern
	Expires: December 30, 2013 Ericsson		Expires: January 16, 2014 Ericsson
	S. Hares		S. Hares
	ADARA		ADARA
	D. Ward		D. Ward
	Cisco Systems		Cisco Systems
	June 28, 2013		T. Nadeau
			Juniper Networks
			July 15, 2013
	An Architecture for the Interface to the Routing System		An Architecture for the Interface to the Routing System
	draft-atlas-i2rs-architecture-00		draft-atlas-i2rs-architecture-01
	Abstract		Abstract
	This document describes an architecture for a standard, programmatic		This document describes an architecture for a standard, programmatic
	interface for state transfer in and out of the Internet's routing		interface for state transfer in and out of the Internet's routing
	system. It describes the basic architecture, the components, and		system. It describes the basic architecture, the components, and
	their interfaces with particular focus on those to be standardized as		their interfaces with particular focus on those to be standardized as
	part of I2RS.		part of I2RS.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 39		skipping to change at page 1, line 41
	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 30, 2013.		This Internet-Draft will expire on January 16, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 2, line 19		skipping to change at page 2, line 21
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Functional Overview . . . . . . . . . . . . . . . . . . . 3		1.1. Functional Overview . . . . . . . . . . . . . . . . . . . 3
	1.2. Architectural Overview . . . . . . . . . . . . . . . . . 4		1.2. Architectural Overview . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Key Architectural Properties . . . . . . . . . . . . . . . . 9		3. Key Architectural Properties . . . . . . . . . . . . . . . . 9
	3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9		3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9
	3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 10		3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 9
	3.4. Authorization and Authentication . . . . . . . . . . . . 10		3.4. Authorization and Authentication . . . . . . . . . . . . 10
	4. Network Applications and I2RS Client . . . . . . . . . . . . 10		4. Network Applications and I2RS Client . . . . . . . . . . . . 10
	4.1. Example Network Application: Topology Manager . . . . . . 11		4.1. Example Network Application: Topology Manager . . . . . . 11
	5. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 11		5. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 11
	5.1. Relationship to its Routing Element . . . . . . . . . . . 11		5.1. Relationship to its Routing Element . . . . . . . . . . . 11
	5.2. State Storage . . . . . . . . . . . . . . . . . . . . . . 12		5.2. State Storage . . . . . . . . . . . . . . . . . . . . . . 12
	5.2.1. Starting and Ending . . . . . . . . . . . . . . . . . 12		5.2.1. Starting and Ending . . . . . . . . . . . . . . . . . 12
	5.2.2. Reversion . . . . . . . . . . . . . . . . . . . . . . 13		5.2.2. Reversion . . . . . . . . . . . . . . . . . . . . . . 13
	5.3. Interactions with Local Config . . . . . . . . . . . . . 13		5.3. Interactions with Local Config . . . . . . . . . . . . . 13
	5.4. Routing Components and Associated I2RS Services . . . . . 13		5.4. Routing Components and Associated I2RS Services . . . . . 14
	5.4.1. Unicast and Multicast RIB and LFIB . . . . . . . . . 14		5.4.1. Unicast and Multicast RIB and LFIB . . . . . . . . . 14
	5.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 14		5.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 14
	5.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 15		5.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 15		5.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 15
	6. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 15		6. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 15
	6.1. Protocol Structure . . . . . . . . . . . . . . . . . . . 15		6.1. Protocol Structure . . . . . . . . . . . . . . . . . . . 15
	6.2. Channel . . . . . . . . . . . . . . . . . . . . . . . . . 16		6.2. Channel . . . . . . . . . . . . . . . . . . . . . . . . . 15
	6.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 16		6.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 16
	6.4. Identity and Security Role . . . . . . . . . . . . . . . 16		6.4. Identity and Security Role . . . . . . . . . . . . . . . 16
	6.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 16		6.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 16
	6.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 17		6.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 17
	6.7. Information collection . . . . . . . . . . . . . . . . . 17		6.7. Information collection . . . . . . . . . . . . . . . . . 17
	6.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 18		6.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 17
	6.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 18		6.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 18
	7. Manageability Considerations . . . . . . . . . . . . . . . . 19		7. Manageability Considerations . . . . . . . . . . . . . . . . 19
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	11. Informative References . . . . . . . . . . . . . . . . . . . 20		11. Informative References . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	Routers that form the Internet's routing infrastructure maintain		Routers that form the Internet's routing infrastructure maintain
	state at various layers of detail and function. For example, a		state at various layers of detail and function. For example, a
	typical router maintains a Routing Information Base (RIB), and		typical router maintains a Routing Information Base (RIB), and
	implements routing protocols such as OSPF, ISIS, BGP to exchange		implements routing protocols such as OSPF, ISIS, BGP to exchange
	protocol state and other information about the state of the network		protocol state and other information about the state of the network
	with other routers.		with other routers.
	skipping to change at page 3, line 40		skipping to change at page 3, line 40
	interface for transferring state into and out of the Internet's		interface for transferring state into and out of the Internet's
	routing system, and recognizes that the routing system and a router's		routing system, and recognizes that the routing system and a router's
	OS provide useful mechanisms that applications could harness to		OS provide useful mechanisms that applications could harness to
	accomplish application-level goals.		accomplish application-level goals.
	Fundamental to the I2RS are clear data models that define the		Fundamental to the I2RS are clear data models that define the
	semantics of the information that can be written and read. The I2RS		semantics of the information that can be written and read. The I2RS
	provides a framework for registering for and requesting the		provides a framework for registering for and requesting the
	appropriate information for each particular application. The I2RS		appropriate information for each particular application. The I2RS
	provides a way for applications to customize network behavior while		provides a way for applications to customize network behavior while
	leveraging the existing routing system.		leveraging the existing routing system as much as desired.
	The I2RS, and therefore this document, is specifically focused on an		The I2RS, and therefore this document, are specifically focused on an
	interface for routing and forwarding data.		interface for routing and forwarding data.
	1.1. Functional Overview		1.1. Functional Overview
	There are four key aspects to the I2RS. First, the interface is a		There are four key aspects to the I2RS. First, the interface is a
	programmatic interface meaning that it is asynchronous and offers		programmatic interface which needs to be asynchronous and offers
	fast, interactive access. Second, the I2RS gives access to		fast, interactive access. Second, the I2RS gives access to
	information and state that is not usually configurable or modeled in		information and state that is not usually configurable or modeled in
	existing implementations or configuration protocols. Third, the I2RS		existing implementations or configuration protocols. Third, the I2RS
	gives applications the ability to learn additional, structured,		gives applications the ability to learn additional, structured,
	filterable information and events from the router. Fourth, the I2RS		filterable information and events from the router. Fourth, the I2RS
	will be data-model driven to facilitate extensibility and provide		will be data-model driven to facilitate extensibility and provide
	standard data-models to be used by network applications.		standard data-models to be used by network applications.
	I2RS is described as an asynchronous programmatic interface; the key		I2RS is described as an asynchronous programmatic interface; the key
	properties of which are described in Section 5 of		properties of which are described in Section 5 of
	[I-D.atlas-i2rs-problem-statement].		[I-D.atlas-i2rs-problem-statement].
	Such an interface facilitates the specification of implicitly non-		Such an interface facilitates the specification of implicitly non-
	permanent state into the routing system, that can optionally be made		permanent state into the routing system, that can optionally be made
	permanent. In addition, the extraction of that information and		permanent. In addition, the extraction of that information and
	additional dynamic information from the routing system is a critical		additional dynamic information from the routing system is a critical
	component of the interface. A non-routing protocol or application		component of the interface. A non-routing protocol or application
	could inject state into a network element's OS via the state-		could inject state into a routing element via the state-insertion
	insertion aspects of the interface and that state could then be		aspects of the I2RS and that state could then be distributed in a
	distributed in a routing or signaling protocol.		routing or signaling protocol and/or be used locally (e.g. to program
			the co-located forwarding plane).
	There are several types of information that the I2RS will facilitate		There are several types of information that the I2RS will facilitate
	an I2RS Client obtaining. These range from dynamic event		an I2RS Client obtaining. These range from dynamic event
	notifications (e.g. changes to a particular next-hop, interface up/		notifications (e.g. changes to a particular next-hop, interface up/
	down, etc.)to information collection streams (statistics, topology,		down, etc.)to information collection streams (statistics, topology,
	route changes, etc) to simply read operations. The I2RS provides the		route changes, etc) to simply read operations. The I2RS provides the
	ability for an I2RS client to request filtered and thresholded		ability for an I2RS client to request filtered and thresholded
	information as well as events.		information as well as events.
	The existing mechanisms, such as SNMP and NetConf, that allow state		The existing mechanisms, such as SNMP and NetConf, that allow state
	to be written and read do not meet all of the key properties given in		to be written and read do not meet all of the key properties given in
	[I-D.atlas-i2rs-problem-statement] for I2RS. The overhead of		[I-D.atlas-i2rs-problem-statement] for I2RS. The overhead of
	infrastructure is also quite high and many MIBs do not, in definition		infrastructure can be quite high and many MIBs do not, in definition
	or practice, allow writing of state. There is also very limited		or practice, allow writing of state. There is also very limited
	capability to add new application-specific state to be distributed		capability to add new application-specific state to be distributed
	via the routing system.		via the routing system.
	ForCES is another data-model-driven method for writing state into a		ForCES is another data-model-driven method for writing state into a
	router, but its focus is on the forwarding plane. By focusing on the		router, but its focus is on the forwarding plane. By focusing on the
	forwarding plane, it requires that the forwarding plane be modeled		forwarding plane, it requires that the forwarding plane be modeled
	and programmable and ignores the existence and intelligence of the		and programmable and ignores the existence and intelligence of the
	router OS and routing system. ForCES provides a lower-level		router OS and routing system. ForCES provides a lower-level
	interface than I2RS is intended to address.		interface than I2RS is intended to address.
	skipping to change at page 7, line 6		skipping to change at page 7, line 6
	I2RS Client: The I2RS client implements the I2RS protocol(s). It		I2RS Client: The I2RS client implements the I2RS protocol(s). It
	interacts with other elements of the policy, provisioning, and		interacts with other elements of the policy, provisioning, and
	configuration system by means outside of the scope of the I2RS		configuration system by means outside of the scope of the I2RS
	effort. It interacts with the I2RS clients to collect information		effort. It interacts with the I2RS clients to collect information
	from the routing and forwarding system. Based on the information		from the routing and forwarding system. Based on the information
	and the policy oriented interactions, the I2RS client may also		and the policy oriented interactions, the I2RS client may also
	interact with the I2RS agent to modify the state of the routing		interact with the I2RS agent to modify the state of the routing
	system the client interacts with to achieve operational goals.		system the client interacts with to achieve operational goals.
	As can be seen in Figure 1, an I2RS client can communicate with		As can be seen in Figure 1, an I2RS client can communicate with
	multiple I2RS agents. The application associated with an I2RS client		multiple I2RS agents. An I2RS client may connect to one or more I2RS
	may connect to one or more I2RS agents based upon its needs.		agents based upon its needs. Similarly, an I2RS agent may
	Similarly, an I2RS agent may communicate with multiple I2RS clients -		communicate with multiple I2RS clients - whether to respond to their
	whether to respond to their requests, to send notifications, etc.		requests, to send notifications, etc. Timely notifications are
	Timely notifications are critical so that several simultaneously		critical so that several simultaneously operating applications have
	operating applications have up-to-date information on the state of		up-to-date information on the state of the network.
	the network.
	As can also be seen in Figure 1, an I2RS Agent may communicate with		As can also be seen in Figure 1, an I2RS Agent may communicate with
	multiple clients. Each client may send the agent a variety of write		multiple clients. Each client may send the agent a variety of write
	operations. The handling of this situation has been a source of		operations. The handling of this situation has been a source of
	discussion in the working group. In order to keep the protocol		discussion in the working group. In order to keep the protocol
	simple, the current view is that two clients should not be attempting		simple, the current view is that two clients should not be attempting
	to write (modify) the same piece of information. Such collisions may		to write (modify) the same piece of information. Such collisions may
	happen, but are considered error cases that should be resolved by the		happen, but are considered error cases that should be resolved by the
	network application layer.		network applications and management systems.
	Multiple I2RS clients may need to supply data into the same list		Multiple I2RS clients may need to supply data into the same list
	(e.g. a prefix or filter list); this is not considered an error and		(e.g. a prefix or filter list); this is not considered an error and
	must be correctly handled.		must be correctly handled. The nuances so that writers do not
			normally collide should be handled in the information models.
	The architectural goal for the I2RS is that such errors should		The architectural goal for the I2RS is that such errors should
	produce predictable behaviors, and be reportable to interested		produce predictable behaviors, and be reportable to interested
	clients. The details of the associated policy is discussed in		clients. The details of the associated policy is discussed in
	Section 6.8. The same policy mechanism (simple priority per I2RS		Section 6.8. The same policy mechanism (simple priority per I2RS
	client) applies to interactions between the I2RS agent and the CLI/		client) applies to interactions between the I2RS agent and the CLI/
	SNMP/NetConf as described in Section 5.3.		SNMP/NetConf as described in Section 5.3.
	In addition it can be noted that there may be indirect interactions		In addition it must be noted that there may be indirect interactions
	between write operations. Detection and avoidance of such		between write operations. Detection and avoidance of such
	interactions is outside the scope of the I2RS work and is left to		interactions is outside the scope of the I2RS work and is left to
	agent design and implementation for now. [[Editor's note: This topic		agent design and implementation for now. [[Editor's note: This topic
	needs more discussion in the working group.]]		needs more discussion in the working group.]]
	2. Terminology		2. Terminology
	The following terminology is used in this document.		The following terminology is used in this document.
	agent or I2RS Agent: An I2RS agent provides the supported I2RS		agent or I2RS Agent: An I2RS agent provides the supported I2RS
	services to the local system's routing sub-systems. The I2RS		services to the local system's routing sub-systems. The I2RS
	agent understands the I2RS protocol and can be contacted by I2RS		agent understands the I2RS protocol and can be contacted by I2RS
	clients.		clients.
	client or I2RS Client: A client speaks the I2RS protocol to		client or I2RS Client: A client speaks the I2RS protocol to
	communicate with I2RS Agents and uses the I2RS services to		communicate with I2RS Agents and uses the I2RS services to
	accomplish a task as instructed by the client's local application.		accomplish a task. An I2RS client can be seen as the part of an
	An I2RS client can be seen as the part of an application that		application that uses and supports I2RS and could be a software
	supports I2RS and could be a software library.		library.
	service or I2RS Service: For the purposes of I2RS, a service refers		service or I2RS Service: For the purposes of I2RS, a service refers
	to a set of related state access functions together with the		to a set of related state access functions together with the
	policies that control its usage. The expectation is that a		policies that control their usage. The expectation is that a
	service will be represented by a data-model. For instance, 'RIB		service will be represented by a data-model. For instance, 'RIB
	service' could be an example of a service that gives access to		service' could be an example of a service that gives access to
	state held in a device's RIB.		state held in a device's RIB.
	read scope: The set of information which the I2RS client is		read scope: The set of information which the I2RS client is
	authorized to read. This access includes the permission to see		authorized to read. This access includes the permission to see
	the existence of data and the ability to retrieve the value of		the existence of data and the ability to retrieve the value of
	that data.		that data.
	write scope: The set of field values which the I2RS client is		write scope: The set of field values which the I2RS client is
	authorized to write (i.e. add, modify or delete). This access can		authorized to write (i.e. add, modify or delete). This access can
	restrict what fields can be modified or created, and what specific		restrict what data can be modified or created, and what specific
	value sets and ranges can be installed.		value sets and ranges can be installed.
	scope: When unspecified as either read scope or write scope, the		scope: When unspecified as either read scope or write scope, the
	term scope applies to both the read scope and write scope.		term scope applies to both the read scope and write scope.
	resources: A resource is an I2RS-specific use of memory, storage,		resources: A resource is an I2RS-specific use of memory, storage,
	or execution that a client may consume due to its I2RS operations.		or execution that a client may consume due to its I2RS operations.
	The amount of each such resource that a client may consume in the		The amount of each such resource that a client may consume in the
	context of a particular agent can be constrained. An example of		context of a particular agent can be constrained based upon the
	such a resource could include the number of notifications		client's security role. An example of such a resource could
	registered for. These are not protocol-specific resources or		include the number of notifications registered for. These are not
	network-specific resources.		protocol-specific resources or network-specific resources.
	role or security role: A security role specifies the scope,		role or security role: A security role specifies the scope,
	resources, priorities, etc. that a client or agent has.		resources, priorities, etc. that a client or agent has.
	identity: A client is associated with exactly one specific		identity: A client is associated with exactly one specific
	identity. State can be attributed to a particular identity. It		identity. State can be attributed to a particular identity. It
	is possible for multiple communication channels to use the same		is possible for multiple communication channels to use the same
	identity; in that case, the assumption is that the associated		identity; in that case, the assumption is that the associated
	client is coordinating such communication.		client is coordinating such communication.
	3. Key Architectural Properties		3. Key Architectural Properties
	3.1. Simplicity		3.1. Simplicity
	There have been many efforts over the years to improve the access to		There have been many efforts over the years to improve the access to
	the information known to the routing and forwarding system. Making		the information known to the routing and forwarding system. Making
	such information visible and usable to network management and		such information visible and usable to network management and
	applications has many well-understood benefits. There are two		applications has many well-understood benefits. There are two
	related challenges in doing so. The span of information potentially		related challenges in doing so. First, the span of information
	available is very large. And the variation in the structure and		potentially available is very large. Second, the variation both in
	kinds of operations tends to introduce protocol complexity.		the structure of the data and in the kinds of operations required
			tends to introduce protocol complexity.
	Having noted that, it is also critical to the utility of I2RS that it		Having noted that, it is also critical to the utility of I2RS that it
	be easily deployed and robust. Complexity in the protocol hinders		be easily deployed and robust. Complexity in the protocol hinders
	implementation, robustness, and deployability. Also, complexity in		implementation, robustness, and deployability. Also, complexity in
	the data models tends to actually make it harder to extend rather		the data models frequently makes it harder to extend rather than
	than easier.		easier.
	Thus, one of the key aims for I2RS is the keep the protocol and		Thus, one of the key aims for I2RS is the keep the protocol and
	modeling architecture simple. So for each architectural component or		modeling architecture simple. So for each architectural component or
	aspect, we ask ourselves "do we need this complexity, or is the		aspect, we ask ourselves "do we need this complexity, or is the
	behavior merely nice to have?"		behavior merely nice to have?" Protocol parsimony is clearly a goal.
	3.2. Extensibility		3.2. Extensibility
	There are several ways that the scope of the I2RS work is being		There are several ways that the scope of the I2RS work is being
	restricted in the interests of achieving a deliverable and deployable		restricted in the interests of achieving a deliverable and deployable
	result. We are only looking at the models to be used over the single		result. We are only working on the models to be used over the single
	identified interface. We are only looking at modeling a subset of		identified interface. We are only looking at modeling a subset of
	the data of interest. And we are probably only representing a subset		the data of interest. And we are probably only representing a subset
	of the operations that may eventually be needed (although there is		of the operations that may eventually be needed (although there is
	some hope that we are closer on that aspect than others to what is		some hope that we are closer on that aspect than others to what is
	needed.)		needed.) Thus, it is important to consider extensibility not only of
			the underlying services' data models, but also of the primitives and
			protocol operations.
	At the same time, it is clearly desirable for the data models and		At the same time, it is clearly desirable for the data models and
	protocol operations we define in the I2RS to be useful the in more		protocol operations we define in the I2RS to be useful the in more
	general settings. It should be easy to integrate data models from		general settings. It should be easy to integrate data models from
	the I2RS with other data. Other work should be able to easily extend		the I2RS with other data. Other work should be able to easily extend
	it to represent additional aspects of the network elements or network		it to represent additional aspects of the network elements or network
	systems. Hence, the data model and protocol definitions need to be		systems. Hence, the data model and protocol definitions need to be
	designed to be highly extensible, preferably in a regular and simple		designed to be highly extensible, preferably in a regular and simple
	fashion.		fashion.
	skipping to change at page 10, line 6		skipping to change at page 10, line 4
	At the same time, it is clearly desirable for the data models and		At the same time, it is clearly desirable for the data models and
	protocol operations we define in the I2RS to be useful the in more		protocol operations we define in the I2RS to be useful the in more
	general settings. It should be easy to integrate data models from		general settings. It should be easy to integrate data models from
	the I2RS with other data. Other work should be able to easily extend		the I2RS with other data. Other work should be able to easily extend
	it to represent additional aspects of the network elements or network		it to represent additional aspects of the network elements or network
	systems. Hence, the data model and protocol definitions need to be		systems. Hence, the data model and protocol definitions need to be
	designed to be highly extensible, preferably in a regular and simple		designed to be highly extensible, preferably in a regular and simple
	fashion.		fashion.
	3.3. Model-Driven Programmatic Interfaces		3.3. Model-Driven Programmatic Interfaces
	A critical component of I2RS is the standard information and data		A critical component of I2RS is the standard information and data
	models with their associated semantics. While many routing protocols		models with their associated semantics. While many components of the
	are standardized, associated data models for them are not yet		routing system are standardized, associated data models for them are
	available. Instead, each router uses different information,		not yet available. Instead, each router uses different information,
	mechanisms, and CLI which makes a standard interface for use by		different mechanisms, and different CLI which makes a standard
	applications extremely cumbersome to develop and maintain. Well-		interface for use by applications extremely cumbersome to develop and
	known data modeling languages exist and may be used for defining the		maintain. Well-known data modeling languages exist and may be used
	necessary data models for I2RS.		for defining the data models for I2RS.
	There are several key benefits for I2RS in using model-driven		There are several key benefits for I2RS in using model-driven
	architecture and protocol(s). First, it allows for transferring		architecture and protocol(s). First, it allows for transferring
	data-models whose content is not explicitly implemented or		data-models whose content is not explicitly implemented or
	understood. Second, tools can automate checking and manipulating		understood. Second, tools can automate checking and manipulating
	data; this is particularly valuable for both extensibility and for		data; this is particularly valuable for both extensibility and for
	the ability to easily manipulate and check proprietary data-models.		the ability to easily manipulate and check proprietary data-models.
	The different services provided by I2RS can correspond to separate		The different services provided by I2RS can correspond to separate
	data-models. An I2RS agent can indicate which data-models are		data-models. An I2RS agent may indicate which data-models are
	supported.		supported.
	3.4. Authorization and Authentication		3.4. Authorization and Authentication
	All control exchanges between the I2RS client and agent MUST be		All control exchanges between the I2RS client and agent MUST be
	authenticated and integrity protected (so that the contents cannot be		authenticated and integrity protected (such that the contents cannot
	changed without detection). Manipulation of the system has to be		be changed without detection). Manipulation of the system must be
	accurately attributable. Architecturally, even information		accurately attributable. In an ideal architecture, even information
	collection and notification should be protected, although this is		collection and notification should be protected; this may be subject
	subject to engineering tradeoffs during the design.		to engineering tradeoffs during the design.
	I2RS Agents, in performing information collection and manipulation,		I2RS Agents, in performing information collection and manipulation,
	will be acting on behalf of the I2RS clients. As such, they will		will be acting on behalf of the I2RS clients. As such, they will
	operate based on the lower of the two permissions of the agent itself		operate based on the lower of the two permissions of the agent itself
	and of the client.		and of the client.
	I2RS clients may be operating on behalf of other entities, in any one		I2RS clients may be operating on behalf of other applications. While
	of a range of broker models. While those identities are not need for		those applications' identities are not need for authorization, each
	authorization, they should still be provided by the I2RS client to		application should have a unique opaque identifier that can be
	the I2RS agent for purposes of tracking attribution of operations.		provided by the I2RS client to the I2RS agent for purposes of
			tracking attribution of operations.
	4. Network Applications and I2RS Client		4. Network Applications and I2RS Client
	An I2RS Client has a standardized interface that uses the I2RS		An I2RS Client has a standardized interface that uses the I2RS
	protocol(s) to communicate with I2RS Agents. The interface between		protocol(s) to communicate with I2RS Agents. The interface between
	an I2RS client and the network applications is outside the scope of		an I2RS client and the network applications is outside the scope of
	I2RS.		I2RS.
	When an I2RS Client interacts with multiple network applications,		When an I2RS Client interacts with multiple network applications,
	that I2RS Client is behaving as a broker and may indicate this to the		that I2RS Client is behaving as a go-between and may indicate this to
	I2RS Agents by, for example, specifying a secondary identity to allow		the I2RS Agents by, for example, specifying a secondary opaque
	improved troubleshooting.		identity to allow improved troubleshooting.
	A network application that uses an I2RS client may also be considered		A network application that uses an I2RS client may also be considered
	a routing element and include an I2RS agent for interactions.		a routing element and include an I2RS agent for interactions.
	However, where the needed information and data models for that upper		However, where the needed information and data models for that upper
	interface differs from that of a conventional routing element, those		interface differs from that of a conventional routing element, those
	models are, at least initially, out of scope for I2RS.		models are, at least initially, out of scope for I2RS.
	4.1. Example Network Application: Topology Manager		4.1. Example Network Application: Topology Manager
	One example of such an application is a Topology Manager. Such an		One example of such an application is a Topology Manager. Such an
	skipping to change at page 12, line 10		skipping to change at page 12, line 10
	affect the general I2RS agent behavior.		affect the general I2RS agent behavior.
	For scalability and generality, the I2RS agent may be responsible for		For scalability and generality, the I2RS agent may be responsible for
	collecting and delivering large amounts of data from various parts of		collecting and delivering large amounts of data from various parts of
	the routing element. Those parts may or may not actually be part of		the routing element. Those parts may or may not actually be part of
	a single physical device. Thus, for scalability and robustness, it		a single physical device. Thus, for scalability and robustness, it
	is important that the architecture allow for a distributed set of		is important that the architecture allow for a distributed set of
	reporting components providing collected data from the I2RS agent		reporting components providing collected data from the I2RS agent
	back to the relevant I2RS clients. As currently envisioned, a given		back to the relevant I2RS clients. As currently envisioned, a given
	I2RS agent would have only one locus per I2RS service for		I2RS agent would have only one locus per I2RS service for
	manipulation of routing element state; distributing the manipulations		manipulation of routing element state.
	would inducing complications and fragility instead of scalability and
	robustness.
	5.2. State Storage		5.2. State Storage
	State modification requests are sent to the I2RS agent in a network		State modification requests are sent to the I2RS agent in a network
	element by I2RS clients. The I2RS agent is responsible for applying		element by I2RS clients. The I2RS agent is responsible for applying
	these changes to the system. One dimension of the storage for I2RS		these changes to the system. How much data must the I2RS Agent store
	Clients requests is how much data must the I2RS Agent store about		about these state-modifying operations, and with what persistence?
	this configuration, and with what persistence. There are range of		There are range of possible answers. One extreme is where it stores
	possible answers. One extreme is where it stores nothing, cannot		nothing, cannot indicate why or by whom state was placed into the
	indicate why or by whom state was placed into the routing element,		routing element, and relies on clients reapplying things in all
	and relies on clients reapplying things in all possible cases. The		possible cases. The other extreme is where multiple clients'
	other extreme is where multiple possibilities are stored and managed,		overlapping operations are stored and managed, as is done in the RIB
	as is done in the RIB for routes with a preference or priority to		for routes with a preference or priority to pick between the routes.
	pick between the routes. This architecture tries to provide
			In answering this question, this architecture tries to provide
	sufficient power to keep client operations effective, while still		sufficient power to keep client operations effective, while still
	being simple to implement in the I2RS Agent, and to observe		being simple to implement in the I2RS Agent, and to observe
	meaningfully during operation.		meaningfully during operation. The I2RS agent stores the set of
			operations it has applied. Simply, the I2RS agent stores who did
	The I2RS agent stores the set of operations it has applied. Simply,		what operation to which entity. New changes replace any data about
	the I2RS agent stores who did what operation to which entity. New		old ones. If an I2RS client does an operation to remove some state,
	changes replace any data about old ones. If an I2RS client does an		that state is removed and the I2RS agent stores no more information
	operation to remove some state, that state is removed and the I2RS		about it. This allows any interested party to determine what the
	agent stores no more information about it. This allows any		current effect of I2RS on the system is, and why. Meaningful logging
	interested party to determine what the current effect of I2RS on the		is also recommended.
	system is, and why. Meaningful logging is also recommended.
	The I2RS Agent will not attempt to retain or reapply state across		The I2RS Agent will not attempt to retain or reapply state across
	routing element reboot. Determination of whether state still applies		routing element reboot. Determination of whether state still applies
	depends heavily on the causes of reboots, and reapplication is at		depends heavily on the causes of reboots, and reapplication is at
	least as likely to cause problems as it is to provide for correct		least as likely to cause problems as it is to provide for correct
	operation. [[Editor's note: This topics needs more discussion in the		operation. [[Editor's note: This topics needs more discussion in the
	working group.]]		working group.]]
	5.2.1. Starting and Ending		5.2.1. Starting and Ending
	skipping to change at page 13, line 14		skipping to change at page 13, line 12
	only to be used under certain conditions. The I2RS interface		only to be used under certain conditions. The I2RS interface
	protocol could be designed to allow an I2RS Client to provide a wide		protocol could be designed to allow an I2RS Client to provide a wide
	range of such conditional information to the I2RS Agent for		range of such conditional information to the I2RS Agent for
	application. At the other extreme, the I2RS client could provide all		application. At the other extreme, the I2RS client could provide all
	such functionality based on its own clocking and network event		such functionality based on its own clocking and network event
	reporting from the relevant I2RS Agents.		reporting from the relevant I2RS Agents.
	Given that the complexity of possible conditions is very large, and		Given that the complexity of possible conditions is very large, and
	that some conditions may even cross network element boundaries,		that some conditions may even cross network element boundaries,
	clearly some degree of handling must be provided on the I2RS client.		clearly some degree of handling must be provided on the I2RS client.
	As such, this architecture takes the view that all the complexity		As such, in this architecture it is assumed that all the complexity
	associated with this should be left to the I2RS client. This		associated with this should be left to the I2RS client. This
	architectural view does mean that reliability of the communication		architectural view does mean that reliability of the communication
	path between the I2RS client and I2RS agent is critical. [[Editor's		path between the I2RS client and I2RS agent is critical. [[Editor's
	note: This requires more discussion in the working group.]]		note: This requires more discussion in the working group.]]
	5.2.2. Reversion		5.2.2. Reversion
	An I2RS Agent may decide that some state should no longer be applied.		An I2RS Agent may decide that some state should no longer be applied.
	An I2RS Client may instruct an Agent to remove state it has applied.		An I2RS Client may instruct an Agent to remove state it has applied.
	In all such cases, the state will revert to what it would have been		In all such cases, the state will revert to what it would have been
	skipping to change at page 13, line 45		skipping to change at page 13, line 43
	separate from the I2RS data store. Thus, changes may originate from		separate from the I2RS data store. Thus, changes may originate from
	either source. Policy (i.e. comparisons between a CLI/SNMP/NetConf		either source. Policy (i.e. comparisons between a CLI/SNMP/NetConf
	priority and a I2RS agent priority) can determine whether the local		priority and a I2RS agent priority) can determine whether the local
	configuration should overwrite any state written by I2RS and		configuration should overwrite any state written by I2RS and
	attributed to a particular I2RS Client or whether I2RS as attributed		attributed to a particular I2RS Client or whether I2RS as attributed
	to a particular I2RS Client can overwrite local configuration state.		to a particular I2RS Client can overwrite local configuration state.
	Simply allowing the most recent state to prevail could cause race		Simply allowing the most recent state to prevail could cause race
	conditions where the final state is not repeatably deterministic.		conditions where the final state is not repeatably deterministic.
	One important aspect is that if CLI/SNMP/NetConf changes data that is		One important aspect is that if CLI/SNMP/NetConf changes data that is
	subject to monitoring or manipulating by I2RS, then the system has to		subject to monitoring or manipulating by I2RS, then the system must
	be instrumented enough to provide suitable I2RS notifications of		be instrumented enough to provide suitable I2RS notifications of
	these changes.		these changes.
	5.4. Routing Components and Associated I2RS Services		5.4. Routing Components and Associated I2RS Services
	For simplicity, each logical protocol or set of functionality that be		For simplicity, each logical protocol or set of functionality that be
	compactly described in a separable information and data model is		compactly described in a separable information and data model is
	considered as a separate I2RS Service. A routing element need not		considered as a separate I2RS Service. A routing element need not
	implement all routing components described nor provide the associated		implement all routing components described nor provide the associated
	I2RS services. The initial services included in the I2RS		I2RS services. The initial services included in the I2RS
	architecture are as follows.		architecture are as follows.
	5.4.1. Unicast and Multicast RIB and LFIB		5.4.1. Unicast and Multicast RIB and LFIB
	Network elements concerned with routing IP maintain IP unicast RIBs.		Network elements concerned with routing IP maintain IP unicast RIBs.
	skipping to change at page 14, line 16		skipping to change at page 14, line 19
	considered as a separate I2RS Service. A routing element need not		considered as a separate I2RS Service. A routing element need not
	implement all routing components described nor provide the associated		implement all routing components described nor provide the associated
	I2RS services. The initial services included in the I2RS		I2RS services. The initial services included in the I2RS
	architecture are as follows.		architecture are as follows.
	5.4.1. Unicast and Multicast RIB and LFIB		5.4.1. Unicast and Multicast RIB and LFIB
	Network elements concerned with routing IP maintain IP unicast RIBs.		Network elements concerned with routing IP maintain IP unicast RIBs.
	Similarly, there are RIBs for IP Multicast, and a Label Information		Similarly, there are RIBs for IP Multicast, and a Label Information
	Base (LIB) for MPLS. The I2RS Agent needs to be able to read and		Base (LIB) for MPLS. The I2RS Agent needs to be able to read and
	write these sets of data. The I2RS data model has to include models		write these sets of data. The I2RS data model must include models
	for this information.		for this information.
	In particular, with regard to writing this information, the I2RS		In particular, with regard to writing this information, the I2RS
	Agent should use the same mechanisms that the routing element already		Agent should use the same mechanisms that the routing element already
	uses to handle RIB input from multiple sources, so as to compatibly		uses to handle RIB input from multiple sources, so as to compatibly
	change the system state.		change the system state.
	The multicast state added to the multicast RIB does not need to match		The multicast state added to the multicast RIB does not need to match
	to well-known protocol installed state. The I2RS Agent can create		to well-known protocol installed state. The I2RS Agent can create
	arbitrary replication state in the RIB, subject to the advertised		arbitrary replication state in the RIB, subject to the advertised
	capabilities of the routing element.		capabilities of the routing element.
	5.4.2. IGPs, BGP and Multicast Protocols		5.4.2. IGPs, BGP and Multicast Protocols
	In addition to interacting with the consolidated RIB, the I2RS agent		In addition to interacting with the consolidated RIB, the I2RS agent
	needs to interact with the individual routing protocols on the		may need to interact with the individual routing protocols on the
	device. This interaction includes a number of different kinds of		device. This interaction includes a number of different kinds of
	operations:		operations:
	o reading the various internal rib(s) of the routing protocol is		o reading the various internal rib(s) of the routing protocol is
	often helpful for understanding the state of the network.		often helpful for understanding the state of the network.
	Directly writing these protocol-specific RIBs or databases is NOT		Directly writing these protocol-specific RIBs or databases is out
	part of the system.		of scope for I2RS.
	o reading the various pieces of policy information the particular		o reading the various pieces of policy information the particular
	protocol instance is using to drive its operations.		protocol instance is using to drive its operations.
	o writing policy information such as interface attributes that are		o writing policy information such as interface attributes that are
	specific to the routing protocol or BGP policy that may indirectly		specific to the routing protocol or BGP policy that may indirectly
	manipulate attributes of routes carried in BGP.		manipulate attributes of routes carried in BGP.
	o writing routes or prefixes to be advertised via the protocol.		o writing routes or prefixes to be advertised via the protocol.
	skipping to change at page 15, line 4		skipping to change at page 15, line 6
	o reading the various pieces of policy information the particular		o reading the various pieces of policy information the particular
	protocol instance is using to drive its operations.		protocol instance is using to drive its operations.
	o writing policy information such as interface attributes that are		o writing policy information such as interface attributes that are
	specific to the routing protocol or BGP policy that may indirectly		specific to the routing protocol or BGP policy that may indirectly
	manipulate attributes of routes carried in BGP.		manipulate attributes of routes carried in BGP.
	o writing routes or prefixes to be advertised via the protocol.		o writing routes or prefixes to be advertised via the protocol.
	o joining/removing interfaces from the multicast trees		o joining/removing interfaces from the multicast trees
	For example, the interaction with OSPF might include modifying the		For example, the interaction with OSPF might include modifying the
	local routing element's link metrics, announcing a locally-attached		local routing element's link metrics, announcing a locally-attached
	prefix, or reading some of the OSPF link-state database. However,		prefix, or reading some of the OSPF link-state database. However,
	modifying the link-state database itself would clearly not be		direct modification of of the link-state database is NOT allowed to
	permitted; that could lead to inconsistency.		preserve network state consistency.
	5.4.3. MPLS		5.4.3. MPLS
	The I2RS Agent will need to interact with the knobs that policy		The I2RS Agent will need to interact with the knobs that policy
	attributes that control LDP operation as well as RSVP-TE based LSPs.		attributes that control LDP operation as well as RSVP-TE based LSPs.
	To avoid duplication, the I2RS interface will not duplicate the path
	computation and active path setup components of the PCE protocols.
	5.4.4. Policy and QoS Mechanisms		5.4.4. Policy and QoS Mechanisms
	Many network elements have separate policy and QoS mechanisms,		Many network elements have separate policy and QoS mechanisms,
	including knobs which affect local path computation and queue control		including knobs which affect local path computation and queue control
	capabilities. These capabilities vary widely across implementations,		capabilities. These capabilities vary widely across implementations,
	and I2RS cannot model the full range of information collection or		and I2RS cannot model the full range of information collection or
	manipulation of these attributes. A core set does need to be		manipulation of these attributes. A core set does need to be
	included in the I2RS data models and in the expected interfaces		included in the I2RS data models and in the expected interfaces
	between the I2RS Agent and the network element, in order to provide		between the I2RS Agent and the network element, in order to provide
	basic capabilities and the hooks for extensibility.		basic capabilities and the hooks for future extensibility.
	6. I2RS Client Agent Interface		6. I2RS Client Agent Interface
	6.1. Protocol Structure		6.1. Protocol Structure
	One could view I2RS merely as a way to talk about the existing		One could view I2RS merely as a way to talk about the existing
	network management interfaces to a network element. That would be		network management interfaces to a network element. That would be
	quite limiting, and would have trouble meeting the requirements		quite limiting and would not meet the requirements elucidated
	elucidated elsewhere. One could also view it as a collection of		elsewhere. One could also view I2RS as a collection of protocols -
	protocols, some existing and some new, that meet the needs. While		some existing and some new - that meet the needs. While that could
	that could be made to work, the complexity of such a mechanism would		be made to work, the complexity of such a mechanism would be quite
	be quite high. One would need to develop means to coordinate		high. One would need to develop means to coordinate information
	information across a set of protocols that were not designed to work		across a set of protocols that were not designed to work together.
	together. As a result, this architecture views the I2RS interface as		From a deployability perspective, this would not meet the goal of
	an interface supporting a single control and data exchange protocol.		simplicity. As a result, this architecture views the I2RS interface
	That protocol may use several underlying transports (TCP, SCTP,		as an interface supporting a single control and data exchange
	DCCP), with suitable authentication and integrity protection		protocol. That protocol may use several underlying transports (TCP,
			SCTP, DCCP), with suitable authentication and integrity protection
	mechanisms. Whatever transport is used for the data exchange, it		mechanisms. Whatever transport is used for the data exchange, it
	must also support suitable congestion control mechanisms.		must also support suitable congestion control mechanisms.
	6.2. Channel		6.2. Channel
	The uses of a single I2RS protocol does not imply that only one		The uses of a single I2RS protocol does not imply that only one
	channel of communication is needed. There may be a range of		channel of communication is required. There may be a range of
	reliability needs, and to support the scaling there may need to be		reliability requirements, and to support the scaling there may need
	channels from multiple parts of a routing element. These will all		to be channels originating from multiple sub-components of a routing
	use the date exchange protocol, and establishment of additional		element. These will all use the date exchange protocol, and
	channels for communication will be coordinated between the I2RS		establishment of additional channels for communication will be
	client and the I2RS agent.		coordinated between the I2RS client and the I2RS agent.
	6.3. Negotiation		6.3. Negotiation
	Protocol support capabilities will vary across I2RS Clients and		Protocol support capabilities will vary across I2RS Clients and
	Routing Elements supporting I2RS Agents. As such, it is likely that		Routing Elements supporting I2RS Agents. As such, capability
	capability negotiation (such as which transports are supported beyond		negotiation (such as which transports are supported beyond the
	the minimum required to implement) will be necessary. It is		minimum required to implement) will clearly be necessary. It is
	important that such negotiations be kept simple and robust, as such		important that such negotiations be kept simple and robust, as such
	mechanisms are often a source of difficulty in implementation and		mechanisms are often a source of difficulty in implementation and
	deployment.		deployment.
			Negotiation should be broken into several aspects, such as protocol
			capablities and I2RS services and model types supported.
	6.4. Identity and Security Role		6.4. Identity and Security Role
	Each I2RS Client will have an identity; it can also have secondary		Each I2RS Client will have an identity; it can also have secondary
	identities to be used for troubleshooting. Via authentication and		identities to be used for troubleshooting. A secondary identity is
	authorization mechanisms, the I2RS agent will have a specific scope		merely a unique, opaque identifier that may be helpful in
	for reading data, for writing data, and limitations on the resources		troubleshooting. Via authentication and authorization mechanisms,
	that can be consumed. The scopes need to specify both the data and		the I2RS agent will have a specific scope for reading data, for
	the value ranges.		writing data, and limitations on the resources that can be consumed.
			The scopes need to specify both the data and the value ranges.
	6.5. Connectivity		6.5. Connectivity
	A client does not need to maintain an active communication channel		A client does not need to maintain an active communication channel
	with an agent. Therefore, an agent may need to open a communication		with an agent. Therefore, an agent may need to open a communication
	channel to the client to communicate previously requested		channel to the client to communicate previously requested
	information. The lack of an active communication channel does not		information. The lack of an active communication channel does not
	imply that the associated client is non-functional. When		imply that the associated client is non-functional. When
	communication is required, the agent or client can open a new		communication is required, the agent or client can open a new
	communication channel.		communication channel.
	State held by an agent that is owned by a client should not be		State held by an agent that is owned by a client should not be
	removed or cleaned up when a client is no longer communicating - even		removed or cleaned up when a client is no longer communicating - even
	if the agent cannot successfully open a new communication channel to		if the agent cannot successfully open a new communication channel to
	the client.		the client.
	There are two different assumptions that can apply to handling dead		There are three different assumptions that can apply to handling dead
	clients. The first is that the network application layer will detect		clients. The first is that the network applications or management
	a dead network application and either restart that network		systems will detect a dead network application and either restart
	application or clean up any state left behind. The second is to		that network application or clean up any state left behind. The
	allow state expiration, expressed as a policy associated with the		second is to allow state expiration, expressed as a policy associated
	I2RS client's role. The state expiration could occur after there has		with the I2RS client's role. The state expiration could occur after
	been no successful communication channel to or from the I2RS client		there has been no successful communication channel to or from the
	for the policy-specified duration.		I2RS client for the policy-specified duration. The third is that the
			client could explicitly request state clean-up if a particular
			transport session is terminated.
	6.6. Notifications		6.6. Notifications
	As with any policy system interacting with the network, the I2RS		As with any policy system interacting with the network, the I2RS
	Agent needs to be able to receive notifications of changes in network		Agent needs to be able to receive notifications of changes in network
	state. Notifications here refers to changes which are unanticipated,		state. Notifications here refers to changes which are unanticipated,
	represent events outside the control of the systems (such as		represent events outside the control of the systems (such as
	interface failures on controlled devices), or are sufficiently sparse		interface failures on controlled devices), or are sufficiently sparse
	as to be anomalous in some fashion.		as to be anomalous in some fashion.
	skipping to change at page 18, line 48		skipping to change at page 18, line 45
	Perform all or none: This traditional SNMP semantic indicates that		Perform all or none: This traditional SNMP semantic indicates that
	other I2RS agent will keep enough state when handling a single		other I2RS agent will keep enough state when handling a single
	message to roll back the operations within that message. Either		message to roll back the operations within that message. Either
	all the operations will succeed, or none of them will be applied		all the operations will succeed, or none of them will be applied
	and an error message will report the single failure which caused		and an error message will report the single failure which caused
	the not to be applied. This is useful when there are, for		the not to be applied. This is useful when there are, for
	example, mutual dependencies across operations in the message.		example, mutual dependencies across operations in the message.
	Perform until error: In this case, the operations in the message		Perform until error: In this case, the operations in the message
	are applied in order. When an error occurs, no further operations		are applied in the specified order. When an error occurs, no
	are applied, and an error is returned indicating the failure.		further operations are applied, and an error is returned
	This is useful if there are dependencies among the operations and		indicating the failure. This is useful if there are dependencies
	they can be topologically sorted.		among the operations and they can be topologically sorted.
	Perform all: In this case, the I2RS Agent will attempt to perform		Perform all: In this case, the I2RS Agent will attempt to perform
	all the operations in the message, and will return error		all the operations in the message, and will return error
	indications for each one that fails. This is useful when there is		indications for each one that fails. This is useful when there is
	no dependency across the operation, or where the client would		no dependency across the operation, or where the client would
	prefer to sort out the effect of errors on its own.		prefer to sort out the effect of errors on its own.
	In the interest of robustness and clarity of protocol state, the		In the interest of robustness and clarity of protocol state, the
	protocol will include an explicit reply to modification operations		protocol will include an explicit reply to modification operations
	even when they fully succeed.		even when they fully succeed.
	skipping to change at page 19, line 48		skipping to change at page 19, line 45
	data models and the value ranges are discussed briefly in		data models and the value ranges are discussed briefly in
	Section 6.4.		Section 6.4.
	9. IANA Considerations		9. IANA Considerations
	This document includes no request to IANA.		This document includes no request to IANA.
	10. Acknowledgements		10. Acknowledgements
	Significant portions of this draft came from draft-ward-i2rs-		Significant portions of this draft came from draft-ward-i2rs-
	framework-00 and draft-atlas-i2rs-policy-framework-00. The authors		framework-00 and draft-atlas-i2rs-policy-framework-00.
	would like to acknowledge Tom Nadeau, who was a co-author on draft-
	ward-i2rs-framework-00.
	The authors would like to thank Nitin Bahadur, Shane Amante, and Ken		The authors would like to thank Nitin Bahadur, Shane Amante, Ed
	Gray for their suggestions and review.		Crabbe, and Ken Gray for their suggestions and review.
	11. Informative References		11. Informative References
	[I-D.atlas-i2rs-problem-statement]		[I-D.atlas-i2rs-problem-statement]
	Atlas, A., Nadeau, T., and D. Ward, "Interface to the		Atlas, A., Nadeau, T., and D. Ward, "Interface to the
	Routing System Problem Statement", draft-atlas-i2rs-		Routing System Problem Statement", draft-atlas-i2rs-
	problem-statement-00 (work in progress), February 2013.		problem-statement-01 (work in progress), July 2013.
	Authors' Addresses		Authors' Addresses
	Alia Atlas		Alia Atlas
	Juniper Networks		Juniper Networks
	10 Technology Park Drive		10 Technology Park Drive
	Westford, MA 01886		Westford, MA 01886
	USA		USA
	Email: akatlas@juniper.net		Email: akatlas@juniper.net
	skipping to change at line 911		skipping to change at page 20, line 37
	Email: shares@ndzh.com		Email: shares@ndzh.com
	Dave Ward		Dave Ward
	Cisco Systems		Cisco Systems
	Tasman Drive		Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: wardd@cisco.com		Email: wardd@cisco.com
			Thomas D. Nadeau
			Juniper Networks
			Email: tnadeau@juniper.net
End of changes. 57 change blocks.
	138 lines changed or deleted		147 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/