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. 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. 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. 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. 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. 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]] On Behalf Of > [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. > >
