There is one key aspect that is different, IMO. The learning of a VPN nexthop does not trigger creation of a MPLS (or GRE or other) tunnel; the LSP or labeled route has to already exist. [In the case of MPLS, an RSVP-TE LSP would (in all probability) need additional parameters from the operator while a BGP or LDP LSP would be downstream unsolicited.]
If the above is a given, our thoughts on the VPN nexthop resolution are that the Nexthop Tracking mechanism (NHT) that is currently under evaluation for inclusion in Quagga can be enhanced so that the client (BGP) can indicate what types of resolution it requires (tunnel, directly-connected etc.) and the resolver (Zebra) can indicate in notifications how the nexthop is resolved. This will allow the current BGP update/route processing flow to remain largely undisturbed. I don't know where exactly NHT stands in terms of being incorporated into upcoming Quagga release, but I don't think there are any serious outstanding objections after the last round of discussions. Therefore, it seems logical to extend this to handle the processing of VPN nexthops. The tunnel to the nexthop has to be separately setup or available. This could be through operator configuration for a GRE/IPsec tunnel or static LSP, by an MPLS component that indicates the availability of a LDP or RSVP LSP or by BGP itself installing a BGP-LU route into the routing table. There could be a controller that installs this too. Ultimately, what is installed is a "labeled route" or "tunnel route" into the main routing table of Zebra and this is what NHT will use for its evaluation (as it is already doing for non-VPN nexthops). On Sun, Dec 20, 2015 at 10:14 PM, A, Keshava <[email protected]> wrote: > Hi, > > So the current BGP flow w.r.t received VPN routes flow is inline towards > this kind of framework. > > Zebra has to resolve the ‘Next hop’ for remote-PE ? > > 1. Tomorrow zebra has to request/subscribe for MPLS subsystem for remote > Route reachability ? > > > > > > OR > > > > 2. we introduce new layer who can make decision with his available data > > 1. If L3 relay on L3 tunnel. (GRE) > > 2. If LSP -> MPLS > > 3. If L2 -> for L2 tunnel (L2TP)/ any L2 tunnel ? > > > > > > Lot depends on this framework what is closed here. > > We are going in approach-1 model ? > > Regards, > > keshava > > *From:* Vivek Venkatraman [mailto:[email protected]] > *Sent:* Sunday, December 20, 2015 9:45 PM > *To:* Paul Jakma > *Cc:* Vincent JARDIN; Quagga Devel > *Subject:* [quagga-dev 14303] Re: VPN routing architecture and > requirements > > > > > > 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
