Subject: [Gen-art] Gen-ART Telechat review of draft-sin-sdnrg-sdn-approach-05.txt

From: Suresh Krishnan <[email-masked]>
Date: Tue, 19 Nov 2013 00:55:07 -0500

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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.

Minor
=====

* 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
   scale.

* 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.

Editorial
=========

* Section 3.3

s/policiy/policy/

Thanks
Suresh

---

From: <[email-masked]>
Date: Tue, 19 Nov 2013 11:47:03 +0100

Hello Suresh,

Thanks for your review. We will update the draft in light of your comments, but please see inline a few responses.

[snip]

* Section 2.1

[CJ] OK.

   As such, the current state-of-the-art tends to confirm the said
   separation, which rather falls under a tautology.
[CJ] What is meant by this sentence is that data and control planes have always been separated from an implementation standpoint, hence the tautology: commercial routers use a (S/W-based) routing engine for route computation purposes, while packet forwarding functions are usually H/W encoded.

   But a somewhat centralized, "controller-embedded", control plane for
   the sake of optimized route computation before FIB population is
   certainly another story.
[CJ] One of the main arguments of SDN proponents is that (1) the control plane is separated from the data plane but, more importantly, (2) this separation assumes a (logically) centralized control plane, which allows the use of commodity H/W. From an implementation standpoint, this is different from current router technologies, although there has been some vendors in the past who tried to promote this kind of design (I remember Newbridge's Vivid technology at the end of the '90s, for example). I'm not too sure about how we can possibly re-word this, admittedly.

* Section 3.1

   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])).
[CJ] What is meant here is that so-called SDN features have been there for quite some time and some of them have been standardized, hence the couple of examples above.

* 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.
[CJ] Fine by me, we'll add an extra sentence.

* Section 3.5

Does this mean

Can you please clarify?
[CJ] option a is the right one. We'll reword accordingly.

* 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.
CJ: The sentence means that there are S/W and H/W limitations respectively that will always restrict the scope of claimed flexibility - another tautology, if you will.

* 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?

CJ: Fair enough. We'll simplify the wording, e.g., "DC networks that may rely upon OpenFlow switches are unlikely to raise FIB scalability issues. Conversely, DC interconnect designs that aim at dynamically managing VM mobility possibly based upon the enforcement of specific QoS policies may raise scalability issues."

* Section 4.6

CJ: the risk is both technical and economical. From a technical standpoint, the ability to dynamically provision resources as a function of the services to be delivered may be incompatible with legacy routing systems because of H/W limitations. From an economical standpoint, this is about assessing the impact of deploying SND solutions for the sake of flexibility and automation on CapEx and OpEx budgets.

Editorial
=========

* Section 3.3

s/policiy/policy/

CJ: thanks.

Cheers,

Christian.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 20 Nov 2013 09:47:32 -0500

Hi Christian/Med,
  I checked out the -06 version submitted this morning, and it addresses
all my comments. Thanks for taking care of this quickly.

Regards
Suresh

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Nov 2013 11:11:52 -0300

Thank you Suresh for the review! And thank you Christian for the quick response & update. I have balloted a no-obj position for this draft on today's IESG telechat.

Jari

On Nov 20, 2013, at 11:47 AM, Suresh Krishnan <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art