Dear Martin, > -----Original Message----- > From: "Martin Stiemerling" <Martin.Stiemerling at neclab.eu> > From Date: 2010-06-08 PM 4:54:41 > To: "vnrg at irtf.org" <vnrg at irtf.org> > Cc: > Subject: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt > > [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. The second sentence describes virtualization and the first sentence is more focused on abstraction point of view among virtualization characteristics. we will refine the first paragraph. > - Section 1, page 3, bullet list: how does this related to VNs? The 3 bullets are general benefits of virtualization, so I think that it is possible to obtain those benefits by using VNs. For example, it may increase utilization of network elements by partitioning (or creating VNs). > - Section 1.1: too narrow for VN and it mixes VNs with programmable > networks. The first paragraph is the definition of VN and the second paragraph is a explanatory part of VN's concept, difference with traditional non-virtualized network, applicability, etc. Then, would you think that Section 1.1 should describe definition of VN only? > > - Section 2: First para: de-ossification may be one motivation but is in > IMHO not the motiviation. Ok. we will revise it. > - Section 2: VNs are not necessarily programmable networks. The Section 2 does not mandate that programmability is as a requirement for VNs. Our intention is that VN can be helpful for realizing programmability. We will revise the paragraph if it causes confusion. > > - 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. Good point. The requirements in Section 3 seem to be design goals or high level requirements rather than detailed requirements. However, in order to identify the detailed requirements, it would be necessary to investigate (functional) components of VN and maybe need to reach RG consensus. I am not sure whether the investigation work is within the scope of PS or solution spaces. > - 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? Again, I am not sure if all the issues above should be handled in the problem statement document. > > 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. Thanks for your review. We will keep revising the document based on comments received. Regards, Sangjin > > 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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.