Subject: [nvo3] Comments on draft-kompella-nvo3-server2nve-00

From: "Guyingjie (Yingjie)" <[email-masked]>
Date: Wed, 26 Sep 2012 08:16:50 +0000

Hi authors,
This is a very good draft which gives good overview of the possible processing between server and NVE . I read draft-kompella-nvo3-server2nve-00 month ago and finally have time to write down my comments in this email.
There are some editorial error, e.g. lack of PA steps description but cite PA.x at some place. But these are not essential problems and easy to revise. People can understand by reading through the draft.  I will list some technical comments or questions one by one in below.

Section 1
C1: Step 5: "informing the network element(s)...... the VM's peer VMs". IMHO, I don't think it's always true to forecast the peer VMs that a VM is going to communicate. In most cases, the peer VMs can be a group of VMs. The VM may communicate with any or some of peer VMs. but it shouldn't be supposed to communicate with all of them. And VM could also communicate with external users or VMs in different VN. So it's not effective to provision peer VMs at the very beginning of VM provisioning. To replace provisioning peer VMs, I do think the idea of provision VM's VNID and VN policies is better, which is also introduced in later part of your draft.

C2: Step 6: "informing the network element(s) to which a VM's peer VMs are connected about the new VM and its addresses" Similar reason as C1. And I will give more reasons on this part in future comments. There are other processing description in the draft that are closely related to Step 6.

C3: "In Step 5 the lNVE discover relevant rNVE elements and the addresses of their VMs" This introduces a very interesting question: shall lNVE be aware of all the rNVE at the very beginning? VM Mobility is considered in NVO3 charter and problem statement, which means the rNVE list could be dynamic. At the time that VM is established, rNVE list could be NVE1,2&3. But maybe after a very short time, NVE3 is excluded from the list of rNVE, because all VMs, belonging to the VN, are moved away. But this question is not an isolated one, it depends on the way of control the WG finally choose. If the WG finally decide to do configuration of VN from authority entity to NVE, then the provisioning of rNVE to lNVE is a reasonable work of authority entity(other name as ORACLE or controller). If WG decides to use a Multicast based VN discovery on NVE, then it's not necessary.

C4: "In Step 6, the rNVE discover the presence and addresses of the new VM" What's the utility for rNVE to learn new VM's address, if rNVE's local VM never communicate with the new VM? rNVE only needs to know the address of lNVE by some way.

Section 2
C5: "For each VM operation, a subset of the following information is needed from server to lNVE: ...... VID" VID is used for differentiate DCVPN traffic between server and NVE, and should be local significant to NVE. So it should be something assigned by lNVE, and response from lNVE to server, instead of from server to lNVE. When VM migrated to server connecting with another NVE, the VID should be re-assigned by the new NVE. But according to A.2, I assume that your intention is that VID can be assigned in pre-associate step and is carried in associate message. Then it's reasonable and should be indicated as optional.

C6: "Table type" I am not sure what's the intention of provisioning table type from server to NVE, could you please give some examples?

C7: I think Authentication is an important part of future work, since people don't think Hypervisor is reliable.

C8: "A.5" I am suspect of address distribution, it occupies too much space, because lNVE and rNVE need to learn all VM addresses in the VN, no matter it needs to communicate or not. A.5 also says "to get the addresses of other VMs in the DCVPN" , this will introduce duplicated address distribution because lNVE needs to get remote VMs addresses every time it has a new VM connecting.

C9: "The dissociate message contains the operation, authentication, VNID, table type, and VM addresses" Table type is not needed here, coz NVE can find the table by VM addresses.

C10: "D.3" VID should not be set to unassigned, if there is still other VMs belong to the VN and connecting through port P. VID is released only when there is no VM belonging to <VNID, P>.

C11:<M.3> I have written another email for VM migration. http://www.ietf.org/mail-archive/web/nvo3/current/msg01387.html

Again, this is a useful draft. Just my 2 cents.

________________________________
Best Regards
Gu Yingjie