Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt
"Sangjin Jeong" <sjjeong@etri.re.kr> Thu, 10 June 2010 05:03 UTC
Return-Path: <sjjeong@etri.re.kr>
X-Original-To: vnrg@core3.amsl.com
Delivered-To: vnrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8779E3A69E1 for <vnrg@core3.amsl.com>; Wed, 9 Jun 2010 22:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.251
X-Spam-Level:
X-Spam-Status: No, score=-96.251 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_INFO=1.448, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGvej8GIdDhq for <vnrg@core3.amsl.com>; Wed, 9 Jun 2010 22:03:00 -0700 (PDT)
Received: from email2.etri.info (email2.etri.re.kr [129.254.16.132]) by core3.amsl.com (Postfix) with ESMTP id 2AB9B3A69DF for <vnrg@irtf.org>; Wed, 9 Jun 2010 22:03:00 -0700 (PDT)
Received: from mail pickup service by email2.etri.info with Microsoft SMTPSVC; Thu, 10 Jun 2010 14:03:00 +0900
priority: normal
Thread-Topic: Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt
thread-index: AcsIWjMTufBQps+/Sbeu5QVZxMFr9w==
From: Sangjin Jeong <sjjeong@etri.re.kr>
To: Didier Colle <didier.colle@intec.UGent.be>
Date: Thu, 10 Jun 2010 14:03:00 +0900
Comment: ??, u-??,
Message-ID: <28E476DDE2F74AAE8D9A22A18AC88F79@etri.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3959
X-OriginalArrivalTime: 10 Jun 2010 05:03:00.0936 (UTC) FILETIME=[3334AC80:01CB085A]
Cc: vnrg@irtf.org, Martin.Stiemerling@neclab.eu
Subject: Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt
X-BeenThere: vnrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Sangjin Jeong <sjjeong@etri.re.kr>
List-Id: "Virtual Networks Research Group \(VNRG\) discussion list" <vnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/vnrg>, <mailto:vnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/vnrg>
List-Post: <mailto:vnrg@irtf.org>
List-Help: <mailto:vnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/vnrg>, <mailto:vnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jun 2010 05:03:01 -0000
Dear Didier, > -----Original Message----- > From: "Didier Colle" <didier.colle@intec.UGent.be> > From Date: 2010-06-08 PM 8:19:57 > To: "Martin Stiemerling" <Martin.Stiemerling@neclab.eu> > Cc: "vnrg@irtf.org" <vnrg@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? Agree. I will revise the paragraph. > > > - 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. I think that programmability is not a mandatory for virtual networks, but virtual networks may promote programmability in network elements. However, I agree with you that programmability is important and closely related virtual networks. > > > - 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 I agree with your investigation regarding VN requirements above. I will incorporate your requirement inputs into Section 3. Regards, Sangjin > > 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
- [vnrg] Review of draft-shin-virtualization-meta-a… Martin Stiemerling
- Re: [vnrg] Review of draft-shin-virtualization-me… Didier Colle
- Re: [vnrg] Review of draft-shin-virtualization-me… Krishna Sankar (ksankar)
- [vnrg] way forward on VNRG definitions Joe Touch
- Re: [vnrg] Review of draft-shin-virtualization-me… Sangjin Jeong
- Re: [vnrg] Review of draft-shin-virtualization-me… Sangjin Jeong
- Re: [vnrg] Review of draft-shin-virtualization-me… Sangjin Jeong
- Re: [vnrg] Review of draft-shin-virtualization-me… Martin Stiemerling
- Re: [vnrg] way forward on VNRG definitions Didier Colle
- Re: [vnrg] way forward on VNRG definitions Martin Röhricht
- Re: [vnrg] way forward on VNRG definitions Martin Röhricht
- Re: [vnrg] way forward on VNRG definitions Didier Colle
- Re: [vnrg] way forward on VNRG definitions Joe Touch
- Re: [vnrg] way forward on VNRG definitions Sangjin Jeong