Hi Lucy, I like to see hot move, no IP address change, without session restart. >
Fine, but this is not draft in question which should describe details how you mirror TCP state across VMs. That's a biggest challenge AFAIK not the routing to VM side which this draft is about. That works seamless both via presence of multiple paths in the system as well as via possible in VRF lookup if needed. *[Lucy] Having a section to describe how it works is very helpful. I don't > see these described in the doc. Current BGP IP VPN has an issue to support > VM mobility. If this solution is to use of BGP IP VPN, it is necessary to > clarify how it solves the issue.* > I am not aware about such issues. Let's not forget that VM addresses are not summarized within DC hence you have extremely fast convergence in milliseconds. *[Lucy] what do you mean L3 device? The host does not participate in > underlay IGP. * > It does not need to. Loadbalancing across two or N intercaces does not require IGP. It works fine with default routes. I see no such tights. Each VPN forwarder can express set of VPNs it is > responsible for and only subset of interesting routes will be distributed > to it. As deployed example RTC can be used or it's analogy encoded in XMPP. > > *[Lucy] Sorry, I don't get it. Do you mean that the forwarder use RTC to > express interesting routes? In your deployed case, do you have hub-spoke > scenarios? If yes, could you elaborate your scenarios? * > > > Forwarder can surely use RTC or control node can be "told" by orchestration layer which routes are required by which hosts. Cheers, R.
