Vipin,
Good stuff. See below for responses in-line.
On 11/25/2015 4:25 PM, Vipin Kumar wrote:
> 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)
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.
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?
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)
> 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
