On Thu, 17 Dec 2015, Vivek Venkatraman wrote:
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
Well, if 4364 is "well-defined", then I was hoping for something
"extra-well-defined". E.g. 4364 states:
" How does a PE determine which Route Target attributes to associate
with a given route? There are a number of different possible ways.
The PE might be configured to associate all routes that lead to a
specified site with a specified Route Target. Or the PE might be
configured to associate certain routes leading to a specified site
with one Route Target, and certain with another."
I could be wrong but that seems to deliberately leave things unspecified.
Basically, in generally we have a routing system that attaches IDs to
network-scopes:
scope-id:[sub-id...]:node-id
The scope being some VPN, the RD in VPNv4? Sub-IDs potentially being the
afi/safis, depending on what the node-id is.
And MPLS/VPN seems additionally to have some odd kind of
manually-configured routing-information group-casting thing in the
route-targets (I don't see any protocol defined to handle managing these,
so it seems all quite manual - in which case, yowser).
Things that might be needed:
- some way to relate incoming packets to scopes. So does something in
Quagga (zebra?) need to support looking up RDs based on some local
attribute (interface?).
interface to VRF to RD? Is VRF:RD a 1:1 relationship in both directions?
- on receiving a route, some operation to choose which scopes it may apply
to.
This could just be using the RD to look up the right set of tables. Or
is there more?
- On considering whether a route should be installed into some table, some
operation to answer this.
E.g., does the nexthop need to be validated in some way? Presumably
normal L2 interfaces have to be in the VRF associated with the RD? (see
first one)
Then presumably the RT membership of the router has to be checked
against the route? Are the RT memberships configured per RD?
- Need to configure RTs: How's that done?
- On install of the route to a table, some operations may need to be
applied. E.g. setting RTs?
- On sending a route, what checks need to be done?
That kind of detail, more succinctly than 4364 and adding in the important
implementation details that are being proposed to be added to Quagga which
4364 deliberately doesn't cover.
??
And then, are there other VPN techs that people want?
E.g., I could imagine a L2 VPN technology which additionally required
maintaining tables to associate multicast groups to sites... Do these
exist? If so do they try map onto the VPNv4 RT stuff, or...?
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Most people feel that everyone is entitled to their opinion.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
