draft-ietf-i2rs-architecture-08.txt		draft-ietf-i2rs-architecture-09.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: July 11, 2015 Ericsson		Expires: September 7, 2015 Ericsson
	S. Hares		S. Hares
	Huawei		Huawei
	D. Ward		D. Ward
	Cisco Systems		Cisco Systems
	T. Nadeau		T. Nadeau
	Brocade		Brocade
	January 7, 2015		March 6, 2015
	An Architecture for the Interface to the Routing System		An Architecture for the Interface to the Routing System
	draft-ietf-i2rs-architecture-08		draft-ietf-i2rs-architecture-09
	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 the Interface to Routing System (I2RS).		part of the Interface to Routing System (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 July 11, 2015.		This Internet-Draft will expire on September 7, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	skipping to change at page 2, line 23		skipping to change at page 2, line 23
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4		1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4
	1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5		1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3. Key Architectural Properties . . . . . . . . . . . . . . . . 10		3. Key Architectural Properties . . . . . . . . . . . . . . . . 10
	3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10		3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11		3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11
	3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11		3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	4.1. Identity and Authentication . . . . . . . . . . . . . . . 13		4.1. Identity and Authentication . . . . . . . . . . . . . . . 14
	4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 14		4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 14
	4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 14		4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 15
	5. Network Applications and I2RS Client . . . . . . . . . . . . 15		5. Network Applications and I2RS Client . . . . . . . . . . . . 15
	5.1. Example Network Application: Topology Manager . . . . . . 15		5.1. Example Network Application: Topology Manager . . . . . . 16
	6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 16		6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 16
	6.1. Relationship to its Routing Element . . . . . . . . . . . 16		6.1. Relationship to its Routing Element . . . . . . . . . . . 16
	6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16		6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 17
	6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 17		6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 17
	6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 18		6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 18
	6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 18		6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 18
	6.3. Interactions with Local Config . . . . . . . . . . . . . 18		6.3. Interactions with Local Config . . . . . . . . . . . . . 19
	6.4. Routing Components and Associated I2RS Services . . . . . 19		6.4. Routing Components and Associated I2RS Services . . . . . 19
	6.4.1. Routing and Label Information Bases . . . . . . . . . 20		6.4.1. Routing and Label Information Bases . . . . . . . . . 20
	6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 21		6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 21
	6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 21		6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 22		6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 22
	6.4.5. Information Modeling, Device Variation, and		6.4.5. Information Modeling, Device Variation, and
	Information Relationships . . . . . . . . . . . . . . 22		Information Relationships . . . . . . . . . . . . . . 22
	6.4.5.1. Managing Variation: Object Classes/Types and		6.4.5.1. Managing Variation: Object Classes/Types and
	Inheritance . . . . . . . . . . . . . . . . . . . 22		Inheritance . . . . . . . . . . . . . . . . . . . 22
	6.4.5.2. Managing Variation: Optionality . . . . . . . . . 23		6.4.5.2. Managing Variation: Optionality . . . . . . . . . 23
	skipping to change at page 12, line 23		skipping to change at page 12, line 23
	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 may indicate which data-models are		data-models. An I2RS agent may indicate which data-models are
	supported.		supported.
	4. Security Considerations		4. Security Considerations
	This I2RS architecture describes interfaces that clearly require		This I2RS architecture describes interfaces that clearly require
	serious consideration of security. First, here is a brief		serious consideration of security. As an architecture, I2RS has been
	description of the assumed security environment for I2RS. The I2RS		designed to re-utilize existing protocols that carry network
	Agent associated with a Routing Element is a trusted part of that		management information. Two of existing protocol which the I2RS WG
	Routing Element. For example, it may be part of a vendor-distributed		has selected to attempt to re-use are NETCONF [RFC6241] and RESTCONF
	signed software image for the entire Routing Element or it may be		[I-D.ietf-netconf-restconf]. The I2RS protocol design process is to
	trusted signed application that an operator has installed. The I2RS		specify additional requirements which will include security for an
	Agent is assumed to have a separate authentication and authorization		existing protocol in order to support the I2RS architecture. After
	channel by which it can validate both the identity and permissions		an existing protocol, e.g. NETCONF or RESTCONF, has been alter to
	associated with an I2RS Client. To support numerous and speedy		fit the I2RS requirements, then this protocol will be reviewed to
	interactions between the I2RS Agent and I2RS Client, it is assumed		determine if it meets the I2RS security requirements.
	that the I2RS Agent can also cache that particular I2RS Clients are
	trusted and their associated authorized scope. This implies that the		Due to the re-use strategy of the I2RS architecture, this security
	permission information may be old either in a pull model until the		section describes the assumed security environment for I2RS with
	I2RS Agent re-requests it, or in a push model until the		additional detail on: a) identity and authentication, b)
	authentication and authorization channel can notify the I2RS Agent of		authorization, and c) client redundancy. Each protocol proposed for
	changes.		inclusions as an I2RS protocol will need to be evaluated for the
			security constraints of the protocol.
			First, here is a brief description of the assumed security
			environment for I2RS. The I2RS Agent associated with a Routing
			Element is a trusted part of that Routing Element. For example, it
			may be part of a vendor-distributed signed software image for the
			entire Routing Element or it may be trusted signed application that
			an operator has installed. The I2RS Agent is assumed to have a
			separate authentication and authorization channel by which it can
			validate both the identity and permissions associated with an I2RS
			Client. To support numerous and speedy interactions between the I2RS
			Agent and I2RS Client, it is assumed that the I2RS Agent can also
			cache that particular I2RS Clients are trusted and their associated
			authorized scope. This implies that 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 authentication and authorization channel
			can notify the I2RS Agent of changes.
	Mutual authentication between the I2RS Client and I2RS Agent is		Mutual authentication between the I2RS Client and I2RS Agent is
	required. An I2RS Client must be able to trust that the I2RS Agent		required. An I2RS Client must be able to trust that the I2RS Agent
	is attached to the relevant Routing Element so that write/modify		is attached to the relevant Routing Element so that write/modify
	operations are correctly applied and so that information received		operations are correctly applied and so that information received
	from the I2RS Agent can be trusted by the I2RS Client.		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
	skipping to change at page 30, line 47		skipping to change at page 30, line 47
	Brim, Thomas Narten, Dean Bogdanovi, Tom Petch, Robert Raszuk,		Brim, Thomas Narten, Dean Bogdanovi, Tom Petch, Robert Raszuk,
	Sriganesh Kini, John Mattsson, Nancy Cam-Winget, DaCheng Zhang, Qin		Sriganesh Kini, John Mattsson, Nancy Cam-Winget, DaCheng Zhang, Qin
	Wu, Ahmed Abro, Salman Asadullah, and Eric Yu. for their suggestions		Wu, Ahmed Abro, Salman Asadullah, and Eric Yu. for their suggestions
	and review.		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-04 (work in progress), June 2014.		problem-statement-06 (work in progress), January 2015.
	[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-07		Information using BGP", draft-ietf-idr-ls-distribution-10
	(work in progress), November 2014.		(work in progress), January 2015.
	[I-D.ietf-netconf-restconf]		[I-D.ietf-netconf-restconf]
	Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", draft-ietf-netconf-restconf-03 (work in		Protocol", draft-ietf-netconf-restconf-04 (work in
	progress), October 2014.		progress), January 2015.
	[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. 13 change blocks.
	30 lines changed or deleted		47 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/