[vnrg] 答复: Re: [Sdnp] High-Level Motivation (Re: one or two blank looks on int-serv reference during the bar bof)//软件定义网络和VNRG
wu.bo@zte.com.cn Tue, 02 August 2011 02:47 UTC
Return-Path: <wu.bo@zte.com.cn>
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 6D97B11E813A; Mon, 1 Aug 2011 19:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.79
X-Spam-Level:
X-Spam-Status: No, score=-93.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, 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 0nszGMEHgYrS; Mon, 1 Aug 2011 19:47:25 -0700 (PDT)
Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2421611E8087; Mon, 1 Aug 2011 19:47:23 -0700 (PDT)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 22013.4236589181; Tue, 2 Aug 2011 10:46:06 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p722jxZX089865; Tue, 2 Aug 2011 10:45:59 +0800 (GMT-8) (envelope-from wu.bo@zte.com.cn)
In-Reply-To: <4E36BE97.4030806@labn.net>
To: Lou Berger <lberger@labn.net>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF8EC1688E.AB1FD814-ON482578E0.000F362C-482578E0.000F3B3C@zte.com.cn>
From: wu.bo@zte.com.cn
Date: Tue, 02 Aug 2011 10:45:57 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-02 10:46:00, Serialize complete at 2011-08-02 10:46:00
Content-Type: multipart/alternative; boundary="=_alternative 000F3B39482578E0_="
X-MAIL: mse01.zte.com.cn p722jxZX089865
Cc: vnrg-bounces@irtf.org, "sdnp@lucidvision.com" <sdnp@lucidvision.com>, "Bitar, Nabil N" <nabil.n.bitar@verizon.com>, Ping Pan <ping@pingpan.org>, VNRG <vnrg@irtf.org>
Subject: [vnrg] 答复: Re: [Sdnp] High-Level Motivation (Re: one or two blank looks on int-serv reference during the bar bof)//软件定义网络和VNRG
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: Tue, 02 Aug 2011 02:47:28 -0000
Lou Berger <lberger@labn.net> ·¢¼þÈË: vnrg-bounces@irtf.org 2011-08-01 22:56 ÊÕ¼þÈË Ping Pan <ping@pingpan.org> ³ËÍ "sdnp@lucidvision.com" <sdnp@lucidvision.com>, "Bitar, Nabil N" <nabil.n.bitar@verizon.com>, VNRG <vnrg@irtf.org> Ö÷Ìâ Re: [vnrg] [Sdnp] High-Level Motivation (Re: one or two blank looks on int-serv reference during the bar bof) 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 ¨C 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 _______________________________________________ vnrg mailing list vnrg@irtf.org https://www.irtf.org/mailman/listinfo/vnrg
- Re: [vnrg] [Sdnp] High-Level Motivation (Re: one … Lou Berger
- Re: [vnrg] [Sdnp] High-Level Motivation (Re: one … Lou Berger
- [vnrg] 答复: Re: [Sdnp] High-Level Motivation (Re: … wu.bo
- Re: [vnrg] [Sdnp] High-Level Motivation (Re: one … David Meyer
- Re: [vnrg] [Sdnp] High-Level Motivation (Re: one … Ping Pan
- Re: [vnrg] [Sdnp] High-Level Motivation (Re: one … Ping Pan