Hi Zu. OK, I see where you are coming from now.
> [Zu Qiang] I see three alternatives which are all described in the > draft > [http://tools.ietf.org/html/draft-zu-nov3-security-requirements-01] > A) If either the NVA is collocated with the VM Orchestration > Systems, or there is an interface between the VM Orchestration > Systems and NVA, it can be assumed that the NVA may learn the VN > connection / disconnection and vNIC association / disassociation > from the VM Orchestration Systems. Then the NVA configures the > attached NVE with the VN context of the connected / disconnected VN > and the associated / disassociated vNIC addresses. The next step is > that the NVA updates the inner-outer address mapping table of the VN > at both the attached NVE and all the participating remote NVEs. > B) The attached NVE is informed by the hypervisor using the > Hypervisor-NVE protocol at VN connection / disconnection and vNIC > association / disassociation. Then the attached NVE notifies the NVA > with the received VN updating information. The next step is that the > NVA updates the inner-outer address mapping table of the VN at both > the attached NVE and all the participating remote NVEs. > C) It is also possible to use a NVE-NVE control plane protocol to > update the peer NVEs' inner-outer address mapping table timely at VN > connection / disconnection or vNIC association / > disassociation. However, this approach may require the NVE-NVE > control plane packets to be flooded to all NVEs when no mapping > exists. C) is another possible approach. In some sense, this is a highly distributed NVA where the NVEs are really part of the NVA. I.e., NVEs are talking directly to other NVEs to obtain and exchange information, rather than relying on an NVA. In this model, I think we lose a clean separation between NVEs and NVAs, since NVEs are implementing NVA functionality. While I agree this is one model, I don't think we should put it in the architecture unless the WG decides it wants to support such a model. Remember, the goal of the architecture document is not to show all possible alternatives, but to show the one NVO3 will support. That said, another possible interaction model has NVEs sending information to other NVEs that one might consider part of the control plane, such as an egress NVE responding with a "target VM not here" or "target VM has moved to NVE XXX", etc. Such messages could be treated as authoritative, in which case they are accepted as updates. Or, they could be treated as hints to go check with the NVA for updated information. The two approaches have very different trust assumptions. Note that draft-sridharan-virtualization-nvgre-ext-00.txt defines UNREACHABLE and REDIRECT messages between NVEs. As a strawman for discussion, I'd suggest that the architecture: 1) Support messages between NVEs that provide hints that an NVE has stale information and should go back to the NVA for updated/authoritative information. and 2) That the architecture does not merge NVE/NVA functionality in such a way that the NVE effectively is part of the NVA. Thoughts? Thomas _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
