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
