On Fri, Oct 21, 2016 at 8:21 PM, Lou Berger <lber...@labn.net> wrote:
Hello Lou, Thanks for your detailed response, I agree to configure the RD , and the RT set per VRF. However, I tried to make a counter proposal about the way to configure it. You will find it below. Your comments are welcome. Best Regards, Philippe >> About the concepts you are talking about, I agree with you. >> Regarding design issue, I think there is a misunderstanding because I >> link RD with RTs, within a VRF. >> Whereas you point the following: >> - associate RD with VPN flows > Not sure what you mean here. About linking RD with RTs, this is not correct. You are right. In previous mail, you underlined the way to associate RD with VPN flows. So I was thinking about configuring RD per VPN flows. This is why I used that sentence "associate RD with VPN flows". > I don't understand what "VPN" means to you or in the config model. BGP > LxVPNs have VRFs and Route Distribution semantics. Together these > semantics can be combined to support LxVPNs. > how about > vrf <name> > rd ... > rt (import|export|both) ... > network <prefix> [rd ...] > In proposed patchwork, vrf is under bgp router subnode. I think, your proposal refers to reuse vrf command under configuration mode. Right ? If that is it, yes. Adaptation is possible. Or you probably think of keeping the VRF command under bgp router node ? For RD and RT set dissociation, yes too. For network command, I don't see the need to move network command under vrf subnode, whereas there is yet some network commands under various bgp vpnvx subnodes. What about keeping network command under address family subnode ? >> One reason is that this work is pure signalling, there is no dataplane >> interaction. > > As is always the the case for BGP ;-) Sorry, I am diving one more time into quagga code :-). The implementation I did does not take into account zebra <-> bgpd communication, and FIB updates. That is what I insisted on when I say the work is "pure signalling". >> Do you see other points to discuss ? >> > > Well, we need to ensure that route distribution happens properly for all > cases (including RR). See below for more specific comments. I noticed a problem , using RR with VPNv4. Actually, this does not work with VPNv4. No BGP updates messages received from RR. >>>> Most of the modifications have been done around what is called the >>>> "VRF structure". > > This is good and aligned with the suggestion to move config to be per VRF. ok >>>> >>>> The RD is mapped to that "VRF structure", but the RT also. This is a >>>> one-to-one mapping. >>>> That "VRF structure" has a RIB table where RT imports are processed. >>>> > > I think a mapping of VRF to RT set is right. Having a default RD for > VRF export is also good. > >>>> I mean, on the design point of view, I don't make a difference between >>>> a RD and a RT. > > I think this is a mistake. RD is about route (re)distribution > selection. RT is about topology and VRF control. yes. >>>> I just have to ensure that the incoming structure is available to >>>> import appropriate entries. >>>> in order to import a RT entry, I have to create a RT mapped to an >>>> other "VRF structure". >>>> >>>> If the RT is not mapped to that "VRF structure", then the RIB >>>> associated to that RT is not present. >>>> Then the import in the RIB RT will not be possible. > > We have parallel code doing the same in RFAPI. 0 I am looking at the RFAPI : imported_vpn table seems to be the one that is similar to the VRF table. I try to find out a solution in order to permit both code live together. I mean, I code redundancy ( not code duplication) can be possible, no? >>>> >>>> To illustrate, a quick example shows that routerA sends a NLRI entry to >>>> routerB. >>>> >>>> routerA> rd 200:111 import 100:111 export 100:111 300:111 >>>> routerA> network 10.10.10.0/24 rd 200:111 >>>> routerB> rd 100:111 import 100:111 export 100:111 >>>> > is this all under a vpn/vrf config parameter or at the top (bgp) level? > see answer above. currently: - vrf rd command is under bgp router sub node. - network is under vpnv4 address family subnode >>>> RouterB will import NLRI entry to RT 100:111 > >>>> This is possible because RouterB has the line rd100:111 ... created. > > hopefully you really mean because RouterB has the line import 100:111 > >>>> >>>> RouterB will not import NLRI entry to RT 300:111, since there is no >>>> underlying structure. > > all good here. > > > Is this a valid entry > routerA> network 10.10.10.0/24 rd 123:111 > > assuming the config structure is under "... vpn ..." > what rt's would be in the update? If the config structure was under vpn, I think this entry would not be valid. >>>> >>>> About "VRF structure", My intention is not to interfere about current >>>> VRF implementation in Quagga. >>>> From the configuration point of view, it is easy to find in literature >>>> cisco configuration where VRF >>>> and RD configuration maps together. > > Sorry, I work from the spec, not cisco manual/docs. > >>>> Could you be more specific about the reason to dissociate RD from VRF ? > the key point to understand is where RDs are used in the processing (VRF > export and BGP route distribution) and where they are not (VRF import) > and that RD != VRF. > >>>> >>>> One modification improvement would consist in : >>>> - That "VRF structure" could be renamed to "RT/RD structure" > please no! VRF is actually much better. > ok > you'd want a different RD here. >>>> >>>> routerC> rd 100:111 import 100:111 export 100:111 >>>> >>>> When receiving a NLRI entry from routerB), and routerA), bgp_update() >>>> will append the entry in the global RIB, according to RD field. >>>> >>>> routerC> show bgp ipv4 vpn >>>> Route Distinguisher : 200:111 >>>> *> 10.10.10.0/24 <nexthop_routerA> >>>> => 10.10.10.0/24 <nexthop_routerB> > > of course if you send this via a route reflector only on would be > recieved -- which is why you need different RDs to get both. How come BGP does not handle reception of NLRI multipath entries without addpath feature :-). You mean this use case should not occur, due to the fact that RDs are often configured specific for each router. So, If I reuse the above example, there would not be multipath entry in the global RIB. But VRF import processing would shows 2 multipath entries in the VRF RIB 100:111 routerA> rd 200:111 import 100:111 export 100:111 routerA> network 10.10.10.0/24 rd 200:111 <nexthop_routerA> routerB> rd 300:111 import 100:111 export 100:111 routerB> network 10.10.10.0/24 rd 300:111 <nexthop_routerB> routerC> rd 100:111 import 100:111 export 100:111 routerC> show bgp ipv4 vpn Route Distinguisher : 200:111 *> 10.10.10.0/24 <nexthop_routerA> Route Distinguisher : 300:111 *> 10.10.10.0/24 <nexthop_routerB> routerC> show ip bgp vrf 100:111 *> 10.10.10.0/24 <nexthop_routerA> => 10.10.10.0/24 <nexthop_routerB> Does RFAPI code permit such result ? Best Regards, Philippe _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
