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
