draft-ietf-i2rs-problem-statement-04.txt		draft-ietf-i2rs-problem-statement-05.txt
	Network Working Group A. Atlas, Ed.		Network Working Group A. Atlas, Ed.
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Informational T. Nadeau, Ed.		Intended status: Informational T. Nadeau, Ed.
	Expires: December 25, 2014 Brocade		Expires: July 10, 2015 Brocade
	D. Ward		D. Ward
	Cisco Systems		Cisco Systems
	June 23, 2014		January 6, 2015
	Interface to the Routing System Problem Statement		Interface to the Routing System Problem Statement
	draft-ietf-i2rs-problem-statement-04		draft-ietf-i2rs-problem-statement-05
	Abstract		Abstract
	As modern networks grow in scale and complexity, the need for rapid		As modern networks grow in scale and complexity, the need for rapid
	and dynamic control increases. With scale, the need to automate even		and dynamic control increases. With scale, the need to automate even
	the simplest operations is important, but even more critical is the		the simplest operations is important, but even more critical is the
	ability to quickly interact with more complex operations such as		ability to quickly interact with more complex operations such as
	policy-based controls.		policy-based controls.
	In order to enable network applications to have access to and control		In order to enable network applications to have access to and control
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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 25, 2014.		This Internet-Draft will expire on July 10, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. I2RS Model and Problem Area for The IETF . . . . . . . . . . 3		2. I2RS Model and Problem Area for The IETF . . . . . . . . . . 3
	3. Standard Data-Models of Routing State for Installation . . . 5		3. Standard Data-Models of Routing State for Installation . . . 5
	4. Learning Router Information . . . . . . . . . . . . . . . . . 6		4. Learning Router Information . . . . . . . . . . . . . . . . . 6
	5. Desired Aspects of a Protocol for I2RS . . . . . . . . . . . 6		5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 6
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	9. Informative References . . . . . . . . . . . . . . . . . . . 8		9. Informative References . . . . . . . . . . . . . . . . . . . 8
	Appendix A. Existing Management Interfaces . . . . . . . . . . . 9		Appendix A. Existing Management Interfaces . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	As modern networks grow in scale and complexity, the need for rapid,		As modern networks grow in scale and complexity, the need for rapid,
	skipping to change at page 5, line 6		skipping to change at page 5, line 6
	.... boundary of a router supporting I2RS		.... boundary of a router supporting I2RS
	Figure 1: I2RS model and Problem Area		Figure 1: I2RS model and Problem Area
	A critical aspect of I2RS is defining a suitable protocol or		A critical aspect of I2RS is defining a suitable protocol or
	protocols to carry messages between the I2RS Clients and the I2RS		protocols to carry messages between the I2RS Clients and the I2RS
	Agent, and defining the data-models for use with those I2RS		Agent, and defining the data-models for use with those I2RS
	protocol(s). The protocol should provide the key features specified		protocol(s). The protocol should provide the key features specified
	in Section 5. The data models should translate into a concise		in Section 5. The data models should translate into a concise
	transfer syntax that is straightforward for applications to use		transfer syntax, sent via the I2RS protocol, that is straightforward
	(e.g., a Web Services design paradigm). The information transfer		for applications to use (e.g., a Web Services design paradigm). The
	should use existing transport protocols to provide the reliability,		information transfer should use existing transport protocols to
	security, and timeliness appropriate for the particular data.		provide the reliability, security, and timeliness appropriate for the
			particular data.
	The second critical aspect are meaningful data-models for information		The second critical aspect of I2RS is a set of meaningful data-models
	in the routing system and in a topology database. The data-model		for information in the routing system and in a topology database.
	should describe the meaning and relationships of the modeled items.		The data-model should describe the meaning and relationships of the
	The data-models should be separable across different features of the		modeled items. The data-models should be separable across different
	managed components, versioned, and extendable. As shown in Figure 1,		features of the managed components, versioned, and extendable. As
	I2RS needs to interact with several logical components of the routing		shown in Figure 1, I2RS needs to interact with several logical
	element: policy database, topology database, subscription and		components of the routing element: policy database, topology
	configuration for dynamic measuresments/events, routing signaling		database, subscription and configuration for dynamic measurements/
	protocols, and its RIB manager. This interaction is both for writing		events, routing signaling protocols, and its RIB manager. This
	(e.g. to policy databases or RIB manager) as well as for reading		interaction is both for writing (e.g. to policy databases or RIB
	(e.g. dynamic measurement or topology database). An application		manager) as well as for reading (e.g. dynamic measurement or topology
	should be able to combine data from individual routing elements to		database). An application should be able to combine data from
	provide network-wide data-model(s).		individual routing elements to provide network-wide data-model(s).
	3. Standard Data-Models of Routing State for Installation		3. Standard Data-Models of Routing State for Installation
	There is a need to be able to precisely control routing and signaling		There is a need to be able to precisely control routing and signaling
	state based upon policy or external measures. This can range from		state based upon policy or external measures. This can range from
	simple static routes to policy-based routing to static multicast		simple static routes to policy-based routing to static multicast
	replication and routing state. This means that, to usefully model		replication and routing state. This means that, to usefully model
	next-hops, the data model employed needs to handle next-hop		next-hops, the data model employed needs to handle next-hop
	indirection and recursion (e.g. a prefix X is routed like prefix Y)		indirection and recursion (e.g. a prefix X is routed like prefix Y)
	as well as different types of tunneling and encapsulation. The		as well as different types of tunneling and encapsulation. The
	skipping to change at page 5, line 51		skipping to change at page 6, line 4
	Efforts to provide this level of control have focused on		Efforts to provide this level of control have focused on
	standardizing data models that describe the forwarding plane (e.g.		standardizing data models that describe the forwarding plane (e.g.
	ForCES [RFC3746]). I2RS posits that the routing system and a		ForCES [RFC3746]). I2RS posits that the routing system and a
	router's OS provide useful mechanisms that applications could		router's OS provide useful mechanisms that applications could
	usefully harness to accomplish application-level goals.		usefully harness to accomplish application-level goals.
	In addition to interfaces to the RIB layer, there is a need to		In addition to interfaces to the RIB layer, there is a need to
	configure the various routing and signaling protocols with differing		configure the various routing and signaling protocols with differing
	dynamic state based upon application-level policy decisions. The		dynamic state based upon application-level policy decisions. The
	range desired is not available via MIB modules at the present time.		range desired is not available via MIB modules at the present time.
	Additionally, on March 2, 2014, the IESG issued a statement about		Additionally, on March 2, 2014, the IESG issued a statement about
	Writeable MIB Modules which is expected to limit creation of future		Writeable MIB Modules [IESG-Statement] which is expected to limit
	writeable MIB modules.		creation of future writeable MIB modules.
	4. Learning Router Information		4. Learning Router Information
	A router has information that applications may require so that they		A router has information that applications may require so that they
	can understand the network, verify that programmed state is installed		can understand the network, verify that programmed state is installed
	in the forwarding plane, measure the behavior of various flows, and		in the forwarding plane, measure the behavior of various flows, and
	understand the existing configuration and state of the router. I2RS		understand the existing configuration and state of the router. I2RS
	provides a framework so that applications can register for		provides a framework so that applications can register for
	asynchronous notifications and can make specific requests for		asynchronous notifications and can make specific requests for
	information.		information.
	Although there are efforts to extend the topological information		Although there are efforts to extend the topological information
	available, even the best of these (e.g., BGP-LS		available, even the best of these (e.g., BGP-LS
	[I-D.gredler-idr-ls-distribution]) still provide only the current		[I-D.ietf-idr-ls-distribution]) still provide only the current active
	active state as seen at the IGP layer and above. Detailed		state as seen at the IGP layer and above. Detailed topological state
	topological state that provides more information than the current		that provides more information than the current functional status
	functional status is needed by applications; only the active paths or		(e.g. active paths and links) is needed by applications. Examples of
	links are known versus those potentially available (e.g.		missing information include paths or link that are potentially
	administratively down) or unknown (e.g. to peers or customers) to the		available (e.g. administratively down) or unknown (e.g. to peers or
	routing topology.		customers) to the routing topology.
	For applications to have a feedback loop that includes awareness of		For applications to have a feedback loop that includes awareness of
	the relevant traffic, an application must be able to request the		the relevant traffic, an application must be able to request the
	measurement and timely, scalable reporting of data. While a		measurement and timely, scalable reporting of data. While a
	mechanism such as IPFIX [RFC5470] may be the facilitator for		mechanism such as IPFIX [RFC5470] may be the facilitator for
	delivering the data, the need for an application to be able to		delivering the data, the need for an application to be able to
	dynamically request that measurements be taken and data delivered is		dynamically request that measurements be taken and data delivered is
	critical.		critical.
	There are a wide range of events that applications could use for		There are a wide range of events that applications could use for
	either verification of router state before other network state is		either verification of router state before other network state is
	changed (e.g. that a route has been installed), to act upon changes		changed (e.g. that a route has been installed), to act upon changes
	to relevant routes by others, or upon router events (e.g. link up/		to relevant routes by others, or upon router events (e.g. link up/
	down). While a few of these (e.g. link up/down) may be available via		down). While a few of these (e.g. link up/down) may be available via
	MIB notifications today, the full range is not - nor has there been		MIB notifications today, the full range is not - nor has there been
	successfully deployed the standardized ability to set up the router		successfully deployed the standardized ability to set up the router
	to trigger different actions upon an event's occurrence so that a		to trigger different actions upon an event's occurrence so that a
	rapid reaction can be accomplished.		rapid reaction can be accomplished.
	5. Desired Aspects of a Protocol for I2RS		5. Aspects to be Considered for an I2RS Protocol
	This section describes required aspects of a protocol that could		This section describes required aspects of a protocol that could
	support I2RS. Whether such a protocol is built upon extending		support I2RS. Whether such a protocol is built upon extending
	existing mechanisms or requires a new mechanism requires further		existing mechanisms or requires a new mechanism requires further
	investigation.		investigation.
	The key aspects needed in an interface to the routing system are:		The key aspects needed in an interface to the routing system are:
	Multiple Simultaneous Asynchronous Operations: A single application		Multiple Simultaneous Asynchronous Operations: A single application
	should be able to send multiple independent atomic operations via		should be able to send multiple independent atomic operations via
	skipping to change at page 7, line 23		skipping to change at page 7, line 23
	operation is processed, it is required that the data locked for		operation is processed, it is required that the data locked for
	writing is very granular (e.g. a particular prefix and route)		writing is very granular (e.g. a particular prefix and route)
	rather than extremely coarse, as is done for writing		rather than extremely coarse, as is done for writing
	configuration. This should improve the number of concurrent I2RS		configuration. This should improve the number of concurrent I2RS
	operations that are feasible and reduce blocking delays.		operations that are feasible and reduce blocking delays.
	Multi-Headed Control: Multiple applications may communicate to the		Multi-Headed Control: Multiple applications may communicate to the
	same I2RS agent in a minimally coordinated fashion. It is		same I2RS agent in a minimally coordinated fashion. It is
	necessary that the I2RS agent can handle multiple requests in a		necessary that the I2RS agent can handle multiple requests in a
	well-known policy-based fashion. Data written can be owned by		well-known policy-based fashion. Data written can be owned by
	different I2RS clients.		different I2RS clients at different times; data may even be
			overwritten by a different I2RS client. The details of how this
			should be handled are described in [I-D.ietf-i2rs-architecture].
	Duplex: Communications can be established by either the I2RS client		Duplex: Communications can be established by either the I2RS client
	(i.e.: that resides within the application or is used by it to		(i.e.: that resides within the application or is used by it to
	communicate with the I2RS agent), or the I2RS agent. Similarly,		communicate with the I2RS agent), or the I2RS agent. Similarly,
	events, acknowledgements, failures, operations, etc. can be sent		events, acknowledgements, failures, operations, etc. can be sent
	at any time by both the router and the application. The I2RS is		at any time by both the router and the application. The I2RS is
	not a pure pull-model where only the application queries to pull		not a pure pull-model where only the application queries to pull
	responses.		responses.
	High-Throughput: At a minimum, the I2RS Agent and associated router		High-Throughput: At a minimum, the I2RS Agent and associated router
	skipping to change at page 8, line 7		skipping to change at page 8, line 10
	example, for scaling, some exported data or events may be better		example, for scaling, some exported data or events may be better
	sent directly from the forwarding plane, while other interactions		sent directly from the forwarding plane, while other interactions
	may come from the control-plane. Thus a single TCP session would		may come from the control-plane. Thus a single TCP session would
	not be a good match.		not be a good match.
	Scalable, Filterable Information Access: To extract information in a		Scalable, Filterable Information Access: To extract information in a
	scalable fashion that is more easily used by applications, the		scalable fashion that is more easily used by applications, the
	ability to specify filtering constructs in an operation requesting		ability to specify filtering constructs in an operation requesting
	data or requesting an asynchronous notification is very valuable.		data or requesting an asynchronous notification is very valuable.
	Secure Control: Any ability to manipulate routing state must be		Secure Control and Access: Any ability to manipulate routing state
	subject to authentication and authorization. Such communications		must be subject to authentication and authorization. Sensitive
	must also have its integrity protected.		routing information may also need to be provided via secure access
			back to the I2RS client. Such communications must be integrity
			protected. Some communications will also require confidentiality.
	Extensible and Interoperability: Both the I2RS protocol and models		Extensible and Interoperability: Both the I2RS protocol and models
	must be extensible and interoperate between different versions of		must be extensible and interoperate between different versions of
	protocols and models.		protocols and models.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann,		The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann,
	Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, and Sue Hares for		Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ
	their suggestions and review.		Housley, Eric Grey, Qin Wu, and Stephen Kent for their suggestions
			and review.
	7. IANA Considerations		7. IANA Considerations
	This document includes no request to IANA.		This document includes no request to IANA.
	8. Security Considerations		8. Security Considerations
	Security is a key aspect of any protocol that allows state		Security is a key aspect of any protocol that allows state
	installation and extracting of detailed router state. More		installation and extracting of detailed router state. The need for
	investigation remains to fully define the security requirements, such		secure control and access is mentioned in Section 5 More
	as authorization and authentication levels.		architectural security considerations are discussed in
			[I-D.ietf-i2rs-architecture]. Briefly, the I2RS Agent is assumed to
			have a separate authentication and authorization channel by which it
			can validate both the identity and the permissions associated with an
			I2RS Client. Mutual authentication between the I2RS Agent and I2RS
			Client is required. Different levels of integrity, confidentiality,
			and replay protection are relevant for different aspects of I2RS.
	9. Informative References		9. Informative References
	[I-D.gredler-idr-ls-distribution]		[I-D.ietf-i2rs-architecture]
	Gredler, H., Medved, J., Previdi, S., and A. Farrel,		Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
	"North-Bound Distribution of Link-State and TE Information		Nadeau, "An Architecture for the Interface to the Routing
	using BGP", draft-gredler-idr-ls-distribution-02 (work in		System", draft-ietf-i2rs-architecture-07 (work in
	progress), July 2012.		progress), December 2014.
			[I-D.ietf-idr-ls-distribution]
			Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
			Ray, "North-Bound Distribution of Link-State and TE
			Information using BGP", draft-ietf-idr-ls-distribution-07
			(work in progress), November 2014.
			[IESG-Statement]
			IESG, "Writable MIB Module IESG Statement", March 2014,
			<https://www.ietf.org/iesg/statement/writable-mib-
			module.html>.
	[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,		[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
	"Forwarding and Control Element Separation (ForCES)		"Forwarding and Control Element Separation (ForCES)
	Framework", RFC 3746, April 2004.		Framework", RFC 3746, April 2004.
	[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April		[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April
	2006.		2006.
	[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,		[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
	"Architecture for IP Flow Information Export", RFC 5470,		"Architecture for IP Flow Information Export", RFC 5470,
	skipping to change at page 9, line 25		skipping to change at page 9, line 47
	configuration and learning of device state. This is a proprietary		configuration and learning of device state. This is a proprietary
	interface resembling a UNIX shell that allows for very customized		interface resembling a UNIX shell that allows for very customized
	control and observation of a device, and, specifically of interest in		control and observation of a device, and, specifically of interest in
	this case, its routing system. Some form of this interface exists on		this case, its routing system. Some form of this interface exists on
	almost every device (virtual or otherwise). Processing of		almost every device (virtual or otherwise). Processing of
	information returned to the CLI (called "screen scraping") is a		information returned to the CLI (called "screen scraping") is a
	burdensome activity because the data is normally formatted for use by		burdensome activity because the data is normally formatted for use by
	a human operator, and because the layout of the data can vary from		a human operator, and because the layout of the data can vary from
	device to device, and between different software versions. Despite		device to device, and between different software versions. Despite
	its ubiquity, this interface has never been standardized and is		its ubiquity, this interface has never been standardized and is
	unlikely to ever be standardized. I2RS does not involve CLI		unlikely to ever be standardized. CLI standardization is not
	standardization.		considered as a candidate solution for the problems motivating I2RS.
	The second most popular interface for interrogation of a device's		The second most popular interface for interrogation of a device's
	state, statistics, and configuration is The Simple Network Management		state, statistics, and configuration is The Simple Network Management
	Protocol (SNMP) and a set of relevant standards-based and proprietary		Protocol (SNMP) and a set of relevant standards-based and proprietary
	Management Information Base (MIB) modules. SNMP has a strong history		Management Information Base (MIB) modules. SNMP has a strong history
	of being used by network managers to gather statistical and state		of being used by network managers to gather statistical and state
	information about devices, including their routing systems. However,		information about devices, including their routing systems. However,
	SNMP is very rarely used to configure a device or any of its systems		SNMP is very rarely used to configure a device or any of its systems
	for reasons that vary depending upon the network operator. Some		for reasons that vary depending upon the network operator. Some
	example reasons include complexity, the lack of desired configuration		example reasons include complexity, the lack of desired configuration
End of changes. 18 change blocks.
	49 lines changed or deleted		73 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/