Skip to main content

Framework for Data Center (DC) Network Virtualization


(Jari Arkko)

No Objection

(Barry Leiba)
(Brian Haberman)
(Spencer Dawkins)
(Stephen Farrell)

Note: This ballot was opened for revision 07 and is now closed.

Adrian Farrel Former IESG member
Yes (2014-06-11 for -07) Unknown
Thanks for this document. I know it represents a lot of effort.

The document is very clear and a good read. I have just a few minor 
points for you to consider as you progress the document.


Tiny ambiguity...

       Virtual Network (VN): A VN is a logical abstraction of a physical
       network that provides L2 or L3 network services to a set of Tenant

It is the VN or the physical network that provides the L2 or L3 services?


You have...

     The Underlay Network does not need to be aware that
     it is carrying NVO3 packets.

I wondered whether you wanted to make a stronger statement here. We 
usually have a stronger separation of overlay and underlay such that

     The Underlay Network is not aware that it is carrying NVO3 packets.


Possibly "NIC card" is tautology.


Format of Figure 3 is a bit messed up


The use of "seamless" in Section 3.3 seems a bit or an overstatement or
perhaps just under-defined. Given the text that follows, I would just
delete "in a seamless manner" from the first paragraph.
Alia Atlas Former IESG member
(was Discuss, Yes) Yes
Yes (2014-06-11 for -07) Unknown
The WG chair and Shepherd need to show IETF consensus on the draft.
Many of the comments made in IETF last call were addressed and others may
be duplicating what was discussed in the WG - but that needs to be clearly
articulated in the Shepherd's report.

Matthew is updating the Shepherd's report to indicate how the IETF last call
input was considered.
Jari Arkko Former IESG member
Yes (for -07) Unknown

Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2014-07-08) Unknown
Thanks for accommodating my discuss and comment points.
Barry Leiba Former IESG member
No Objection
No Objection (for -07) Unknown

Benoît Claise Former IESG member
No Objection
No Objection (2014-06-12 for -07) Unknown
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 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?


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

       . . . 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.
Brian Haberman Former IESG member
No Objection
No Objection (for -07) Unknown

Joel Jaeggli Former IESG member
No Objection
No Objection (2014-06-12 for -07) Unknown
can you find something other than BUM?
Kathleen Moriarty Former IESG member
(was Discuss) No Objection
No Objection (2014-07-02 for -08) Unknown
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (2014-06-11 for -07) Unknown
Thanks for Section 4.2 and especially 4.2.4 and 4.2.6. Good to have the discussions about the challenges!
Spencer Dawkins Former IESG member
No Objection
No Objection (for -07) Unknown

Stephen Farrell Former IESG member
No Objection
No Objection (for -07) Unknown