< draft-ietf-i2rs-architecture-04.txt		draft-ietf-i2rs-architecture-05.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 25, 2014 Ericsson		Expires: January 21, 2015 Ericsson
	S. Hares		S. Hares
	Hickory Hill Consulting		Hickory Hill Consulting
	D. Ward		D. Ward
	Cisco Systems		Cisco Systems
	T. Nadeau		T. Nadeau
	Brocade		Brocade
	June 23, 2014		July 20, 2014
	An Architecture for the Interface to the Routing System		An Architecture for the Interface to the Routing System
	draft-ietf-i2rs-architecture-04		draft-ietf-i2rs-architecture-05
	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 routing		interface for state transfer in and out of the internet 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 41 ¶		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 25, 2014.		This Internet-Draft will expire on January 21, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 12, line 32 ¶		skipping to change at page 12, line 32 ¶
	channel by which it can validate both the identity and permissions		channel by which it can validate both the identity and permissions
	associated with an I2RS Client. To support numerous and speedy		associated with an I2RS Client. To support numerous and speedy
	interactions between the I2RS Agent and I2RS Client, it is assumed		interactions between the I2RS Agent and I2RS Client, it is assumed
	that the I2RS Agent can also cache that particular I2RS Clients are		that the I2RS Agent can also cache that particular I2RS Clients are
	trusted and their associated authorized scope. This implies that the		trusted and their associated authorized scope. This implies that the
	permission information may be old either in a pull model until the		permission information may be old either in a pull model until the
	I2RS Agent re-requests it, or in a push model until the		I2RS Agent re-requests it, or in a push model until the
	authentication and authorization channel can notify the I2RS Agent of		authentication and authorization channel can notify the I2RS Agent of
	changes.		changes.
			Mutual authentication between the I2RS Client and I2RS Agent is
			required. An I2RS Client must be able to trust that the I2RS Agent
			is attached to the relevant Routing Element so that write/modify
			operations are correctly applied and so that information received
			from the I2RS Agent can be trusted by the I2RS Client.
	An I2RS Client is not automatically trustworthy. It has identity		An I2RS Client is not automatically trustworthy. It has identity
	information and applications using that I2RS Client should be aware		information and applications using that I2RS Client should be aware
	of the scope limitations of that I2RS Client. If the I2RS Client is		of the scope limitations of that I2RS Client. If the I2RS Client is
	acting as a broker for multiple applications, managing the security,		acting as a broker for multiple applications, managing the security,
	authentication and authorization for that communication is out of		authentication and authorization for that communication is out of
	scope; nothing prevents I2RS and a separate authentication and		scope; nothing prevents I2RS and a separate authentication and
	authorization channel from being used. Regardless of mechanism, an		authorization channel from being used. Regardless of mechanism, an
	I2RS Client that is acting as a broker is responsible for determining		I2RS Client that is acting as a broker is responsible for determining
	that applications using it are trusted and permitted to make the		that applications using it are trusted and permitted to make the
	particular requests.		particular requests.
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	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. There may be multiple I2RS Agents		back to the relevant I2RS clients. There may be multiple I2RS Agents
	within the same router. In such a case, they must have non-		within the same router. In such a case, they must have non-
	overlapping sets of information which they manipulate.		overlapping sets of information which they manipulate.
			To facilitate operations, deployment and troubleshooting, it is
			important that traceability of the I2RS Agent's requests and actions
			be supported via a common data model.
	6.2. I2RS State Storage		6.2. I2RS State Storage
	State modification requests are sent to the I2RS agent in a routing		State modification requests are sent to the I2RS agent in a routing
	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, subject to the authorization discussed		these changes to the system, subject to the authorization discussed
	above. The I2RS agent will retain knowledge of the changes it has		above. The I2RS agent will retain knowledge of the changes it has
	applied, and the client on whose behalf it applied the changes. The		applied, and the client on whose behalf it applied the changes. The
	I2RS agent will also store active subscriptions. These sets of data		I2RS agent will also store active subscriptions. These sets of data
	form the I2RS data store. This data is retained by the agent until		form the I2RS data store. This data is retained by the agent until
	the state is removed by the client, overridden by some other		the state is removed by the client, overridden by some other
	skipping to change at page 30, line 13 ¶		skipping to change at page 30, line 13 ¶
	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.		framework-00 and draft-atlas-i2rs-policy-framework-00.
	The authors would like to thank Nitin Bahadur, Shane Amante, Ed		The authors would like to thank Nitin Bahadur, Shane Amante, Ed
	Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe		Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe
	Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott		Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott
	Brim, Thomas Narten, Dean Bogdanovi, Tom Petch, Robert Raszuk, and		Brim, Thomas Narten, Dean Bogdanovi, Tom Petch, Robert Raszuk,
	Sriganesh Kini for their suggestions and review.		Sriganesh Kini, and John Mattsson for their suggestions and review.
	11. Informative References		11. Informative References
	[I-D.ietf-i2rs-problem-statement]		[I-D.ietf-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-ietf-i2rs-		Routing System Problem Statement", draft-ietf-i2rs-
	problem-statement-03 (work in progress), June 2014.		problem-statement-04 (work in progress), June 2014.
	[I-D.ietf-idr-ls-distribution]		[I-D.ietf-idr-ls-distribution]
	Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.		Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
	Ray, "North-Bound Distribution of Link-State and TE		Ray, "North-Bound Distribution of Link-State and TE
	Information using BGP", draft-ietf-idr-ls-distribution-05		Information using BGP", draft-ietf-idr-ls-distribution-05
	(work in progress), May 2014.		(work in progress), May 2014.
	[I-D.ietf-netconf-restconf]		[I-D.ietf-netconf-restconf]
	Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,		Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
	"RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work		"RESTCONF Protocol", draft-ietf-netconf-restconf-01 (work
	in progress), March 2014.		in progress), July 2014.
	[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.		[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
	Bierman, "Network Configuration Protocol (NETCONF)", RFC		Bierman, "Network Configuration Protocol (NETCONF)", RFC
	6241, June 2011.		6241, June 2011.
	[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration		[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
	Protocol (NETCONF) Access Control Model", RFC 6536, March		Protocol (NETCONF) Access Control Model", RFC 6536, March
	2012.		2012.
	Authors' Addresses		Authors' Addresses
End of changes. 9 change blocks.
	9 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/