Last Call Review of draft-ietf-bmwg-sdn-controller-benchmark-term-07

Request Review of draft-ietf-bmwg-sdn-controller-benchmark-term
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-02-02
Requested 2018-01-19
Authors Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks
Draft last updated 2018-01-30
Completed reviews Rtgdir Last Call review of -07 by Ines Robles (diff)
Opsdir Last Call review of -07 by Ron Bonica (diff)
Genart Last Call review of -07 by Stewart Bryant (diff)
Secdir Last Call review of -07 by Paul Hoffman (diff)
Opsdir Telechat review of -09 by Ron Bonica (diff)
Genart Telechat review of -09 by Stewart Bryant (diff)
Assignment Reviewer Stewart Bryant 
State Completed
Review review-ietf-bmwg-sdn-controller-benchmark-term-07-genart-lc-bryant-2018-01-30
Reviewed rev. 07 (document currently at 10)
Review result Ready with Nits
Review completed: 2018-01-30


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-bmwg-sdn-controller-benchmark-term-07
Reviewer: Stewart Bryant
Review Date: 2018-01-30
IETF LC End Date: 2018-02-02
IESG Telechat date: Not scheduled for a telechat

Summary: Generally a well written document. The various comments I make are mostly editorial with some on the fringe of being technical.

Major issues: None

Minor issues: Asynchronous Message Processing Rate

   The number responses to asynchronous messages (such as new flow
SB> That should be the number of responses per second.

   As SDN assures flexible network and agile provisioning, it is
   important to measure how many network events the controller can
   handle at a time. This benchmark is obtained by sending asynchronous
   messages from every connected Network Device at the rate that the
   controller processes (without dropping them). 

SB> So what you are testing here is the control network and the 
SB> controller. This is perhaps the only practical way to run the 
SB> test, but it seems a pity that you do not deconvolve these
SB> two aspects of the test.
SB> I suppose this is really network Async Msg Proc rate rather than
SB> controller Async proc rate.
SB> We may get to this in the companion document, but doesn't there
SB> need to be some standardization of the event message to compare
SB> apple with apples over time?

Nits/editorial comments: 


   A mechanism for
   benchmarking the performance of SDN controllers is defined in the
   companion methodology document. 
SB> It would be convenient to the reader to provide the reference to or name of
SB> the companion document


2.2.4. Number of Cluster nodes

   This parameter is relevant when testing the controller performance
   in clustering/teaming mode. The number of nodes in the cluster MUST
   be greater than 1.

SB> I see what you are saying, but you may wish to clarify that this 
SB> constraint does not apply all the time. For example one of two nodes
SB> may start later than another, or fail, or maybe I worry over nothing here.

2.3. Benchmarking Terms

   This section defines metrics for benchmarking the SDN controller.
SB> Should that be controller(s)? Reactive Path Provisioning Time

   The time taken by the controller to setup a path reactively between
   source and destination node, defined as the interval starting with
   the first flow provisioning request message received by the
   controller(s), ending with the last flow provisioning response
   message sent from the controller(s) at it Southbound interface.

   As SDN supports agile provisioning, it is important to measure how
SB> Should that be When, rather that As since not all will support the feature. Control Sessions Capacity

Measurement Units:
SB> Surely this should be in units of sessions? Network Discovery Size

Measurement Units:


SB> How can this be N/A surely it is a number of network units of various type. Forwarding Table Capacity

2.3.3. Security Exception Handling

Measurement Units:

SB> Shouldn't that be as per base performance test specified in 2.3.1?
SB> or text similar to UoM?

7. Security Considerations

   Security issues are not discussed in this memo.

SB> Whilst true, you do of course instrument various security related
SB> parameters