Subject: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 8 Jun 2010 09:54:41 +0200

[writing as individual RG member and not as chair]

Dear all,

Here is a brief review of draft-shin-virtualization-meta-arch-01.txt.

- Section 1, 1st paragraph: this describes abstraction but not virtualization.
- Section 1, page 3, bullet list: how does this related to VNs?
- Section 1.1: too narrow for VN and it mixes VNs with programmable networks.

- Section 2: First para: de-ossification may be one motivation but is in IMHO not the motiviation. 
- Section 2: VNs are not necessarily programmable networks. 

- Section 3: The requirements are too high-level. It would be good to get more detailed requirements and where (from what system) these requirements are.
- Section 4: It's too high-level. A good use case would describe a VN use case and the resulting challenges and requirements

I personally do not yet see this document to be the RG problem statement draft at this point of time. 

The draft misses some important points:
- what are some use cases you have in mind (system and what it does)
  - e.g., testbed virtualization, operator-scale, Internet-scale, etc?
- what components are you using
- how do these components interact
- what about the existing work, e.g., VPNs, L2 link bundling technologies, virtual routers
- what are the problems?

In general: I do not yet see that this draft is really a problem statement. It makes a start and its worth keep working on it, but needs more thoughts and discussions.

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Didier Colle <[email-masked]>
Date: Tue, 08 Jun 2010 13:19:57 +0200

Dear Martin, all,

My two cents in this discussion.

> - Section 1, 1st paragraph: this describes abstraction but not virtualization.

Would you then say that abstraction is a key tool to realizing 
virtualization?
And what would then be definition of "virtualization"? E.g., creating 
"virtual things/instances"? To my feeling, "virtualization" means 
creating "virtual things" by "abstracting away the real things 
(infrastructure)".
Hmm... this might become a pretty "artificial" discussion...

Although I tend to agree with the text that virtualization bottom-line 
always boils down to abstraction of the physical infrastructure, I 
disagree with the statement in the text: "... or end users can interact 
with those resources WITHOUT THE KNOWLEDGE OF THE PHYSICAL CHARACTERISTICS."
* For example, in an IP/WDM scenario the overlaid IP network(s) is(/are) 
virtual networks but still the IP routing protocols running in 
this(/these) virtual IP networks needs to be aware of possible SRLGs. 
Thus "without knowledge" does not seem correct to me, "with limited 
ABSTRACTED knowledge" seems more appropriate to me.
* Is this compliant with the statement in section 1.1 "When combined 
with programmability feature in network elements, USERS of virtual 
networks CAN PROGRAM the network elements on any layers FROM PHYSICAL 
LAYER to application layer according to users' requirements." How do you 
program the physical layer WITHOUT KNOWING ANYTHING about that physical 
layer?

> - Section 1.1: too narrow for VN and it mixes VNs with programmable networks.

Euh... well, to me programmability is a key requirement for virtual 
networks. Perhaps programmability should not be mixed in section 1.1, 
but to my understanding it is missing from the requirements section 3.

> - Section 2: VNs are not necessarily programmable networks. 

Again I would not exclude programmability from the requirements.
When having a Software-Defined Radio infrastructure, it should be 
possible to create SDR virtual network instances.
When having an infrastructure based on NetFPGA-alike hardware, it should 
be possible to create FPGA-programmable virtual network instances (e.g., 
part of the FPGA footprint).

> - Section 3: The requirements are too high-level. It would be good to get more detailed requirements and where (from what system) these requirements are.

Some thoughts:
* A system managing the virtual instances is needed.
* The infrastructure should provide a standardized interface/api to such 
system.
* An interface between that mgmt system and the user: giving user 
ABSTRACTED info on capabilities of the infrastructure over which he 
wants to create a virtual instance (e.g., is it programmable, or do you 
have only a limited number of combinations of "lego bricks"?) 
Information on the config/mgmt interface of the virtual network 
(element) instance(s), ... information on the subset of resources that 
were assigned to a virtual network instance (e.g., a virtual network 
instance might have been assigned a certain set of VLAN-IDs that he only 
he can use)
* Enforcement of isolation
* Enforcement of performance guarantees

Kind regards,

Didier

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

-- 
Didier Colle
Ghent University - IMEC - IBBT
Department of Information Technology (INTEC)
Gaston Crommenlaan 8 bus 201, B-9050 Gent (Ledeberg)
Email: [email-masked]
MSN: [email-masked]
Skype: didiercolle
Tel. +32 9 331 4970
Fax. +32 9 331 4899
Mobile: +32 473 295655
WWW: www.ibcn.intec.UGent.be

---

From: "Krishna Sankar (ksankar)" <[email-masked]>
Date: Tue, 8 Jun 2010 09:26:47 -0700

Good points.

a)	I think if we delete the first sentence "Conventionally ...
characteristics." It would read better. The second sentence is a
succinct description of the virtualization domain, as it stands now.
b)	Virtualization provides abstraction rather than hiding. And in
some cases, it provides direct path to the underlying hardware as well
(for performance and other reasons)
c)	I think programmability is orthogonal to virtualization. IMHO,
virtualization should be dealing with declarative constructs which then
are provisioned and configured by the underlying network.
d)	Yep, second paragraph in section 1.1 is a little mixed. If
programmability needs to be addressed, it should be a new section with
appropriate details.
e)	In section 2, elasticity should be mentioned and described. The
last paragraph touches upon it. But need a little more elaboration
f)	In section 3, SLAs and limits are mentioned, but distributed
across couple of bullet points. Would be good to aggregate them
g)	Would like to see the virtualization requirements be described
on a layered scale of
orchestration-automation-provisioning-configuration - that way we can
separate appropriate paradigms at the right context for example
programmability from abstraction
h)	Also at some point we need to look from the
data-control-management planes  
Cheers
<k/>
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Didier Colle
Sent: Tuesday, June 08, 2010 4:20 AM
To: Martin Stiemerling
Cc: [email-masked]
Subject: Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt

Dear Martin, all,

with those resources WITHOUT THE KNOWLEDGE OF THE PHYSICAL
CHARACTERISTICS."

> - Section 3: The requirements are too high-level. It would be good to
get more detailed requirements and where (from what system) these
requirements are.

Some thoughts:

system.

he can use)

Kind regards,

Didier

> - Section 4: It's too high-level. A good use case would describe a VN
use case and the resulting challenges and requirements
> In general: I do not yet see that this draft is really a problem
statement. It makes a start and its worth keep working on it, but needs
more thoughts and discussions.
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jun 2010 09:57:51 -0700

Hi, all,

(speaking as co-chair)

One of the challenges with starting with full text ("prose") is a tendency to
edit the text, to focus on what to change, rather than on either what's missing,
or shifts in perspective that would require substantial revision.

To avoid that, Martin and I propose that we begin by each providing definitions
and perspectives, rather than all try to wordsmith any single suggestion.

As a starting point, we would like to have everyone on the list answer the
following questions. We would prefer short text rather than full paragraphs
extracted from any I-D or other document.

Please DO NOT merely edit the posts of others. Once we see where people stand in
their own voice, we can decide how best to move forward.

Please send your responses by Jun 30 if possible.

Joe (as VNRG co-chair)

-----------------------------------------------------

Starting questions:

1. how do you define VNs?

	1.a. what are the key components?

	1.b. what is the relationship between these components?

	1.c. what is the characteristic behavior/capability of the
	resulting system?

2. what are VNs used for?

3. what are they key challenges?

for each challenge:
	- define the challenge
	- explain why it is hard
	- provide some references to those working on solutions

-----

---

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 17 Jun 2010 10:28:24 +0200

Hi Didier, 

> Sent: Tuesday, June 08, 2010 1:20 PM
> To: Martin Stiemerling
> Cc: [email-masked]

Well, abstraction is one element of the virtualization but the text reads whether this is the single element. Another key element is, for instance, aggregation is also an important property.

> ABSTRACTED knowledge" seems more appropriate to me.

I see the "without knowledge" a feature we would like to achieve, but it
might be a theoretical feature. 

> program the physical layer WITHOUT KNOWING ANYTHING about that physical

No idea. 

> but to my understanding it is missing from the requirements section 3.

Probably, somebody should come up with what this "programmability"
should be - before going down that road. 

> part of the FPGA footprint).

See above, as the understanding of programmability is very different
in the community. 

> * Enforcement of performance guarantees

Give it a try and write it up in a draft, but more important contribute to
the  call on VNRG definitions (Joe's email of June 8). 

Thanks,

  Martin

---

From: Didier Colle <[email-masked]>
Date: Fri, 18 Jun 2010 11:12:11 +0200

Third trial in a week... now after having been whitelisted on mail.ietf.org
In case other might have similar problems (no response on Joe's request 
is in the mailinglist archive), it might be a solution to request to 
whilelist you too.

My apologies in case you receive this message a second time... I have
the impression the first trial didn't get through, therefore second trial...

****************************************************

Dear Joe, all,

> 1. how do you define VNs?

A virtual network:
* is a ... that appears to be a NETWORK
* but is VIRTUAL in the sense that it does not necessary correspond 1:1
to a physical network.

> 	1.a. what are the key components?

Hmm...
Answer 1 (= narrow): key components of a VN itself? All key components
of the network that it is emulating.
Answer 2 (= broad):
i) Infrastructure:
      ia) Bare substrate (e.g., hardware... but substrate could be a VN
itself).
      ib) Adaptation layer (cfr. MMU when speaking about virtual memory
could compare to the thing that realizes the per-VPN VRF instances in
BGP/MPLS VPNs).
ii) Mgmt system: responsible for life-cycle mgmt of the VN instances
iii) VN instances
      iiia) VN data/forwarding plane: VN nodes and VN links
      iiib) VN control/mgmt plane: not necessary located in the VN nodes
(e.g., PCE)
iv) VN instance external interfaces
      iva) VN end-systems (e.g., (virtual) servers, (virtual) clients,
...) [not sure whether to in-/exclude them]
      ivb) including in particular VN gateways
v) VN instance operator

> 	1.b. what is the relationship between these components?

notation:
<---> 1:1 relationship
<--*> 1:N relationship
<-*-> 1:1 relationship inside VN instance
<-**> 1:N relation ship inside VN instance

relationships:
ib <--*> ia: 1:N relationship to allow many substrates forming a large
scale VN instance
ii <---> ib: VN instance life-cycle mgmt
ib <--*> iii
iiia <-*-> iiib: control/mgmt of VN instance.
iiia <-**> iva (and also iiib <--*> iva: thinking about DHCP, AAA, ...)
iiia <-**> ivb
iiib <-**> ivb: e.g., discovery/notification protocol in order to
populate a gateway between a IPv4 VN instance and IPv6 VN instance
v <-*-> iiib: access to control/mgmt of VN instance (could be in-band in
iiia, but this is not necessary).
ii <--*> v: VN instance operator requesting life-cycle mgmt actions of
its own VN isntance, billing of VN instance operator/owner for having
the VN instance operational, ...

> 	1.c. what is the characteristic behavior/capability of the

not sure what to answer here.

> 2. what are VNs used for?

* gain from economy of scale effects: many VN instances over huge
substrate --> low cost per VN instance
* creating large-scale networks: combining many smaller hardware
substrates into a single huge VN instance
* separation of concerns: split between infrastructure operator (compare
to operator of train tracks) vs. network operator/service provider
(compare to train operator owning the trains themselves).
* reducing complexity: separate VN instances at the lowest possible
layer. Everything inside the VN instances can be implemented much more
straightforward, requiring dealing less with different
situations/conditions/traffic streams/...
* increasing flexibility/modularity: instead of trying a one fits all
solution, move as much as possible specialization to the VN instances
(ok, here we need again the programmability that is orthogonal to the
virtualization, otherwise the infrastructure still needs to provide all
possible lego-bricks) --> flexibility/modularity probably means faster
time to market.
* better interoperability/portability: by having a standardized
(low-level) ib<--*>iii interface and moving as much as possible
specialization to the VN instances, standardization requirements in the
substrate ia can be reduced facilitating operating heterogeneous
substrate boxes (cfr. the JavaVM on linux or other OS enables running
the same code on both machines).

> 3. what are they key challenges?

* performance due to the intermediate adaptation layer (cfr. ib above).
* VN instance isolation
* accountability: in case of problems: is the VN/VN operator or
infra/infra operator responsible for any issue that may occur.
* reporting information / access to parts of substrate by the VN
instances (thus over interface ib<--*>iii): cfr. the example of SRLG
that needs to be made available to the VN instances.

Have a nice weekend,

Didier

Joe Touch wrote:
> ------------------------------------------------------------------------
>

---

From: Martin Röhricht <[email-masked]>
Date: Wed, 30 Jun 2010 16:10:53 +0200

Dear Joe,

> extracted from any I-D or other document.

A VN is a network that appears to its users as an ordinary network by
providing ordinary interfaces and services but which is actually
decoupled from the physical substrate.

> 	1.a. what are the key components?

Virtual nodes, virtual links, management entities

> 	1.b. what is the relationship between these components?

An arbitrary number of virtual links may be spanned between an arbitrary
number of virtual nodes.  A physical node may be equipped with multiple
virtual nodes.  Virtual links are controlled by management entities
residing on physical nodes and acting as mediators between pyhsical and
virtual nodes.

> 	1.c. what is the characteristic behavior/capability of the

The resulting virtual network provides its users the illusion of using a
dedicated (physical) network with a set of guaranteed resources.  It
should provide its services isolated from other virtual or physical
networks that actually run on the same hardware.  Network management
operations should be performed transparent for the network's users, e.g.
by migrating nodes or links in the physical substrate.

> 2. what are VNs used for?

VNs may be used to provide a dedicated network for its users which
operates isolated from any other network traffic.  They may be used to
bring out completely new network architectures and protocols.  They may
be used to optimize resource utilization either via aggregating or via
distributing resources used for a virtual network.

> 	- provide some references to those working on solutions

- Instantiation of virtual nodes and virtual links.  How can we a
 priori determine whether a virtual node exists or is actively running?
- Inter-domain-wide operation across multiple administrative domains.
 Comparable to the issues in QoS research we may be able to easily
 provide dedicated services to users within our domain, but providing
 these services inter-domain-wide may have some technical or business
 constraints.
- Dynamic and on-demand instantiation of virtual networks.  Instead of
 using a manual or semi-manual (e.g. script-based) configuration of
 virtual networks, it may be desirable to use signaling protocols for a
 dynamic and on-demand management of virtual networks.
- Network topologies. Talking about virtual networks, we may wish to
 not only control some virtual nodes and virtual links, but also create
 virtual network topologies, such as full-meshed networks, rings,
 trees, etc.
- Attachment of end-users---are they part of the virtual network? How
 do we cope with the mobility of end-users, again inter-domain-wide?
- Aggregation---to what level can we aggregate traffic by still
 preserving isolation and by not losing flexibility to migrate virtual
 nodes and virtual links to another location?
- Security---how can security be achieved?  Is it an integrated part of
the virtual network architecture and transparent to its users?
- AAA---using virtual network resources breaks down to actually using
 physical resources of one or more network operators.  How do we
 provide authentication, authorization, and accountability?  How do we
 provide these AAA services inter-domain-wide?
- Are Quality-of-Service guarantees an inherent requirement for virtual
 networks? If yes, to what extent?
- Providing the users the opportunity to create completely new network
 architectures and protocols inside their virtual networks---how do we
 cope with interoperability?  Or do we run the risk of creating an
 »inverse Internet«?

That's it for now.

Martin