From vumip1@gmail.com  Mon Aug  1 07:13:52 2011
Return-Path: <vumip1@gmail.com>
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 1B95721F8D6F for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 07:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_LOW=-1]
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 bKvUAmvJBY-q for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 07:13:51 -0700 (PDT)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7E53221F8D70 for <vnrg@irtf.org>; Mon,  1 Aug 2011 07:13:48 -0700 (PDT)
Received: by pzk2 with SMTP id 2so12289987pzk.9 for <vnrg@irtf.org>; Mon, 01 Aug 2011 07:13:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=WJsW6hP9V14kbYWc59hZPcAo2oibJ1HUJDYOfyuIdu4=; b=vYY9HyuvC3811Nh9GkjU5Qcbi0khMZJ96086A+Ev+pw7z7S75IVPZuMSixcrN5FlGY 5i9FYuTyffY/GXva/BqTxgUvnxwO+FUD2WsePpHFBRD2fgykDADs24aj4dezT7GjlUSt xrWcxQRaCk1fRMQN9wT+CJfO3XHVZzooMsl+Q=
MIME-Version: 1.0
Received: by 10.68.25.162 with SMTP id d2mr7573068pbg.372.1312208033822; Mon, 01 Aug 2011 07:13:53 -0700 (PDT)
Received: by 10.68.66.1 with HTTP; Mon, 1 Aug 2011 07:13:53 -0700 (PDT)
Date: Mon, 1 Aug 2011 10:13:53 -0400
Message-ID: <CANtnpwhQf7e2i=wEQr-jEsGFqkgfz+mTqRAiiZtibkmc+jzgTg@mail.gmail.com>
From: Bhumip Khasnabish <vumip1@gmail.com>
To: vnrg@irtf.org
Content-Type: multipart/alternative; boundary=bcaec5215d57ba361804a9723d12
Subject: [vnrg] inviting discussion on NaaS
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 14:13:52 -0000

--bcaec5215d57ba361804a9723d12
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Dear All,

We would like to initiate a discussion on

(A) Definition of, and

(B) Expectations from NaaS

based on our preso on NaaS during VNRG mtg. in IETE-81 (Quebec, 29July2011)=
.


Thanks a lot.

Best.

Bhumip Khasnabish
vumip1@gmail.com
bhumip.khasnabish@zteusa.com
+1-781-752-8003 (mobile)
http://www.linkedin.com/in/bhumipkhasnabish

                   __o
             _ `\ <, _
.......... ( =95 ) / ( =95 ) ......................
--

--bcaec5215d57ba361804a9723d12
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div><br clear=3D"all">Dear All,<br>=A0<br>We would like to initiate a disc=
ussion on=A0 <br>=A0<br>(A) Definition of, and <br>=A0<br>(B) Expectations =
from NaaS<br>=A0<br>based on our preso on NaaS during VNRG mtg. in IETE-81 =
(Quebec, 29July2011).</div>

<div><br>=A0<br>Thanks a lot.</div>
<p>Best.</p>
<p>Bhumip Khasnabish<br><a href=3D"mailto:vumip1@gmail.com" target=3D"_blan=
k">vumip1@gmail.com</a> <br><a href=3D"mailto:bhumip.khasnabish@zteusa.com"=
 target=3D"_blank">bhumip.khasnabish@zteusa.com</a>=A0 <br><a href=3D"tel:%=
2B1-781-752-8003" target=3D"_blank" value=3D"+17817528003">+1-781-752-8003<=
/a> (mobile) <br>
<a href=3D"http://www.linkedin.com/in/bhumipkhasnabish" target=3D"_blank">h=
ttp://www.linkedin.com/in/bhumipkhasnabish</a>=A0 </p>
<p>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __o<br>=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 _ `\ &lt;, _<br>.......... ( =95 ) / ( =95 ) ..=
....................<br>-- <br></p>
<div>=A0</div>

--bcaec5215d57ba361804a9723d12--

From lberger@labn.net  Mon Aug  1 08:07:55 2011
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 95F0E11E80BB for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 08:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.035
X-Spam-Level: 
X-Spam-Status: No, score=-102.035 tagged_above=-999 required=5 tests=[AWL=0.230, 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 nvNbFDOR4leq for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 08:07:54 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id EF0D511E8090 for <vnrg@irtf.org>; Mon,  1 Aug 2011 08:07:53 -0700 (PDT)
Received: (qmail 3395 invoked by uid 0); 1 Aug 2011 15:07:54 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 1 Aug 2011 15:07:54 -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=EpUqxREQuzsz5hET3kZBAvUN4ZjIdRY5XXyKDukLF3M=;  b=fLFBDVYWvwhXVSD9fCNZDShVpwK164fg4y8ypKMabDQH95RMVotkTyeqOBDFEd0FIV3Zv1/TDw1zj9n7BORRzYf0rc8KF5W+/eviVsVnPImODjw1XuImwd2phYQZE1zV;
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 1Qnu5y-0006B6-DG; Mon, 01 Aug 2011 09:07:54 -0600
Message-ID: <4E36C14E.6080909@labn.net>
Date: Mon, 01 Aug 2011 11:07:58 -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> <4E36BE97.4030806@labn.net> <CAHEV9L2=F+GkyE_JBUXehR6CpuHeZg7RKzM0qwN3DLOgfZh=6A@mail.gmail.com>
In-Reply-To: <CAHEV9L2=F+GkyE_JBUXehR6CpuHeZg7RKzM0qwN3DLOgfZh=6A@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 15:07:55 -0000

> 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 <lberger@labn.net
> <mailto:lberger@labn.net>> 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
>     > <nabil.n.bitar@verizon.com <mailto:nabil.n.bitar@verizon.com>
>     <mailto: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>
>     >     <mailto: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
>     <mailto:Lyong@Ciena.com>>>
>     >     Cc: "sdnp@lucidvision.com <mailto:sdnp@lucidvision.com>
>     <mailto:sdnp@lucidvision.com <mailto:sdnp@lucidvision.com>>"
>     >     <sdnp@lucidvision.com <mailto:sdnp@lucidvision.com>
>     <mailto: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 <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
>     <mailto:imageb58e9e.gif@b6446a3d.24d4497b>>>
>     >>
>     >>     *From:* sdnp-bounces@lucidvision.com
>     <mailto:sdnp-bounces@lucidvision.com>
>     >>     <mailto:sdnp-bounces@lucidvision.com
>     <mailto: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
>     <mailto:sdnp@lucidvision.com>>sdnp@lucidvision.com
>     <mailto:sdnp@lucidvision.com>
>     >>     <mailto: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
>     <mailto:edc@google.com>>edc@google.com <mailto:edc@google.com>
>     <mailto: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
>     <mailto:SDNP@lucidvision.com>>SDNP@lucidvision.com
>     <mailto:SDNP@lucidvision.com>
>     >>             <mailto: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>
>     <mailto:SDNP@lucidvision.com <mailto:SDNP@lucidvision.com>>
>     >>     http://lucidvision.com/mailman/listinfo/sdnp
>     >
>     >     _______________________________________________
>     >     SDNP mailing list
>     >     SDNP@lucidvision.com <mailto:SDNP@lucidvision.com>
>     <mailto: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
> 
> 

From gfortaine@live.com  Mon Aug  1 10:44:15 2011
Return-Path: <gfortaine@live.com>
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 7F12211E810D for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 10:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 hz8PyOa5KCFZ for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 10:44:14 -0700 (PDT)
Received: from blu0-omc2-s3.blu0.hotmail.com (blu0-omc2-s3.blu0.hotmail.com [65.55.111.78]) by ietfa.amsl.com (Postfix) with ESMTP id A1CD511E8114 for <vnrg@irtf.org>; Mon,  1 Aug 2011 10:44:14 -0700 (PDT)
Received: from BLU135-W17 ([65.55.111.71]) by blu0-omc2-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 1 Aug 2011 10:44:17 -0700
Message-ID: <BLU135-W17443EE3A86BCE732EBD62C8380@phx.gbl>
X-Originating-IP: [83.198.123.176]
From: Guillaume FORTAINE <gfortaine@live.com>
To: <vnrg@irtf.org>
Date: Mon, 1 Aug 2011 19:44:17 +0200
Importance: Normal
In-Reply-To: <CANtnpwhQf7e2i=wEQr-jEsGFqkgfz+mTqRAiiZtibkmc+jzgTg@mail.gmail.com>
References: <CANtnpwhQf7e2i=wEQr-jEsGFqkgfz+mTqRAiiZtibkmc+jzgTg@mail.gmail.com>
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Aug 2011 17:44:17.0154 (UTC) FILETIME=[A29C2E20:01CC5072]
Subject: Re: [vnrg] inviting discussion on NaaS
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 17:44:15 -0000

Hello=2C

For your information :

http://wiki.openstack.org/NetworkService

Best Regards=2C

Guillaume FORTAINE
+33(0)6.319.092.519
gfortaine@gfortaine.biz

________________________________
> Date: Mon=2C 1 Aug 2011 10:13:53 -0400=20
> From: vumip1@gmail.com=20
> To: vnrg@irtf.org=20
> Subject: [vnrg] inviting discussion on NaaS=20
> =20
> =20
> Dear All=2C=20
> =20
> We would like to initiate a discussion on=20
> =20
> (A) Definition of=2C and=20
> =20
> (B) Expectations from NaaS=20
> =20
> based on our preso on NaaS during VNRG mtg. in IETE-81 (Quebec=2C 29July2=
011).=20
> =20
> =20
> Thanks a lot.=20
> =20
> Best.=20
> =20
> Bhumip Khasnabish=20
> vumip1@gmail.com<mailto:vumip1@gmail.com>=20
> bhumip.khasnabish@zteusa.com<mailto:bhumip.khasnabish@zteusa.com>=20
> +1-781-752-8003 (mobile)=20
> http://www.linkedin.com/in/bhumipkhasnabish=20
> =20
>                     __o=20
>               _ `\ <=2C _=20
> .......... ( =95 ) / ( =95 ) ......................=20
> -- =20
> =20
> =20
> =20
> _______________________________________________ vnrg mailing list =20
> vnrg@irtf.org https://www.irtf.org/mailman/listinfo/vnrg=20
 		 	   		  =

From lberger@labn.net  Mon Aug  1 13:22:53 2011
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

From wu.bo@zte.com.cn  Mon Aug  1 19:47:28 2011
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, 2 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] =?gb2312?b?tPC4tDogUmU6ICBbU2RucF0gSGlnaC1MZXZlbCBNb3Rp?= =?gb2312?b?dmF0aW9uIChSZTogb25lIG9yIHR3byBibGFuayBsb29rcyBvbiBpbnQtc2Vy?= =?gb2312?b?diByZWZlcmVuY2UgZHVyaW5nIHRoZSBiYXIgYm9mKS8vyO28/rao0uXN+MLn?= =?gb2312?b?us1WTlJH?=
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

This is a multipart message in MIME format.
--=_alternative 000F3B39482578E0_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

TG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gDQq3orz+yMs6ICB2bnJnLWJvdW5jZXNAaXJ0
Zi5vcmcNCjIwMTEtMDgtMDEgMjI6NTYNCg0KytW8/sjLDQpQaW5nIFBhbiA8cGluZ0BwaW5ncGFu
Lm9yZz4NCrOty80NCiJzZG5wQGx1Y2lkdmlzaW9uLmNvbSIgPHNkbnBAbHVjaWR2aXNpb24uY29t
PiwgIkJpdGFyLCAgTmFiaWwgTiIgDQo8bmFiaWwubi5iaXRhckB2ZXJpem9uLmNvbT4sIFZOUkcg
PHZucmdAaXJ0Zi5vcmc+DQrW98ziDQpSZTogW3ZucmddIFtTZG5wXSBIaWdoLUxldmVsIE1vdGl2
YXRpb24gKFJlOiBvbmUgb3IgdHdvIGJsYW5rIGxvb2tzIG9uIA0KaW50LXNlcnYgcmVmZXJlbmNl
IGR1cmluZyB0aGUgYmFyIGJvZikNCg0KDQoNCg0KDQoNClBpbmcsDQogICAgICAgICAgICAgICAg
IE5pY2UgaW50cm8vb3ZlcnZpZXcuICBTbyBob3cgZG9lcyB0aGlzIGVmZm9ydCByZWxhdGUgdG8g
DQp0aGUgVk5SRw0KKGh0dHA6Ly9pcnRmLm9yZy92bnJnLCBhbHNvIGNyb3NzLXBvc3RlZCk/ICBT
ZWVtcyB0byBtZSB0aGF0IHRoZXJlIGlzIGENCmZhaXIgYml0IG9mIG92ZXJsYXAuDQoNClRoYW5r
cywNCkxvdQ0KDQpPbiA4LzEvMjAxMSAxMDo0MiBBTSwgUGluZyBQYW4gd3JvdGU6DQo+IEhpLA0K
PiANCj4gWW91IGhhdmUgcmFpc2VkIGEgdmVyeSBjcml0aWNhbCBxdWVzdGlvbiBoZXJlLiBEdXJp
bmcgSUVURiBhbmQgb3ZlciB0aGUNCj4gd2Vla2VuZCwgc2V2ZXJhbCBoYXZlIGFza2VkIG9mZi1s
aW5lIGFib3V0IG91ciBtb3RpdmF0aW9uLiBBcmUgd2UgZG9pbmcNCj4gUlNWUCwgVU5JLCBHRU5J
LCBiYW5kd2lkdGggYnJva2VyIGV0Yy4/DQo+IA0KPiBTbyBhbGxvdyBtZSB0byBleHBsYWluIG91
ciB0aGlua2luZyBhbmQgbW90aXZhdGlvbiBhdCB2ZXJ5IGhpZ2ggbGV2ZWwgDQpoZXJlOg0KPiAN
Cj4gKDEpIFdoeT8NCj4gDQo+IE1hbnkgb2YgdXMgaGF2ZSBiZWVuIGEgcGFydCBvZiB0aGUgSW50
ZXJuZXQgY3JlYXRpb24gYW5kIGRlcGxveW1lbnQgaW4NCj4gdGhlIHBhc3QgbWFueSB5ZWFycy4g
SXQgaGFzIGJlY29tZSBzb21ldGhpbmcgbW9yZSB0aGFuIHdlIGhhZCBkcmVhbWVkDQo+IGZvciBi
ZXR0ZXIgb3IgZm9yIHdvcnNlLiBXaGlsZSB3ZSB3ZXJlIHNxdWVlemluZyB0aGUgbGFzdCBiaXQg
b2YNCj4gaW5lZmZpY2llbmN5IG91dCBvZiByb3V0aW5nLCBmb3J3YXJkaW5nIGFuZCBwb2xpY2lu
ZywgdGhlIG5ldw0KPiBhcHBsaWNhdGlvbnMgaGF2ZSBlbWVyZ2VkIGFuZCBwcm9saWZlcmF0ZWQu
IFdoaWxlIHdlIHdlcmUgZGVzaWduaW5nIHRoZQ0KPiBpbnRlcmZhY2UgYmV0d2VlbiB0cmFuc3Bv
cnQsIHBhY2tldCwgYnJvYWRiYW5kIGFuZCB3aXJlbGVzcyBuZXR3b3JrcywNCj4gdGhlIG5ldyBz
ZXJ2aWNlcyBoYXZlIGJlZW4gY3JlYXRlZCBhbmQgZGVwbG95ZWQgc2ltcGx5IG92ZXIgdGhlDQo+
IHVuZGVybHlpbmcgbmV0d29ya3MuIFdoaWxlIHdlIHdlcmUgb3B0aW1pemluZyB0aGUgdXNlIG9m
IGJhbmR3aWR0aCBhbmQNCj4gcHJvY2Vzc2luZyBvbiBvdXIgaGFyZHdhcmUsIHRoZSBNb29yZSdz
IExhdyBoYXMgbWFkZSBhbGwgcGFydHMgb2YgdGhlDQo+IG5ldHdvcmsgbGVzcyBleHBlbnNpdmUg
ZWFjaCBkYXkuIFRoaXMgaXMgdGhlIHdheSBpdCBpcyENCj4gDQo+IFRoZSBpbnRlcmZhY2UgYmV0
d2VlbiBhcHBsaWNhdGlvbiBhbmQgbmV0d29yayBoYXMgYmVlbiBhbiBpbnRlcmVzdGluZw0KPiBh
cmVhOiBXZSBoYXZlIHNlZW4gdGhlIGFwcHJvYWNoIGluIGNsb3NpbmcgdGhlIG5ldHdvcmsgYW5k
IGVuZm9yY2luZw0KPiB0aWdodGVyIGNvbnRyb2wgb3ZlciB1c2VycyB3aXRoaW4gYSB3YWxsZWQg
Z2FyZGVuIChnb29kIGx1Y2shKS4gV2UgaGF2ZQ0KPiBhbHNvIHNlZW4gdGhlIGF0dGVtcHRzIGlu
IHB1c2hpbmcgdGhlIHRyYWRpdGlvbmFsIG5ldHdvcmsNCj4gb3BlcmF0aW9uIG1ldGhvZG9sb2d5
IGludG8gYXBwbGljYXRpb25zICh5dWshKQ0KPiANCj4gTXkgYmVsaWVmIGlzIHRoYXQgd2Ugc2hv
dWxkIG9wZW4gdXAgdGhlIG5ldHdvcmssIGVtYnJhY2UNCj4gbmV3IGFwcGxpY2F0aW9ucyBhbmQg
cHJvdmlkZSBzaW1wbGVyIGFuZCBlYXNpZXIgaW50ZXJmYWNlIHRvIHRoZSB1c2Vycy4NCj4gVGhl
IHZhbHVlIG9mIHRoZSBuZXR3b3JrIGlzIGluIGF0dHJhY3RpbmcgbW9yZSB0cmFmZmljLCBtb3Jl
IHVzZXJzIGFuZA0KPiBtb3JlIGFwcGxpY2F0aW9ucywgbm90IGluIGNyZWF0aW5nIG1vcmUgbWlk
ZGxlbWVuLg0KPiANCj4gTWFueSBoYXZlIGJlZW4gc2F5aW5nIHRoYXQgbmV0d29yayBzaG91bGQg
YmUgYSAiZHVtYiBwaXBlIi4gVHJ1ZSBhbmQNCj4gZmFsc2UuIEl0J3MgdHJ1ZSB0aGF0LCBhcyBm
YXIgYXMgdXNlcnMgYXJlIGNvbmNlcm5lZCwgYW55IGxpbmsgYmV0d2Vlbg0KPiB0d28gbmV0d29y
ayBlbmRwb2ludHMgc2hvdWxkIGJlIHByZWRpY3RhYmxlIGFuZCByZWxpYWJsZSBhcyBhIHNpbXBs
ZQ0KPiB3aXJlLiBBdCB0aGUgc2FtZSB0aW1lLCB0aGUgbmV0d29yayBuZWVkcyB0byBiZSBwcmV0
dHkgc21hcnQgaW4gbWFraW5nDQo+IHRoZSBpbnRlcmZhY2UgZHVtYi4NCj4gDQo+IFRvZGF5LCB3
ZSBjYW4gY3JlYXRlIGNvbm5lY3Rpb25zIGF0IGFueSBsYXllciwgYXQgYW55IHJhdGUsIGluIGFu
eQ0KPiBmb3JtYXQsIHdpdGggYW55IHByb3BlcnR5IGFuZCBpbiBhbnkgZ3JhbnVsYXJpdHkgaW5z
aWRlIHRoZSBuZXR3b3JrLiBPdXINCj4gbW90aXZhdGlvbiBoZXJlIGlzIGluIG1ha2luZyB0aGUg
bmV0d29yayBjb25uZWN0aW9ucyB2aXNpYmxlIGFuZA0KPiBwcm9ncmFtbWFibGUgdG8gdGhlIGFw
cGxpY2F0aW9ucy4NCj4gDQo+ICgyKSBXaHkgdXM/DQo+IA0KPiBGb3IgYSBsb25nIHRpbWUsIFdl
YiBhbmQgbmV0d29yayB0ZWNobm9sb2dpZXMgaGF2ZSBiZWVuIGRldmVsb3BlZA0KPiBpbiBwYXJh
bGxlbC4gSG93ZXZlciwgdGhlIHJlY2VudCBkZW1hbmQgaW4gZGF0YSBjZW50ZXJzIHJlcXVpcmVz
DQo+IHRoZSBtYXNzaXZlIHdlYiB0cmFuc2FjdGlvbiBhbmQgdGhlIGhlYXZ5IG5ldHdvcmsgdHJh
bnNwb3J0IHRha2luZyBwbGFjZQ0KPiB3aXRoaW4gYSBmZXcgaHVuZHJlZCBmZWV0LiBXZWIgb3Bl
cmF0aW9uLCBkcml2ZW4gYnkgbWFzc2l2ZSBwYXJhbGxlbA0KPiBwcm9jZXNzaW5nIGFuZCBtYXNz
aXZlIGNvbnRlbnQgcmVwbGljYXRpb24sIGRlbWFuZHMgc2ltcGxlIGFuZCBjaGVhcGVyDQo+IG5l
dHdvcmsgc3VwcG9ydC4gVG8gZGF0ZSwgbm8gbmV0d29yayBwb3J0IGlzIGZhc3RlciBlbm91Z2gs
IGFuZCBubw0KPiBhcHBsaWNhdGlvbi1uZXR3b3JrIG9wZXJhdGlvbiBpcyBlZmZpY2llbnQgZW5v
dWdoLg0KPiANCj4gSSBiZWxpZXZlIHRoYXQgdGhlIG5ldHdvcmsgdGVjaG5vbG9neSBuZWVkcyB0
byBzY2FsZSB1cA0KPiBhbmQgYWNjb21tb2RhdGUgdGhlIGRlbWFuZCBmcm9tIHRoZSBhcHBsaWNh
dGlvbnMuIFdlIG5lZWQgdG8gbWFrZSBvdXINCj4gbmV0d29yayBzaW1wbGVyLCBlYXNpZXIgYW5k
IG1vcmUgZWZmaWNpZW50LiAoWWVzLCB3ZSBzYXkgdGhpcyBldmVyeSB0aW1lDQo+IHdoZW4gd2Ug
c3RhcnQgYSBuZXcgcHJvamVjdCwgdGhlIG91dGNvbWUgaXMgYWx3YXlzIGNvbnRyYWRpY3Rpbmcu
IEJ1dCwNCj4gd2UgdHJ5IGFueXdheSEgOy0pKQ0KPiANCj4gV2UgZW52aXNpb24gdG8gY3JlYXRl
IHByb2dyYW1tYWJsZSBuZXR3b3JrIEFQSSdzLCBieSBhZGFwdGluZyBib3RoDQo+IG5ldHdvcmtp
bmcgYW5kIGFwcGxpY2F0aW9uIHRlY2huaXF1ZXMuIFdlIHdpbGwgbGV2ZXJhZ2UgdGhlIGV4aXN0
aW5nDQo+IG5ldHdvcmtpbmcgdGVjaG5vbG9naWVzLCBkZXNpZ25lZCBhbmQgZGVmaW5lZCBpbiBJ
RVRGLCB0byBjcmVhdGUsDQo+IG1vbml0b3IgYW5kIGRpc2NvdmVyIG5ldHdvcmsgcmVzb3VyY2Vz
LCBzZXJ2aWNlcyBhbmQgY29ubmVjdGlvbnMuIEFuZCB3ZQ0KPiB3aWxsIGxldmVyYWdlIHRoZSBz
Y2FsYWJsZSBhbmQgc2VjdXJlIG1lc3NhZ2UgcHJvY2Vzc2luZyBjYXBhYmlsaXR5IGZyb20NCj4g
V2ViIChvciBvdmVyIHBvcnQtODApIGZvciBBUEkncy4NCj4gDQo+ICgzKSBFeGFtcGxlcyAoYmUg
bW9yZSBzcGVjaWZpYykNCj4gDQo+IE5ldHdvcmsgcHJvZ3JhbW1hYmlsaXR5IGFwcGxpZXMgaW4g
bWFueSBwbGFjZXMsIGFuZCB3ZSBzZWUgYSBmZXcNCj4gYXBwbGljYXRpb25zIG5lZWQgdG8gYmUg
c29sdmVkIHJlYWwgZmFzdC4NCj4gDQo+IEZpcnN0LCB0aGUgVk0gbmV0d29yayBpbnRlcmZhY2Ug
aXMgVkxBTi4gQXMgc3VjaCwgYW55IFZNIG5ldHdvcmstbGV2ZWwNCj4gc2VydmljZSBtYW5pcHVs
YXRpb24gbmVlZCB0byBiZSBhY2NvbXBsaXNoZWQgdGhyb3VnaCB0aGUgbWFuYWdlbWVudCBhdA0K
PiBWTEFOLWdyYW51bGFyaXR5LiANCj4gDQo+IEZvciBleGFtcGxlLCBpZiBWTSBhcHBsaWNhdGlv
bnMgcmVxdWlyZSBub24tZGlzcnVwdGl2ZSBzZXJ2aWNlcywgdGhlDQo+IHNlcnZpY2Ugb3BlcmF0
b3JzIG1heSBtYXAgdGhlIFZNJ3MgdG8gdGhlIG5ldHdvcmsgbGlua3Mgd2l0aCBiYW5kd2lkdGgs
DQo+IGRlbGF5IGFuZCBwcm90ZWN0aW9uIGNvbnN0cmFpbnRzLCBieSB1dGlsaXppbmcgTVBMUyBh
bmQgRlJSIHRvIGFjaGlldmUNCj4gbmV0d29yay13aWRlIHN1cHBvcnQuDQo+IA0KPiBBbm90aGVy
IGV4YW1wbGUgaXMgaW4gc3VwcG9ydGluZyBlbnRlcnByaXNlIFZQTidzLiBJbiB0aGlzIHNjZW5h
cmlvLCB0aGUNCj4gc2VydmljZSBvcGVyYXRvcnMgbWF5IGJ1bmRsZSB0aGUgcmVsZXZhbnQgVk0n
cyB0byB0aGUgY29ycmVzcG9uZGluZyBNUExTDQo+IFZQTidzLiBBbGwgdGhlIHRlY2huaXF1ZXMg
ZGVmaW5lZCBpbiBJRVRGIGNhbiBiZSByZWFkaWx5IHVzZWQgdG8gc3VwcG9ydA0KPiBWTSBtb2Jp
bGl0eSBhbmQgc2VydmljZSBzZWN1cml0eSBoZXJlLg0KPiANCj4gQW5vdGhlciBhcmVhIHdlIG5l
ZWQgdG8gdG8gbG9vayBhdCBpcyBpbiB0aGUgYXJlYSBvZiB2aWRlby9tZWRpYQ0KPiBzZXJ2aWNl
cy4gT1RUIHZpZGVvIHNlcnZpY2VzIHdpbGwgbGlrZWx5IHN0b3JlIHRoZSBjb250ZW50IG9uIHRo
ZSBkYXRhDQo+IGNlbnRlcnMsIGFuZCB1dGlsaXplIGxvY2FsIENETidzIGZvciBkZWxpdmVyeSAo
dGFrZSBhIGxvb2sgYXQgTmV0ZmxpeCkuDQo+IFRoZSBjb250ZW50IG1heSBiZSByZXBsaWNhdGVk
IGZyb20gZGF0YSBjZW50ZXIgdG8gZGF0YSBjZW50ZXIsIGFuZCBDRE4ncw0KPiBtYXkgdXRpbGl6
ZSBkaWZmZXJlbnQgZGlzdHJpYnV0ZSB0ZWNobmlxdWVzLiBIb3dldmVyLCB0aGUgc2VydmljZQ0K
PiBvcGVyYXRvcnMgbWF5IG1hcCB0aGUgKGxvZ2ljYWwpIGNvbnRlbnQgdG8gdGhlIGFjdHVhbCBk
aXN0cmlidXRpb24NCj4gZW5naW5lcyB3aXRoIHNlcnZpY2UgZ3VhcmFudGVlcy4gSSBrbm93IHNv
bWUgb2YgdGhlIHdvcmsgaGFzDQo+IGJlZW4gZGlzY3Vzc2VkIGluIEFMVE8sIHNvIGxldCdzIHdv
cmsgdG9nZXRoZXIgdGhlcmUuDQo+IA0KPiBTZXJ2aWNlIG1vbml0b3JpbmcgaXMgYW5vdGhlciBp
bXBvcnRhbnQgYXNwZWN0IG9mIHRoZSB3b3JrLiBFYWNoIHdlYg0KPiBzZXJ2aWNlIGlzIHN1cHBv
cnRlZCBieSBtYW55IGJhY2stZW5kIGFwcGxpY2F0aW9ucywgd2hpY2ggbWF5IG9wZXJhdGVkDQo+
IGluIGRpZmZlcmVudCBsb2NhdGlvbnMuIFRvIGhhdmUgYSByb2J1c3Qgc2VydmljZSwgdGhlIHNl
cnZpY2Ugb3BlcmF0b3JzDQo+IG5lZWQgdG8gaGF2ZSBhIHdheSB0byBtb25pdG9yIGFuZCBndWFy
YW50ZWUgbmV0d29yay1zZXJ2aWNlcyB0byB0aG9zZQ0KPiBzZXJ2aWNlcy4NCj4gDQo+IEluIHN1
bW1hcnksIHdlIGVudmlzaW9uIFNETiB3b3JrIHRvIGJyaWRnZSB0aGUgZ2FwIGJldHdlZW4gdGhl
DQo+IGFwcGxpY2F0aW9ucyBhbmQgdGhlIG5ldHdvcmsuIEluIHRoZSBmdXR1cmUsIHdlIG1heSBh
ZGRyZXNzDQo+IGludGVyLW5ldHdvcmtpbmcgY29uY2VybnMuIEhvd2V2ZXIsIG11Y2ggb2YgdGhl
IG5ldHdvcmtpbmctbGV2ZWwgd29yaw0KPiBjYW4gYmUgc29sdmVkIHdpdGggYSBiZXR0ZXIgT1NT
LiBJJ2QgcHJlZmVyIHRvIHNvbHZlIHRoZQ0KPiBhcHBsaWNhdGlvbi1uZXR3b3JrIGludGVyZmFj
aW5nIGlzc3VlcyBmaXJzdC4NCj4gDQo+IA0KPiAoNCkgTmV4dCBTdGVwcw0KPiANCj4gSSBoYXZl
IGFuIG9sZC1zY2hvb2wgd2hlbiBpdCBjb21lcyB0byB0aGlzOiBydW5uaW5nIGNvZGUgYW5kIHJv
dWdoDQo+IGNvbnNlbnN1cyENCj4gDQo+IEluIHRoZSBjb21pbmcgd2Vla3MsIHdlIHdvdWxkIGxp
a2UgdG8gY29sbGVjdCBtb3JlIHVzZSBjYXNlcywNCj4gY29sbGFib3JhdGUgd2l0aCBtYW55LCBs
ZWFybiBmcm9tIGVhY2ggb3RoZXIuIEF0IHRoZSBlbmQsIHdlIHNob3VsZCBwdXQNCj4gdG9nZXRo
ZXIgdGhlIGFyY2hpdGVjdHVyZSwgcHJvdG9jb2wgZGVzaWduIGFuZCBob3BlZnVsbHkgc29tZSAN
CnByb3RvdHlwZXMuDQo+IA0KPiBIb3BlIHRoaXMgbWFrZXMgc2Vuc2UuDQo+IA0KPiBCZXN0IHJl
Z2FyZHMsDQo+IA0KPiAtIFBpbmcNCj4gDQo+IA0KPiBPbiBXZWQsIEp1bCAyNywgMjAxMSBhdCAy
OjMyIFBNLCBCaXRhciwgTmFiaWwgTg0KPiA8bmFiaWwubi5iaXRhckB2ZXJpem9uLmNvbSA8bWFp
bHRvOm5hYmlsLm4uYml0YXJAdmVyaXpvbi5jb20+PiB3cm90ZToNCj4gDQo+IA0KPiAgICAgSSB0
aGluayBkdXJpbmcgdGhlIG1lZXRpbmcgYSBnb29kIHNwZWN0cnVtIG9mIHVzZSBjYXNlcyB3YXMN
Cj4gICAgIGRpc2N1c3NlZCByYWdpbmcgZnJvbSBkYXRhIGNlbnRlciB0eXBlIGFwcGxpY2F0aW9u
cyB0byB0aGUgY2FzZSBvZg0KPiAgICAgaW50ZXItcHJvdmlkZXIgY29ubmVjdGlvbiBzZXR1cCBv
ciBwb2xpY3kgdHJhbnNmZXIuICBJdCBzZWVtcyB0aGF0DQo+ICAgICB0aGVyZSBpcyBhIG5lZWQg
dG8gcHV0IGRvd24gdGhlIHVzZSBjYXNlcyBvbiBwYXBlciBhbmQgc2VlIHdoYXQNCj4gICAgIGV4
aXN0aW5nIG1lY2hhbmlzbXMgY2FuIGJlIHVzZWQgdG8gYWRkcmVzcyB0aGVzZSB1c2UgY2FzZXMg
YW5kIHdoeQ0KPiAgICAgdGhlcmUgaXMgbmV3IHdvcmsgbmVlZGVkLiBJcyBpdCBmcmVzaCBuZXcg
d29yayBvciBleHRlbnNpb25zIHRvDQo+ICAgICBleGlzdGluZyBtZWNoYW5pc21zPyAgV2hhdCBh
cmUgdGhlIGdhcHMgIGluIHdoYXQgZXhpc3RzIGlzIGJlaW5nDQo+ICAgICBzb2x2ZWQ/IEl0IGlz
IG5vdCBjbGVhciB0byBtZSB0aGF0IHRoZXJlIGlzIG9uZSBoYW1tZXIgdGhhdCB3aWxsIGJlDQo+
ICAgICBhYmxlIHRvIGFkZHJlc3MgYWxsIHRoZSB1c2UgY2FzZXMgLCBhbmQgaWYgbmVlZGVkLCB3
aXRob3V0DQo+ICAgICByZWNyZWF0aW5nIHRoZSB3aGVlbCBvciBhZGRpbmcgY29tcGxleGl0aWVz
IG9yIGRlZmljaWVuY2llcyAgVGhhdA0KPiAgICAgbWF5IGJlIGJpYXNlZCBieSB0aGUgdmlldyBJ
IGhhZCB3YWxraW5nIGludG8gdGhlIG1lZXRpbmcgdGhhdCB0aGVyZQ0KPiAgICAgd2FzIHRlbmRl
bmN5IHRvIGZvY3VzIG9uIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgYXBwbGljYXRpb24gYW5k
DQo+ICAgICB0aGUgU0ROIGNvbnRyb2xsZXIgIHRvIHJlcXVlc3QgcmVzb3VyY2VzIG1heWJlIHN1
YmplY3QgdG8NCj4gICAgICBjb25zdHJhaW50cywgdG8gcmVjZWl2ZSBpbmZvcm1hdGlvbiwgcmVz
cG9uc2UgdG8gYSByZXF1ZXN0IGFuZC9vcg0KPiAgICAgbm90aWZpY2F0aW9uICBmcm9tIHRoZSBT
RE4gY29udHJvbGxlci4gV2hhdCB0aGUgU0ROIGNvbnRyb2xsZXIgZG9lcw0KPiAgICAgbWF5IGNh
cGl0YWxpemUgb24gZXhpc3RpbmcgbWVjaGFuaXNtcyB3aGljaCB3aWxsIGJlIGRlcGVuZGVudCBv
biB0aGUNCj4gICAgIHVzZSBjYXNlIGFuZCB0aGUgbmF0dXJlIG9mIHRoZSBhcHBsaWNhdGlvbiBy
ZXF1ZXN0LiAgV2hpbGUgdGhlDQo+ICAgICBpbnRlcmZhY2UgY2FuIGJlIGdlbmVyaWMgIGFuZCBl
eHRlbnNpYmxlLCB0aGUgdXNlIGNhc2Ugb3INCj4gICAgIGFwcGxpY2F0aW9uIHdpbGwgZHJpdmUg
d2hhdCBpbmZvcm1hdGlvbiBpcyBleGNoYW5nZWQuDQo+ICAgICBJIGFwcHJlY2lhdGUgYSBjbGFy
aWZpY2F0aW9uIGlmIGFsbCB0aGUgdGhlIGZvbGxvd2luZyBzdGlsbCBhdCBwbGF5DQo+ICAgICBo
ZXJlIG9yIHNvbWV0aGluZyB3YXMgcHJ1bmVkIG91dCBvciB0b28gZWFybHkgdG8gcHJ1bmU6DQo+
IA0KPiAgICAgICAgMS4gYXBwbGljYXRpb24gLVNETiBjb250cm9sbGVyIGludGVyZmFjZS4gV2hh
dCBpcyB0aGUgZnVuY3Rpb24gb2YNCj4gICAgICAgICAgIHRoYXQgaW50ZXJmYWNlIGlzIGdvaW5n
IHRvIGJlIGFwcGxpY2F0aW9uIGRlcGVuZGVudC4gVGhhdCBnb2VzDQo+ICAgICAgICAgICBmb3Ig
b3RoZXIgaW50ZXJmYWNlcw0KPiAgICAgICAgMi4gU0ROIGNvbnRyb2xsZXItU0ROIGludGVyZmFj
ZQ0KPiAgICAgICAgMy4gU0ROIGNvbnRyb2xsZXItU0ROIGNvbnRyb2xsZXIgaW50ZXJmYWNlDQo+
ICAgICAgICA0LiBQYXRoIGNvbXB1dGF0aW9uIChub3QgbmVjZXNzYXJpbHkgVEUgKSBmb3IgYSB0
dW5uZWwgb3INCj4gICAgICAgICAgIG1pY3JvZmxvdyBiYXNlZCBvbiBjZXJ0YWluIGNvbnN0cmFp
bnRzLiANCj4gICAgICAgIDUuIGZsb3cgbWFwcGluZyB0byBhIHBhdGgsIGluY2x1ZGluZyBmbG93
IGNsYXNzaWZpY2F0aW9uIGFuZA0KPiAgICAgICAgICAgY29uZmlndXJhdGlvbiBvbiBldmVyeSBo
b3AuDQo+IA0KPiAgICAgVGhhbmtzLA0KPiAgICAgTmFiaWwNCj4gICAgIEZyb206IFRob21hcyBO
YWRlYXUgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tDQo+ICAgICA8bWFpbHRvOnRuYWRlYXVAbHVj
aWR2aXNpb24uY29tPj4NCj4gICAgIERhdGU6IFdlZCwgMjcgSnVsIDIwMTEgMTE6Mjk6MjAgLTA0
MDANCj4gICAgIFRvOiAiT25nLCBMeW5kb24iIDxMeW9uZ0BDaWVuYS5jb20gPG1haWx0bzpMeW9u
Z0BDaWVuYS5jb20+Pg0KPiAgICAgQ2M6ICJzZG5wQGx1Y2lkdmlzaW9uLmNvbSA8bWFpbHRvOnNk
bnBAbHVjaWR2aXNpb24uY29tPiINCj4gICAgIDxzZG5wQGx1Y2lkdmlzaW9uLmNvbSA8bWFpbHRv
OnNkbnBAbHVjaWR2aXNpb24uY29tPj4NCj4gDQo+ICAgICBTdWJqZWN0OiBSZTogW1NkbnBdIG9u
ZSBvciB0d28gYmxhbmsgbG9va3Mgb24gaW50LXNlcnYgcmVmZXJlbmNlDQo+ICAgICBkdXJpbmcg
dGhlIGJhciBib2YNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAgICAgT24gSnVsIDI3LCAyMDExLCBh
dCAxMToxNSBBTSwgIk9uZywgTHluZG9uIiA8THlvbmdAQ2llbmEuY29tDQo+ICAgICA8bWFpbHRv
Okx5b25nQENpZW5hLmNvbT4+IHdyb3RlOg0KPiANCj4+ICAgICBIaSBHdXlzLF9fX18NCj4+DQo+
PiAgICAgX18gX18NCj4+DQo+PiAgICAgUmVnYXJkaW5nICgyKSwgaWYgd2Whr3JlIGFnbm9zdGlj
IHRoZW4gdGhpcyB3b3JrIHNlZW1zIHRvIGJlIG1vcmUNCj4+ICAgICBnZW5lcmFsLCBpdCBjb3Vs
ZCBhcHBseSB0byBPRi1jb250cm9sbGVkIG5ldHdvcmtzLA0KPj4gICAgIE1QTFMvR01QTFMtY29u
dHJvbGxlZCBuZXR3b3JrcywgUENFL25vbi1QQ0UsIGV0Yy5fX19fDQo+Pg0KPj4gICAgIF9fIF9f
DQo+Pg0KPj4gICAgIFJlZ2FyZGluZyAoMykgbm90IHN1cmUgdGhhdCB0aGlzIGZvbGxvd3MgqEMg
aW4gYSBsb3Qgb2YgdGhlIGNvbnRyb2wNCj4+ICAgICBwbGFuZSB0ZWNobm9sb2dpZXMgdGhlcmUg
aXMgYSB3YXkgdG8gY29udHJvbCB0aGUgcGF0aC4gIFF1ZXN0aW9uLA0KPj4gICAgIHRob3VnaCwg
aG93IG11Y2ggZG9lcyBhbiBhcHBsaWNhdGlvbiBuZWVkIHRvIGtub3cgYWJvdXQgdGhlIHBhdGg/
DQo+Pg0KPiANCj4gICAgIEkgdGhpbmsgdGhhdCBkZXBlbmRzIG9uIHdoYXQgdGhlIGFwcGxpY2F0
aW9uIGlzIGFuZCB3aGF0IGl0J3MNCj4gICAgIHB1cnBvc2UgaXMuIEl0IG1heSBiZSBpbnRlcmVz
dGVkIGluIG5ldHdvcmsgcmVzb3VyY2VzIG90aGVyIHRoYW4NCj4gICAgIGp1c3QgbGlua3MgYW5k
IHBhdGhzLiBBbHNvLCBhcyBEYW5ueSBtZW50aW9uZWQgaW4gaGlzIHVzZSBjYXNlDQo+ICAgICB5
ZXN0ZXJkYXkgdGhlcmUgaXMgYSBuZWVkIGZvciB2YXJ5aW5nIGxldmVscyBvZiBncmFudWxhcml0
eSBoZXJlLiANCj4gDQo+ICAgICBUb20NCj4gDQo+PiAgICAgX19fXw0KPj4NCj4+ICAgICBfXyBf
Xw0KPj4NCj4+ICAgICBDaGVlcnMsX19fXw0KPj4NCj4+ICAgICBfXyBfXw0KPj4NCj4+ICAgICBM
eW5kb25fX19fDQo+Pg0KPj4gICAgIF9fIF9fDQo+Pg0KPj4gICAgIEJUVywgdGhlIGNvbXBhcmlz
b24gdG8gaW50c2VydiByZW1pbmRzIG1lIHRoYXQgd2hlbiBJIHRyeSB0bw0KPj4gICAgIGV4cGxh
aW4gT0YgdG8gcGVvcGxlLCB0aGV5IGNvbW1vbmx5IGFzayB3aHkgdGhpcyBpcyBkaWZmZXJlbnQg
ZnJvbQ0KPj4gICAgIEZPUkNFUyFfX19fDQo+Pg0KPj4gICAgIF9fIF9fDQo+Pg0KPj4NCj4+ICAg
ICA8aW1hZ2ViNThlOWUuZ2lmQGI2NDQ2YTNkLjI0ZDQ0OTdiDQo+PiAgICAgPG1haWx0bzppbWFn
ZWI1OGU5ZS5naWZAYjY0NDZhM2QuMjRkNDQ5N2I+Pg0KPj4NCj4+ICAgICAqRnJvbToqIHNkbnAt
Ym91bmNlc0BsdWNpZHZpc2lvbi5jb20NCj4+ICAgICA8bWFpbHRvOnNkbnAtYm91bmNlc0BsdWNp
ZHZpc2lvbi5jb20+DQo+PiAgICAgW21haWx0bzpzZG5wLWJvdW5jZXNAbHVjaWR2aXNpb24uY29t
XSAqT24gQmVoYWxmIE9mICpFZHdhcmQgQ3JhYmJlDQo+PiAgICAgKlNlbnQ6KiBXZWRuZXNkYXks
IEp1bHkgMjcsIDIwMTEgNzoyMyBBTQ0KPj4gICAgICpUbzoqIFBpbmcgUGFuDQo+PiAgICAgKkNj
OiogPG1haWx0bzpzZG5wQGx1Y2lkdmlzaW9uLmNvbT5zZG5wQGx1Y2lkdmlzaW9uLmNvbQ0KPj4g
ICAgIDxtYWlsdG86c2RucEBsdWNpZHZpc2lvbi5jb20+DQo+PiAgICAgKlN1YmplY3Q6KiBSZTog
W1NkbnBdIG9uZSBvciB0d28gYmxhbmsgbG9va3Mgb24gaW50LXNlcnYgcmVmZXJlbmNlDQo+PiAg
ICAgZHVyaW5nIHRoZSBiYXIgYm9mX19fXw0KPj4NCj4+ICAgICBfXyBfXw0KPj4NCj4+ICAgICBf
XyBfXw0KPj4NCj4+ICAgICAgICAgT3VyIGdvYWwgaGVyZSBpcyB0byBzb2x2ZSBhIHNwZWNpZmlj
IHByb2JsZW06IG1hcCBhcHBsaWNhdGlvbg0KPj4gICAgICAgICBmbG93cyAoaW4gd2hhdGV2ZXIg
dGhlIGZvcm0pIGludG8gcGh5c2ljYWwgbmV0d29yayB0dW5uZWxzLl9fX18NCj4+DQo+PiAgICAg
ICAgIF9fIF9fDQo+Pg0KPj4gICAgIF9fIF9fDQo+Pg0KPj4gICAgIHRocmVlIHRoaW5ncyBoZXJl
OiBfX19fDQo+Pg0KPj4gICAgIF9fIF9fDQo+Pg0KPj4gICAgIDEpIHNvIGJhc2ljYWxseSwgeW91
J3JlIHNheWluZyB5b3Ugd2FudCBhIGNvbW1vbiBsYW5ndWFnZSB0bw0KPj4gICAgICBidWlsZCBh
IEZFQywgbWFwcGluZyBhIHNldCBvZiBuLXR1cGxlIG1hdGNoZXMgKHZsYW4sIHdoYXRldmVyKQ0K
Pj4gICAgIGludG8gYSBzcGVjaWZpYyBlbmNhcHN1bGF0aW9uP19fX18NCj4+DQo+PiAgICAgX18g
X18NCj4+DQo+PiAgICAgMikgYXJlIHRoZXNlIHR1bm5lbHMgcHJlLWV4aXN0aW5nPyAgaWYgc28s
IGZpbmUsIGlmIG5vdCwgd2Ugbm93DQo+PiAgICAgaGF2ZSB0byBzZXQgdXAgdGhlIHR1bm5lbCwg
YXQgd2hpY2ggcG9pbnQgd2UncmUgYmFjayB0byBkZWFsaW5nDQo+PiAgICAgd2l0aCBlaXRoZXIg
T0YgdHlwZSBwZXIgaG9wIHN0YXRlIHNldHVwIG9yIGFuIGV4aXN0aW5nIGVuZCB0bw0KPj4gICAg
IGVuZCBzaWduYWxpbmcgcHJvdG9jb2wgKGFuZCAgd2UncmUgZGVhbGluZyB3aXRoIHRoaW5ncyBh
dCBhIHBlcg0KPj4gICAgIGhvc3QsIGFwcCBsZXZlbD8gIFRodXMgdGhlICBpbnQtc2VydiByZWZl
cmVuY2UgOy0pLiAgUGVyaGFwcyB0aGUNCj4+ICAgICBpZGVhIGlzIHRvIGJlIGFnbm9zdGljIHJl
Z2FyZGluZyBwYXRoIHNldHVwIG1ldGhvZCBoZXJlP19fX18NCj4+DQo+PiAgICAgX18gX18NCj4+
DQo+PiAgICAgMykgd291bGQgdGhpcyBhbHNvIGltcGx5IHRoYXQgdGhhdCBkZWZpbml0aW9uIG9m
IHRoZQ0KPj4gICAgIGNoYXJhY3RlcmlzdGljcywgaW5jbHVkaW5nIHBhdGgsICB0aGF0IHRoZSB0
dW5uZWwgdGFrZXMgb3ZlciB0aGUNCj4+ICAgICB1bmRlcmx5aW5nIGluZnJhc3RydWN0dXJlIGlz
IGluIHNjb3BlP19fX18NCj4+DQo+PiAgICAgX18gX18NCj4+DQo+PiAgICAgIF9fX18NCj4+DQo+
PiAgICAgICAgIE5vIG5lZWQgaW4gbGltaXRpbmcgYXBwbGljYXRpb25zLCBhbmQgbm8gbmVlZCBp
biBtYWtpbmcNCj4+ICAgICAgICAgbmV0d29yayBzbWFydGVyIChvciBkdW1iZXIpLiA7LSkNCj4+
ICAgICAgICAgX19fXw0KPj4NCj4+ICAgICAgICAgX18gX18NCj4+DQo+PiAgICAgICAgIFRoYW5r
cyFfX19fDQo+Pg0KPj4gICAgICAgICBfXyBfXw0KPj4NCj4+ICAgICAgICAgLSBQaW5nDQo+Pg0K
Pj4gICAgICAgICBfX19fDQo+Pg0KPj4gICAgICAgICBPbiBUdWUsIEp1bCAyNiwgMjAxMSBhdCA3
OjI4IFBNLCBFZHdhcmQgQ3JhYmJlIDwNCj4+ICAgICAgICAgPG1haWx0bzplZGNAZ29vZ2xlLmNv
bT5lZGNAZ29vZ2xlLmNvbSA8bWFpbHRvOmVkY0Bnb29nbGUuY29tPj4NCj4+ICAgICAgICAgd3Jv
dGU6X19fXw0KPj4NCj4+ICAgICAgICAgICAgIGZvciByZWZlcmVuY2UsIHdhcyByZWZlcnJpbmcg
dG86X19fXw0KPj4NCj4+ICAgICAgICAgICAgIF9fIF9fDQo+Pg0KPj4gICAgICAgICAgICAgPGh0
dHA6Ly90b29scy5pZXRmLm9yZy9yZmMvcmZjMjIxMC50eHQNCj5odHRwOi8vdG9vbHMuaWV0Zi5v
cmcvcmZjL3JmYzIyMTAudHh0X19fXw0KPj4NCj4+ICAgICAgICAgICAgIF9fIF9fDQo+Pg0KPj4g
ICAgICAgICAgICAgX18gX18NCj4+DQo+PiAgICAgICAgICAgICBfXyBfXw0KPj4NCj4+ICAgICAg
ICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
PiAgICAgICAgICAgICBTRE5QIG1haWxpbmcgbGlzdA0KPj4gICAgICAgICAgICAgPG1haWx0bzpT
RE5QQGx1Y2lkdmlzaW9uLmNvbT5TRE5QQGx1Y2lkdmlzaW9uLmNvbQ0KPj4gICAgICAgICAgICAg
PG1haWx0bzpTRE5QQGx1Y2lkdmlzaW9uLmNvbT4NCj4+ICAgICAgICAgICAgIDxodHRwOi8vbHVj
aWR2aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8vc2RucA0KPmh0dHA6Ly9sdWNpZHZpc2lvbi5j
b20vbWFpbG1hbi9saXN0aW5mby9zZG5wX19fXw0KPj4NCj4+ICAgICAgICAgX18gX18NCj4+DQo+
PiAgICAgX18gX18NCj4+DQo+Pg0KPj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+PiAgICAgU0ROUCBtYWlsaW5nIGxpc3QNCj4+ICAgICBTRE5Q
QGx1Y2lkdmlzaW9uLmNvbSA8bWFpbHRvOlNETlBAbHVjaWR2aXNpb24uY29tPg0KPj4gICAgIGh0
dHA6Ly9sdWNpZHZpc2lvbi5jb20vbWFpbG1hbi9saXN0aW5mby9zZG5wDQo+IA0KPiAgICAgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgIFNETlAg
bWFpbGluZyBsaXN0DQo+ICAgICBTRE5QQGx1Y2lkdmlzaW9uLmNvbSA8bWFpbHRvOlNETlBAbHVj
aWR2aXNpb24uY29tPg0KPiAgICAgaHR0cDovL2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFuL2xpc3Rp
bmZvL3NkbnANCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IFNETlAgbWFpbGluZyBsaXN0DQo+IFNETlBAbHVjaWR2aXNp
b24uY29tDQo+IGh0dHA6Ly9sdWNpZHZpc2lvbi5jb20vbWFpbG1hbi9saXN0aW5mby9zZG5wDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kdm5yZyBtYWls
aW5nIGxpc3QNCnZucmdAaXJ0Zi5vcmcNCmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlz
dGluZm8vdm5yZw0KDQoNCg0K
--=_alternative 000F3B39482578E0_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K
PHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+TG91IEJlcmdl
ciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x
IGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7dm5yZy1ib3VuY2VzQGlydGYub3JnPC9m
b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDgtMDEgMjI6NTY8
L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv
cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi
PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+
UGluZyBQYW4gJmx0O3BpbmdAcGluZ3Bhbi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+
DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z
rcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVv
dDtzZG5wQGx1Y2lkdmlzaW9uLmNvbSZxdW90OyAmbHQ7c2RucEBsdWNpZHZpc2lvbi5jb20mZ3Q7
LA0KJnF1b3Q7Qml0YXIsICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05hYmlsIE4mcXVvdDsg
Jmx0O25hYmlsLm4uYml0YXJAdmVyaXpvbi5jb20mZ3Q7LA0KVk5SRyAmbHQ7dm5yZ0BpcnRmLm9y
ZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv
bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg
c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbdm5yZ10gW1NkbnBdIEhpZ2gtTGV2ZWwgTW90
aXZhdGlvbg0KKFJlOiBvbmUgb3IgdHdvIGJsYW5rIGxvb2tzIG9uIGludC1zZXJ2IHJlZmVyZW5j
ZSBkdXJpbmcgdGhlIGJhciBib2YpPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg
dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5QaW5nLDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpOaWNlIGludHJvL292ZXJ2aWV3LiAm
bmJzcDtTbyBob3cgZG9lcyB0aGlzIGVmZm9ydCByZWxhdGUgdG8gdGhlIFZOUkc8YnI+DQooaHR0
cDovL2lydGYub3JnL3ZucmcsIGFsc28gY3Jvc3MtcG9zdGVkKT8gJm5ic3A7U2VlbXMgdG8gbWUg
dGhhdCB0aGVyZQ0KaXMgYTxicj4NCmZhaXIgYml0IG9mIG92ZXJsYXAuPGJyPg0KPGJyPg0KVGhh
bmtzLDxicj4NCkxvdTxicj4NCjxicj4NCk9uIDgvMS8yMDExIDEwOjQyIEFNLCBQaW5nIFBhbiB3
cm90ZTo8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3UgaGF2ZSByYWlzZWQg
YSB2ZXJ5IGNyaXRpY2FsIHF1ZXN0aW9uIGhlcmUuIER1cmluZyBJRVRGIGFuZCBvdmVyDQp0aGU8
YnI+DQomZ3Q7IHdlZWtlbmQsIHNldmVyYWwgaGF2ZSBhc2tlZCBvZmYtbGluZSBhYm91dCBvdXIg
bW90aXZhdGlvbi4gQXJlIHdlDQpkb2luZzxicj4NCiZndDsgUlNWUCwgVU5JLCBHRU5JLCBiYW5k
d2lkdGggYnJva2VyIGV0Yy4/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvIGFsbG93IG1lIHRvIGV4
cGxhaW4gb3VyIHRoaW5raW5nIGFuZCBtb3RpdmF0aW9uIGF0IHZlcnkgaGlnaCBsZXZlbA0KaGVy
ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgKDEpIFdoeT88YnI+DQomZ3Q7IDxicj4NCiZndDsgTWFu
eSBvZiB1cyBoYXZlIGJlZW4gYSBwYXJ0IG9mIHRoZSBJbnRlcm5ldCBjcmVhdGlvbiBhbmQgZGVw
bG95bWVudA0KaW48YnI+DQomZ3Q7IHRoZSBwYXN0IG1hbnkgeWVhcnMuIEl0IGhhcyBiZWNvbWUg
c29tZXRoaW5nIG1vcmUgdGhhbiB3ZSBoYWQgZHJlYW1lZDxicj4NCiZndDsgZm9yIGJldHRlciBv
ciBmb3Igd29yc2UuIFdoaWxlIHdlIHdlcmUgc3F1ZWV6aW5nIHRoZSBsYXN0IGJpdCBvZjxicj4N
CiZndDsgaW5lZmZpY2llbmN5IG91dCBvZiByb3V0aW5nLCBmb3J3YXJkaW5nIGFuZCBwb2xpY2lu
ZywgdGhlIG5ldzxicj4NCiZndDsgYXBwbGljYXRpb25zIGhhdmUgZW1lcmdlZCBhbmQgcHJvbGlm
ZXJhdGVkLiBXaGlsZSB3ZSB3ZXJlIGRlc2lnbmluZw0KdGhlPGJyPg0KJmd0OyBpbnRlcmZhY2Ug
YmV0d2VlbiB0cmFuc3BvcnQsIHBhY2tldCwgYnJvYWRiYW5kIGFuZCB3aXJlbGVzcyBuZXR3b3Jr
cyw8YnI+DQomZ3Q7IHRoZSBuZXcgc2VydmljZXMgaGF2ZSBiZWVuIGNyZWF0ZWQgYW5kIGRlcGxv
eWVkIHNpbXBseSBvdmVyIHRoZTxicj4NCiZndDsgdW5kZXJseWluZyBuZXR3b3Jrcy4gV2hpbGUg
d2Ugd2VyZSBvcHRpbWl6aW5nIHRoZSB1c2Ugb2YgYmFuZHdpZHRoDQphbmQ8YnI+DQomZ3Q7IHBy
b2Nlc3Npbmcgb24gb3VyIGhhcmR3YXJlLCB0aGUgTW9vcmUncyBMYXcgaGFzIG1hZGUgYWxsIHBh
cnRzIG9mDQp0aGU8YnI+DQomZ3Q7IG5ldHdvcmsgbGVzcyBleHBlbnNpdmUgZWFjaCBkYXkuIFRo
aXMgaXMgdGhlIHdheSBpdCBpcyE8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGludGVyZmFjZSBi
ZXR3ZWVuIGFwcGxpY2F0aW9uIGFuZCBuZXR3b3JrIGhhcyBiZWVuIGFuIGludGVyZXN0aW5nPGJy
Pg0KJmd0OyBhcmVhOiBXZSBoYXZlIHNlZW4gdGhlIGFwcHJvYWNoIGluIGNsb3NpbmcgdGhlIG5l
dHdvcmsgYW5kIGVuZm9yY2luZzxicj4NCiZndDsgdGlnaHRlciBjb250cm9sIG92ZXIgdXNlcnMg
d2l0aGluIGEgd2FsbGVkIGdhcmRlbiAoZ29vZCBsdWNrISkuIFdlDQpoYXZlPGJyPg0KJmd0OyBh
bHNvIHNlZW4gdGhlIGF0dGVtcHRzIGluIHB1c2hpbmcgdGhlIHRyYWRpdGlvbmFsIG5ldHdvcms8
YnI+DQomZ3Q7IG9wZXJhdGlvbiBtZXRob2RvbG9neSBpbnRvIGFwcGxpY2F0aW9ucyAoeXVrISk8
YnI+DQomZ3Q7IDxicj4NCiZndDsgTXkgYmVsaWVmIGlzIHRoYXQgd2Ugc2hvdWxkIG9wZW4gdXAg
dGhlIG5ldHdvcmssIGVtYnJhY2U8YnI+DQomZ3Q7IG5ldyBhcHBsaWNhdGlvbnMgYW5kIHByb3Zp
ZGUgc2ltcGxlciBhbmQgZWFzaWVyIGludGVyZmFjZSB0byB0aGUgdXNlcnMuPGJyPg0KJmd0OyBU
aGUgdmFsdWUgb2YgdGhlIG5ldHdvcmsgaXMgaW4gYXR0cmFjdGluZyBtb3JlIHRyYWZmaWMsIG1v
cmUgdXNlcnMNCmFuZDxicj4NCiZndDsgbW9yZSBhcHBsaWNhdGlvbnMsIG5vdCBpbiBjcmVhdGlu
ZyBtb3JlIG1pZGRsZW1lbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgTWFueSBoYXZlIGJlZW4gc2F5
aW5nIHRoYXQgbmV0d29yayBzaG91bGQgYmUgYSAmcXVvdDtkdW1iIHBpcGUmcXVvdDsuDQpUcnVl
IGFuZDxicj4NCiZndDsgZmFsc2UuIEl0J3MgdHJ1ZSB0aGF0LCBhcyBmYXIgYXMgdXNlcnMgYXJl
IGNvbmNlcm5lZCwgYW55IGxpbmsgYmV0d2Vlbjxicj4NCiZndDsgdHdvIG5ldHdvcmsgZW5kcG9p
bnRzIHNob3VsZCBiZSBwcmVkaWN0YWJsZSBhbmQgcmVsaWFibGUgYXMgYSBzaW1wbGU8YnI+DQom
Z3Q7IHdpcmUuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZSBuZXR3b3JrIG5lZWRzIHRvIGJlIHByZXR0
eSBzbWFydCBpbiBtYWtpbmc8YnI+DQomZ3Q7IHRoZSBpbnRlcmZhY2UgZHVtYi48YnI+DQomZ3Q7
IDxicj4NCiZndDsgVG9kYXksIHdlIGNhbiBjcmVhdGUgY29ubmVjdGlvbnMgYXQgYW55IGxheWVy
LCBhdCBhbnkgcmF0ZSwgaW4gYW55PGJyPg0KJmd0OyBmb3JtYXQsIHdpdGggYW55IHByb3BlcnR5
IGFuZCBpbiBhbnkgZ3JhbnVsYXJpdHkgaW5zaWRlIHRoZSBuZXR3b3JrLg0KT3VyPGJyPg0KJmd0
OyBtb3RpdmF0aW9uIGhlcmUgaXMgaW4gbWFraW5nIHRoZSBuZXR3b3JrIGNvbm5lY3Rpb25zIHZp
c2libGUgYW5kPGJyPg0KJmd0OyBwcm9ncmFtbWFibGUgdG8gdGhlIGFwcGxpY2F0aW9ucy48YnI+
DQomZ3Q7IDxicj4NCiZndDsgKDIpIFdoeSB1cz88YnI+DQomZ3Q7IDxicj4NCiZndDsgRm9yIGEg
bG9uZyB0aW1lLCBXZWIgYW5kIG5ldHdvcmsgdGVjaG5vbG9naWVzIGhhdmUgYmVlbiBkZXZlbG9w
ZWQ8YnI+DQomZ3Q7IGluIHBhcmFsbGVsLiBIb3dldmVyLCB0aGUgcmVjZW50IGRlbWFuZCBpbiBk
YXRhIGNlbnRlcnMgcmVxdWlyZXM8YnI+DQomZ3Q7IHRoZSBtYXNzaXZlIHdlYiB0cmFuc2FjdGlv
biBhbmQgdGhlIGhlYXZ5IG5ldHdvcmsgdHJhbnNwb3J0IHRha2luZw0KcGxhY2U8YnI+DQomZ3Q7
IHdpdGhpbiBhIGZldyBodW5kcmVkIGZlZXQuIFdlYiBvcGVyYXRpb24sIGRyaXZlbiBieSBtYXNz
aXZlIHBhcmFsbGVsPGJyPg0KJmd0OyBwcm9jZXNzaW5nIGFuZCBtYXNzaXZlIGNvbnRlbnQgcmVw
bGljYXRpb24sIGRlbWFuZHMgc2ltcGxlIGFuZCBjaGVhcGVyPGJyPg0KJmd0OyBuZXR3b3JrIHN1
cHBvcnQuIFRvIGRhdGUsIG5vIG5ldHdvcmsgcG9ydCBpcyBmYXN0ZXIgZW5vdWdoLCBhbmQgbm88
YnI+DQomZ3Q7IGFwcGxpY2F0aW9uLW5ldHdvcmsgb3BlcmF0aW9uIGlzIGVmZmljaWVudCBlbm91
Z2guPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYmVsaWV2ZSB0aGF0IHRoZSBuZXR3b3JrIHRlY2hu
b2xvZ3kgbmVlZHMgdG8gc2NhbGUgdXA8YnI+DQomZ3Q7IGFuZCBhY2NvbW1vZGF0ZSB0aGUgZGVt
YW5kIGZyb20gdGhlIGFwcGxpY2F0aW9ucy4gV2UgbmVlZCB0byBtYWtlDQpvdXI8YnI+DQomZ3Q7
IG5ldHdvcmsgc2ltcGxlciwgZWFzaWVyIGFuZCBtb3JlIGVmZmljaWVudC4gKFllcywgd2Ugc2F5
IHRoaXMgZXZlcnkNCnRpbWU8YnI+DQomZ3Q7IHdoZW4gd2Ugc3RhcnQgYSBuZXcgcHJvamVjdCwg
dGhlIG91dGNvbWUgaXMgYWx3YXlzIGNvbnRyYWRpY3RpbmcuDQpCdXQsPGJyPg0KJmd0OyB3ZSB0
cnkgYW55d2F5ISA7LSkpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlIGVudmlzaW9uIHRvIGNyZWF0
ZSBwcm9ncmFtbWFibGUgbmV0d29yayBBUEkncywgYnkgYWRhcHRpbmcgYm90aDxicj4NCiZndDsg
bmV0d29ya2luZyBhbmQgYXBwbGljYXRpb24gdGVjaG5pcXVlcy4gV2Ugd2lsbCBsZXZlcmFnZSB0
aGUgZXhpc3Rpbmc8YnI+DQomZ3Q7IG5ldHdvcmtpbmcgdGVjaG5vbG9naWVzLCBkZXNpZ25lZCBh
bmQgZGVmaW5lZCBpbiBJRVRGLCB0byBjcmVhdGUsPGJyPg0KJmd0OyBtb25pdG9yIGFuZCBkaXNj
b3ZlciBuZXR3b3JrIHJlc291cmNlcywgc2VydmljZXMgYW5kIGNvbm5lY3Rpb25zLg0KQW5kIHdl
PGJyPg0KJmd0OyB3aWxsIGxldmVyYWdlIHRoZSBzY2FsYWJsZSBhbmQgc2VjdXJlIG1lc3NhZ2Ug
cHJvY2Vzc2luZyBjYXBhYmlsaXR5DQpmcm9tPGJyPg0KJmd0OyBXZWIgKG9yIG92ZXIgcG9ydC04
MCkgZm9yIEFQSSdzLjxicj4NCiZndDsgPGJyPg0KJmd0OyAoMykgRXhhbXBsZXMgKGJlIG1vcmUg
c3BlY2lmaWMpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5ldHdvcmsgcHJvZ3JhbW1hYmlsaXR5IGFw
cGxpZXMgaW4gbWFueSBwbGFjZXMsIGFuZCB3ZSBzZWUgYSBmZXc8YnI+DQomZ3Q7IGFwcGxpY2F0
aW9ucyBuZWVkIHRvIGJlIHNvbHZlZCByZWFsIGZhc3QuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZp
cnN0LCB0aGUgVk0gbmV0d29yayBpbnRlcmZhY2UgaXMgVkxBTi4gQXMgc3VjaCwgYW55IFZNIG5l
dHdvcmstbGV2ZWw8YnI+DQomZ3Q7IHNlcnZpY2UgbWFuaXB1bGF0aW9uIG5lZWQgdG8gYmUgYWNj
b21wbGlzaGVkIHRocm91Z2ggdGhlIG1hbmFnZW1lbnQNCmF0PGJyPg0KJmd0OyBWTEFOLWdyYW51
bGFyaXR5LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgRm9yIGV4YW1wbGUsIGlmIFZNIGFwcGxpY2F0
aW9ucyByZXF1aXJlIG5vbi1kaXNydXB0aXZlIHNlcnZpY2VzLCB0aGU8YnI+DQomZ3Q7IHNlcnZp
Y2Ugb3BlcmF0b3JzIG1heSBtYXAgdGhlIFZNJ3MgdG8gdGhlIG5ldHdvcmsgbGlua3Mgd2l0aCBi
YW5kd2lkdGgsPGJyPg0KJmd0OyBkZWxheSBhbmQgcHJvdGVjdGlvbiBjb25zdHJhaW50cywgYnkg
dXRpbGl6aW5nIE1QTFMgYW5kIEZSUiB0byBhY2hpZXZlPGJyPg0KJmd0OyBuZXR3b3JrLXdpZGUg
c3VwcG9ydC48YnI+DQomZ3Q7IDxicj4NCiZndDsgQW5vdGhlciBleGFtcGxlIGlzIGluIHN1cHBv
cnRpbmcgZW50ZXJwcmlzZSBWUE4ncy4gSW4gdGhpcyBzY2VuYXJpbywNCnRoZTxicj4NCiZndDsg
c2VydmljZSBvcGVyYXRvcnMgbWF5IGJ1bmRsZSB0aGUgcmVsZXZhbnQgVk0ncyB0byB0aGUgY29y
cmVzcG9uZGluZw0KTVBMUzxicj4NCiZndDsgVlBOJ3MuIEFsbCB0aGUgdGVjaG5pcXVlcyBkZWZp
bmVkIGluIElFVEYgY2FuIGJlIHJlYWRpbHkgdXNlZCB0byBzdXBwb3J0PGJyPg0KJmd0OyBWTSBt
b2JpbGl0eSBhbmQgc2VydmljZSBzZWN1cml0eSBoZXJlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBB
bm90aGVyIGFyZWEgd2UgbmVlZCB0byB0byBsb29rIGF0IGlzIGluIHRoZSBhcmVhIG9mIHZpZGVv
L21lZGlhPGJyPg0KJmd0OyBzZXJ2aWNlcy4gT1RUIHZpZGVvIHNlcnZpY2VzIHdpbGwgbGlrZWx5
IHN0b3JlIHRoZSBjb250ZW50IG9uIHRoZQ0KZGF0YTxicj4NCiZndDsgY2VudGVycywgYW5kIHV0
aWxpemUgbG9jYWwgQ0ROJ3MgZm9yIGRlbGl2ZXJ5ICh0YWtlIGEgbG9vayBhdCBOZXRmbGl4KS48
YnI+DQomZ3Q7IFRoZSBjb250ZW50IG1heSBiZSByZXBsaWNhdGVkIGZyb20gZGF0YSBjZW50ZXIg
dG8gZGF0YSBjZW50ZXIsIGFuZA0KQ0ROJ3M8YnI+DQomZ3Q7IG1heSB1dGlsaXplIGRpZmZlcmVu
dCBkaXN0cmlidXRlIHRlY2huaXF1ZXMuIEhvd2V2ZXIsIHRoZSBzZXJ2aWNlPGJyPg0KJmd0OyBv
cGVyYXRvcnMgbWF5IG1hcCB0aGUgKGxvZ2ljYWwpIGNvbnRlbnQgdG8gdGhlIGFjdHVhbCBkaXN0
cmlidXRpb248YnI+DQomZ3Q7IGVuZ2luZXMgd2l0aCBzZXJ2aWNlIGd1YXJhbnRlZXMuIEkga25v
dyBzb21lIG9mIHRoZSB3b3JrIGhhczxicj4NCiZndDsgYmVlbiBkaXNjdXNzZWQgaW4gQUxUTywg
c28gbGV0J3Mgd29yayB0b2dldGhlciB0aGVyZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgU2Vydmlj
ZSBtb25pdG9yaW5nIGlzIGFub3RoZXIgaW1wb3J0YW50IGFzcGVjdCBvZiB0aGUgd29yay4gRWFj
aCB3ZWI8YnI+DQomZ3Q7IHNlcnZpY2UgaXMgc3VwcG9ydGVkIGJ5IG1hbnkgYmFjay1lbmQgYXBw
bGljYXRpb25zLCB3aGljaCBtYXkgb3BlcmF0ZWQ8YnI+DQomZ3Q7IGluIGRpZmZlcmVudCBsb2Nh
dGlvbnMuIFRvIGhhdmUgYSByb2J1c3Qgc2VydmljZSwgdGhlIHNlcnZpY2Ugb3BlcmF0b3JzPGJy
Pg0KJmd0OyBuZWVkIHRvIGhhdmUgYSB3YXkgdG8gbW9uaXRvciBhbmQgZ3VhcmFudGVlIG5ldHdv
cmstc2VydmljZXMgdG8gdGhvc2U8YnI+DQomZ3Q7IHNlcnZpY2VzLjxicj4NCiZndDsgPGJyPg0K
Jmd0OyBJbiBzdW1tYXJ5LCB3ZSBlbnZpc2lvbiBTRE4gd29yayB0byBicmlkZ2UgdGhlIGdhcCBi
ZXR3ZWVuIHRoZTxicj4NCiZndDsgYXBwbGljYXRpb25zIGFuZCB0aGUgbmV0d29yay4gSW4gdGhl
IGZ1dHVyZSwgd2UgbWF5IGFkZHJlc3M8YnI+DQomZ3Q7IGludGVyLW5ldHdvcmtpbmcgY29uY2Vy
bnMuIEhvd2V2ZXIsIG11Y2ggb2YgdGhlIG5ldHdvcmtpbmctbGV2ZWwgd29yazxicj4NCiZndDsg
Y2FuIGJlIHNvbHZlZCB3aXRoIGEgYmV0dGVyIE9TUy4gSSdkIHByZWZlciB0byBzb2x2ZSB0aGU8
YnI+DQomZ3Q7IGFwcGxpY2F0aW9uLW5ldHdvcmsgaW50ZXJmYWNpbmcgaXNzdWVzIGZpcnN0Ljxi
cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICg0KSBOZXh0IFN0ZXBzPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IEkgaGF2ZSBhbiBvbGQtc2Nob29sIHdoZW4gaXQgY29tZXMgdG8gdGhpczogcnVu
bmluZyBjb2RlIGFuZCByb3VnaDxicj4NCiZndDsgY29uc2Vuc3VzITxicj4NCiZndDsgPGJyPg0K
Jmd0OyBJbiB0aGUgY29taW5nIHdlZWtzLCB3ZSB3b3VsZCBsaWtlIHRvIGNvbGxlY3QgbW9yZSB1
c2UgY2FzZXMsPGJyPg0KJmd0OyBjb2xsYWJvcmF0ZSB3aXRoIG1hbnksIGxlYXJuIGZyb20gZWFj
aCBvdGhlci4gQXQgdGhlIGVuZCwgd2Ugc2hvdWxkDQpwdXQ8YnI+DQomZ3Q7IHRvZ2V0aGVyIHRo
ZSBhcmNoaXRlY3R1cmUsIHByb3RvY29sIGRlc2lnbiBhbmQgaG9wZWZ1bGx5IHNvbWUgcHJvdG90
eXBlcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgSG9wZSB0aGlzIG1ha2VzIHNlbnNlLjxicj4NCiZn
dDsgPGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0gUGluZzxi
cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIFdlZCwgSnVsIDI3LCAyMDExIGF0IDI6
MzIgUE0sIEJpdGFyLCBOYWJpbCBOPGJyPg0KJmd0OyAmbHQ7bmFiaWwubi5iaXRhckB2ZXJpem9u
LmNvbSAmbHQ7bWFpbHRvOm5hYmlsLm4uYml0YXJAdmVyaXpvbi5jb20mZ3Q7Jmd0Ow0Kd3JvdGU6
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBJIHRoaW5rIGR1
cmluZyB0aGUgbWVldGluZyBhIGdvb2Qgc3BlY3RydW0gb2YgdXNlIGNhc2VzDQp3YXM8YnI+DQom
Z3Q7ICZuYnNwOyAmbmJzcDsgZGlzY3Vzc2VkIHJhZ2luZyBmcm9tIGRhdGEgY2VudGVyIHR5cGUg
YXBwbGljYXRpb25zDQp0byB0aGUgY2FzZSBvZjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBpbnRl
ci1wcm92aWRlciBjb25uZWN0aW9uIHNldHVwIG9yIHBvbGljeSB0cmFuc2Zlci4NCiZuYnNwO0l0
IHNlZW1zIHRoYXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdGhlcmUgaXMgYSBuZWVkIHRvIHB1
dCBkb3duIHRoZSB1c2UgY2FzZXMgb24gcGFwZXIgYW5kDQpzZWUgd2hhdDxicj4NCiZndDsgJm5i
c3A7ICZuYnNwOyBleGlzdGluZyBtZWNoYW5pc21zIGNhbiBiZSB1c2VkIHRvIGFkZHJlc3MgdGhl
c2UgdXNlDQpjYXNlcyBhbmQgd2h5PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHRoZXJlIGlzIG5l
dyB3b3JrIG5lZWRlZC4gSXMgaXQgZnJlc2ggbmV3IHdvcmsgb3IgZXh0ZW5zaW9ucw0KdG88YnI+
DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZXhpc3RpbmcgbWVjaGFuaXNtcz8gJm5ic3A7V2hhdCBhcmUg
dGhlIGdhcHMgJm5ic3A7aW4NCndoYXQgZXhpc3RzIGlzIGJlaW5nPGJyPg0KJmd0OyAmbmJzcDsg
Jm5ic3A7IHNvbHZlZD8gSXQgaXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgaXMgb25lIGhh
bW1lcg0KdGhhdCB3aWxsIGJlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGFibGUgdG8gYWRkcmVz
cyBhbGwgdGhlIHVzZSBjYXNlcyAsIGFuZCBpZiBuZWVkZWQsIHdpdGhvdXQ8YnI+DQomZ3Q7ICZu
YnNwOyAmbmJzcDsgcmVjcmVhdGluZyB0aGUgd2hlZWwgb3IgYWRkaW5nIGNvbXBsZXhpdGllcyBv
ciBkZWZpY2llbmNpZXMNCiZuYnNwO1RoYXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgbWF5IGJl
IGJpYXNlZCBieSB0aGUgdmlldyBJIGhhZCB3YWxraW5nIGludG8gdGhlIG1lZXRpbmcNCnRoYXQg
dGhlcmU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgd2FzIHRlbmRlbmN5IHRvIGZvY3VzIG9uIHRo
ZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgYXBwbGljYXRpb24NCmFuZDxicj4NCiZndDsgJm5ic3A7
ICZuYnNwOyB0aGUgU0ROIGNvbnRyb2xsZXIgJm5ic3A7dG8gcmVxdWVzdCByZXNvdXJjZXMgbWF5
YmUNCnN1YmplY3QgdG88YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uc3RyYWludHMs
IHRvIHJlY2VpdmUgaW5mb3JtYXRpb24sIHJlc3BvbnNlDQp0byBhIHJlcXVlc3QgYW5kL29yPGJy
Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IG5vdGlmaWNhdGlvbiAmbmJzcDtmcm9tIHRoZSBTRE4gY29u
dHJvbGxlci4gV2hhdCB0aGUNClNETiBjb250cm9sbGVyIGRvZXM8YnI+DQomZ3Q7ICZuYnNwOyAm
bmJzcDsgbWF5IGNhcGl0YWxpemUgb24gZXhpc3RpbmcgbWVjaGFuaXNtcyB3aGljaCB3aWxsIGJl
DQpkZXBlbmRlbnQgb24gdGhlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHVzZSBjYXNlIGFuZCB0
aGUgbmF0dXJlIG9mIHRoZSBhcHBsaWNhdGlvbiByZXF1ZXN0Lg0KJm5ic3A7V2hpbGUgdGhlPGJy
Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IGludGVyZmFjZSBjYW4gYmUgZ2VuZXJpYyAmbmJzcDthbmQg
ZXh0ZW5zaWJsZSwgdGhlIHVzZQ0KY2FzZSBvcjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBhcHBs
aWNhdGlvbiB3aWxsIGRyaXZlIHdoYXQgaW5mb3JtYXRpb24gaXMgZXhjaGFuZ2VkLjxicj4NCiZn
dDsgJm5ic3A7ICZuYnNwOyBJIGFwcHJlY2lhdGUgYSBjbGFyaWZpY2F0aW9uIGlmIGFsbCB0aGUg
dGhlIGZvbGxvd2luZw0Kc3RpbGwgYXQgcGxheTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBoZXJl
IG9yIHNvbWV0aGluZyB3YXMgcHJ1bmVkIG91dCBvciB0b28gZWFybHkgdG8gcHJ1bmU6PGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzEuIGFwcGxpY2F0aW9u
IC1TRE4gY29udHJvbGxlciBpbnRlcmZhY2UuDQpXaGF0IGlzIHRoZSBmdW5jdGlvbiBvZjxicj4N
CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGF0IGludGVyZmFjZSBp
cyBnb2luZyB0byBiZSBhcHBsaWNhdGlvbg0KZGVwZW5kZW50LiBUaGF0IGdvZXM8YnI+DQomZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9yIG90aGVyIGludGVyZmFjZXM8
YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIuIFNETiBjb250cm9sbGVyLVNE
TiBpbnRlcmZhY2U8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzMuIFNETiBj
b250cm9sbGVyLVNETiBjb250cm9sbGVyIGludGVyZmFjZTxicj4NCiZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7NC4gUGF0aCBjb21wdXRhdGlvbiAobm90IG5lY2Vzc2FyaWx5IFRFDQop
IGZvciBhIHR1bm5lbCBvcjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyBtaWNyb2Zsb3cgYmFzZWQgb24gY2VydGFpbiBjb25zdHJhaW50cy4NCjxicj4NCiZndDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7NS4gZmxvdyBtYXBwaW5nIHRvIGEgcGF0aCwgaW5j
bHVkaW5nIGZsb3cNCmNsYXNzaWZpY2F0aW9uIGFuZDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyBjb25maWd1cmF0aW9uIG9uIGV2ZXJ5IGhvcC48YnI+DQomZ3Q7
IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBUaGFua3MsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7
IE5hYmlsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEZyb206IFRob21hcyBOYWRlYXUgJmx0O3Ru
YWRlYXVAbHVjaWR2aXNpb24uY29tPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86
dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20mZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBE
YXRlOiBXZWQsIDI3IEp1bCAyMDExIDExOjI5OjIwIC0wNDAwPGJyPg0KJmd0OyAmbmJzcDsgJm5i
c3A7IFRvOiAmcXVvdDtPbmcsIEx5bmRvbiZxdW90OyAmbHQ7THlvbmdAQ2llbmEuY29tICZsdDtt
YWlsdG86THlvbmdAQ2llbmEuY29tJmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgQ2M6
ICZxdW90O3NkbnBAbHVjaWR2aXNpb24uY29tICZsdDttYWlsdG86c2RucEBsdWNpZHZpc2lvbi5j
b20mZ3Q7JnF1b3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZsdDtzZG5wQGx1Y2lkdmlzaW9u
LmNvbSAmbHQ7bWFpbHRvOnNkbnBAbHVjaWR2aXNpb24uY29tJmd0OyZndDs8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgJm5ic3A7ICZuYnNwOyBTdWJqZWN0OiBSZTogW1NkbnBdIG9uZSBvciB0d28gYmxh
bmsgbG9va3Mgb24gaW50LXNlcnYNCnJlZmVyZW5jZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBk
dXJpbmcgdGhlIGJhciBib2Y8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IE9uIEp1bCAyNywgMjAxMSwg
YXQgMTE6MTUgQU0sICZxdW90O09uZywgTHluZG9uJnF1b3Q7DQombHQ7THlvbmdAQ2llbmEuY29t
PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86THlvbmdAQ2llbmEuY29tJmd0OyZn
dDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IEhpIEd1eXMs
X19fXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxicj4N
CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBSZWdhcmRpbmcgKDIpLCBpZiB3
ZaGvcmUgYWdub3N0aWMgdGhlbiB0aGlzIHdvcmsNCnNlZW1zIHRvIGJlIG1vcmU8YnI+DQomZ3Q7
Jmd0OyAmbmJzcDsgJm5ic3A7IGdlbmVyYWwsIGl0IGNvdWxkIGFwcGx5IHRvIE9GLWNvbnRyb2xs
ZWQgbmV0d29ya3MsPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBNUExTL0dNUExTLWNvbnRy
b2xsZWQgbmV0d29ya3MsIFBDRS9ub24tUENFLCBldGMuX19fXzxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
Jm5ic3A7ICZuYnNwOyBSZWdhcmRpbmcgKDMpIG5vdCBzdXJlIHRoYXQgdGhpcyBmb2xsb3dzIKhD
IGluDQphIGxvdCBvZiB0aGUgY29udHJvbDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgcGxh
bmUgdGVjaG5vbG9naWVzIHRoZXJlIGlzIGEgd2F5IHRvIGNvbnRyb2wgdGhlDQpwYXRoLiAmbmJz
cDtRdWVzdGlvbiw8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IHRob3VnaCwgaG93IG11Y2gg
ZG9lcyBhbiBhcHBsaWNhdGlvbiBuZWVkIHRvIGtub3cNCmFib3V0IHRoZSBwYXRoPzxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgSSB0aGluayB0aGF0IGRl
cGVuZHMgb24gd2hhdCB0aGUgYXBwbGljYXRpb24gaXMgYW5kDQp3aGF0IGl0J3M8YnI+DQomZ3Q7
ICZuYnNwOyAmbmJzcDsgcHVycG9zZSBpcy4gSXQgbWF5IGJlIGludGVyZXN0ZWQgaW4gbmV0d29y
ayByZXNvdXJjZXMNCm90aGVyIHRoYW48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsganVzdCBsaW5r
cyBhbmQgcGF0aHMuIEFsc28sIGFzIERhbm55IG1lbnRpb25lZCBpbiBoaXMNCnVzZSBjYXNlPGJy
Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IHllc3RlcmRheSB0aGVyZSBpcyBhIG5lZWQgZm9yIHZhcnlp
bmcgbGV2ZWxzIG9mIGdyYW51bGFyaXR5DQpoZXJlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5i
c3A7ICZuYnNwOyBUb208YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgX19f
Xzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBDaGVlcnMsX19fXzxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyBMeW5kb25fX19fPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0OyAmbmJzcDsgJm5ic3A7IF9fIF9fPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJz
cDsgJm5ic3A7IEJUVywgdGhlIGNvbXBhcmlzb24gdG8gaW50c2VydiByZW1pbmRzIG1lIHRoYXQg
d2hlbg0KSSB0cnkgdG88YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IGV4cGxhaW4gT0YgdG8g
cGVvcGxlLCB0aGV5IGNvbW1vbmx5IGFzayB3aHkgdGhpcw0KaXMgZGlmZmVyZW50IGZyb208YnI+
DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IEZPUkNFUyFfX19fPGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IF9fIF9fPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJmx0O2ltYWdlYjU4ZTllLmdpZkBiNjQ0NmEzZC4y
NGQ0NDk3Yjxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzppbWFnZWI1OGU5
ZS5naWZAYjY0NDZhM2QuMjRkNDQ5N2ImZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsgJm5ic3A7ICZuYnNwOyAqRnJvbToqIHNkbnAtYm91bmNlc0BsdWNpZHZpc2lvbi5jb208YnI+
DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86c2RucC1ib3VuY2VzQGx1Y2lkdmlz
aW9uLmNvbSZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IFttYWlsdG86c2RucC1ib3Vu
Y2VzQGx1Y2lkdmlzaW9uLmNvbV0gKk9uIEJlaGFsZg0KT2YgKkVkd2FyZCBDcmFiYmU8YnI+DQom
Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICpTZW50OiogV2VkbmVzZGF5LCBKdWx5IDI3LCAyMDExIDc6
MjMgQU08YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICpUbzoqIFBpbmcgUGFuPGJyPg0KJmd0
OyZndDsgJm5ic3A7ICZuYnNwOyAqQ2M6KiAmbHQ7bWFpbHRvOnNkbnBAbHVjaWR2aXNpb24uY29t
Jmd0O3NkbnBAbHVjaWR2aXNpb24uY29tPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbHQ7
bWFpbHRvOnNkbnBAbHVjaWR2aXNpb24uY29tJmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJz
cDsgKlN1YmplY3Q6KiBSZTogW1NkbnBdIG9uZSBvciB0d28gYmxhbmsgbG9va3Mgb24NCmludC1z
ZXJ2IHJlZmVyZW5jZTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgZHVyaW5nIHRoZSBiYXIg
Ym9mX19fXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxi
cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE91ciBnb2FsIGhl
cmUgaXMgdG8gc29sdmUgYSBzcGVjaWZpYw0KcHJvYmxlbTogbWFwIGFwcGxpY2F0aW9uPGJyPg0K
Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZsb3dzIChpbiB3aGF0ZXZlciB0
aGUgZm9ybSkgaW50bw0KcGh5c2ljYWwgbmV0d29yayB0dW5uZWxzLl9fX188YnI+DQomZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyB0aHJlZSB0aGluZ3MgaGVyZTogX19fXzxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAxKSBzbyBiYXNpY2FsbHksIHlvdSdyZSBzYXlpbmcg
eW91IHdhbnQgYSBjb21tb24NCmxhbmd1YWdlIHRvPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDtidWlsZCBhIEZFQywgbWFwcGluZyBhIHNldCBvZiBuLXR1cGxlIG1hdGNoZXMNCih2
bGFuLCB3aGF0ZXZlcik8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IGludG8gYSBzcGVjaWZp
YyBlbmNhcHN1bGF0aW9uP19fX188YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAm
bmJzcDsgX18gX188YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgMikg
YXJlIHRoZXNlIHR1bm5lbHMgcHJlLWV4aXN0aW5nPyAmbmJzcDtpZiBzbywNCmZpbmUsIGlmIG5v
dCwgd2Ugbm93PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBoYXZlIHRvIHNldCB1cCB0aGUg
dHVubmVsLCBhdCB3aGljaCBwb2ludCB3ZSdyZQ0KYmFjayB0byBkZWFsaW5nPGJyPg0KJmd0OyZn
dDsgJm5ic3A7ICZuYnNwOyB3aXRoIGVpdGhlciBPRiB0eXBlIHBlciBob3Agc3RhdGUgc2V0dXAg
b3IgYW4gZXhpc3RpbmcNCmVuZCB0bzxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgZW5kIHNp
Z25hbGluZyBwcm90b2NvbCAoYW5kICZuYnNwO3dlJ3JlIGRlYWxpbmcNCndpdGggdGhpbmdzIGF0
IGEgcGVyPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBob3N0LCBhcHAgbGV2ZWw/ICZuYnNw
O1RodXMgdGhlICZuYnNwO2ludC1zZXJ2IHJlZmVyZW5jZQ0KOy0pLiAmbmJzcDtQZXJoYXBzIHRo
ZTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgaWRlYSBpcyB0byBiZSBhZ25vc3RpYyByZWdh
cmRpbmcgcGF0aCBzZXR1cCBtZXRob2QNCmhlcmU/X19fXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5i
c3A7ICZuYnNwOyAzKSB3b3VsZCB0aGlzIGFsc28gaW1wbHkgdGhhdCB0aGF0IGRlZmluaXRpb24g
b2YNCnRoZTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgY2hhcmFjdGVyaXN0aWNzLCBpbmNs
dWRpbmcgcGF0aCwgJm5ic3A7dGhhdCB0aGUNCnR1bm5lbCB0YWtlcyBvdmVyIHRoZTxicj4NCiZn
dDsmZ3Q7ICZuYnNwOyAmbmJzcDsgdW5kZXJseWluZyBpbmZyYXN0cnVjdHVyZSBpcyBpbiBzY29w
ZT9fX19fPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IF9fIF9fPGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fX188YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBObyBuZWVk
IGluIGxpbWl0aW5nIGFwcGxpY2F0aW9ucywNCmFuZCBubyBuZWVkIGluIG1ha2luZzxicj4NCiZn
dDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBuZXR3b3JrIHNtYXJ0ZXIgKG9yIGR1
bWJlcikuIDstKTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19f
PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
X18gX188YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyBUaGFua3MhX19fXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IF9fIF9fPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLSBQaW5nPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE9uIFR1ZSwgSnVsIDI2LCAyMDExIGF0IDc6
MjggUE0sIEVkd2FyZA0KQ3JhYmJlICZsdDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJmx0O21haWx0bzplZGNAZ29vZ2xlLmNvbSZndDtlZGNAZ29vZ2xlLmNvbQ0K
Jmx0O21haWx0bzplZGNAZ29vZ2xlLmNvbSZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7IHdyb3RlOl9fX188YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvciByZWZlcmVuY2Us
IHdhcyByZWZlcnJpbmcNCnRvOl9fX188YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fIF9fPGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bHQ7aHR0cDovL3Rvb2xzLmlldGYub3JnL3JmYy9yZmMyMjEwLnR4dCZndDtodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvcmZjL3JmYzIyMTAudHh0X19fXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX18gX188YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IF9fIF9fPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfXyBfXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTRE5QIG1haWxpbmcgbGlzdDxicj4NCiZn
dDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttYWls
dG86U0ROUEBsdWNpZHZpc2lvbi5jb20mZ3Q7U0ROUEBsdWNpZHZpc2lvbi5jb208YnI+DQomZ3Q7
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRv
OlNETlBAbHVjaWR2aXNpb24uY29tJmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtodHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxt
YW4vbGlzdGluZm8vc2RucCZndDtodHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxtYW4vbGlzdGlu
Zm8vc2RucF9fX188YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyBfXyBfXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNw
OyBfXyBfXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsg
Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBTRE5QIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7
ICZuYnNwOyAmbmJzcDsgU0ROUEBsdWNpZHZpc2lvbi5jb20gJmx0O21haWx0bzpTRE5QQGx1Y2lk
dmlzaW9uLmNvbSZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IGh0dHA6Ly9sdWNpZHZp
c2lvbi5jb20vbWFpbG1hbi9saXN0aW5mby9zZG5wPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNw
OyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgU0ROUCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZuYnNw
OyAmbmJzcDsgU0ROUEBsdWNpZHZpc2lvbi5jb20gJmx0O21haWx0bzpTRE5QQGx1Y2lkdmlzaW9u
LmNvbSZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgaHR0cDovL2x1Y2lkdmlzaW9uLmNvbS9t
YWlsbWFuL2xpc3RpbmZvL3NkbnA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQomZ3Q7IFNETlAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBTRE5QQGx1Y2lk
dmlzaW9uLmNvbTxicj4NCiZndDsgaHR0cDovL2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFuL2xpc3Rp
bmZvL3NkbnA8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCnZucmcgbWFpbGluZyBsaXN0PGJyPg0Kdm5yZ0BpcnRmLm9yZzxicj4NCmh0dHBz
Oi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vdm5yZzxicj4NCjxicj4NCjwvZm9udD48
L3R0Pg0KPGJyPg0K
--=_alternative 000F3B39482578E0_=--

From dmm@1-4-5.net  Mon Aug  1 09:31:59 2011
Return-Path: <dmm@1-4-5.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 F1D6F21F8E4C for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 09:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 5h7dzSEIpwvS for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 09:31:57 -0700 (PDT)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 819D621F8E54 for <vnrg@irtf.org>; Mon,  1 Aug 2011 09:31:57 -0700 (PDT)
Received: by pzk2 with SMTP id 2so12475416pzk.9 for <vnrg@irtf.org>; Mon, 01 Aug 2011 09:32:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.54.164 with SMTP id k4mr7548919pbp.310.1312216322706; Mon, 01 Aug 2011 09:32:02 -0700 (PDT)
Received: by 10.68.55.35 with HTTP; Mon, 1 Aug 2011 09:32:02 -0700 (PDT)
X-Originating-IP: [128.223.156.117]
In-Reply-To: <4E36BE97.4030806@labn.net>
References: <CAHEV9L3avPiHVjBtttTL_7VbNeJ=Q=oegot2A_m8snN5vzNsgA@mail.gmail.com> <4E36BE97.4030806@labn.net>
Date: Mon, 1 Aug 2011 09:32:02 -0700
Message-ID: <CAHiKxWgzftY7g5B=FmNoKeRe4hjZ1Ahk6TyUuLLRGuos5SDWxQ@mail.gmail.com>
From: David Meyer <dmm@1-4-5.net>
To: Lou Berger <lberger@labn.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 02 Aug 2011 05:53:00 -0700
Cc: "sdnp@lucidvision.com" <sdnp@lucidvision.com>, Ping Pan <ping@pingpan.org>, 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 16:31:59 -0000

On Mon, Aug 1, 2011 at 7:56 AM, Lou Berger <lberger@labn.net> wrote:
> Ping,
> =A0 =A0 =A0 =A0Nice intro/overview. =A0So how does this effort relate to =
the VNRG
> (http://irtf.org/vnrg, also cross-posted)? =A0Seems 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 he=
re:
>>
>> (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:
>>
>>
>> =A0 =A0 I think during the meeting a good spectrum of use cases was
>> =A0 =A0 discussed raging from data center type applications to the case =
of
>> =A0 =A0 inter-provider connection setup or policy transfer. =A0It seems =
that
>> =A0 =A0 there is a need to put down the use cases on paper and see what
>> =A0 =A0 existing mechanisms can be used to address these use cases and w=
hy
>> =A0 =A0 there is new work needed. Is it fresh new work or extensions to
>> =A0 =A0 existing mechanisms? =A0What are the gaps =A0in what exists is b=
eing
>> =A0 =A0 solved? It is not clear to me that there is one hammer that will=
 be
>> =A0 =A0 able to address all the use cases , and if needed, without
>> =A0 =A0 recreating the wheel or adding complexities or deficiencies =A0T=
hat
>> =A0 =A0 may be biased by the view I had walking into the meeting that th=
ere
>> =A0 =A0 was tendency to focus on the interface between the application a=
nd
>> =A0 =A0 the SDN controller =A0to request resources maybe subject to
>> =A0 =A0 =A0constraints, to receive information, response to a request an=
d/or
>> =A0 =A0 notification =A0from the SDN controller. What the SDN controller=
 does
>> =A0 =A0 may capitalize on existing mechanisms which will be dependent on=
 the
>> =A0 =A0 use case and the nature of the application request. =A0While the
>> =A0 =A0 interface can be generic =A0and extensible, the use case or
>> =A0 =A0 application will drive what information is exchanged.
>> =A0 =A0 I appreciate a clarification if all the the following still at p=
lay
>> =A0 =A0 here or something was pruned out or too early to prune:
>>
>> =A0 =A0 =A0 =A01. application -SDN controller interface. What is the fun=
ction of
>> =A0 =A0 =A0 =A0 =A0 that interface is going to be application dependent.=
 That goes
>> =A0 =A0 =A0 =A0 =A0 for other interfaces
>> =A0 =A0 =A0 =A02. SDN controller-SDN interface
>> =A0 =A0 =A0 =A03. SDN controller-SDN controller interface
>> =A0 =A0 =A0 =A04. Path computation (not necessarily TE ) for a tunnel or
>> =A0 =A0 =A0 =A0 =A0 microflow based on certain constraints.
>> =A0 =A0 =A0 =A05. flow mapping to a path, including flow classification =
and
>> =A0 =A0 =A0 =A0 =A0 configuration on every hop.
>>
>> =A0 =A0 Thanks,
>> =A0 =A0 Nabil
>> =A0 =A0 From: Thomas Nadeau <tnadeau@lucidvision.com
>> =A0 =A0 <mailto:tnadeau@lucidvision.com>>
>> =A0 =A0 Date: Wed, 27 Jul 2011 11:29:20 -0400
>> =A0 =A0 To: "Ong, Lyndon" <Lyong@Ciena.com <mailto:Lyong@Ciena.com>>
>> =A0 =A0 Cc: "sdnp@lucidvision.com <mailto:sdnp@lucidvision.com>"
>> =A0 =A0 <sdnp@lucidvision.com <mailto:sdnp@lucidvision.com>>
>>
>> =A0 =A0 Subject: Re: [Sdnp] one or two blank looks on int-serv reference
>> =A0 =A0 during the bar bof
>>
>>
>>
>>
>>
>> =A0 =A0 On Jul 27, 2011, at 11:15 AM, "Ong, Lyndon" <Lyong@Ciena.com
>> =A0 =A0 <mailto:Lyong@Ciena.com>> wrote:
>>
>>> =A0 =A0 Hi Guys,____
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 Regarding (2), if we=92re agnostic then this work seems to be m=
ore
>>> =A0 =A0 general, it could apply to OF-controlled networks,
>>> =A0 =A0 MPLS/GMPLS-controlled networks, PCE/non-PCE, etc.____
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 Regarding (3) not sure that this follows =96 in a lot of the co=
ntrol
>>> =A0 =A0 plane technologies there is a way to control the path. =A0Quest=
ion,
>>> =A0 =A0 though, how much does an application need to know about the pat=
h?
>>>
>>
>> =A0 =A0 I think that depends on what the application is and what it's
>> =A0 =A0 purpose is. It may be interested in network resources other than
>> =A0 =A0 just links and paths. Also, as Danny mentioned in his use case
>> =A0 =A0 yesterday there is a need for varying levels of granularity here=
.
>>
>> =A0 =A0 Tom
>>
>>> =A0 =A0 ____
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 Cheers,____
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 Lyndon____
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 BTW, the comparison to intserv reminds me that when I try to
>>> =A0 =A0 explain OF to people, they commonly ask why this is different f=
rom
>>> =A0 =A0 FORCES!____
>>>
>>> =A0 =A0 __ __
>>>
>>>
>>> =A0 =A0 <imageb58e9e.gif@b6446a3d.24d4497b
>>> =A0 =A0 <mailto:imageb58e9e.gif@b6446a3d.24d4497b>>
>>>
>>> =A0 =A0 *From:* sdnp-bounces@lucidvision.com
>>> =A0 =A0 <mailto:sdnp-bounces@lucidvision.com>
>>> =A0 =A0 [mailto:sdnp-bounces@lucidvision.com] *On Behalf Of *Edward Cra=
bbe
>>> =A0 =A0 *Sent:* Wednesday, July 27, 2011 7:23 AM
>>> =A0 =A0 *To:* Ping Pan
>>> =A0 =A0 *Cc:* <mailto:sdnp@lucidvision.com>sdnp@lucidvision.com
>>> =A0 =A0 <mailto:sdnp@lucidvision.com>
>>> =A0 =A0 *Subject:* Re: [Sdnp] one or two blank looks on int-serv refere=
nce
>>> =A0 =A0 during the bar bof____
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 =A0 =A0 Our goal here is to solve a specific problem: map appli=
cation
>>> =A0 =A0 =A0 =A0 flows (in whatever the form) into physical network tunn=
els.____
>>>
>>> =A0 =A0 =A0 =A0 __ __
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 three things here: ____
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 1) so basically, you're saying you want a common language to
>>> =A0 =A0 =A0build a FEC, mapping a set of n-tuple matches (vlan, whateve=
r)
>>> =A0 =A0 into a specific encapsulation?____
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 2) are these tunnels pre-existing? =A0if so, fine, if not, we n=
ow
>>> =A0 =A0 have to set up the tunnel, at which point we're back to dealing
>>> =A0 =A0 with either OF type per hop state setup or an existing end to
>>> =A0 =A0 end signaling protocol (and =A0we're dealing with things at a p=
er
>>> =A0 =A0 host, app level? =A0Thus the =A0int-serv reference ;-). =A0Perh=
aps the
>>> =A0 =A0 idea is to be agnostic regarding path setup method here?____
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 3) would this also imply that that definition of the
>>> =A0 =A0 characteristics, including path, =A0that the tunnel takes over =
the
>>> =A0 =A0 underlying infrastructure is in scope?____
>>>
>>> =A0 =A0 __ __
>>>
>>> =A0 =A0 =A0____
>>>
>>> =A0 =A0 =A0 =A0 No need in limiting applications, and no need in making
>>> =A0 =A0 =A0 =A0 network smarter (or dumber). ;-)
>>> =A0 =A0 =A0 =A0 ____
>>>
>>> =A0 =A0 =A0 =A0 __ __
>>>
>>> =A0 =A0 =A0 =A0 Thanks!____
>>>
>>> =A0 =A0 =A0 =A0 __ __
>>>
>>> =A0 =A0 =A0 =A0 - Ping
>>>
>>> =A0 =A0 =A0 =A0 ____
>>>
>>> =A0 =A0 =A0 =A0 On Tue, Jul 26, 2011 at 7:28 PM, Edward Crabbe <
>>> =A0 =A0 =A0 =A0 <mailto:edc@google.com>edc@google.com <mailto:edc@googl=
e.com>>
>>> =A0 =A0 =A0 =A0 wrote:____
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 for reference, was referring to:____
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 __ __
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 <http://tools.ietf.org/rfc/rfc2210.txt>http://t=
ools.ietf.org/rfc/rfc2210.txt____
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 __ __
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 __ __
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 __ __
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 _______________________________________________
>>> =A0 =A0 =A0 =A0 =A0 =A0 SDNP mailing list
>>> =A0 =A0 =A0 =A0 =A0 =A0 <mailto:SDNP@lucidvision.com>SDNP@lucidvision.c=
om
>>> =A0 =A0 =A0 =A0 =A0 =A0 <mailto:SDNP@lucidvision.com>
>>> =A0 =A0 =A0 =A0 =A0 =A0 <http://lucidvision.com/mailman/listinfo/sdnp>h=
ttp://lucidvision.com/mailman/listinfo/sdnp____
>>>
>>> =A0 =A0 =A0 =A0 __ __
>>>
>>> =A0 =A0 __ __
>>>
>>>
>>> =A0 =A0 _______________________________________________
>>> =A0 =A0 SDNP mailing list
>>> =A0 =A0 SDNP@lucidvision.com <mailto:SDNP@lucidvision.com>
>>> =A0 =A0 http://lucidvision.com/mailman/listinfo/sdnp
>>
>> =A0 =A0 _______________________________________________
>> =A0 =A0 SDNP mailing list
>> =A0 =A0 SDNP@lucidvision.com <mailto:SDNP@lucidvision.com>
>> =A0 =A0 http://lucidvision.com/mailman/listinfo/sdnp
>>
>>
>>
>>
>> _______________________________________________
>> SDNP mailing list
>> SDNP@lucidvision.com
>> http://lucidvision.com/mailman/listinfo/sdnp
> _______________________________________________
> SDNP mailing list
> SDNP@lucidvision.com
> http://lucidvision.com/mailman/listinfo/sdnp
>

From ping@pingpan.org  Mon Aug  1 07:58:39 2011
Return-Path: <ping@pingpan.org>
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 3F08411E8073 for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 07:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.902
X-Spam-Level: 
X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.074,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Cjq6xBPHbxPk for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 07:58:37 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with SMTP id B5D5011E8070 for <vnrg@irtf.org>; Mon,  1 Aug 2011 07:58:36 -0700 (PDT)
Received: from mail-iy0-f181.google.com ([209.85.210.181]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTja/Ip6M0hYt7IqcyiUeznPJcwfCKDpB@postini.com; Mon, 01 Aug 2011 07:58:43 PDT
Received: by mail-iy0-f181.google.com with SMTP id 40so8331763iyf.12 for <vnrg@irtf.org>; Mon, 01 Aug 2011 07:58:42 -0700 (PDT)
Received: by 10.231.124.210 with SMTP id v18mr467091ibr.148.1312210721505; Mon, 01 Aug 2011 07:58:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.57.28 with HTTP; Mon, 1 Aug 2011 07:58:01 -0700 (PDT)
In-Reply-To: <4E36BE97.4030806@labn.net>
References: <CAHEV9L3avPiHVjBtttTL_7VbNeJ=Q=oegot2A_m8snN5vzNsgA@mail.gmail.com> <4E36BE97.4030806@labn.net>
From: Ping Pan <ping@pingpan.org>
Date: Mon, 1 Aug 2011 10:58:01 -0400
Message-ID: <CAHEV9L2=F+GkyE_JBUXehR6CpuHeZg7RKzM0qwN3DLOgfZh=6A@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Content-Type: multipart/alternative; boundary=0016e64761feed019f04a972dd00
X-Mailman-Approved-At: Tue, 02 Aug 2011 05:53:11 -0700
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 14:58:39 -0000

--0016e64761feed019f04a972dd00
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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 <lberger@labn.net> 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. Ou=
r
> > 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 plac=
e
> > 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 tim=
e
> > 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 w=
e
> > will leverage the scalable and secure message processing capability fro=
m
> > 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, th=
e
> > service operators may bundle the relevant VM's to the corresponding MPL=
S
> > VPN's. All the techniques defined in IETF can be readily used to suppor=
t
> > 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 prototype=
s.
> >
> > 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 th=
e
> >     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 o=
f
> >           that interface is going to be application dependent. That goe=
s
> >           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=92re 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 =96 in a lot of the contr=
ol
> >>     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
>

--0016e64761feed019f04a972dd00
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

This is not research, and we have no intention in forcing applications to a=
dapt network-operation=A0semantics.<div><br></div><div>The goal is having t=
he applications programming the network, without breaking it.<div><div><br>

</div>- Ping<br>
<br><br><div class=3D"gmail_quote">On Mon, Aug 1, 2011 at 10:56 AM, Lou Ber=
ger <span dir=3D"ltr">&lt;<a href=3D"mailto:lberger@labn.net">lberger@labn.=
net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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


&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 __ __<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 __ __<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 __ __<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 __________________________________________=
_____<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 SDNP mailing list<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 &lt;mailto:<a href=3D"mailto:SDNP@lucidvis=
ion.com">SDNP@lucidvision.com</a>&gt;<a href=3D"mailto:SDNP@lucidvision.com=
">SDNP@lucidvision.com</a><br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 &lt;mailto:<a href=3D"mailto:SDNP@lucidvis=
ion.com">SDNP@lucidvision.com</a>&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 &lt;<a href=3D"http://lucidvision.com/mail=
man/listinfo/sdnp" target=3D"_blank">http://lucidvision.com/mailman/listinf=
o/sdnp</a>&gt;<a href=3D"http://lucidvision.com/mailman/listinfo/sdnp____" =
target=3D"_blank">http://lucidvision.com/mailman/listinfo/sdnp____</a><br>


&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 __ __<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 __ __<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 _______________________________________________<br>
&gt;&gt; =A0 =A0 SDNP mailing list<br>
&gt;&gt; =A0 =A0 <a href=3D"mailto:SDNP@lucidvision.com">SDNP@lucidvision.c=
om</a> &lt;mailto:<a href=3D"mailto:SDNP@lucidvision.com">SDNP@lucidvision.=
com</a>&gt;<br>
<div class=3D"im">&gt;&gt; =A0 =A0 <a href=3D"http://lucidvision.com/mailma=
n/listinfo/sdnp" target=3D"_blank">http://lucidvision.com/mailman/listinfo/=
sdnp</a><br>
&gt;<br>
&gt; =A0 =A0 _______________________________________________<br>
&gt; =A0 =A0 SDNP mailing list<br>
</div>&gt; =A0 =A0 <a href=3D"mailto:SDNP@lucidvision.com">SDNP@lucidvision=
.com</a> &lt;mailto:<a href=3D"mailto:SDNP@lucidvision.com">SDNP@lucidvisio=
n.com</a>&gt;<br>
<div><div></div><div class=3D"h5">&gt; =A0 =A0 <a href=3D"http://lucidvisio=
n.com/mailman/listinfo/sdnp" target=3D"_blank">http://lucidvision.com/mailm=
an/listinfo/sdnp</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; SDNP mailing list<br>
&gt; <a href=3D"mailto:SDNP@lucidvision.com">SDNP@lucidvision.com</a><br>
&gt; <a href=3D"http://lucidvision.com/mailman/listinfo/sdnp" target=3D"_bl=
ank">http://lucidvision.com/mailman/listinfo/sdnp</a><br>
</div></div></blockquote></div><br></div></div>

--0016e64761feed019f04a972dd00--

From ping@pingpan.org  Mon Aug  1 08:14:23 2011
Return-Path: <ping@pingpan.org>
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 926EC21F8D40 for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 08:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.913
X-Spam-Level: 
X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.063,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 apbogDkb5cas for <vnrg@ietfa.amsl.com>; Mon,  1 Aug 2011 08:14:23 -0700 (PDT)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with SMTP id CF31B21F8D39 for <vnrg@irtf.org>; Mon,  1 Aug 2011 08:14:22 -0700 (PDT)
Received: from mail-yw0-f43.google.com ([209.85.213.43]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTjbC1M6nGjgO9OWm8N4pteFaqmvAdaN4@postini.com; Mon, 01 Aug 2011 08:14:29 PDT
Received: by ywt2 with SMTP id 2so1415577ywt.2 for <vnrg@irtf.org>; Mon, 01 Aug 2011 08:14:28 -0700 (PDT)
Received: by 10.42.108.198 with SMTP id i6mr221605icp.212.1312211668101; Mon, 01 Aug 2011 08:14:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.57.28 with HTTP; Mon, 1 Aug 2011 08:13:48 -0700 (PDT)
In-Reply-To: <4E36C14E.6080909@labn.net>
References: <CAHEV9L3avPiHVjBtttTL_7VbNeJ=Q=oegot2A_m8snN5vzNsgA@mail.gmail.com> <4E36BE97.4030806@labn.net> <CAHEV9L2=F+GkyE_JBUXehR6CpuHeZg7RKzM0qwN3DLOgfZh=6A@mail.gmail.com> <4E36C14E.6080909@labn.net>
From: Ping Pan <ping@pingpan.org>
Date: Mon, 1 Aug 2011 11:13:48 -0400
Message-ID: <CAHEV9L2u7_TfnfwM_dgT-3Fw4ydn9Cs_jrGJuaFnCfOzFwie4Q@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Content-Type: multipart/alternative; boundary=20cf303bf98258ebc804a9731632
X-Mailman-Approved-At: Tue, 02 Aug 2011 05:53:11 -0700
Cc: "sdnp@lucidvision.com" <sdnp@lucidvision.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 15:14:23 -0000

--20cf303bf98258ebc804a9731632
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Aug 1, 2011 at 11:07 AM, Lou Berger <lberger@labn.net> wrote:

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


Lou,

As you can see from the mail, the scope is to cover applications beyond VN.


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


"E" stands for execution. ;-)

Thanks!

Ping

--20cf303bf98258ebc804a9731632
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Mon, Aug 1, 2011 at 11:07 AM, Lou Berger =
<span dir=3D"ltr">&lt;<a href=3D"mailto:lberger@labn.net">lberger@labn.net<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">&gt; The goal is having the applications programming the =
network, without<br>
&gt; breaking it.<br>
<br>
</div>So you&#39;re saying the objective is an API to a VN, right?<br></blo=
ckquote><div><br></div><div><br></div><div>Lou,</div><div><br></div><div>As=
 you can see from the mail, the scope is to cover applications beyond VN.</=
div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
&gt; This is not research, and we have no intention in forcing applications=
<br>
&gt; to adapt network-operation semantics.<br>
<br>
</div>It still seems like the same problem space to me, but the difference<=
br>
is/may be in objectives. =A0You want a concrete solution while that isn&#39=
;t<br>
a specific VNRG objective.<br>
<br>
In other words, you want the work in *E* not *R*, right?<br>
<br>
Lou</blockquote><div><br></div><div>&quot;E&quot; stands for execution. ;-)=
=A0</div><div><br></div><div>Thanks!</div><div><br></div><div>Ping</div><di=
v><br></div></div>

--20cf303bf98258ebc804a9731632--

From lars.eggert@nokia.com  Tue Aug  2 06:47:20 2011
Return-Path: <lars.eggert@nokia.com>
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 543B121F8779 for <vnrg@ietfa.amsl.com>; Tue,  2 Aug 2011 06:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.831
X-Spam-Level: 
X-Spam-Status: No, score=-103.831 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, GB_I_INVITATION=-2, SARE_NETPROD=0.111, 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 yEVvlp90mpUU for <vnrg@ietfa.amsl.com>; Tue,  2 Aug 2011 06:47:19 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB7321F865B for <vnrg@irtf.org>; Tue,  2 Aug 2011 06:47:19 -0700 (PDT)
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p72DlQGJ030894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <vnrg@irtf.org>; Tue, 2 Aug 2011 16:47:28 +0300
From: Lars Eggert <lars.eggert@nokia.com>
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.97.2 at fit.nokia.com
Content-Type: multipart/signed; boundary="Apple-Mail=_DDB08DE9-05F7-4ADC-9F80-E3C139931D6F"; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 2 Aug 2011 16:47:24 +0300
Message-Id: <47C9DA69-D255-431E-A885-877592323E0B@nokia.com>
To: VNRG <vnrg@irtf.org>
Mime-Version: 1.0 (Apple Message framework v1244.3)
X-Mailer: Apple Mail (2.1244.3)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.fit.nokia.com); Tue, 02 Aug 2011 16:47:24 +0300 (EEST)
X-Nokia-AV: Clean
X-Mailman-Approved-At: Wed, 03 Aug 2011 02:17:56 -0700
Subject: [vnrg] Call for Nominations: Applied Networking Research Prize (ANRP) for IETF-82
X-BeenThere: vnrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: anrp@isoc.org
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 13:47:20 -0000

--Apple-Mail=_DDB08DE9-05F7-4ADC-9F80-E3C139931D6F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252



               CALL FOR NOMINATIONS:

      APPLIED NETWORKING RESEARCH PRIZE (ANRP)
     =20
               http://irtf.org/anrp


*** Submit nominations until August 28 for the ANRP for IETF-82,
*** November 13-18, 2011 in Taipei, Taiwan:
*** http://fit.nokia.com/anrp/82/

The Applied Networking Research Prize (ANRP) is awarded for
recent results in applied networking research that are relevant
for transitioning into shipping Internet products and related
standardization efforts. Researchers with relevant, recently
published results are encouraged to apply for this prize, which
will offer them the opportunity to present and discuss their work
with the engineers, network operators, policy makers and
scientists that participate in the Internet Engineering Task
Force (IETF) and its research arm, the Internet Research Task
Force (IRTF). Third-party nominations for this prize are also
encouraged. The goal of the Applied Networking Research Prize
(ANRP) is to recognize the best new ideas in networking, and
bring them to the IETF and IRTF especially in cases where they
would not otherwise see much exposure or discussion.

The Applied Networking Research Prize (ANRP) consists of:

* cash prize of $500 (USD)

* invited talk at the IRTF Open Meeting

* travel grant to attend the week-long IETF meeting
  (airfare, hotel, registration, stipend)

* recognition at the IETF plenary

* invitation to related social activities

* potential for additional travel grants to future IETF
  meetings, based on community feedback


HOW TO APPLY

Only a single person can be nominated based on a peer-reviewed,
recently-published, original journal, conference or workshop paper
they authored. The nominee must be one of the main authors of the
nominated paper. Both self nominations (nominating one=92s own paper)
and third-party nominations (nominating someone else=92s paper) are
encouraged.

The nominated paper should provide a scientific foundation for
possible future IETF engineering work or IRTF experimentation,
analyze the behavior of Internet protocols in operational
deployments or realistic testbeds, make an important contribution
to the understanding of Internet scalability, performance,
reliability, security or capability, or otherwise be of relevance
to ongoing or future IETF or IRTF activities.

Applicants must briefly describe how the nominated paper relates
to these goals, and are encouraged to describe how presentation
of these research results will foster their transition into new
IETF engineering or IRTF experimentation, or otherwise seed new
activities that will have an impact on the real-world Internet.

The goal of the Applied Networking Research Prize (ANRP) is to
foster the transitioning of research results into real-world
benefits for the Internet. Therefore, applicants must indicate
that they (or the nominee, in case of third-party nominations)
are available to attend the respective IETF meeting in person and
in its entirety.

Nominations must include:

* the name and email address of the nominee

* a reference to the published nominated paper

* a PDF copy of the nominated paper

* a statement that describes how the nominated paper
  fulfills the goals of the award

* a statement that the nominee is available to attend the
  respective IETF meeting in person and in its entirety

* a brief biography or CV of the nominee

* optionally, any other supporting information (link to
  nominee's web site, etc.)

*** Nominations are submitted via the submission site:
*** http://fit.nokia.com/anrp/82/


SELECTION PROCESS

A small selection committee comprised of individuals
knowledgeable about the IRTF, IETF and the broader networking
research community will evaluate the submissions against these
selection criteria. The goal is to select 1-2 submissions for the
Applied Networking Research Prize (ANRP) during each nomination
period. All nominees will be notified by email.


IMPORTANT DATES

Applications open:  August 1, 2011
Applications close: August 28, 2011
Notifications:      September 20, 2011
IETF-82 Meeting:    November 13-18, 2011 in Taipei, Taiwan=20


SPONSORS

The Applied Networking Research Prize (ANRP) is supported by the
Internet Society (ISOC), as part of its Internet Research Award
Programme, in coordination with the Internet Research Task Force
(IRTF).=

--Apple-Mail=_DDB08DE9-05F7-4ADC-9F80-E3C139931D6F
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw
ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x
MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r
aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W
wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm
3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4
65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh
ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4
FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js
MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf
kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz
TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g
kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE
0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag
AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp
U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg
SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs
EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO
4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy
riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC
ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w
EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH
AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw
VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov
L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ
cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD
VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT
aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs
YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE
VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM
JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv
YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR
yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy
+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/
wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny
aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgwMjEzNDcyNFowIwYJKoZIhvcNAQkE
MRYEFLG+NfUytUvQjRBiP9XmDWgPc50jMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT
aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+
bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt
cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1
YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB
ALCzcFt4mKtK5A7rEXtOw87WYuwmTpa5RMFHxRGq2/i45Uu/Ze8nbH1IKwtqmjpfigfTKsq2GIIw
yoMG/rKSH5Z3YcvYIjGTjn/qa3o53AxC1nappJDVYYUU2mG/Jk/igu9eX7Ox9ZLdQrV8DgChYMBO
TZn3UksHKUmU2U4Sait8KCs4PwMbvSHY0nDP40ux6JZZR0SoD1kG9IRYBdLCba072eN86CRtXK3L
B+7g/68NBdBD7gjAB0O/pJbMxm1+gFfsOU9jpGJD1jkhAsrJ1bWoY85+Fk5pL61aZ+Vx45fLhYIR
WVjSOtNAbUFBKWUCnY0G4rF+5M0zagcx12Ne9IQAAAAAAAA=

--Apple-Mail=_DDB08DE9-05F7-4ADC-9F80-E3C139931D6F--

From roland.bless@kit.edu  Wed Aug  3 04:54:40 2011
Return-Path: <roland.bless@kit.edu>
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 CB9D121F8B6C for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 04:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.362
X-Spam-Level: 
X-Spam-Status: No, score=-5.362 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x7=0.6, SARE_BAYES_6x7=0.6]
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 mv6wPvDFBMHM for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 04:54:39 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC3F21F8B66 for <vnrg@irtf.org>; Wed,  3 Aug 2011 04:54:39 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1Qoa26-00067y-PU for <vnrg@irtf.org>; Wed, 03 Aug 2011 13:54:49 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id D41D5A80078 for <vnrg@irtf.org>; Wed,  3 Aug 2011 13:54:41 +0200 (CEST)
Message-ID: <4E3936FF.1090006@kit.edu>
Date: Wed, 03 Aug 2011 13:54:39 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: "vnrg@irtf.org" <vnrg@irtf.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1312372489.424280000
Subject: [vnrg] Some definitions and way forward
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: Wed, 03 Aug 2011 11:54:40 -0000

Hi,

as already mentioned in the IETF-81 meeting, I committed to
write up some definitions (mostly results from the 4WARD EU project)
that may be useful for further discussion of terminology and problem
statements. I'll leave recursion aspects aside at first since it usually
complicates the discussion - but it's often rather straight-forward to
apply recursion (i.e., consider virtual resources as (virtual)
substrate) etc.
Some illustrations of roles and interfaces can be found in
http://www.ietf.org/proceedings/77/slides/VNRG-3.pdf

Virtual Resource:
A virtual resource appears to a user of that resource
as if he is the (exclusive) owner of that resource.

Substrate:
This denotes the physical resources that host the virtual
resources, i.e., each virtual resource is instantiated
inside one or more physical resources. Substrate resources can
either be partitioned or aggregated in order to provide a
virtual resource. From the above definition of a virtual
resource follows that virtual resources must be
isolated from each other in the data plane as well as
in the control plane.

Virtual Network:
A virtual network (VNet) is a set of (virtual) nodes directly
connected by (virtual) links and realized on top of a
set of underlying physical resources, the Substrate.
There should be no assumptions about the particular
network protocols or architectures running
inside the VNet, i.e., it is not necessarily IP.
Virtual nodes can be further distinguished into
virtual routers and virtual hosts. Virtual routers
forward packets whereas virtual hosts are sinks
or sources of packets.

Infrastructure Provider:
The Infrastructure Provider (InP) is responsible for maintaining
physical networking resources, such as routers, links, wireless
infrastructure, etc., and enabling the virtualization of these
resources. The InP also offers a resource control interface for the
virtualized resources. Through this interface, InPs can make virtual
resources and partial virtual topologies available to virtual network
provider, which are the customers of the InP. The InP can usually
migrate virtual resource between substrate resources so that the
users of virtual resources are not aware of any change. The actual
mapping from virtual to substrate resources inside the InPs domains
is usually only known by the InP. InPs may have to use a common
interface for setting up virtual links across different InPs.

Virtual Network Provider:
The Virtual Network Provider (VNP) constructs virtual networks using
virtual resources and partial topologies provided by one or more InPs.
The VNP needs a resource control interface to request and configure
these virtual resources offered by the InP who actually owns the
resource. A newly constructed VNet can be made available to a virtual
network operator (or to another VNP, who can recursively use
it to construct an even larger VNet). The VNP performs mainly a broker
role, providing easier access for VNOs to virtual resources spanning
multiple InPs.

Virtual Network Operator:
The Virtual Network Operator (VNO) operates, controls, and manages the
VNet in order to offer services inside the VNet.
Once the VNet has been constructed by a VNP, the VNO is given
"Out-of-VNet access" to control the virtual resources, allowing him
to configure and manage them just like a traditional network operator
manages physical network resources. This Out-of-VNet access control
interface is required in order to install, reboot, start, stop, shutdown
virtual node etc. from outside the VNet (e.g., if your virtual
node crashed, you must have some knob to restart/revive it).
This also requires to get transparent access to the virtual resources
irrespective of where the resources is currently hosted in the
substrate as the InP may not expose the current location and migrate
the virtual resource "freely". The VNO also controls and manages the
virtual resources from inside the VNet (In-VNet Management).

Service Provider:
A service provider may provide services to end-users by using the
protocols running inside the virtual network. Consider an IP-TV
provider who delivers IP-TV inside the VNet to his customers.
In order to accomplish this, the Service Provider may want to employ
IP multicast for efficient distribution of the streams inside the VNet.
So the VNO may run PIM-DM/SM protocols inside the VNet as required by
the service provider.

We note that some of the roles can actually overlap, e.g.,
VNP and VNO, InP/VNP/VNO and service provider etc.

End-users:
End-users attach to the virtual network and use the communication
services provided by/within the virtual network, i.e., they run a
virtual node that implements the suitable protocol stack.
End-users have usually access to some substrate network and need to
get to a virtual access node via a viable substrate path. This process
of transitioning the real world into the virtual world/net is called
"end-user attachment" and the substrate path can be considered as being
a so-called "virtual last mile link". A typical method to accomplish
this is to create a tunnel across the substrate between the end-user's
device and the VNet access node. Problems that need to be solved here
are for example: how can an end-user find the right virtual access node
for a particular VNet across the substrate? How can mobility and
multi-homing in the substrate be considered, e.g., the virtual link stays
connected. How to consider multi-homing and mobility in the VNet, i.e.,
being attached to multiple VNet access nodes simultaneously or moving
between them?

More detailed text on the scenario and control interfaces
can be found here (open access):
http://journal.ub.tu-berlin.de/eceasst/article/download/225/216

I would propose that we try to create an RG draft that defines
some basic terminology, captures the content of some recent
RG discussions on some related aspects as virtual vs. logical,
layering vs. virtualization, important properties, "acid tests",
and so on and then describes some of the
problems that the RG feels need to be solved. In a next step
we may pick some of the problems and work on them (probably in
parallel).

Regards,
 Roland


From vumip1@gmail.com  Wed Aug  3 07:32:25 2011
Return-Path: <vumip1@gmail.com>
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 7FC9F21F86B6 for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 07:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level: 
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_5x7=0.6, SARE_BAYES_6x7=0.6]
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 ReuXiAhlLeD2 for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 07:32:24 -0700 (PDT)
Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8B421F86AC for <vnrg@irtf.org>; Wed,  3 Aug 2011 07:32:24 -0700 (PDT)
Received: by gyf3 with SMTP id 3so611558gyf.13 for <vnrg@irtf.org>; Wed, 03 Aug 2011 07:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=voVKSgsuux3JVAmCq8cQUSLW6N+neMY0b4Q9jTqfFDo=; b=HQ1FBW+t4nW2RGK50M+O8tsfLORteSiB86DraKZCLZeY9+CdwHkEuQeNu+YY4Alcy3 HNwnwudeipcc3z76jJzZ2MCvJ//1R7C5HvpPfawd5lVDZgjsA7rs9gltqPiUzCf/znw6 Ox5jeynyRF7xFfB2ZJ+0JbJrlLkGIaPyo5Cs4=
MIME-Version: 1.0
Received: by 10.236.176.36 with SMTP id a24mr6096759yhm.284.1312381954798; Wed, 03 Aug 2011 07:32:34 -0700 (PDT)
Received: by 10.236.103.164 with HTTP; Wed, 3 Aug 2011 07:32:34 -0700 (PDT)
In-Reply-To: <4E3936FF.1090006@kit.edu>
References: <4E3936FF.1090006@kit.edu>
Date: Wed, 3 Aug 2011 10:32:34 -0400
Message-ID: <CANtnpwiY8qiCFgZowmfRRN9aG_WyATzE0jn12DZiuAYFcbF0FA@mail.gmail.com>
From: Bhumip Khasnabish <vumip1@gmail.com>
To: Roland Bless <roland.bless@kit.edu>
Content-Type: multipart/alternative; boundary=20cf303b3cc139b2dc04a99abc7f
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Wed, 03 Aug 2011 14:32:25 -0000

--20cf303b3cc139b2dc04a99abc7f
Content-Type: text/plain; charset=ISO-8859-1

Hi Roland,

Thanks.

Do we need to define "Virtual Node" and "Virtual Service" as well?

VNode may contain a variety of virtual resources, and we may need to define
them.

Best.

Bhumip


On Wed, Aug 3, 2011 at 7:54 AM, Roland Bless <roland.bless@kit.edu> wrote:

> Hi,
>
> as already mentioned in the IETF-81 meeting, I committed to
> write up some definitions (mostly results from the 4WARD EU project)
> that may be useful for further discussion of terminology and problem
> statements. I'll leave recursion aspects aside at first since it usually
> complicates the discussion - but it's often rather straight-forward to
> apply recursion (i.e., consider virtual resources as (virtual)
> substrate) etc.
> Some illustrations of roles and interfaces can be found in
> http://www.ietf.org/proceedings/77/slides/VNRG-3.pdf
>
> Virtual Resource:
> A virtual resource appears to a user of that resource
> as if he is the (exclusive) owner of that resource.
>
> Substrate:
> This denotes the physical resources that host the virtual
> resources, i.e., each virtual resource is instantiated
> inside one or more physical resources. Substrate resources can
> either be partitioned or aggregated in order to provide a
> virtual resource. From the above definition of a virtual
> resource follows that virtual resources must be
> isolated from each other in the data plane as well as
> in the control plane.
>
> Virtual Network:
> A virtual network (VNet) is a set of (virtual) nodes directly
> connected by (virtual) links and realized on top of a
> set of underlying physical resources, the Substrate.
> There should be no assumptions about the particular
> network protocols or architectures running
> inside the VNet, i.e., it is not necessarily IP.
> Virtual nodes can be further distinguished into
> virtual routers and virtual hosts. Virtual routers
> forward packets whereas virtual hosts are sinks
> or sources of packets.
>
> Infrastructure Provider:
> The Infrastructure Provider (InP) is responsible for maintaining
> physical networking resources, such as routers, links, wireless
> infrastructure, etc., and enabling the virtualization of these
> resources. The InP also offers a resource control interface for the
> virtualized resources. Through this interface, InPs can make virtual
> resources and partial virtual topologies available to virtual network
> provider, which are the customers of the InP. The InP can usually
> migrate virtual resource between substrate resources so that the
> users of virtual resources are not aware of any change. The actual
> mapping from virtual to substrate resources inside the InPs domains
> is usually only known by the InP. InPs may have to use a common
> interface for setting up virtual links across different InPs.
>
> Virtual Network Provider:
> The Virtual Network Provider (VNP) constructs virtual networks using
> virtual resources and partial topologies provided by one or more InPs.
> The VNP needs a resource control interface to request and configure
> these virtual resources offered by the InP who actually owns the
> resource. A newly constructed VNet can be made available to a virtual
> network operator (or to another VNP, who can recursively use
> it to construct an even larger VNet). The VNP performs mainly a broker
> role, providing easier access for VNOs to virtual resources spanning
> multiple InPs.
>
> Virtual Network Operator:
> The Virtual Network Operator (VNO) operates, controls, and manages the
> VNet in order to offer services inside the VNet.
> Once the VNet has been constructed by a VNP, the VNO is given
> "Out-of-VNet access" to control the virtual resources, allowing him
> to configure and manage them just like a traditional network operator
> manages physical network resources. This Out-of-VNet access control
> interface is required in order to install, reboot, start, stop, shutdown
> virtual node etc. from outside the VNet (e.g., if your virtual
> node crashed, you must have some knob to restart/revive it).
> This also requires to get transparent access to the virtual resources
> irrespective of where the resources is currently hosted in the
> substrate as the InP may not expose the current location and migrate
> the virtual resource "freely". The VNO also controls and manages the
> virtual resources from inside the VNet (In-VNet Management).
>
> Service Provider:
> A service provider may provide services to end-users by using the
> protocols running inside the virtual network. Consider an IP-TV
> provider who delivers IP-TV inside the VNet to his customers.
> In order to accomplish this, the Service Provider may want to employ
> IP multicast for efficient distribution of the streams inside the VNet.
> So the VNO may run PIM-DM/SM protocols inside the VNet as required by
> the service provider.
>
> We note that some of the roles can actually overlap, e.g.,
> VNP and VNO, InP/VNP/VNO and service provider etc.
>
> End-users:
> End-users attach to the virtual network and use the communication
> services provided by/within the virtual network, i.e., they run a
> virtual node that implements the suitable protocol stack.
> End-users have usually access to some substrate network and need to
> get to a virtual access node via a viable substrate path. This process
> of transitioning the real world into the virtual world/net is called
> "end-user attachment" and the substrate path can be considered as being
> a so-called "virtual last mile link". A typical method to accomplish
> this is to create a tunnel across the substrate between the end-user's
> device and the VNet access node. Problems that need to be solved here
> are for example: how can an end-user find the right virtual access node
> for a particular VNet across the substrate? How can mobility and
> multi-homing in the substrate be considered, e.g., the virtual link stays
> connected. How to consider multi-homing and mobility in the VNet, i.e.,
> being attached to multiple VNet access nodes simultaneously or moving
> between them?
>
> More detailed text on the scenario and control interfaces
> can be found here (open access):
> http://journal.ub.tu-berlin.de/eceasst/article/download/225/216
>
> I would propose that we try to create an RG draft that defines
> some basic terminology, captures the content of some recent
> RG discussions on some related aspects as virtual vs. logical,
> layering vs. virtualization, important properties, "acid tests",
> and so on and then describes some of the
> problems that the RG feels need to be solved. In a next step
> we may pick some of the problems and work on them (probably in
> parallel).
>
> Regards,
>  Roland
>
> _______________________________________________
> vnrg mailing list
> vnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/vnrg
>

--20cf303b3cc139b2dc04a99abc7f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Hi Roland, </div>
<div>=A0</div>
<div>Thanks.</div>
<div>=A0</div>
<div>Do we need to define &quot;Virtual Node&quot; and &quot;Virtual Servic=
e&quot; as well? </div>
<div>=A0</div>
<div>VNode may contain a variety of virtual resources, and we may need to d=
efine them.</div>
<div>=A0</div>
<div>Best.</div>
<div>=A0</div>
<div>Bhumip</div>
<div>=A0<br><br></div>
<div class=3D"gmail_quote">On Wed, Aug 3, 2011 at 7:54 AM, Roland Bless <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:roland.bless@kit.edu">roland.bless@kit=
.edu</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">Hi,<br><br>as already mentioned =
in the IETF-81 meeting, I committed to<br>write up some definitions (mostly=
 results from the 4WARD EU project)<br>
that may be useful for further discussion of terminology and problem<br>sta=
tements. I&#39;ll leave recursion aspects aside at first since it usually<b=
r>complicates the discussion - but it&#39;s often rather straight-forward t=
o<br>
apply recursion (i.e., consider virtual resources as (virtual)<br>substrate=
) etc.<br>Some illustrations of roles and interfaces can be found in<br><a =
href=3D"http://www.ietf.org/proceedings/77/slides/VNRG-3.pdf" target=3D"_bl=
ank">http://www.ietf.org/proceedings/77/slides/VNRG-3.pdf</a><br>
<br>Virtual Resource:<br>A virtual resource appears to a user of that resou=
rce<br>as if he is the (exclusive) owner of that resource.<br><br>Substrate=
:<br>This denotes the physical resources that host the virtual<br>resources=
, i.e., each virtual resource is instantiated<br>
inside one or more physical resources. Substrate resources can<br>either be=
 partitioned or aggregated in order to provide a<br>virtual resource. From =
the above definition of a virtual<br>resource follows that virtual resource=
s must be<br>
isolated from each other in the data plane as well as<br>in the control pla=
ne.<br><br>Virtual Network:<br>A virtual network (VNet) is a set of (virtua=
l) nodes directly<br>connected by (virtual) links and realized on top of a<=
br>
set of underlying physical resources, the Substrate.<br>There should be no =
assumptions about the particular<br>network protocols or architectures runn=
ing<br>inside the VNet, i.e., it is not necessarily IP.<br>Virtual nodes ca=
n be further distinguished into<br>
virtual routers and virtual hosts. Virtual routers<br>forward packets where=
as virtual hosts are sinks<br>or sources of packets.<br><br>Infrastructure =
Provider:<br>The Infrastructure Provider (InP) is responsible for maintaini=
ng<br>
physical networking resources, such as routers, links, wireless<br>infrastr=
ucture, etc., and enabling the virtualization of these<br>resources. The In=
P also offers a resource control interface for the<br>virtualized resources=
. Through this interface, InPs can make virtual<br>
resources and partial virtual topologies available to virtual network<br>pr=
ovider, which are the customers of the InP. The InP can usually<br>migrate =
virtual resource between substrate resources so that the<br>users of virtua=
l resources are not aware of any change. The actual<br>
mapping from virtual to substrate resources inside the InPs domains<br>is u=
sually only known by the InP. InPs may have to use a common<br>interface fo=
r setting up virtual links across different InPs.<br><br>Virtual Network Pr=
ovider:<br>
The Virtual Network Provider (VNP) constructs virtual networks using<br>vir=
tual resources and partial topologies provided by one or more InPs.<br>The =
VNP needs a resource control interface to request and configure<br>these vi=
rtual resources offered by the InP who actually owns the<br>
resource. A newly constructed VNet can be made available to a virtual<br>ne=
twork operator (or to another VNP, who can recursively use<br>it to constru=
ct an even larger VNet). The VNP performs mainly a broker<br>role, providin=
g easier access for VNOs to virtual resources spanning<br>
multiple InPs.<br><br>Virtual Network Operator:<br>The Virtual Network Oper=
ator (VNO) operates, controls, and manages the<br>VNet in order to offer se=
rvices inside the VNet.<br>Once the VNet has been constructed by a VNP, the=
 VNO is given<br>
&quot;Out-of-VNet access&quot; to control the virtual resources, allowing h=
im<br>to configure and manage them just like a traditional network operator=
<br>manages physical network resources. This Out-of-VNet access control<br>
interface is required in order to install, reboot, start, stop, shutdown<br=
>virtual node etc. from outside the VNet (e.g., if your virtual<br>node cra=
shed, you must have some knob to restart/revive it).<br>This also requires =
to get transparent access to the virtual resources<br>
irrespective of where the resources is currently hosted in the<br>substrate=
 as the InP may not expose the current location and migrate<br>the virtual =
resource &quot;freely&quot;. The VNO also controls and manages the<br>virtu=
al resources from inside the VNet (In-VNet Management).<br>
<br>Service Provider:<br>A service provider may provide services to end-use=
rs by using the<br>protocols running inside the virtual network. Consider a=
n IP-TV<br>provider who delivers IP-TV inside the VNet to his customers.<br=
>
In order to accomplish this, the Service Provider may want to employ<br>IP =
multicast for efficient distribution of the streams inside the VNet.<br>So =
the VNO may run PIM-DM/SM protocols inside the VNet as required by<br>the s=
ervice provider.<br>
<br>We note that some of the roles can actually overlap, e.g.,<br>VNP and V=
NO, InP/VNP/VNO and service provider etc.<br><br>End-users:<br>End-users at=
tach to the virtual network and use the communication<br>services provided =
by/within the virtual network, i.e., they run a<br>
virtual node that implements the suitable protocol stack.<br>End-users have=
 usually access to some substrate network and need to<br>get to a virtual a=
ccess node via a viable substrate path. This process<br>of transitioning th=
e real world into the virtual world/net is called<br>
&quot;end-user attachment&quot; and the substrate path can be considered as=
 being<br>a so-called &quot;virtual last mile link&quot;. A typical method =
to accomplish<br>this is to create a tunnel across the substrate between th=
e end-user&#39;s<br>
device and the VNet access node. Problems that need to be solved here<br>ar=
e for example: how can an end-user find the right virtual access node<br>fo=
r a particular VNet across the substrate? How can mobility and<br>multi-hom=
ing in the substrate be considered, e.g., the virtual link stays<br>
connected. How to consider multi-homing and mobility in the VNet, i.e.,<br>=
being attached to multiple VNet access nodes simultaneously or moving<br>be=
tween them?<br><br>More detailed text on the scenario and control interface=
s<br>
can be found here (open access):<br><a href=3D"http://journal.ub.tu-berlin.=
de/eceasst/article/download/225/216" target=3D"_blank">http://journal.ub.tu=
-berlin.de/eceasst/article/download/225/216</a><br><br>I would propose that=
 we try to create an RG draft that defines<br>
some basic terminology, captures the content of some recent<br>RG discussio=
ns on some related aspects as virtual vs. logical,<br>layering vs. virtuali=
zation, important properties, &quot;acid tests&quot;,<br>and so on and then=
 describes some of the<br>
problems that the RG feels need to be solved. In a next step<br>we may pick=
 some of the problems and work on them (probably in<br>parallel).<br><br>Re=
gards,<br>=A0Roland<br><br>_______________________________________________<=
br>
vnrg mailing list<br><a href=3D"mailto:vnrg@irtf.org">vnrg@irtf.org</a><br>=
<a href=3D"https://www.irtf.org/mailman/listinfo/vnrg" target=3D"_blank">ht=
tps://www.irtf.org/mailman/listinfo/vnrg</a><br></blockquote></div><br>=A0

--20cf303b3cc139b2dc04a99abc7f--

From vumip1@gmail.com  Wed Aug  3 09:11:00 2011
Return-Path: <vumip1@gmail.com>
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 62CF421F8B0E for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 09:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 oPbCm-M5fU54 for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 09:10:59 -0700 (PDT)
Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6117A21F8B6F for <vnrg@irtf.org>; Wed,  3 Aug 2011 09:10:59 -0700 (PDT)
Received: by gwb15 with SMTP id 15so422707gwb.13 for <vnrg@irtf.org>; Wed, 03 Aug 2011 09:11:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U6o8SsjbMM5+nkOSSXhAENuI25UeyvsckX6qEiW1Eo8=; b=RtcDAkYgVWzefWsJbfzYKCirhnPdJqmKah1N/7QmUdGyISlKRg4Kcpu0nIoSGwgQvQ V6z5QOG6eyurZ36Pko650YogEOweo5aVyrfOkjG9GXBM2UnEzqrxRhUDRdV7/Ii5Rx/y 1yWNnWszOFM0IYFMyyixqnvSDh3CLJPXBjgho=
MIME-Version: 1.0
Received: by 10.236.175.163 with SMTP id z23mr2402067yhl.83.1312387869851; Wed, 03 Aug 2011 09:11:09 -0700 (PDT)
Received: by 10.236.103.164 with HTTP; Wed, 3 Aug 2011 09:11:03 -0700 (PDT)
In-Reply-To: <BLU135-W17443EE3A86BCE732EBD62C8380@phx.gbl>
References: <CANtnpwhQf7e2i=wEQr-jEsGFqkgfz+mTqRAiiZtibkmc+jzgTg@mail.gmail.com> <BLU135-W17443EE3A86BCE732EBD62C8380@phx.gbl>
Date: Wed, 3 Aug 2011 12:11:03 -0400
Message-ID: <CANtnpwhdTCBqVDxneomsjsfqG6J-74wuLoFb4XfQjsZ45Fu+tA@mail.gmail.com>
From: Bhumip Khasnabish <vumip1@gmail.com>
To: Guillaume FORTAINE <gfortaine@live.com>
Content-Type: multipart/alternative; boundary=20cf303f68c2ca3f8e04a99c1c71
Cc: vnrg@irtf.org
Subject: Re: [vnrg] inviting discussion on NaaS
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: Wed, 03 Aug 2011 16:11:00 -0000

--20cf303f68c2ca3f8e04a99c1c71
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello Guillaume,

Thanks a lot.

Some of us have been coached by IETF and IRTF veterans to use info from
other sources very cautiously.
 They encouraged us to have a discussion in the list or in face-to-face
meetings to develop agreed-upon terms and definitions.

We'll certainly review these and see which ones we can use in the draft tha=
t
we plan to develop.

Thanks again.

Best.

Bhumip



On Mon, Aug 1, 2011 at 1:44 PM, Guillaume FORTAINE <gfortaine@live.com>wrot=
e:

>
> Hello,
>
> For your information :
>
> http://wiki.openstack.org/NetworkService
>
> Best Regards,
>
> Guillaume FORTAINE
> +33(0)6.319.092.519
> gfortaine@gfortaine.biz
>
> ________________________________
> > Date: Mon, 1 Aug 2011 10:13:53 -0400
> > From: vumip1@gmail.com
> > To: vnrg@irtf.org
> > Subject: [vnrg] inviting discussion on NaaS
> >
> >
> > Dear All,
> >
> > We would like to initiate a discussion on
> >
> > (A) Definition of, and
> >
> > (B) Expectations from NaaS
> >
> > based on our preso on NaaS during VNRG mtg. in IETE-81 (Quebec,
> 29July2011).
> >
> >
> > Thanks a lot.
> >
> > Best.
> >
> > Bhumip Khasnabish
> > vumip1@gmail.com<mailto:vumip1@gmail.com>
> > bhumip.khasnabish@zteusa.com<mailto:bhumip.khasnabish@zteusa.com>
> > +1-781-752-8003 (mobile)
> > http://www.linkedin.com/in/bhumipkhasnabish
> >
> >                     __o
> >               _ `\ <, _
> > .......... ( =95 ) / ( =95 ) ......................
> > --
> >
> >
> >
> > _______________________________________________ vnrg mailing list
> > vnrg@irtf.org https://www.irtf.org/mailman/listinfo/vnrg
>
> _______________________________________________
> vnrg mailing list
> vnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/vnrg
>

--20cf303f68c2ca3f8e04a99c1c71
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>Hello Guillaume,</div>
<div>=A0</div>
<div>Thanks a lot. </div>
<div>=A0</div>
<div>Some of us have been coached by IETF and IRTF veterans to use info fro=
m other sources very cautiously. </div>
<div>=A0They encouraged us to have a discussion in the list or in face-to-f=
ace meetings to develop agreed-upon terms and definitions.</div>
<div>=A0</div>
<div>We&#39;ll certainly review these and see which ones we can use in the =
draft that we plan to develop.</div>
<div>=A0</div>
<div>Thanks again.</div>
<div>=A0</div>
<div>Best.</div>
<div>=A0</div>
<div>Bhumip</div>
<div><br><br>=A0</div>
<div class=3D"gmail_quote">On Mon, Aug 1, 2011 at 1:44 PM, Guillaume FORTAI=
NE <span dir=3D"ltr">&lt;<a href=3D"mailto:gfortaine@live.com" target=3D"_b=
lank">gfortaine@live.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote"><br>Hello,<br><br>For your infor=
mation :<br><br><a href=3D"http://wiki.openstack.org/NetworkService" target=
=3D"_blank">http://wiki.openstack.org/NetworkService</a><br>
<br>Best Regards,<br><br>Guillaume FORTAINE<br>+33(0)6.319.092.519<br><a hr=
ef=3D"mailto:gfortaine@gfortaine.biz" target=3D"_blank">gfortaine@gfortaine=
.biz</a><br><br>________________________________<br>&gt; Date: Mon, 1 Aug 2=
011 10:13:53 -0400<br>
&gt; From: <a href=3D"mailto:vumip1@gmail.com" target=3D"_blank">vumip1@gma=
il.com</a><br>&gt; To: <a href=3D"mailto:vnrg@irtf.org" target=3D"_blank">v=
nrg@irtf.org</a><br>&gt; Subject: [vnrg] inviting discussion on NaaS<br>
<div>&gt;<br>&gt;<br>&gt; Dear All,<br>&gt;<br>&gt; We would like to initia=
te a discussion on<br>&gt;<br>&gt; (A) Definition of, and<br>&gt;<br>&gt; (=
B) Expectations from NaaS<br>&gt;<br>&gt; based on our preso on NaaS during=
 VNRG mtg. in IETE-81 (Quebec, 29July2011).<br>
&gt;<br>&gt;<br>&gt; Thanks a lot.<br>&gt;<br>&gt; Best.<br>&gt;<br>&gt; Bh=
umip Khasnabish<br></div>&gt; <a href=3D"mailto:vumip1@gmail.com" target=3D=
"_blank">vumip1@gmail.com</a>&lt;mailto:<a href=3D"mailto:vumip1@gmail.com"=
 target=3D"_blank">vumip1@gmail.com</a>&gt;<br>
&gt; <a href=3D"mailto:bhumip.khasnabish@zteusa.com" target=3D"_blank">bhum=
ip.khasnabish@zteusa.com</a>&lt;mailto:<a href=3D"mailto:bhumip.khasnabish@=
zteusa.com" target=3D"_blank">bhumip.khasnabish@zteusa.com</a>&gt;<br>
<div>&gt; <a href=3D"tel:%2B1-781-752-8003" target=3D"_blank" value=3D"+178=
17528003">+1-781-752-8003</a> (mobile)<br>&gt; <a href=3D"http://www.linked=
in.com/in/bhumipkhasnabish" target=3D"_blank">http://www.linkedin.com/in/bh=
umipkhasnabish</a><br>
&gt;<br>&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __o<br>&gt; =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 _ `\ &lt;, _<br>&gt; .......... ( =95 ) / ( =95 ) .....=
.................<br>&gt; --<br>&gt;<br>&gt;<br>&gt;<br></div>&gt; ________=
_______________________________________ vnrg mailing list<br>
&gt; <a href=3D"mailto:vnrg@irtf.org" target=3D"_blank">vnrg@irtf.org</a> <=
a href=3D"https://www.irtf.org/mailman/listinfo/vnrg" target=3D"_blank">htt=
ps://www.irtf.org/mailman/listinfo/vnrg</a><br><br>________________________=
_______________________<br>
vnrg mailing list<br><a href=3D"mailto:vnrg@irtf.org" target=3D"_blank">vnr=
g@irtf.org</a><br><a href=3D"https://www.irtf.org/mailman/listinfo/vnrg" ta=
rget=3D"_blank">https://www.irtf.org/mailman/listinfo/vnrg</a><br></blockqu=
ote>
</div><br><br clear=3D"all">=A0=20

--20cf303f68c2ca3f8e04a99c1c71--

From dimitri.papadimitriou@alcatel-lucent.com  Wed Aug  3 09:13:13 2011
Return-Path: <dimitri.papadimitriou@alcatel-lucent.com>
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 A760821F8BA4 for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 09:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.916
X-Spam-Level: 
X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=1.333,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 EiyXpkFvXdZw for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 09:13:13 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 51A1B21F8B71 for <vnrg@irtf.org>; Wed,  3 Aug 2011 09:13:10 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p73GDKLO001074 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Aug 2011 18:13:20 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 3 Aug 2011 18:13:20 +0200
From: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
To: Roland Bless <roland.bless@kit.edu>, "vnrg@irtf.org" <vnrg@irtf.org>
Date: Wed, 3 Aug 2011 18:13:19 +0200
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxR1DQdXQF84+vwTgmzaENg61zEdQAAVt+g
Message-ID: <EFDB2B5417263843B5077E12666D8C10187C646D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu>
In-Reply-To: <4E3936FF.1090006@kit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Subject: Re: [vnrg] Some definitions and way forward
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: Wed, 03 Aug 2011 16:13:13 -0000

Hi,

These definitions stems from the view that physical resource owner provides=
 virtual resources of the same kind (delimits the type of virtual resources=
 it can deliver). My understanding from the scope given in the Maastricht m=
eeting was:

- virtual resources can be hosted on physical resources of different type i=
.e. virtual nodes/links don't have to be instantiated from physical nodes/l=
inks; for instance, a virtual network can comprise virtual nodes that are b=
ringing together/aggregating resources from multiple physical nodes AND a s=
et of virtual nodes that are emulated on a single physical machine. =20

- virtual resources composing a virtual network can be of different type an=
d thus virtually operate at different layers (thus beyond nodes and links o=
perating at a given layer) including wireless/wireline virtual links with d=
ifferent properties (with or without emulated delay), hosts and intermediat=
e nodes of different kind, e.g., switches, routers, base stations, etc.). T=
his is basically what makes the difference between an "overlay network" and=
 "virtual network". =20

The role definitions here below tend to reproduce (and thus somehow limit) =
the roles we actually know from "physical networks". Taking the above defin=
itions, if the virtual network would be running on physical hosts, "provide=
rs" would not maintain any physical resource of the type indicated here bel=
ow (routers, links, wireless infrastructure, etc.) but only computing resou=
rces on terminals/servers.=20

The role definitions provided here below tend to enforce too a client-serve=
r strict demarcation between resource owner and non-owner merging thus a fu=
nctional and operational role whereas demarcation would be needed between a=
n external entity to the VN (as delimited by the functionality that the VN =
delivers) and a Virtual NAP (whether one owns the underlying resources or n=
ot).

Thanks,
-dimitri.

> -----Original Message-----
> From: vnrg-bounces@irtf.org [mailto:vnrg-bounces@irtf.org] On=20
> Behalf Of Roland Bless
> Sent: Wednesday, August 03, 2011 1:55 PM
> To: vnrg@irtf.org
> Subject: [vnrg] Some definitions and way forward
>=20
> Hi,
>=20
> as already mentioned in the IETF-81 meeting, I committed to
> write up some definitions (mostly results from the 4WARD EU project)
> that may be useful for further discussion of terminology and problem
> statements. I'll leave recursion aspects aside at first since=20
> it usually
> complicates the discussion - but it's often rather straight-forward to
> apply recursion (i.e., consider virtual resources as (virtual)
> substrate) etc.
> Some illustrations of roles and interfaces can be found in
> http://www.ietf.org/proceedings/77/slides/VNRG-3.pdf
>=20
> Virtual Resource:
> A virtual resource appears to a user of that resource
> as if he is the (exclusive) owner of that resource.
>=20
> Substrate:
> This denotes the physical resources that host the virtual
> resources, i.e., each virtual resource is instantiated
> inside one or more physical resources. Substrate resources can
> either be partitioned or aggregated in order to provide a
> virtual resource. From the above definition of a virtual
> resource follows that virtual resources must be
> isolated from each other in the data plane as well as
> in the control plane.
>=20
> Virtual Network:
> A virtual network (VNet) is a set of (virtual) nodes directly
> connected by (virtual) links and realized on top of a
> set of underlying physical resources, the Substrate.
> There should be no assumptions about the particular
> network protocols or architectures running
> inside the VNet, i.e., it is not necessarily IP.
> Virtual nodes can be further distinguished into
> virtual routers and virtual hosts. Virtual routers
> forward packets whereas virtual hosts are sinks
> or sources of packets.
>=20
> Infrastructure Provider:
> The Infrastructure Provider (InP) is responsible for maintaining
> physical networking resources, such as routers, links, wireless
> infrastructure, etc., and enabling the virtualization of these
> resources. The InP also offers a resource control interface for the
> virtualized resources. Through this interface, InPs can make virtual
> resources and partial virtual topologies available to virtual network
> provider, which are the customers of the InP. The InP can usually
> migrate virtual resource between substrate resources so that the
> users of virtual resources are not aware of any change. The actual
> mapping from virtual to substrate resources inside the InPs domains
> is usually only known by the InP. InPs may have to use a common
> interface for setting up virtual links across different InPs.
>=20
> Virtual Network Provider:
> The Virtual Network Provider (VNP) constructs virtual networks using
> virtual resources and partial topologies provided by one or more InPs.
> The VNP needs a resource control interface to request and configure
> these virtual resources offered by the InP who actually owns the
> resource. A newly constructed VNet can be made available to a virtual
> network operator (or to another VNP, who can recursively use
> it to construct an even larger VNet). The VNP performs mainly a broker
> role, providing easier access for VNOs to virtual resources spanning
> multiple InPs.
>=20
> Virtual Network Operator:
> The Virtual Network Operator (VNO) operates, controls, and manages the
> VNet in order to offer services inside the VNet.
> Once the VNet has been constructed by a VNP, the VNO is given
> "Out-of-VNet access" to control the virtual resources, allowing him
> to configure and manage them just like a traditional network operator
> manages physical network resources. This Out-of-VNet access control
> interface is required in order to install, reboot, start,=20
> stop, shutdown
> virtual node etc. from outside the VNet (e.g., if your virtual
> node crashed, you must have some knob to restart/revive it).
> This also requires to get transparent access to the virtual resources
> irrespective of where the resources is currently hosted in the
> substrate as the InP may not expose the current location and migrate
> the virtual resource "freely". The VNO also controls and manages the
> virtual resources from inside the VNet (In-VNet Management).
>=20
> Service Provider:
> A service provider may provide services to end-users by using the
> protocols running inside the virtual network. Consider an IP-TV
> provider who delivers IP-TV inside the VNet to his customers.
> In order to accomplish this, the Service Provider may want to employ
> IP multicast for efficient distribution of the streams inside=20
> the VNet.
> So the VNO may run PIM-DM/SM protocols inside the VNet as required by
> the service provider.
>=20
> We note that some of the roles can actually overlap, e.g.,
> VNP and VNO, InP/VNP/VNO and service provider etc.
>=20
> End-users:
> End-users attach to the virtual network and use the communication
> services provided by/within the virtual network, i.e., they run a
> virtual node that implements the suitable protocol stack.
> End-users have usually access to some substrate network and need to
> get to a virtual access node via a viable substrate path. This process
> of transitioning the real world into the virtual world/net is called
> "end-user attachment" and the substrate path can be=20
> considered as being
> a so-called "virtual last mile link". A typical method to accomplish
> this is to create a tunnel across the substrate between the end-user's
> device and the VNet access node. Problems that need to be solved here
> are for example: how can an end-user find the right virtual=20
> access node
> for a particular VNet across the substrate? How can mobility and
> multi-homing in the substrate be considered, e.g., the=20
> virtual link stays
> connected. How to consider multi-homing and mobility in the=20
> VNet, i.e.,
> being attached to multiple VNet access nodes simultaneously or moving
> between them?
>=20
> More detailed text on the scenario and control interfaces
> can be found here (open access):
> http://journal.ub.tu-berlin.de/eceasst/article/download/225/216
>=20
> I would propose that we try to create an RG draft that defines
> some basic terminology, captures the content of some recent
> RG discussions on some related aspects as virtual vs. logical,
> layering vs. virtualization, important properties, "acid tests",
> and so on and then describes some of the
> problems that the RG feels need to be solved. In a next step
> we may pick some of the problems and work on them (probably in
> parallel).
>=20
> Regards,
>  Roland
>=20
> _______________________________________________
> vnrg mailing list
> vnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/vnrg
> =

From touch@isi.edu  Wed Aug  3 09:20:12 2011
Return-Path: <touch@isi.edu>
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 1866121F875C for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 09:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.243
X-Spam-Level: 
X-Spam-Status: No, score=-103.243 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, 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 A-6OgnA8Msyp for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 09:20:11 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7CB21F873D for <vnrg@irtf.org>; Wed,  3 Aug 2011 09:20:11 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p73GJLeu001476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Aug 2011 09:19:22 -0700 (PDT)
Message-ID: <4E39750A.2080302@isi.edu>
Date: Wed, 03 Aug 2011 09:19:22 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Roland Bless <roland.bless@kit.edu>
References: <4E3936FF.1090006@kit.edu>
In-Reply-To: <4E3936FF.1090006@kit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Wed, 03 Aug 2011 16:20:12 -0000

Hi, Roland,

Some of the issues below go well beyond architecture - e.g., operators, 
ISPs, etc.

It might be useful to focus on the arch aspects first.

Also, it'd be useful to understand your view of the relationship of 
these definitions to PPVPNs, VPNs, etc.

Joe (as an individual contributor)

On 8/3/2011 4:54 AM, Roland Bless wrote:
> Hi,
>
> as already mentioned in the IETF-81 meeting, I committed to
> write up some definitions (mostly results from the 4WARD EU project)
> that may be useful for further discussion of terminology and problem
> statements. I'll leave recursion aspects aside at first since it usually
> complicates the discussion - but it's often rather straight-forward to
> apply recursion (i.e., consider virtual resources as (virtual)
> substrate) etc.
> Some illustrations of roles and interfaces can be found in
> http://www.ietf.org/proceedings/77/slides/VNRG-3.pdf
>
> Virtual Resource:
> A virtual resource appears to a user of that resource
> as if he is the (exclusive) owner of that resource.
>
> Substrate:
> This denotes the physical resources that host the virtual
> resources, i.e., each virtual resource is instantiated
> inside one or more physical resources. Substrate resources can
> either be partitioned or aggregated in order to provide a
> virtual resource. From the above definition of a virtual
> resource follows that virtual resources must be
> isolated from each other in the data plane as well as
> in the control plane.
>
> Virtual Network:
> A virtual network (VNet) is a set of (virtual) nodes directly
> connected by (virtual) links and realized on top of a
> set of underlying physical resources, the Substrate.
> There should be no assumptions about the particular
> network protocols or architectures running
> inside the VNet, i.e., it is not necessarily IP.
> Virtual nodes can be further distinguished into
> virtual routers and virtual hosts. Virtual routers
> forward packets whereas virtual hosts are sinks
> or sources of packets.
>
> Infrastructure Provider:
> The Infrastructure Provider (InP) is responsible for maintaining
> physical networking resources, such as routers, links, wireless
> infrastructure, etc., and enabling the virtualization of these
> resources. The InP also offers a resource control interface for the
> virtualized resources. Through this interface, InPs can make virtual
> resources and partial virtual topologies available to virtual network
> provider, which are the customers of the InP. The InP can usually
> migrate virtual resource between substrate resources so that the
> users of virtual resources are not aware of any change. The actual
> mapping from virtual to substrate resources inside the InPs domains
> is usually only known by the InP. InPs may have to use a common
> interface for setting up virtual links across different InPs.
>
> Virtual Network Provider:
> The Virtual Network Provider (VNP) constructs virtual networks using
> virtual resources and partial topologies provided by one or more InPs.
> The VNP needs a resource control interface to request and configure
> these virtual resources offered by the InP who actually owns the
> resource. A newly constructed VNet can be made available to a virtual
> network operator (or to another VNP, who can recursively use
> it to construct an even larger VNet). The VNP performs mainly a broker
> role, providing easier access for VNOs to virtual resources spanning
> multiple InPs.
>
> Virtual Network Operator:
> The Virtual Network Operator (VNO) operates, controls, and manages the
> VNet in order to offer services inside the VNet.
> Once the VNet has been constructed by a VNP, the VNO is given
> "Out-of-VNet access" to control the virtual resources, allowing him
> to configure and manage them just like a traditional network operator
> manages physical network resources. This Out-of-VNet access control
> interface is required in order to install, reboot, start, stop, shutdown
> virtual node etc. from outside the VNet (e.g., if your virtual
> node crashed, you must have some knob to restart/revive it).
> This also requires to get transparent access to the virtual resources
> irrespective of where the resources is currently hosted in the
> substrate as the InP may not expose the current location and migrate
> the virtual resource "freely". The VNO also controls and manages the
> virtual resources from inside the VNet (In-VNet Management).
>
> Service Provider:
> A service provider may provide services to end-users by using the
> protocols running inside the virtual network. Consider an IP-TV
> provider who delivers IP-TV inside the VNet to his customers.
> In order to accomplish this, the Service Provider may want to employ
> IP multicast for efficient distribution of the streams inside the VNet.
> So the VNO may run PIM-DM/SM protocols inside the VNet as required by
> the service provider.
>
> We note that some of the roles can actually overlap, e.g.,
> VNP and VNO, InP/VNP/VNO and service provider etc.
>
> End-users:
> End-users attach to the virtual network and use the communication
> services provided by/within the virtual network, i.e., they run a
> virtual node that implements the suitable protocol stack.
> End-users have usually access to some substrate network and need to
> get to a virtual access node via a viable substrate path. This process
> of transitioning the real world into the virtual world/net is called
> "end-user attachment" and the substrate path can be considered as being
> a so-called "virtual last mile link". A typical method to accomplish
> this is to create a tunnel across the substrate between the end-user's
> device and the VNet access node. Problems that need to be solved here
> are for example: how can an end-user find the right virtual access node
> for a particular VNet across the substrate? How can mobility and
> multi-homing in the substrate be considered, e.g., the virtual link stays
> connected. How to consider multi-homing and mobility in the VNet, i.e.,
> being attached to multiple VNet access nodes simultaneously or moving
> between them?
>
> More detailed text on the scenario and control interfaces
> can be found here (open access):
> http://journal.ub.tu-berlin.de/eceasst/article/download/225/216
>
> I would propose that we try to create an RG draft that defines
> some basic terminology, captures the content of some recent
> RG discussions on some related aspects as virtual vs. logical,
> layering vs. virtualization, important properties, "acid tests",
> and so on and then describes some of the
> problems that the RG feels need to be solved. In a next step
> we may pick some of the problems and work on them (probably in
> parallel).
>
> Regards,
>   Roland
>
> _______________________________________________
> vnrg mailing list
> vnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/vnrg

From roland.bless@kit.edu  Wed Aug  3 12:53:39 2011
Return-Path: <roland.bless@kit.edu>
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 623C611E8092 for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 12:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.941
X-Spam-Level: 
X-Spam-Status: No, score=-5.941 tagged_above=-999 required=5 tests=[AWL=0.308,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 lVbiLph695yw for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 12:53:38 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 509B811E8091 for <vnrg@irtf.org>; Wed,  3 Aug 2011 12:53:37 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1QohVe-0004Ou-Rj; Wed, 03 Aug 2011 21:53:49 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 0A0A1A806B5; Wed,  3 Aug 2011 21:53:41 +0200 (CEST)
Message-ID: <4E39A744.8010508@kit.edu>
Date: Wed, 03 Aug 2011 21:53:40 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu> <EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
In-Reply-To: <EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1312401229.195784000
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Wed, 03 Aug 2011 19:53:39 -0000

Hi Dimitri,

On 03.08.2011 18:07, Papadimitriou, Dimitri (Dimitri) wrote:

> These definitions stems from the view that physical resource owner
> provides virtual resources of the same kind (delimits the type of
> virtual resources it can deliver). My understanding from the scope
> given in the Maastricht meeting was:

Not clear how you infer this view, since I don't see this kind of
restriction in my text.

> - virtual resources can be hosted on physical resources of different
> type i.e. virtual nodes/links don't have to be instantiated from
> physical nodes/links; for instance, a virtual network can comprise
> virtual nodes that are bringing together/aggregating resources from
> multiple physical nodes AND a set of virtual nodes that are emulated
> on a single physical machine.

Thanks for pointing this out, but the given definitions
don't exclude that. How you map virtual nodes and virtual
links onto the substrate resources may vary a lot. We also
consider mapping a virtual link onto a substrate node since
both virtual nodes that are connected by the link are hosted
on the same substrate node. I think it would be good to provide
some examples of mappings to make this clear, maybe when discussing
the terms virtual links and virtual nodes in more detail.

> - virtual resources composing a virtual network can be of different
> type and thus virtually operate at different layers (thus beyond
> nodes and links operating at a given layer) including
> wireless/wireline virtual links with different properties (with or
> without emulated delay), hosts and intermediate nodes of different
> kind, e.g., switches, routers, base stations, etc.). This is
> basically what makes the difference between an "overlay network" and
> "virtual network".

This is important, but probably not easy to grasp. I don't want to
exclude having virtual switches or virtual wireless links and so on,
but it's probably complicated to discuss them all together across
different layers. If you consider virtual routers, then virtual switches
are probably "transparent" connectors just as they are for IP
routers in physical networks. I think we need to work on that.
The difference to overlay networks is IMHO (as also discussed in
earlier mail
http://www.ietf.org/mail-archive/web/vnrg/current/msg00224.html) that
overlay nodes are always sitting at the "ends"
of its underlying layer (the underlay).

> The role definitions here below tend to reproduce (and thus somehow
> limit) the roles we actually know from "physical networks". Taking
> the above definitions, if the virtual network would be running on
> physical hosts, "providers" would not maintain any physical resource
> of the type indicated here below (routers, links, wireless
> infrastructure, etc.) but only computing resources on
> terminals/servers.

As already said above, I can't infer restrictions directly from my text,
but I'd suggest that we provide examples that make these aspects very
clear. The provided definitions perfectly allow that a whole virtual
network is embedded into a single physical substrate host.

On the other hand one can expect that also virtual networks are used
to transport data over some physical distance in many cases. If this
isn't the case one may probably come up with simpler structures that
provide the same level of isolation, e.g., no need to provide a large
virtual infrastructure using several virtual routers if you merely need
to connect virtual nodes that are *always* residing inside the same
physical host - a single virtual switch or router may provide sufficient
connectivity or isolation between them (depending on the addressing
scheme); this may change as soon as the virtual nodes
may actually move to different substrate nodes...

> The role definitions provided here below tend to enforce too a
> client-server strict demarcation between resource owner and non-owner

Which resource do you mean here the virtual or the substrate resource?

> merging thus a functional and operational role whereas demarcation
> would be needed between an external entity to the VN (as delimited by
> the functionality that the VN delivers) and a Virtual NAP (whether
> one owns the underlying resources or not).

Sorry, now I'm lost, I don't get your point here - can you provide
an example? I don't think that any client-server based demarcation
is implied by the proposed architecture, actually we also considered
P2P-based
self-organized access structures for controlling the virtual resources...

> Thanks, -dimitri.

Thanks for your input, that was exactly what I was looking for,
i.e., collecting different viewpoints in order to complete the
big picture.

Regards,
 Roland


From roland.bless@kit.edu  Wed Aug  3 12:55:13 2011
Return-Path: <roland.bless@kit.edu>
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 C497921F8666 for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 12:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.96
X-Spam-Level: 
X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.289,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 vGavMnXGLKIK for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 12:55:13 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD1211E807E for <vnrg@irtf.org>; Wed,  3 Aug 2011 12:55:13 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1QohXE-0004fj-2Y; Wed, 03 Aug 2011 21:55:25 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 76759A806B5; Wed,  3 Aug 2011 21:55:18 +0200 (CEST)
Message-ID: <4E39A7A5.3030702@kit.edu>
Date: Wed, 03 Aug 2011 21:55:17 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Bhumip Khasnabish <vumip1@gmail.com>
References: <4E3936FF.1090006@kit.edu> <CANtnpwiY8qiCFgZowmfRRN9aG_WyATzE0jn12DZiuAYFcbF0FA@mail.gmail.com>
In-Reply-To: <CANtnpwiY8qiCFgZowmfRRN9aG_WyATzE0jn12DZiuAYFcbF0FA@mail.gmail.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1312401325.353458000
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Wed, 03 Aug 2011 19:55:13 -0000

Hi Bhumip,

On 03.08.2011 16:32, Bhumip Khasnabish wrote:

> Do we need to define "Virtual Node" and "Virtual Service" as well?
>  
> VNode may contain a variety of virtual resources, and we may need to
> define them.

Yes, as Dimitri also pointed out, we may need to provide
different examples to make the scope of the terms clearer.

Regards,
 Roland


From roland.bless@kit.edu  Wed Aug  3 13:04:53 2011
Return-Path: <roland.bless@kit.edu>
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 0150321F8429 for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 13:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.272,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 qJMDpJ9NLJro for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 13:04:52 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6082F21F83E2 for <vnrg@irtf.org>; Wed,  3 Aug 2011 13:04:52 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1QohgY-0005cw-Nl; Wed, 03 Aug 2011 22:05:04 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id E50EDA806B5; Wed,  3 Aug 2011 22:04:57 +0200 (CEST)
Message-ID: <4E39A9E8.5070307@kit.edu>
Date: Wed, 03 Aug 2011 22:04:56 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <4E3936FF.1090006@kit.edu> <4E39750A.2080302@isi.edu>
In-Reply-To: <4E39750A.2080302@isi.edu>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1312401904.168867000
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Wed, 03 Aug 2011 20:04:53 -0000

Hi Joe,

On 03.08.2011 18:19, Joe Touch wrote:
> Some of the issues below go well beyond architecture - e.g., operators,
> ISPs, etc.

I don't know what you consider as architecture, but we came up with
the roles in order to define an architecture. Some of the roles
definitely imply control interfaces for access virtual resources.
I don't want to discuss any non-technical implications, esp. business
stuff, here, but IMHO one cannot leave the control plane aside.

> It might be useful to focus on the arch aspects first.

Do you consider the data plane aspects as being the architecture?
IMHO the control plane aspects belongs to the architecture as well!

> Also, it'd be useful to understand your view of the relationship of
> these definitions to PPVPNs, VPNs, etc.

I have no clear description yet, but VPNs usually are not including
the virtual node aspect. They are mainly about providing/establishing
links to connect to an existing infrastructure and are more a kind of
overlay. I think we need to come  up with a clearer distinction, but
that will need more time.

Regards,
 Roland

From dimitri.papadimitriou@alcatel-lucent.com  Wed Aug  3 15:50:33 2011
Return-Path: <dimitri.papadimitriou@alcatel-lucent.com>
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 9FF5F11E809B for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 15:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.249
X-Spam-Level: 
X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 vEYVb8GAR0An for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 15:50:32 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7749721F8781 for <vnrg@irtf.org>; Wed,  3 Aug 2011 15:50:32 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p73MogDa004909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 Aug 2011 00:50:42 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 4 Aug 2011 00:50:42 +0200
From: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
To: Roland Bless <roland.bless@kit.edu>
Date: Thu, 4 Aug 2011 00:50:41 +0200
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxSFxOmkWOETIEKQ6OG68O3d+bc4QAAOYOA
Message-ID: <EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu> <EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E39A744.8010508@kit.edu>
In-Reply-To: <4E39A744.8010508@kit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Wed, 03 Aug 2011 22:50:33 -0000

Hi Roland,=20

> -----Original Message-----
> From: Roland Bless [mailto:roland.bless@kit.edu]=20
> Sent: Wednesday, August 03, 2011 9:54 PM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: vnrg@irtf.org
> Subject: Re: [vnrg] Some definitions and way forward
>=20
> Hi Dimitri,
>=20
> On 03.08.2011 18:07, Papadimitriou, Dimitri (Dimitri) wrote:
>=20
> > These definitions stems from the view that physical resource owner
> > provides virtual resources of the same kind (delimits the type of
> > virtual resources it can deliver). My understanding from the scope
> > given in the Maastricht meeting was:
>=20
> Not clear how you infer this view, since I don't see this kind of
> restriction in my text.

For instance: "The Infrastructure Provider (InP) is responsible for maintai=
ning physical networking resources, such as routers, links, wireless infras=
tructure, etc., and enabling the virtualization of these resources. "

Hence, the question why only infrastructure providers are assumed to own ph=
ysical resources that can host virtual resources composing a virtual networ=
k ? The question also can be asked in more general terms (independently of =
the ownership): why only physical networking resources would be capable to =
host virtual resources ?

> > - virtual resources can be hosted on physical resources of different
> > type i.e. virtual nodes/links don't have to be instantiated from
> > physical nodes/links; for instance, a virtual network can comprise
> > virtual nodes that are bringing together/aggregating resources from
> > multiple physical nodes AND a set of virtual nodes that are emulated
> > on a single physical machine.
>=20
> Thanks for pointing this out, but the given definitions
> don't exclude that.=20

The definition provided are only explicit about aggregation and partition a=
t the substrate-level (cf. "Substrate resources can either be partitioned o=
r aggregated in order to provide a virtual resource.") whereas allowing to =
run N virtual resources on a given partition of physical resources should a=
lso be considered.

A simple example: one can run today a couple of virtual routers on a single=
 partition of a server (hosting multiple partitions) and emulate communicat=
ion between these partitions, thus create a virtual network within the cont=
ext of single physical resource.=20

You seem to assume this is not excluded from the definitions you provided s=
o please explain where this is the case ?=20

> How you map virtual nodes and virtual
> links onto the substrate resources may vary a lot.

Indeed but definitions do not have to explain the "how" (e.g. how mapping i=
s performed) but "what" (this mapping provides)

> We also
> consider mapping a virtual link onto a substrate node since
> both virtual nodes that are connected by the link are hosted
> on the same substrate node. I think it would be good to provide
> some examples of mappings to make this clear, maybe when discussing
> the terms virtual links and virtual nodes in more detail.

See above concerning the example.=20

> > - virtual resources composing a virtual network can be of different
> > type and thus virtually operate at different layers (thus beyond
> > nodes and links operating at a given layer) including
> > wireless/wireline virtual links with different properties (with or
> > without emulated delay), hosts and intermediate nodes of different
> > kind, e.g., switches, routers, base stations, etc.). This is
> > basically what makes the difference between an "overlay network" and
> > "virtual network".
>=20
> This is important, but probably not easy to grasp. I don't want to
> exclude having virtual switches or virtual wireless links and so on,
> but it's probably complicated to discuss them all together across
> different layers. If you consider virtual routers, then=20
> virtual switches
> are probably "transparent" connectors just as they are for IP
> routers in physical networks.

The latter is about the actual use of the virtual network.=20

The definitions have to comprise the notion of composition: the possibility=
 to map different types of physical resources to different types of virtual=
 resources that can operate different and be combined to provide a virtual =
network.=20

> I think we need to work on that.
>
> The difference to overlay networks is IMHO (as also discussed in
> earlier mail
> http://www.ietf.org/mail-archive/web/vnrg/current/msg00224.html) that
> overlay nodes are always sitting at the "ends"
> of its underlying layer (the underlay).
>
> > The role definitions here below tend to reproduce (and thus somehow
> > limit) the roles we actually know from "physical networks". Taking
> > the above definitions, if the virtual network would be running on
> > physical hosts, "providers" would not maintain any physical resource
> > of the type indicated here below (routers, links, wireless
> > infrastructure, etc.) but only computing resources on
> > terminals/servers.
>=20
> As already said above, I can't infer restrictions directly=20
> from my text,

It is written texto in your definitions you have provided ""Out-of-VNet acc=
ess" to control the virtual resources, allowing him to configure and manage=
 them just like a traditional network operator manages physical network res=
ources."

> but I'd suggest that we provide examples that make these aspects very
> clear. The provided definitions perfectly allow that a whole virtual
> network is embedded into a single physical substrate host.

As stated above I don't see where in the definitions. As stated above the d=
efinition constrict a virtual resource of type X to be hosted on physical r=
esources of type X whereas is should read a virtual resource of type X coul=
d be hosted on a physical resource of type Y.

> On the other hand one can expect that also virtual networks are used
> to transport data over some physical distance in many cases. If this
> isn't the case one may probably come up with simpler structures that
> provide the same level of isolation, e.g., no need to provide a large
> virtual infrastructure using several virtual routers if you=20
> merely need
> to connect virtual nodes that are *always* residing inside the same
> physical host - a single virtual switch or router may provide=20
> sufficient
> connectivity or isolation between them (depending on the addressing
> scheme); this may change as soon as the virtual nodes
> may actually move to different substrate nodes...
>=20
> > The role definitions provided here below tend to enforce too a
> > client-server strict demarcation between resource owner and=20
> non-owner
>=20
> Which resource do you mean here the virtual or the substrate resource?

Following the definitions you have provided the ownership of the substrate =
delimits the resource space accessible to host the virtual resources (Note:=
 this has been the main point of discussion during the meeting in Beijing).=
=20

> > merging thus a functional and operational role whereas demarcation
> > would be needed between an external entity to the VN (as=20
> delimited by
> > the functionality that the VN delivers) and a Virtual NAP (whether
> > one owns the underlying resources or not).
>=20
> Sorry, now I'm lost, I don't get your point here - can you provide
> an example?=20

Here below, a simple example:=20

        -------------VN---------------
       |                              |
      VNAP         ||                 |
  EE --X--> VR <---||---> VR          |
  |    |    |      ||    / | \        |
  R5   |   R4 R3---||---  R2  --- R1  |
       |           ||                 |
        -----------||-----------------
                   ||
<---- Owner 1 ---->||<--- Owner 2 --->


A functional demarcation line between EE and the VN exists because the VN p=
rovides a functionality to the EE not because the "resources" (R1,R2,R3,R4)=
 (or what they can virtually host) are owned by the "VN provider" i.e. here=
 R3, R4 belongs to Owner 1 and R2, R3 to Owner 2. =20

In brief, the underlying architectural question is not about drawing demarc=
ation lines between different owners of physical resources but about the fu=
nctional demarcation determined by the composition of VR.

> I don't think that any client-server based demarcation
> is implied by the proposed architecture,=20

Referring to the definitions you have provided "A service provider may prov=
ide services to end-users by using the protocols running inside the virtual=
 network. Consider an IP-TV provider who delivers IP-TV inside the VNet to =
his customers."

> actually we also considered P2P-based
> self-organized access structures for controlling the virtual=20
> resources...
>
> Thanks for your input, that was exactly what I was looking for,
> i.e., collecting different viewpoints in order to complete the
> big picture.

Thanks,
-dimitri.
=20
> Regards,
>  Roland
>=20
> =

From roland.bless@kit.edu  Thu Aug  4 01:36:17 2011
Return-Path: <roland.bless@kit.edu>
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 CB24B21F8BAA for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 01:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.992
X-Spam-Level: 
X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=0.257,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 mKlnJ6gTfOzI for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 01:36:17 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 80A6721F8BA0 for <vnrg@irtf.org>; Thu,  4 Aug 2011 01:36:15 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1QotPf-0007W2-WF; Thu, 04 Aug 2011 10:36:26 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id A6244A80025; Thu,  4 Aug 2011 10:36:17 +0200 (CEST)
Message-ID: <4E3A59FE.1090809@kit.edu>
Date: Thu, 04 Aug 2011 10:36:14 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu> <EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E39A744.8010508@kit.edu> <EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
In-Reply-To: <EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1312446986.254207000
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Thu, 04 Aug 2011 08:36:17 -0000

Hi Dimitri,

On 04.08.2011 00:50, Papadimitriou, Dimitri (Dimitri) wrote:
> For instance: "The Infrastructure Provider (InP) is responsible for
> maintaining physical networking resources, such as routers, links,
> wireless infrastructure, etc., and enabling the virtualization of
> these resources. "
> 
> Hence, the question why only infrastructure providers are assumed to
> own physical resources that can host virtual resources composing a
> virtual network ? The question also can be asked in more general
> terms (independently of the ownership): why only physical networking
> resources would be capable to host virtual resources ?

You mean recursion? You are absolutely right if you mean
that virtual resources can be also hosted on top of virtual resources.
I definitely don't want to exclude that.

But: I find it easier to discuss the "lowest level" of virtualization
here, before going into recursion aspects. Even if you are somewhere up
in the hierarchy where virtual resources are built out of other virtual
resources, they have to materialize somewhere at the lowest physical
level in some form. I concentrated talking about this lowest level of
virtualization, where virtual resources are directly hosted on
substrate resources. My text thus stated in the beginning:
>> I'll leave recursion aspects aside at first since it usually
>> complicates the discussion

If you consider the possibility of using virtual resources as
(virtual) substrate, you are entering the recursion domain. Maybe
we can distinguish the physical substrate from the virtual substrate.
I can also imagine that a VNet is made up of using both types of
subtrate at the same time, e.g.,

                 VNet A
                /      \
               /    Virtual Resources
              /          \
   (Physical) Substrate Resources

At the lowest level, however, it boils down to physical resources
somehow, doesn't it? Since the virtual resources are abstracting
from physical resources it actually doesn't matter so much whether
your substrate is virtual or physical...

> The definition provided are only explicit about aggregation and
> partition at the substrate-level (cf. "Substrate resources can either be
> partitioned or aggregated in order to provide a virtual resource.")
> whereas allowing to run N virtual resources on a given partition of
> physical resources should also be considered.

Ok, but you need to distinguish each of the N virtual resources
somehow in that particular partition due to isolation.
Isn't this also some kind of partitioning? Maybe it is a special
kind if they share the resource and their partitions are thus
not static but variable to some extent? This would be extremely
useful in some cases in order to get some statistical multiplexing
gain, but the QoS guarantee for the virtual resource is also only
statistical, which is ok.

> A simple example: one can run today a couple of virtual routers on a
> single partition of a server (hosting multiple partitions) and emulate
> communication between these partitions, thus create a virtual network
> within the context of single physical resource.
>
> You seem to assume this is not excluded from the definitions you
> provided so please explain where this is the case ?

Since it is left open how you map the virtual resources onto
the physical resources, i.e., which virtual resource is mapped
onto which particular substrate resource.
If you want to map several virtual nodes onto a single substrate node,
that's fine. In this case the virtual links collapse to some shortcut
inside the substrate node, usually inter-process communication via
memory. The latter is a perfect example for your postulation that the
types can be different: a virtual link is mapped to a node/host/memory.
Perfectly valid IMHO.

>> How you map virtual nodes and virtual
>> links onto the substrate resources may vary a lot.
> 
> Indeed but definitions do not have to explain the "how" (e.g. how
> mapping is performed) but "what" (this mapping provides)

I think we mean the same thing: with "how" I actually meant
what is mapped onto what, e.g., a virtual link onto a substrate node
or substrate path etc.

> The definitions have to comprise the notion of composition: the
> possibility to map different types of physical resources to different
> types of virtual resources that can operate different and be combined
> to provide a virtual network.

I don't know whether composition is the right term or whether we
need a term for this at all.

> It is written texto in your definitions you have provided
> ""Out-of-VNet access" to control the virtual resources, allowing him
> to configure and manage them just like a traditional network operator
> manages physical network resources."

I don't see a problem here since virtual resources should appear
like the real resources. Whether they are made up of physical or
virtual resources doesn't matter in this respect. You still need
to manage your virtual resources, don't you?

>> but I'd suggest that we provide examples that make these aspects very
>> clear. The provided definitions perfectly allow that a whole virtual
>> network is embedded into a single physical substrate host.

> As stated above I don't see where in the definitions. As stated above
> the definition constrict a virtual resource of type X to be hosted on
> physical resources of type X whereas is should read a virtual
> resource of type X could be hosted on a physical resource of type Y.

Agreed as in the above example, but I just stated that virtual
resources are mapped onto substrate resources, but didn't require
anything on their type equivalence/strictness AFAICT.

>> Which resource do you mean here the virtual or the substrate resource?

> Following the definitions you have provided the ownership of the
> substrate delimits the resource space accessible to host the virtual
> resources (Note: this has been the main point of discussion during
> the meeting in Beijing).

Unfortunately, I wasn't present in Beijing and maybe didn't get the
point from reading the notes.

> Here below, a simple example: 
> 
>         -------------VN---------------
>        |                              |
>       VNAP         ||                 |
>   EE --X--> VR <---||---> VR          |
>   |    |    |      ||    / | \        |
>   R5   |   R4 R3---||---  R2  --- R1  |
>        |           ||                 |
>         -----------||-----------------
>                    ||
> <---- Owner 1 ---->||<--- Owner 2 --->
> 

> A functional demarcation line between EE and the VN exists because
> the VN provides a functionality to the EE not because the "resources"
> (R1,R2,R3,R4) (or what they can virtually host) are owned by the "VN
> provider" i.e. here R3, R4 belongs to Owner 1 and R2, R3 to Owner 2.

Yes, agreed, the virtual resources of the VNet are owned/managed by
the VNO, but it doesn't matter from this point of view who owns the
substrate resources where the virtual resources are running on.

> In brief, the underlying architectural question is not about drawing
> demarcation lines between different owners of physical resources but
> about the functional demarcation determined by the composition of VR.

However, interfaces must exist between different substrate providers
that need to draw a virtual link between some of their substrate nodes,
which host the corresponding virtual nodes.

Thanks for clarifying,
 Roland

From andreas.fischer@uni-passau.de  Thu Aug  4 01:56:51 2011
Return-Path: <andreas.fischer@uni-passau.de>
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 424DE21F8B83 for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 01:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 EQTInUfMrfSu for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 01:56:50 -0700 (PDT)
Received: from tom.rz.uni-passau.de (tom.rz.uni-passau.de [132.231.51.4]) by ietfa.amsl.com (Postfix) with ESMTP id F3F9721F8AD2 for <vnrg@irtf.org>; Thu,  4 Aug 2011 01:56:49 -0700 (PDT)
Received: from tom.rz.uni-passau.de (puremessage.rz.uni-passau.de [132.231.51.54]) by tom.rz.uni-passau.de (Postfix) with SMTP id 3C4422E0936 for <vnrg@irtf.org>; Thu,  4 Aug 2011 10:57:03 +0200 (CEST)
Received: from mail.uni-passau.de (localhost [127.0.0.1]) by tom.rz.uni-passau.de (Postfix) with ESMTP id E54A52E07DD for <vnrg@irtf.org>; Thu,  4 Aug 2011 10:57:02 +0200 (CEST)
Received: from [132.231.13.115] (helo=[132.231.13.115]) by mail.uni-passau.de with ESMTP (eXpurgate 3.2.5) (envelope-from <andreas.fischer@uni-passau.de>) id 4e3a5ede-104a-84e70d730842-1 for <vnrg@irtf.org>; Thu, 04 Aug 2011 10:57:02 +0200
Message-ID: <4E3A5EDE.2060208@uni-passau.de>
Date: Thu, 04 Aug 2011 10:57:02 +0200
From: Andreas Fischer <andreas.fischer@uni-passau.de>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: vnrg@irtf.org
References: <4E3936FF.1090006@kit.edu> <4E39750A.2080302@isi.edu> <4E39A9E8.5070307@kit.edu>
In-Reply-To: <4E39A9E8.5070307@kit.edu>
X-Enigmail-Version: 1.2
Content-Type: multipart/mixed; boundary="------------010107010505060108090203"
X-purgate-ID: 151291::1312448222-0000104A-179091EC/0-0/0-0
X-purgate-type: clean
X-purgate-size: 2196
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate: clean
X-PerlMx-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, MIME_TEXT_ONLY_MP_MIXED 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, RDNS_NXDOMAIN 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0'
Subject: Re: [vnrg] Some definitions and way forward
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: Thu, 04 Aug 2011 08:56:51 -0000

This is a multi-part message in MIME format.
--------------010107010505060108090203
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Roland, Joe,

>> Also, it'd be useful to understand your view of the relationship
>> of these definitions to PPVPNs, VPNs, etc.
> 
> I have no clear description yet, but VPNs usually are not including 
> the virtual node aspect. They are mainly about
> providing/establishing links to connect to an existing infrastructure
> and are more a kind of overlay. I think we need to come  up with a
> clearer distinction, but that will need more time.

Aren't VPNs just one kind of link virtualization? VPNs are basically
tunnels with added encryption, no? Tunnels, on the other hand, just
create a "virtual link" between two arbitrary nodes in a network.

As such, I would also disagree to consider them as kind of an overlay
network, as
a) They don't build a network, only a link (the 'N' in 'VPN' is
misleading, IMHO)
b) They are not necessarily between end hosts (which conflicts your
earlier statement, that overlay nodes are always sitting at the edge of
the network)

Regards,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOOl7eAjz9S4YPAw8RAm6VAJ4vKG+OBDXMIe9novs0Pk4bWMtlBgCePEKc
OMCz/O7q0UmUPB9X5nKcX2g=
=8z6n
-----END PGP SIGNATURE-----

--------------010107010505060108090203
Content-Type: text/x-vcard; charset=utf-8;
 name="andreas_fischer.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="andreas_fischer.vcf"

begin:vcard
fn:Andreas Fischer
n:Fischer;Andreas
org:University of Passau;Computer Networks and Computer Communications
adr:;;Innstrasse 43;94032 Passau;;;Germany
email;internet:andreas.fischer@uni-passau.de
tel;work:(+49) 851 509-3057
note;quoted-printable:PGP / GPG Key Fingerprint:=0D=0A=
	FC6C 9D76 F36E 9349 5CA4 ED02 023C FD4B 860F 030F
x-mozilla-html:FALSE
url:http://www.net.fim.uni-passau.de/fischer
version:2.1
end:vcard


--------------010107010505060108090203--

From Michael.Scharf@alcatel-lucent.com  Thu Aug  4 02:35:43 2011
Return-Path: <Michael.Scharf@alcatel-lucent.com>
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 3965221F8B7B for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 02:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.22
X-Spam-Level: 
X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 38sygia7FDQq for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 02:35:42 -0700 (PDT)
Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 81CC021F8B5F for <vnrg@irtf.org>; Thu,  4 Aug 2011 02:35:41 -0700 (PDT)
Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p749ZrRX032307; Thu, 4 Aug 2011 11:35:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 4 Aug 2011 11:35:52 +0200
Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654BE35@SLFSNX.rcs.alcatel-research.de>
In-Reply-To: <4E3A5EDE.2060208@uni-passau.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxShILN5i7FfDB2S2WL8dcmKUq7CgABE4wg
References: <4E3936FF.1090006@kit.edu> <4E39750A.2080302@isi.edu><4E39A9E8.5070307@kit.edu> <4E3A5EDE.2060208@uni-passau.de>
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
To: "Andreas Fischer" <andreas.fischer@uni-passau.de>
X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward
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: Thu, 04 Aug 2011 09:35:43 -0000

> Aren't VPNs just one kind of link virtualization? VPNs are=20
> basically tunnels with added encryption, no? Tunnels, on the=20
> other hand, just create a "virtual link" between two=20
> arbitrary nodes in a network.

This may be an oversimplification. There are of course many existing
multipoint-to-multipoint VPN technologies that go much beyond link
virtualization. An example is VPLS.

Michael

From roland.bless@kit.edu  Thu Aug  4 02:53:10 2011
Return-Path: <roland.bless@kit.edu>
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 B003F21F8B1B for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 02:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.006
X-Spam-Level: 
X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.243,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 tZt2jIFIKkxh for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 02:53:10 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id DABEB21F8B03 for <vnrg@irtf.org>; Thu,  4 Aug 2011 02:53:09 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1Qouc8-00083g-La; Thu, 04 Aug 2011 11:53:23 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 60EB9A80025; Thu,  4 Aug 2011 11:53:15 +0200 (CEST)
Message-ID: <4E3A6C09.8010505@kit.edu>
Date: Thu, 04 Aug 2011 11:53:13 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Andreas Fischer <andreas.fischer@uni-passau.de>
References: <4E3936FF.1090006@kit.edu> <4E39750A.2080302@isi.edu>	<4E39A9E8.5070307@kit.edu> <4E3A5EDE.2060208@uni-passau.de>
In-Reply-To: <4E3A5EDE.2060208@uni-passau.de>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1312451603.432147000
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward
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: Thu, 04 Aug 2011 09:53:10 -0000

Hi Andreas,

On 04.08.2011 10:57, Andreas Fischer wrote:
> Aren't VPNs just one kind of link virtualization? VPNs are basically
> tunnels with added encryption, no? Tunnels, on the other hand, just
> create a "virtual link" between two arbitrary nodes in a network.

Yes, but a tunnel is IMHO an overlay technique:
it is created between the end-points of the underlying layer. Consider
an L3-VPN, consisting of networks N1 and N2 and a "virtual link" between
them.

 /----\                        /----\
|  N1  |--R1==============R4--|      |
|      |  |                |  |  N2  |
 \----/   +-----R2----R3---+   \----/

N1 and N2 are networks that are connected via some provider network.
R1 and R4 are their access routers. The tunnel is established between
the endpoints R1 and R4, i.e., they are source/sink of the outer header
of the tunnel packets and the tunnel is terminated there. R2 and R3 are
not and do not have to be aware of the virtual link in this case.
A non-overlay solution would require awareness in R2/R3, e.g., creating
and LSP.

> As such, I would also disagree to consider them as kind of an overlay
> network, as
> a) They don't build a network, only a link (the 'N' in 'VPN' is
> misleading, IMHO)

Hm, but there are other nodes connected by that tunnel, e.g.,
N1 and N2 may have their own routers etc. Especially, they
have their own addressing scheme and routing inside their
VPN.

> b) They are not necessarily between end hosts (which conflicts your
> earlier statement, that overlay nodes are always sitting at the edge of
> the network)

But always between end-points (in an addressing sense, not in a
topological sense) of the underlay/substrate. If one defines a host
as being either source or sink of packets, the term host is also
correct. In the above example, we have R1 and R4 being routers in the
substrate, but from a forwarding perspective, they are end-points
(hosts) for the tunnel. For VPN traffic, the hosts will reside in N1 or
N2.

Regards,
 Roland

From dimitri.papadimitriou@alcatel-lucent.com  Thu Aug  4 03:28:33 2011
Return-Path: <dimitri.papadimitriou@alcatel-lucent.com>
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 B742821F8B25 for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 03:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.449
X-Spam-Level: 
X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=0.800,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 L6GK23uee-XA for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 03:28:32 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 62B4B21F88B7 for <vnrg@irtf.org>; Thu,  4 Aug 2011 03:28:31 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p74ASh8f002767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 Aug 2011 12:28:43 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 4 Aug 2011 12:28:43 +0200
From: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
To: Roland Bless <roland.bless@kit.edu>
Date: Thu, 4 Aug 2011 12:28:42 +0200
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxSgZ9TE4SnMQegSl6UV+R/mKATFAAC10nw
Message-ID: <EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu> <EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E39A744.8010508@kit.edu> <EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E3A59FE.1090809@kit.edu>
In-Reply-To: <4E3A59FE.1090809@kit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Thu, 04 Aug 2011 10:28:33 -0000

Hi,

Trying to summarize the discussion:

o) VNRG, even if dealing virtual network, does not mandate VN provided excl=
usively by networking infrastructure providers. Part of the problem comes f=
rom the definition initially proposed which refers to Infrastructure Provid=
er whereas one should speak about a Physical Resource Host (or a term that =
doesn't implicitly assign VN roles from the roles inherited by current phys=
ical networks).=20

o) Next we should not restrict physical resources to networking nodes / lin=
ks but also incorporate storage and processing resources (a.k.a IT resource=
s). Thus, instead of restricting a virtual resource of type X to be hosted =
on physical resources of type X, the definitions should allow for a virtual=
 resource of type X to be hosted on a physical resource of type Y.=20

o) Moreover, we have to better distinguish the type of resource from their =
function/role. In the initial definition, there is a 1:1 relationship (beca=
use a physical networking node can only host virtual nodes e.g. virtual rou=
ters), whereas in the example provided in the previous e-mail (case of emul=
ation of virtual resources), there is a 1:N relationship (IT resources can =
emulate a set of routers).

o) Finally, the partition of the physical resources on which the VN relies =
should not determine the delimitation of that VN. Whatever the criteria of =
demarcation between physical resources being administrative, ownership, etc=
. as long as we don't find an architecturally constraining reason these dif=
ferent levels of demarcation should be left independent.

Thanks,
-dimitri.

> -----Original Message-----
> From: Roland Bless [mailto:roland.bless@kit.edu]=20
> Sent: Thursday, August 04, 2011 10:36 AM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: vnrg@irtf.org
> Subject: Re: [vnrg] Some definitions and way forward
>=20
> Hi Dimitri,
>=20
> On 04.08.2011 00:50, Papadimitriou, Dimitri (Dimitri) wrote:
> > For instance: "The Infrastructure Provider (InP) is responsible for
> > maintaining physical networking resources, such as routers, links,
> > wireless infrastructure, etc., and enabling the virtualization of
> > these resources. "
> >=20
> > Hence, the question why only infrastructure providers are assumed to
> > own physical resources that can host virtual resources composing a
> > virtual network ? The question also can be asked in more general
> > terms (independently of the ownership): why only physical networking
> > resources would be capable to host virtual resources ?
>=20
> You mean recursion? You are absolutely right if you mean
> that virtual resources can be also hosted on top of virtual resources.
> I definitely don't want to exclude that.
>=20
> But: I find it easier to discuss the "lowest level" of virtualization
> here, before going into recursion aspects. Even if you are=20
> somewhere up
> in the hierarchy where virtual resources are built out of=20
> other virtual
> resources, they have to materialize somewhere at the lowest physical
> level in some form. I concentrated talking about this lowest level of
> virtualization, where virtual resources are directly hosted on
> substrate resources. My text thus stated in the beginning:
> >> I'll leave recursion aspects aside at first since it usually
> >> complicates the discussion
>=20
> If you consider the possibility of using virtual resources as
> (virtual) substrate, you are entering the recursion domain. Maybe
> we can distinguish the physical substrate from the virtual substrate.
> I can also imagine that a VNet is made up of using both types of
> subtrate at the same time, e.g.,
>=20
>                  VNet A
>                 /      \
>                /    Virtual Resources
>               /          \
>    (Physical) Substrate Resources
>=20
> At the lowest level, however, it boils down to physical resources
> somehow, doesn't it? Since the virtual resources are abstracting
> from physical resources it actually doesn't matter so much whether
> your substrate is virtual or physical...
>=20
> > The definition provided are only explicit about aggregation and
> > partition at the substrate-level (cf. "Substrate resources=20
> can either be
> > partitioned or aggregated in order to provide a virtual resource.")
> > whereas allowing to run N virtual resources on a given partition of
> > physical resources should also be considered.
>=20
> Ok, but you need to distinguish each of the N virtual resources
> somehow in that particular partition due to isolation.
> Isn't this also some kind of partitioning? Maybe it is a special
> kind if they share the resource and their partitions are thus
> not static but variable to some extent? This would be extremely
> useful in some cases in order to get some statistical multiplexing
> gain, but the QoS guarantee for the virtual resource is also only
> statistical, which is ok.
>=20
> > A simple example: one can run today a couple of virtual routers on a
> > single partition of a server (hosting multiple partitions)=20
> and emulate
> > communication between these partitions, thus create a=20
> virtual network
> > within the context of single physical resource.
> >
> > You seem to assume this is not excluded from the definitions you
> > provided so please explain where this is the case ?
>=20
> Since it is left open how you map the virtual resources onto
> the physical resources, i.e., which virtual resource is mapped
> onto which particular substrate resource.
> If you want to map several virtual nodes onto a single substrate node,
> that's fine. In this case the virtual links collapse to some shortcut
> inside the substrate node, usually inter-process communication via
> memory. The latter is a perfect example for your postulation that the
> types can be different: a virtual link is mapped to a=20
> node/host/memory.
> Perfectly valid IMHO.
>=20
> >> How you map virtual nodes and virtual
> >> links onto the substrate resources may vary a lot.
> >=20
> > Indeed but definitions do not have to explain the "how" (e.g. how
> > mapping is performed) but "what" (this mapping provides)
>=20
> I think we mean the same thing: with "how" I actually meant
> what is mapped onto what, e.g., a virtual link onto a substrate node
> or substrate path etc.
>=20
> > The definitions have to comprise the notion of composition: the
> > possibility to map different types of physical resources to=20
> different
> > types of virtual resources that can operate different and=20
> be combined
> > to provide a virtual network.
>=20
> I don't know whether composition is the right term or whether we
> need a term for this at all.
>=20
> > It is written texto in your definitions you have provided
> > ""Out-of-VNet access" to control the virtual resources, allowing him
> > to configure and manage them just like a traditional=20
> network operator
> > manages physical network resources."
>=20
> I don't see a problem here since virtual resources should appear
> like the real resources. Whether they are made up of physical or
> virtual resources doesn't matter in this respect. You still need
> to manage your virtual resources, don't you?
>=20
> >> but I'd suggest that we provide examples that make these=20
> aspects very
> >> clear. The provided definitions perfectly allow that a=20
> whole virtual
> >> network is embedded into a single physical substrate host.
>=20
> > As stated above I don't see where in the definitions. As=20
> stated above
> > the definition constrict a virtual resource of type X to be=20
> hosted on
> > physical resources of type X whereas is should read a virtual
> > resource of type X could be hosted on a physical resource of type Y.
>=20
> Agreed as in the above example, but I just stated that virtual
> resources are mapped onto substrate resources, but didn't require
> anything on their type equivalence/strictness AFAICT.
>=20
> >> Which resource do you mean here the virtual or the=20
> substrate resource?
>=20
> > Following the definitions you have provided the ownership of the
> > substrate delimits the resource space accessible to host the virtual
> > resources (Note: this has been the main point of discussion during
> > the meeting in Beijing).
>=20
> Unfortunately, I wasn't present in Beijing and maybe didn't get the
> point from reading the notes.
>=20
> > Here below, a simple example:=20
> >=20
> >         -------------VN---------------
> >        |                              |
> >       VNAP         ||                 |
> >   EE --X--> VR <---||---> VR          |
> >   |    |    |      ||    / | \        |
> >   R5   |   R4 R3---||---  R2  --- R1  |
> >        |           ||                 |
> >         -----------||-----------------
> >                    ||
> > <---- Owner 1 ---->||<--- Owner 2 --->
> >=20
>=20
> > A functional demarcation line between EE and the VN exists because
> > the VN provides a functionality to the EE not because the=20
> "resources"
> > (R1,R2,R3,R4) (or what they can virtually host) are owned by the "VN
> > provider" i.e. here R3, R4 belongs to Owner 1 and R2, R3 to Owner 2.
>=20
> Yes, agreed, the virtual resources of the VNet are owned/managed by
> the VNO, but it doesn't matter from this point of view who owns the
> substrate resources where the virtual resources are running on.
>=20
> > In brief, the underlying architectural question is not about drawing
> > demarcation lines between different owners of physical resources but
> > about the functional demarcation determined by the=20
> composition of VR.
>=20
> However, interfaces must exist between different substrate providers
> that need to draw a virtual link between some of their=20
> substrate nodes,
> which host the corresponding virtual nodes.
>=20
> Thanks for clarifying,
>  Roland
> =

From andreas.fischer@uni-passau.de  Thu Aug  4 03:47:00 2011
Return-Path: <andreas.fischer@uni-passau.de>
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 D5B1E21F8B04 for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 03:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 S0Y+P-7oomUq for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 03:47:00 -0700 (PDT)
Received: from tom.rz.uni-passau.de (tom.rz.uni-passau.de [132.231.51.4]) by ietfa.amsl.com (Postfix) with ESMTP id C564B21F8B00 for <vnrg@irtf.org>; Thu,  4 Aug 2011 03:46:59 -0700 (PDT)
Received: from tom.rz.uni-passau.de (puremessage.rz.uni-passau.de [132.231.51.54]) by tom.rz.uni-passau.de (Postfix) with SMTP id B91DC2E0951; Thu,  4 Aug 2011 12:47:13 +0200 (CEST)
Received: from mail.uni-passau.de (localhost [127.0.0.1]) by tom.rz.uni-passau.de (Postfix) with ESMTP id 5FE522E0954; Thu,  4 Aug 2011 12:47:13 +0200 (CEST)
Received: from [132.231.13.115] (helo=[132.231.13.115]) by mail.uni-passau.de with ESMTP (eXpurgate 3.2.5) (envelope-from <andreas.fischer@uni-passau.de>) id 4e3a78b1-104a-84e70d7309a9-1 for <multiple-recipients>; Thu, 04 Aug 2011 12:47:13 +0200
Message-ID: <4E3A78B1.1050808@uni-passau.de>
Date: Thu, 04 Aug 2011 12:47:13 +0200
From: Andreas Fischer <andreas.fischer@uni-passau.de>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Roland Bless <roland.bless@kit.edu>
References: <4E3936FF.1090006@kit.edu> <4E39750A.2080302@isi.edu>	<4E39A9E8.5070307@kit.edu> <4E3A5EDE.2060208@uni-passau.de> <4E3A6C09.8010505@kit.edu>
In-Reply-To: <4E3A6C09.8010505@kit.edu>
X-Enigmail-Version: 1.2
Content-Type: multipart/mixed; boundary="------------000109060709090006020301"
X-purgate-ID: 151291::1312454833-0000104A-039F604E/0-0/0-0
X-purgate-type: clean
X-purgate-size: 3658
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate: clean
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MIME_TEXT_ONLY_MP_MIXED 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, RDNS_NXDOMAIN 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FRAUD_FUNWORDS 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0'
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward
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: Thu, 04 Aug 2011 10:47:01 -0000

This is a multi-part message in MIME format.
--------------000109060709090006020301
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Roland,

On 04.08.2011 11:53, Roland Bless wrote:
> Hi Andreas,
> 
> On 04.08.2011 10:57, Andreas Fischer wrote:
>> Aren't VPNs just one kind of link virtualization? VPNs are
>> basically tunnels with added encryption, no? Tunnels, on the other
>> hand, just create a "virtual link" between two arbitrary nodes in a
>> network.
> 
> Yes, but a tunnel is IMHO an overlay technique: it is created between
> the end-points of the underlying layer. Consider an L3-VPN,
> consisting of networks N1 and N2 and a "virtual link" between them.
> 
> /----\                        /----\ |  N1  |--R1==============R4--|
> | |      |  |                |  |  N2  | \----/   +-----R2----R3---+
> \----/
> 
> N1 and N2 are networks that are connected via some provider network. 
> R1 and R4 are their access routers. The tunnel is established
> between the endpoints R1 and R4, i.e., they are source/sink of the
> outer header of the tunnel packets and the tunnel is terminated
> there. R2 and R3 are not and do not have to be aware of the virtual
> link in this case. A non-overlay solution would require awareness in
> R2/R3, e.g., creating and LSP.

Ok, I think I had a slightly different notion of overlay here. If an
overlay is characterized by being transparent to the substrate (except
for the end-points, of course), then I agree with your point.

>> As such, I would also disagree to consider them as kind of an
>> overlay network, as a) They don't build a network, only a link (the
>> 'N' in 'VPN' is misleading, IMHO)
> 
> Hm, but there are other nodes connected by that tunnel, e.g., N1 and
> N2 may have their own routers etc. Especially, they have their own
> addressing scheme and routing inside their VPN.

Depends. If you consider the conglomerate of N1, R1, R4, and N2 as being
the VPN, then there is actually a network. However, then the 'V' and the
'P' are misleading. This network is - for a large part - not virtual,
but real. Moreover, it is not necessarily private - R1 may possibly only
route certain traffic via the tunnel (e.g. only traffic destined for
N2), whereas the rest may be open to the Internet.

Regarding typical implementations (IPSec, OpenVPN, SSH, ...) I would
consider the VPN in your picture consisting of just the tunnel.
Therefore my argument, that it isn't actually a network, just a link
(apologies to Michael - I did not consider multipoint-to-multipoint VPNs
here).

Regards,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOOnixAjz9S4YPAw8RAgXJAJ9fvf/NM/Cwz/c27u6clGPcQmCgVgCeMLwE
tJ3mMZyvem60hZeR0tkADZ0=
=OOYA
-----END PGP SIGNATURE-----

--------------000109060709090006020301
Content-Type: text/x-vcard; charset=utf-8;
 name="andreas_fischer.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="andreas_fischer.vcf"

begin:vcard
fn:Andreas Fischer
n:Fischer;Andreas
org:University of Passau;Computer Networks and Computer Communications
adr:;;Innstrasse 43;94032 Passau;;;Germany
email;internet:andreas.fischer@uni-passau.de
tel;work:(+49) 851 509-3057
note;quoted-printable:PGP / GPG Key Fingerprint:=0D=0A=
	FC6C 9D76 F36E 9349 5CA4 ED02 023C FD4B 860F 030F
x-mozilla-html:FALSE
url:http://www.net.fim.uni-passau.de/fischer
version:2.1
end:vcard


--------------000109060709090006020301--

From touch@isi.edu  Thu Aug  4 11:00:22 2011
Return-Path: <touch@isi.edu>
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 3CB725E800E for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 11:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.22
X-Spam-Level: 
X-Spam-Status: No, score=-103.22 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, 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 IylzPJFc5o3J for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 11:00:21 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C38335E8002 for <vnrg@irtf.org>; Thu,  4 Aug 2011 11:00:21 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p74I0IEX027091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Aug 2011 11:00:18 -0700 (PDT)
Message-ID: <4E3ADE32.4050601@isi.edu>
Date: Thu, 04 Aug 2011 11:00:18 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Roland Bless <roland.bless@kit.edu>
References: <4E3936FF.1090006@kit.edu> <4E39750A.2080302@isi.edu>	<4E39A9E8.5070307@kit.edu> <4E3A5EDE.2060208@uni-passau.de> <4E3A6C09.8010505@kit.edu>
In-Reply-To: <4E3A6C09.8010505@kit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward
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: Thu, 04 Aug 2011 18:00:22 -0000

Hi, all,

AFAICT:

a tunnel is a way to virtualize a network path at one level (the 
substrate - physical or itself virtual) as a single hop at the virtual level

tunnels may be pt-pt or multipoint; L3 tunnels emulate L2 subnets in a sense

However, a VPN is something different; it's a network that is not 
accessible except via an additional tunnel. The core of a VPN need not 
be virtualized; only the link to a single user or to another VPN is virtual.

That's my view of the difference.

Joe (as an individual contributor)



From roland.bless@kit.edu  Thu Aug  4 14:06:21 2011
Return-Path: <roland.bless@kit.edu>
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 8120311E8090 for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 14:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.029
X-Spam-Level: 
X-Spam-Status: No, score=-6.029 tagged_above=-999 required=5 tests=[AWL=0.220,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 H6D-JA5PZV-i for <vnrg@ietfa.amsl.com>; Thu,  4 Aug 2011 14:06:21 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id AC3C011E8077 for <vnrg@irtf.org>; Thu,  4 Aug 2011 14:06:20 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1Qp57c-0004ou-2i; Thu, 04 Aug 2011 23:06:33 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 44CE5A80025; Thu,  4 Aug 2011 23:06:27 +0200 (CEST)
Message-ID: <4E3B09D2.70202@kit.edu>
Date: Thu, 04 Aug 2011 23:06:26 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu> <EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E39A744.8010508@kit.edu> <EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E3A59FE.1090809@kit.edu> <EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
In-Reply-To: <EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1312491993.840208000
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Thu, 04 Aug 2011 21:06:21 -0000

Hi Dimitri and all,

On 04.08.2011 12:28, Papadimitriou, Dimitri (Dimitri) wrote:
> Trying to summarize the discussion:

> o) VNRG, even if dealing virtual network, does not mandate VN
> provided exclusively by networking infrastructure providers. Part of
> the problem comes from the definition initially proposed which refers
> to Infrastructure Provider whereas one should speak about a Physical
> Resource Host (or a term that doesn't implicitly assign VN roles from
> the roles inherited by current physical networks).

To me "Infrastructure Provider" is a broad term not necessarily
narrowing down to solely a meaning of "_Network_ Infrastructure
Provider". That is, an InP may provide many different types of substrate
resources, e.g., network nodes, links, servers, hosts, storage, etc.
Would that be ok for you?

> o) Next we should not restrict physical resources to networking nodes
> / links but also incorporate storage and processing resources (a.k.a
> IT resources). Thus, instead of restricting a virtual resource of
> type X to be hosted on physical resources of type X, the definitions
> should allow for a virtual resource of type X to be hosted on a
> physical resource of type Y.

Agreed as already discussed.

> o) Moreover, we have to better distinguish the type of resource from
> their function/role. In the initial definition, there is a 1:1
> relationship (because a physical networking node can only host
> virtual nodes e.g. virtual routers), whereas in the example provided
> in the previous e-mail (case of emulation of virtual resources),
> there is a 1:N relationship (IT resources can emulate a set of
> routers).

Yes.

> o) Finally, the partition of the physical resources on which the VN
> relies should not determine the delimitation of that VN. Whatever the
> criteria of demarcation between physical resources being
> administrative, ownership, etc. as long as we don't find an
> architecturally constraining reason these different levels of
> demarcation should be left independent.

Agreed, I think in my earlier example it was pretty clear that the VN
spanned multiple InP domains, which is a nice aspect of this virtual
abstraction, i.e., you don't have to care about the InP boundaries.

Regards,
 Roland

From hannu.flinck@nsn.com  Fri Aug  5 00:03:17 2011
Return-Path: <hannu.flinck@nsn.com>
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 8B1F921F8892 for <vnrg@ietfa.amsl.com>; Fri,  5 Aug 2011 00:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Z+tZZAbwiUb5 for <vnrg@ietfa.amsl.com>; Fri,  5 Aug 2011 00:03:17 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id CC06C21F8891 for <vnrg@irtf.org>; Fri,  5 Aug 2011 00:03:15 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p7573Uex023729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <vnrg@irtf.org>; Fri, 5 Aug 2011 09:03:30 +0200
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p7573RMi006069 for <vnrg@irtf.org>; Fri, 5 Aug 2011 09:03:30 +0200
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 5 Aug 2011 09:03:24 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 5 Aug 2011 10:03:23 +0300
Message-ID: <26E5D1C5D5365D47B147E5E62FC73585036D307A@FIESEXC035.nsn-intra.net>
In-Reply-To: <4E3B09D2.70202@kit.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxS6moEGqpSf002SpmYAzH5+wX4zAAUd4RA
References: <4E3936FF.1090006@kit.edu><EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E39A744.8010508@kit.edu><EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E3A59FE.1090809@kit.edu><EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E3B09D2.70202@kit.edu>
From: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
To: <vnrg@irtf.org>
X-OriginalArrivalTime: 05 Aug 2011 07:03:24.0571 (UTC) FILETIME=[C4BCA6B0:01CC533D]
Subject: Re: [vnrg] Some definitions and way forward
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: Fri, 05 Aug 2011 07:03:17 -0000

Roland and Dimitri

I agree that the definition of Infrastructure Provider is problematic. I
do not think that stating "... an InP may provide many different types
of substrate
resources, e.g., network nodes, links, servers, hosts, storage, etc."
captures the issue yet.

Virtual networks and physical networks (substrate) can be mixed and
matched. A MVNO can have most of its infra as "virtual" but some parts
can be very physical (substrate), say by having its own base stations in
some key areas. Same applies to many enterprise network where parts of
the resources are virtualized and externalized and some are under the
control of the enterprise itself. Such an entity would be both InP and
VNP at the same time. Do we really need to have define InP and VNP at
all as these terms do not add clarity but confusion?=20

Best regards
Hannu=20

-----Original Message-----
From: vnrg-bounces@irtf.org [mailto:vnrg-bounces@irtf.org] On Behalf Of
ext Roland Bless
Sent: Friday, August 05, 2011 12:06 AM
To: Papadimitriou,Dimitri (Dimitri)
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward

Hi Dimitri and all,

On 04.08.2011 12:28, Papadimitriou, Dimitri (Dimitri) wrote:
> Trying to summarize the discussion:

> o) VNRG, even if dealing virtual network, does not mandate VN
> provided exclusively by networking infrastructure providers. Part of
> the problem comes from the definition initially proposed which refers
> to Infrastructure Provider whereas one should speak about a Physical
> Resource Host (or a term that doesn't implicitly assign VN roles from
> the roles inherited by current physical networks).

To me "Infrastructure Provider" is a broad term not necessarily
narrowing down to solely a meaning of "_Network_ Infrastructure
Provider". That is, an InP may provide many different types of substrate
resources, e.g., network nodes, links, servers, hosts, storage, etc.
Would that be ok for you?


From roland.bless@kit.edu  Fri Aug  5 01:12:11 2011
Return-Path: <roland.bless@kit.edu>
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 9ED9021F8BCD for <vnrg@ietfa.amsl.com>; Fri,  5 Aug 2011 01:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.039
X-Spam-Level: 
X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=0.210,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 51bNiNMUKffw for <vnrg@ietfa.amsl.com>; Fri,  5 Aug 2011 01:12:10 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 917C021F8BB0 for <vnrg@irtf.org>; Fri,  5 Aug 2011 01:12:10 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1QpFVy-0008HV-7z; Fri, 05 Aug 2011 10:12:23 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 2685EA80118; Fri,  5 Aug 2011 10:12:16 +0200 (CEST)
Message-ID: <4E3BA5DE.6010204@kit.edu>
Date: Fri, 05 Aug 2011 10:12:14 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
References: <4E3936FF.1090006@kit.edu><EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E39A744.8010508@kit.edu><EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E3A59FE.1090809@kit.edu><EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>	<4E3B09D2.70202@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D307A@FIESEXC035.nsn-intra.net>
In-Reply-To: <26E5D1C5D5365D47B147E5E62FC73585036D307A@FIESEXC035.nsn-intra.net>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1312531944.013566000
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward
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: Fri, 05 Aug 2011 08:12:11 -0000

Hi Hannu,

On 05.08.2011 09:03, Flinck, Hannu (NSN - FI/Espoo) wrote:
> I agree that the definition of Infrastructure Provider is problematic. I
> do not think that stating "... an InP may provide many different types
> of substrate
> resources, e.g., network nodes, links, servers, hosts, storage, etc."
> captures the issue yet.

I don't know what particular problem you mean by "the issue".
It is a fact that virtual resources have to be hosted somewhere
down in the substrate. The substrate is controlled by some entity
(the InP) who also has control over the virtual resources, e.g., an
InP can migrate VMs between substrate nodes or increase/reduce the
capacity of virtual resources etc. A VNO performs also control over
the virtual resource but at a different level and not in the same manner
as an InP. How can we describe such scenarios without defining the
entities/roles who are entitled to perform such control/access?
It's pretty normal that a VNet can be composed of virtual (and physical)
resources hosted at different InPs, so considering the role
of an InP does not impose any restrictions on the VNet realization.

> Virtual networks and physical networks (substrate) can be mixed and
> matched. A MVNO can have most of its infra as "virtual" but some parts

Fully agreed.

> can be very physical (substrate), say by having its own base stations in
> some key areas. Same applies to many enterprise network where parts of
> the resources are virtualized and externalized and some are under the
> control of the enterprise itself. Such an entity would be both InP and
> VNP at the same time. Do we really need to have define InP and VNP at
> all as these terms do not add clarity but confusion? 

I don't see a problem if such entity is performing both roles at the
same time. It makes pretty clear that another InP controls the _virtual_
resources, i.e., the enterprise also depends on this InP, who may be
responsible in case of problems with the virtual resources. The
enterprise needs also some control access to the virtual resources,
no matter where they are actually hosted in the substrate...
Virtual resources are not just hanging in the air, they are realized
on top of virtual or physical substrate resources. As soon as you are
considering control plane issues, different roles matter a lot.

Regards,
 Roland

From hannu.flinck@nsn.com  Fri Aug  5 01:31:41 2011
Return-Path: <hannu.flinck@nsn.com>
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 7B14B21F8B9E for <vnrg@ietfa.amsl.com>; Fri,  5 Aug 2011 01:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 cNU6KyvnfkPy for <vnrg@ietfa.amsl.com>; Fri,  5 Aug 2011 01:31:41 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0FB21F8B98 for <vnrg@irtf.org>; Fri,  5 Aug 2011 01:31:40 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p758VsJv022470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Aug 2011 10:31:54 +0200
Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p758Vpuw026825; Fri, 5 Aug 2011 10:31:54 +0200
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 5 Aug 2011 10:31:42 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 5 Aug 2011 11:31:40 +0300
Message-ID: <26E5D1C5D5365D47B147E5E62FC73585036D31C7@FIESEXC035.nsn-intra.net>
In-Reply-To: <4E3BA5DE.6010204@kit.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxTR2phlY2WpnW7QqWzew++Iwb4XwAAarKw
References: <4E3936FF.1090006@kit.edu><EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E39A744.8010508@kit.edu><EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E3A59FE.1090809@kit.edu><EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>	<4E3B09D2.70202@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D307A@FIESEXC035.nsn-intra.net> <4E3BA5DE.6010204@kit.edu>
From: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
To: "ext Roland Bless" <roland.bless@kit.edu>
X-OriginalArrivalTime: 05 Aug 2011 08:31:42.0987 (UTC) FILETIME=[1AD6C5B0:01CC534A]
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward
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: Fri, 05 Aug 2011 08:31:41 -0000

The "issue" is the definition of the terms you have been discussing on
this mailing list and particularly the first point in Dimitri's mail
dated (04.08.2011 12:28,) summarizing the discussion. It was also quoted
in my mail.

Can you please elaborate what do you mean by "As soon as you
areconsidering control plane issues, different roles matter a lot." For
me the InP and VNP doesn't seem to be that useful other than explaining
a certain, somewhat limited business model.

  =20
Regards
Hannu

-----Original Message-----
From: ext Roland Bless [mailto:roland.bless@kit.edu]=20
Sent: Friday, August 05, 2011 11:12 AM
To: Flinck, Hannu (NSN - FI/Espoo)
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward

Hi Hannu,

On 05.08.2011 09:03, Flinck, Hannu (NSN - FI/Espoo) wrote:
> I agree that the definition of Infrastructure Provider is problematic.
I
> do not think that stating "... an InP may provide many different types
> of substrate
> resources, e.g., network nodes, links, servers, hosts, storage, etc."
> captures the issue yet.

I don't know what particular problem you mean by "the issue".
It is a fact that virtual resources have to be hosted somewhere
down in the substrate. The substrate is controlled by some entity
(the InP) who also has control over the virtual resources, e.g., an
InP can migrate VMs between substrate nodes or increase/reduce the
capacity of virtual resources etc. A VNO performs also control over
the virtual resource but at a different level and not in the same manner
as an InP. How can we describe such scenarios without defining the
entities/roles who are entitled to perform such control/access?
It's pretty normal that a VNet can be composed of virtual (and physical)
resources hosted at different InPs, so considering the role
of an InP does not impose any restrictions on the VNet realization.

> Virtual networks and physical networks (substrate) can be mixed and
> matched. A MVNO can have most of its infra as "virtual" but some parts

Fully agreed.

> can be very physical (substrate), say by having its own base stations
in
> some key areas. Same applies to many enterprise network where parts of
> the resources are virtualized and externalized and some are under the
> control of the enterprise itself. Such an entity would be both InP and
> VNP at the same time. Do we really need to have define InP and VNP at
> all as these terms do not add clarity but confusion?=20

I don't see a problem if such entity is performing both roles at the
same time. It makes pretty clear that another InP controls the _virtual_
resources, i.e., the enterprise also depends on this InP, who may be
responsible in case of problems with the virtual resources. The
enterprise needs also some control access to the virtual resources,
no matter where they are actually hosted in the substrate...
Virtual resources are not just hanging in the air, they are realized
on top of virtual or physical substrate resources. As soon as you are
considering control plane issues, different roles matter a lot.

Regards,
 Roland

From roland.bless@kit.edu  Fri Aug  5 04:04:34 2011
Return-Path: <roland.bless@kit.edu>
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 0ECE821F8B76 for <vnrg@ietfa.amsl.com>; Fri,  5 Aug 2011 04:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.048
X-Spam-Level: 
X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=0.201,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 Z4Lf-t0jEUNG for <vnrg@ietfa.amsl.com>; Fri,  5 Aug 2011 04:04:33 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4354E21F8B54 for <vnrg@irtf.org>; Fri,  5 Aug 2011 04:04:32 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1QpICo-0001Aw-KS; Fri, 05 Aug 2011 13:04:47 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id A00A5A80067; Fri,  5 Aug 2011 13:04:41 +0200 (CEST)
Message-ID: <4E3BCE47.2000805@kit.edu>
Date: Fri, 05 Aug 2011 13:04:39 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
References: <4E3936FF.1090006@kit.edu><EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E39A744.8010508@kit.edu><EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E3A59FE.1090809@kit.edu><EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>	<4E3B09D2.70202@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D307A@FIESEXC035.nsn-intra.net> <4E3BA5DE.6010204@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D31C7@FIESEXC035.nsn-intra.net>
In-Reply-To: <26E5D1C5D5365D47B147E5E62FC73585036D31C7@FIESEXC035.nsn-intra.net>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1312542287.914099000
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward
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: Fri, 05 Aug 2011 11:04:34 -0000

Hi Hannu,

On 05.08.2011 10:31, Flinck, Hannu (NSN - FI/Espoo) wrote:
> Can you please elaborate what do you mean by "As soon as you
> areconsidering control plane issues, different roles matter a lot." For
> me the InP and VNP doesn't seem to be that useful other than explaining
> a certain, somewhat limited business model.

As already mentioned, it's really not about discussing a business
model, but about controlling virtual and real resources. In order to
do that you need different control interfaces for the various
stakeholders. Let's assume you (as VNO) need to reboot your virtual
router, because it crashed. Then your InP needs to provide access to the
virtual router in order to do that, no matter where it is currently
hosted in the substrate, but probably without exposing the current
mapping of virtual to substrate resources.
As InP you have the mapping information and can easily do this, maybe
using a different control interface. If you have a VNet spanning several
InP domains, you even need to find out first at which InP the virtual
router is currently hosted. This has implications for addressing
virtual resources in the control plane and so on. These are important
control plane aspects, not business model aspects.

Regards,
 Roland

From dimitri.papadimitriou@alcatel-lucent.com  Sat Aug  6 04:43:53 2011
Return-Path: <dimitri.papadimitriou@alcatel-lucent.com>
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 2CBF421F8663 for <vnrg@ietfa.amsl.com>; Sat,  6 Aug 2011 04:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.582
X-Spam-Level: 
X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=0.667,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 uZiUGFsCy-YL for <vnrg@ietfa.amsl.com>; Sat,  6 Aug 2011 04:43:52 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 695EF21F863C for <vnrg@irtf.org>; Sat,  6 Aug 2011 04:43:52 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p76Bi7wY005161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 6 Aug 2011 13:44:07 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 6 Aug 2011 13:44:08 +0200
From: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
To: Roland Bless <roland.bless@kit.edu>, "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
Date: Sat, 6 Aug 2011 13:44:06 +0200
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxTX4ZbNkryoinLQU+84QfmEw7m1wAUt4EQ
Message-ID: <EFDB2B5417263843B5077E12666D8C1018FD2A4C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu><EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E39A744.8010508@kit.edu><EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E3A59FE.1090809@kit.edu><EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E3B09D2.70202@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D307A@FIESEXC035.nsn-intra.net> <4E3BA5DE.6010204@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D31C7@FIESEXC035.nsn-intra.net> <4E3BCE47.2000805@kit.edu>
In-Reply-To: <4E3BCE47.2000805@kit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Sat, 06 Aug 2011 11:43:53 -0000

=20
Hi,

> On 05.08.2011 10:31, Flinck, Hannu (NSN - FI/Espoo) wrote:
> > Can you please elaborate what do you mean by "As soon as you
> > areconsidering control plane issues, different roles matter=20
> a lot." For
> > me the InP and VNP doesn't seem to be that useful other=20
> than explaining
> > a certain, somewhat limited business model.
>=20
> As already mentioned, it's really not about discussing a business
> model, but about controlling virtual and real resources. In order to
> do that you need different control interfaces for the various
> stakeholders. Let's assume you (as VNO) need to reboot your virtual
> router, because it crashed. Then your InP needs to provide=20
> access to the virtual router in order to do that,=20

The problem is not the inclusion of "control functionality" into the archit=
ectural related definitions but the assignment and distribution of control =
roles to stakeholders as part of these definitions (cf. VNO, VNP, InP, etc.=
). At this stage, it is important to define WHAT is to be controlled and no=
t WHO controls what (and the term, e.g., Provider is basically defining the=
 WHO).=20

Using my previous example it means that VN, VR* and R* entities have of cou=
rse associated control function but I didn't indicate who is associated/in =
charge of controlling the VN, VR*, and R* since it this is not part of the =
an architectural scope of the definitions we're currently working on.=20

Thanks,
-dimitri.

> no matter where it is currently
> hosted in the substrate, but probably without exposing the current
> mapping of virtual to substrate resources.
> As InP you have the mapping information and can easily do this, maybe
> using a different control interface. If you have a VNet=20
> spanning several
> InP domains, you even need to find out first at which InP the virtual
> router is currently hosted. This has implications for addressing
> virtual resources in the control plane and so on. These are important
> control plane aspects, not business model aspects.
>=20
> Regards,
>  Roland
> _______________________________________________
> vnrg mailing list
> vnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/vnrg
> =

From hannu.flinck@nsn.com  Sat Aug  6 07:03:56 2011
Return-Path: <hannu.flinck@nsn.com>
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 53DD421F8754 for <vnrg@ietfa.amsl.com>; Sat,  6 Aug 2011 07:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Ict9QEHhKWZr for <vnrg@ietfa.amsl.com>; Sat,  6 Aug 2011 07:03:55 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5C21F874C for <vnrg@irtf.org>; Sat,  6 Aug 2011 07:03:54 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p76E48l0003973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Aug 2011 16:04:08 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p76E474l025039; Sat, 6 Aug 2011 16:04:08 +0200
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 6 Aug 2011 16:04:07 +0200
Received: from 10.150.128.35 ([10.150.128.35]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ;  Sat,  6 Aug 2011 14:04:06 +0000
From: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
To: "ext Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>,  "Roland Bless" <roland.bless@kit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Date: Sat,  6 Aug 2011 17:02:45 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxTX4ZbNkryoinLQU+84QfmEw7m1wAUt4EQACPT8yE=
Message-ID: <08df01cc5441$b42c4877$2380960a@nsnintra.net>
X-Mailer: EAS Version 1.00
MIME-Version: 1.0
Content-Language: i-default
X-OriginalArrivalTime: 06 Aug 2011 14:04:07.0337 (UTC) FILETIME=[B502D190:01CC5441]
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward
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: Sat, 06 Aug 2011 14:03:56 -0000

Exactly.

Hannu

--- original message ---
From: "ext Papadimitriou, Dimitri (Dimitri)" =
<dimitri.papadimitriou@alcatel-lucent.com>
Subject: RE: [vnrg] Some definitions and way forward
Date: 6th August 2011
Time: 2:44:23 pm

=20
Hi,

> On 05.08.2011 10:31, Flinck, Hannu (NSN - FI/Espoo) wrote:
> > Can you please elaborate what do you mean by "As soon as you
> > areconsidering control plane issues, different roles matter=20
> a lot." For
> > me the InP and VNP doesn't seem to be that useful other=20
> than explaining
> > a certain, somewhat limited business model.
>=20
> As already mentioned, it's really not about discussing a business
> model, but about controlling virtual and real resources. In order to
> do that you need different control interfaces for the various
> stakeholders. Let's assume you (as VNO) need to reboot your virtual
> router, because it crashed. Then your InP needs to provide=20
> access to the virtual router in order to do that,=20

The problem is not the inclusion of "control functionality" into the =
architectural related definitions but the assignment and distribution of =
control roles to stakeholders as part of these definitions (cf. VNO, =
VNP, InP, etc.). At this stage, it is important to define WHAT is to be =
controlled and not WHO controls what (and the term, e.g., Provider is =
basically defining the WHO).=20

Using my previous example it means that VN, VR* and R* entities have of =
course associated control function but I didn't indicate who is =
associated/in charge of controlling the VN, VR*, and R* since it this is =
not part of the an architectural scope of the definitions we're =
currently working on.=20

Thanks,
-dimitri.

> no matter where it is currently
> hosted in the substrate, but probably without exposing the current
> mapping of virtual to substrate resources.
> As InP you have the mapping information and can easily do this, maybe
> using a different control interface. If you have a VNet=20
> spanning several
> InP domains, you even need to find out first at which InP the virtual
> router is currently hosted. This has implications for addressing
> virtual resources in the control plane and so on. These are important
> control plane aspects, not business model aspects.
>=20
> Regards,
>  Roland
> _______________________________________________
> vnrg mailing list
> vnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/vnrg
>=20

From dimitri.papadimitriou@alcatel-lucent.com  Wed Aug  3 09:09:02 2011
Return-Path: <dimitri.papadimitriou@alcatel-lucent.com>
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 301E821F8B51 for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 09:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.916
X-Spam-Level: 
X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=1.333,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 jc1pbXAUB9Jf for <vnrg@ietfa.amsl.com>; Wed,  3 Aug 2011 09:09:01 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id D24AE21F8B33 for <vnrg@irtf.org>; Wed,  3 Aug 2011 09:09:00 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p73G7GYI032026 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Aug 2011 18:09:12 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 3 Aug 2011 18:09:05 +0200
From: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
To: Roland Bless <roland.bless@kit.edu>, "vnrg@irtf.org" <vnrg@irtf.org>
Date: Wed, 3 Aug 2011 18:07:01 +0200
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxR1DQdXQF84+vwTgmzaENg61zEdQAAVt+g
Message-ID: <EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu>
In-Reply-To: <4E3936FF.1090006@kit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
X-Mailman-Approved-At: Mon, 08 Aug 2011 01:12:06 -0700
Subject: Re: [vnrg] Some definitions and way forward
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: Wed, 03 Aug 2011 16:09:02 -0000

Hi,

These definitions stems from the view that physical resource owner provides=
 virtual resources of the same kind (delimits the type of virtual resources=
 it can deliver). My understanding from the scope given in the Maastricht m=
eeting was:

- virtual resources can be hosted on physical resources of different type i=
.e. virtual nodes/links don't have to be instantiated from physical nodes/l=
inks; for instance, a virtual network can comprise virtual nodes that are b=
ringing together/aggregating resources from multiple physical nodes AND a s=
et of virtual nodes that are emulated on a single physical machine. =20

- virtual resources composing a virtual network can be of different type an=
d thus virtually operate at different layers (thus beyond nodes and links o=
perating at a given layer) including wireless/wireline virtual links with d=
ifferent properties (with or without emulated delay), hosts and intermediat=
e nodes of different kind, e.g., switches, routers, base stations, etc.). T=
his is basically what makes the difference between an "overlay network" and=
 "virtual network". =20

The role definitions here below tend to reproduce (and thus somehow limit) =
the roles we actually know from "physical networks". Taking the above defin=
itions, if the virtual network would be running on physical hosts, "provide=
rs" would not maintain any physical resource of the type indicated here bel=
ow (routers, links, wireless infrastructure, etc.) but only computing resou=
rces on terminals/servers.=20

The role definitions provided here below tend to enforce too a client-serve=
r strict demarcation between resource owner and non-owner merging thus a fu=
nctional and operational role whereas demarcation would be needed between a=
n external entity to the VN (as delimited by the functionality that the VN =
delivers) and a Virtual NAP (whether one owns the underlying resources or n=
ot).

Thanks,
-dimitri.

> -----Original Message-----
> From: vnrg-bounces@irtf.org [mailto:vnrg-bounces@irtf.org] On=20
> Behalf Of Roland Bless
> Sent: Wednesday, August 03, 2011 1:55 PM
> To: vnrg@irtf.org
> Subject: [vnrg] Some definitions and way forward
>=20
> Hi,
>=20
> as already mentioned in the IETF-81 meeting, I committed to
> write up some definitions (mostly results from the 4WARD EU project)
> that may be useful for further discussion of terminology and problem
> statements. I'll leave recursion aspects aside at first since=20
> it usually
> complicates the discussion - but it's often rather straight-forward to
> apply recursion (i.e., consider virtual resources as (virtual)
> substrate) etc.
> Some illustrations of roles and interfaces can be found in
> http://www.ietf.org/proceedings/77/slides/VNRG-3.pdf
>=20
> Virtual Resource:
> A virtual resource appears to a user of that resource
> as if he is the (exclusive) owner of that resource.
>=20
> Substrate:
> This denotes the physical resources that host the virtual
> resources, i.e., each virtual resource is instantiated
> inside one or more physical resources. Substrate resources can
> either be partitioned or aggregated in order to provide a
> virtual resource. From the above definition of a virtual
> resource follows that virtual resources must be
> isolated from each other in the data plane as well as
> in the control plane.
>=20
> Virtual Network:
> A virtual network (VNet) is a set of (virtual) nodes directly
> connected by (virtual) links and realized on top of a
> set of underlying physical resources, the Substrate.
> There should be no assumptions about the particular
> network protocols or architectures running
> inside the VNet, i.e., it is not necessarily IP.
> Virtual nodes can be further distinguished into
> virtual routers and virtual hosts. Virtual routers
> forward packets whereas virtual hosts are sinks
> or sources of packets.
>=20
> Infrastructure Provider:
> The Infrastructure Provider (InP) is responsible for maintaining
> physical networking resources, such as routers, links, wireless
> infrastructure, etc., and enabling the virtualization of these
> resources. The InP also offers a resource control interface for the
> virtualized resources. Through this interface, InPs can make virtual
> resources and partial virtual topologies available to virtual network
> provider, which are the customers of the InP. The InP can usually
> migrate virtual resource between substrate resources so that the
> users of virtual resources are not aware of any change. The actual
> mapping from virtual to substrate resources inside the InPs domains
> is usually only known by the InP. InPs may have to use a common
> interface for setting up virtual links across different InPs.
>=20
> Virtual Network Provider:
> The Virtual Network Provider (VNP) constructs virtual networks using
> virtual resources and partial topologies provided by one or more InPs.
> The VNP needs a resource control interface to request and configure
> these virtual resources offered by the InP who actually owns the
> resource. A newly constructed VNet can be made available to a virtual
> network operator (or to another VNP, who can recursively use
> it to construct an even larger VNet). The VNP performs mainly a broker
> role, providing easier access for VNOs to virtual resources spanning
> multiple InPs.
>=20
> Virtual Network Operator:
> The Virtual Network Operator (VNO) operates, controls, and manages the
> VNet in order to offer services inside the VNet.
> Once the VNet has been constructed by a VNP, the VNO is given
> "Out-of-VNet access" to control the virtual resources, allowing him
> to configure and manage them just like a traditional network operator
> manages physical network resources. This Out-of-VNet access control
> interface is required in order to install, reboot, start,=20
> stop, shutdown
> virtual node etc. from outside the VNet (e.g., if your virtual
> node crashed, you must have some knob to restart/revive it).
> This also requires to get transparent access to the virtual resources
> irrespective of where the resources is currently hosted in the
> substrate as the InP may not expose the current location and migrate
> the virtual resource "freely". The VNO also controls and manages the
> virtual resources from inside the VNet (In-VNet Management).
>=20
> Service Provider:
> A service provider may provide services to end-users by using the
> protocols running inside the virtual network. Consider an IP-TV
> provider who delivers IP-TV inside the VNet to his customers.
> In order to accomplish this, the Service Provider may want to employ
> IP multicast for efficient distribution of the streams inside=20
> the VNet.
> So the VNO may run PIM-DM/SM protocols inside the VNet as required by
> the service provider.
>=20
> We note that some of the roles can actually overlap, e.g.,
> VNP and VNO, InP/VNP/VNO and service provider etc.
>=20
> End-users:
> End-users attach to the virtual network and use the communication
> services provided by/within the virtual network, i.e., they run a
> virtual node that implements the suitable protocol stack.
> End-users have usually access to some substrate network and need to
> get to a virtual access node via a viable substrate path. This process
> of transitioning the real world into the virtual world/net is called
> "end-user attachment" and the substrate path can be=20
> considered as being
> a so-called "virtual last mile link". A typical method to accomplish
> this is to create a tunnel across the substrate between the end-user's
> device and the VNet access node. Problems that need to be solved here
> are for example: how can an end-user find the right virtual=20
> access node
> for a particular VNet across the substrate? How can mobility and
> multi-homing in the substrate be considered, e.g., the=20
> virtual link stays
> connected. How to consider multi-homing and mobility in the=20
> VNet, i.e.,
> being attached to multiple VNet access nodes simultaneously or moving
> between them?
>=20
> More detailed text on the scenario and control interfaces
> can be found here (open access):
> http://journal.ub.tu-berlin.de/eceasst/article/download/225/216
>=20
> I would propose that we try to create an RG draft that defines
> some basic terminology, captures the content of some recent
> RG discussions on some related aspects as virtual vs. logical,
> layering vs. virtualization, important properties, "acid tests",
> and so on and then describes some of the
> problems that the RG feels need to be solved. In a next step
> we may pick some of the problems and work on them (probably in
> parallel).
>=20
> Regards,
>  Roland
>=20
> _______________________________________________
> vnrg mailing list
> vnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/vnrg
> =

From roland.bless@kit.edu  Thu Aug 11 07:51:10 2011
Return-Path: <roland.bless@kit.edu>
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 D3F3821F8AFC for <vnrg@ietfa.amsl.com>; Thu, 11 Aug 2011 07:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.056
X-Spam-Level: 
X-Spam-Status: No, score=-6.056 tagged_above=-999 required=5 tests=[AWL=0.193,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoF8VQpZho9I for <vnrg@ietfa.amsl.com>; Thu, 11 Aug 2011 07:51:10 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 18A0F21F8AEA for <vnrg@irtf.org>; Thu, 11 Aug 2011 07:51:06 -0700 (PDT)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25  id 1QrWba-00052b-Un; Thu, 11 Aug 2011 16:51:36 +0200
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25  id 1QrWba-0006di-QI; Thu, 11 Aug 2011 16:51:30 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 59D19A804C7; Thu, 11 Aug 2011 16:51:30 +0200 (CEST)
Message-ID: <4E43EC71.9030403@kit.edu>
Date: Thu, 11 Aug 2011 16:51:29 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu><EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E39A744.8010508@kit.edu><EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E3A59FE.1090809@kit.edu><EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>	<4E3B09D2.70202@kit.edu>	<26E5D1C5D5365D47B147E5E62FC73585036D307A@FIESEXC035.nsn-intra.net>	<4E3BA5DE.6010204@kit.edu>	<26E5D1C5D5365D47B147E5E62FC73585036D31C7@FIESEXC035.nsn-intra.net> <4E3BCE47.2000805@kit.edu> <EFDB2B5417263843B5077E12666D8C1018FD2A4C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
In-Reply-To: <EFDB2B5417263843B5077E12666D8C1018FD2A4C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1313074296.206639000
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
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: Thu, 11 Aug 2011 14:51:10 -0000

Hi Dimitri,

sorry for the late reply, but I was traveling...

> The problem is not the inclusion of "control functionality" into the
> architectural related definitions but the assignment and distribution of
> control roles to stakeholders as part of these definitions (cf. VNO,
> VNP, InP, etc.). At this stage, it is important to define WHAT is to be
> controlled and not WHO controls what (and the term, e.g., Provider is
> basically defining the WHO).

Ok, so far agreed, but IMHO it's difficult to come up with control
interfaces if you are not considering the controlling entity/party,
i.e., the user of this control interface.
Maybe I'll try a second round of definitions without these roles.

Regards,
 Roland

From Martin.Stiemerling@neclab.eu  Tue Aug 23 06:30:43 2011
Return-Path: <Martin.Stiemerling@neclab.eu>
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 2F49521F85AA for <vnrg@ietfa.amsl.com>; Tue, 23 Aug 2011 06:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.077
X-Spam-Level: 
X-Spam-Status: No, score=-102.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXDyBY0BVHuT for <vnrg@ietfa.amsl.com>; Tue, 23 Aug 2011 06:30:42 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9EC21F854C for <vnrg@irtf.org>; Tue, 23 Aug 2011 06:30:39 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 870952800031D for <vnrg@irtf.org>; Tue, 23 Aug 2011 15:31:46 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoAzGLBqChuG for <vnrg@irtf.org>; Tue, 23 Aug 2011 15:31:46 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 6CADF2800018F for <vnrg@irtf.org>; Tue, 23 Aug 2011 15:31:41 +0200 (CEST)
Received: from Polydeuces.office.hd ([169.254.3.194]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Tue, 23 Aug 2011 15:31:41 +0200
From: Martin Stiemerling <Martin.Stiemerling@neclab.eu>
To: "vnrg@irtf.org" <vnrg@irtf.org>
Thread-Topic: IETF#81draft meeting minutes 
Thread-Index: AcxhmOZR3XtMI2CVRGiTkVY/X7PN/Q==
Date: Tue, 23 Aug 2011 13:31:40 +0000
Message-ID: <E84E7B8FF3F2314DA16E48EC89AB49F01CF6ACB2@Polydeuces.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.1.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [vnrg] IETF#81draft meeting minutes
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, 23 Aug 2011 13:30:43 -0000

Hi all,

Please find the draft meeting minutes of our VNRG session at the 81st IETF =
meeting here:
http://www.ietf.org/proceedings/81/minutes/VNRG.txt

Let me know any change request ASAP.

Thanks to Roland Bless for taking the notes.

  Martin

martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re=
gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in =
England 2832014=20