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

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 12 Jan 2016 17:49:14 -0800

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) ...".

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.

   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.

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?

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.

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?

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.

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.

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.

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.