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

[Lou Berger <[e-mail]>]

> The goal is having the applications programming the network, without
> breaking it.

So you're saying the objective is an API to a VN, right?

> This is not research, and we have no intention in forcing applications
> to adapt network-operation semantics.

It still seems like the same problem space to me, but the difference
is/may be in objectives.  You want a concrete solution while that isn't
a specific VNRG objective.

In other words, you want the work in *E* not *R*, right?

Lou

On 8/1/2011 10:58 AM, Ping Pan wrote:
> This is not research, and we have no intention in forcing applications
> to adapt network-operation semantics.
> 
> The goal is having the applications programming the network, without
> breaking it.
> 
> - Ping
> 
> 
> On Mon, Aug 1, 2011 at 10:56 AM, Lou Berger <[e-mail]
> <mailto:[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.
> 
>     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]>
>     <mailto:[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]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>>
>     >     Date: Wed, 27 Jul 2011 11:29:20 -0400
>     >     To: "Ong, Lyndon" <[e-mail] <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>     >     Cc: "[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>"
>     >     <[e-mail] <mailto:[e-mail]>
>     <mailto:[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] <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
>     <mailto:imageb58e9e.gif@b6446a3d.24d4497b>>>
>     >>
>     >>     *From:* [e-mail]
>     <mailto:[e-mail]>
>     >>     <mailto:[e-mail]
>     <mailto:[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]
>     <mailto:[e-mail]>>[e-mail]
>     <mailto:[e-mail]>
>     >>     <mailto:[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]
>     <mailto:[e-mail]>>[e-mail] <mailto:[e-mail]>
>     <mailto:[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]
>     <mailto:[e-mail]>>[e-mail]
>     <mailto:[e-mail]>
>     >>             <mailto:[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]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >>     http://lucidvision.com/mailman/listinfo/sdnp
>     >
>     >     _______________________________________________
>     >     SDNP mailing list
>     >     [e-mail] <mailto:[e-mail]>
>     <mailto:[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
> 
>