Subject: [vnrg] Some definitions and way forward

From: Roland Bless <[email-masked]>
Date: Wed, 03 Aug 2011 13:54:39 +0200

Hi,

as already mentioned in the IETF-81 meeting, I committed to
write up some definitions (mostly results from the 4WARD EU project)
that may be useful for further discussion of terminology and problem
statements. I'll leave recursion aspects aside at first since it usually
complicates the discussion - but it's often rather straight-forward to
apply recursion (i.e., consider virtual resources as (virtual)
substrate) etc.
Some illustrations of roles and interfaces can be found in
http://www.ietf.org/proceedings/77/slides/VNRG-3.pdf

Virtual Resource:
A virtual resource appears to a user of that resource
as if he is the (exclusive) owner of that resource.

Substrate:
This denotes the physical resources that host the virtual
resources, i.e., each virtual resource is instantiated
inside one or more physical resources. Substrate resources can
either be partitioned or aggregated in order to provide a
virtual resource. From the above definition of a virtual
resource follows that virtual resources must be
isolated from each other in the data plane as well as
in the control plane.

Virtual Network:
A virtual network (VNet) is a set of (virtual) nodes directly
connected by (virtual) links and realized on top of a
set of underlying physical resources, the Substrate.
There should be no assumptions about the particular
network protocols or architectures running
inside the VNet, i.e., it is not necessarily IP.
Virtual nodes can be further distinguished into
virtual routers and virtual hosts. Virtual routers
forward packets whereas virtual hosts are sinks
or sources of packets.

Infrastructure Provider:
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. The InP also offers a resource control interface for the
virtualized resources. Through this interface, InPs can make virtual
resources and partial virtual topologies available to virtual network
provider, which are the customers of the InP. The InP can usually
migrate virtual resource between substrate resources so that the
users of virtual resources are not aware of any change. The actual
mapping from virtual to substrate resources inside the InPs domains
is usually only known by the InP. InPs may have to use a common
interface for setting up virtual links across different InPs.

Virtual Network Provider:
The Virtual Network Provider (VNP) constructs virtual networks using
virtual resources and partial topologies provided by one or more InPs.
The VNP needs a resource control interface to request and configure
these virtual resources offered by the InP who actually owns the
resource. A newly constructed VNet can be made available to a virtual
network operator (or to another VNP, who can recursively use
it to construct an even larger VNet). The VNP performs mainly a broker
role, providing easier access for VNOs to virtual resources spanning
multiple InPs.

Virtual Network Operator:
The Virtual Network Operator (VNO) operates, controls, and manages the
VNet in order to offer services inside the VNet.
Once the VNet has been constructed by a VNP, the VNO is given
"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. This Out-of-VNet access control
interface is required in order to install, reboot, start, stop, shutdown
virtual node etc. from outside the VNet (e.g., if your virtual
node crashed, you must have some knob to restart/revive it).
This also requires to get transparent access to the virtual resources
irrespective of where the resources is currently hosted in the
substrate as the InP may not expose the current location and migrate
the virtual resource "freely". The VNO also controls and manages the
virtual resources from inside the VNet (In-VNet Management).

Service Provider:
A service provider may provide services to end-users by using the
protocols running inside the virtual network. Consider an IP-TV
provider who delivers IP-TV inside the VNet to his customers.
In order to accomplish this, the Service Provider may want to employ
IP multicast for efficient distribution of the streams inside the VNet.
So the VNO may run PIM-DM/SM protocols inside the VNet as required by
the service provider.

We note that some of the roles can actually overlap, e.g.,
VNP and VNO, InP/VNP/VNO and service provider etc.

End-users:
End-users attach to the virtual network and use the communication
services provided by/within the virtual network, i.e., they run a
virtual node that implements the suitable protocol stack.
End-users have usually access to some substrate network and need to
get to a virtual access node via a viable substrate path. This process
of transitioning the real world into the virtual world/net is called
"end-user attachment" and the substrate path can be considered as being
a so-called "virtual last mile link". A typical method to accomplish
this is to create a tunnel across the substrate between the end-user's
device and the VNet access node. Problems that need to be solved here
are for example: how can an end-user find the right virtual access node
for a particular VNet across the substrate? How can mobility and
multi-homing in the substrate be considered, e.g., the virtual link stays
connected. How to consider multi-homing and mobility in the VNet, i.e.,
being attached to multiple VNet access nodes simultaneously or moving
between them?

More detailed text on the scenario and control interfaces
can be found here (open access):
http://journal.ub.tu-berlin.de/eceasst/article/download/225/216

I would propose that we try to create an RG draft that defines
some basic terminology, captures the content of some recent
RG discussions on some related aspects as virtual vs. logical,
layering vs. virtualization, important properties, "acid tests",
and so on and then describes some of the
problems that the RG feels need to be solved. In a next step
we may pick some of the problems and work on them (probably in
parallel).

Regards,
 Roland

---

From: Bhumip Khasnabish <[email-masked]>
Date: Wed, 3 Aug 2011 10:32:34 -0400

Hi Roland,

Thanks.

Do we need to define "Virtual Node" and "Virtual Service" as well?

VNode may contain a variety of virtual resources, and we may need to define
them.

Best.

Bhumip

On Wed, Aug 3, 2011 at 7:54 AM, Roland Bless <[email-masked]> wrote:

> _______________________________________________
> vnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/vnrg
>

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 3 Aug 2011 18:13:19 +0200

Hi,

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:

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

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

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. 

The role definitions provided here below tend to enforce too a client-server strict demarcation between resource owner and non-owner 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).

Thanks,
-dimitri.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Roland Bless
> Sent: Wednesday, August 03, 2011 1:55 PM
> To: [email-masked]
> Subject: [vnrg] Some definitions and way forward
> 
> Hi,
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Aug 2011 09:19:22 -0700

Hi, Roland,

Some of the issues below go well beyond architecture - e.g., operators, 
ISPs, etc.

It might be useful to focus on the arch aspects first.

Also, it'd be useful to understand your view of the relationship of 
these definitions to PPVPNs, VPNs, etc.

Joe (as an individual contributor)

---

From: Roland Bless <[email-masked]>
Date: Wed, 03 Aug 2011 21:53:40 +0200

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

---

From: Roland Bless <[email-masked]>
Date: Wed, 03 Aug 2011 21:55:17 +0200

Hi Bhumip,

On 03.08.2011 16:32, Bhumip Khasnabish wrote:

> VNode may contain a variety of virtual resources, and we may need to
> define them.

Yes, as Dimitri also pointed out, we may need to provide
different examples to make the scope of the terms clearer.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Wed, 03 Aug 2011 22:04:56 +0200

Hi Joe,

> Some of the issues below go well beyond architecture - e.g., operators,

I don't know what you consider as architecture, but we came up with
the roles in order to define an architecture. Some of the roles
definitely imply control interfaces for access virtual resources.
I don't want to discuss any non-technical implications, esp. business
stuff, here, but IMHO one cannot leave the control plane aside.

> It might be useful to focus on the arch aspects first.

Do you consider the data plane aspects as being the architecture?
IMHO the control plane aspects belongs to the architecture as well!

> these definitions to PPVPNs, VPNs, etc.

I have no clear description yet, but VPNs usually are not including
the virtual node aspect. They are mainly about providing/establishing
links to connect to an existing infrastructure and are more a kind of
overlay. I think we need to come  up with a clearer distinction, but
that will need more time.

Regards,
 Roland

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 4 Aug 2011 00:50:41 +0200

Hi Roland, 

> From: Roland Bless [mailto:[email-masked]] 
> Sent: Wednesday, August 03, 2011 9:54 PM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: [email-masked]
> Subject: Re: [vnrg] Some definitions and way forward
> 
> Hi Dimitri,
> 

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 ?

> don't exclude that. 

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.

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 ? 

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

> We also

See above concerning the example. 

> routers in physical networks.

The latter is about the actual use of the virtual network. 

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 think we need to work on that.
>

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

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

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

> an example? 

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.  

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.

> I don't think that any client-server based demarcation
> is implied by the proposed architecture, 

Referring to the definitions you have provided "A service provider may provide services to end-users by using the protocols running inside the virtual network. Consider an IP-TV provider who delivers IP-TV inside the VNet to his customers."

> actually we also considered P2P-based

Thanks,
-dimitri.

---

From: Roland Bless <[email-masked]>
Date: Thu, 04 Aug 2011 10:36:14 +0200

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.

> 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
> 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?

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

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

> 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

---

From: Andreas Fischer <[email-masked]>
Date: Thu, 04 Aug 2011 10:57:02 +0200

Hi Roland, Joe,

>> Also, it'd be useful to understand your view of the relationship
>> of these definitions to PPVPNs, VPNs, etc.
> 
> the virtual node aspect. They are mainly about
> providing/establishing links to connect to an existing infrastructure
> and are more a kind of overlay. I think we need to come  up with a
> clearer distinction, but that will need more time.

Aren't VPNs just one kind of link virtualization? VPNs are basically
tunnels with added encryption, no? Tunnels, on the other hand, just
create a "virtual link" between two arbitrary nodes in a network.

As such, I would also disagree to consider them as kind of an overlay
network, as
a) They don't build a network, only a link (the 'N' in 'VPN' is
misleading, IMHO)
b) They are not necessarily between end hosts (which conflicts your
earlier statement, that overlay nodes are always sitting at the edge of
the network)

Regards,
Andreas

---

From: "SCHARF, Michael" <[email-masked]>
Date: Thu, 4 Aug 2011 11:35:52 +0200

> Aren't VPNs just one kind of link virtualization? VPNs are 
> basically tunnels with added encryption, no? Tunnels, on the 
> other hand, just create a "virtual link" between two 
> arbitrary nodes in a network.

This may be an oversimplification. There are of course many existing
multipoint-to-multipoint VPN technologies that go much beyond link
virtualization. An example is VPLS.

Michael

---

From: Roland Bless <[email-masked]>
Date: Thu, 04 Aug 2011 11:53:13 +0200

Hi Andreas,

> create a "virtual link" between two arbitrary nodes in a network.

Yes, but a tunnel is IMHO an overlay technique:
it is created between the end-points of the underlying layer. Consider
an L3-VPN, consisting of networks N1 and N2 and a "virtual link" between
them.

 /----\                        /----\
|  N1  |--R1==============R4--|      |
|      |  |                |  |  N2  |
 \----/   +-----R2----R3---+   \----/

N1 and N2 are networks that are connected via some provider network.
R1 and R4 are their access routers. The tunnel is established between
the endpoints R1 and R4, i.e., they are source/sink of the outer header
of the tunnel packets and the tunnel is terminated there. R2 and R3 are
not and do not have to be aware of the virtual link in this case.
A non-overlay solution would require awareness in R2/R3, e.g., creating
and LSP.

> a) They don't build a network, only a link (the 'N' in 'VPN' is

Hm, but there are other nodes connected by that tunnel, e.g.,
N1 and N2 may have their own routers etc. Especially, they
have their own addressing scheme and routing inside their
VPN.

> earlier statement, that overlay nodes are always sitting at the edge of

But always between end-points (in an addressing sense, not in a
topological sense) of the underlay/substrate. If one defines a host
as being either source or sink of packets, the term host is also
correct. In the above example, we have R1 and R4 being routers in the
substrate, but from a forwarding perspective, they are end-points
(hosts) for the tunnel. For VPN traffic, the hosts will reside in N1 or
N2.

Regards,
 Roland

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 4 Aug 2011 12:28:42 +0200

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.

> Sent: Thursday, August 04, 2011 10:36 AM

---

From: Andreas Fischer <[email-masked]>
Date: Thu, 04 Aug 2011 12:47:13 +0200

Hi Roland,

On 04.08.2011 11:53, Roland Bless wrote:
>> basically tunnels with added encryption, no? Tunnels, on the other
>> hand, just create a "virtual link" between two arbitrary nodes in a
>> network.
> 
> Yes, but a tunnel is IMHO an overlay technique: it is created between
> the end-points of the underlying layer. Consider an L3-VPN,
> consisting of networks N1 and N2 and a "virtual link" between them.
> 
> /----\                        /----\ |  N1  |--R1==============R4--|
> | |      |  |                |  |  N2  | \----/   +-----R2----R3---+
> \----/
> 
> R1 and R4 are their access routers. The tunnel is established
> between the endpoints R1 and R4, i.e., they are source/sink of the
> outer header of the tunnel packets and the tunnel is terminated
> there. R2 and R3 are not and do not have to be aware of the virtual
> link in this case. A non-overlay solution would require awareness in
> R2/R3, e.g., creating and LSP.

Ok, I think I had a slightly different notion of overlay here. If an
overlay is characterized by being transparent to the substrate (except
for the end-points, of course), then I agree with your point.

>> As such, I would also disagree to consider them as kind of an
>> overlay network, as a) They don't build a network, only a link (the
>> 'N' in 'VPN' is misleading, IMHO)
> 
> Hm, but there are other nodes connected by that tunnel, e.g., N1 and
> N2 may have their own routers etc. Especially, they have their own
> addressing scheme and routing inside their VPN.

Depends. If you consider the conglomerate of N1, R1, R4, and N2 as being
the VPN, then there is actually a network. However, then the 'V' and the
'P' are misleading. This network is - for a large part - not virtual,
but real. Moreover, it is not necessarily private - R1 may possibly only
route certain traffic via the tunnel (e.g. only traffic destined for
N2), whereas the rest may be open to the Internet.

Regarding typical implementations (IPSec, OpenVPN, SSH, ...) I would
consider the VPN in your picture consisting of just the tunnel.
Therefore my argument, that it isn't actually a network, just a link
(apologies to Michael - I did not consider multipoint-to-multipoint VPNs
here).

Regards,
Andreas

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Aug 2011 11:00:18 -0700

Hi, all,

AFAICT:

a tunnel is a way to virtualize a network path at one level (the 
substrate - physical or itself virtual) as a single hop at the virtual level

tunnels may be pt-pt or multipoint; L3 tunnels emulate L2 subnets in a sense

However, a VPN is something different; it's a network that is not 
accessible except via an additional tunnel. The core of a VPN need not 
be virtualized; only the link to a single user or to another VPN is virtual.

That's my view of the difference.

---

From: Roland Bless <[email-masked]>
Date: Thu, 04 Aug 2011 23:06:26 +0200

Hi Dimitri and all,

> 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

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 5 Aug 2011 10:03:23 +0300

Roland and Dimitri

I agree that the definition of Infrastructure Provider is problematic. I
do not think that stating "... an InP may provide many different types
of substrate
resources, e.g., network nodes, links, servers, hosts, storage, etc."
captures the issue yet.

Virtual networks and physical networks (substrate) can be mixed and
matched. A MVNO can have most of its infra as "virtual" but some parts
can be very physical (substrate), say by having its own base stations in
some key areas. Same applies to many enterprise network where parts of
the resources are virtualized and externalized and some are under the
control of the enterprise itself. Such an entity would be both InP and
VNP at the same time. Do we really need to have define InP and VNP at
all as these terms do not add clarity but confusion? 

Best regards
Hannu 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Roland Bless
Sent: Friday, August 05, 2011 12:06 AM
To: Papadimitriou,Dimitri (Dimitri)
Cc: [email-masked]
Subject: Re: [vnrg] Some definitions and way forward

Hi Dimitri and all,

---

From: Roland Bless <[email-masked]>
Date: Fri, 05 Aug 2011 10:12:14 +0200

Hi Hannu,

> resources, e.g., network nodes, links, servers, hosts, storage, etc."

I don't know what particular problem you mean by "the issue".
It is a fact that virtual resources have to be hosted somewhere
down in the substrate. The substrate is controlled by some entity
(the InP) who also has control over the virtual resources, e.g., an
InP can migrate VMs between substrate nodes or increase/reduce the
capacity of virtual resources etc. A VNO performs also control over
the virtual resource but at a different level and not in the same manner
as an InP. How can we describe such scenarios without defining the
entities/roles who are entitled to perform such control/access?
It's pretty normal that a VNet can be composed of virtual (and physical)
resources hosted at different InPs, so considering the role
of an InP does not impose any restrictions on the VNet realization.

> matched. A MVNO can have most of its infra as "virtual" but some parts

Fully agreed.

> all as these terms do not add clarity but confusion? 

I don't see a problem if such entity is performing both roles at the
same time. It makes pretty clear that another InP controls the _virtual_
resources, i.e., the enterprise also depends on this InP, who may be
responsible in case of problems with the virtual resources. The
enterprise needs also some control access to the virtual resources,
no matter where they are actually hosted in the substrate...
Virtual resources are not just hanging in the air, they are realized
on top of virtual or physical substrate resources. As soon as you are
considering control plane issues, different roles matter a lot.

Regards,
 Roland

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 5 Aug 2011 11:31:40 +0300

The "issue" is the definition of the terms you have been discussing on
this mailing list and particularly the first point in Dimitri's mail
dated (04.08.2011 12:28,) summarizing the discussion. It was also quoted
in my mail.

Can you please elaborate what do you mean by "As soon as you
areconsidering control plane issues, different roles matter a lot." For
me the InP and VNP doesn't seem to be that useful other than explaining
a certain, somewhat limited business model.

Regards
Hannu

-----Original Message-----
From: ext Roland Bless [mailto:[email-masked]] 
Sent: Friday, August 05, 2011 11:12 AM
To: Flinck, Hannu (NSN - FI/Espoo)
Cc: [email-masked]
Subject: Re: [vnrg] Some definitions and way forward

Hi Hannu,

Fully agreed.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Fri, 05 Aug 2011 13:04:39 +0200

Hi Hannu,

> a certain, somewhat limited business model.

As already mentioned, it's really not about discussing a business
model, but about controlling virtual and real resources. In order to
do that you need different control interfaces for the various
stakeholders. Let's assume you (as VNO) need to reboot your virtual
router, because it crashed. Then your InP needs to provide access to the
virtual router in order to do that, no matter where it is currently
hosted in the substrate, but probably without exposing the current
mapping of virtual to substrate resources.
As InP you have the mapping information and can easily do this, maybe
using a different control interface. If you have a VNet spanning several
InP domains, you even need to find out first at which InP the virtual
router is currently hosted. This has implications for addressing
virtual resources in the control plane and so on. These are important
control plane aspects, not business model aspects.

Regards,
 Roland

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 6 Aug 2011 13:44:06 +0200

Hi,

> router, because it crashed. Then your InP needs to provide 
> access to the virtual router in order to do that, 

The problem is not the inclusion of "control functionality" into the architectural related definitions but the assignment and distribution of control roles to stakeholders as part of these definitions (cf. VNO, VNP, InP, etc.). At this stage, it is important to define WHAT is to be controlled and not WHO controls what (and the term, e.g., Provider is basically defining the WHO). 

Using my previous example it means that VN, VR* and R* entities have of course associated control function but I didn't indicate who is associated/in charge of controlling the VN, VR*, and R* since it this is not part of the an architectural scope of the definitions we're currently working on. 

Thanks,
-dimitri.

> no matter where it is currently

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 3 Aug 2011 18:07:01 +0200

Hi,

Thanks,
-dimitri.

---

From: Roland Bless <[email-masked]>
Date: Thu, 11 Aug 2011 16:51:29 +0200

Hi Dimitri,

sorry for the late reply, but I was traveling...

> The problem is not the inclusion of "control functionality" into the
> architectural related definitions but the assignment and distribution of
> control roles to stakeholders as part of these definitions (cf. VNO,
> VNP, InP, etc.). At this stage, it is important to define WHAT is to be
> controlled and not WHO controls what (and the term, e.g., Provider is
> basically defining the WHO).

Ok, so far agreed, but IMHO it's difficult to come up with control
interfaces if you are not considering the controlling entity/party,
i.e., the user of this control interface.
Maybe I'll try a second round of definitions without these roles.

Regards,
 Roland