Re: [vnrg] Some definitions and way forward

["Papadimitriou, Dimitri (Dimitri)" <[e-mail]>]

Hi Roland, 

> -----Original Message-----
> From: Roland Bless [mailto:[e-mail]] 
> Sent: Wednesday, August 03, 2011 9:54 PM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: [e-mail]
> Subject: Re: [vnrg] Some definitions and way forward
> 
> 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.

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 ?

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

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

See above concerning the example. 

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

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

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

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

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

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

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

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
> self-organized access structures for controlling the virtual 
> resources...
>
> Thanks for your input, that was exactly what I was looking for,
> i.e., collecting different viewpoints in order to complete the
> big picture.

Thanks,
-dimitri.
 
> Regards,
>  Roland
> 
>