Hi Keshava, Thanks for your comments/questions, responses inline.
On Fri, Nov 27, 2015 at 7:45 PM, A, Keshava <[email protected]> wrote: > Vivek, > > > > Thanks for sharing the detail information. > > Have some of the below thoughts and let me know the opinion. > > > > *From CE side to PE:* > > Under the same VRF, if there are multiple CE peers > connected to a PE will form multiple 'bgp struct' for the same VRF instance. > > Each of these BGP struct's rib (of same VRF instance) > will write the routes to corresponding ‘zebra vrf instance’. > > Zebra doing the best route within that VRF instance and > install those to FIB, so that local cross can happen across CE's with in > that VRF instance ? > > This is how something is allowed now ? > Multiple CE peers in the same VRF would be multiple neighbors (struct peer) that belong to that instance (struct bgp). It would be the same as peers in the default instance right now. These CEs can talk to one another through the PE, if required - if that is what the 2nd part of your question/comment is referring to. > > > > > *From PE to remote PE*: *I have little question about this "Routes to PEs > would be advertised from all of the VRF (instance) RIBs in BGP."* > > > > Means does the BGP-global-instance will walk over all > other vrf_instance 'bgp structs RIBs' and directly copy those routes, into > its BGP global RIB ? > > How is the route data structure arrangement in that global > BGP RIB, so that when VRF got deleted/any operation can selective operate > on respective VRF routes locally ? Or it has to be triggered by respective > VRF BGP_instance ? > > Or > > Default BGP will do ‘importing of these routes from each of Zerba VRF > instance based on the RT match’ ? (I think this is it is right ? ) > For advertisement of VPN routes to a PE, the simple case would be to advertise the routes present in each VRF instance in BGP. So, yes, the VPN route advertisement to a PE will involve walking the IP RIBs of each BGP instance. More involved cases include route reflection, Inter-AS etc. Removal of a VRF (or CE withdrawing all routes or 'no redistribute ospf' done for that BGP instance etc.) will all result in the routes being withdrawn from all PEs to which they were advertised - a model similar to what happens now. Obviously, there are some new dimensions because these routes are IPvX routes in the instance RIBs but must be processed for VPNvX withdraws. In addition, the routes may need to be withdrawn from other CEs in the same VRF too, uninstalled from the Zebra VRF RIB etc. Most of these will be modeled on existing operations. > > > > > Some thoughts: (suggestion) > > To keep it neat and maintain the separation of concern , > is it also better to introduce something like "VPN Manager" a new model in > Quagga Routing architecture ? > > *VPN Manger: * > > o Overall Management of VPN/VRF in Quagga architecture. Handles VRF > create, delete > > o Assigns the label and label management. > In some ways, the VRF registration mechanism that we're introducing as part of VRF-lite support in BGP can be viewed as a VPN manager. I envisage a related label management component when we move beyond VRF-lite to full-blown L3VPNs (or EVPNs w/ MPLS). To me, these would be part of 'zebra', not a separate daemon; the VRF management is definitely being implemented as part of zebra. > o Routes learned from CE side will pass through this module to get > converted as VPN routes. > This would happen in BGP. Of course, corresponding files (say, bgp_l3vpn.c or bgp_rtexport.c etc.) could be viewed as a sub-component. > o For ‘received VPN routes’ BGP Next hop can subscribed to this module. > > § "VPN Manager" responsible to track the remote PE next hop. It tracks > MPLS-LSP tunnel, IP tunnels, which is transparent to BGP module and > notifies once it is UP. > This would really be extensions to the NHT mechanism that is currently in discussion for inclusion into the next Quagga release. > o Local VRF route leaking across instance. > This topic will probably take up more discussion. There is the "BGP way" of doing it using intersecting RTs, then there is the possibility to implement something similar to RIB-groups etc. > > > > > Regards, > > keshava > > > > > > > > *From:* Vivek Venkatraman [mailto:[email protected]] > *Sent:* Saturday, November 28, 2015 12:48 AM > *To:* A, Keshava > *Cc:* Vipin Kumar; Lou Berger; [email protected]; Dinesh Dutt > *Subject:* Re: [quagga-dev 14011] VRF global and protocol specific config > > > > Hi Keshava, > > > > I can answer some of your queries. Again, note that the short-term goal is > to build on top of the base VRF support introduced into Quagga recently to > achieve the following: > > > > a. Ensure 'name' support in configuration and interactions > > b. Ensure that VRF can work with the VRF device implementation of VRF that > has been accepted into the Linux kernel, while not breaking the netns model > and paving the way for a hierarchy in future (multiple netns, each > implementing multiple VRFs using the VRF-device model). > > c. Extend VRF support into BGP > > > > All these would ensure that the VRF-lite or Multi-VRF implementation in > Quagga is complete (of course, without OSPF, RIP etc. yet). Any route > leaking across VRFs would initially be possible only through an external > device (firewall etc.) > > > > Each VRF would be a instance/view in BGP - 'struct bgp' in terms of data > structures. The peering towards CEs, whether VRF-lite or full-blown RFC > 4364 would be within these instances and the CE-learnt routes would be > stored within the corresponding RIBs and installed into Zebra in the > corresponding VRF. PEs for RFC 4364 would be configured in the "global" or > "default" instance - "address-family vpnvX unicast". Routes to PEs would be > advertised from all of the VRF (instance) RIBs in BGP. In the reverse > direction, received VPN-IPvX routes would be installed in the VPN-IPvX RIB > in the default instance and then "imported" into one or more VRF (instance) > RIBs in BGP based on import policies/RTs. Once here, they would get > installed into Zebra similar to CE-learnt routes. > > > > If the protocol towards the CE is static (or OSPF later on), the routes in > the corresponding VRF in Zebra have to be injected into BGP (in > corresponding VRF/instance) in order to be advertised to remove PEs. This > would follow the model for the default VRF - you have to configure > "networks" or perform "redistribute" in the corresponding VRF/instance. Of > course, this would be needed for connected routes also. > > > > I've glossed over label assignment, nexthop validation etc. in this, but > they will all fit in too. > > > > Vivek > > > > On Wed, Nov 25, 2015 at 10:46 PM, A, Keshava <[email protected]> wrote: > > Hi Vipin, > > > > When we say BGPL3 VPN , is it classical RFC 2457biz scenarios of all the > options . > > > > How the below Basic L3 VPN scenario will be handled ? > > Routing facing towards CE (private side) will be multi-instance one ? > > All different VRFs routes will be injected to public-VRF and converted > into L3 VPN routes , will this be done directly Zerba directly ? > > Who Managers these Labels ? Then Public BGP will inject these from > Zerba and updates to remote BGP ? > > > > L3VPN routes received from remote-PE will have relation with MPLS > subsystem ? > > When does BGP makes received routes as active ? Does Quagga/BGP tracks > MPLS-LSP tunnel status between those PE’s ? > > > > How is this multi-VRF is supported ? Each routing protocol will support > multi-instance support ? > > How is the flow of “private VRF routes” getting converted into “ VPN > routes” and visa-versa in Quagga? How will be this architecture ? > > > > This will help to have better common understanding in terms of basic > scale and functionality and overall Quagga L3 VPN architecture. > > > > > > > > > > Regards, > > keshava > > > > *From:* Vipin Kumar [mailto:[email protected]] > *Sent:* Thursday, November 26, 2015 2:56 AM > *To:* Lou Berger; [email protected]; Vivek Venkatraman; Dinesh > Dutt > *Subject:* [quagga-dev 14011] VRF global and protocol specific config > > > > Hi Lou, > > > > Based on what we have in quagga, this is how we seem to be converging on > this: > > (I sent email previously to agree with Paul's suggestion about keeping > view|vrf both) > > > > > > *1. Simple VRF (no lxvpn) case* > > > > *BGP mode config:* > > > > router bgp <asn> vrf <name1> > > > > ! regular peering. > > ! redistribution > > ! import/export of routes between VRFs based on route-targets > > .. > > router bgp <asn> vrf <name2> > > .. > > > > > > *Global VRF mode config:* > > > > (config)# vrf vrf-name > > (config-vrf)# route-target <>:<> ! May be in an address-family specific > way > > (import/export) > > > > *2. L3VPN VRF case* > > > > > > a. BGP as PE-PE, and other IGPs as PE-CE protocols > > > > *BGP mode config:* > > > > router bgp <asn> !default instance with the default-table > > .. > > ! this is where vpn address-family config may belong > > > > router bgp <asn> vrf <name1> > > ! redistribution from IGPs > > ! import/export of routes between VRFs based on route-targets > > .. > > router bgp <asn> vrf <name2> > ! .. > > > > Possibly for OSPF (just like BGP multi-instance per daemon) > > router ospf vrf <name1> > > !adjacency towards CE > > router ospf vrf <name2> > > .. > > > > *Global VRF mode config:* > > > > (config)# vrf vrf-name > > (config-vrf)# route-target <>:<> ! May be in an address-family specific > way > > (import/export) > > > > > > b. BGP as PE-PE, and also as PE-CE protocol > > > > *BGP mode config:* > > > > router bgp <asn> !default instance with the default-table > > .. > ! peering towards other PEs/RR > > ! this is where vpn address-family config may belong > > router bgp <asn> vrf <name1> > > > > ! peering towards CE > > ! import/export of routes between VRFs based on route-targets > > .. > > router bgp <asn> vrf <name2> > ! .. > > > > > > > > *Global VRF mode config:* > > > > (config)# vrf vrf-name > (config-vrf)# route-target <>:<> ! May be in an address-family specific > way > (import/export) > > > > > > BGP l3VPN implementation may work across BGP instances, to work on > import/export of routes. > > > > For static routes import/export between VRFs, can be implemented in Zebra > > > > Do you (or others) see any issue with this config model going forward for > LxVPNs too? > > > > Vipin > > > > > > > > On Sun, Nov 22, 2015 at 6:50 PM, Lou Berger <[email protected]> wrote: > > Vipin, > > So this maps pretty well when talking vrf-lite, but before making this > change I think we should agree upon how tunnel based VRFs are > represented and configured over a core instance so we don't end up with > naming or concept clashes. If not full syntax, I think we should at > least have a direction outlined. > > Have you given any thoughts on how you'd like to handle this? > > Thanks, > Lou > > On 11/22/2015 12:23 AM, Vipin Kumar wrote: > > Hello Quagga-dev, > > > > *Objective of this email: > > * > > > > To see if 'view' keyword can be replaced with 'vrf' > > > > *Why:* > > > > 1. Code and flow to implement VRFs in BGP is turning out to be quite > > similar to how it is for views. VRF in BGP can be considered as a > > super-set of the current views functionality. It should be possible to > > realize views as a special type of VRF, and possibly enable it by a > > config option. > > > > This is to reduce the overhead on implementation (and also on > > usability) to provide both view and vrf options at > > configuration/show/clear/debug commands. > > > > 2. While views may be working for some use-cases, the support in > > 'show commands' is not quite complete yet. > > > > *More Details:* > > > > In a way, this is a follow-up on the VRF discussion we had where we > > suggested we could use the current BGP multi-instance implementation. > > > > Currently, BGP has some support for multiple views. These are > > implemented as separate BGP instances, each with its own set of global > > configuration, neighbors, RIB etc. This effectively makes the mapping > > of a VRF to a view the most logical approach. > > > > bgp multiple-instance > > > > router bgp <asn> view <name1> > > .. > > router bgp <asn> view <name2> > > > > > > For VRFs, one obvious choice is to use similar model with vrf keyword: > > > > router bgp <asn> vrf <name> > > > > If views are currently not being used for any real purpose, they could > > be directly replaced with 'vrf' in the user-interface. A 'type' field > > for the VRF could be introduced later to support other possibilities. > > If views are being used/deployed now, we'd like to know more about how > > they are used. In this case, we will think of a backward compatible > > change to introduce VRFs with views. > > > > Thought to poll the community to see if thinking in this direction > > even makes sense. > > > > Feel free to send unicast responses/or respond to the thread as is. > > > > Regards, > > Vipin > > > > > > > > > > _______________________________________________ > > 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
