Third trial in a week... now after having been whitelisted on mail.ietf.orgIn 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 vnrg at irtf.org 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: didier.colle at intec.UGent.be MSN: didiercolle at hotmail.com Skype: didiercolle Tel. +32 9 331 4970 Fax. +32 9 331 4899 Mobile: +32 473 295655 WWW: www.ibcn.intec.UGent.be
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.