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

Lou Berger <lberger@labn.net> Mon, 01 August 2011 20:22 UTC

Return-Path: <lberger@labn.net>
X-Original-To: vnrg@ietfa.amsl.com
Delivered-To: vnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4845C21F8B20 for <vnrg@ietfa.amsl.com>; Mon, 1 Aug 2011 13:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.031
X-Spam-Level:
X-Spam-Status: No, score=-102.031 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKRprczz6yTx for <vnrg@ietfa.amsl.com>; Mon, 1 Aug 2011 13:22:52 -0700 (PDT)
Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by ietfa.amsl.com (Postfix) with SMTP id 05D0021F8B14 for <vnrg@irtf.org>; Mon, 1 Aug 2011 13:22:51 -0700 (PDT)
Received: (qmail 4463 invoked by uid 0); 1 Aug 2011 14:56:19 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy3.bluehost.com with SMTP; 1 Aug 2011 14:56:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=l/YXv2eljsaLGv+pOH2HXRYdY6yVKx8SDrpFbE+I1Ko=; b=b6HsVyJ+jnr+hSQOz2xnSQMJFaJkycpJjB/YqnDf9siLbGjRIh+TwD8E26W3DHVIhPV+3lfRFZD9Tpkk++QJ1ooixJ+Q6LiBxcHnqCRSjPxda92Tc0mkEag7jPyJDSE4;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1Qntul-0001Lk-1Y; Mon, 01 Aug 2011 08:56:19 -0600
Message-ID: <4E36BE97.4030806@labn.net>
Date: Mon, 01 Aug 2011 10:56:23 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Ping Pan <ping@pingpan.org>
References: <CAHEV9L3avPiHVjBtttTL_7VbNeJ=Q=oegot2A_m8snN5vzNsgA@mail.gmail.com>
In-Reply-To: <CAHEV9L3avPiHVjBtttTL_7VbNeJ=Q=oegot2A_m8snN5vzNsgA@mail.gmail.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "sdnp@lucidvision.com" <sdnp@lucidvision.com>, "Bitar, Nabil N" <nabil.n.bitar@verizon.com>, VNRG <vnrg@irtf.org>
Subject: Re: [vnrg] [Sdnp] High-Level Motivation (Re: one or two blank looks on int-serv reference during the bar bof)
X-BeenThere: vnrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Virtual Networks Research Group \(VNRG\) discussion list" <vnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/vnrg>, <mailto:vnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/vnrg>
List-Post: <mailto:vnrg@irtf.org>
List-Help: <mailto:vnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/vnrg>, <mailto:vnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 20:22:53 -0000

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
> <nabil.n.bitar@verizon.com <mailto:nabil.n.bitar@verizon.com>> 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 <tnadeau@lucidvision.com
>     <mailto:tnadeau@lucidvision.com>>
>     Date: Wed, 27 Jul 2011 11:29:20 -0400
>     To: "Ong, Lyndon" <Lyong@Ciena.com <mailto:Lyong@Ciena.com>>
>     Cc: "sdnp@lucidvision.com <mailto:sdnp@lucidvision.com>"
>     <sdnp@lucidvision.com <mailto:sdnp@lucidvision.com>>
> 
>     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" <Lyong@Ciena.com
>     <mailto:Lyong@Ciena.com>> 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:* sdnp-bounces@lucidvision.com
>>     <mailto:sdnp-bounces@lucidvision.com>
>>     [mailto:sdnp-bounces@lucidvision.com] *On Behalf Of *Edward Crabbe
>>     *Sent:* Wednesday, July 27, 2011 7:23 AM
>>     *To:* Ping Pan
>>     *Cc:* <mailto:sdnp@lucidvision.com>sdnp@lucidvision.com
>>     <mailto:sdnp@lucidvision.com>
>>     *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:edc@google.com>edc@google.com <mailto:edc@google.com>>
>>         wrote:____
>>
>>             for reference, was referring to:____
>>
>>             __ __
>>
>>             <http://tools.ietf.org/rfc/rfc2210.txt>http://tools.ietf.org/rfc/rfc2210.txt____
>>
>>             __ __
>>
>>             __ __
>>
>>             __ __
>>
>>             _______________________________________________
>>             SDNP mailing list
>>             <mailto:SDNP@lucidvision.com>SDNP@lucidvision.com
>>             <mailto:SDNP@lucidvision.com>
>>             <http://lucidvision.com/mailman/listinfo/sdnp>http://lucidvision.com/mailman/listinfo/sdnp____
>>
>>         __ __
>>
>>     __ __
>>
>>
>>     _______________________________________________
>>     SDNP mailing list
>>     SDNP@lucidvision.com <mailto:SDNP@lucidvision.com>
>>     http://lucidvision.com/mailman/listinfo/sdnp
> 
>     _______________________________________________
>     SDNP mailing list
>     SDNP@lucidvision.com <mailto:SDNP@lucidvision.com>
>     http://lucidvision.com/mailman/listinfo/sdnp
> 
> 
> 
> 
> _______________________________________________
> SDNP mailing list
> SDNP@lucidvision.com
> http://lucidvision.com/mailman/listinfo/sdnp