Re: [vnrg] comments on draft-shin-virtualization-meta-arch-01

"Sangjin Jeong" <sjjeong@etri.re.kr> Tue, 04 May 2010 07:43 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 455BD3A6892 for <vnrg@core3.amsl.com>; Tue, 4 May 2010 00:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.251
X-Spam-Level:
X-Spam-Status: No, score=-98.251 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, HELO_MISMATCH_INFO=1.448, 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 bpHSaEzKE6h3 for <vnrg@core3.amsl.com>; Tue, 4 May 2010 00:43:21 -0700 (PDT)
Received: from email2.etri.info (email2.etri.re.kr [129.254.16.132]) by core3.amsl.com (Postfix) with ESMTP id 52D653A6882 for <vnrg@irtf.org>; Tue, 4 May 2010 00:43:20 -0700 (PDT)
Received: from mail pickup service by email2.etri.info with Microsoft SMTPSVC; Tue, 4 May 2010 16:43:04 +0900
Priority: normal
Thread-Topic: [vnrg] comments on draft-shin-virtualization-meta-arch-01
thread-index: AcrrXW4RMMAtniXhRjafecphK3pmzg==
From: Sangjin Jeong <sjjeong@etri.re.kr>
To: WashamFan <Washam.Fan@huaweisymantec.com>
Date: Tue, 04 May 2010 16:43:04 +0900
Comment: ??, u-??,
Message-ID: <F7820E1ECDD54DACA0F39C0E0E7528A8@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: 04 May 2010 07:43:04.0754 (UTC) FILETIME=[6E3E4120:01CAEB5D]
Cc: vnrg@irtf.org
Subject: Re: [vnrg] comments on draft-shin-virtualization-meta-arch-01
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: Tue, 04 May 2010 07:43:22 -0000

Hello Washam,
 
Thanks for your comments.
See inline, please.
 
Regards,
Sangjin

> -----Original Message----- 
> From: "WashamFan" <Washam.Fan@huaweisymantec.com> 
> From Date: 2010-04-30 PM 4:43:38 
> To: "vnrg@irtf.org" <vnrg@irtf.org> 
> Cc: 
> Subject: [vnrg] comments on draft-shin-virtualization-meta-arch-01 
> 
> 
> 

> Hi, 
> 
> I review this doc and have some comments as below: 
> 
> 1. In section 1, I think the order of benefits of server virtualization 
> should be intuitively corresponded to the order of benefits of  
> virtualization described earlier. So, I'd like switch the second bullet 
> and the third for benefits of server virtualization 

Ok. I will change the order.

> 
> for the third bullet for benifits of virtualization, I don't know how 
> the term 'Encapsulation' related to described easier deployment 
> and provision benefits. In your ppt presented in IETF77, you use 
> 'abstraction' instead. 

As described in the third bullet, by abstracting the underlying 
hardware characteristics and by providing virtual hardwares that 
have standard interfaces, users may be able to easily utilize the 
virtual hardwares. Those virtual hardwares may be provided by 
encapsulating the physical hardware. But, abstraction may be 
better term for this perspective.  
Also, there are small inconsistency in the terminology used 
throughout the document, so I will fix it in the next version.

> 
> 2. In section 3, I don't know all the requirements are applied 
> to isolation VNs or aggregation VNs or both? It might hard to 
> distinguish these 2 types. E.g., we deployed 3 VNs on top of 
> the existing infrastructure in my department, when we consolidate 
> computing resources from another department with my department, 
> the 3 VNs could be expanded as well. The isolation and aggregation 
> VNs co-exist. 

The requirements described in Section 3 are general requirements for 
network virtualization, not specific to isolation VNs or aggregation VNs.
Thus, some or all requirements may be applicable depending on 
the use cases, IMHO. 

> 
> 3. In section 4, you gave us an example where different service providers 
> use different VNs, what if users want to use services provided by 
> different providers, should they join different VNs (explicitly or implicitly)? 

I think that this is a federation issue. If a service provider allows use of 
its resources to the users of other service providers, the users will be 
able to join VNs owned by the service provider. Explicit or implicit join will 
be dependent on the federation methods among service providers.

> 
> Thanks, 
> washam 
> _______________________________________________ 
> vnrg mailing list 
> vnrg@irtf.org 
> https://www.irtf.org/mailman/listinfo/vnrg