Subject: Re: [Sdn] FW: Last Call: <draft-sin-sdnrg-sdn-approach-04.txt> (Software-Defined Networking: A Perspective From Within A Service Provider) to Informational RFC

From: Linda Dunbar <[email-masked]>
Date: Tue, 8 Oct 2013 20:18:22 +0000

Adrian, 

Thanks for sharing this draft. This is a very good draft to summarize SDN for carrier networks. 

Two comments:
- 100% Agree with the draft on the emphasis of PDP (Policy Decision Point) and PEP (Policy enforcement Point) components of SDN. why does the draft emphasize that "SDN approach should be global, network-wide"? Here are a couple of examples that SDN is not global based:

1) The wireless' PCRF (Policy and Charging rules function) and PCEF (Policy Charging Enforcement Function) are good examples of SDN. However, PCRF and PCEF only control the access segments, not global network. 

2) In data center, centralized controller(s), with the information passed from VM management system,  can define (virtual) networks to interconnect Virtual machines. This network is local to Data Center, not necessarily global based. 

- We all understand the challenges of "Full Automation". However, the SDN and Full automation are two separate angles to Carrier networks. I find the Section 4.1  "Implications of full automation" actually de-rails the focus of the draft on SDN. 

My two cents. 

Linda 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adrian Farrel
> Sent: Monday, October 07, 2013 1:49 PM
> To: [email-masked]
> Subject: [Sdn] FW: Last Call: <draft-sin-sdnrg-sdn-approach-04.txt>
> (Software-Defined Networking: A Perspective From Within A Service
> Provider) to Informational RFC
> 
> Heads up!
> 
> This document which was discussed from time-to-time in the SDNRG is
> going for
> IETF last call as an AD-sponsored independent submission.
> 
> Review comments are welcome as always. Please follow the instructions
> in the
> email below.
> 
> Thanks,
> Adrian
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:ietf-announce-
> > [email-masked]] On Behalf Of The IESG
> > Sent: 07 October 2013 19:40
> > To: IETF-Announce
> > Subject: Last Call: <draft-sin-sdnrg-sdn-approach-04.txt> (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'
> >   <draft-sin-sdnrg-sdn-approach-04.txt> 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
> > [email-masked] mailing lists by 2013-11-04. Exceptionally, comments
> may be
> > sent to [email-masked] 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.
> 
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn

---

From: "George, Wes" <[email-masked]>
Date: Wed, 9 Oct 2013 10:17:47 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Linda Dunbar

>
> - We all understand the challenges of "Full Automation". However, the
> SDN and Full automation are two separate angles to Carrier networks. I
> find the Section 4.1  "Implications of full automation" actually de-
> rails the focus of the draft on SDN.

[WEG] I strongly disagree. First, "we all understand..." is an overgeneralization, and a dangerous and grossly inaccurate one at that. Lots of SDN vendors have repeatedly demonstrated to me how little they actually understand about this problem. It's not a new problem by any means, but there's a really significant amount of hand-waving going on around the complexities of actually doing what they're saying is possible through the "magic" of SDN, when few have demonstrated how the abstract concept "SDN" actually makes solving this problem easier. The reality is that SDN and automation are inextricably linked. The next to last sentence in section 2.3 reinforces this, and I believe that 4.1 is absolutely appropriate for this draft. A truly software-defined network is an automated one, and any discussion of an operator's perspective on SDN is going to need to consider the same challenges that have been present in prior attempts to better automate network management, provisioning, and control. There are two models for managing a network like this, one that is fully automated, meaning that it is quite a lot more complex and susceptible to "ghost in the machine" problems, the other which has a human making most of the important decisions and then dictating those to the network. Even the latter model requires a significant amount of automation to execute what the human has decided should be done.
The things covered in section 4.1 mirrors a lot of the discussion that I have had both internally and with other operators around the challenges of separating the hype of SDN from the actual benefit, and in selling this model to operations folks who are skeptical of ceding control to a set of computer logic.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 9 Oct 2013 18:40:45 +0000

It is true that SDN depends on automation. 

IMHO, "Automation" is a much bigger area than SDN. 

When you look at Amazon EC2 graphic interface, you can click X number of VMs, and create any kind of virtual networks among them, along with a set of service functions to dictate inter-subnet communication. That is a "Software defined network". 

Linda

> From: George, Wes [mailto:[email-masked]]
> Sent: Wednesday, October 09, 2013 9:18 AM
> To: Linda Dunbar; IETF Discussion
> Subject: RE: [Sdn] FW: Last Call: <draft-sin-sdnrg-sdn-approach-04.txt>
> [WEG] I strongly disagree. First, "we all understand..." is an
> overgeneralization, and a dangerous and grossly inaccurate one at that.
> Lots of SDN vendors have repeatedly demonstrated to me how little they
> actually understand about this problem. It's not a new problem by any
> means, but there's a really significant amount of hand-waving going on
> around the complexities of actually doing what they're saying is
> possible through the "magic" of SDN, when few have demonstrated how the
> abstract concept "SDN" actually makes solving this problem easier. The
> reality is that SDN and automation are inextricably linked. The next to
> last sentence in section 2.3 reinforces this, and I believe that 4.1 is
> absolutely appropriate for this draft. A truly software-defined network
> is an automated one, and any discussion of an operator's perspective on
> SDN is going to need to consider the same challenges that have been
> present in prior attempts to better automate network management,
> provisioning, and control. There are two models for managing a network
> like this, one that is fully automated, meaning that it is quite a lot
> more complex and susceptible to "ghost in the machine" problems, the
> other which has a human making most of the important decisions and then
> dictating those to the network. Even the latter model requires a
> significant amount of automation to execute what the human has decided
> should be done.
> The things covered in section 4.1 mirrors a lot of the discussion that
> I have had both internally and with other operators around the
> challenges of separating the hype of SDN from the actual benefit, and
> in selling this model to operations folks who are skeptical of ceding
> control to a set of computer logic.
> 
> Wes George
> 
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject
> to copyright belonging to Time Warner Cable. This E-mail is intended
> solely for the use of the individual or entity to which it is addressed.
> If you are not the intended recipient of this E-mail, you are hereby
> notified that any dissemination, distribution, copying, or action taken
> in relation to the contents of and attachments to this E-mail is
> strictly prohibited and may be unlawful. If you have received this E-
> mail in error, please notify the sender immediately and permanently
> delete the original and any copy of this E-mail and any printout.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Oct 2013 09:33:36 +0200

Hi Linda,

You can click the web page and start number of cisco CSR or juniper
vSRX instances to create an arbitrary virtual networks. Is this SDN or
just nice web based front end which you call SDN ?

If I start the same network with few lines of python or perl script is
this still SDN or not any longer ?

Likewise I can easily provision BGP sessions and bunch of services
running on hardware routers by software .. in fact this is already the
case in vast majority of networks. It is therefor SDN too isn't it ?

Best,
R.