[sop] Fwd: SOP and SDN Question

[Michael Hammer <[e-mail]>]

Resending.

---------- Forwarded message ----------
From: Michael Hammer <[e-mail]>
Date: Thu, Feb 23, 2012 at 11:57 AM
Subject: SOP and SDN Question
To: [e-mail]


All,

I saw some questions asking what is the difference between SOP and SDN/OF.
So, I did a quick review of the SDN BOF presentations.
Here is some food for thought:

1) The SDN Problem Statement is more narrowly focused on network and
doesn't address
other important cloud elements of compute and storage, nor the additional
layers that make
up PaaS and SaaS.  So, I am thinking that difference is really in the scope
of perspective.
SOP is about how to specify what cloud consumer needs the cloud to
do, while SDN is in
the weeds on how to do the network portion.  What does SDN do for compute
and storage?
Nothing.  SOP provides a means to reference and stitch together those
disparate pieces.

One presentation shows a lack of coordination by hypervisor with the
underlying network,
but then just moves the "solution" to the network layer, without showing
how coordination
between the IT and C (network) is sync'd.  Now imagine if those IT
resources are split
across multiple clouds/DCs.  Isolation of network from the IT side could
lead to disconnect
amongst unified ITC service components.  We believe SOP enables a
coordinated solution.

2)  Some quotes from the BOF presentations:
    "OpenFlow does not configure, boot, or maintain a box".
    "Enabling programmatic automation of configuration, management,
     monitoring, data mining, ... is largely orthogonal to OF/SDN"
Well, SOP is there to boot, configure, and maintain the various layers of
those boxes.
It is about replacing slow-time-scale management etc. with on-demand
signaling and control.
Cloud is about provisioning on-demand, in other words configuring and
booting resources
in the Cloud/DC.  So, something missing here.  I get the feeling that
OpenFlow is more like
assembly-language level execution of a macro-command.  With SOP we are
focused on the
macro-command level, within which an admin domain might get implemented by
low-level
openflow execution.

3)  SDN seems to focus on replacing current generation static network
management configuration
versus focusing on the dynamic on-demand external customer aspects.  Would
love to see security
implications on SDN.  I could see an inter-domain SOP request fanning out
to IT (host) and network (SDN)
control signaling components, where the SDN replaces some existing
management controls.
We are trying to address the cloud-bursting scenarios that cross admin
domains.
The last slide of the operator's perspective gives insight to what we want
SOP to address.

4)  Perhaps the best way of explaining this is by analogy.  The essence of
SDN/OF appears to be
the separation of the control plane from the data (forwarding) plane.  So,
where have I heard that before?
Those working in the VoIP space are probably very familiar with the
separation between the
Media Gateway Controller and the Media Gateways using either MGCP or H.248.

Or how about the Media Resource Control Protocol?  Those are examples of
vertical control protocols,
where a master controller manages multiple slave components within a single
admin domain.
Now contrast that with a signaling and control protocol such as SIP or
H.323 that interoperate
horizontally between admin domains.  Just as SIP and MGCP perform
complementary roles for VoIP,
we see SOP and SDN/OF performing complementary roles in the cloud space.

Finally, imagine what cloud services means in terms of delivery of hardware
and software by vendors
to both customer (enterprise) and cloud SP (e.g. carrier) domains.  If the
blade, disk, bridge, and router hardware
can, like a chameleon, take on a different character depending on the
firmware and software layered on top,
then there needs to be a way to remotely provision and configure those
IaaS, PaaS, SaaS software layers,
be it colored Cisco, Juniper, Dell, HP, IBM, Microsoft, Linux, or whatever.

The nature of communications is that it works best when both ends are fully
interoperable.

So, while a private enterprise cloud will need to push an on-demand service
request  to one or more public clouds,
both those clouds may need to "rent" various layers of cloud software
either prior to or following that cloudburst
from multiple players in the vendor community.
A standardized protocol for service orchestration for all those cloud
layers enables that.

We are already seeing such on-demand ecosystems becoming reality in the
Unified Communications space
with the movement of IP-PBXs onto DCs as well as IMS components.

If those can be provided on-demand to meet the capacity needs of the
customer/carrier,
then what stops any other type of cloud software from doing the same?

Mike