Re: [vnrg] Some definitions and way forward

["Papadimitriou, Dimitri (Dimitri)" <[e-mail]>]

Hi,

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

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. 

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

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.

Thanks,
-dimitri.

> -----Original Message-----
> From: Roland Bless [mailto:[e-mail]] 
> Sent: Thursday, August 04, 2011 10:36 AM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: [e-mail]
> Subject: Re: [vnrg] Some definitions and way forward
> 
> 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
>