Subject: Re: [nvrg-bof] Updated charter proposal
From: Roland Bless <[email-masked]>
To: Martin Stiemerling <[email-masked]>
Cc: [email-masked]
Date: Wed, 17 Jun 2009 09:20:55 +0200
List-Id: Discussion list for the proposal of a Network Virtualization RG <nvrg.listserv.gwdg.de>

Hi Martin and all,

as promised, some more feedback[, though later than planned, sorry.]
I'll not comment on the nits here.

Martin Stiemerling wrote:
> The group will address the following research challenges:
> - Consider a whole system for virtualized networks and not only single
>   components or a limited set of components;
> - Identifying architectural challenges resulting from virtual networks;  
> - Recursive network management of virtual networks;
> - Emerging technological and implementation issues.

As James and Joe already mentioned, I think that it would
be a good starting point to first
- identify the virtual network resources that need to be controlled
  and managed, derive some requirements for them
- work on a network virtualization framework (identifying the different
  roles/actors and their interaction).
- identify control interfaces as well as
  requirements for interoperability, especially in the background of
  creating and running virtual networks across provider domains.

Regards,
 Roland

Date: Thu, 11 Jun 2009 15:39:54 +0200
From: Martin Stiemerling <[email-masked]>
To: [email-masked]
Subject: [nvrg-bof] Currently offline

Hi folks,

Sorry for being so silent about the nvrg list and especially the charter 
discussion, but I'm currently away from work for private reasons and 
will hopefully return on June 15th.

  Martin

From: Mosharaf Chowdhury <[email-masked]>
Date: Thu, 11 Jun 2009 14:44:44 +0600
To: Joe Touch <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>, "Prof. Raouf Boutaba" <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

--000325574962af07b6046c0e9b6a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Thanks Joe for providing the authoritative info on XBone.. We are trying to
update the ComMag article with the XBone info before it goes to the press..
But I will certainly update the preprint(s) on my website.

Btw, I would say that the ComMag one is basically an extended abstract of
the survey with the primary objective of gaining more attention to the
network virtualization movement.

Any how, as I mentioned before, we (http://netlab.cs.uwaterloo.ca/virtual) were
and still are looking forward to comments/inputs from everyone, and we would
like to take part in / lead! efforts regarding
standardizing/structuring/creating an altogether new RFC/charter or updating
the existing techreport with necessary changes (if minimal) through mutual
discussions in the community.

Mosharaf

--
Mosharaf K Chowdhury
http://www.mosharaf.com

On Thu, Jun 11, 2009 at 2:15 AM, Joe Touch <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> PS - two updates to that note below:
>
> 1) a more recent version is appearing in IEEE Communications in July 2009
>
> 2) both versions still have a few bugs
>
> a) PlanetLab is not an overlay (there are no virtual links, interfaces,
> or addresses) (it should not appear in Table 1 either)
>
> b) Table 1 incorrectly lists X-Bone as application-layer, whereas it is
> network layer.
>
> c) the appropriate reference for the X-Bone should have been:
> Dynamic Internet Overlay Deployment and Management Using the X-Bone. Joe
> Touch. Computer Networks, July 2001, pp. 117-135
>
> Joe
>
>
> Joe Touch wrote:
> >
> > Joe Touch wrote:
> > ...
> >>> Also, I'd propose to (4) have some state of the art document that
> >>> overviews current solutions to a wide range of techniques for
> >>> virtualizing network resources.
> >> There was a paper I saw a draft of fairly recently that did a good job
> >> of this. I'll see if I can get the authors involved in the WG or see if
> >> they want to offer their info as input to a draft.
> >
> > OK, so it only took me a few hours to figure out that this doc was
> > actually posted on this list back in October (yikes!).
> >
> > See attached. I wonder if we actually need an RFC if there's already a
> > sufficient tech report in this space? If we do, then I would nominate
> > Mosharaf to lead the effort (if of interest) ;-)
> >
> > Joe
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > Subject:
> > Re: [nvrg-bof] Further steps
> > From:
> > "Mosharaf Chowdhury" <[email-masked]>
> > Date:
> > Thu, 16 Oct 2008 14:28:56 -0400
> > To:
> > "Martin Stiemerling" <[email-masked]>
> >
> > To:
> > "Martin Stiemerling" <[email-masked]>
> > CC:
> > [email-masked]
> >
> >
> > Hi Martin,
> >
> > I believe you would be interested in the survey we have put together
> > recently. You can find the technical report here:
> > http://www.cs.uwaterloo.ca/research/tr/2008/CS-2008-25.pdf. Any comment,
> > critique will be very much appreciated.
> >
> > And I'd be glad to contribute in the compilation of a formal problem
> > statement for NVRG.
> >
> > Btw, I was wondering whether there is anything formally named IRTF NVRG
> > (administratively speaking) ?
> >
> > -Mosharaf
> >
> > On Mon, Oct 13, 2008 at 3:48 PM, Martin Stiemerling
> > <[email-masked]> wrote:
> >
> >     Dear all,
> >
> >     Some words on what are the next steps IMO:
> >
> >     - I'm about to compile a problem statement for Network
> >     Virtualization Research Group. This draft should be a write-up
> >     containing some clarification of terminology and a sketch of the
> >     problem space the NVRG would tackle.
> >     - Planning a new meeting at the upcoming IETF meeting in
> >     Minneapolis, if people are interested to join. Some information
> >     about the upcoming IETF meeting: http://www.ietf.org/meetings/73/
> >
> >     Let me know if you're interest in contributing.
> >
> >      Martin
> >
> >     [email-masked]
> >
> >     NEC Laboratories Europe - Network Research Division
> >     NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> >     London W3 6BL | Registered in England 2832014
> >
> >
> >
> >
> > --
> > Mosharaf K Chowdhury
> > Cheriton School of Computer Science
> > University of Waterloo
> > http://www.mosharaf.com/
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkowFFAACgkQE5f5cImnZruwyACg5D06oyTVDXLQz4vtIAEOqg7A
> N7EAoPSdrWbUDnNgn1m61lw4hz/nNllF
> =CePZ
> -----END PGP SIGNATURE-----
>

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

<div>Thanks Joe for providing the authoritative info on XBone.. We are tryi=
ng to update the ComMag article with the XBone info before it goes to the p=
ress.. But I will certainly update the preprint(s) on my website.=A0</div>

<div><br></div><div>Btw, I would say that the ComMag one is basically an ex=
tended abstract of the survey with the primary objective of gaining more at=
tention to the network virtualization movement.</div><div><br></div><div>

Any how, as I mentioned before, we=A0(<a href=3D"http://netlab.cs.uwaterloo=
.ca/virtual">http://netlab.cs.uwaterloo.ca/virtual</a>)=A0were and still ar=
e looking forward to comments/inputs from everyone, and we would like to ta=
ke part in / lead! efforts regarding standardizing/structuring/creating an =
altogether new RFC/charter or updating the existing techreport with necessa=
ry changes (if minimal) through mutual discussions in the community.</div>

<div><br></div><div>Mosharaf</div><div><br></div><div>--</div><div>Mosharaf=
 K Chowdhury</div><div><a href=3D"http://www.mosharaf.com">http://www.mosha=
raf.com</a></div><br>
<br><br><div class=3D"gmail_quote">On Thu, Jun 11, 2009 at 2:15 AM, Joe Tou=
ch <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</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">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>PS - two updates to that note below:<br>
<br>
1) a more recent version is appearing in IEEE Communications in July 2009<b=
r>
<br>
2) both versions still have a few bugs<br>
<br>
a) PlanetLab is not an overlay (there are no virtual links, interfaces,<br>
or addresses) (it should not appear in Table 1 either)<br>
<br>
b) Table 1 incorrectly lists X-Bone as application-layer, whereas it is<br>
network layer.<br>
<br>
c) the appropriate reference for the X-Bone should have been:<br>
Dynamic Internet Overlay Deployment and Management Using the X-Bone. Joe<br=
>
Touch. Computer Networks, July 2001, pp. 117-135<br>
<br>
Joe<br>
<div><div></div><div class=3D"h5"><br>
<br>
Joe Touch wrote:<br>
&gt;<br>
&gt; Joe Touch wrote:<br>
&gt; ...<br>
&gt;&gt;&gt; Also, I&#39;d propose to (4) have some state of the art docume=
nt that<br>
&gt;&gt;&gt; overviews current solutions to a wide range of techniques for<=
br>
&gt;&gt;&gt; virtualizing network resources.<br>
&gt;&gt; There was a paper I saw a draft of fairly recently that did a good=
 job<br>
&gt;&gt; of this. I&#39;ll see if I can get the authors involved in the WG =
or see if<br>
&gt;&gt; they want to offer their info as input to a draft.<br>
&gt;<br>
&gt; OK, so it only took me a few hours to figure out that this doc was<br>
&gt; actually posted on this list back in October (yikes!).<br>
&gt;<br>
&gt; See attached. I wonder if we actually need an RFC if there&#39;s alrea=
dy a<br>
&gt; sufficient tech report in this space? If we do, then I would nominate<=
br>
&gt; Mosharaf to lead the effort (if of interest) ;-)<br>
&gt;<br>
&gt; Joe<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; ----------------------------------------------------------=
--------------<br>
&gt;<br>
&gt; Subject:<br>
&gt; Re: [nvrg-bof] Further steps<br>
&gt; From:<br>
&gt; &quot;Mosharaf Chowdhury&quot; &lt;<a href=3D"mailto:mosharafkabir@gma=
il.com">[email-masked]</a>&gt;<br>
&gt; Date:<br>
&gt; Thu, 16 Oct 2008 14:28:56 -0400<br>
&gt; To:<br>
&gt; &quot;Martin Stiemerling&quot; &lt;[email-masked]&gt;<br>
&gt;<br>
&gt; To:<br>
&gt; &quot;Martin Stiemerling&quot; &lt;[email-masked]&gt;<br>
&gt; CC:<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;<br>
&gt;<br>
&gt; Hi Martin,<br>
&gt;<br>
&gt; I believe you would be interested in the survey we have put together<b=
r>
&gt; recently. You can find the technical report here:<br>
&gt; <a href=3D"http://www.cs.uwaterloo.ca/research/tr/2008/CS-2008-25.pdf"=
 target=3D"_blank">http://www.cs.uwaterloo.ca/research/tr/2008/CS-2008-25.p=
df</a>. Any comment,<br>
&gt; critique will be very much appreciated.<br>
&gt;<br>
&gt; And I&#39;d be glad to contribute in the compilation of a formal probl=
em<br>
&gt; statement for NVRG.<br>
&gt;<br>
&gt; Btw, I was wondering whether there is anything formally named IRTF NVR=
G<br>
&gt; (administratively speaking) ?<br>
&gt;<br>
&gt; -Mosharaf<br>
&gt;<br>
&gt; On Mon, Oct 13, 2008 at 3:48 PM, Martin Stiemerling<br>
&gt; &lt;[email-masked]&gt; wrote:<br>
&gt;<br>
&gt; =A0 =A0 Dear all,<br>
&gt;<br>
&gt; =A0 =A0 Some words on what are the next steps IMO:<br>
&gt;<br>
&gt; =A0 =A0 - I&#39;m about to compile a problem statement for Network<br>
&gt; =A0 =A0 Virtualization Research Group. This draft should be a write-up=
<br>
&gt; =A0 =A0 containing some clarification of terminology and a sketch of t=
he<br>
&gt; =A0 =A0 problem space the NVRG would tackle.<br>
&gt; =A0 =A0 - Planning a new meeting at the upcoming IETF meeting in<br>
&gt; =A0 =A0 Minneapolis, if people are interested to join. Some informatio=
n<br>
&gt; =A0 =A0 about the upcoming IETF meeting: <a href=3D"http://www.ietf.or=
g/meetings/73/" target=3D"_blank">http://www.ietf.org/meetings/73/</a><br>
&gt;<br>
&gt; =A0 =A0 Let me know if you&#39;re interest in contributing.<br>
&gt;<br>
&gt; =A0 =A0 =A0Martin<br>
<div class=3D"im">&gt;<br>
&gt; =A0 =A0 [email-masked]<br>
&gt;<br>
&gt; =A0 =A0 NEC Laboratories Europe - Network Research Division<br>
&gt; =A0 =A0 NEC Europe Limited | Registered Office: NEC House, 1 Victoria =
Road,<br>
&gt; =A0 =A0 London W3 6BL | Registered in England 2832014<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
</div>&gt; Mosharaf K Chowdhury<br>
&gt; Cheriton School of Computer Science<br>
&gt; University of Waterloo<br>
&gt; <a href=3D"http://www.mosharaf.com/" target=3D"_blank">http://www.mosh=
araf.com/</a><br>
<div class=3D"im">&gt;<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (MingW32)<br>
Comment: Using GnuPG with Mozilla - <a href=3D"http://enigmail.mozdev.org" =
target=3D"_blank">http://enigmail.mozdev.org</a><br>
<br>
</div>iEYEARECAAYFAkowFFAACgkQE5f5cImnZruwyACg5D06oyTVDXLQz4vtIAEOqg7A<br>
N7EAoPSdrWbUDnNgn1m61lw4hz/nNllF<br>
=3DCePZ<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br>

--000325574962af07b6046c0e9b6a--

Date: Wed, 10 Jun 2009 13:15:12 -0700
From: Joe Touch <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

PS - two updates to that note below:

1) a more recent version is appearing in IEEE Communications in July 2009

2) both versions still have a few bugs

a) PlanetLab is not an overlay (there are no virtual links, interfaces,
or addresses) (it should not appear in Table 1 either)

b) Table 1 incorrectly lists X-Bone as application-layer, whereas it is
network layer.

c) the appropriate reference for the X-Bone should have been:
Dynamic Internet Overlay Deployment and Management Using the X-Bone. Joe
Touch. Computer Networks, July 2001, pp. 117-135

Joe

Joe Touch wrote:
> 
> Joe Touch wrote:
> ...
>>> Also, I'd propose to (4) have some state of the art document that
>>> overviews current solutions to a wide range of techniques for
>>> virtualizing network resources.
>> There was a paper I saw a draft of fairly recently that did a good job
>> of this. I'll see if I can get the authors involved in the WG or see if
>> they want to offer their info as input to a draft.
> 
> OK, so it only took me a few hours to figure out that this doc was
> actually posted on this list back in October (yikes!).
> 
> See attached. I wonder if we actually need an RFC if there's already a
> sufficient tech report in this space? If we do, then I would nominate
> Mosharaf to lead the effort (if of interest) ;-)
> 
> Joe
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [nvrg-bof] Further steps
> From:
> "Mosharaf Chowdhury" <[email-masked]>
> Date:
> Thu, 16 Oct 2008 14:28:56 -0400
> To:
> "Martin Stiemerling" <[email-masked]>
> 
> To:
> "Martin Stiemerling" <[email-masked]>
> CC:
> [email-masked]
> 
> 
> Hi Martin,
> 
> I believe you would be interested in the survey we have put together
> recently. You can find the technical report here:
> http://www.cs.uwaterloo.ca/research/tr/2008/CS-2008-25.pdf. Any comment,
> critique will be very much appreciated.
> 
> And I'd be glad to contribute in the compilation of a formal problem
> statement for NVRG.
> 
> Btw, I was wondering whether there is anything formally named IRTF NVRG
> (administratively speaking) ?
> 
> -Mosharaf
> 
> On Mon, Oct 13, 2008 at 3:48 PM, Martin Stiemerling
> <[email-masked]> wrote:
> 
>     Dear all,
> 
>     Some words on what are the next steps IMO:
> 
>     - I'm about to compile a problem statement for Network
>     Virtualization Research Group. This draft should be a write-up
>     containing some clarification of terminology and a sketch of the
>     problem space the NVRG would tackle.
>     - Planning a new meeting at the upcoming IETF meeting in
>     Minneapolis, if people are interested to join. Some information
>     about the upcoming IETF meeting: http://www.ietf.org/meetings/73/
> 
>     Let me know if you're interest in contributing.
> 
>      Martin
> 
>     [email-masked]
> 
>     NEC Laboratories Europe - Network Research Division
>     NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
>     London W3 6BL | Registered in England 2832014
> 
> 
> 
> 
> -- 
> Mosharaf K Chowdhury
> Cheriton School of Computer Science
> University of Waterloo
> http://www.mosharaf.com/
> 

Date: Wed, 10 Jun 2009 12:36:42 -0700
From: Joe Touch <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig07D7A52CAE1687EA90630770
Content-Type: multipart/mixed;
 boundary="------------020301050702000401000001"

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

Joe Touch wrote:
=2E..
>> Also, I'd propose to (4) have some state of the art document that
>> overviews current solutions to a wide range of techniques for
>> virtualizing network resources.
>=20
> There was a paper I saw a draft of fairly recently that did a good job
> of this. I'll see if I can get the authors involved in the WG or see if=

> they want to offer their info as input to a draft.

OK, so it only took me a few hours to figure out that this doc was
actually posted on this list back in October (yikes!).

See attached. I wonder if we actually need an RFC if there's already a
sufficient tech report in this space? If we do, then I would nominate
Mosharaf to lead the effort (if of interest) ;-)

Joe

--------------020301050702000401000001
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Attached Message"

Date: Thu, 16 Oct 2008 14:28:56 -0400
From: "Mosharaf Chowdhury" <[email-masked]>
To: "Martin Stiemerling" <[email-masked]>
Cc: [email-masked]
Subject: Re: [nvrg-bof] Further steps
Sender: [email-masked]

------=_Part_40832_22617490.1224181736380
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Martin,

I believe you would be interested in the survey we have put together
recently. You can find the technical report here:
http://www.cs.uwaterloo.ca/research/tr/2008/CS-2008-25.pdf. Any comment,
critique will be very much appreciated.

And I'd be glad to contribute in the compilation of a formal problem
statement for NVRG.

Btw, I was wondering whether there is anything formally named IRTF NVRG
(administratively speaking) ?

-Mosharaf

On Mon, Oct 13, 2008 at 3:48 PM, Martin Stiemerling
<[email-masked]> wrote:

> Dear all,
>
> Some words on what are the next steps IMO:
>
> - I'm about to compile a problem statement for Network Virtualization
> Research Group. This draft should be a write-up containing some
> clarification of terminology and a sketch of the problem space the NVRG
> would tackle.
> - Planning a new meeting at the upcoming IETF meeting in Minneapolis, if
> people are interested to join. Some information about the upcoming IETF
> meeting: http://www.ietf.org/meetings/73/
>
> Let me know if you're interest in contributing.
>
>  Martin
>
> [email-masked]
>
> NEC Laboratories Europe - Network Research Division
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London
> W3 6BL | Registered in England 2832014
>
>

-- 
Mosharaf K Chowdhury
Cheriton School of Computer Science
University of Waterloo
http://www.mosharaf.com/

------=_Part_40832_22617490.1224181736380
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">Hi Martin,<br><br>I believe you would be interested in the survey we have put together recently. You can find the technical report here: <a href="http://www.cs.uwaterloo.ca/research/tr/2008/CS-2008-25.pdf" target="_blank">http://www.cs.uwaterloo.ca/research/tr/2008/CS-2008-25.pdf</a>. Any comment, critique will be very much appreciated. <br>
<br>And I&#39;d be glad to contribute in the compilation of a formal problem statement for NVRG.<br>
<br>
Btw, I was wondering whether there is anything formally named IRTF NVRG (administratively speaking) ?<br>
<br>
-Mosharaf<br><br><div class="gmail_quote">On Mon, Oct 13, 2008 at 3:48 PM, Martin Stiemerling <span dir="ltr">&lt;[email-masked]&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Dear all,<br>
<br>
Some words on what are the next steps IMO:<br>
<br>
- I&#39;m about to compile a problem statement for Network Virtualization Research Group. This draft should be a write-up containing some clarification of terminology and a sketch of the problem space the NVRG would tackle.<br>

- Planning a new meeting at the upcoming IETF meeting in Minneapolis, if people are interested to join. Some information about the upcoming IETF meeting: <a href="http://www.ietf.org/meetings/73/" target="_blank">http://www.ietf.org/meetings/73/</a><br>

<br>
Let me know if you&#39;re interest in contributing.<br>
<br>
 &nbsp;Martin<br>
<br>
[email-masked]<br>
<br>
NEC Laboratories Europe - Network Research Division<br>
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Mosharaf K Chowdhury<br>Cheriton School of Computer Science<br>University of Waterloo<br><a href="http://www.mosharaf.com/" target="_blank">http://www.mosharaf.com/</a><br>

<br>
</div>

------=_Part_40832_22617490.1224181736380--

--------------020301050702000401000001--

--------------enig07D7A52CAE1687EA90630770
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig07D7A52CAE1687EA90630770--

Date: Wed, 10 Jun 2009 12:31:59 -0700
From: Joe Touch <[email-masked]>
To: James Kempf <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

James Kempf wrote:
> I've actually heard the term "slices" apply to network as well as
> computation resources.
> 
> 			jak 

I have too, focusing on things like BW, not on addresses, interfaces,
paths, etc. We have a name for that - an overlay or a virtual network.
I've also heard people assert (incorrectly) that slices of existing
systems (e.g., PlanetLab) included network virtualization. Given the
confusion, the term slice may have clear meaning in a distributed OS,
but does not in networking.

I'd rather not use an ill-defined term that doesn't have a direct
relation to the WG's work, esp. in the charter.

Joe

> 
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]] 
>> Sent: Wednesday, June 10, 2009 12:10 PM
>> To: James Kempf
>> Cc: Martin Stiemerling; [email-masked]
>> Subject: Re: [nvrg-bof] Updated charter proposal
>>
> 
> 
> James Kempf wrote:
>>>> Hi Joe,
>>>>
>>>> Thanx for the reply. Regarding: 
>>>>
>>>>>> Currently,
>>>>>> there is much work going on in GENI on control frameworks for 
>>>>>> provisioning a virtual aggregate (a network slice and compute 
>>>>>> resources).
>>>>> This is not network virtualization. I.e., when we deal 
> with an OS, we 
>>>>> don't try to standardize the provisioning of memory, processing 
>>>>> capacity, etc. Processes don't ask for 20% of a CPU; they 
> just ask to 
>>>>> run. Processes don't ask for 20% of memory, they ask for 
> it in terms 
>>>>> they need (bytes).
>>>>> Similarly, virtual networks ask for resources in terms they need 
>>>>> (addresses, links, and reserved link capacity, i.e., 
> provisioning). 
>>>>> We need a common way to express how to virtualize the 
> network (which 
>>>>> most "virtualization" systems don't really do anyway) 
> before we can 
>>>>> standardize how its resources are manged.
>>>> GENI has the notion of RSPECs which I believe are designed to allow 
>>>> virtual network providers to ask for resources. There has also been 
>>>> some recent work in 4WARD along these lines. Are you saying 
> that the 
>>>> way these proposals are designed doesn't really address the need or 
>>>> perhaps that they need some modification?
> RSPECs, like many things in GENI, focus on services and 
> computation - i.e., OS resources, not network resources 
> (e.g., addresses, interfaces, virtual links, etc.) - at least 
> according to the March 2008 slides I could find on the topic.
> 
>>>> One of the issues we've been discussing here at ER is that there is 
>>>> already a collection of deployed data plane techniques to support 
>>>> network virtualization. For dedicated bandwith, the techniques run 
>>>> from dedicated lambdas up to MPLS LSPs in IP networks and PBB-TE 
>>>> tunnels in Metro Ethernet. For nondedicated bandwidth, 
> there are IP-IP 
>>>> tunnels, maybe one could even view HIP as a kind of tunnel. 
> Are these 
>>>> techniques insufficient?
> There are lots of building blocks, and a few systems that 
> create network architectures out of them (which is more than 
> just the building blocks).
> We need to develop a common framework for virtualizing the 
> *network*; then we can engage groups like GENI about how to 
> organize distributed resources on it.
> 
>>>> If you grant that these techniques are sufficient, then the primary 
>>>> issue becomes how to  construct a virtual network in a 
> cross provider 
>>>> way. This today, as far as I can determine, is impossible except if 
>>>> you run over IP.
> It can be done at IP, MPLS, or ethernet, as well as some 
> other less ubiquitous ways today.
> 
>>>> The issue you cite above, namely how to name and allocate 
> resources, 
>>>> is a big one, also interoperability between providers to allow the 
>>>> slices to be plumbed together.
> Slices, AFAICT, refer to a group of (virtualized) OS 
> resources. It's not useful to talk about those resources 
> until the *network* resources are virtualized and coordinated.
> 
>>>> There is also a question of
>>>> timescale. Most providers require a timescale of days to set up a 
>>>> virtual network like a VPN. I believe the vision of most 
> researchers 
>>>> is such virtual networks to be available on demand.
> You're jumping a few steps ahead. IMO, the steps are:
> 
> 	- define a common virtual network framework
> 	(what this BOF is for)
> 	- determine how providers can offer VNFs as a service
> 	- determine how to provision a VNF across providers
> 	- integrate VNFs with slice reservation systems
> 
> We're at step one here.
> 
>>>> So our view on this is that the work is primarily needed in 
>>>> constructing a control plane that allows virtual network 
> slices to be 
>>>> constructed from resources obtained from different ISPs by 
> a virtual 
>>>> network provider. And then to connect the network resources 
> up to end 
>>>> host resources (which may involve clouds or end host virtual 
>>>> machines). This seems to me what GENI is trying to address, maybe 
>>>> Trilogy and Akari as well (I am not that familiar with them).
> It's hard to consider discussing a control plane when we 
> haven't yet defined what to control. Slices don't include 
> network interfaces or addresses as a virtualized, localized 
> resources - that is the purpose of network virtualization, 
> and it is useful independently of a slice. So let's start by 
> decoupling the two, and solve the network virtualization 
> problem first.
> 
> Joe
>>

Content-class: urn:content-classes:message
Date: Wed, 10 Jun 2009 14:26:54 -0500
From: "James Kempf" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

I've actually heard the term "slices" apply to network as well as
computation resources.

			jak=20

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]=20
> Sent: Wednesday, June 10, 2009 12:10 PM
> To: James Kempf
> Cc: Martin Stiemerling; [email-masked]
> Subject: Re: [nvrg-bof] Updated charter proposal
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
>=20
> James Kempf wrote:
> > Hi Joe,
> >=20
> > Thanx for the reply. Regarding:=20
> >=20
> >>> Currently,
> >>> there is much work going on in GENI on control frameworks for=20
> >>> provisioning a virtual aggregate (a network slice and compute=20
> >>> resources).
> >> This is not network virtualization. I.e., when we deal=20
> with an OS, we=20
> >> don't try to standardize the provisioning of memory, processing=20
> >> capacity, etc. Processes don't ask for 20% of a CPU; they=20
> just ask to=20
> >> run. Processes don't ask for 20% of memory, they ask for=20
> it in terms=20
> >> they need (bytes).
> >> Similarly, virtual networks ask for resources in terms they need=20
> >> (addresses, links, and reserved link capacity, i.e.,=20
> provisioning).=20
> >> We need a common way to express how to virtualize the=20
> network (which=20
> >> most "virtualization" systems don't really do anyway)=20
> before we can=20
> >> standardize how its resources are manged.
> >=20
> > GENI has the notion of RSPECs which I believe are designed to allow=20
> > virtual network providers to ask for resources. There has also been=20
> > some recent work in 4WARD along these lines. Are you saying=20
> that the=20
> > way these proposals are designed doesn't really address the need or=20
> > perhaps that they need some modification?
>=20
> RSPECs, like many things in GENI, focus on services and=20
> computation - i.e., OS resources, not network resources=20
> (e.g., addresses, interfaces, virtual links, etc.) - at least=20
> according to the March 2008 slides I could find on the topic.
>=20
> > One of the issues we've been discussing here at ER is that there is=20
> > already a collection of deployed data plane techniques to support=20
> > network virtualization. For dedicated bandwith, the techniques run=20
> > from dedicated lambdas up to MPLS LSPs in IP networks and PBB-TE=20
> > tunnels in Metro Ethernet. For nondedicated bandwidth,=20
> there are IP-IP=20
> > tunnels, maybe one could even view HIP as a kind of tunnel.=20
> Are these=20
> > techniques insufficient?
>=20
> There are lots of building blocks, and a few systems that=20
> create network architectures out of them (which is more than=20
> just the building blocks).
> We need to develop a common framework for virtualizing the=20
> *network*; then we can engage groups like GENI about how to=20
> organize distributed resources on it.
>=20
> > If you grant that these techniques are sufficient, then the primary=20
> > issue becomes how to  construct a virtual network in a=20
> cross provider=20
> > way. This today, as far as I can determine, is impossible except if=20
> > you run over IP.
>=20
> It can be done at IP, MPLS, or ethernet, as well as some=20
> other less ubiquitous ways today.
>=20
> > The issue you cite above, namely how to name and allocate=20
> resources,=20
> > is a big one, also interoperability between providers to allow the=20
> > slices to be plumbed together.
>=20
> Slices, AFAICT, refer to a group of (virtualized) OS=20
> resources. It's not useful to talk about those resources=20
> until the *network* resources are virtualized and coordinated.
>=20
> > There is also a question of
> > timescale. Most providers require a timescale of days to set up a=20
> > virtual network like a VPN. I believe the vision of most=20
> researchers=20
> > is such virtual networks to be available on demand.
>=20
> You're jumping a few steps ahead. IMO, the steps are:
>=20
> 	- define a common virtual network framework
> 	(what this BOF is for)
> 	- determine how providers can offer VNFs as a service
> 	- determine how to provision a VNF across providers
> 	- integrate VNFs with slice reservation systems
>=20
> We're at step one here.
>=20
> > So our view on this is that the work is primarily needed in=20
> > constructing a control plane that allows virtual network=20
> slices to be=20
> > constructed from resources obtained from different ISPs by=20
> a virtual=20
> > network provider. And then to connect the network resources=20
> up to end=20
> > host resources (which may involve clouds or end host virtual=20
> > machines). This seems to me what GENI is trying to address, maybe=20
> > Trilogy and Akari as well (I am not that familiar with them).
>=20
> It's hard to consider discussing a control plane when we=20
> haven't yet defined what to control. Slices don't include=20
> network interfaces or addresses as a virtualized, localized=20
> resources - that is the purpose of network virtualization,=20
> and it is useful independently of a slice. So let's start by=20
> decoupling the two, and solve the network virtualization=20
> problem first.
>=20
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>=20
> iEYEARECAAYFAkowBQgACgkQE5f5cImnZru+lACg3yyM6NNqYz90irCUtrFIZF+9
> QvAAn0zElAT+gaKjYR1dRruVq4Z68Xhr
> =3D0bYe
> -----END PGP SIGNATURE-----
>=20

Date: Wed, 10 Jun 2009 12:10:01 -0700
From: Joe Touch <[email-masked]>
To: James Kempf <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

James Kempf wrote:
> Hi Joe,
> 
> Thanx for the reply. Regarding: 
> 
>>> Currently,
>>> there is much work going on in GENI on control frameworks for 
>>> provisioning a virtual aggregate (a network slice and compute 
>>> resources).
>> This is not network virtualization. I.e., when we deal with 
>> an OS, we don't try to standardize the provisioning of 
>> memory, processing capacity, etc. Processes don't ask for 20% 
>> of a CPU; they just ask to run. Processes don't ask for 20% 
>> of memory, they ask for it in terms they need (bytes). 
>> Similarly, virtual networks ask for resources in terms they 
>> need (addresses, links, and reserved link capacity, i.e., 
>> provisioning). We need a common way to express how to 
>> virtualize the network (which most "virtualization" systems 
>> don't really do anyway) before we can standardize how its 
>> resources are manged.
> 
> GENI has the notion of RSPECs which I believe are designed to allow
> virtual network providers to ask for resources. There has also been some
> recent work in 4WARD along these lines. Are you saying that the way
> these proposals are designed doesn't really address the need or perhaps
> that they need some modification?

RSPECs, like many things in GENI, focus on services and computation -
i.e., OS resources, not network resources (e.g., addresses, interfaces,
virtual links, etc.) - at least according to the March 2008 slides I
could find on the topic.

> One of the issues we've been discussing here at ER is that there is
> already a collection of deployed data plane techniques to support
> network virtualization. For dedicated bandwith, the techniques run from
> dedicated lambdas up to MPLS LSPs in IP networks and PBB-TE tunnels in
> Metro Ethernet. For nondedicated bandwidth, there are IP-IP tunnels,
> maybe one could even view HIP as a kind of tunnel. Are these techniques
> insufficient?

There are lots of building blocks, and a few systems that create network
architectures out of them (which is more than just the building blocks).
We need to develop a common framework for virtualizing the *network*;
then we can engage groups like GENI about how to organize distributed
resources on it.

> If you grant that these techniques are sufficient, then the primary
> issue becomes how to  construct a virtual network in a cross provider
> way. This today, as far as I can determine, is impossible except if you
> run over IP. 

It can be done at IP, MPLS, or ethernet, as well as some other less
ubiquitous ways today.

> The issue you cite above, namely how to name and allocate
> resources, is a big one, also interoperability between providers to
> allow the slices to be plumbed together.

Slices, AFAICT, refer to a group of (virtualized) OS resources. It's not
useful to talk about those resources until the *network* resources are
virtualized and coordinated.

> There is also a question of
> timescale. Most providers require a timescale of days to set up a
> virtual network like a VPN. I believe the vision of most researchers is
> such virtual networks to be available on demand.

You're jumping a few steps ahead. IMO, the steps are:

	- define a common virtual network framework
	(what this BOF is for)
	- determine how providers can offer VNFs as a service
	- determine how to provision a VNF across providers
	- integrate VNFs with slice reservation systems

We're at step one here.

> So our view on this is that the work is primarily needed in constructing
> a control plane that allows virtual network slices to be constructed
> from resources obtained from different ISPs by a virtual network
> provider. And then to connect the network resources up to end host
> resources (which may involve clouds or end host virtual machines). This
> seems to me what GENI is trying to address, maybe Trilogy and Akari as
> well (I am not that familiar with them).

It's hard to consider discussing a control plane when we haven't yet
defined what to control. Slices don't include network interfaces or
addresses as a virtualized, localized resources - that is the purpose of
network virtualization, and it is useful independently of a slice. So
let's start by decoupling the two, and solve the network virtualization
problem first.

Joe

Content-class: urn:content-classes:message
Date: Wed, 10 Jun 2009 13:51:24 -0500
From: "James Kempf" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

Hi Joe,

Thanx for the reply. Regarding:=20

> > Currently,
> > there is much work going on in GENI on control frameworks for=20
> > provisioning a virtual aggregate (a network slice and compute=20
> > resources).
>=20
> This is not network virtualization. I.e., when we deal with=20
> an OS, we don't try to standardize the provisioning of=20
> memory, processing capacity, etc. Processes don't ask for 20%=20
> of a CPU; they just ask to run. Processes don't ask for 20%=20
> of memory, they ask for it in terms they need (bytes).=20
> Similarly, virtual networks ask for resources in terms they=20
> need (addresses, links, and reserved link capacity, i.e.,=20
> provisioning). We need a common way to express how to=20
> virtualize the network (which most "virtualization" systems=20
> don't really do anyway) before we can standardize how its=20
> resources are manged.
>=20

GENI has the notion of RSPECs which I believe are designed to allow
virtual network providers to ask for resources. There has also been some
recent work in 4WARD along these lines. Are you saying that the way
these proposals are designed doesn't really address the need or perhaps
that they need some modification?

One of the issues we've been discussing here at ER is that there is
already a collection of deployed data plane techniques to support
network virtualization. For dedicated bandwith, the techniques run from
dedicated lambdas up to MPLS LSPs in IP networks and PBB-TE tunnels in
Metro Ethernet. For nondedicated bandwidth, there are IP-IP tunnels,
maybe one could even view HIP as a kind of tunnel. Are these techniques
insufficient?

If you grant that these techniques are sufficient, then the primary
issue becomes how to   construct a virtual network in a cross provider
way. This today, as far as I can determine, is impossible except if you
run over IP. The issue you cite above, namely how to name and allocate
resources, is a big one, also interoperability between providers to
allow the slices to be plumbed together. There is also a question of
timescale. Most providers require a timescale of days to set up a
virtual network like a VPN. I believe the vision of most researchers is
such virtual networks to be available on demand.

So our view on this is that the work is primarily needed in constructing
a control plane that allows virtual network slices to be constructed
from resources obtained from different ISPs by a virtual network
provider. And then to connect the network resources up to end host
resources (which may involve clouds or end host virtual machines). This
seems to me what GENI is trying to address, maybe Trilogy and Akari as
well (I am not that familiar with them).

             jak

Date: Wed, 10 Jun 2009 08:41:58 -0700
From: Joe Touch <[email-masked]>
To: Katsushi Kobayashi <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

Katsushi Kobayashi wrote:
> Hi,
> 
> I think the charter draft is fine. A minor comment is the followings:
> 
> l.4.
> ........... These resource can be network components, such as, for
> example, routers, switches or hosts, and also services, such as, for
> example,
> name mapping systems. .....
> 
> In the above, there is no "circuit" and "link" technology in the network
> component type enumeration. I think it should be add, if it can be consists
> of virtualized network.

Agreed, with enthusiasm. I'd say "virtual link", rather than "circuit" -
since circuit has other implications (must be 1:1, must have fixed
resources, etc.)

Joe

Date: Wed, 10 Jun 2009 08:40:38 -0700
From: Joe Touch <[email-masked]>
To: Jukka Manner <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

Jukka Manner wrote:
> Hi Martin, all,
> 
> Overall the charter looks fine. I agree to some of the earlier comments on
> 1. discussing unifying different testbeds

I don't see that as a goal for an IRTF WG.

> 2. Adding a problem statement
> 3. Adding more research themes

This seems useful.

> Also, I'd propose to (4) have some state of the art document that
> overviews current solutions to a wide range of techniques for
> virtualizing network resources.

There was a paper I saw a draft of fairly recently that did a good job
of this. I'll see if I can get the authors involved in the WG or see if
they want to offer their info as input to a draft.

Joe

Date: Wed, 10 Jun 2009 08:39:21 -0700
From: Joe Touch <[email-masked]>
To: Martin Stiemerling <[email-masked]>
Cc: [email-masked]
Subject: Re: [nvrg-bof] Updated charter proposal

Comments below...

Martin Stiemerling wrote:
> Hi all,
> 
> Here is the updated charter proposal. Let me know your comments.
> 
>   Martin
> 
> Draft charter for the Virtual Networks Research Group VNRG) proposal
> 
> VERSION: 2009-05-22 0800 UCT
> 
> Recent developments in networking are aiming at better utilizing infrastructure
> in terms of reusing a single physical or logical resource for multiple other
> network instances, or to aggregate multiple these resources to obtain more
> "functionality". These resource can be network components, such as, for
> example, routers, switches or hosts, and also services, such as, for example,
> name mapping systems. Typically, this is referred to as Virtual Networks, where
> a resource is either re-used for multiple networks or multiple resources are
> aggregated for virtual resource.
> Important properties of Virtual Networks are i) the level of participation
> of each resource and ii) the clear separation of any virtual network to all
> others. Each resource can be sliced so that it can be part of multiple 

The term should be 'virtualized', not 'sliced'. We don't talk about
slicing memory or CPUs, e.g.

> Virtual Networks, but on the other hand does virtualization guarentee the
> clear separation of each network, so that actions in one network do not affect
> the operation of any other network. 
> 
> However, in the network community, Virtual Networks is a very  
> broad term, ranging from running multiple wave lengths over a fiber,  
> MPLS, virtual routers, to overlay systems. This leads to deployment of  
> single technologies in parts of the Internet or other IP-based  
> networks, but lacks a common understanding of what virtualized networks
> is causing to IP-based networks, or how Virtual Networks is applied
> in favorable way.  This leads to the introduction of virtualization in an
> uncoordinated way between the various players, such as network operators,
> vendors, service providers and testbed providers (e.g. GENI, FEDERICA, etc)
> without considerations about the overall impact on the system level. 

There are other testbeds to note, e.g. CoreLab, AKARI, etc.

> The Virtual Networks Research Group (VNRG)  provides a forum for  
> interchange of ideas among a group of network researchers with an  
> interest in network virtualization in the context of the Interent and  
> also beyond the current Internet.
> 
> The RG works on a set of principles of virtual networks that a single
> physical resource can be re-used by multiple entities with a clear separation
> between the actions taken by the single entities. Virtualization delivers an
> abstraction to the user (i.e., not necessarily a human but a service or
> whatever) referring to the decoupling from the physical resource, i.e., 
> the abstraction is not bound to a single resource but can be relocated
> but is a logical structure. Virtualization also offers recursion, i.e., an
> already virtualized network can again include virtual networks.
> 
> 
> The group will address the following research challenges:
> - Consider a whole system for virtualized networks and not only single
>   components or a limited set of components;
> - Identifying architectural challenges resulting from virtual networks;  
> - Recursive network management of virtual networks;
> - Emerging technological and implementation issues.
> 
> 
> Web site: http://user.informatik.uni-goettingen.de/~stiemer/nvrg/
> 
> Mailing list:  Open mailing list to anybody, just needs signing up  
> with the list
> list's address: [email-masked]
> signing up: https://listserv.gwdg.de/mailman/listinfo/nvrg
> 
> 
> 
> 
> [email-masked]
> 
> NEC Laboratories Europe - Network Research Division
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
> 

Date: Wed, 10 Jun 2009 08:28:31 -0700
From: Joe Touch <[email-masked]>
To: PAPADIMITRIOU Dimitri <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

Catching up...

PAPADIMITRIOU Dimitri wrote:
...
> Two base comments:
> 
> o) "research challenges" should include a specific work item on a
> "problem statement/observations" vs "needs" e.g. why are the intended
> functionality not resolvable with the current Internet/where are the
> limitations ?/etc. Such effort would be allow to identify more clearly
> the architectural and design goals (if the approach is inductive
> documenting set of representative use cases can be considered).

Agreed.

> o) the "Identifying architectural challenges resulting from virtual
> networks" is the only research topic, the others are either statements
> (i) or sub-components of one possible design (ii) or bottom-level
> implementation issues (by the way which issues are foreseen beside
> interop ?). Henceforth, I suggest to detail the list of research points.

IMO, that doesn't need to happen in the charter. Charters should be
vague and give the WG wiggle room to do the most effective work possible
without requiring inordinate overhead (e.g., to recharter).

Joe

Date: Wed, 10 Jun 2009 08:26:12 -0700
From: Joe Touch <[email-masked]>
To: James Kempf <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

James Kempf wrote:
...
> If there is any reason at all for an IETF-affiliated group on
> virtualization, it has to do with interoperability, IMHO. 

Agreed,

> Currently,
> there is much work going on in GENI on control frameworks for
> provisioning a virtual aggregate (a network slice and compute
> resources). 

This is not network virtualization. I.e., when we deal with an OS, we
don't try to standardize the provisioning of memory, processing
capacity, etc. Processes don't ask for 20% of a CPU; they just ask to
run. Processes don't ask for 20% of memory, they ask for it in terms
they need (bytes). Similarly, virtual networks ask for resources in
terms they need (addresses, links, and reserved link capacity, i.e.,
provisioning). We need a common way to express how to virtualize the
network (which most "virtualization" systems don't really do anyway)
before we can standardize how its resources are manged.

> I think the RG should focus on bringing together researchers in
> different geographic areas to define interoperability between control
> frameworks, and should include both nonprofit operators and for-profit
> operators, vendors, and researchers. 

That sounds like unifying network management before we have specified an
Internet protocol suite or host or gateway requirements.

Joe

Date: Wed, 10 Jun 2009 08:11:31 -0700
From: Joe Touch <[email-masked]>
To: Aaron Falk <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

Aaron Falk wrote:
> I agree with James.  Virtualization is getting intense interest in
> industry but in a way that is very different from the way projects like
> GENI and FEDERICA are using it.  Operators use virtualization as a way
> of bringing up and managing services.  GENI uses virtualization to allow
> researchers to share deeply-programmable experimental infrastructure. 

I'm not sure this is all on the same page at all. Industry
virtualization focuses on the OS, as you note to virtualize services,
not as a way to virtualize a network.

Network virtualization has a fairly long history (over a decade), which
is close to the virtualization efforts in the EU and Japan right now,
and where NVRG was going IMO.

AFAICT, GENI is exploring the two together, but they are not necessarily
coupled.

Network virtualization without OS virtualization is just as useful,
mapping network resources at the process group level rather than the OS
level.

As to whether experiments or commercial systems require different
things, I could not disagree more. They may have different priorities of
what to develop short-term or what needs more detailed development
(e.g., a debugger isn't a run-time system), but overall they solve
exactly the same problem architecturally.

...
> Off the top of my head, here are a few examples of challenges GENI faces
> related to virtualization:
> 
>     * How is isolation between slices handled?  To strict a requirement
>       and you loose flexibility, too loose and experiments are
>       influenced by other slices.

Consider the same question in terms of OSs. They're isolated except
where sharing is explicit (shared memory, IPC). Why isn't the same
answer good enough for virtual nets?

>     * How is repeatability handled?  The virtual world is dependent on
>       the real infrastructure beneath it.  How much should it be
>       measured/controlled to permit repeatable experiments?
>     * How is visibility handled?  Users may be interested in fine grain
>       information about the real devices in the path.  By definition,
>       this is hidden from users via virtualization.  How is visibility
>       controlled?
>     * How do the three topics above (isolation, repeatability, and
>       visibility) impact experiment design and resource discovery?
>     * Can slices with very diverse goals in the above topics share
>       infrastructure?

If I were to ask the same questions about multiprocessing (process
virtualization), would they make the same (or any) sense?

Virtualization is abstraction. Abstraction means that you may know
process time, but not clock time; you may know path properties, but not
physical path. If you don't want to (or can't) ignore these properties
you're better off not virtualizing - e.g., as per many real-time OS's.

Joe

Date: Wed, 10 Jun 2009 10:51:07 -0400
From: Aaron Falk <[email-masked]>
Organization: BBN Technologies
To: James Kempf <[email-masked]>
Cc: [email-masked], Martin Stiemerling <[email-masked]>
Subject: Re: [nvrg-bof] Updated charter proposal

I agree with James.  Virtualization is getting intense interest in
industry but in a way that is very different from the way projects like
GENI and FEDERICA are using it.  Operators use virtualization as a way
of bringing up and managing services.  GENI uses virtualization to allow
researchers to share deeply-programmable experimental infrastructure. 
The constraints and goals are quite different, I think.  How are these
aspects related?  Can an RG be used to bring interested parties from
both communities together?  What can they learn from each other?  It
might be worth trying to chat with some vendors (HP? Cisco?) and
operators (MVNOs?) before trying to answer these questions. Since,
AFAICT, they have been largely absent from the discussion so far.

Off the top of my head, here are a few examples of challenges GENI faces
related to virtualization:

    * How is isolation between slices handled?  To strict a requirement
      and you loose flexibility, too loose and experiments are
      influenced by other slices.
    * How is repeatability handled?  The virtual world is dependent on
      the real infrastructure beneath it.  How much should it be
      measured/controlled to permit repeatable experiments?
    * How is visibility handled?  Users may be interested in fine grain
      information about the real devices in the path.  By definition,
      this is hidden from users via virtualization.  How is visibility
      controlled?
    * How do the three topics above (isolation, repeatability, and
      visibility) impact experiment design and resource discovery?
    * Can slices with very diverse goals in the above topics share
      infrastructure?

There are probably others but I'd need more coffee to produce them. :)

cheers,

--aaron

James Kempf wrote:
> The charter is currently a bit fuzzy. I don't see much value in yet
> another forum to discuss architecture or other theoretical concerns,
> except perhaps to keep contact with important academic work in this
> area. 
>
> If there is any reason at all for an IETF-affiliated group on
> virtualization, it has to do with interoperability, IMHO. Currently,
> there is much work going on in GENI on control frameworks for
> provisioning a virtual aggregate (a network slice and compute
> resources). AFICT, this work is primarily directed at the US academic
> institutions and the operators involved are primarily nonprofits
> (Internet 2 and the nonprofit regionals) due to the US funding model
> (through NSF). I don't know what is going on in Europe, Japan, or China
> with respect to prototype frameworks for virtual network control, though
> I am somewhat familiar with virtualization architectural work in Europe.
> The danger is that we end up in 5 years time with national or regional
> control frameworks for virtualized resource allocation that don't
> properly interoperate.
>
> I think the RG should focus on bringing together researchers in
> different geographic areas to define interoperability between control
> frameworks, and should include both nonprofit operators and for-profit
> operators, vendors, and researchers. Ideally, in perhaps a year or two,
> the issues should be well enough sorted out for an IETF WG to form that
> can standardize an interoperability framework. 
>
> There may be some other topics that an RG could consider, but I think it
> would be better to have a specific focus that would serve IETF well.
>
> 			jak  
>
>   
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Martin Stiemerling
>> Sent: Friday, May 22, 2009 12:34 AM
>> To: [email-masked]
>> Subject: [nvrg-bof] Updated charter proposal
>>
>> Hi all,
>>
>> Here is the updated charter proposal. Let me know your comments.
>>
>>   Martin
>>
>> Draft charter for the Virtual Networks Research Group VNRG) proposal
>>
>> VERSION: 2009-05-22 0800 UCT
>>
>> Recent developments in networking are aiming at better 
>> utilizing infrastructure in terms of reusing a single 
>> physical or logical resource for multiple other network 
>> instances, or to aggregate multiple these resources to obtain 
>> more "functionality". These resource can be network 
>> components, such as, for example, routers, switches or hosts, 
>> and also services, such as, for example, name mapping 
>> systems. Typically, this is referred to as Virtual Networks, 
>> where a resource is either re-used for multiple networks or 
>> multiple resources are aggregated for virtual resource.
>> Important properties of Virtual Networks are i) the level of 
>> participation of each resource and ii) the clear separation 
>> of any virtual network to all others. Each resource can be 
>> sliced so that it can be part of multiple Virtual Networks, 
>> but on the other hand does virtualization guarentee the clear 
>> separation of each network, so that actions in one network do 
>> not affect the operation of any other network. 
>>
>> However, in the network community, Virtual Networks is a very 
>> broad term, ranging from running multiple wave lengths over a 
>> fiber, MPLS, virtual routers, to overlay systems. This leads 
>> to deployment of single technologies in parts of the Internet 
>> or other IP-based networks, but lacks a common understanding 
>> of what virtualized networks is causing to IP-based networks, 
>> or how Virtual Networks is applied in favorable way.  This 
>> leads to the introduction of virtualization in an 
>> uncoordinated way between the various players, such as 
>> network operators, vendors, service providers and testbed 
>> providers (e.g. GENI, FEDERICA, etc) without considerations 
>> about the overall impact on the system level. 
>>
>> The Virtual Networks Research Group (VNRG)  provides a forum 
>> for interchange of ideas among a group of network researchers 
>> with an interest in network virtualization in the context of 
>> the Interent and also beyond the current Internet.
>>
>> The RG works on a set of principles of virtual networks that 
>> a single physical resource can be re-used by multiple 
>> entities with a clear separation between the actions taken by 
>> the single entities. Virtualization delivers an abstraction 
>> to the user (i.e., not necessarily a human but a service or
>> whatever) referring to the decoupling from the physical 
>> resource, i.e., the abstraction is not bound to a single 
>> resource but can be relocated but is a logical structure. 
>> Virtualization also offers recursion, i.e., an already 
>> virtualized network can again include virtual networks.
>>
>>
>> The group will address the following research challenges:
>> - Consider a whole system for virtualized networks and not only single
>>   components or a limited set of components;
>> - Identifying architectural challenges resulting from virtual 
>> networks;  
>> - Recursive network management of virtual networks;
>> - Emerging technological and implementation issues.
>>
>>
>> Web site: http://user.informatik.uni-goettingen.de/~stiemer/nvrg/
>>
>> Mailing list:  Open mailing list to anybody, just needs signing up  
>> with the list
>> list's address: [email-masked]
>> signing up: https://listserv.gwdg.de/mailman/listinfo/nvrg
>>
>>
>>
>>
>> [email-masked]
>>
>> NEC Laboratories Europe - Network Research Division
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
>> Road, London W3 6BL | Registered in England 2832014 
>>
>>
>>     

Date: Sun, 07 Jun 2009 21:40:17 +0300
From: Jukka Manner <[email-masked]>
To: Martin Stiemerling <[email-masked]>
Cc: [email-masked]
Subject: Re: [nvrg-bof] Updated charter proposal

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

Hi Martin, all,

Overall the charter looks fine. I agree to some of the earlier comments on
1. discussing unifying different testbeds
2. Adding a problem statement
3. Adding more research themes

Also, I'd propose to (4) have some state of the art document that 
overviews current solutions to a wide range of techniques for 
virtualizing network resources.

Cheers,
Jukka

Martin Stiemerling wrote:
> Hi all,
> 
> Here is the updated charter proposal. Let me know your comments.
> 
>   Martin
> 
> Draft charter for the Virtual Networks Research Group VNRG) proposal
> 
> VERSION: 2009-05-22 0800 UCT
> 
> Recent developments in networking are aiming at better utilizing infrastructure
> in terms of reusing a single physical or logical resource for multiple other
> network instances, or to aggregate multiple these resources to obtain more
> "functionality". These resource can be network components, such as, for
> example, routers, switches or hosts, and also services, such as, for example,
> name mapping systems. Typically, this is referred to as Virtual Networks, where
> a resource is either re-used for multiple networks or multiple resources are
> aggregated for virtual resource.
> Important properties of Virtual Networks are i) the level of participation
> of each resource and ii) the clear separation of any virtual network to all
> others. Each resource can be sliced so that it can be part of multiple 
> Virtual Networks, but on the other hand does virtualization guarentee the
> clear separation of each network, so that actions in one network do not affect
> the operation of any other network. 
> 
> However, in the network community, Virtual Networks is a very  
> broad term, ranging from running multiple wave lengths over a fiber,  
> MPLS, virtual routers, to overlay systems. This leads to deployment of  
> single technologies in parts of the Internet or other IP-based  
> networks, but lacks a common understanding of what virtualized networks
> is causing to IP-based networks, or how Virtual Networks is applied
> in favorable way.  This leads to the introduction of virtualization in an
> uncoordinated way between the various players, such as network operators,
> vendors, service providers and testbed providers (e.g. GENI, FEDERICA, etc)
> without considerations about the overall impact on the system level. 
> 
> The Virtual Networks Research Group (VNRG)  provides a forum for  
> interchange of ideas among a group of network researchers with an  
> interest in network virtualization in the context of the Interent and  
> also beyond the current Internet.
> 
> The RG works on a set of principles of virtual networks that a single
> physical resource can be re-used by multiple entities with a clear separation
> between the actions taken by the single entities. Virtualization delivers an
> abstraction to the user (i.e., not necessarily a human but a service or
> whatever) referring to the decoupling from the physical resource, i.e., 
> the abstraction is not bound to a single resource but can be relocated
> but is a logical structure. Virtualization also offers recursion, i.e., an
> already virtualized network can again include virtual networks.
> 
> 
> The group will address the following research challenges:
> - Consider a whole system for virtualized networks and not only single
>   components or a limited set of components;
> - Identifying architectural challenges resulting from virtual networks;  
> - Recursive network management of virtual networks;
> - Emerging technological and implementation issues.
> 
> 
> Web site: http://user.informatik.uni-goettingen.de/~stiemer/nvrg/
> 
> Mailing list:  Open mailing list to anybody, just needs signing up  
> with the list
> list's address: [email-masked]
> signing up: https://listserv.gwdg.de/mailman/listinfo/nvrg
> 
> 
> 
> 
> [email-masked]
> 
> NEC Laboratories Europe - Network Research Division
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
> 

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Helsinki University of Technology Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320 (Otakaari 5A)
P.O. Box 3000, FIN-02015 TKK      E-mail: [email-masked]
Finland                           WWW:    www.comnet.tkk.fi

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

begin:vcard
fn:Jukka Manner
n:Manner;Jukka
org:Helsinki University of Technology (TKK);Department of Communications and Networking (Comnet)
adr:(Otakaari 5 A);;P.O.Box 3000;TKK;;02015;Finland
email;internet:[email-masked]
title:Professor, PhD.
tel;work:+358-9-4512481
tel;fax:+358-9-4512474
tel;cell:+358-50-5112973
x-mozilla-html:FALSE
url:http://comnet.tkk.fi
version:2.1
end:vcard

--------------000300010808070608010205--

Date: Wed, 03 Jun 2009 11:26:55 +0200
From: Roland Bless <[email-masked]>
Organization: Institute of Telematics, University of Karlsruhe
To: Martin Stiemerling <[email-masked]>
Cc: [email-masked]
Subject: Re: [nvrg-bof] Updated charter proposal

Hi Martin,

Martin Stiemerling wrote:
> I assume that no answer to this can mean:
> - it is all just fine (what I don't believe)
> - it so bad, not worth talking about it (hopefully not)
> - people have lost interest in the NVRG.
> 
> So let me know your comments and general opinion!

Don't worry, my feedback was just delayed by several
business trips and holidays. The charter reads a
little bit strange since you replaced "Network Virtualization" by
"Virtual Networks" but you didn't adapt the sentences
then. :-) I'll send some more detailed comments
within the next days.

Regards,
 Roland