Anoop, Thanks for the suggestions - comments inline ...
Thanks, --David From: nvo3 [mailto:[email protected]] On Behalf Of Anoop Ghanwani Sent: Tuesday, January 12, 2016 8:49 PM To: [email protected] 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
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
