Re: [nvrg-bof] Updated charter proposal

["James Kempf" <james.kempf at ericsson.com>]

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

			jak 

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU] 
> Sent: Wednesday, June 10, 2009 12:10 PM
> To: James Kempf
> Cc: Martin Stiemerling; nvrg at listserv.gwdg.de
> Subject: Re: [nvrg-bof] Updated charter proposal
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkowBQgACgkQE5f5cImnZru+lACg3yyM6NNqYz90irCUtrFIZF+9
> QvAAn0zElAT+gaKjYR1dRruVq4Z68Xhr
> =0bYe
> -----END PGP SIGNATURE-----
>