Re: [sop] [Sdnp] updated SDN problem statement draft

["Ashish Dalela (adalela)" <[e-mail]>]

Tina, 

 

Late response, just catching up with email backlog. The short answer to your question is “yes”. The long answer is below.

 

SDN in the ONF sense is networking specific. In the SDNP drafts, I have seen compute, storage and security also mentioned as within the scope of SDNP. That makes me think – how are we crossing these domains while still calling this SDN? It has to be a wider definition of SDN where SDN is not limited to networking.

 

The other issue is if SDN is limited to a “device driver” level abstraction of a device as OF portrays it. It may not be. Within a networking device, you can abstract a switch at the level of device driver, RIB, routing protocols or mgmt interfaces. In some cases, all of these may be needed concurrently. I think in most practical cases you need all of them. An example of this is OF-Config which has to define a routing configuration using XML which abstracts on CLI for OF packets to even reach the device. So, you can’t get away with multiple levels anyway.

 

When you want multi-domain and multi-tier SDN, then you need something more generic than what OF is giving today. One of things you will find is the need to separate the transaction pieces from the service pieces. People often say that we can tier separate domain controllers and integrate them at a higher level controller. I don’t think that is trivial. How do you integrate two different domains, unless they speak in the same language?  We need to drive common approaches to reduce complexity.

 

We don’t want to be replacing the horizontal complexity with a vertical complexity. 

 

Thanks, Ashish

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Ping Pan
Sent: Thursday, March 15, 2012 12:20 AM
To: Tina TSOU
Cc: [e-mail]
Subject: Re: [Sdnp] updated SDN problem statement draft

 

Wrong list to ask the question. 

On Wed, Mar 14, 2012 at 11:41 AM, Tina TSOU <[e-mail]> wrote:



Sent from my iPad


On Mar 14, 2012, at 6:27 AM, "Ping Pan" <[e-mail]> wrote:

	On Wed, Mar 14, 2012 at 5:23 AM, Scott Brim <[e-mail]> wrote:

	On Tue, Mar 13, 2012 at 11:48, David Meyer <[e-mail]> wrote:
	> Thanks Ping. Search for dmm> in-line.

	>    Software Defined Network (SDN) is an overlay architecture that
	>    presents the underlying transport network to the applications and
	>    services for monitoring, and provisioning at abstraction level.
	>
	>
	> dmm> Is it true that SDN an overlay architecture, or is this SDN
	> dmm> something different than what is being termed SDN in the
	> dmm> industry? If so maybe we should use a different term?
	
	From a distance I'm still wondering about this group's "SDN" and other
	"SDNs".  This definition doesn't sound like an overlay architecture,
	rather it sounds like element management.

	 

	Yeah, I hear you. Let's forget about ONF SDN, IETF SDN and other flavors of SDN's and names. Let's just focus on its original concept that first advocated by Scott Shenker and others - we may have misinterpreted it quite a bit. However, over the past many months, we keep asking: what is it? why us? how does it really work at engineering level? what business will it serve?

	 

	For a long time, we have been trying to go through all the material, products and use cases that we can get our hands on, and met many who are working in this area. There are a couple of enlighten moments, especially, when I saw the campus deployment in Indiana University. Through the use of routers plus OpenFlow-enabled OEM boxes, the virtual NOC can control and allocate bandwidth to different users. The users can run a totally independent network off servers, and run some very simple applications. The total cost of ownership is tiny, the management of the virtual NOC is getting crazy, but the potential it presents is amazing.  (The guy was telling me that the excitement, the craziness and the unknowns are very much like when we were doing NFSnet :-))

	 

	This "virtual" network is presenting itself with a real engineering challenge to overcome. User registration is a problem. The existing provisioning methodology is way too trivial via OpenFlow, on the other hand, the box itself is dirt cheap. The basic network management, including coordinating network alarms to the virtual users/applications, is not in place. Redundancy and protection - what are they? ;-) Yes, the north-bound API's do not exist in any standard form....

Doesn't SOP do this job?





 

We can call whatever the name we want, but I think this is an area that IETF can address and contribute.

 

Regards,

 

Ping