[Sdnp] updated SDN problem statement draft

Zhangfatai zhangfatai at huawei.com
Fri Mar 16 04:39:23 EDT 2012


No need to be so scared, it is coming to us, ☺

The supposed static optical between data centers could be virtualized and the data center providers can manipulate the virtualized network (bandwidth pool) through a kind of interface. This could be one of the scenarios for SDN. By doing that, service providers don’t need to care about the bandwidth from which king of infrastructure (either it is router or OTN). Isn’t it one of the motivations for SDN? ☺



Thanks

Fatai

From: Ping Pan [mailto:ping at pingpan.org]
Sent: 2012年3月15日 20:33
To: Zhangfatai
Cc: Pankaj Shroff; sdnp at lucidvision.com
Subject: Re: [Sdnp] updated SDN problem statement draft

Well, I will be scared of that model. ;-)

I believe that there will be plentiful of cheap bandwidth, especially when transported over optical, but it is utility, just like water and electricity. In itself, bandwidth won't be a type of  service.

However, I do believe that SDN is important in allowing the applications to "get" bandwidth through a simple interface. Like what we have talked about during previous IETF BoF, bandwidth-on-demand is an important application for SDN in our opinion. At the end of the day, the applications just need "pipes" with low latency, reliability and lots of bandwidth. How the bandwidth being provided, L1/L2/L3/L4, is probably secondary, compare with cost.

2 cents,

Ping
On Thu, Mar 15, 2012 at 2:03 AM, Zhangfatai <zhangfatai at huawei.com<mailto:zhangfatai at huawei.com>> wrote:
Hi Ping,

In case of SDN, the situation is more tricky. We have application providers who own the network - they may need to use SDN for internal expansion. We have data center providers who need SND to offer a more flexible interface to the users (IaaS?). We have virtual data center providers who need SDN to make the best use of the underlying networks for new service offering. We have network providers who own data centers who need SDN for better enterprise support...

[Fatai] We have optical providers who may need SDN to make the optical as a service (Let me say OaaS here)  instead of dumb pipe. It is known that the traffic between data centers proliferates very fast, so the optical (with fast, cost-efficient and  huge bandwidth) can be the leverage to provide the value-added pipes to the data center providers. I think this could be amazing and interesting thing for optical providers, ☺

Thanks

Fatai

From: sdnp-bounces at lucidvision.com<mailto:sdnp-bounces at lucidvision.com> [mailto:sdnp-bounces at lucidvision.com<mailto:sdnp-bounces at lucidvision.com>] On Behalf Of Ping Pan
Sent: 2012年3月15日 4:51

To: Pankaj Shroff
Cc: sdnp at lucidvision.com<mailto:sdnp at lucidvision.com>
Subject: Re: [Sdnp] updated SDN problem statement draft

Very good point.

We should think hard about it. To a large degree, the layering issue is not a "pure" technical question. IMHO, this is driven by the business arrangement for the service offering.

You have mentioned ALTO. This is a perfect example how a technical layering serves different purposes depending on the applications. In the context of P2P traffic management, there are at least two models in deployment:

(a) It's owned by the application providers, who would gather network topology information, and update the tracker manager accordingly. The motivation may be that they don't pile up bandwidth cost (or piss off service providers).

(b) It's owned by the network providers to control traffic in/out of their networks. The motivation is to reduce the use of the expensive links.

In case of SDN, the situation is more tricky. We have application providers who own the network - they may need to use SDN for internal expansion. We have data center providers who need SND to offer a more flexible interface to the users (IaaS?). We have virtual data center providers who need SDN to make the best use of the underlying networks for new service offering. We have network providers who own data centers who need SDN for better enterprise support...

Obviously, business drives technology, and the business is evolving. But what we see as a common point is that, at the network layer, everybody wants to have a uniformed way to interface the underlying networks, regardless if it's expensive router network, or cheap disposable OEM boxes, or  somewhere in between. A pipe is a pipe! :-) I think this is where SDN will fit in.

Love to know what you think.

Regards,

Ping

On Wed, Mar 14, 2012 at 12:01 PM, Pankaj Shroff <shroffg at gmail.com<mailto:shroffg at gmail.com>> wrote:
One suggestion is that perhaps it is valuable to consider the existence of such a "platform", "layer", "API" or "controller" in the context of specific vertical applications/services. For example if you take a specific service like Content Delivery or Video Streaming over CDNs, where service provider owns the underlying networking infrastructure, does it make sense to have a "service controller" and then what are the "protocols or APIs" it could/ would/ should exercise in order to orchestrate the underlying elements - whether they are Proxy Server Selection functions (service layer), ALTO servers (SDN layer), Routers (network layer) or Optical transport switches (OTN, ROADM, DWDM, etc.) (Transport layer)? Maybe? Maybe not?

Not necessarily advocating the control/ orchestration of all these elements in every session setup - but just offering a service oriented use case to work off of.

Perhaps there are sufficient use cases like this that could benefit and the SDNP layer could be broad enough to cover those set of "interesting" services.

Pankaj



On Wed, Mar 14, 2012 at 2:50 PM, Ping Pan <ping at pingpan.org<mailto:ping at pingpan.org>> wrote:
Wrong list to ask the question.

On Wed, Mar 14, 2012 at 11:41 AM, Tina TSOU <Tina.Tsou.Zouting at huawei.com<mailto:Tina.Tsou.Zouting at huawei.com>> wrote:


Sent from my iPad

On Mar 14, 2012, at 6:27 AM, "Ping Pan" <ping at pingpan.org<mailto:ping at pingpan.org>> wrote:
On Wed, Mar 14, 2012 at 5:23 AM, Scott Brim <scott.brim at gmail.com<mailto:scott.brim at gmail.com>> wrote:
On Tue, Mar 13, 2012 at 11:48, David Meyer <dmm at 1-4-5.net<mailto:dmm at 1-4-5.net>> 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


_______________________________________________
SDNP mailing list
SDNP at lucidvision.com<mailto:SDNP at lucidvision.com>
http://lucidvision.com/mailman/listinfo/sdnp



--
Pankaj Shroff
shroffG at Gmail.com

_______________________________________________
SDNP mailing list
SDNP at lucidvision.com<mailto:SDNP at lucidvision.com>
http://lucidvision.com/mailman/listinfo/sdnp


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lucidvision.com/pipermail/sdnp/attachments/20120316/0e57ea48/attachment-0001.htm>


More information about the SDNP mailing list