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

From: "Sangjin Jeong" <[email-masked]>
Date: Thu, 10 Jun 2010 12:53:06 +0900

Dear Martin,

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

---

From: "Sangjin Jeong" <[email-masked]>
Date: Thu, 10 Jun 2010 14:03:00 +0900

Dear Didier,

> From: "Didier Colle" <[email-masked]> 
> From Date: 2010-06-08 PM 8:19:57 
> To: "Martin Stiemerling" <[email-masked]> 
> Cc: "[email-masked]" <[email-masked]> 
> Subject: Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt 
>  
> Dear Martin, all, 
> 
> My two cents in this discussion. 
> 
> Martin Stiemerling wrote: 
> 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.

> 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.

> 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). 
> 
> 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 
> > I personally do not yet see this document to be the RG problem statement > 
virtual routers

---

From: "Sangjin Jeong" <[email-masked]>
Date: Thu, 10 Jun 2010 14:38:08 +0900

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
 
> From: "Krishna Sankar (ksankar)" <[email-masked]> 
> From Date: 2010-06-09 AM 1:26:47 
> To: "Didier Colle" <[email-masked]>, "Martin Stiemerling" > 
<[email-masked]> 
> 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/> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Didier Colle 
> Sent: Tuesday, June 08, 2010 4:20 AM 
> To: Martin Stiemerling 
> Cc: [email-masked] 
> > - Section 2: First para: de-ossification may be one motivation but is 
> in IMHO not the motiviation. 
> > - 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: 
> > - 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. 
> > 
> > - 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 
> > 
> > 
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
> London W3 6BL | Registered in England 2832014 
> > 
> > 
> > _______________________________________________ 
> > vnrg mailing list 
> > [email-masked] 
> > 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: [email-masked] 
> MSN: [email-masked] 
> Skype: didiercolle 
> Tel. +32 9 331 4970 
> Fax. +32 9 331 4899 
> Mobile: +32 473 295655 
> WWW: www.ibcn.intec.UGent.be