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

["Martin Stiemerling" <Martin.Stiemerling at neclab.eu>]

Hi Didier, 

> -----Original Message-----
> From: vnrg-bounces at irtf.org [mailto:vnrg-bounces at irtf.org] On Behalf Of
> Didier Colle
> Sent: Tuesday, June 08, 2010 1:20 PM
> To: Martin Stiemerling
> Cc: vnrg at irtf.org
> Subject: Re: [vnrg] Review of draft-shin-virtualization-meta-arch-
> 01.txt
> 
> Dear Martin, all,
> 
> My two cents in this discussion.
> 
> Martin Stiemerling wrote:
> > [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.
> >
> 
> 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...

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.

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

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

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

No idea. 

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

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

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

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

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

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


martin.stiemerling at neclab.eu

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