Hello, Larry
Now I'm little bit confused. In the draft it is specified that "A protocol is needed to provide this inner to outer mapping and VN Context to each NVE that requires it and keep the mapping updated in a timely manner." Does it mean the NVE shall accept the configuration protocol received from the NVA unconditional? What is the configuration contains an error, e.g. a duplicated address which the NVE cannot perform the mapping updates? Shall we allow the NVE to reject the configuration message with an error code as response? My proposal is not to turn the NVA into some kind of syslog server. It is just to complete the protocol. It would be good to define the response message for the NVA configuration message. So the NVA will know that the NVE has been configured properly. Of cause, in the error case, the NVA can report it to a management entity so a human can decide if something bad is happening or not. Have a nice day Zu Qiang From: Larry Kreeger (kreeger) [mailto:[email protected]] Sent: Monday, October 21, 2013 1:55 AM To: Zu Qiang Cc: [email protected]; [email protected] Subject: Re: Error notification [draft-ietf-nvo3-nve-nva-cp-req-00] Hi Zu, Are you saying that duplicate address detection should be a mandatory requirement for an overlay solution? I'm not sure if it should be. While I agree that it may be possible for NVEs to detect duplicate addresses, at the end you wrote "As discussed above, the misconfiguration of the TS address can be detected. And the NVE(s) shall notify the NVA when the error is detected. Therefore, a protocol is needed to allow the NVE to report the detected address misconfiguration to the NVA." I'm not sure if the NVA is the correct place for a duplicate address detection to be reported. It seems like it would be better for this to be reported to a management entity so a human can decide if something bad is happening or not. I would hate to turn the NVA into some kind of syslog server...and if we decide it should be, why not just use syslog? - Larry From: Zu Qiang <[email protected]<mailto:[email protected]>> Date: Tuesday, September 17, 2013 6:47 AM To: Larry Kreeger <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Error notification [draft-ietf-nvo3-nve-nva-cp-req-00] Hello, Larry and all We had discussion on the duplicated address issue under [draft-kreeger-nvo3-hypervisor-nve-cp] discussion. It may be good to have some text in this draft [draft-ietf-nvo3-nve-nva-cp-req] for the case that an error is detected and the NVE shall report it to the NVA. The following is my proposal: There are possibilities that two TSs of a given VN have been misconfigured with the same address by the VM orchestration system. If the two TSs have been located in the same hypervisor, the hypervisor is supposed to detect this error and report it to the orchestration. It should not send the VNIC association to the attached NVE. If the two TSs have been located in the different hypervisors under the same NVE, the hypervisors may not be able to detect this error. Therefore the VNIC association notifies will be sent to the attached NVE. When the NVE receives the VNIC association notify, it shall verify the received info with the VNIC address association list of the VN context. If the same VNIC address association is found, the misconfiguration can be detected. If the two TSs have been located in the different hypervisors under the different NVEs, the hypervisors may not be able to detect this error. Therefore the VNIC association notifies will be sent to the attached NVEs. - In this case, the attached NVE will receive the VNIC association notify from the hypervisor, which the VNIC address association list of the VN will be configured. At the same time an inner-outer address mapping configuration message will be received from the NVA which the inner address will be the same as the address received in the VNIC association notify, which means the misconfiguration can be detected. - The not attached NVE will receive two instances of the inner-outer address mapping, which the inner address are same and the outer address are different, which means the misconfiguration can be detected. In VM migration case, it is possible to have the VNIC disassociation at the old location after the VNIC association at the new location. A timer based solution may be needed to avoid triggering the error handling too quick. As discussed above, the misconfiguration of the TS address can be detected. And the NVE(s) shall notify the NVA when the error is detected. Therefore, a protocol is needed to allow the NVE to report the detected address misconfiguration to the NVA. Have a nice day Zu Qiang ______________________________________________________________________________________________________________________ * 4.4: is the timer solution good enough for the case of address misconfiguration? How the NVE knows there is an address misconfiguration or it is VM mobility? LK> The timer is just a way to implement the optimization of not notifying the NVA when a VM moves and we don't have a pre-associate to tell us directly. It is related to VNIC migration, and not related to address configuration. I'm not sure what you are referring to. [Zu Qiang] there may be the case that two VMs under different NVEs are configured with the same address by mistake. In this case, the NVA may receive the VM connections notifications from both NVEs. The notification may not be received at same time. How should the NVA knows this is a VM mobility or a misconfiguration? Do we need a procedure to cover that case? LK2> I see. If a duplicate address is configured by mistake, then there is no good way to know which VM has the correct address. I'm not sure if we can guarantee that a migration event will always be communicated to the NVE, nor whether a disconnect will aways come before a connect, so it may be difficult to detect the difference between a new VM coming up and a migration. We plan to merge in some content from draft-kompella-nvo3-server2nve-02, so maybe we can address this issue as part of that. [Zu Qiang] I think this is an issue which shall be covered in NVO3. I can provide some text on this if it is ok for you.
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
