[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vnrg] Towards a Virtual Network definition



Hi Dae Young,

Am 17.02.2011 04:16, schrieb Dae Young KIM:
> Long time no see.

Yes.

> Are we sure about this? As a experimenter, I'd also be interested in
> virtualization of entities deeper in the layer, that is, virtualization
> of even L2 and L1.

Ok, why not, but IMHO one should distinguish, however, what is your
currently considered layer that is virtualized and what is the
substrate (which might be heterogeneous). And as I said, you may use
also virtualization techniques in the substrate, e.g. VLANs etc.

> 'Network' we're talking about here would not merely mean 'Network Layer'
> in the OSI sense, but mean more of generic 'network' realm compassing
> from Physical upwards even up to Transport or beyond.

Sure, if you want to. For me the focus is on layer 3, but
others may have different interests, e.g., wireless virtualization
is also highly interesting and useful.

>     Question: does the host "belong" to the VNet topology or
>     not? IMHO, it is the same situation as in the Internet today:
>     hosts are part of the network but don't belong to an
>     ISPs infrastructure, i.e., they are attached to the
>     access routers/switches etc.
> 
> 
> A host might be just one type of nodes in networking, i.e., stub node. A
> router, on the other hand might represent another type of node, i.e., a
> relay node.

Yep.

> With this notion, I'd think 'hosts' could also belong to the VNet topology.

In the 4WARD project the VNet topology description didn't include
hosts or stub nodes since they are dynamically attached and you usually
don't know a priori which hosts will be attached. Furthermore, mobility
of hosts is another reason why it is difficult to include them into
a topology description. So maybe it's better to say: hosts are part
of the VNet (topology) but don't belong to the VNet infrastructure.

Regards,
 Roland

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.