Please see inline….

From: Lucy yong []
Sent: Friday, September 16, 2016 8:38 PM
To: Olufemi Komolafe <>; Bocci, Matthew (Nokia - GB) 
<>; NVO3 <>
Subject: RE: WG last call for draft-ietf-nvo3-use-case-09

Hi Femi,

Thank you for the comment. Please see inline below.

From: nvo3 [] On Behalf Of Olufemi Komolafe
Sent: Thursday, September 15, 2016 5:18 AM
To: Bocci, Matthew (Nokia - GB); NVO3
Subject: Re: [nvo3] WG last call for draft-ietf-nvo3-use-case-09

I think the draft is OK but I’ve got a few comments below:

Section 1: Why are these the  use cases considered?   I think a better 
justification of why these use cases are considered representative or even 
significant will enhance the draft.
[Lucy] Section 1 is introduction that highlight NVO3 motivation and its enabled 
applications. The rest of sections describes some use cases and justification.
[Femi]:  Yeah, I understand your point but I was wondering if you can state why 
you picked these particular use cases and scenarios.   i.e. do you consider 
these to be the most likely use cases?  Or the most complex/interesting use 
cases?  If so, why?

Section 3.1: Perhaps add a better definition of vGW
[Lucy] ack. Will do in next version.
[Femi]: OK.

Section 4: Is this statement 100% accurate: "Operators no longer need to worry 
about the constraints of the DC physical network configuration when creating 
VMs and configuring a virtual network."?
[Lucy] This is a goal at least. When DC service provider offers IaaS to 
customers and allows a customer to create its own cloud on DC service provider 
infrastructure, DC provider zero touch provisioning is the goal,  and no DC 
physical network configuration change is a “MUST” to achieve this goal.
[Femi]: Fair enough.

Section 4.1: This section is potentially very interesting and perhaps should be 
fleshed out some more; some of the issues arising from interworking between 
different technologies are interesting and perhaps worthy of further 
discussion.  However, there are some suggestions that some DCs are highly 
homogenised in terms of deployed hardware and technology so perhaps also 
mention this possibility?
[Lucy] What would you like to add here?
[Femi]: Perhaps expand the discussion  on the VXLAN/NVGRE/VLAN interworking 
example to highlight some of the issues/benefits when different NVO3 overlays 
are used within the same DC?  And state how likely you think such use cases are 
likely to be?

Section 4:3: "DC Provider operators"? In fact, draft uses both "DC provider" or 
"DC operator" throughout.  Is there a difference?  If so, perhaps state the 
difference.  If not, perhaps pick one and use it consistently in the draft?
[Lucy] Thanks to point out this. DC Provider means that a company offers cloud 
services to consumers. DC operators are roles who are responsible to construct 
and manage cloud service instances in their life-cycle and manage the 
infrastructure for running these applications . One is from consumer 
perspective, another is from DC and service operation perspective. Any service 
provider company has these two aspects: easy for customer to get a service and 
easy for operator to manage the service. Make a sense? If yes, I will make it 
clear in next version.
[Femi]: Makes sense; thanks for clarifying.




From: nvo3 [] On Behalf Of Bocci, Matthew (Nokia - 
Sent: Tuesday, September 06, 2016 11:14 AM
To: NVO3 <<>>
Subject: [nvo3] WG last call for draft-ietf-nvo3-use-case-09

This email begins a two week working group last call for 

Please review the draft and post any comments to the NVO3 working group list.

If you have read the latest version of the draft but have no comments and 
believe it is ready for publication as an Informational RFC, please also 
indicate so to the WG email list.

This working group last call will close on Tuesday 20th September 2016.

Best regards

Matthew and Sam
nvo3 mailing list

Reply via email to