Re: [vnrg] [Sdnp] High-Level Motivation (Re: one or two blank looks on int-serv reference during the bar bof)

[David Meyer <[e-mail]>]

On Mon, Aug 1, 2011 at 7:56 AM, Lou Berger <[e-mail]> wrote:
> Ping,
>        Nice intro/overview.  So how does this effort relate to the VNRG
> (http://irtf.org/vnrg, also cross-posted)?  Seems to me that there is a
> fair bit of overlap.

I would say that virtualization is a "feature" you can build out of
SDN. SDN is a more general
concept, however.
http://www.slideshare.net/martin_casado/sdn-abstractions has a nice
description of
what SDN is/could be.

Dave


> Thanks,
> Lou
>
> On 8/1/2011 10:42 AM, Ping Pan wrote:
>> Hi,
>>
>> You have raised a very critical question here. During IETF and over the
>> weekend, several have asked off-line about our motivation. Are we doing
>> RSVP, UNI, GENI, bandwidth broker etc.?
>>
>> So allow me to explain our thinking and motivation at very high level here:
>>
>> (1) Why?
>>
>> Many of us have been a part of the Internet creation and deployment in
>> the past many years. It has become something more than we had dreamed
>> for better or for worse. While we were squeezing the last bit of
>> inefficiency out of routing, forwarding and policing, the new
>> applications have emerged and proliferated. While we were designing the
>> interface between transport, packet, broadband and wireless networks,
>> the new services have been created and deployed simply over the
>> underlying networks. While we were optimizing the use of bandwidth and
>> processing on our hardware, the Moore's Law has made all parts of the
>> network less expensive each day. This is the way it is!
>>
>> The interface between application and network has been an interesting
>> area: We have seen the approach in closing the network and enforcing
>> tighter control over users within a walled garden (good luck!). We have
>> also seen the attempts in pushing the traditional network
>> operation methodology into applications (yuk!)
>>
>> My belief is that we should open up the network, embrace
>> new applications and provide simpler and easier interface to the users.
>> The value of the network is in attracting more traffic, more users and
>> more applications, not in creating more middlemen.
>>
>> Many have been saying that network should be a "dumb pipe". True and
>> false. It's true that, as far as users are concerned, any link between
>> two network endpoints should be predictable and reliable as a simple
>> wire. At the same time, the network needs to be pretty smart in making
>> the interface dumb.
>>
>> Today, we can create connections at any layer, at any rate, in any
>> format, with any property and in any granularity inside the network. Our
>> motivation here is in making the network connections visible and
>> programmable to the applications.
>>
>> (2) Why us?
>>
>> For a long time, Web and network technologies have been developed
>> in parallel. However, the recent demand in data centers requires
>> the massive web transaction and the heavy network transport taking place
>> within a few hundred feet. Web operation, driven by massive parallel
>> processing and massive content replication, demands simple and cheaper
>> network support. To date, no network port is faster enough, and no
>> application-network operation is efficient enough.
>>
>> I believe that the network technology needs to scale up
>> and accommodate the demand from the applications. We need to make our
>> network simpler, easier and more efficient. (Yes, we say this every time
>> when we start a new project, the outcome is always contradicting. But,
>> we try anyway! ;-))
>>
>> We envision to create programmable network API's, by adapting both
>> networking and application techniques. We will leverage the existing
>> networking technologies, designed and defined in IETF, to create,
>> monitor and discover network resources, services and connections. And we
>> will leverage the scalable and secure message processing capability from
>> Web (or over port-80) for API's.
>>
>> (3) Examples (be more specific)
>>
>> Network programmability applies in many places, and we see a few
>> applications need to be solved real fast.
>>
>> First, the VM network interface is VLAN. As such, any VM network-level
>> service manipulation need to be accomplished through the management at
>> VLAN-granularity.
>>
>> For example, if VM applications require non-disruptive services, the
>> service operators may map the VM's to the network links with bandwidth,
>> delay and protection constraints, by utilizing MPLS and FRR to achieve
>> network-wide support.
>>
>> Another example is in supporting enterprise VPN's. In this scenario, the
>> service operators may bundle the relevant VM's to the corresponding MPLS
>> VPN's. All the techniques defined in IETF can be readily used to support
>> VM mobility and service security here.
>>
>> Another area we need to to look at is in the area of video/media
>> services. OTT video services will likely store the content on the data
>> centers, and utilize local CDN's for delivery (take a look at Netflix).
>> The content may be replicated from data center to data center, and CDN's
>> may utilize different distribute techniques. However, the service
>> operators may map the (logical) content to the actual distribution
>> engines with service guarantees. I know some of the work has
>> been discussed in ALTO, so let's work together there.
>>
>> Service monitoring is another important aspect of the work. Each web
>> service is supported by many back-end applications, which may operated
>> in different locations. To have a robust service, the service operators
>> need to have a way to monitor and guarantee network-services to those
>> services.
>>
>> In summary, we envision SDN work to bridge the gap between the
>> applications and the network. In the future, we may address
>> inter-networking concerns. However, much of the networking-level work
>> can be solved with a better OSS. I'd prefer to solve the
>> application-network interfacing issues first.
>>
>>
>> (4) Next Steps
>>
>> I have an old-school when it comes to this: running code and rough
>> consensus!
>>
>> In the coming weeks, we would like to collect more use cases,
>> collaborate with many, learn from each other. At the end, we should put
>> together the architecture, protocol design and hopefully some prototypes.
>>
>> Hope this makes sense.
>>
>> Best regards,
>>
>> - Ping
>>
>>
>> On Wed, Jul 27, 2011 at 2:32 PM, Bitar, Nabil N
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>
>>     I think during the meeting a good spectrum of use cases was
>>     discussed raging from data center type applications to the case of
>>     inter-provider connection setup or policy transfer.  It seems that
>>     there is a need to put down the use cases on paper and see what
>>     existing mechanisms can be used to address these use cases and why
>>     there is new work needed. Is it fresh new work or extensions to
>>     existing mechanisms?  What are the gaps  in what exists is being
>>     solved? It is not clear to me that there is one hammer that will be
>>     able to address all the use cases , and if needed, without
>>     recreating the wheel or adding complexities or deficiencies  That
>>     may be biased by the view I had walking into the meeting that there
>>     was tendency to focus on the interface between the application and
>>     the SDN controller  to request resources maybe subject to
>>      constraints, to receive information, response to a request and/or
>>     notification  from the SDN controller. What the SDN controller does
>>     may capitalize on existing mechanisms which will be dependent on the
>>     use case and the nature of the application request.  While the
>>     interface can be generic  and extensible, the use case or
>>     application will drive what information is exchanged.
>>     I appreciate a clarification if all the the following still at play
>>     here or something was pruned out or too early to prune:
>>
>>        1. application -SDN controller interface. What is the function of
>>           that interface is going to be application dependent. That goes
>>           for other interfaces
>>        2. SDN controller-SDN interface
>>        3. SDN controller-SDN controller interface
>>        4. Path computation (not necessarily TE ) for a tunnel or
>>           microflow based on certain constraints.
>>        5. flow mapping to a path, including flow classification and
>>           configuration on every hop.
>>
>>     Thanks,
>>     Nabil
>>     From: Thomas Nadeau <[e-mail]
>>     <mailto:[e-mail]>>
>>     Date: Wed, 27 Jul 2011 11:29:20 -0400
>>     To: "Ong, Lyndon" <[e-mail] <mailto:[e-mail]>>
>>     Cc: "[e-mail] <mailto:[e-mail]>"
>>     <[e-mail] <mailto:[e-mail]>>
>>
>>     Subject: Re: [Sdnp] one or two blank looks on int-serv reference
>>     during the bar bof
>>
>>
>>
>>
>>
>>     On Jul 27, 2011, at 11:15 AM, "Ong, Lyndon" <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>>     Hi Guys,____
>>>
>>>     __ __
>>>
>>>     Regarding (2), if we’re agnostic then this work seems to be more
>>>     general, it could apply to OF-controlled networks,
>>>     MPLS/GMPLS-controlled networks, PCE/non-PCE, etc.____
>>>
>>>     __ __
>>>
>>>     Regarding (3) not sure that this follows – in a lot of the control
>>>     plane technologies there is a way to control the path.  Question,
>>>     though, how much does an application need to know about the path?
>>>
>>
>>     I think that depends on what the application is and what it's
>>     purpose is. It may be interested in network resources other than
>>     just links and paths. Also, as Danny mentioned in his use case
>>     yesterday there is a need for varying levels of granularity here.
>>
>>     Tom
>>
>>>     ____
>>>
>>>     __ __
>>>
>>>     Cheers,____
>>>
>>>     __ __
>>>
>>>     Lyndon____
>>>
>>>     __ __
>>>
>>>     BTW, the comparison to intserv reminds me that when I try to
>>>     explain OF to people, they commonly ask why this is different from
>>>     FORCES!____
>>>
>>>     __ __
>>>
>>>
>>>     <imageb58e9e.gif@b6446a3d.24d4497b
>>>     <mailto:imageb58e9e.gif@b6446a3d.24d4497b>>
>>>
>>>     *From:* [e-mail]
>>>     <mailto:[e-mail]>
>>>     [mailto:[e-mail]] *On Behalf Of *Edward Crabbe
>>>     *Sent:* Wednesday, July 27, 2011 7:23 AM
>>>     *To:* Ping Pan
>>>     *Cc:* <mailto:[e-mail]>[e-mail]
>>>     <mailto:[e-mail]>
>>>     *Subject:* Re: [Sdnp] one or two blank looks on int-serv reference
>>>     during the bar bof____
>>>
>>>     __ __
>>>
>>>     __ __
>>>
>>>         Our goal here is to solve a specific problem: map application
>>>         flows (in whatever the form) into physical network tunnels.____
>>>
>>>         __ __
>>>
>>>     __ __
>>>
>>>     three things here: ____
>>>
>>>     __ __
>>>
>>>     1) so basically, you're saying you want a common language to
>>>      build a FEC, mapping a set of n-tuple matches (vlan, whatever)
>>>     into a specific encapsulation?____
>>>
>>>     __ __
>>>
>>>     2) are these tunnels pre-existing?  if so, fine, if not, we now
>>>     have to set up the tunnel, at which point we're back to dealing
>>>     with either OF type per hop state setup or an existing end to
>>>     end signaling protocol (and  we're dealing with things at a per
>>>     host, app level?  Thus the  int-serv reference ;-).  Perhaps the
>>>     idea is to be agnostic regarding path setup method here?____
>>>
>>>     __ __
>>>
>>>     3) would this also imply that that definition of the
>>>     characteristics, including path,  that the tunnel takes over the
>>>     underlying infrastructure is in scope?____
>>>
>>>     __ __
>>>
>>>      ____
>>>
>>>         No need in limiting applications, and no need in making
>>>         network smarter (or dumber). ;-)
>>>         ____
>>>
>>>         __ __
>>>
>>>         Thanks!____
>>>
>>>         __ __
>>>
>>>         - Ping
>>>
>>>         ____
>>>
>>>         On Tue, Jul 26, 2011 at 7:28 PM, Edward Crabbe <
>>>         <mailto:[e-mail]>[e-mail] <mailto:[e-mail]>>
>>>         wrote:____
>>>
>>>             for reference, was referring to:____
>>>
>>>             __ __
>>>
>>>             <http://tools.ietf.org/rfc/rfc2210.txt>http://tools.ietf.org/rfc/rfc2210.txt____
>>>
>>>             __ __
>>>
>>>             __ __
>>>
>>>             __ __
>>>
>>>             _______________________________________________
>>>             SDNP mailing list
>>>             <mailto:[e-mail]>[e-mail]
>>>             <mailto:[e-mail]>
>>>             <http://lucidvision.com/mailman/listinfo/sdnp>http://lucidvision.com/mailman/listinfo/sdnp____
>>>
>>>         __ __
>>>
>>>     __ __
>>>
>>>
>>>     _______________________________________________
>>>     SDNP mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     http://lucidvision.com/mailman/listinfo/sdnp
>>
>>     _______________________________________________
>>     SDNP mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     http://lucidvision.com/mailman/listinfo/sdnp
>>
>>
>>
>>
>> _______________________________________________
>> SDNP mailing list
>> [e-mail]
>> http://lucidvision.com/mailman/listinfo/sdnp
> _______________________________________________
> SDNP mailing list
> [e-mail]
> http://lucidvision.com/mailman/listinfo/sdnp
>