Last Call Review of draft-ietf-nvo3-framework-06
review-ietf-nvo3-framework-06-opsdir-lc-morton-2014-06-06-00

OPS-DIR review of 
draft-ietf-nvo3-framework-06.txt

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
operational area directors.  Document editors and WG chairs should
treat these comments just like any other last call comments.

These are comments from a reader previously un-involved with
nvo3 work, and should be taken in that light.

Al

This document supports future development of a Network Virtualization
Overlay with IP network underlay, NVO3, by describing the reference 
model and logical components of such a datacenter network with multiple
tenants. Technical issues are raised in some detail, and as a result
the nvo3 problem statement is augmented by the framework's sections
that identify issues, such as the "Operational Management 
Considerations" section and the forward references given there. 

Although I don't request a change in terminology, I found the term
"underlay" to be distracting as a non-indoctrinated reader. Further,
Figure 3 doesn't identify the underlay network, but it depicts the
L3 Network (IP underlay) above the "Overlay" network and therefore
the figure is drawn upside-down. I think "foundation" would be a 
more easily understood term for some readers, but the Figure should
identify the underlay network and be re-drawn for clarity, at least.

Perhaps some of the difficulty with the underlay network concept is
the alternate reference to either IP networks or L3 networks/
technologies:

       . . . In the case 
       of NVO3, the underlay network is IP.
...
       Underlay nodes utilize L3 technologies to interconnect NVE nodes. 
       These nodes perform forwarding based on outer L3 header information, 

It's hard to maintain clarity with numbered-layers in the face of 
overlays, underlays, tunneling, VPNs (but here L* is embedded in the 
names), etc., but can't solve the whole problem here.

Specific comments:
    2.4. Operational Management Considerations 
...
       As far as the IP underlay is concerned, existing IP OAM facilities 
       are used.  
So, a clear mapping between overlay and underlay addresses is needed
by the person or entity directing OAM activities, right? It appears
section 3.1.5.3 discusses this to some degree. Section 3.3 on VM
Mobility adds to the complexity of performing meaningful OAM. 

. . .
       As far as configuration is concerned, the DC environment is driven 
       by the need to bring new services up rapidly and is typically very 
       dynamic specifically in the context of virtualized services. It is 
       therefore critical to automate the configuration of NVO3 services. 
This last sentence sounds like a requirement, but automation does not
appear to be addressed very extensively in the draft, 
except that VNI values are automatically generated by the egress NVE,
and there are a few others.

   4.1. Pros & Cons 
The Cons and other issues raised in section 4 are potential
pitfalls for operations, and this could be noted.

In particular, sections 4.2.5 and 4.2.6 point to difficulties 
of VM placement and the lack of interaction between network layers
when coordination is needed in critical areas.
For example, with many specific examples provided in the previous
sections, how do the authors recommend to provision bandwidth in
the IP network for each, ideally performance-isolated, VNI?