We (@Cumulus) are also extremely interested in this topic and would like to join the deep dive. I concur with Lou that the fundamental aspects of BGP/MPLS L3VPNs (RFC 2547bis -> RFC 4364) are pretty well-defined - it is for the most part regular BGP processing with the inclusion of route import/export. Of course, there will be implementation and provisioning choices to make. With BGP/MPLS EVPNs and EVPN/NVO, we would need to consider some refactoring of the code to deal with MACs instead of routes. And the architecture should support other use cases such as what Vincent has mentioned.
Vivek On Tue, Dec 15, 2015 at 2:59 PM, Vincent JARDIN <[email protected]> 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 > > 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 >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
