Hi, Thomas: Thank for your clarification to this VM mobility issue. I thought that is the issue we can potentially talked about although we have no idea Whether this issue is workable. But I agree this issue may add a lot of complexity to the network when we think to introduce some new functionalities to tackle it.
I am okay to take it out unless we have more concrete proposal to fix this. Thanks for taking my comments into account. I would like to see your update to incorporate The improving text you proposed in this thread. Regards! -Qin -----Original Message----- From: Thomas Narten [mailto:[email protected]] Sent: Thursday, April 18, 2013 8:41 PM To: Qin Wu Cc: Eric Gray; [email protected] Subject: Re: [nvo3] 答复: 答复: Comments on draft-ietf-nvo3-overlay-problem-statement Hi Qin. > Your proposed text improve a lot since it deal with both communication > between two VN but also communication between one VN and one > Non-VN, using general term "gateway" makes sense to me. > Regarding my added text, what I am trying to say if we need to > consider VM movement between two VNs (i.e.,VM mobility case), IMO, no. My assumption is that the basic model we have is that a VM is associated with one VN (** but see below). Movement from one VN to another is not really part of the model. Movement from one VN to another raises a bunch of questions, including, perhaps whether a change in IP address of the VM is needed. Unless someone can make a compelling argument for this case (i.e., what the use case and semantics are), I just see it as adding complexity without value. **note: a VM can be associated with more than one VM, but then it has multiple interfaces, each connected to one VN. But then, movemment from one VN to another implies that one interface is first associated with VNA and then with VNB, which then falls back to the same case as a VM having only one interface and one VN connection. Thomas _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
