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