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
