Hi Robert, From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Wednesday, February 05, 2014 5:29 PM To: Lucy yong Cc: [email protected]; L3VPN Subject: Re: WG Last Call for draft-ietf-l3vpn-end-system
Hi Lucy, I would like to see some explanation how the solution supports VM mobility, which is the key requirement in network virtualization in DC, also how to support the end system mobility where the system is a laptop or smart phone. I think you need to be a bit more specific on your definition of VM mobility ... cold or hot ? Same IP/different IP, with keeping the sessions (TCP) state or not. [Lucy] here is the text from the requirement section in the doc. IP Mobility requires the ability to "move" a device without disrupting its TCP (or UDP) transport sessions. These sessions often deploy second or sub-second keepalives to detect application failure. Experience with failure restoration in Service Provider networks shows that fast-failure restoration often requires the pre- provisioning of a restoration path. IP Mobility can be a result of devices physically moving (e.g., a WiFi enabled laptop) or workload being diverted between physical systems such as network appliances or application servers. -end I like to see hot move, no IP address change, without session restart. VM mobility actually from tentat virtualization is an easy part and works as far as bgp/xmpp withdraw message can propagate. Notice that in the VRF you can have backup entries (corresponding to your new VM) which can be preinstalled and activated later. [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. If VPN forwarder is on the end system, i.e. server, the server may have two physically ports connects to TOR switches. Does GRE tunnel use one port or both ports, how end system should implement this? Notice that host is an L3 device. So each such port would be part of a different L3 path to BGP NH. It can nicely load balance across many parallel links to TOR. [Lucy] what do you mean L3 device? The host does not participate in underlay IGP. VPN forwarder can build a tunnel using host IP address, how that be routed or load balanced over these links to TOR, I think that the draft should describe them as the solution. If VPN forwarder is on external device, the end system (server) may have two physical ports as well. Could virtual network interfaces on the end system attach to two external VPN forwarder or just one. I see no problem to attach to N of them. Moreover just like in distributed systems not all of them need to keep all VPN routes and optimization is possible for "selective download feature" - analogy from selective download from local RP to linecards. [Lucy] I don't see that has an issue, but think that some description is necessary because these are often use cases. In BGP IP VPN [RFC4364], routing and forwarding are coupled; Route Target defines the routing and forwarding topology. When separating them into Route Server and VPN forwarder and one Route Server with many VPN forwarders, which topology that Route Target define? Only symmetric configuration is intuitive to me. 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? Thanks, Lucy Cheers, R. Wish to see some descriptions on these areas. I am not against this solution but think it needs more work. Regards, Lucy -----Original Message----- From: L3VPN [mailto:[email protected]<mailto:[email protected]>] On Behalf Of [email protected]<mailto:[email protected]> Sent: Friday, January 31, 2014 9:01 AM To: L3VPN Subject: WG Last Call for draft-ietf-l3vpn-end-system Hello working group, This email starts a Working Group Last Call on draft-ietf-l3vpn-end-system, which is considered mature and ready for a working group review. Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than **February 15th**. Thank you, -Thomas & Martin [ http://tools.ietf.org/html/draft-ietf-l3vpn-end-system ] _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
