[frr] [PATCH 01/11] bgpd: BGP VRF processing handling

Thu Jan 5 10:51:00 EST 2017

The option #7 has two proposals:
*configuring rd/rt bgp per vrf instance*
This is ok for me.

*configure rd/rt bgp per vpnvx entry, that is to say with the network command*
I have some remarks to say:

>the following network command is to directly inject a VPNV4 route with RD/RT/label values
>this is expected to be used only when BGP is running as a route-server or controller

o It willl bring complexity in configuration : what about multiple
route target list.
network <NET> [rd <RD>] [ rt_import <import list>] [rt_export <export
list>] [tag <TAG>]

o it will add extra consuming memory in keeping the configuration
parameters, whereas each route refers to a logical VRF entity.
network <NET1> [rd <RD1>] [ rt_import <RT1 RT2 RT3>] [rt_export <RT4
RT5 RT6>] [tag <TAG>]
...
network <NET2> [rd <RD1>] [ rt_import <RT1 RT2 RT3>] [rt_export <RT4
RT5 RT6>] [tag <TAG>]

It makes sense to do some kind of factorisation in the configuration.

>otherwise, the network would be an IPvX network under the corresponding VRF
o in the case of a controller ( are you refering to a bgp daemon on
behalf of a sdn controller ?),
I see some problems when handling incoming messages.

Suppose an incoming message is received with <RD1>, and an other with
<RD2>, how can I know where to get the associate route target, so as
to perform import processing ?

I would opt for a bgp vrf and rd/rt configuration, separate from the
networking configuration.
I see two options on where to host vrf sub node:

proposed 1)- under bgp node ( proposed patch)

> 2) Does not match any other industry vendor
=> inherited from option #6.

proposed 2)- on the top level configuration mode.
It would be as if we were configuring underlying vrf subnodes, except
that the sdn controller does not care about the relationship between
zebra.
What about adding an extra keyword under vrf subnode to mention that
the BGP instance acts as a controller, and does not care about zebra
relationship, and then can create vrf instances,but without
interacting with zebra.

vrf <VRF>
 rd <>
 rt <>
 no zebra ### instantiate a logical vrf reachable by all the quagga.
It should not be a big deal for a controller to define a vrf that has
no relationship with  underlying namespaces.

Regards,

Philippe

On Thu, Jan 5, 2017 at 4:23 PM, Donald Sharp <sharpd at cumulusnetworks.com> wrote:
> We have proposed option #7 to maintain backwards compatibility.
>
> donald
>
> On Thu, Jan 5, 2017 at 10:15 AM, Philippe Guibert
> <philippe.guibert at 6wind.com> wrote:
>> Hello,
>>
>> On Thu, Jan 5, 2017 at 3:24 PM, Donald Sharp <sharpd at cumulusnetworks.com> wrote:
>>> As stated earlier we felt that option #6 had these issues:
>>>
>>> 1) VRF in multiple places add confusion
>>
>> option #6 shows two places for rd/rt configuration
>> a- under bgp router node
>> b- under address-family node : vrf <>
>>
>> longer option #6 shows two places for rd/rt configuration
>> c- under address-family node : signaling vrf <>
>> d- under configure node : vrf <> + signaling vrf <reference>
>>
>> option #7 is deployed today.
>>
>> Just to bring more clarity, The patch does not implement all options.
>> It just implements a- choice.
>>
>>> 2) Does not match any other industry vendor
>>> 3) Backwards Compatibility issues with what is already deployed today.
>>
>> You probably refer to option #7 ?
>>
>> router bgp <as> vrf vrf-1
>> rd <value>
>> route-target import <value>
>> route-target export <value>
>>
>>
>>>
>>> From my perspective, option #6 is not compelling enough to implement
>>> to break backwards compatibility
>>
>> option #7 is satisfying for a per vrf bgp instance.
>> Unless to pick between a b d or d in option #6 or #6extended, I do not
>> see other choices.
>> To which model are you refering, please ?
>>
>> Regards,
>>
>> Philippe
>>
>>>
>>> donald
>>>
>>> On Thu, Jan 5, 2017 at 8:29 AM, Philippe Guibert
>>> <philippe.guibert at 6wind.com> wrote:
>>>> Hello Lou,
>>>>
>>>> A pull request has been triggered.
>>>>
>>>> https://github.com/freerangerouting/frr/pull/44
>>>>
>>>> Regarding modifications done between this pull request and the last
>>>> emission on quagga 1.1.0 release, some changes have been done:
>>>> - adaptation for frr
>>>> - new vty enhancements. this is a subset of all the commands depicted
>>>> of option #6 of the following document:
>>>> https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/edit
>>>>
>>>> *Here is the new vty brought:*
>>>>
>>>> router bgp AAA ! core instance
>>>>    vrf <VRFNAME1>
>>>>      rt {import|export|both} RTLIST
>>>>      rd {VALUE}
>>>>      maximum-path <>
>>>>    exit-bgp-vrf
>>>>    address-family vpnv4
>>>>     network <> rd <> tag <>
>>>>    exit-address-family
>>>>  exit
>>>>
>>>> *About the behaviour :*
>>>>
>>>> If you do not have any VRF configured, it does not prevent you from
>>>> doing route processing with network command.
>>>> Even you can receive new entries.
>>>> The result can be seen by following command:
>>>>
>>>> show bgp ipv4 vpn
>>>>
>>>>
>>>> If you have VRF configured, and you have route target set, then you
>>>> will do import processing.
>>>> The result can be seen by following command:
>>>>
>>>> show ip bgp vrf <VRFNAME>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Philippe
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jan 5, 2017 at 12:27 PM, Lou Berger <lberger at labn.net> wrote:
>>>>> Philippe,
>>>>>
>>>>> It would be good to hear how this fits in the the vrf config discussions we
>>>>> had a month or two ago.  (Does anyone have a pointer to the resulting notes
>>>>> handy?)
>>>>>
>>>>> I'd also like to ensure that it doesn't break the parallel functionality
>>>>> already in the vnc code. I'm happy to test this  once you have a public repo
>>>>> with the merged code available.
>>>>>
>>>>> Lou
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On January 5, 2017 2:54:03 AM Philippe Guibert <philippe.guibert at 6wind.com>
>>>>> wrote:
>>>>>
>>>>>> Donald,
>>>>>>
>>>>>> An other patch series is needed, prior to applying it:
>>>>>>
>>>>>> https://lists.nox.tf/pipermail/frr/2016-December/000275.html
>>>>>>
>>>>>> I aggregated both series, and run CI testing
>>>>>> Once it is done, I will make a pull request based on the aggregation of
>>>>>> both.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Philippe
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 5, 2017 at 2:41 AM, Donald Sharp <sharpd at cumulusnetworks.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> I could not get this patch to apply to either master or stable/2.0.
>>>>>>> What should it be applied to?
>>>>>>>
>>>>>>> dohnald
>>>>>>>
>>>>>>> On Wed, Dec 21, 2016 at 9:21 AM, Vincent JARDIN
>>>>>>> <vincent.jardin at 6wind.com> wrote:
>>>>>>>>
>>>>>>>> Le 21/12/2016 à 15:13, Philippe Guibert a écrit :
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> +
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please Philippe, can you send a v2 of your serie without such
>>>>>>>> white-space/new line updates?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> frr mailing list
>>>>>>>> frr at lists.nox.tf
>>>>>>>> https://lists.nox.tf/listinfo/frr
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> frr mailing list
>>>>>> frr at lists.nox.tf
>>>>>> https://lists.nox.tf/listinfo/frr
>>>>>
>>>>>
>>>>>