Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt

["Sangjin Jeong" <[e-mail]>]

Dear Martin,

> -----Original Message----- 
> From: "Martin Stiemerling" <[e-mail]> 
> From Date: 2010-06-08 PM 4:54:41 
> To: "[e-mail]" <[e-mail]> 
> 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 
> 
> 
> [e-mail] 
> 
> NEC Laboratories Europe - Network Research Division 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London 
W3 6BL | Registered in England 2832014