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
