Software-Defined Networking: A Perspective from within a Service Provider Environment
draft-sin-sdnrg-sdn-approach-09

[Ballot comment]
Thank you for the additional text on bootstrapping, discovery and control channel maintenance. I believe the new text highlights a number of important issues that are often glossed over in discussions on SDN.

[Ballot discuss]
Thank you for addressing the other elements of my discuss.

We are now left with this item:

"Firstly when I can across the topic of bootstrapping I was quite excited that there was going to be a serious discussion of how you bring up and manage an SDN, whether an IGP was required to create a base topology, and if not how this all worked. Unfortunately this did not seem to be addressed by the authors."

This is partially addressed by the new fifth para in the bootstrapping text, but I think that you need to go a little further. You handle that case where SDN provides overlay on a conventional IGP based network. However, I think that some claim that SDN can be a substitute for an IGP based network approach, and I think that you need to address the point that there MUST at all times be a resilient method for all nodes to discover and connect to the SDN controller. Where the SDN is not an overlay function over a network using an existing IGP, either a specialist additional network is required to provide that discovery and connection functionality, or a suitable alternative boostrap protocol needs to be developed and deployed.

[Ballot comment]
I really like this doc, and the comments others have made would improve it (so that I would really, really like this doc), but it is awkwardly straddling IRTF and IETF, with a third leg pointed towards ISE. I would support it being published in either the IRTF stream or the ISE stream..

What I'd really like to see, is it being published as an Independent Submission as "one service provider's view" and/or forming the basis of a taxonomy document with broader support.

I note that the Beyond OpenFlow section (3.5) is almost a mantra in SDNRG - it's the kind of thing you can say when it's not an IETF stream document.

What Lars would really like to see, is "SDNRG Working Group" not being in the upper left hand corner of the title page. Does that get rewritten by the RFC Editor anyway?

[Ballot comment]
On one side, I'm happy to see a first SDN document in the IETF.
This document is nice little introduction and explain some high level concepts. Thanks

On the other side, I have some concerns:
While the text is not bad, it states some personal opinions.
We could debate on some points for some time: COPS-PR (I thought it was dead), where does the intelligence reside? interfaces, etc.
Also, it seems like a self promotion of the authors other drafts

  [I-D.boucadair-connectivity-provisioning-profile] 
  [I-D.boucadair-connectivity-provisioning-protocol]
  [I-D.boucadair-network-automation-requirements]

Bottom line, I asked for some opinion, and I receive this one:
"it's not really accepted by the community; its very much the personal opinions of those two guys"
This also reflects my personal conclusion. Note that the acknowledgments section does show an overwhelming set of SP reviewers.

I abstain, and would move to no objection if this documnet would go through ISE. I could leave with a SDNRG document.

[Ballot comment]
On one side, I'm happy to see a first SDN document in the IETF.
This document is nice little introduction and explain some high level concepts. Thanks

On the other side, I have some concerns:
While the text is not bad, it really states some personal opinions.
Note: I agree with most points, but I know that other communities would not!
We could debate on some points for some time: COPS-PR (I thought it was dead), where does the intelligence reside?, etc.
3. it seems like a self promotion of the authors other drafts

  [I-D.boucadair-connectivity-provisioning-profile]
   
  [I-D.boucadair-connectivity-provisioning-protocol]

  [I-D.boucadair-network-automation-requirements]


Bottom line, I asked for some opinion, and I receive this one:
"it's not really accepted by the community; its very much the personal opinions of those two guys"
This also reflects my personal conclusion. Note that the acknowledgments section does show an overwhelming set of SP reviewers.

I abstain, and would move to no objection if this documnet would go through ISE. I could leave with a SDNRG document.

[Ballot comment]
On one side, I'm happy to see a first SDN document in the IETF.
This document is nice little introduction and explain some agreed high level concepts. Thanks

On the other side, I have some concerns:
While the text is not bad, it really states some personal opinions.
Note: I agree with most points, but I know that other communities would not!
We could debate on some points for some time: COPS-PR (I thought it was dead), where does the intelligence reside?, etc.
3. it seems like a self promotion of the authors other drafts

  [I-D.boucadair-connectivity-provisioning-profile]
   
  [I-D.boucadair-connectivity-provisioning-protocol]

  [I-D.boucadair-network-automation-requirements]


Bottom line, I asked for some opinion, and I receive this one:
"it's not really accepted by the community; its very much the personal opinions of those two guys"
This also reflects my personal conclusion. Note that the acknowledgments section does show an overwhelming set of SP reviewers.

I abstain, and would move to no objection if this documnet would go through ISE. I could leave with a SDNRG document.

[Ballot comment]

Overall, I like this - it should be useful input for
people designing SDN stuff. I do wonder why it isn't
just an IRTF SDNRG document though, since it might
fit better there. But doing it this was is fine by me.

- 3.3 says that some s/w modules might be controlled by
external entities - surely that would raise some
additional security and privacy consideratons in an SDN
deployment? I'd say that would be worth a mention in
section 6.

- Section 6 could probably also mention s/w update
requirements, if that's not already covered in Sam
Hartman's draft that's referenced. (Can't recall.)

[Ballot comment]
The section on flexibility 2.2 essentially says we're not going to define it (flexibility), but imagine a case where signaling is used to twiddle cos/packet treatment. I would characterize that as deeply unsatisfying.

section 3.5

seems like a poorly targeted screed on openflow and I don't think it particularly appropiate as written to include such things in IETF documents.

[Ballot comment]
I agree with my esteemed colleagues that this document would be far more appropriate on the Independent stream.  Or, as I expected from the draft name, the IRTF stream.  I do have to admit, though, that this document could fit through the same loop hole I suggested for RTMFP -- it is a product of the IETF in the sense that the IETF thought it was a good idea to publish.

That concern aside, thanks to the authors for a readable, thoughtful document.

In Section 3.1:
"(references can be added if needed)"
This can probably be deleted at this point.

[Ballot comment]
Regardless of what stream it gets published through I think it ought to clear say which service provider's opinion this draft documents.

The title of the draft is:

  A Perspective From Within A Service Provider

I assume the provider to which this draft is referring is France Telecom because the authors are both form the same company?  Wouldn't a better title be:

  France Telecom's Perspective on Software-Defined Networking

With that title change then it would be like every other draft we "discuss" that comes through the IESG that is an organization's protocol, view, profile, etc. ?

[Ballot comment]
I would like to hear why this draft is put forward as AD sponsored, as this looks like a fine thing for the ISE track.

[Ballot comment]
While I agree with many of the points raised in this document, I cannot support its publication as an IETF stream RFC.  This type of opinion piece is much better suited as a corporate whitepaper or an Informational RFC via the ISE.  Given that view, I am abstaining on this document.

[Ballot discuss]
I disagree with Brian, in that I think that it is fine for such RFCs to be published although it feels more like an ISE document. Indeed the content is mainly useful in getting readers to understand the wider issues of SDN. I would
like the opportunity to discuss this publication approach with the IESG.

There are two shortcomings in the text that I would like to discuss with the sponsoring AD.

Firstly when I can across the topic of bootstrapping I was quite excited that there was going to be a serious discussion of how you bring up and manage an SDN, whether an IGP was required to create a base topology, and if not how this all worked. Unfortunately this did not seem to be addressed by the authors.

Secondly, there was no discussion of OAM or other test and verification tools that I could see, which is also a topic that deserves consideration in such a document.

The document fulfills the roll of a primer on SDN within the IETF, and would be significantly improved with text on those topics.

[Ballot comment]
While I agree with many of the points raised in this document, I cannot support its publication as an RFC.  This type of opinion piece is much better suited as a corporate whitepaper.  Given that view, I am abstaining on this document.

IESG/Authors/WG Chairs:

IANA has reviewed draft-sin-sdnrg-sdn-approach-04, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Software-Defined Networking: A Perspective From Within A Service Provider) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Software-Defined Networking: A Perspective From Within A Service
  Provider'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  Software-Defined Networking (SDN) has been one of the major buzz
  words of the networking industry for the past couple of years.  And
  yet, no clear definition of what SDN actually covers has been broadly
  admitted so far.  This document aims at contributing to the
  clarification of the SDN landscape by providing a perspective on
  requirements, issues and other considerations about SDN, as seen from
  within a service provider environment.

  It is not meant to endlessly discuss what SDN truly means, but rather
  to suggest a functional taxonomy of the techniques that can be used
  under a SDN umbrella and to elaborate on the various pending issues
  the combined activation of such techniques inevitably raises.  As
  such, a definition of SDN is only mentioned for the sake of
  clarification.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-sin-sdnrg-sdn-approach/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-sin-sdnrg-sdn-approach/ballot/


No IPR declarations have been submitted directly on this I-D.