Subject: Re: [nvo3] comments on draft-ietf-nvo3-arch-04

From: "Black, David" <[email-masked]>
Date: Mon, 7 Mar 2016 03:27:44 +0000

Anoop,

Thanks for the suggestions - comments inline ...

Thanks, --David

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Tuesday, January 12, 2016 8:49 PM
To: [email-masked]
Subject: [nvo3] comments on draft-ietf-nvo3-arch-04

Here are my comments (really suggestions) for the NVO3 architecture doc.

Anoop

==

Global comments
- A separate section for list of acronyms would be useful.
- Throughout the document, there are statements of the form "the nvo3 architecture must support ...".  This is the architecture document which is specifying the architecture.  To me, it seems like these statements should say "the nvo3 architecture supports (or allows) ...".

David> Agree on the latter change, not sure about acronym list.

Section 3
   Tenant Systems connected to a
   virtual network typically communicate freely with other Tenant
   Systems on the same VN, but communication between Tenant Systems on
   one VN and those external to the VN (whether on another VN or
   connected to the Internet) is carefully controlled and governed by
   policy.

In light of the work in the SFC WG, I don't think this is necessarily true.  You can have policies that control communication even within a VN.

David> And the description of those policies belongs in an SFC draft, not here ;-).  The important point is that nvo3 imposes no such restrictions.  We’ll try to
David> rephrase to make that clearer, but SFC policy belongs over in the SFC WG ...

   any L2 destination

   addresses provided by Tenant Systems are effectively ignored.  For L3

   service, the Tenant System will be configured with an IP subnet that

   is effectively a point-to-point link, i.e., having only the Tenant

   System and a next-hop router address on it.

I don't think the statement about L2 addresses being ignored is correct.  L2 addresses would be correctly set to get the packet from the VM to the NVE, it's just that they NVE would remove the MAC header and thereafter a new MAC header is not put on the frame until it gets to the destination NVE.

David> This is for L3 service - the first point at which nvo3 enters the picture is the NVE which removes the original L2 destination address.  We could change that
David> to “... are effectively ignored by the NVEs and overlay network.

Section 3.2

Is there a 1:1 mapping between VAP and VNI?  That's what Fig 2 appears to show (and what the text says).  How are multiple VLANs on a TSI/NIC handled?

David> I would map the VAP and VNI 1:1 and use multiple pairs thereof if the VLANs get mapped to separate virtual networks.

Section 3.3

While flooding works, it can lead to traffic hot spots and can lead to problems in larger networks.

Would be good to elaborate what kinds of problems.

David> Would adding something like “(e.g., excessive amounts of flooded traffic)” to the end of the sentence suffice?

Section 3.4

Both can pass

   information about what virtual networks a VM connects to down to the

   hypervisor.

Should this say "All three" rather than both?

David> I see ... “Each” is probably better than “All three” here.

Section 4.2.1

In the

   split-NVE case, however, the VLAN tag used between the hypervisor and

   offloaded portions of the NVE normally only identify the specific VN

   that traffic belongs to.  In order to allow a tenant to preserve VLAN

   information in the split-NVE case, additional mechanisms would be

   needed.

It's not clear to me what the problem is and why additional mechanisms are needed.  Clarify if possible.

David> Trying to use one VLAN tag to do two things, as described in the quoted text.  Please suggest alternative text if that’s not clear.

Section 4.3

Bullet 3 - suggest a reference to the multicast framework draft.  Also what is referred to as "serial multicast" in this draft (there are multiple instances, not just this section) is called "replication at the source NVE" in the multicast draft.  It would good to align the terminology.

David> Sure, makes sense.  Reference to multicast framework draft would be informative, not normative.

Section 8.3

   While the NVA could push information about every virtual network to

   every NVE, such an approach scales poorly and is unnecessary.  In

   practice, a given NVE will only need and want to know about VNs to

   which it is attached.
This statement needs some work in light of distributed gateway.  Information about VNs not directly attached is very much needed, as long as routing to them is permitted.

David> Ah, the problem is the word “about” - Would use of “relevant to” instead of “about” in the second sentence fix the problem.

Section 9, Figure 3

What is more likely having local GWs, i.e. 2 IP-Gs, one in each NV domain, rather than a single IP-G sitting in the middle.  The IP-Gs would communicate using regular VPN methods such as BGP E-VPN.

David> It’s an example, and a single IP-G is considerably easier to explain than a VPN interconnect, especially as VPNs can also be used to NV extend domains
David> in addition to providing gateway functionality between them