[Sdnp] updated SDN problem statement draft

Thu Mar 15 09:38:58 EDT 2012

Tom - I would tend to agree. But before that, I want to make sure I understand what you meant. There are WGs in the IETF focused on technologies and frameworks that support various kinds of services. I tend to agree that there is tremendous value in collaborating across WGs. A middleware layer as the one that is being proposed here has the risk of quickly becoming (or wanting to become) all encompassing and therefore impractical. Instead if under the auspices of another WG charter that focuses on a service - some benefits and mechanisms can be identified that apply explicitly to that charter, then work in this category can fit there instead. The risk then is that the same process must be repeated when a second use case and third and so on is discovered where similar benefits are applicable to other WG charters. Not sure if there is a perfect answer. 

Did I interpret that correctly?

Pankaj

Sent from my iPhone
twitter: @chompi

On Mar 14, 2012, at 16:56, Thomas Nadeau <tnadeau at lucidvision.com> wrote:

> 
> On Mar 14, 2012, at 4:50 PM, Ping Pan wrote:
> 
>> 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.
> 
> 	This leads us back to the list of items that can be accomplished by any potential WG: the architecture and framework.  These are valuable in that they show how the "lego blocks" can be assembled in a way that works.  This can also drive work done in other WGs to work within this framework and architecture, as well as the work we can do in this area.
> 
> 	--Tom
> 
> 
> 
>> 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> 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> wrote:
>> Wrong list to ask the question. 
>> 
>> 
>> On Wed, Mar 14, 2012 at 11:41 AM, Tina TSOU <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> wrote:
>> 
>>> On Wed, Mar 14, 2012 at 5:23 AM, Scott Brim <scott.brim at gmail.com> wrote:
>>> On Tue, Mar 13, 2012 at 11:48, David Meyer <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
>> http://lucidvision.com/mailman/listinfo/sdnp
>> 
>> 
>> 
>> 
>> -- 
>> Pankaj Shroff
>> shroffG at Gmail.com
>> 
>> _______________________________________________
>> SDNP mailing list
>> SDNP at lucidvision.com
>> http://lucidvision.com/mailman/listinfo/sdnp
>> 
>> 
>> _______________________________________________
>> SDNP mailing list
>> SDNP at lucidvision.com
>> http://lucidvision.com/mailman/listinfo/sdnp
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lucidvision.com/pipermail/sdnp/attachments/20120315/cad499e5/attachment.htm>