Re: [vnrg] way forward on VNRG definitions

[Didier Colle <[e-mail]>]

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

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

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


Joe Touch wrote:
> 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
>
> -----
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> vnrg mailing list
> [e-mail]
> 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: [e-mail]
MSN: [e-mail]
Skype: didiercolle
Tel. [phone]
Fax. [phone]
Mobile: [phone]
WWW: www.ibcn.intec.UGent.be