Hi Robert On Wed, Sep 19, 2012 at 8:33 AM, Robert Raszuk <[email protected]> wrote: > Hi Patrick, > > >> is BGP the best alternative as the control plane mechanism? > > I am not sure if it is the best, but clearly it is the one used widest > today. And since data centers are not operating in vacuum it does make sense > to use the same "signalling" mechanism as the rest of the networks are using > for tenant isolation.
Somewhat true, it depends on the DC. Many enterprise DC and hosting providers DC are disconnected from the WAN - the ISP offers the WAN connections and the DC uses a different "signalling mechanism for their network, such as STP ;.) Not that many uses MPLS inside their DCs, a few though. Also the WAN network and DC network are usually in different management domains. > > >> What NVO3 is trying to achieve is to setup and remove tunnels between >> NVEs when VM/TES are added/moved on the NVEs. So what we really need >> is "tunnel initiation protocol", right? > > > Wrong. Tunneling has gone about 10 years ago in the industry. What it > evolved to is encapsulation. > > The significant difference is that you need to provide only sufficient > information about encap header in order to make your application work .. > this is opposed to establish any end to end state (what typically tunnel > initiation protocols do). > > Getting this subtle difference is the key to success. > But the liveness detection of the path must be handled somehow by the encapsulation scheme, right? If that is the case, should that be taking care of the network or the endpoints? By locating the NVE as far at the edge the tunneling scheme will scale quite well depending on how many VMs you are allocating per NVE (x86 platform) - 10, 50, 100? > >> I believe that a SIP architecture is closer to that than BGP, which is >> basically a routing protocol. > > > While I respect your believes years of deployment and operational experience > with BGP based L3VPNs and L2VPNs indicate at least to me otherwise. Maybe I > am biased but I have never head of service providers using SIP to provide > VPNs for their customers. > > My background is also from BGP/LDP based L3VPN and L2VPN and I have some experience with SIP, trying to think out of the box >> The NVE would be something similar as a SIP UA. When a VM/TES gets >> added at the NVE the NVE sends an INVITE to the "conference group" >> (the CUG) with its local members (MAC addresses) to the SIP signalling >> system. > > > While we could discuss details the NVE tenant will participate in many > "conference groups". Those "groups" represent not only CUGs but also wide > range of evolving services which will be real value add to the DC providers. > > I am of the pretty strong opinion that revenue from network plumbing be it > open pipe or VPN is over. The value add is in flexibility of service > integration .. service being anything from appliance to big data/large job > on demand processing. I do not see how SIP would help there. > Agree. SIP would only keep track of where the VMs are located. Turning this around, what new services would a BGP based L3VPN and L2VPN offer in the DC? We have been on this path for the last 10-15 years on the WAN side and some experience with a few DCs. > >> Thus it would interesting to visit an SIP >> architecture to see what it can offer as an NVO3 control plane >> solution before rushing into a BGP. > > > As said above I am not sure the "rushing" is right term. If you look at your > requirements from operators point of view we have customers interconnected > with L3 or L2 VPNs. Adding seamless DC to their services is a very important > service. > Which operators do you refer to - enterprises, ISP, telcos, cloud, hosting providers? > SIP would be detached from reality and while it may even work in it's own > juice I am afraid it would have zero chance for wide industry adoption in > the data VPN space. Maybe, but at least worth to have a discussion about. Patrick > > Best regards, > R. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
