Re: [vnrg] Some definitions and way forward

[Roland Bless <[e-mail]>]

Hi Dimitri,

On 03.08.2011 18:07, Papadimitriou, Dimitri (Dimitri) wrote:

> These definitions stems from the view that physical resource owner
> provides virtual resources of the same kind (delimits the type of
> virtual resources it can deliver). My understanding from the scope
> given in the Maastricht meeting was:

Not clear how you infer this view, since I don't see this kind of
restriction in my text.

> - virtual resources can be hosted on physical resources of different
> type i.e. virtual nodes/links don't have to be instantiated from
> physical nodes/links; for instance, a virtual network can comprise
> virtual nodes that are bringing together/aggregating resources from
> multiple physical nodes AND a set of virtual nodes that are emulated
> on a single physical machine.

Thanks for pointing this out, but the given definitions
don't exclude that. How you map virtual nodes and virtual
links onto the substrate resources may vary a lot. We also
consider mapping a virtual link onto a substrate node since
both virtual nodes that are connected by the link are hosted
on the same substrate node. I think it would be good to provide
some examples of mappings to make this clear, maybe when discussing
the terms virtual links and virtual nodes in more detail.

> - virtual resources composing a virtual network can be of different
> type and thus virtually operate at different layers (thus beyond
> nodes and links operating at a given layer) including
> wireless/wireline virtual links with different properties (with or
> without emulated delay), hosts and intermediate nodes of different
> kind, e.g., switches, routers, base stations, etc.). This is
> basically what makes the difference between an "overlay network" and
> "virtual network".

This is important, but probably not easy to grasp. I don't want to
exclude having virtual switches or virtual wireless links and so on,
but it's probably complicated to discuss them all together across
different layers. If you consider virtual routers, then virtual switches
are probably "transparent" connectors just as they are for IP
routers in physical networks. I think we need to work on that.
The difference to overlay networks is IMHO (as also discussed in
earlier mail
http://www.ietf.org/mail-archive/web/vnrg/current/msg00224.html) that
overlay nodes are always sitting at the "ends"
of its underlying layer (the underlay).

> The role definitions here below tend to reproduce (and thus somehow
> limit) the roles we actually know from "physical networks". Taking
> the above definitions, if the virtual network would be running on
> physical hosts, "providers" would not maintain any physical resource
> of the type indicated here below (routers, links, wireless
> infrastructure, etc.) but only computing resources on
> terminals/servers.

As already said above, I can't infer restrictions directly from my text,
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.

On the other hand one can expect that also virtual networks are used
to transport data over some physical distance in many cases. If this
isn't the case one may probably come up with simpler structures that
provide the same level of isolation, e.g., no need to provide a large
virtual infrastructure using several virtual routers if you merely need
to connect virtual nodes that are *always* residing inside the same
physical host - a single virtual switch or router may provide sufficient
connectivity or isolation between them (depending on the addressing
scheme); this may change as soon as the virtual nodes
may actually move to different substrate nodes...

> The role definitions provided here below tend to enforce too a
> client-server strict demarcation between resource owner and non-owner

Which resource do you mean here the virtual or the substrate resource?

> merging thus a functional and operational role whereas demarcation
> would be needed between an external entity to the VN (as delimited by
> the functionality that the VN delivers) and a Virtual NAP (whether
> one owns the underlying resources or not).

Sorry, now I'm lost, I don't get your point here - can you provide
an example? I don't think that any client-server based demarcation
is implied by the proposed architecture, actually we also considered
P2P-based
self-organized access structures for controlling the virtual resources...

> Thanks, -dimitri.

Thanks for your input, that was exactly what I was looking for,
i.e., collecting different viewpoints in order to complete the
big picture.

Regards,
 Roland