On Fri, Dec 18, 2015 at 7:24 AM, Paul Jakma <[email protected]> wrote: > 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. >
Isn't this really the operator's decision based on the design and needs of the network/service? The RFC has defined the Route Target attribute and its usage, but its attachment to a route is left to the operator. The implementation, based on my past experience, would be through "export" Route Targets configured for the VRF which can be overridden with export policies (route-maps) attached to the VRF and/or neighbor outbound policies. > > 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. > I did not quite follow you on this part. > > 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?). > I assume you are talking of received BGP updates, particularly for the VPN address family? These would be typically processed and installed in the VPN-IPv4 or VPN-IPv6 RIB with best-path selection being run etc. in a manner rather similar to how IPvX routes are currently handled. Route Reflection, Inter-AS VPN scenarios etc. will need advertisements from this RIB to neighbors. The key difference from existing BGP update/route processing for IPvX would be that these VPN-IPvX prefixes don't get announced into the Routing Table Manager (Zebra) as VPN routes but are "imported" into one or more VRF RIBs based on the Route Target attributes in the received update and the configuration for the VRFs. In the VRF RIBs, these are installed as IPv4 or IPv6 routes and will get announced into Zebra after going through best-path selection. These routes can also get advertised to BGP neighbors in that VRF (CE peers). One other key difference is that the nexthop for the VPN routes would need special resolution - to be resolved over a tunnel. L2VPN (EVPN) would be rather similar, but we're dealing with MACs, not routes, so would need to have a MAC VRF and MAC FDB implemented in Zebra (or a similar component). Also, in EVPN, it is not just routing information (MACs) that are exchanged, but also information pertaining to connectivity, fast convergence etc., so BGP will need to deal with those types of information (route types). In the data path, it wouldn't be all that different from VRF-lite that is available now. The incoming interface (or more complex logic in future) would associate the packet with a VRF. The key difference is that instead of the nexthop being in the same VRF (or in another VRF, if route-leaking is supported) it would be a tunnel (MPLS or otherwise) to a remote destination. > > interface to VRF to RD? Is VRF:RD a 1:1 relationship in both directions? > VRF:RD is a 1:1 relationship in all the common scenarios that I am aware of. Also, an interface would map to one VRF in the simple case as stated above. This is true for existing VRF-lite too. > - 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? > If your definition of "scopes" is a generalization of VRFs, it is the RTs that would determine that based on how RFC 4364 (or RFC 7432) is defined. The RD is just used to disambiguate addresses. > - 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? > The simplest forms of the config - again based on my past implementation experience and what I've seen on other vendors - would involve associating an RD and import/export RTs with a VRF; the import RT and export RT could both be the same value. In the case of EVPNs, there are again some additional RTs, which can sometimes be auto-derived (i.e., based on VLAN id). Of course, Quagga could deviate, if that is the consensus. Since Lou has stated he has an implementation that implements many of the L3VPN and EVPN (NVO) functions, he can probably give details of his config model after the holidays and the discussion on that front could proceed from there. > > - 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
