Framework for Data Center (DC) Network Virtualization
draft-ietf-nvo3-framework-09

Thanks for accommodating my discuss and comment points.

This is combined feedback from the OPS DIR review (Thanks Al Morton) and my own review. I like the document and in particular section 4 about "Key aspects of overlay networks"

- Thanks for section 2.4. Operational Management Considerations, but I share Al Morton's views (OPS-DIR review) on this section

...
       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. 
Maybe I expect too much from this document and this is/will be covered in draft-ashwood-nvo3-oam-requirements?

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


  

EDITORIAL: -
       ... to provide similar functions to a ToR.

       ...

       Another example is the case where the
       End Device is the Tenant System, and the NVE function can be
       implemented by the connected ToR
   
       ...

ToR => ToR switch
There are multiple instances of this.

- Having figure 3 and section 3 would help readability.

- Some more comments, more editorial, from Al Morton

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.

can you find something other than BUM?

Thank you for addressing my prior discusses, the security section provides a much better overview now and will hopefully help subsequent drafts from NVO3.  I appreciate the effort that went into these edits.

Now addressed:
1. The Security Considerations section hint around the risk of breaking the intended isolation of tenants without ever stating that possibility in the first few sections that describe securing NVEs, NVAs, and management systems.  The risks should be explained so that the reader, including developers and implementers, understand that breaking the designed tenant isolation is possible when security requirements and considerations are not met (or there are weaknesses/flaws in software).  This may help to further motivate implementation of security requirements.

2. The framework describes both overlay and underlay networks.  When responding to Alissa's discuss, I would like like to see the text address when encryption is needed with the associated risks for the overlay and underlay networks as well, the answers may be different for each.  The security considerations section goes back and forth between the two right now without always calling out which it is referring to and this would be helpful.  This is also the case for the unauthorized access descriptions in the security considerations section.  I'm adding this as a second discuss to make sure we can work through some text to add and these considerations are included as I think they will be helpful to address what each means for both overlay and underlay networks (management/control data and tenant data).

Not yet addressed:
For Alissa's comment, it would be good to include the reference intended in the draft for opportunistic encryption to avoid confusion.

Thanks for Section 4.2 and especially 4.2.4 and 4.2.6. Good to have the discussions about the challenges!