Ryan, I'll be traveling around the time of the L3 meeting this week. My flight leaves 40 minutes after the meeting and I might have trouble attending. It might be best to put it off a week or to plan another time -- maybe Friday -- when we could discuss it in IRC or in a Hangout.
Carl On Mon, Dec 8, 2014 at 8:43 AM, Ryan Clevenger <ryan.cleven...@rackspace.com> wrote: > Thanks for getting back Carl. I think we may be able to make this weeks > meeting. Jason Kölker is the engineer doing all of the lifting on this side. > Let me get with him to review what you all have so far and check our > availability. > > ________________________________________ > > Ryan Clevenger > Manager, Cloud Engineering - US > m: 678.548.7261 > e: ryan.cleven...@rackspace.com > > ________________________________ > From: Carl Baldwin [c...@ecbaldwin.net] > Sent: Sunday, December 07, 2014 4:04 PM > To: OpenStack Development Mailing List > Subject: Re: [openstack-dev] [Neutron] [RFC] Floating IP idea solicitation > and collaboration > > Ryan, > > I have been working with the L3 sub team in this direction. Progress has > been slow because of other priorities but we have made some. I have written > a blueprint detailing some changes needed to the code to enable the > flexibility to one day run glaring ups on an l3 routed network . Jaime > has been working on one that integrates ryu (or other speakers) with neutron > . Dvr was also a step in this direction. > > I'd like to invite you to the l3 weekly meeting  to discuss further. I'm > very happy to see interest in this area and have someone new to collaborate. > > Carl > >  https://review.openstack.org/#/c/88619/ >  https://review.openstack.org/#/c/125401/ >  https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam > > On Dec 3, 2014 4:04 PM, "Ryan Clevenger" <ryan.cleven...@rackspace.com> > wrote: >> >> Hi, >> >> At Rackspace, we have a need to create a higher level networking service >> primarily for the purpose of creating a Floating IP solution in our >> environment. The current solutions for Floating IPs, being tied to plugin >> implementations, does not meet our needs at scale for the following reasons: >> >> 1. Limited endpoint H/A mainly targeting failover only and not >> multi-active endpoints, >> 2. Lack of noisy neighbor and DDOS mitigation, >> 3. IP fragmentation (with cells, public connectivity is terminated inside >> each cell leading to fragmentation and IP stranding when cell CPU/Memory use >> doesn't line up with allocated IP blocks. Abstracting public connectivity >> away from nova installations allows for much more efficient use of those >> precious IPv4 blocks). >> 4. Diversity in transit (multiple encapsulation and transit types on a per >> floating ip basis). >> >> We realize that network infrastructures are often unique and such a >> solution would likely diverge from provider to provider. However, we would >> love to collaborate with the community to see if such a project could be >> built that would meet the needs of providers at scale. We believe that, at >> its core, this solution would boil down to terminating north<->south traffic >> temporarily at a massively horizontally scalable centralized core and then >> encapsulating traffic east<->west to a specific host based on the >> association setup via the current L3 router's extension's 'floatingips' >> resource. >> >> Our current idea, involves using Open vSwitch for header rewriting and >> tunnel encapsulation combined with a set of Ryu applications for management: >> >> https://i.imgur.com/bivSdcC.png >> >> The Ryu application uses Ryu's BGP support to announce up to the Public >> Routing layer individual floating ips (/32's or /128's) which are then >> summarized and announced to the rest of the datacenter. If a particular >> floating ip is experiencing unusually large traffic (DDOS, slashdot effect, >> etc.), the Ryu application could change the announcements up to the Public >> layer to shift that traffic to dedicated hosts setup for that purpose. It >> also announces a single /32 "Tunnel Endpoint" ip downstream to the TunnelNet >> Routing system which provides transit to and from the cells and their >> hypervisors. Since traffic from either direction can then end up on any of >> the FLIP hosts, a simple flow table to modify the MAC and IP in either the >> SRC or DST fields (depending on traffic direction) allows the system to be >> completely stateless. We have proven this out (with static routing and >> flows) to work reliably in a small lab setup. >> >> On the hypervisor side, we currently plumb networks into separate OVS >> bridges. Another Ryu application would control the bridge that handles >> overlay networking to selectively divert traffic destined for the default >> gateway up to the FLIP NAT systems, taking into account any configured >> logical routing and local L2 traffic to pass out into the existing overlay >> fabric undisturbed. >> >> Adding in support for L2VPN EVPN >> (https://tools.ietf.org/html/draft-ietf-l2vpn-evpn-11) and L2VPN EVPN >> Overlay (https://tools.ietf.org/html/draft-sd-l2vpn-evpn-overlay-03) to the >> Ryu BGP speaker will allow the hypervisor side Ryu application to advertise >> up to the FLIP system reachability information to take into account VM >> failover, live-migrate, and supported encapsulation types. We believe that >> decoupling the tunnel endpoint discovery from the control plane >> (Nova/Neutron) will provide for a more robust solution as well as allow for >> use outside of openstack if desired. >> >> ________________________________________ >> >> Ryan Clevenger >> Manager, Cloud Engineering - US >> m: 678.548.7261 >> e: ryan.cleven...@rackspace.com >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStackemail@example.com >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev