draft-ietf-i2rs-architecture-06.txt		draft-ietf-i2rs-architecture-07.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: June 5, 2015 Ericsson		Expires: June 14, 2015 Ericsson
	S. Hares		S. Hares
	Huawei		Huawei
	D. Ward		D. Ward
	Cisco Systems		Cisco Systems
	T. Nadeau		T. Nadeau
	Brocade		Brocade
	December 2, 2014		December 11, 2014
	An Architecture for the Interface to the Routing System		An Architecture for the Interface to the Routing System
	draft-ietf-i2rs-architecture-06		draft-ietf-i2rs-architecture-07
	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 June 5, 2015.		This Internet-Draft will expire on June 14, 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 2, line 33		skipping to change at page 2, line 33
	4.1. Identity and Authentication . . . . . . . . . . . . . . . 13		4.1. Identity and Authentication . . . . . . . . . . . . . . . 13
	4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13		4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13
	5. Network Applications and I2RS Client . . . . . . . . . . . . 14		5. Network Applications and I2RS Client . . . . . . . . . . . . 14
	5.1. Example Network Application: Topology Manager . . . . . . 15		5.1. Example Network Application: Topology Manager . . . . . . 15
	6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 15		6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 15
	6.1. Relationship to its Routing Element . . . . . . . . . . . 15		6.1. Relationship to its Routing Element . . . . . . . . . . . 15
	6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16		6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16
	6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 16		6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 16
	6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 17		6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 17
	6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 17		6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 17
	6.3. Interactions with Local Config . . . . . . . . . . . . . 17		6.3. Interactions with Local Config . . . . . . . . . . . . . 18
	6.4. Routing Components and Associated I2RS Services . . . . . 18		6.4. Routing Components and Associated I2RS Services . . . . . 18
	6.4.1. Routing and Label Information Bases . . . . . . . . . 19		6.4.1. Routing and Label Information Bases . . . . . . . . . 19
	6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 20		6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 20
	6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 20		6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 20
	6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 21		6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 21
	6.4.5. Information Modeling, Device Variation, and		6.4.5. Information Modeling, Device Variation, and
	Information Relationships . . . . . . . . . . . . . . 21		Information Relationships . . . . . . . . . . . . . . 21
	6.4.5.1. Managing Variation: Object Classes/Types and		6.4.5.1. Managing Variation: Object Classes/Types and
	Inheritance . . . . . . . . . . . . . . . . . . . 21		Inheritance . . . . . . . . . . . . . . . . . . . 21
	6.4.5.2. Managing Variation: Optionality . . . . . . . . . 22		6.4.5.2. Managing Variation: Optionality . . . . . . . . . 22
	skipping to change at page 5, line 15		skipping to change at page 5, line 15
	1.2. Architectural Overview		1.2. Architectural Overview
	Figure 1 shows the basic architecture for I2RS between applications		Figure 1 shows the basic architecture for I2RS between applications
	using I2RS, their associated I2RS Clients, and I2RS Agents.		using I2RS, their associated I2RS Clients, and I2RS Agents.
	Applications access I2RS services through I2RS clients. A single		Applications access I2RS services through I2RS clients. A single
	client can provide access to one or more applications. In the		client can provide access to one or more applications. In the
	figure, Clients A and B provide access to a single application, while		figure, Clients A and B provide access to a single application, while
	Client P provides access to multiple applications.		Client P provides access to multiple applications.
	Applications can access I2RS services through local or remote		Applications can access I2RS services through local or remote
	clients. In the figure, Applicatons A and B access I2RS services		clients. In the figure, Applications A and B access I2RS services
	through local clients, while Applications C, D and E access I2RS		through local clients, while Applications C, D and E access I2RS
	services through a remote client. The details of how applications		services through a remote client. The details of how applications
	communicate with a remote client is out of scope for I2RS.		communicate with a remote client is out of scope for I2RS.
	An I2RS Client can access one or more I2RS agents. In the figure,		An I2RS Client can access one or more I2RS agents. In the figure,
	Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent		Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent
	can provide service to one or more clients. In the figure, I2RS		can provide service to one or more clients. In the figure, I2RS
	Agent 1 provides services to Clients A, B and P while Agent 2		Agent 1 provides services to Clients A, B and P while Agent 2
	provides services to only Clients B and P.		provides services to only Clients B and P.
	skipping to change at page 8, line 31		skipping to change at page 8, line 31
	operations. In order to keep the protocol simple, two clients should		operations. In order to keep the protocol simple, two clients should
	not attempt to write (modify) the same piece of information on an		not attempt to write (modify) the same piece of information on an
	I2RS Agent. This is considered an error. However, such collisions		I2RS Agent. This is considered an error. However, such collisions
	may happen and section 7.8 (multi-headed control) describes how the		may happen and section 7.8 (multi-headed control) describes how the
	I2RS agent resolves collision by first utilizing priority to resolve		I2RS agent resolves collision by first utilizing priority to resolve
	collisions, and second by servicing the requests in a first in, first		collisions, and second by servicing the requests in a first in, first
	served basis. The i2rs architecture includes this definition of		served basis. The i2rs architecture includes this definition of
	behavior for this case simply for predictability not because this is		behavior for this case simply for predictability not because this is
	an intended result. This predictability will simplify the error		an intended result. This predictability will simplify the error
	handling and suppress oscillations. If additional error cases beyond		handling and suppress oscillations. If additional error cases beyond
	this simple treatment are required, these these error cases should be		this simple treatment are required, these error cases should be
	resolved by the network applications and management systems.		resolved by the network applications and management systems.
	In contrast, although multiple I2RS clients may need to supply data		In contrast, although multiple I2RS clients may need to supply data
	into the same list (e.g. a prefix or filter list), this is not		into the same list (e.g. a prefix or filter list), this is not
	considered an error and must be correctly handled. The nuances so		considered an error and must be correctly handled. The nuances so
	that writers do not normally collide should be handled in the		that writers do not normally collide should be handled in the
	information models.		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
	skipping to change at page 17, line 20		skipping to change at page 17, line 20
	I2RS does not require a persistent connection between the I2RS		I2RS does not require a persistent connection between the I2RS
	Client and I2RS Agent, it is necessary to have a mechanism for the		Client and I2RS Agent, it is necessary to have a mechanism for the
	I2RS Agent to notify I2RS Clients that had subscriptions or		I2RS Agent to notify I2RS Clients that had subscriptions or
	written ephemeral state; such I2RS Clients should be cached by the		written ephemeral state; such I2RS Clients should be cached by the
	I2RS Agent's system in persistent storage. When the I2RS Agent		I2RS Agent's system in persistent storage. When the I2RS Agent
	starts, it should send a NOTIFICATION_I2RS_AGENT_STARTING to each		starts, it should send a NOTIFICATION_I2RS_AGENT_STARTING to each
	cached I2RS Client.		cached I2RS Client.
	Graceful failure: In this case, the I2RS Agent can do specific		Graceful failure: In this case, the I2RS Agent can do specific
	limited work as part of the process of being disabled. The I2RS		limited work as part of the process of being disabled. The I2RS
	Agent Agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all		Agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all its
	its cached I2RS Clients.		cached I2RS Clients.
	6.2.2. Starting and Ending		6.2.2. Starting and Ending
	When an I2RS client applies changes via the I2RS protocol, those		When an I2RS client applies changes via the I2RS protocol, those
	changes are applied and left until removed or the routing element		changes are applied and left until removed or the routing element
	reboots. The network application may make decisions about what to		reboots. The network application may make decisions about what to
	request via I2RS based upon a variety of conditions that imply		request via I2RS based upon a variety of conditions that imply
	different start times and stop times. That complexity is managed by		different start times and stop times. That complexity is managed by
	the network application and is not handled by I2RS.		the network application and is not handled by I2RS.
	6.2.3. Reversion		6.2.3. 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
	without the I2RS; that state is generally whatever was specified via		without the I2RS client-agent interaction; that state is generally
	the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple		whatever was specified via the CLI, NETCONF, SNMP, etc. I2RS Agents
	alternative states, nor try to determine which one among such a		will not store multiple alternative states, nor try to determine
	plurality it should fall back to. Thus, the model followed is not		which one among such a plurality it should fall back to. Thus, the
	like the RIB, where multiple routes are stored at different		model followed is not like the RIB, where multiple routes are stored
	preferences.		at different preferences. (For I2RS state in the presence of two
			I2RS clients, please see section 1.2 and section 7.8)
	An I2RS Client may register for notifications, subject to its		An I2RS Client may register for notifications, subject to its
	notification scope, regarding state modification or removal by a		notification scope, regarding state modification or removal by a
	particular I2RS Client.		particular I2RS Client.
	6.3. Interactions with Local Config		6.3. Interactions with Local Config
	Changes may originate from either Local Config or from I2RS. The		Changes may originate from either Local Config or from I2RS. The
	modifications and data stored by I2RS are separate from the local		modifications and data stored by I2RS are separate from the local
	device configuration, but conflicts between the two must be resolved		device configuration, but conflicts between the two must be resolved
	skipping to change at page 19, line 52		skipping to change at page 19, line 52
	functionality (e.g. pre-defined templates to be applied to interfaces		functionality (e.g. pre-defined templates to be applied to interfaces
	or for QoS behaviors that traffic is direct into). Section 6.4.5		or for QoS behaviors that traffic is direct into). Section 6.4.5
	discusses information modeling constructs and the range of		discusses information modeling constructs and the range of
	relationship types that are applicable.		relationship types that are applicable.
	6.4.1. Routing and Label Information Bases		6.4.1. Routing and Label Information Bases
	Routing elements may maintain one or more Information Bases.		Routing elements may maintain one or more Information Bases.
	Examples include Routing Information Bases such as IPv4/IPv6 Unicast		Examples include Routing Information Bases such as IPv4/IPv6 Unicast
	or IPv4/IPv6 Multicast. Another such example includes the MPLS Label		or IPv4/IPv6 Multicast. Another such example includes the MPLS Label
	Information Bases, per-platform- or per-interface." This		Information Bases, per-platform or per-interface. This
	functionality, exposed via an I2RS Service, must interact smoothly		functionality, exposed via an I2RS Service, must interact smoothly
	with the same mechanisms that the routing element already uses to		with the same mechanisms that the routing element already uses to
	handle RIB input from multiple sources, so as to safely change the		handle RIB input from multiple sources, so as to safely change the
	system state. Conceptually, this can be handled by having the I2RS		system state. Conceptually, this can be handled by having the I2RS
	Agent communicate with a RIB Manager as a separate routing source.		Agent communicate with a RIB Manager as a separate routing source.
	The point-to-multipoint state added to the RIB does not need to match		The point-to-multipoint state added to the RIB does not need to match
	to well-known multicast protocol installed state. The I2RS Agent can		to well-known multicast protocol installed state. The I2RS Agent can
	create arbitrary replication state in the RIB, subject to the		create arbitrary replication state in the RIB, subject to the
	advertised capabilities of the routing element.		advertised capabilities of the routing element.
	skipping to change at page 20, line 44		skipping to change at page 20, line 44
	o joining/removing interfaces from the multicast trees		o joining/removing interfaces from the multicast trees
	o subscribing to an information stream of route changes		o subscribing to an information stream of route changes
	o receiving notifications about peers coming up or going down		o receiving notifications about peers coming up or going down
	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,
	direct modification of the link-state database MUST NOT be allowed in		direct modification of the link-state database must not be allowed in
	order to preserve network state consistency.		order to preserve network state consistency.
	6.4.3. MPLS		6.4.3. MPLS
	I2RS Services will be needed to expose the protocols that create		I2RS Services will be needed to expose the protocols that create
	transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g.		transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g.
	BGP, LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs,		BGP, LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs,
	L2VPNs, etc). This should include all local information about LSPs		L2VPNs, etc). This should include all local information about LSPs
	originating in, transiting, or terminating in this Routing Element.		originating in, transiting, or terminating in this Routing Element.
	skipping to change at page 23, line 25		skipping to change at page 23, line 25
	is a topic for further discussion.		is a topic for further discussion.
	6.4.5.4. Object Relationships		6.4.5.4. Object Relationships
	Objects (in a Routing Element or otherwise) do not exist in		Objects (in a Routing Element or otherwise) do not exist in
	isolation. They are related to each other. One of the important		isolation. They are related to each other. One of the important
	things a class definition does is represent the relationships between		things a class definition does is represent the relationships between
	instances of different classes. These relationships can be very		instances of different classes. These relationships can be very
	simple, or quite complicated. The following lists the information		simple, or quite complicated. The following lists the information
	relationships that the information models need to support.		relationships that the information models need to support.
	[[Editors' note: All of these are for discussion, and it is expected
	that the list may be changed during WG discussion.]]
	6.4.5.4.1. Initialization		6.4.5.4.1. Initialization
	The simplest relationship is that one object instance is initialized		The simplest relationship is that one object instance is initialized
	by copying another. For example, one may have an object instance		by copying another. For example, one may have an object instance
	that represents the default setup for a tunnel, and all new tunnels		that represents the default setup for a tunnel, and all new tunnels
	have fields copied from there if they are not set as part of		have fields copied from there if they are not set as part of
	establishment. This is closely related to the templates discussed		establishment. This is closely related to the templates discussed
	above, but not identical. Since the relationship is only momentary		above, but not identical. Since the relationship is only momentary
	it is often not formally represented in modeling, but only captured		it is often not formally represented in modeling, but only captured
	skipping to change at page 24, line 17		skipping to change at page 24, line 17
	Sometimes the relationship between objects is stronger. A valid ARP		Sometimes the relationship between objects is stronger. A valid ARP
	entry has to point to the active interface over which it was derived.		entry has to point to the active interface over which it was derived.
	This is the classic meaning of an object reference in programming.		This is the classic meaning of an object reference in programming.
	It can be used for relationships like containment or dependence.		It can be used for relationships like containment or dependence.
	This is usually represented by an explicit modeling link.		This is usually represented by an explicit modeling link.
	6.4.5.4.4. Active Reference		6.4.5.4.4. Active Reference
	There is an even stronger form of coupling between objects if changes		There is an even stronger form of coupling between objects if changes
	in one of the two objects are always to be reflected in the state of		in one of the two objects are always to be reflected in the state of
	the other. For example, if a Tunnel has an MTU, and link MTU changes		the other. For example, if a Tunnel has an MTU (maximum transmit
	need to immediately propagate to the Tunnel MTU, then the tunnel is		unit), and link MTU changes need to immediately propagate to the
	actively coupled to the link interface. This kind of active state		Tunnel MTU, then the tunnel is actively coupled to the link
	coupling implies some sort of internal bookkeeping to ensure		interface. This kind of active state coupling implies some sort of
	consistency, often conceptualized as a subscription model across		internal bookkeeping to ensure consistency, often conceptualized as a
	objects.		subscription model across objects.
	7. I2RS Client Agent Interface		7. I2RS Client Agent Interface
	7.1. One Control and Data Exchange Protocol		7.1. One Control and Data Exchange Protocol
	As agreed by the I2RS working group, this I2RS architecture assumes		As agreed by the I2RS working group, this I2RS architecture assumes
	that there is a single I2RS protocol for control and data exchange;		that there is a single I2RS protocol for control and data exchange;
	that protocol will be based on NETCONF[RFC6241] and RESTCONF		that protocol will be based on NETCONF[RFC6241] and RESTCONF
	[I-D.ietf-netconf-restconf]. This helps meet the goal of simplicity		[I-D.ietf-netconf-restconf]. This helps meet the goal of simplicity
	and thereby enhances deployability. That protocol may need to use		and thereby enhances deployability. That protocol may need to use
	several underlying transports (TCP, SCTP, DCCP), with suitable		several underlying transports (TCP, SCTP (stream control transport
	authentication and integrity protection mechanisms. These different		protocol), DCCP (Datagram Congestion Control Protocol)), with
	transports can support different types of communication (e.g.		suitable authentication and integrity protection mechanisms. These
	control, reading, notifications, and information collection) and		different transports can support different types of communication
	different sets of data. Whatever transport is used for the data		(e.g. control, reading, notifications, and information collection)
			and different sets of data. Whatever transport is used for the data
	exchange, it must also support suitable congestion control		exchange, it must also support suitable congestion control
	mechanisms. The transports chosen should be operator and implementor		mechanisms. The transports chosen should be operator and implementor
	friendly to ease adoption.		friendly to ease adoption.
	7.2. Communication Channels		7.2. Communication Channels
	Multiple communication channels and multiple types of communication		Multiple communication channels and multiple types of communication
	channels are required. There may be a range of requirements (e.g.		channels are required. There may be a range of requirements (e.g.
	confidentiality, reliability), and to support the scaling there may		confidentiality, reliability), and to support the scaling there may
	need to be channels originating from multiple sub-components of a		need to be channels originating from multiple sub-components of a
	skipping to change at page 28, line 26		skipping to change at page 28, line 26
	considered an error case. This architecture does not attempt to		considered an error case. This architecture does not attempt to
	determine what the right state of data should be when such a		determine what the right state of data should be when such a
	collision happens. Rather, the architecture mandates that there be		collision happens. Rather, the architecture mandates that there be
	decidable means by which I2RS Agents handle the collisions. The		decidable means by which I2RS Agents handle the collisions. The
	mechanism for ensuring predictability is to have a simple priority		mechanism for ensuring predictability is to have a simple priority
	associated with each I2RS clients, and the highest priority change		associated with each I2RS clients, and the highest priority change
	remains in effect. In the case of priority ties, the first client		remains in effect. In the case of priority ties, the first client
	whose attribution is associated with the data will keep control.		whose attribution is associated with the data will keep control.
	In order for this approach to multi-headed control to be useful for		In order for this approach to multi-headed control to be useful for
	I2RS Clients, it is important that it be possible for an I2RS Client		I2RS Clients, it is important that it is possible for an I2RS Client
	to register for changes to any changes made by I2RS to data that it		to register for changes to any changes made by I2RS to data that it
	may care about. This is included in the I2RS event mechanisms. This		may care about. This is included in the I2RS event mechanisms. This
	also needs to apply to changes made by CLI/NETCONF/SNMP within the		also needs to apply to changes made by CLI/NETCONF/SNMP within the
	write-scope of the I2RS Agent, as the same priority mechanism (even		write-scope of the I2RS Agent, as the same priority mechanism (even
	if it is "CLI always wins") applies there. The I2RS client may then		if it is "CLI always wins") applies there. The I2RS client may then
	respond to the situation as it sees fit.		respond to the situation as it sees fit.
	7.9. Transactions		7.9. Transactions
	In the interest of simplicity, the I2RS architecture does not include		In the interest of simplicity, the I2RS architecture does not include
	skipping to change at page 30, line 15		skipping to change at page 30, line 15
	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,		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 Wu 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-04 (work in progress), June 2014.
	[I-D.ietf-idr-ls-distribution]		[I-D.ietf-idr-ls-distribution]
End of changes. 16 change blocks.
	32 lines changed or deleted		32 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/