Re: [vnrg] Some definitions and way forward

[Roland Bless <[e-mail]>]

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