Last Call Review of draft-sin-sdnrg-sdn-approach-04

Request Review of draft-sin-sdnrg-sdn-approach
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-11-04
Requested 2013-10-10
Authors Mohamed Boucadair, Christian Jacquenet
Draft last updated 2013-11-04
Completed reviews Genart Last Call review of -04 by Suresh Krishnan (diff)
Genart Telechat review of -05 by Suresh Krishnan (diff)
Secdir Last Call review of -04 by Leif Johansson (diff)
Opsdir Early review of -05 by David Kessens (diff)
Assignment Reviewer Suresh Krishnan 
State Completed
Review review-sin-sdnrg-sdn-approach-04-genart-lc-krishnan-2013-11-04
Reviewed rev. 04 (document currently at 09)
Review result Almost Ready
Review completed: 2013-11-04


I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see


Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-sin-sdnrg-sdn-approach-05.txt
Reviewer: Suresh Krishnan
Review Date: 2013/11/18
IESG Telechat date: 2013/11/21

Summary: This draft is almost ready for publication as an Informational
RFC but I do have a few comments that the authors may wish to consider.


* Section 2.1

-> Not sure if the word encoded is appropriate here.

s/hardware-encoded/usually implemented in hardware/

-> These two sentences are hard to read and it is not clear what point
they are trying to make. Please consider rewording.

   As such, the current state-of-the-art tends to confirm the said
   separation, which rather falls under a tautology.

   But a somewhat centralized, "controller-embedded", control plane for
   the sake of optimized route computation before FIB population is
   certainly another story.

* Section 3.1

Not sure what this sentence is trying to convey. Can you clarify?

   Some of these features have also been standardized (e.g., DNS-based
   routing [RFC1383] that can be seen as an illustration of separated
   control and forwarding planes or ForCES ([RFC5810][RFC5812])).

* Section 3.4

This direct access to some engines using a vendor-specific could be
beneficial to performance but may increase configuration complexity (in
opposition to the final goal in Section 4.1 of accommodating
heterogeneous network technologies). It may be worthwhile to add some
text to the following paragraph in this regard.

   Maintaining hard-coded performance optimization techniques is
   encouraged.  So is the use of interfaces that allow the direct
   control of some engines (e.g., routing, forwarding) without requiring
   any in-between adaptation layer (generic objects to vendor-specific
   CLI commands for instance).

* Section 3.5

This sentence is ambiguous

OpenFlow is clearly not the "next big thing"

Does this mean

a) OpenFlow is certainly not the "next best thing" (or)
b) It is not clear if OpenFlow will be the "next best thing"

Can you please clarify?

* Section 3.6

This sentence about non-goals is unclear. What are the "respective
software limitations"?

   o  Fully flexible software implementations, because the claimed
      flexibility will be limited by respective software and hardware
      limitations, anyway.

* Section 4.5

This sentence is long and complex, and the exact point it is trying to
make is not clear. Can you simplify/reword?

   For example: while the deployment of a network solely composed of
   OpenFlow switches within a data center environment is unlikely to
   raise FIB scalability issues given the current state-of-the-art, data
   center networking that relies upon complex, possibly IP-based, QoS-
   inferred, interconnect design schemes meant to dynamically manage the
   mobility of Virtual Machines between sites is certainly of another

* Section 4.6

Can you clarify what risk is being assessed here?

   o  Assessing whether SDN-labeled solutions are likely to obsolete
      existing technologies because of hardware limitations.


* Section 3.3