Vipin,
See below.
On 11/30/2015 3:32 PM, Vipin Kumar wrote:
> 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]
> <mailto:[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.
(related comment below.)
>
>
> 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?
>
Are you asking about multiple or single? Single is the minimum, multiple
core would be the case where different customer sets (VRFs) use
independent core infrastructure resources/topologies. (e.g., without
MPLS-TE core).
> 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?
I don't think it's a scaling issue.
The main issue with supporting multiple cores today is a simple
code/config issue, where bgp_get_default is called rather than having
struct bgp properly passed. Also would need additional cli syntax to
change core/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)
>
>
> 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.
Perhaps, just would prefer to not have the same function coded
(configured and tested) multiple ways.
Lou
>
> 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]>
> > <mailto:[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]>
> <mailto:[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
