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.
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
