Hi Lou, Certainly helps to have a open discussion upfront. Some of the points you are making are resonating well with what I/we had also given some thought internally. Please see a few comments inline..
On Fri, Nov 27, 2015 at 12:44 PM, Lou Berger <[email protected]> wrote: > Vipin, > Good stuff. See below for responses in-line. > > > So are you suggesting import / export is not tied to BGP? Right? > RT (and RD) are BGP 'things'. Also cross -VRF route leaking at a single > router (i.e., even in the VRF-lite case) naturally falls out of BGP > L3VPN support, so I wouldn't think special code developed just to > support this narrow case is the right way to go. That said, I think > it's okay/good to have such vrf 'policy' information be configured > outside of the vrf's BGP instance. > Yes. For route-targets, I was thinking of not starting with the BGP specific restriction, if some application does want to take advantage of the concept of import/export through these constructs. And I don't have a strong opinion on this. > A related consideration is how many core instances can be supported. > Our (NVA) VRF import/export (and some CLI) code currently assumes a > single 'default' core instance. I know others have this limitation as > well, but it really isn't a fundamental thing so we should decide on > which model is the long term objective as it can impact required config > info. > > In particular, it goes to how 'vrf vrf-name' is associated with its > core instance. We currently put this under the single core instance > looking to the long term. Of course another alternative is to add a > config line within config-vrf. I really can argue this either way, so > would be interested in the opinions of others. > There's also the additional issue of import/export filtering using both > prefix lists and route maps. I haven't given this enough thought to > discuss at this point. (We do have some support for this and need to > think/discuss internally on how to map our pre-Zebra VRF implementation > to the current discussion.) > > > > > > *2. L3VPN VRF case* > > > > > > a. BGP as PE-PE, and other IGPs as PE-CE protocols > also have pure P and C nodes... > > > > > *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> > > ! .. > > > > > > See my comments above. Again core questions are: > 1) Are multiple 'cores' supported or only a single default? > What are the use-cases you have in mind for enabling multiple core/default instances? Is it more for scaling the default instance better by enabling multiple of them, or there is a need of separation inside a default instance by means of multiple cores? 2) Where are VRF-specific RTs and RD configured > (a) at top level policy > (b) or under the core/default BGP instance > 3) How is local inter-VRF route leaking supported (via BGP L3VPNs or vis > special-case zebra code) > > I dont have an opinion on this yet. However, if we go by standards it seem to belong in BGP, but implementation wise if this means avoidable data movement/processing between zebra and BGP, then it could be implemented in a generic (lib code)way, which zebra and BGP both could use. Regards, Vipin > > 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) > > > > > Same discussion as above. > > > > > 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 > > I'm not sure this makes sense as the BGP has been the place where most > have implemented RT policy as it just falls out from RFC4364/4659 > implementation. I'd say focus on simple vrf-lite working first with all > the protocols before jumping in on inter-VRF import/export. > > > > > Do you (or others) see any issue with this config model going forward > > for LxVPNs too? > > > > In addition to the questions raised above, I think we should have > answers for route policy ( maps and prefix lists). > > Lou > > > Vipin > > > > > > > > On Sun, Nov 22, 2015 at 6:50 PM, Lou Berger <[email protected] > > <mailto:[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] <mailto:[email protected]> > > > https://lists.quagga.net/mailman/listinfo/quagga-dev > > > > > > > > >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
