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

[Ping Pan <[e-mail]>]

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]> 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]>> 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
>