Dear Krishna, Thanks for the comments. I agree with your comments and will incorporate them into the next version of the document. Please see some replies inline. Regards, Sangjin > -----Original Message----- > From: "Krishna Sankar (ksankar)" <ksankar at cisco.com> > From Date: 2010-06-09 AM 1:26:47 > To: "Didier Colle" <didier.colle at intec.UGent.be>, "Martin Stiemerling" > <Martin.Stiemerling at neclab.eu> > Cc: "vnrg at irtf.org" <vnrg at irtf.org> > Subject: Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt > > 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 Ok. I will revise it, but it will be appreciate if you could provide some suggestion. > 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 Ok. I will try to categorize the requirements in the next version. > h) Also at some point we need to look from the > data-control-management planes We also have received similar comments regarding management aspect, so we will investigate it. > Cheers > <k/> > -----Original Message----- > From: vnrg-bounces at irtf.org [mailto:vnrg-bounces at irtf.org] On Behalf Of > Didier Colle > Sent: Tuesday, June 08, 2010 4:20 AM > 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... > > 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, 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. > > > - 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). > > > - 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 > > > - 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 > > > > > > 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 > > > > > > _______________________________________________ > > 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.