< draft-ietf-bmwg-sdn-controller-benchmark-term-06.txt		draft-ietf-bmwg-sdn-controller-benchmark-term-07.txt >
	Internet-Draft Bhuvaneswaran Vengainathan		Internet-Draft Bhuvaneswaran Vengainathan
	Network Working Group Anton Basil		Network Working Group Anton Basil
	Intended Status: Informational Veryx Technologies		Intended Status: Informational Veryx Technologies
	Expires: May 16, 2018 Mark Tassinari		Expires: June 10, 2018 Mark Tassinari
	Hewlett-Packard		Hewlett-Packard
	Vishwas Manral		Vishwas Manral
	Nano Sec		Nano Sec
	Sarah Banks		Sarah Banks
	VSS Monitoring		VSS Monitoring
	November 16, 2017		January 10, 2018
	Terminology for Benchmarking SDN Controller Performance		Terminology for Benchmarking SDN Controller Performance
	draft-ietf-bmwg-sdn-controller-benchmark-term-06		draft-ietf-bmwg-sdn-controller-benchmark-term-07
	Abstract		Abstract
	This document defines terminology for benchmarking an SDN		This document defines terminology for benchmarking an SDN
	controller's control plane performance. It extends the terminology		controller's control plane performance. It extends the terminology
	already defined in RFC 7426 for the purpose of benchmarking SDN		already defined in RFC 7426 for the purpose of benchmarking SDN
	controllers. The terms provided in this document help to benchmark		controllers. The terms provided in this document help to benchmark
	SDN controller's performance independent of the controller's		SDN controller's performance independent of the controller's
	supported protocols and/or network services. A mechanism for		supported protocols and/or network services. A mechanism for
	benchmarking the performance of SDN controllers is defined in the		benchmarking the performance of SDN controllers is defined in the
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference		at any 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 May 16, 2018.		This Internet-Draft will expire on June 10, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	2.1.3. Controller Forwarding Table..........................5		2.1.3. Controller Forwarding Table..........................5
	2.1.4. Proactive Flow Provisioning Mode.....................5		2.1.4. Proactive Flow Provisioning Mode.....................5
	2.1.5. Reactive Flow Provisioning Mode......................6		2.1.5. Reactive Flow Provisioning Mode......................6
	2.1.6. Path.................................................6		2.1.6. Path.................................................6
	2.1.7. Standalone Mode......................................6		2.1.7. Standalone Mode......................................6
	2.1.8. Cluster/Redundancy Mode..............................7		2.1.8. Cluster/Redundancy Mode..............................7
	2.1.9. Asynchronous Message.................................7		2.1.9. Asynchronous Message.................................7
	2.1.10. Test Traffic Generator..............................8		2.1.10. Test Traffic Generator..............................8
	2.2. Test Configuration/Setup Terms............................8		2.2. Test Configuration/Setup Terms............................8
	2.2.1. Number of Network Devices............................8		2.2.1. Number of Network Devices............................8
	2.2.2. Trials...............................................8		2.2.2. Trial Repetition.....................................8
	2.2.3. Trial Duration.......................................9		2.2.3. Trial Duration.......................................9
	2.2.4. Number of Cluster nodes..............................9		2.2.4. Number of Cluster nodes..............................9
	2.3. Benchmarking Terms.......................................10		2.3. Benchmarking Terms.......................................10
	2.3.1. Performance.........................................10		2.3.1. Performance.........................................10
	2.3.1.1. Network Topology Discovery Time................10		2.3.1.1. Network Topology Discovery Time................10
	2.3.1.2. Asynchronous Message Processing Time...........10		2.3.1.2. Asynchronous Message Processing Time...........10
	2.3.1.3. Asynchronous Message Processing Rate...........11		2.3.1.3. Asynchronous Message Processing Rate...........11
	2.3.1.4. Reactive Path Provisioning Time................12		2.3.1.4. Reactive Path Provisioning Time................12
	2.3.1.5. Proactive Path Provisioning Time...............12		2.3.1.5. Proactive Path Provisioning Time...............12
	2.3.1.6. Reactive Path Provisioning Rate................13		2.3.1.6. Reactive Path Provisioning Rate................13
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	2.3.2.1. Control Sessions Capacity......................15		2.3.2.1. Control Sessions Capacity......................15
	2.3.2.2. Network Discovery Size.........................15		2.3.2.2. Network Discovery Size.........................15
	2.3.2.3. Forwarding Table Capacity......................16		2.3.2.3. Forwarding Table Capacity......................16
	2.3.3. Security............................................16		2.3.3. Security............................................16
	2.3.3.1. Exception Handling.............................16		2.3.3.1. Exception Handling.............................16
	2.3.3.2. Denial of Service Handling.....................17		2.3.3.2. Denial of Service Handling.....................17
	2.3.4. Reliability.........................................17		2.3.4. Reliability.........................................17
	2.3.4.1. Controller Failover Time.......................17		2.3.4.1. Controller Failover Time.......................17
	2.3.4.2. Network Re-Provisioning Time...................18		2.3.4.2. Network Re-Provisioning Time...................18
	3. Test Setup....................................................18		3. Test Setup....................................................18
	3.1. Test setup - Controller working in Standalone Mode.......18		3.1. Test setup - Controller working in Standalone Mode.......19
	3.2. Test setup - Controller working in Cluster Mode..........19		3.2. Test setup - Controller working in Cluster Mode..........20
	4. Test Coverage.................................................20		4. Test Coverage.................................................21
	5. References....................................................21		5. References....................................................22
	5.1. Normative References.....................................21		5.1. Normative References.....................................22
	5.2. Informative References...................................22		5.2. Informative References...................................22
	6. IANA Considerations...........................................22		6. IANA Considerations...........................................22
	7. Security Considerations.......................................22		7. Security Considerations.......................................22
	8. Acknowledgements..............................................22		8. Acknowledgements..............................................23
	9. Authors' Addresses............................................22		9. Authors' Addresses............................................23
	1. Introduction		1. Introduction
	Software Defined Networking (SDN) is a networking architecture in		Software Defined Networking (SDN) is a networking architecture in
	which network control is decoupled from the underlying forwarding		which network control is decoupled from the underlying forwarding
	function and is placed in a centralized location called the SDN		function and is placed in a centralized location called the SDN
	controller. The SDN controller abstracts the underlying network and		controller. The SDN controller provides an abstraction of the
	offers a global view of the overall network to applications and		underlying network and offers a global view of the overall network
	business logic. Thus, an SDN controller provides the flexibility to		to applications and business logic. Thus, an SDN controller provides
	program, control, and manage network behaviour dynamically through		the flexibility to program, control, and manage network behaviour
	standard interfaces. Since the network controls are logically		dynamically through standard interfaces. Since the network controls
	centralized, the need to benchmark the SDN controller performance		are logically centralized, the need to benchmark the SDN controller
	becomes significant. This document defines terms to benchmark		performance becomes significant. This document defines terms to
	various controller designs for performance, scalability, reliability		benchmark various controller designs for performance, scalability,
	and security, independent of northbound and southbound protocols.		reliability and security, independent of northbound and southbound
			protocols.
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119.		document are to be interpreted as described in RFC 2119.
	2. Term Definitions		2. Term Definitions
	2.1. SDN Terms		2.1. SDN Terms
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 27 ¶
	N/A		N/A
	See Also:		See Also:
	None		None
	2.1.3. Controller Forwarding Table		2.1.3. Controller Forwarding Table
	Definition:		Definition:
	A controller forwarding table contains flow entries learned in one		A controller forwarding table contains flow entries learned in one
	of two ways: first, entries could be learned from traffic received		of two ways: first, entries could be learned from traffic received
	through the data plane, or, second, these entries could be		through the data plane, or second, these entries could be statically
	statically provisioned on the controller, and distributed to devices		provisioned on the controller and distributed to devices via the
	via the southbound interface.		southbound interface.
	Discussion:		Discussion:
	The controller forwarding table has an aging mechanism which will be		The controller forwarding table has an aging mechanism which will be
	applied only for dynamically learnt entries.		applied only for dynamically learned entries.
	Measurement Units:		Measurement Units:
	N/A		N/A
	See Also:		See Also:
	None		None
	2.1.4. Proactive Flow Provisioning Mode		2.1.4. Proactive Flow Provisioning Mode
	Definition:		Definition:
	skipping to change at page 7, line 47 ¶		skipping to change at page 7, line 47 ¶
	2.1.9. Asynchronous Message		2.1.9. Asynchronous Message
	Definition:		Definition:
	Any message from the Network Device that is generated for network		Any message from the Network Device that is generated for network
	events.		events.
	Discussion:		Discussion:
	Control messages like flow setup request and response message is		Control messages like flow setup request and response message is
	classified as asynchronous message. The controller has to return a		classified as asynchronous message. The controller has to return a
	response message. Note that the Network Device will not be in		response message. Note that the Network Device will not be in
	blocking mode and continues to send/receive other control messages		blocking mode and continues to send/receive other control messages.
	Measurement Units:		Measurement Units:
	N/A		N/A
	See Also:		See Also:
	None		None
	2.1.10. Test Traffic Generator		2.1.10. Test Traffic Generator
	Definition:		Definition:
	Test Traffic Generator is an entity that generates/receives network		Test Traffic Generator is an entity that generates/receives network
	traffic.		traffic.
	Discussion:		Discussion:
	Test Traffic Generator can be an entity that interfaces with Network		Test Traffic Generator typically connects with Network Devices to
	Devices to send/receive real-time network traffic.		send/receive real-time network traffic.
	Measurement Units:		Measurement Units:
	N/A		N/A
	See Also:		See Also:
	None		None
	2.2. Test Configuration/Setup Terms		2.2. Test Configuration/Setup Terms
	2.2.1. Number of Network Devices		2.2.1. Number of Network Devices
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 43 ¶
	Discussion:		Discussion:
	The Network Devices defined in the test topology can be deployed		The Network Devices defined in the test topology can be deployed
	using real hardware or emulated in hardware platforms.		using real hardware or emulated in hardware platforms.
	Measurement Units:		Measurement Units:
	N/A		N/A
	See Also:		See Also:
	None		None
	2.2.2. Trials		2.2.2. Trial Repetition
	Definition:		Definition:
	The number of times the test needs to be repeated.		The number of times the test needs to be repeated.
	Discussion:		Discussion:
	The test needs to be repeated for multiple iterations to obtain a		The test needs to be repeated for multiple iterations to obtain a
	reliable metric. It is recommended that this test SHOULD be		reliable metric. It is recommended that this test SHOULD be
	performed for at least 10 iterations to increase the confidence in		performed for at least 10 iterations to increase the confidence in
	measured result.		measured result.
	skipping to change at page 9, line 23 ¶		skipping to change at page 9, line 23 ¶
	See Also:		See Also:
	None		None
	2.2.3. Trial Duration		2.2.3. Trial Duration
	Definition:		Definition:
	Defines the duration of test trials for each iteration.		Defines the duration of test trials for each iteration.
	Discussion:		Discussion:
	Trial duration forms the basis for stop criteria for benchmarking		Trial duration forms the basis for stop criteria for benchmarking
	tests. Trial not completed within this time interval is considered		tests. Trials not completed within this time interval is considered
	as incomplete.		as incomplete.
	Measurement Units:		Measurement Units:
	seconds		seconds
	See Also:		See Also:
	None		None
	2.2.4. Number of Cluster nodes		2.2.4. Number of Cluster nodes
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 9 ¶
	Measurement Units:		Measurement Units:
	N/A		N/A
	See Also:		See Also:
	None		None
	2.3. Benchmarking Terms		2.3. Benchmarking Terms
	This section defines metrics for benchmarking the SDN controller.		This section defines metrics for benchmarking the SDN controller.
	The procedure to perform the defined metrics is defined in the		The procedure to perform the defined metrics is defined in the
	accompanying methodology document [I-D.sdn-controller-benchmark-meth]		accompanying methodology document[I-D.sdn-controller-benchmark-meth]
	2.3.1. Performance		2.3.1. Performance
	2.3.1.1. Network Topology Discovery Time		2.3.1.1. Network Topology Discovery Time
	Definition:		Definition:
	The time taken by controller(s) to determine the complete network		The time taken by controller(s) to determine the complete network
	topology, defined as the interval starting with the first discovery		topology, defined as the interval starting with the first discovery
	message from the controller(s) at its Southbound interface, ending		message from the controller(s) at its Southbound interface, ending
	with all features of the static topology determined.		with all features of the static topology determined.
	Discussion:		Discussion:
	Network topology discovery is key for the SDN controller to		Network topology discovery is key for the SDN controller to
	provision and manage the network. So it is important to measure how		provision and manage the network. So it is important to measure how
	quickly the controller discovers the topology to learn the current		quickly the controller discovers the topology to learn the current
	network state. This benchmark is obtained by presenting a network		network state. This benchmark is obtained by presenting a network
	topology (Tree, Mesh or Linear) with the given number of nodes to		topology (Tree, Mesh or Linear) with the given number of nodes to
	the controller and wait for the discovery process to complete .It is		the controller and wait for the discovery process to complete. It is
	expected that the controller supports network discovery mechanism		expected that the controller supports network discovery mechanism
	and uses protocol messages for its discovery process.		and uses protocol messages for its discovery process.
	Measurement Units:		Measurement Units:
	milliseconds		milliseconds
	See Also:		See Also:
	None		None
	2.3.1.2. Asynchronous Message Processing Time		2.3.1.2. Asynchronous Message Processing Time
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 26 ¶
	2.3.1.3. Asynchronous Message Processing Rate		2.3.1.3. Asynchronous Message Processing Rate
	Definition:		Definition:
	The number responses to asynchronous messages (such as new flow		The number responses to asynchronous messages (such as new flow
	arrival notification message, etc.) for which the controller(s)		arrival notification message, etc.) for which the controller(s)
	performed processing and replied with a valid and productive (non-		performed processing and replied with a valid and productive (non-
	trivial) response message.		trivial) response message.
	Discussion:		Discussion:
	As SDN assures flexible network and agile provisioning, it is		As SDN assures flexible network and agile provisioning, it is
	important to measure how many network events that the controller can		important to measure how many network events the controller can
	handle at a time. This benchmark is obtained by sending asynchronous		handle at a time. This benchmark is obtained by sending asynchronous
	messages from every connected Network Devices at the rate that the		messages from every connected Network Device at the rate that the
	controller processes without dropping. This test assumes that the		controller processes (without dropping them). This test assumes that
	controller responds to all the received asynchronous messages (the		the controller responds to all the received asynchronous messages
	messages can be designed to elicit individual responses).		(the messages can be designed to elicit individual responses).
	When sending asynchronous messages to the controller(s) at high		When sending asynchronous messages to the controller(s) at high
	rates, some messages or responses may be discarded or corrupted and		rates, some messages or responses may be discarded or corrupted and
	require retransmission to controller(s). Therefore, a useful		require retransmission to controller(s). Therefore, a useful
	qualification on Asynchronous Message Processing Rate is whether the		qualification on Asynchronous Message Processing Rate is whether the
	in-coming message count equals the response count in each trial.		in-coming message count equals the response count in each trial.
	This is called the Loss-free Asynchronous Message Processing Rate.		This is called the Loss-free Asynchronous Message Processing Rate.
	Note that several of the early controller benchmarking tools did not		Note that several of the early controller benchmarking tools did not
	consider lost messages, and instead report the maximum response		consider lost messages, and instead report the maximum response
	rate. This is called the Maximum Asynchronous Message Processing		rate. This is called the Maximum Asynchronous Message Processing
	Rate.		Rate.
	To characterize both the Loss-free and Maximum Rates, a test could		To characterize both the Loss-free and Maximum Rates, a test could
	begin the first trial by sending asynchronous messages to the		begin the first trial by sending asynchronous messages to the
	controller (s) at the maximum possible rate and record the message		controller(s) at the maximum possible rate and record the message
	reply rate and the message loss rate. The message sending rate is		reply rate and the message loss rate. The message sending rate is
	then decreased by the step-size. The message reply rate and the		then decreased by the step-size. The message reply rate and the
	message loss rate are recorded. The test ends with a trial where the		message loss rate are recorded. The test ends with a trial where the
	controller(s) processes the all asynchronous messages sent without		controller(s) processes the all asynchronous messages sent without
	loss. This is the Loss-free Asynchronous Message Processing Rate.		loss. This is the Loss-free Asynchronous Message Processing Rate.
	The trial where the controller(s) produced the maximum response rate		The trial where the controller(s) produced the maximum response rate
	is the Maximum Asynchronous Message Processing Rate. Of course, the		is the Maximum Asynchronous Message Processing Rate. Of course, the
	first trial could begin at a low sending rate with zero lost		first trial could begin at a low sending rate with zero lost
	responses, and increase until the Loss-free and Maximum Rates are		responses, and increase until the Loss-free and Maximum Rates are
	skipping to change at page 12, line 49 ¶		skipping to change at page 12, line 48 ¶
	Measurement Units:		Measurement Units:
	milliseconds.		milliseconds.
	See Also:		See Also:
	None		None
	2.3.1.5. Proactive Path Provisioning Time		2.3.1.5. Proactive Path Provisioning Time
	Definition:		Definition:
	The time taken by the controller to setup a path proactively between		The time taken by the controller to proactively setup a path between
	source and destination node, defined as the interval starting with		source and destination node, defined as the interval starting with
	the first proactive flow provisioned in the controller(s) at its		the first proactive flow provisioned in the controller(s) at its
	Northbound interface, ending with the last flow provisioning		Northbound interface, ending with the last flow provisioning command
	response message sent from the controller(s) at it Southbound		message sent from the controller(s) at it Southbound interface.
	interface.
	Discussion:		Discussion:
	For SDN to support pre-provisioning of traffic path from		For SDN to support pre-provisioning of traffic path from
	application, it is important to measure how fast that the controller		application, it is important to measure how fast that the controller
	provisions an end-to-end flow in the dataplane. The benchmark is		provisions an end-to-end flow in the dataplane. The benchmark is
	obtained by provisioning a flow on controller's northbound interface		obtained by provisioning a flow on controller's northbound interface
	for the traffic to reach from a source to a destination endpoint,		for the traffic to reach from a source to a destination endpoint,
	finding the time difference between the first and the last flow		finding the time difference between the first and the last flow
	provisioning message exchanged between the controller and the		provisioning message exchanged between the controller and the
	Network Devices for the traffic path.		Network Devices for the traffic path.
	skipping to change at page 13, line 34 ¶		skipping to change at page 13, line 32 ¶
	2.3.1.6. Reactive Path Provisioning Rate		2.3.1.6. Reactive Path Provisioning Rate
	Definition:		Definition:
	The maximum number of independent paths a controller can		The maximum number of independent paths a controller can
	concurrently establish between source and destination nodes		concurrently establish between source and destination nodes
	reactively, defined as the number of paths provisioned by the		reactively, defined as the number of paths provisioned by the
	controller(s) at its Southbound interface for the flow provisioning		controller(s) at its Southbound interface for the flow provisioning
	requests received for path provisioning at its Southbound interface		requests received for path provisioning at its Southbound interface
	between the start of the trial and the expiry of given trial		between the start of the trial and the expiry of given trial
	duration		duration.
	Discussion:		Discussion:
	For SDN to support agile traffic forwarding, it is important to		For SDN to support agile traffic forwarding, it is important to
	measure how many end-to-end flows that the controller could setup in		measure how many end-to-end flows that the controller could setup in
	the dataplane. This benchmark is obtained by sending traffic each		the dataplane. This benchmark is obtained by sending traffic each
	with unique source and destination pairs from the source Network		with unique source and destination pairs from the source Network
	Device and determine the number of frames received at the		Device and determine the number of frames received at the
	destination Network Device.		destination Network Device.
	Measurement Units:		Measurement Units:
	skipping to change at page 14, line 13 ¶		skipping to change at page 14, line 13 ¶
	None		None
	2.3.1.7. Proactive Path Provisioning Rate		2.3.1.7. Proactive Path Provisioning Rate
	Definition:		Definition:
	Measure the maximum number of independent paths a controller can		Measure the maximum number of independent paths a controller can
	concurrently establish between source and destination nodes		concurrently establish between source and destination nodes
	proactively, defined as the number of paths provisioned by the		proactively, defined as the number of paths provisioned by the
	controller(s) at its Southbound interface for the paths provisioned		controller(s) at its Southbound interface for the paths provisioned
	in its Northbound interface between the start of the trial and the		in its Northbound interface between the start of the trial and the
	expiry of given trial duration		expiry of given trial duration.
	Discussion:		Discussion:
	For SDN to support pre-provisioning of traffic path for a larger		For SDN to support pre-provisioning of traffic path for a larger
	network from the application, it is important to measure how many		network from the application, it is important to measure how many
	end-to-end flows that the controller could setup in the dataplane.		end-to-end flows that the controller could setup in the dataplane.
	This benchmark is obtained by sending traffic each with unique		This benchmark is obtained by sending traffic each with unique
	source and destination pairs from the source Network Device. Program		source and destination pairs from the source Network Device. Program
	the flows on controller's northbound interface for traffic to reach		the flows on controller's northbound interface for traffic to reach
	from each of the unique source and destination pairs and determine		from each of the unique source and destination pairs and determine
	the number of frames received at the destination Network Device.		the number of frames received at the destination Network Device.
	skipping to change at page 22, line 8 ¶		skipping to change at page 22, line 25 ¶
	"Terminology for Benchmarking Network-layer Traffic		"Terminology for Benchmarking Network-layer Traffic
	Control Mechanisms", RFC 4689, October 2006.		Control Mechanisms", RFC 4689, October 2006.
	[RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis,		[RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis,
	"Framework for IP Performance Metrics", RFC 2330,		"Framework for IP Performance Metrics", RFC 2330,
	May 1998.		May 1998.
	[I-D.sdn-controller-benchmark-meth] Bhuvaneswaran.V, Anton Basil,		[I-D.sdn-controller-benchmark-meth] Bhuvaneswaran.V, Anton Basil,
	Mark.T, Vishwas Manral, Sarah Banks "Benchmarking		Mark.T, Vishwas Manral, Sarah Banks "Benchmarking
	Methodology for SDN Controller Performance",		Methodology for SDN Controller Performance",
	draft-ietf-bmwg-sdn-controller-benchmark-meth-06		draft-ietf-bmwg-sdn-controller-benchmark-meth-07
	(Work in progress), November 16, 2017		(Work in progress), January 10, 2018
	5.2. Informative References		5.2. Informative References
	[OpenFlow Switch Specification] ONF,"OpenFlow Switch Specification"		[OpenFlow Switch Specification] ONF,"OpenFlow Switch Specification"
	Version 1.4.0 (Wire Protocol 0x05), October 14, 2013.		Version 1.4.0 (Wire Protocol 0x05), October 14, 2013.
	6. IANA Considerations		6. IANA Considerations
	This document does not have any IANA requests.		This document does not have any IANA requests.
	skipping to change at page 23, line 22 ¶		skipping to change at page 23, line 47 ¶
	Email: mark.tassinari@hpe.com		Email: mark.tassinari@hpe.com
	Vishwas Manral		Vishwas Manral
	Nano Sec,CA		Nano Sec,CA
	Email: vishwas.manral@gmail.com		Email: vishwas.manral@gmail.com
	Sarah Banks		Sarah Banks
	VSS Monitoring		VSS Monitoring
			930 De Guigne Drive,
			Sunnyvale, CA
	Email: sbanks@encrypted.net		Email: sbanks@encrypted.net
End of changes. 26 change blocks.
	47 lines changed or deleted		49 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/