Re: [vnrg] Some definitions and way forward

[Roland Bless <[e-mail]>]

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