Vincent On 12/15/2015 5:59 PM, Vincent JARDIN wrote: > If I can add on top of that, a big user of this support will be Openstack: > https://wiki.openstack.org/wiki/Neutron/MPLSVPNaaS > and > https://github.com/openstack/networking-bgpvpn
Do you have any of the L3VPN BGP changes yet? I'd like to see if we have any / how much overlap in code that is to be upstream-ed... Thanks, Lou > let's deep dive after season holidays. > > best regards, > Vincent > > On 15/12/2015 23:33, Lou Berger wrote: >> Hi Paul, >> Do you have any thoughts on how you'd like to have this discussion? >> >> Some detailed responses below. >> >> On 12/15/2015 10:34 AM, Paul Jakma wrote: >>> Hi, >>> >>> I'd like to figure out what the right architecture is to support VPN >>> routing. I'm not terribly interested in them myself, but it seems they're >>> not going away and there are various people interested in adding things in >>> this area. >>> >>> I'd like to try pin down which VPN routing technologies are of interest, >>> and what the requirements and commonalities are. It'd be good to be learn >>> from ospfd/ospf6d and ripd/ripngd, and try do a bit better. >>> >>> VPN routing, to my mind, mostly is about mapping some set of information >>> to a routing context, potentially in some series, to retrieve routing >>> information[1]. E.g. perhaps some kind of interface ID to some context >>> identifier to index into the final prefix-trie. >> I/we think both routing and NVO3/NVA overlay control are of interest. >> >>> * Which VPN routing technologies are people interested in? (L3VPN) >> Also, since you ask I/we care about: >> 1) BGP controlled v4 and v6 L3VPNs, RFCs: 4760, 4360, 4364, 4659, 5512, >> 5566 RFC4364,4659 >> (and have code in various stages of readiness for upstreaming, and >> have >> previously posted the core set of these changes here.) >> 2) BGP controlled EVPNs >> (we have a non-standard EVPN-inspired implementation, and expect >> will have >> lots of discussion on this, once the core/base VPN discussions take >> place.) >> >>> * What kind of relations and lookups do we need, in terms of what kind of >>> identifiers (ifindices? VRF IDs? RDs? etc..)? >> yes, interfaces (physical and logical), RDs and RTs. >>> * At which places do you want to exchange routing information? >> A very good / interesting discussion. This goes to the discussion on >> list at the end of last month. It's important to not forget all the >> features that may be needed during import/export, in particular >> filtering/route maps. >> >>> I think it'd be really good to get all these details down in one place, so >>> we can figure out what commonalities there are, and avoid having set after >>> set of "similar but different" bits of code going in here and there. >>> >>> We sometimes pay a heavy cost down the road for the want of relatively >>> small amounts of up-front work. >>> >>> 1. In an ideal world, we'd just prepend these things to each other and put >>> them into the address label and put that information in the packet. Then >>> routing lookup could be a lot more straight-forward and regular. But, hey >>> 32-bits is enough for everyone... >>> >>> regards, >> Thanks for getting the discussion started, >> Lou >> >> >> >> _______________________________________________ >> Quagga-dev mailing list >> [email protected] >> https://lists.quagga.net/mailman/listinfo/quagga-dev >> > _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
