Subject: RE: WG Last Call for draft-ietf-l3vpn-end-system

From: Lucy yong <[email-masked]>
Date: Wed, 5 Feb 2014 22:44:07 +0000

I had some comments on this draft while ago. 
http://www.ietf.org/mail-archive/web/l3vpn/current/msg03820.html

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.

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?  

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. 

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. 

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 6 Feb 2014 00:29:03 +0100

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.

> 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.

---

From: Lucy yong <[email-masked]>
Date: Thu, 6 Feb 2014 02:54:27 +0000

Hi Robert,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, February 05, 2014 5:29 PM
To: Lucy yong
Cc: [email-masked]; L3VPN
Subject: Re: WG Last Call for draft-ietf-l3vpn-end-system

Hi Lucy,

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.

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.

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.

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.

Regards,
Lucy

-----Original Message-----
From: L3VPN [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, January 31, 2014 9:01 AM
To: L3VPN
Subject: WG Last Call for draft-ietf-l3vpn-end-system
Hello working group,

Thank you,

-Thomas & Martin

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 5 Feb 2014 23:28:47 -0800

Lucy,

On Feb 5, 2014, at 6:54 PM, Lucy yong <[email-masked]> wrote:
> [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.

What do you believe is the issue ? I am not aware of any issue to support VM mobility. In fact it seems to work quite well.
Current BGP IP VPN supports advertising route changes Those route advertisement changes can happen in milliseconds. VM (hot) mobility in deployments that implement this document is constrained by storage bandwidth. The network route advertisement is a couple of orders of magnitude faster than VM state save and restore.

> 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?  

GRE is an IP protocol. Is your question how an end-system with two interfaces sends IP packets ?

> 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?

Most existing L3VPN PEs have a routing engine and multiple separate forwarding engines (aka line cards). This document does not change the behavior of the routing component. It documents how the VRF table calculated by the Route Server (i.e. the routing engine in a standard PE) is transmitted to the forwarding component.

The Routing and forwarding tables are not separated.

I don't believe that the document is ambigous about the behavior of a conforming implementation. It seems to me that you are looking more for tutorial level information which is not the intent of an IETF standard.  

  Pedro.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 6 Feb 2014 10:49:17 +0100

Hi Lucy,

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.

> 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.