[01/11] bgpd: BGP VRF processing handling

Submitted by Philippe Guibert on Dec. 21, 2016, 2:13 p.m.

Details

Message ID 1482329636-13850-2-git-send-email-philippe.guibert@6wind.com
State New
Headers show

Commit Message

Philippe Guibert Dec. 21, 2016, 2:13 p.m.
NLRI entries received from MP-BGP peer exchange are exported in VRF RIB
tables. This commit introduces the BGP VRF processing handler that can
be used for further processing into VRF RIB tables: best selection
algorithm, multipath.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
---
 bgpd/bgp_route.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 51 insertions(+), 5 deletions(-)

Comments

Vincent Jardin Dec. 21, 2016, 2:21 p.m.
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?
Donald Sharp Jan. 5, 2017, 1:41 a.m.
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@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@lists.nox.tf
> https://lists.nox.tf/listinfo/frr
Philippe Guibert Jan. 5, 2017, 7:53 a.m.
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@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@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@lists.nox.tf
>> https://lists.nox.tf/listinfo/frr
Lou Berger Jan. 5, 2017, 11:27 a.m.
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@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@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@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@lists.nox.tf
>>> https://lists.nox.tf/listinfo/frr
>
> _______________________________________________
> frr mailing list
> frr@lists.nox.tf
> https://lists.nox.tf/listinfo/frr
Philippe Guibert Jan. 5, 2017, 1:29 p.m.
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@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@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@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@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@lists.nox.tf
>>>> https://lists.nox.tf/listinfo/frr
>>
>>
>> _______________________________________________
>> frr mailing list
>> frr@lists.nox.tf
>> https://lists.nox.tf/listinfo/frr
>
>
>
Donald Sharp Jan. 5, 2017, 2:24 p.m.
As stated earlier we felt that option #6 had these issues:

1) VRF in multiple places add confusion
2) Does not match any other industry vendor
3) Backwards Compatibility issues with what is already deployed today.

From my perspective, option #6 is not compelling enough to implement
to break backwards compatibility

donald

On Thu, Jan 5, 2017 at 8:29 AM, Philippe Guibert
<philippe.guibert@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@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@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@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@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@lists.nox.tf
>>>>> https://lists.nox.tf/listinfo/frr
>>>
>>>
>>> _______________________________________________
>>> frr mailing list
>>> frr@lists.nox.tf
>>> https://lists.nox.tf/listinfo/frr
>>
>>
>>
Lou Berger Jan. 5, 2017, 2:59 p.m.
I suspect that the VRF portion of this patch provides a subset of the
functions already in the VNC code with the addition of vty/cli support. 
Our plan was to add the vty functions for the VNC code once they were
agreed to by the community (background in the link provided by
Philippe).  It sounds to me that we should resume this discussion as
well as discuss this patch in an upcoming technical meeting.

Philippe,

The patch also seems to provide some fixes/changes to core MP BGP code. 
Is this correct?  Would it be reasonable to submit this as an
independent patch?

Thanks,

Lou


On 1/5/2017 9:24 AM, Donald Sharp wrote:
> As stated earlier we felt that option #6 had these issues:
>
> 1) VRF in multiple places add confusion
> 2) Does not match any other industry vendor
> 3) Backwards Compatibility issues with what is already deployed today.
>
> From my perspective, option #6 is not compelling enough to implement
> to break backwards compatibility
>
> donald
>
> On Thu, Jan 5, 2017 at 8:29 AM, Philippe Guibert
> <philippe.guibert@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@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@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@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@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@lists.nox.tf
>>>>>> https://lists.nox.tf/listinfo/frr
>>>>
>>>> _______________________________________________
>>>> frr mailing list
>>>> frr@lists.nox.tf
>>>> https://lists.nox.tf/listinfo/frr
>>>
>>>
Philippe Guibert Jan. 5, 2017, 3:15 p.m.
Hello,

On Thu, Jan 5, 2017 at 3:24 PM, Donald Sharp <sharpd@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@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@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@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@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@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@lists.nox.tf
>>>>>> https://lists.nox.tf/listinfo/frr
>>>>
>>>>
>>>> _______________________________________________
>>>> frr mailing list
>>>> frr@lists.nox.tf
>>>> https://lists.nox.tf/listinfo/frr
>>>
>>>
>>>
Donald Sharp Jan. 5, 2017, 3:23 p.m.
We have proposed option #7 to maintain backwards compatibility.

donald

On Thu, Jan 5, 2017 at 10:15 AM, Philippe Guibert
<philippe.guibert@6wind.com> wrote:
> Hello,
>
> On Thu, Jan 5, 2017 at 3:24 PM, Donald Sharp <sharpd@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@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@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@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@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@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@lists.nox.tf
>>>>>>> https://lists.nox.tf/listinfo/frr
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> frr mailing list
>>>>> frr@lists.nox.tf
>>>>> https://lists.nox.tf/listinfo/frr
>>>>
>>>>
>>>>
Philippe Guibert Jan. 5, 2017, 3:51 p.m.
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@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@6wind.com> wrote:
>> Hello,
>>
>> On Thu, Jan 5, 2017 at 3:24 PM, Donald Sharp <sharpd@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@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@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@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@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@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@lists.nox.tf
>>>>>>>> https://lists.nox.tf/listinfo/frr
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> frr mailing list
>>>>>> frr@lists.nox.tf
>>>>>> https://lists.nox.tf/listinfo/frr
>>>>>
>>>>>
>>>>>
Philippe Guibert Jan. 24, 2017, 4:19 p.m.
On Thu, Jan 5, 2017 at 3:59 PM, Lou Berger <lberger@labn.net> wrote:

Hello Lou, all,


> I suspect that the VRF portion of this patch provides a subset of the
> functions already in the VNC code with the addition of vty/cli support.
>

I briefly listed you on chat ( a few weeks ago) the main functionalities
that the VRF portion does.
In this patch, the VRF portion does the following:
- VRF processing application to VPNv4 messages ( import to VRF)
- ability to enable Multipath, and configure the appropriate number of paths
- ability to handle ECMP entries coming from different BGP speakers
- each new modification in VRF RIB is linked to an informational message (
add/withdraw)

Next to this, some code needs to be rebased with frr, related to VPNv6, and
EVPN ( including EVPN IPv6 and IPv4).
- VRF import processing application to EVPN route type 5 and EVPN route
type 2 messages
- VRF import processing application to VPNv6 and EVPN IPv6 messages
- ability to perform VRF processing with route target
- ability to configure VRF per layer. meaning define a layer 2 VRF or a
layer 3 VRF
- ability to handle EVPN entries coming from different BGP speakers
- ability to filter specific L2 or L3 data from EVPN RT2 messages in
appropriate VRF.
- ability to carry special ext. communities params ( router mac and encaps
type)


> Our plan was to add the vty functions for the VNC code once they were
> agreed to by the community (background in the link provided by
> Philippe).  It sounds to me that we should resume this discussion as
> well as discuss this patch in an upcoming technical meeting.
>
>
From our exchange, I understand that the VNC feature implements the VRF
portion of this patch.
The VNC also implements the NVO3 style forwarder. You are better placed
than me to talk about the VNC feature.

I don't know if there are plans for supporting the next features I mention
( EVPN, VPNv6) and when ?.

Also, if VNC is interesting to use, I would like to have some figures in
terms of footprint or performances. What about the following usage:
10 VRFs, 1000000 prefixes, and 8 peers configured.

Best Regards,

Philippe
Lou Berger Jan. 24, 2017, 6:37 p.m.
Philippe,

I'm not sure what you're asking here, if anything.  Nonetheless I'll add
some to details/response below

On 1/24/2017 11:19 AM, Philippe Guibert wrote:
> On Thu, Jan 5, 2017 at 3:59 PM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>> wrote:
>
> Hello Lou, all,
>  
>
>     I suspect that the VRF portion of this patch provides a subset of the
>     functions already in the VNC code with the addition of vty/cli
>     support.
>
>

The vrf-policy and add drop functions described
https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/
are now available via https://github.com/freerangerouting/frr/pulls
> I briefly listed you on chat ( a few weeks ago) the main
> functionalities that the VRF portion does.
> In this patch, the VRF portion does the following:
> - VRF processing application to VPNv4 messages ( import to VRF)
> - ability to enable Multipath, and configure the appropriate number of
> paths
> - ability to handle ECMP entries coming from different BGP speakers
> - each new modification in VRF RIB is linked to an informational
> message ( add/withdraw) 
>
> Next to this, some code needs to be rebased with frr, related to
> VPNv6, and EVPN ( including EVPN IPv6 and IPv4).
> - VRF import processing application to EVPN route type 5 and EVPN
> route type 2 messages
> - VRF import processing application to VPNv6 and EVPN IPv6 messages
> - ability to perform VRF processing with route target 
> - ability to configure VRF per layer. meaning define a layer 2 VRF or
> a layer 3 VRF
> - ability to handle EVPN entries coming from different BGP speakers
> - ability to filter specific L2 or L3 data from EVPN RT2 messages in
> appropriate VRF.
> - ability to carry special ext. communities params ( router mac and
> encaps type)
>  
Here's a list of what's covered in the VNC code:
o NVO3 NVA (SDN controller)
o BGP based distribution of IPv4, IPv6 and L2/MAC VPN information over
arbitrary tunnel types
  - IPv4 and IPv6 tested extensively, MAC tested, but less extensively
  - Arbitrary control topologies (mesh, RR, hybrid, etc.)
o Full BGP VRF support (RTs & RDs)
o Multiple L2 logical nets (~= EVPN Ethernet Segment Id)
o Parallel L2 forwarders per segment
o Remote Forwarder "RF" (NVE) support
  - Dynamic RF registration based on configured policy
  - Full state maintained per remote forwarder
  - Dynamically learned, or configured mappings
  - Cache driven (pull) and full table download (push)
  - Notification of adds/withdrawals (both models)
o Support for load sharing, dynamic moves, redundant NVAs & NVEs
o Per VRF import/export via BGP (inside L3VPN)
o IGP import/export to single zebra
o API support for custom remote forwarder (NVA/NVE) protocol


>     Our plan was to add the vty functions for the VNC code once they were
>     agreed to by the community (background in the link provided by
>     Philippe).  It sounds to me that we should resume this discussion as
>     well as discuss this patch in an upcoming technical meeting.
>
>
again, see pull requests for basic support

> From our exchange, I understand that the VNC feature implements the
> VRF portion of this patch.
> The VNC also implements the NVO3 style forwarder. You are better
> placed than me to talk about the VNC feature.
>
> I don't know if there are plans for supporting the next features I
> mention ( EVPN, VPNv6) and when ?.
>
-L2 is via non-standard BGP encoding, plan to convert to evpn once core
code available
- Support for  zebra VRFs needs to be done as part of the CLI support
mentioned in URL above.
> Also, if VNC is interesting to use, I would like to have some figures
> in terms of footprint or performances. What about the following usage:
> 10 VRFs, 1000000 prefixes, and 8 peers configured.
>
Sure.  See the pull request to try out any scenario you wish.  we
regularly do tests with 100Ks prefixes.
Lou

> Best Regards,
>
> Philippe
Philippe Guibert Jan. 31, 2017, 9:43 a.m.
Hello Lou,

On Tue, Jan 24, 2017 at 7:37 PM, Lou Berger <lberger@labn.net> wrote:

> I'm not sure what you're asking here, if anything.  Nonetheless I'll add
> some to details/response below

Thanks a lot, I need information, I need to dig into the vnc internals :-).


> The vrf-policy and add drop functions described

drop function, you mean clear command ?

> https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/
> are now available via https://github.com/freerangerouting/frr/pulls

I attended lately at the meeting of 17th of january.
I had a question about following vty commands:

a)
global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
[label <value>] [pref (0-255)]
b)
vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55

When I run a), I was expecting to have the prefix imported in the
rf_import_table 65:1.
Maybe there is a configuration issue, or the behaviour is not what I expect ?

When I run b), the prefix is imported as local, as expected.
Assuming b) is a command for troubleshooting, should not that command
moved under debug rfapi-dev node ?

> >
> Here's a list of what's covered in the VNC code:
> o NVO3 NVA (SDN controller)
> o BGP based distribution of IPv4, IPv6 and L2/MAC VPN information over
> arbitrary tunnel types
>   - IPv4 and IPv6 tested extensively, MAC tested, but less extensively
>   - Arbitrary control topologies (mesh, RR, hybrid, etc.)
> o Full BGP VRF support (RTs & RDs)

This is what I am interested in.
- First, Importing VPNv4 or VPNv6 entries

> o Multiple L2 logical nets (~= EVPN Ethernet Segment Id)
From what I see, the 10 byte ethernet segment identifier is not carried out yet.
This matches what you are referring by L2/MAC VPN information over
arbitrary tunnel types

> o Parallel L2 forwarders per segment
> o Remote Forwarder "RF" (NVE) support
>   - Dynamic RF registration based on configured policy
>   - Full state maintained per remote forwarder
>   - Dynamically learned, or configured mappings
>   - Cache driven (pull) and full table download (push)
>   - Notification of adds/withdrawals (both models)

Are the notifications you are referring handled by the following
callback structure:
file rfapi.h, struct rfapi_rfp_cb_methods ?

Is it possible to get some notifications when a new prefix coming from
a remote BGP speaker is imported ?
I tried to use rfp_methods.response_cb, and fp_methods.local_cb, but
without any success.
If you have a pointer to give me, you are very welcome.

> o Support for load sharing, dynamic moves, redundant NVAs & NVEs

I made a pull request in order to support multipath for vpnvx address families.
( https://github.com/freerangerouting/frr/pull/138 )
I admit that this is not necessary in order to test multipath against RTs.
I could then test ECMP with VNC.
I observe the following:

Whatever the selection criterium on global RIB ( multipath enabled or
not), the entry is present in vnc registration list.
show vnc registration

[Remote] Prefix RT={64603:1111} VRF "64603:1111"
Prefix               VN Address      UN Address      Cost Lifetime
11.11.0.0/16         Label: 125                      155  infinite
11.11.0.0/16         Label: 125                      155  infinite

I was expecting something like that:
[Remote] Prefix RT={64603:1111} VRF "64603:1111"
   Prefix               VN Address      UN Address      Cost Lifetime
*> 11.11.0.0/16         Label: 125                      155  infinite
    11.11.0.0/16         Label: 125                      155  infinite

If there was a command to enable multipath on the RT, I would have
expect the following

[Remote] Prefix RT={64603:1111} VRF "64603:1111"
   Prefix               VN Address      UN Address      Cost Lifetime
*> 11.11.0.0/16         Label: 125                      155  infinite
=>11.11.0.0/16         Label: 125                      155  infinite

Does that mean that all entries are taken into account without any


> o Per VRF import/export via BGP (inside L3VPN)

I began some testing.

> o IGP import/export to single zebra
> o API support for custom remote forwarder (NVA/NVE) protocol
>
>
> >     Our plan was to add the vty functions for the VNC code once they were
> >     agreed to by the community (background in the link provided by
> >     Philippe).  It sounds to me that we should resume this discussion as
> >     well as discuss this patch in an upcoming technical meeting.
> >
> >
> again, see pull requests for basic support
>
> > From our exchange, I understand that the VNC feature implements the
> > VRF portion of this patch.
> > The VNC also implements the NVO3 style forwarder. You are better
> > placed than me to talk about the VNC feature.
> >
> > I don't know if there are plans for supporting the next features I
> > mention ( EVPN, VPNv6) and when ?.
> >
> -L2 is via non-standard BGP encoding, plan to convert to evpn once core
> code available
> - Support for  zebra VRFs needs to be done as part of the CLI support
> mentioned in URL above.

In fact, VPNv6 should already work, I guess ?
I understand that both features are linked : "evpn core" and "evpn
import processing".

> > Also, if VNC is interesting to use, I would like to have some figures
> > in terms of footprint or performances. What about the following usage:
> > 10 VRFs, 1000000 prefixes, and 8 peers configured.
> >

I could extract some memory figures. 20000 prefixes and 40 VRFs. Interesting.
Lou Berger Jan. 31, 2017, 1:23 p.m.
On 1/31/2017 4:43 AM, Philippe Guibert wrote:
> Hello Lou,
>
> On Tue, Jan 24, 2017 at 7:37 PM, Lou Berger <lberger@labn.net> wrote:
>
>> I'm not sure what you're asking here, if anything.  Nonetheless I'll add
>> some to details/response below
> Thanks a lot, I need information, I need to dig into the vnc internals :-).
>
>
>> The vrf-policy and add drop functions described
> drop function, you mean clear command ?
yes.
>> https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/
>> are now available via https://github.com/freerangerouting/frr/pulls
> I attended lately at the meeting of 17th of january.
> I had a question about following vty commands:
>
> a)
> global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
> [label <value>] [pref (0-255)]
> b)
> vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55
I had forgotten that this command even existed -- it is ancient and IMO
a historic appendage - deleting or moving to debug is a good idea.

in the Jan 17 the form that was agreed to for such was to use route maps
to set RD and to add under vrf-policy
*

    label <value> [prefix <prefix>|prefixlist <prefixlist>]

**

*and we don't have support for this yet.*

*

> When I run a), I was expecting to have the prefix imported in the
> rf_import_table 65:1.
> Maybe there is a configuration issue, or the behaviour is not what I expect ?
keep in mind RTs determine table while RDs control route
selection/distribution.
The RTs on the add command are determined by the vrf-policy of the
<vrf-name>.  When no vrf is specified the add is to the default
instance's unicast table.  This is really something outside of vrf
support and not something we have (or are planning) to implement.

> When I run b), the prefix is imported as local, as expected.
> Assuming b) is a command for troubleshooting, should not that command
> moved under debug rfapi-dev node ?

This predates the rfapi code removing it or making a debug is a good
idea.  Do you want to do it or should I?

>> Here's a list of what's covered in the VNC code:
>> o NVO3 NVA (SDN controller)
>> o BGP based distribution of IPv4, IPv6 and L2/MAC VPN information over
>> arbitrary tunnel types
>>   - IPv4 and IPv6 tested extensively, MAC tested, but less extensively
>>   - Arbitrary control topologies (mesh, RR, hybrid, etc.)
>> o Full BGP VRF support (RTs & RDs)
> This is what I am interested in.
> - First, Importing VPNv4 or VPNv6 entries
>
>> o Multiple L2 logical nets (~= EVPN Ethernet Segment Id)
> From what I see, the 10 byte ethernet segment identifier is not carried out yet.
> This matches what you are referring by L2/MAC VPN information over
> arbitrary tunnel types
A 4 byte logical network identifier is carried as an RT unless there is
a configured RT override (for the LNI label tuple under l2-group config).

>> o Parallel L2 forwarders per segment
>> o Remote Forwarder "RF" (NVE) support
>>   - Dynamic RF registration based on configured policy
>>   - Full state maintained per remote forwarder
>>   - Dynamically learned, or configured mappings
>>   - Cache driven (pull) and full table download (push)
>>   - Notification of adds/withdrawals (both models)
> Are the notifications you are referring handled by the following
> callback structure:
> file rfapi.h, struct rfapi_rfp_cb_methods ?
>
> Is it possible to get some notifications when a new prefix coming from
> a remote BGP speaker is imported ?
yes
> I tried to use rfp_methods.response_cb, and fp_methods.local_cb, but
> without any success.
you have to set these on rfapi_register and then query for mac|IP, or
set full table download and query for anything...
> If you have a pointer to give me, you are very welcome.
>
>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
> I made a pull request in order to support multipath for vpnvx address families.
> ( https://github.com/freerangerouting/frr/pull/138 )
> I admit that this is not necessary in order to test multipath against RTs.
RDs you mean.  Different RDs allow for route distribution of multiple
instances of the same prefix.

> I could then test ECMP with VNC.
multipath isn't needed - but it also can be used.
> I observe the following:
>
> Whatever the selection criterium on global RIB ( multipath enabled or
> not), the entry is present in vnc registration list.
> show vnc registration
>
> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
> Prefix               VN Address      UN Address      Cost Lifetime
> 11.11.0.0/16         Label: 125                      155  infinite
> 11.11.0.0/16         Label: 125                      155  infinite
>
> I was expecting something like that:
> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>    Prefix               VN Address      UN Address      Cost Lifetime
> *> 11.11.0.0/16         Label: 125                      155  infinite
>     11.11.0.0/16         Label: 125                      155  infinite
>
> If there was a command to enable multipath on the RT, I would have
> expect the following
>
> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>    Prefix               VN Address      UN Address      Cost Lifetime
> *> 11.11.0.0/16         Label: 125                      155  infinite
> =>11.11.0.0/16         Label: 125                      155  infinite
I think I need to see the output of 'show bgp ipv4 vpn' to comment. 
Right now these look like ECMP routes to me.

> Does that mean that all entries are taken into account without any
>
This like got cut off.

>> o Per VRF import/export via BGP (inside L3VPN)
> I began some testing.
>
>> o IGP import/export to single zebra
>> o API support for custom remote forwarder (NVA/NVE) protocol
>>
>>
>>>     Our plan was to add the vty functions for the VNC code once they were
>>>     agreed to by the community (background in the link provided by
>>>     Philippe).  It sounds to me that we should resume this discussion as
>>>     well as discuss this patch in an upcoming technical meeting.
>>>
>>>
>> again, see pull requests for basic support
>>
>>> From our exchange, I understand that the VNC feature implements the
>>> VRF portion of this patch.
>>> The VNC also implements the NVO3 style forwarder. You are better
>>> placed than me to talk about the VNC feature.
>>>
>>> I don't know if there are plans for supporting the next features I
>>> mention ( EVPN, VPNv6) and when ?.
>>>
>> -L2 is via non-standard BGP encoding, plan to convert to evpn once core
>> code available
>> - Support for  zebra VRFs needs to be done as part of the CLI support
>> mentioned in URL above.
> In fact, VPNv6 should already work, I guess ?
v4 and v6 have equivalent support in our code. (Unless there's a bug.)

> I understand that both features are linked : "evpn core" and "evpn
> import processing".
evpn core is your (or someone else's) code, I'm not sure what you mean
import processing we already have support for mac addresses in RFAPI,
just the BGP encoding isn't according to standard EVPN -- and it's this
encode/decode that will need to be integrated with the EVPN core code
once it's available.

>>> Also, if VNC is interesting to use, I would like to have some figures
>>> in terms of footprint or performances. What about the following usage:
>>> 10 VRFs, 1000000 prefixes, and 8 peers configured.
>>>
> I could extract some memory figures. 20000 prefixes and 40 VRFs. 
great.
> Interesting.
>
How did it look / compare to what you expected?

Lou
Philippe Guibert Jan. 31, 2017, 3:01 p.m.
Hello Lou,


On Tue, Jan 31, 2017 at 2:23 PM, Lou Berger <lberger@labn.net> wrote:

>>> https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/
>>> are now available via https://github.com/freerangerouting/frr/pulls
>> I attended lately at the meeting of 17th of january.
>> I had a question about following vty commands:
>>
>> a)
>> global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
>> [label <value>] [pref (0-255)]
>> b)
>> vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55
> I had forgotten that this command even existed -- it is ancient and IMO
> a historic appendage - deleting or moving to debug is a good idea.

I can handle it, I just need to understand the following.

> in the Jan 17 the form that was agreed to for such was to use route maps
> to set RD and to add under vrf-policy
> *
>
>     label <value> [prefix <prefix>|prefixlist <prefixlist>]
>
> **
>
> *and we don't have support for this yet.*
>
> *
>
Could you give more information, please.

If I am referring to RD/RT document, I can see that route-map keyword
has been removed.
I have some remarks:
o still possible to enter following commands. keeping all commands
would suit me:
  a)  rd <value> [prefix <prefix>|prefixlist <prefixlist>]
  b)  label <value> [prefix <prefix>|prefixlist <prefixlist>]
  c) prefix <prefix> [label <value>] [rd <value>]
o route-map seems to have been suppressed, but I think it would be ok
to integrate it with route-map.
o I would propose a 4th command under vrf-policy. Would that be acceptable ?
  c) prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
o about next-hop self | A.B.C.D | A::B::C, I am pro keeping this command
o is there a command that permits to consider the newly prefix as a
vpnv4 entry or an encap entry ( or an evpn entry )?

>> When I run a), I was expecting to have the prefix imported in the

My mistake, it was network b) : 77.11.44.0/24 rd 65:1 tag 55

>> rf_import_table 65:1.
>> Maybe there is a configuration issue, or the behaviour is not what I expect ?
> keep in mind RTs determine table while RDs control route
> selection/distribution.
> The RTs on the add command are determined by the vrf-policy of the
> <vrf-name>.  When no vrf is specified the add is to the default
> instance's unicast table.  This is really something outside of vrf
> support and not something we have (or are planning) to implement.
>
my config is the following:
vrf 65:1
 rd 65:1
 rt import 65:1
 rt export 65:1
exit-vrf-policy


>> When I run b), the prefix is imported as local, as expected.

My mistake, it was network a) : vnc add

>> Assuming b) is a command for troubleshooting, should not that command

Assuming a) vnc add

>> moved under debug rfapi-dev node ?
>
> This predates the rfapi code removing it or making a debug is a good
> idea.  Do you want to do it or should I?

I can handle it.

>>>   - Notification of adds/withdrawals (both models)
>> Are the notifications you are referring handled by the following
>> callback structure:
>> file rfapi.h, struct rfapi_rfp_cb_methods ?
>>
>> Is it possible to get some notifications when a new prefix coming from
>> a remote BGP speaker is imported ?
> yes
>> I tried to use rfp_methods.response_cb, and fp_methods.local_cb, but
>> without any success.
> you have to set these on rfapi_register and then query for mac|IP, or
> set full table download and query for anything...

I will have a look, and keep you in touch.

>> If you have a pointer to give me, you are very welcome.
>>
>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>> I made a pull request in order to support multipath for vpnvx address families.
>> ( https://github.com/freerangerouting/frr/pull/138 )
>> I admit that this is not necessary in order to test multipath against RTs.
> RDs you mean.  Different RDs allow for route distribution of multiple
> instances of the same prefix.
>
>> I could then test ECMP with VNC.

>> Whatever the selection criterium on global RIB ( multipath enabled or
>> not), the entry is present in vnc registration list.
>> show vnc registration
>>
>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>> Prefix               VN Address      UN Address      Cost Lifetime
>> 11.11.0.0/16         Label: 125                      155  infinite
>> 11.11.0.0/16         Label: 125                      155  infinite
>>

> I think I need to see the output of 'show bgp ipv4 vpn' to comment.
> Right now these look like ECMP routes to me.

The output in vnc register is the same, whatever if the route is
selected or not in show bgp ipv4 vpn entry
Here is the output

bgpd# show bgp ipv4 vpn
BGP table version is 0, local router ID is 10.125.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64603:1111
*=i11.11.0.0/16     10.10.10.1         0    100      0 i
     EC{64603:1111} label=125 type=bgp, subtype=0
*>i11.11.0.0/16     40.40.10.1         0    100      0 i
     EC{64603:1111} label=125 type=bgp, subtype=0
*>i22.22.0.0/16     20.20.10.1         0    100      0 i
     EC{64603:1111} label=125 type=bgp, subtype=0
*>i33.33.0.0/16     30.30.10.1         0    100      0 i
     EC{64603:1111} label=125 type=bgp, subtype=0
Displayed 4 routes and 5 total paths

>
>> Does that mean that all entries are taken into account without any
>>
> This like got cut off.

Does that mean that all entries are taken into account without any
best selection algorithm within the VRF ?

>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>> Prefix               VN Address      UN Address      Cost Lifetime
>> 11.11.0.0/16         Label: 125                      155  infinite
>> 11.11.0.0/16         Label: 125                      155  infinite

For instance, if in VRF RT "64603:1111", the number of paths is
limited to 1 ( no load balancing for example), then I would expect to
see one entry, not two.


>>>> mention ( EVPN, VPNv6) and when ?.
>>>>
>> In fact, VPNv6 should already work, I guess ?
> v4 and v6 have equivalent support in our code. (Unless there's a bug.)

In fact, I could make VPNv6 work.

1002::/64            Label: 676                      155  infinite



>> I understand that both features are linked : "evpn core" and "evpn
>> import processing".
> evpn core is your (or someone else's) code, I'm not sure what you mean
> import processing we already have support for mac addresses in RFAPI,

evpn import processing stands for work to be done for VNC to handle
VRF import processing for EVPN.

> just the BGP encoding isn't according to standard EVPN -- and it's this
> encode/decode that will need to be integrated with the EVPN core code
> once it's available.
>
>>>> Also, if VNC is interesting to use, I would like to have some figures
>>>> in terms of footprint or performances. What about the following usage:
>>>> 10 VRFs, 1000000 prefixes, and 8 peers configured.
>>>>
>> I could extract some memory figures. 20000 prefixes and 40 VRFs.
> great.
>> Interesting.
>>
> How did it look / compare to what you expected?

Actually, the VNC implementation is heavier in terms of memory ( for
1M routes, I have had 1,8GB memory consumed versus 1,3GB for the other
implementation ofVRF import processing). But I think we have to
consider the whole set of other features that VNC brings.

I would like to do the performance measurements, but for that, I would
like to measure  it with capnproto interface attached to VNC. So more
work to do before.

>
> Lou
Philippe Guibert Feb. 3, 2017, 8:33 a.m.
Hello Lou, all,

coming back to you, I need some answers, please.

a) about the "network" configuration command per vrf-policy
Because network command under address-family would be replaced by an
other command under vrf-policy.

- I did not see all options on RD/RT document I would expect.
IMHO, prefix parameter is not an option, and it should be possible to
provision a whole set of prefixes per vrf-policy.

configuration example:

config term
router bgp ....
 vrf-policy <vrf-name>
    rd <value> [prefix <prefix>|prefixlist <prefixlist>]
    label <value> [prefix <prefix>|prefixlist <prefixlist>]
    route-target <import|export|both> <value>
    !use routemap to change
    nexthop <ip-addr|ipv6-addr|self>
    prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
           <---- command moved from afi/safi node to vrf-policy

- Per extension, I would also expect a command that mentions the
signalisation transport method ?
If I set a prefix, how can I force the prefix to be advertised by
VPNvx or EVPN ?

I would expect such a command to request the transport method

config term
router bgp ....
 vrf-policy <vrf-name>
    transport vpn | evpn | encap


b) about the multipath case.
From the previous mail example, I observe that show vnc registration
takes into account all incoming NLRIs.
How can vrf-policy so as to configure VRF RIB to enable/disable multipath ?

When ECMP NLRIs are encountered, how can the VRF RIB differentiate the
case that I want to do Load Balancing or not ?

I would expect such a command to influence the multipath case
config term
router bgp ....
 vrf-policy <vrf-name>
   maximum-path <1-64>                       <--- command added


Best Regards,

Philippe

On Tue, Jan 31, 2017 at 4:01 PM, Philippe Guibert
<philippe.guibert@6wind.com> wrote:
> Hello Lou,
>
>
> On Tue, Jan 31, 2017 at 2:23 PM, Lou Berger <lberger@labn.net> wrote:
>
>>>> https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/
>>>> are now available via https://github.com/freerangerouting/frr/pulls
>>> I attended lately at the meeting of 17th of january.
>>> I had a question about following vty commands:
>>>
>>> a)
>>> global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
>>> [label <value>] [pref (0-255)]
>>> b)
>>> vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55
>> I had forgotten that this command even existed -- it is ancient and IMO
>> a historic appendage - deleting or moving to debug is a good idea.
>
> I can handle it, I just need to understand the following.
>
>> in the Jan 17 the form that was agreed to for such was to use route maps
>> to set RD and to add under vrf-policy
>> *
>>
>>     label <value> [prefix <prefix>|prefixlist <prefixlist>]
>>
>> **
>>
>> *and we don't have support for this yet.*
>>
>> *
>>
> Could you give more information, please.
>
> If I am referring to RD/RT document, I can see that route-map keyword
> has been removed.
> I have some remarks:
> o still possible to enter following commands. keeping all commands
> would suit me:
>   a)  rd <value> [prefix <prefix>|prefixlist <prefixlist>]
>   b)  label <value> [prefix <prefix>|prefixlist <prefixlist>]
>   c) prefix <prefix> [label <value>] [rd <value>]
> o route-map seems to have been suppressed, but I think it would be ok
> to integrate it with route-map.
> o I would propose a 4th command under vrf-policy. Would that be acceptable ?
>   c) prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
> o about next-hop self | A.B.C.D | A::B::C, I am pro keeping this command
> o is there a command that permits to consider the newly prefix as a
> vpnv4 entry or an encap entry ( or an evpn entry )?
>
>>> When I run a), I was expecting to have the prefix imported in the
>
> My mistake, it was network b) : 77.11.44.0/24 rd 65:1 tag 55
>
>>> rf_import_table 65:1.
>>> Maybe there is a configuration issue, or the behaviour is not what I expect ?
>> keep in mind RTs determine table while RDs control route
>> selection/distribution.
>> The RTs on the add command are determined by the vrf-policy of the
>> <vrf-name>.  When no vrf is specified the add is to the default
>> instance's unicast table.  This is really something outside of vrf
>> support and not something we have (or are planning) to implement.
>>
> my config is the following:
> vrf 65:1
>  rd 65:1
>  rt import 65:1
>  rt export 65:1
> exit-vrf-policy
>
>
>>> When I run b), the prefix is imported as local, as expected.
>
> My mistake, it was network a) : vnc add
>
>>> Assuming b) is a command for troubleshooting, should not that command
>
> Assuming a) vnc add
>
>>> moved under debug rfapi-dev node ?
>>
>> This predates the rfapi code removing it or making a debug is a good
>> idea.  Do you want to do it or should I?
>
> I can handle it.
>
>>>>   - Notification of adds/withdrawals (both models)
>>> Are the notifications you are referring handled by the following
>>> callback structure:
>>> file rfapi.h, struct rfapi_rfp_cb_methods ?
>>>
>>> Is it possible to get some notifications when a new prefix coming from
>>> a remote BGP speaker is imported ?
>> yes
>>> I tried to use rfp_methods.response_cb, and fp_methods.local_cb, but
>>> without any success.
>> you have to set these on rfapi_register and then query for mac|IP, or
>> set full table download and query for anything...
>
> I will have a look, and keep you in touch.
>
>>> If you have a pointer to give me, you are very welcome.
>>>
>>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>>> I made a pull request in order to support multipath for vpnvx address families.
>>> ( https://github.com/freerangerouting/frr/pull/138 )
>>> I admit that this is not necessary in order to test multipath against RTs.
>> RDs you mean.  Different RDs allow for route distribution of multiple
>> instances of the same prefix.
>>
>>> I could then test ECMP with VNC.
>
>>> Whatever the selection criterium on global RIB ( multipath enabled or
>>> not), the entry is present in vnc registration list.
>>> show vnc registration
>>>
>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>> Prefix               VN Address      UN Address      Cost Lifetime
>>> 11.11.0.0/16         Label: 125                      155  infinite
>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>
>
>> I think I need to see the output of 'show bgp ipv4 vpn' to comment.
>> Right now these look like ECMP routes to me.
>
> The output in vnc register is the same, whatever if the route is
> selected or not in show bgp ipv4 vpn entry
> Here is the output
>
> bgpd# show bgp ipv4 vpn
> BGP table version is 0, local router ID is 10.125.0.1
> Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
> Origin codes: i - IGP, e - EGP, ? - incomplete
>    Network          Next Hop            Metric LocPrf Weight Path
> Route Distinguisher: 64603:1111
> *=i11.11.0.0/16     10.10.10.1         0    100      0 i
>      EC{64603:1111} label=125 type=bgp, subtype=0
> *>i11.11.0.0/16     40.40.10.1         0    100      0 i
>      EC{64603:1111} label=125 type=bgp, subtype=0
> *>i22.22.0.0/16     20.20.10.1         0    100      0 i
>      EC{64603:1111} label=125 type=bgp, subtype=0
> *>i33.33.0.0/16     30.30.10.1         0    100      0 i
>      EC{64603:1111} label=125 type=bgp, subtype=0
> Displayed 4 routes and 5 total paths
>
>>
>>> Does that mean that all entries are taken into account without any
>>>
>> This like got cut off.
>
> Does that mean that all entries are taken into account without any
> best selection algorithm within the VRF ?
>
>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>> Prefix               VN Address      UN Address      Cost Lifetime
>>> 11.11.0.0/16         Label: 125                      155  infinite
>>> 11.11.0.0/16         Label: 125                      155  infinite
>
> For instance, if in VRF RT "64603:1111", the number of paths is
> limited to 1 ( no load balancing for example), then I would expect to
> see one entry, not two.
>
>
>>>>> mention ( EVPN, VPNv6) and when ?.
>>>>>
>>> In fact, VPNv6 should already work, I guess ?
>> v4 and v6 have equivalent support in our code. (Unless there's a bug.)
>
> In fact, I could make VPNv6 work.
>
> 1002::/64            Label: 676                      155  infinite
>
>
>
>>> I understand that both features are linked : "evpn core" and "evpn
>>> import processing".
>> evpn core is your (or someone else's) code, I'm not sure what you mean
>> import processing we already have support for mac addresses in RFAPI,
>
> evpn import processing stands for work to be done for VNC to handle
> VRF import processing for EVPN.
>
>> just the BGP encoding isn't according to standard EVPN -- and it's this
>> encode/decode that will need to be integrated with the EVPN core code
>> once it's available.
>>
>>>>> Also, if VNC is interesting to use, I would like to have some figures
>>>>> in terms of footprint or performances. What about the following usage:
>>>>> 10 VRFs, 1000000 prefixes, and 8 peers configured.
>>>>>
>>> I could extract some memory figures. 20000 prefixes and 40 VRFs.
>> great.
>>> Interesting.
>>>
>> How did it look / compare to what you expected?
>
> Actually, the VNC implementation is heavier in terms of memory ( for
> 1M routes, I have had 1,8GB memory consumed versus 1,3GB for the other
> implementation ofVRF import processing). But I think we have to
> consider the whole set of other features that VNC brings.
>
> I would like to do the performance measurements, but for that, I would
> like to measure  it with capnproto interface attached to VNC. So more
> work to do before.
>
>>
>> Lou
Lou Berger Feb. 3, 2017, 11:16 a.m.
Philippe


On January 31, 2017 10:10:34 AM Philippe Guibert 
<philippe.guibert@6wind.com> wrote:

> Hello Lou,
>
>
> On Tue, Jan 31, 2017 at 2:23 PM, Lou Berger <lberger@labn.net> wrote:
>
>>>> https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/
>>>> are now available via https://github.com/freerangerouting/frr/pulls
>>> I attended lately at the meeting of 17th of january.
>>> I had a question about following vty commands:
>>>
>>> a)
>>> global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
>>> [label <value>] [pref (0-255)]
>>> b)
>>> vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55
>> I had forgotten that this command even existed -- it is ancient and IMO
>> a historic appendage - deleting or moving to debug is a good idea.
>
> I can handle it, I just need to understand the following.
>

Thanks!

>> in the Jan 17 the form that was agreed to for such was to use route maps
>> to set RD and to add under vrf-policy
>> *
>>
>>     label <value> [prefix <prefix>|prefixlist <prefixlist>]
>>
>> **
>>
>> *and we don't have support for this yet.*
>>
>> *
>>
> Could you give more information, please.
>
> If I am referring to RD/RT document, I can see that route-map keyword
> has been removed.
> I have some remarks:
> o still possible to enter following commands. keeping all commands
> would suit me:
>   a)  rd <value> [prefix <prefix>|prefixlist <prefixlist>]
>   b)  label <value> [prefix <prefix>|prefixlist <prefixlist>]
>   c) prefix <prefix> [label <value>] [rd <value>]
> o route-map seems to have been suppressed, but I think it would be ok
> to integrate it with route-map.
> o I would propose a 4th command under vrf-policy. Would that be acceptable ?
>   c) prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
> o about next-hop self | A.B.C.D | A::B::C, I am pro keeping this command
> o is there a command that permits to consider the newly prefix as a
> vpnv4 entry or an encap entry ( or an evpn entry )?
>

As I understood the group consensus on the call, specific routes would be 
learned/configured in the context of a vrf (under bgp <as> vrf <vrf>) and 
specific  RDs and the typical attributes could be set using typical route 
map operations. -- here's the related portion for the Google doc:

router bgp XXX vrf <vrf-name>
   ! (address-family ipv4)
   network  1.2.3.0/24 route-map foo
   neighbor ... ! CE session (or alternately, VRF-lite session)
   !make vrf redistribution (import/export)the default
   redistribute static|ospf|vrf [route map] ...! CE setup for OSPF
   no redistribute vrf
   no export vrf
   export vrf [route map] ...


>>> When I run a), I was expecting to have the prefix imported in the
>
> My mistake, it was network b) : 77.11.44.0/24 rd 65:1 tag 55
>
>>> rf_import_table 65:1.
>>> Maybe there is a configuration issue, or the behaviour is not what I expect ?
>> keep in mind RTs determine table while RDs control route
>> selection/distribution.
>> The RTs on the add command are determined by the vrf-policy of the
>> <vrf-name>.  When no vrf is specified the add is to the default
>> instance's unicast table.  This is really something outside of vrf
>> support and not something we have (or are planning) to implement.
>>
> my config is the following:
> vrf 65:1
>  rd 65:1
>  rt import 65:1
>  rt export 65:1
> exit-vrf-policy
>
>
>>> When I run b), the prefix is imported as local, as expected.
>
> My mistake, it was network a) : vnc add
>
>>> Assuming b) is a command for troubleshooting, should not that command
>
> Assuming a) vnc add
>
>>> moved under debug rfapi-dev node ?
>>
>> This predates the rfapi code removing it or making a debug is a good
>> idea.  Do you want to do it or should I?
>
> I can handle it.
>

Thank you!

>>>>   - Notification of adds/withdrawals (both models)
>>> Are the notifications you are referring handled by the following
>>> callback structure:
>>> file rfapi.h, struct rfapi_rfp_cb_methods ?
>>>
>>> Is it possible to get some notifications when a new prefix coming from
>>> a remote BGP speaker is imported ?
>> yes
>>> I tried to use rfp_methods.response_cb, and fp_methods.local_cb, but
>>> without any success.
>> you have to set these on rfapi_register and then query for mac|IP, or
>> set full table download and query for anything...
>
> I will have a look, and keep you in touch.
>

I did find on issue related to mpls call backs in reviewing / retesting the 
code and this has been pushed.  Other tunnel types should have worked.

>>> If you have a pointer to give me, you are very welcome.
>>>
>>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>>> I made a pull request in order to support multipath for vpnvx address families.
>>> ( https://github.com/freerangerouting/frr/pull/138 )
>>> I admit that this is not necessary in order to test multipath against RTs.
>> RDs you mean.  Different RDs allow for route distribution of multiple
>> instances of the same prefix.
>>
>>> I could then test ECMP with VNC.
>
>>> Whatever the selection criterium on global RIB ( multipath enabled or
>>> not), the entry is present in vnc registration list.
>>> show vnc registration
>>>
>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>> Prefix               VN Address      UN Address      Cost Lifetime
>>> 11.11.0.0/16         Label: 125                      155  infinite
>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>
>
>> I think I need to see the output of 'show bgp ipv4 vpn' to comment.
>> Right now these look like ECMP routes to me.
>
> The output in vnc register is the same, whatever if the route is
> selected or not in show bgp ipv4 vpn entry

The rfapi does order the prefixes on query call back based on preference, 
but it up to the call back code to decide if only the best route is used.  
This was explicitly done to support multi/and backup path forwarding.

Again the output you were expecting is here:

> Here is the output
>
> bgpd# show bgp ipv4 vpn
> BGP table version is 0, local router ID is 10.125.0.1
> Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
> Origin codes: i - IGP, e - EGP, ? - incomplete
>    Network          Next Hop            Metric LocPrf Weight Path
> Route Distinguisher: 64603:1111
> *=i11.11.0.0/16     10.10.10.1         0    100      0 i
>      EC{64603:1111} label=125 type=bgp, subtype=0
> *>i11.11.0.0/16     40.40.10.1         0    100      0 i
>      EC{64603:1111} label=125 type=bgp, subtype=0
> *>i22.22.0.0/16     20.20.10.1         0    100      0 i
>      EC{64603:1111} label=125 type=bgp, subtype=0
> *>i33.33.0.0/16     30.30.10.1         0    100      0 i
>      EC{64603:1111} label=125 type=bgp, subtype=0
> Displayed 4 routes and 5 total paths
>
>>
>>> Does that mean that all entries are taken into account without any
>>>
>> This like got cut off.
>
> Does that mean that all entries are taken into account without any
> best selection algorithm within the VRF ?
>

No they are ordered and available for downstream processing / selection by 
the rfp code.

>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>> Prefix               VN Address      UN Address      Cost Lifetime
>>> 11.11.0.0/16         Label: 125                      155  infinite
>>> 11.11.0.0/16         Label: 125                      155  infinite
>
> For instance, if in VRF RT "64603:1111", the number of paths is
> limited to 1 ( no load balancing for example), then I would expect to
> see one entry, not two.
>
Well both show in the show vrf command too - this command is there to show 
all state.

>
>>>>> mention ( EVPN, VPNv6) and when ?.
>>>>>
>>> In fact, VPNv6 should already work, I guess ?
>> v4 and v6 have equivalent support in our code. (Unless there's a bug.)
>
> In fact, I could make VPNv6 work.
>
> 1002::/64            Label: 676                      155  infinite
>
>

Great.
>
>>> I understand that both features are linked : "evpn core" and "evpn
>>> import processing".
>> evpn core is your (or someone else's) code, I'm not sure what you mean
>> import processing we already have support for mac addresses in RFAPI,
>
> evpn import processing stands for work to be done for VNC to handle
> VRF import processing for EVPN.
>

I still don't follow - sorry.

>> just the BGP encoding isn't according to standard EVPN -- and it's this
>> encode/decode that will need to be integrated with the EVPN core code
>> once it's available.
>>
>>>>> Also, if VNC is interesting to use, I would like to have some figures
>>>>> in terms of footprint or performances. What about the following usage:
>>>>> 10 VRFs, 1000000 prefixes, and 8 peers configured.
>>>>>
>>> I could extract some memory figures. 20000 prefixes and 40 VRFs.
>> great.
>>> Interesting.
>>>
>> How did it look / compare to what you expected?
>
> Actually, the VNC implementation is heavier in terms of memory ( for
> 1M routes, I have had 1,8GB memory consumed versus 1,3GB for the other
> implementation ofVRF import processing). But I think we have to
> consider the whole set of other features that VNC brings.
>

Interesting.  I'll go lookup what we're seeing...

> I would like to do the performance measurements, but for that, I would
> like to measure  it with capnproto interface attached to VNC. So more
> work to do before.
>

Look forward to hearing the results.

Lou
>>
>> Lou
>
Lou Berger Feb. 3, 2017, 11:19 a.m.
Philippe,

Please see the mail I just sent.  It also sounds like you enough questions 
on the rd/RT config discussed that we should revisit it on a future call.

Lou


On February 3, 2017 3:34:08 AM Philippe Guibert 
<philippe.guibert@6wind.com> wrote:

> Hello Lou, all,
>
> coming back to you, I need some answers, please.
>
> a) about the "network" configuration command per vrf-policy
> Because network command under address-family would be replaced by an
> other command under vrf-policy.
>
> - I did not see all options on RD/RT document I would expect.
> IMHO, prefix parameter is not an option, and it should be possible to
> provision a whole set of prefixes per vrf-policy.
>
> configuration example:
>
> config term
> router bgp ....
>  vrf-policy <vrf-name>
>     rd <value> [prefix <prefix>|prefixlist <prefixlist>]
>     label <value> [prefix <prefix>|prefixlist <prefixlist>]
>     route-target <import|export|both> <value>
>     !use routemap to change
>     nexthop <ip-addr|ipv6-addr|self>
>     prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
>            <---- command moved from afi/safi node to vrf-policy
>
> - Per extension, I would also expect a command that mentions the
> signalisation transport method ?
> If I set a prefix, how can I force the prefix to be advertised by
> VPNvx or EVPN ?
>
> I would expect such a command to request the transport method
>
> config term
> router bgp ....
>  vrf-policy <vrf-name>
>     transport vpn | evpn | encap
>
>
> b) about the multipath case.
> From the previous mail example, I observe that show vnc registration
> takes into account all incoming NLRIs.
> How can vrf-policy so as to configure VRF RIB to enable/disable multipath ?
>
> When ECMP NLRIs are encountered, how can the VRF RIB differentiate the
> case that I want to do Load Balancing or not ?
>
> I would expect such a command to influence the multipath case
> config term
> router bgp ....
>  vrf-policy <vrf-name>
>    maximum-path <1-64>                       <--- command added
>
>
> Best Regards,
>
> Philippe
>
> On Tue, Jan 31, 2017 at 4:01 PM, Philippe Guibert
> <philippe.guibert@6wind.com> wrote:
>> Hello Lou,
>>
>>
>> On Tue, Jan 31, 2017 at 2:23 PM, Lou Berger <lberger@labn.net> wrote:
>>
>>>>> https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/
>>>>> are now available via https://github.com/freerangerouting/frr/pulls
>>>> I attended lately at the meeting of 17th of january.
>>>> I had a question about following vty commands:
>>>>
>>>> a)
>>>> global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
>>>> [label <value>] [pref (0-255)]
>>>> b)
>>>> vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55
>>> I had forgotten that this command even existed -- it is ancient and IMO
>>> a historic appendage - deleting or moving to debug is a good idea.
>>
>> I can handle it, I just need to understand the following.
>>
>>> in the Jan 17 the form that was agreed to for such was to use route maps
>>> to set RD and to add under vrf-policy
>>> *
>>>
>>>     label <value> [prefix <prefix>|prefixlist <prefixlist>]
>>>
>>> **
>>>
>>> *and we don't have support for this yet.*
>>>
>>> *
>>>
>> Could you give more information, please.
>>
>> If I am referring to RD/RT document, I can see that route-map keyword
>> has been removed.
>> I have some remarks:
>> o still possible to enter following commands. keeping all commands
>> would suit me:
>>   a)  rd <value> [prefix <prefix>|prefixlist <prefixlist>]
>>   b)  label <value> [prefix <prefix>|prefixlist <prefixlist>]
>>   c) prefix <prefix> [label <value>] [rd <value>]
>> o route-map seems to have been suppressed, but I think it would be ok
>> to integrate it with route-map.
>> o I would propose a 4th command under vrf-policy. Would that be acceptable ?
>>   c) prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
>> o about next-hop self | A.B.C.D | A::B::C, I am pro keeping this command
>> o is there a command that permits to consider the newly prefix as a
>> vpnv4 entry or an encap entry ( or an evpn entry )?
>>
>>>> When I run a), I was expecting to have the prefix imported in the
>>
>> My mistake, it was network b) : 77.11.44.0/24 rd 65:1 tag 55
>>
>>>> rf_import_table 65:1.
>>>> Maybe there is a configuration issue, or the behaviour is not what I expect ?
>>> keep in mind RTs determine table while RDs control route
>>> selection/distribution.
>>> The RTs on the add command are determined by the vrf-policy of the
>>> <vrf-name>.  When no vrf is specified the add is to the default
>>> instance's unicast table.  This is really something outside of vrf
>>> support and not something we have (or are planning) to implement.
>>>
>> my config is the following:
>> vrf 65:1
>>  rd 65:1
>>  rt import 65:1
>>  rt export 65:1
>> exit-vrf-policy
>>
>>
>>>> When I run b), the prefix is imported as local, as expected.
>>
>> My mistake, it was network a) : vnc add
>>
>>>> Assuming b) is a command for troubleshooting, should not that command
>>
>> Assuming a) vnc add
>>
>>>> moved under debug rfapi-dev node ?
>>>
>>> This predates the rfapi code removing it or making a debug is a good
>>> idea.  Do you want to do it or should I?
>>
>> I can handle it.
>>
>>>>>   - Notification of adds/withdrawals (both models)
>>>> Are the notifications you are referring handled by the following
>>>> callback structure:
>>>> file rfapi.h, struct rfapi_rfp_cb_methods ?
>>>>
>>>> Is it possible to get some notifications when a new prefix coming from
>>>> a remote BGP speaker is imported ?
>>> yes
>>>> I tried to use rfp_methods.response_cb, and fp_methods.local_cb, but
>>>> without any success.
>>> you have to set these on rfapi_register and then query for mac|IP, or
>>> set full table download and query for anything...
>>
>> I will have a look, and keep you in touch.
>>
>>>> If you have a pointer to give me, you are very welcome.
>>>>
>>>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>>>> I made a pull request in order to support multipath for vpnvx address families.
>>>> ( https://github.com/freerangerouting/frr/pull/138 )
>>>> I admit that this is not necessary in order to test multipath against RTs.
>>> RDs you mean.  Different RDs allow for route distribution of multiple
>>> instances of the same prefix.
>>>
>>>> I could then test ECMP with VNC.
>>
>>>> Whatever the selection criterium on global RIB ( multipath enabled or
>>>> not), the entry is present in vnc registration list.
>>>> show vnc registration
>>>>
>>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>>> Prefix               VN Address      UN Address      Cost Lifetime
>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>>
>>
>>> I think I need to see the output of 'show bgp ipv4 vpn' to comment.
>>> Right now these look like ECMP routes to me.
>>
>> The output in vnc register is the same, whatever if the route is
>> selected or not in show bgp ipv4 vpn entry
>> Here is the output
>>
>> bgpd# show bgp ipv4 vpn
>> BGP table version is 0, local router ID is 10.125.0.1
>> Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>    Network          Next Hop            Metric LocPrf Weight Path
>> Route Distinguisher: 64603:1111
>> *=i11.11.0.0/16     10.10.10.1         0    100      0 i
>>      EC{64603:1111} label=125 type=bgp, subtype=0
>> *>i11.11.0.0/16     40.40.10.1         0    100      0 i
>>      EC{64603:1111} label=125 type=bgp, subtype=0
>> *>i22.22.0.0/16     20.20.10.1         0    100      0 i
>>      EC{64603:1111} label=125 type=bgp, subtype=0
>> *>i33.33.0.0/16     30.30.10.1         0    100      0 i
>>      EC{64603:1111} label=125 type=bgp, subtype=0
>> Displayed 4 routes and 5 total paths
>>
>>>
>>>> Does that mean that all entries are taken into account without any
>>>>
>>> This like got cut off.
>>
>> Does that mean that all entries are taken into account without any
>> best selection algorithm within the VRF ?
>>
>>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>>> Prefix               VN Address      UN Address      Cost Lifetime
>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>
>> For instance, if in VRF RT "64603:1111", the number of paths is
>> limited to 1 ( no load balancing for example), then I would expect to
>> see one entry, not two.
>>
>>
>>>>>> mention ( EVPN, VPNv6) and when ?.
>>>>>>
>>>> In fact, VPNv6 should already work, I guess ?
>>> v4 and v6 have equivalent support in our code. (Unless there's a bug.)
>>
>> In fact, I could make VPNv6 work.
>>
>> 1002::/64            Label: 676                      155  infinite
>>
>>
>>
>>>> I understand that both features are linked : "evpn core" and "evpn
>>>> import processing".
>>> evpn core is your (or someone else's) code, I'm not sure what you mean
>>> import processing we already have support for mac addresses in RFAPI,
>>
>> evpn import processing stands for work to be done for VNC to handle
>> VRF import processing for EVPN.
>>
>>> just the BGP encoding isn't according to standard EVPN -- and it's this
>>> encode/decode that will need to be integrated with the EVPN core code
>>> once it's available.
>>>
>>>>>> Also, if VNC is interesting to use, I would like to have some figures
>>>>>> in terms of footprint or performances. What about the following usage:
>>>>>> 10 VRFs, 1000000 prefixes, and 8 peers configured.
>>>>>>
>>>> I could extract some memory figures. 20000 prefixes and 40 VRFs.
>>> great.
>>>> Interesting.
>>>>
>>> How did it look / compare to what you expected?
>>
>> Actually, the VNC implementation is heavier in terms of memory ( for
>> 1M routes, I have had 1,8GB memory consumed versus 1,3GB for the other
>> implementation ofVRF import processing). But I think we have to
>> consider the whole set of other features that VNC brings.
>>
>> I would like to do the performance measurements, but for that, I would
>> like to measure  it with capnproto interface attached to VNC. So more
>> work to do before.
>>
>>>
>>> Lou
>
Philippe Guibert Feb. 6, 2017, 9:45 a.m.
Hello Lou, all,

On Fri, Feb 3, 2017 at 12:16 PM, Lou Berger <lberger@labn.net> wrote:
>>>> a)
>>>> global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
>>>> [label <value>] [pref (0-255)]
>>>> b)
>>>> vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55
>>>
>>> I had forgotten that this command even existed -- it is ancient and IMO
>>> a historic appendage - deleting or moving to debug is a good idea.
>>
>>
>> I can handle it, I just need to understand the following.
>>
>
> Thanks!

I mean, I need to be able to configure prefixes before suppressing the
command :-).



>> If I am referring to RD/RT document, I can see that route-map keyword
>> has been removed.
>> I have some remarks:
>> o still possible to enter following commands. keeping all commands
>> would suit me:
>>   a)  rd <value> [prefix <prefix>|prefixlist <prefixlist>]
>>   b)  label <value> [prefix <prefix>|prefixlist <prefixlist>]
>>   c) prefix <prefix> [label <value>] [rd <value>]
>> o route-map seems to have been suppressed, but I think it would be ok
>> to integrate it with route-map.
>> o I would propose a 4th command under vrf-policy. Would that be acceptable
>> ?
>>   c) prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
>> o about next-hop self | A.B.C.D | A::B::C, I am pro keeping this command
>> o is there a command that permits to consider the newly prefix as a
>> vpnv4 entry or an encap entry ( or an evpn entry )?
>>
>
> As I understood the group consensus on the call, specific routes would be
> learned/configured in the context of a vrf (under bgp <as> vrf <vrf>) and
> specific  RDs and the typical attributes could be set using typical route
> map operations. -- here's the related portion for the Google doc:
>


> router bgp XXX vrf <vrf-name>
>    ! (address-family ipv4)
>    network  1.2.3.0/24 route-map foo
>    neighbor ... ! CE session (or alternately, VRF-lite session)
>    !make vrf redistribution (import/export)the default
>    redistribute static|ospf|vrf [route map] ...! CE setup for OSPF
>    no redistribute vrf
>    no export vrf
>    export vrf [route map] ...

This solution fits with one BGP instance per VRF.
I agree for that.

But the solution is not enough.
It does not fit with one BGP instance for multiple VRF handling.

Is there any group consensus about supporting the following:
specific routes to be added in the context of a VRF-policy by using
following configuration method:

router bgp <ID>
 vrf-policy <vrf-policy-name>
   rd <>
   label <>
   rt import <>
   rt export <>
  prefix <prefix> [label <value>] [nexthop <value>]
exit-vrf-policy

Adding to the review, I would also expect a command that mentions the
signalisation transport method ?
If I set a prefix, how can I force the prefix to be advertised by
VPNvx or EVPN ?
In the EVPN Route type 5 method, the same

config term
router bgp ....
 vrf-policy <vrf-name>
    transport vpn | evpn | encap


>>>> moved under debug rfapi-dev node ?
>>>
>>>
>>> This predates the rfapi code removing it or making a debug is a good
>>> idea.  Do you want to do it or should I?
>>

See https://github.com/freerangerouting/frr/pull/168


>
>>>>>   - Notification of adds/withdrawals (both models)
>>
> I did find on issue related to mpls call backs in reviewing / retesting the
> code and this has been pushed.  Other tunnel types should have worked.
>
I will check. Thanks.

>>>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>>>>
>>>> I could then test ECMP with VNC.
>>>> Whatever the selection criterium on global RIB ( multipath enabled or
>>>> not), the entry is present in vnc registration list.
>>>> show vnc registration
>>>>
>>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>>> Prefix               VN Address      UN Address      Cost Lifetime
>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>>

> The rfapi does order the prefixes on query call back based on preference,

By using preference on BGP, the entries will not be considered as ECMP.

> but it up to the call back code to decide if only the best route is used.
> This was explicitly done to support multi/and backup path forwarding.

1) If I understand correctly, if it is up to the call back code, then
I understand following scenario should be implemented:

On my case, the call back should instantiate a VRF RIB table.
When ECMP entries are detected, an algorithm in the callback should be
triggered to know which ECMP entry is valid.
If there is a preference set that is greater in one of the ECMP
entries, then it will be selected.
If there is no preference difference, the difference will be based on
the underlay nexthop attribute.

Reversely,  if a route is withdrawn, notitication call back would be
called. an algorithm in the callback should be triggered too to know
if there are still ECMP entries or not.
If the entry with the best preference disappears, then the entry with
the least preference would be selected.


2) I would prefer having an internal implementation of BGP best
selection algorithm, and configure then notifications so as to inform
only the selected entries.
It would avoid having a second VRF RIB instance implemented in a second place.
If I have a preference set for one route more than one other route,
then only the preferred entry would be sent to the notification.

For 2), I would need :
- a vrt command to configure multipath per vrf-policy
config term
router bgp ....
 vrf-policy <vrf-name>
    transport vpn | evpn | encap
- a vty command to change the notification procedure.
config term
router bgp ....
 ## callbacks would be advertised
 ## new entries that are set as selected ( ECMP or best prefrence for example)
 ## removed entries that are set as unselected ( entries that are no
more unselected because of a new selected entry with best preference)
 vnc notification only-selected
 ## show vnc registration would show only the selected one
  vnc display only-selected

Waiting for suggestions,




>
> Again the output you were expecting is here:
>
>> Here is the output
>>
>> bgpd# show bgp ipv4 vpn
>> BGP table version is 0, local router ID is 10.125.0.1
>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> internal
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>    Network          Next Hop            Metric LocPrf Weight Path
>> Route Distinguisher: 64603:1111
>> *=i11.11.0.0/16     10.10.10.1         0    100      0 i
>>      EC{64603:1111} label=125 type=bgp, subtype=0
>> *>i11.11.0.0/16     40.40.10.1         0    100      0 i
>>      EC{64603:1111} label=125 type=bgp, subtype=0
>> *>i22.22.0.0/16     20.20.10.1         0    100      0 i
>>      EC{64603:1111} label=125 type=bgp, subtype=0
>> *>i33.33.0.0/16     30.30.10.1         0    100      0 i
>>      EC{64603:1111} label=125 type=bgp, subtype=0
>> Displayed 4 routes and 5 total paths
>>
>>>
>>>> Does that mean that all entries are taken into account without any
>>>>
>>> This like got cut off.
>>
>>
>> Does that mean that all entries are taken into account without any
>> best selection algorithm within the VRF ?
>>
>
> No they are ordered and available for downstream processing / selection by
> the rfp code.
>

Best Regards,

Philippe
Lou Berger Feb. 6, 2017, 11:32 a.m.
Philippe


On February 6, 2017 4:46:14 AM Philippe Guibert 
<philippe.guibert@6wind.com> wrote:

> Hello Lou, all,
>
> On Fri, Feb 3, 2017 at 12:16 PM, Lou Berger <lberger@labn.net> wrote:
>>>>> a)
>>>>> global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
>>>>> [label <value>] [pref (0-255)]
>>>>> b)
>>>>> vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55
>>>>
>>>> I had forgotten that this command even existed -- it is ancient and IMO
>>>> a historic appendage - deleting or moving to debug is a good idea.
>>>
>>>
>>> I can handle it, I just need to understand the following.
>>>
>>
>> Thanks!
>
> I mean, I need to be able to configure prefixes before suppressing the
> command :-).
>
>
>
>>> If I am referring to RD/RT document, I can see that route-map keyword
>>> has been removed.
>>> I have some remarks:
>>> o still possible to enter following commands. keeping all commands
>>> would suit me:
>>>   a)  rd <value> [prefix <prefix>|prefixlist <prefixlist>]
>>>   b)  label <value> [prefix <prefix>|prefixlist <prefixlist>]
>>>   c) prefix <prefix> [label <value>] [rd <value>]
>>> o route-map seems to have been suppressed, but I think it would be ok
>>> to integrate it with route-map.
>>> o I would propose a 4th command under vrf-policy. Would that be acceptable
>>> ?
>>>   c) prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
>>> o about next-hop self | A.B.C.D | A::B::C, I am pro keeping this command
>>> o is there a command that permits to consider the newly prefix as a
>>> vpnv4 entry or an encap entry ( or an evpn entry )?
>>>
>>
>> As I understood the group consensus on the call, specific routes would be
>> learned/configured in the context of a vrf (under bgp <as> vrf <vrf>) and
>> specific  RDs and the typical attributes could be set using typical route
>> map operations. -- here's the related portion for the Google doc:
>>
>
>
>> router bgp XXX vrf <vrf-name>
>>    ! (address-family ipv4)
>>    network  1.2.3.0/24 route-map foo
>>    neighbor ... ! CE session (or alternately, VRF-lite session)
>>    !make vrf redistribution (import/export)the default
>>    redistribute static|ospf|vrf [route map] ...! CE setup for OSPF
>>    no redistribute vrf
>>    no export vrf
>>    export vrf [route map] ...
>
> This solution fits with one BGP instance per VRF.
> I agree for that.
>
> But the solution is not enough.
> It does not fit with one BGP instance for multiple VRF handling.
>
> Is there any group consensus about supporting the following:
> specific routes to be added in the context of a VRF-policy by using
> following configuration method:
>
> router bgp <ID>
>  vrf-policy <vrf-policy-name>
>    rd <>
>    label <>
>    rt import <>
>    rt export <>
>   prefix <prefix> [label <value>] [nexthop <value>]
> exit-vrf-policy
>

This should be discussed on a future call IMO.

> Adding to the review, I would also expect a command that mentions the
> signalisation transport method ?
> If I set a prefix, how can I force the prefix to be advertised by
> VPNvx or EVPN ?
> In the EVPN Route type 5 method, the same
>
> config term
> router bgp ....
>  vrf-policy <vrf-name>
>     transport vpn | evpn | encap
>

Vpn and encap are not orthognol.  The code currently supports vpn and 
vpn+encap and more commands are needed for the encap case.

>
>>>>> moved under debug rfapi-dev node ?
>>>>
>>>>
>>>> This predates the rfapi code removing it or making a debug is a good
>>>> idea.  Do you want to do it or should I?
>>>
>
> See https://github.com/freerangerouting/frr/pull/168
>

Umm I thought we were talking making network  rd and tag a debug command - 
not vnc commands.

>
>>
>>>>>>   - Notification of adds/withdrawals (both models)
>>>
>> I did find on issue related to mpls call backs in reviewing / retesting the
>> code and this has been pushed.  Other tunnel types should have worked.
>>
> I will check. Thanks.
>
>>>>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>>>>>
>>>>> I could then test ECMP with VNC.
>>>>> Whatever the selection criterium on global RIB ( multipath enabled or
>>>>> not), the entry is present in vnc registration list.
>>>>> show vnc registration
>>>>>
>>>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>>>> Prefix               VN Address      UN Address      Cost Lifetime
>>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>>>
>
>> The rfapi does order the prefixes on query call back based on preference,
>
> By using preference on BGP, the entries will not be considered as ECMP.
>

Unless I miss read something these had identical preferences...  the show 
bgp vrf command is probably what you should be looking at here.

>> but it up to the call back code to decide if only the best route is used.
>> This was explicitly done to support multi/and backup path forwarding.
>
> 1) If I understand correctly, if it is up to the call back code, then
> I understand following scenario should be implemented:
>
> On my case, the call back should instantiate a VRF RIB table.

Why?  Certainly there needs to be a fib somewhere - but I'd expect it to be 
on the other end of your rfp.

Also when routes are redistributed into a vrf there will be another rib 
within that bgp instance.

> When ECMP entries are detected, an algorithm in the callback should be
> triggered to know which ECMP entry is valid.

Umm. I'm not following you here.

> If there is a preference set that is greater in one of the ECMP
> entries, then it will be selected.


> If there is no preference difference, the difference will be based on
> the underlay nexthop attribute.
>
> Reversely,  if a route is withdrawn, notitication call back would be
> called. an algorithm in the callback should be triggered too to know
> if there are still ECMP entries or not.

Rfapi can be configured in a bunch of different ways.  See rfapi.h and 
ensure you're using the options that best match your use case.

> If the entry with the best preference disappears, then the entry with
> the least preference would be selected.
>

There are probably multiple ways to make it work - there are intentionally 
multiple ways to use rfapi to support the different types of rf protocols 
out there.

>
> 2) I would prefer having an internal implementation of BGP best
> selection algorithm, and configure then notifications so as to inform
> only the selected entries.
> It would avoid having a second VRF RIB instance implemented in a second place.

Sure this isn't hard to add as a new config paramtere/feature.  In the 
interim there are hacky approaches to do this.

> If I have a preference set for one route more than one other route,
> then only the preferred entry would be sent to the notification.
>
Sure I can se why you might want this in the inbox usage scenaro.  We were 
focused on controller scenarios.


> For 2), I would need :
> - a vrt command to configure multipath per vrf-policy
> config term
> router bgp ....
>  vrf-policy <vrf-name>
>     transport vpn | evpn | encap
> - a vty command to change the notification procedure.

I think the rest are likely code level changes - not config.
> config term
> router bgp ....
>  ## callbacks would be advertised
>  ## new entries that are set as selected ( ECMP or best prefrence for example)
>  ## removed entries that are set as unselected ( entries that are no
> more unselected because of a new selected entry with best preference)
>  vnc notification only-selected


Perhaps as an option...
>  ## show vnc registration would show only the selected one
>   vnc display only-selected
>

Lou

> Waiting for suggestions,
>
>
>
>
>>
>> Again the output you were expecting is here:
>>
>>> Here is the output
>>>
>>> bgpd# show bgp ipv4 vpn
>>> BGP table version is 0, local router ID is 10.125.0.1
>>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>>> internal
>>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>>    Network          Next Hop            Metric LocPrf Weight Path
>>> Route Distinguisher: 64603:1111
>>> *=i11.11.0.0/16     10.10.10.1         0    100      0 i
>>>      EC{64603:1111} label=125 type=bgp, subtype=0
>>> *>i11.11.0.0/16     40.40.10.1         0    100      0 i
>>>      EC{64603:1111} label=125 type=bgp, subtype=0
>>> *>i22.22.0.0/16     20.20.10.1         0    100      0 i
>>>      EC{64603:1111} label=125 type=bgp, subtype=0
>>> *>i33.33.0.0/16     30.30.10.1         0    100      0 i
>>>      EC{64603:1111} label=125 type=bgp, subtype=0
>>> Displayed 4 routes and 5 total paths
>>>
>>>>
>>>>> Does that mean that all entries are taken into account without any
>>>>>
>>>> This like got cut off.
>>>
>>>
>>> Does that mean that all entries are taken into account without any
>>> best selection algorithm within the VRF ?
>>>
>>
>> No they are ordered and available for downstream processing / selection by
>> the rfp code.
>>
>
> Best Regards,
>
> Philippe
>
Jeff Tantsura Feb. 6, 2017, 7:27 p.m.
Hi,

RD is usually configured in context of VRF, not per prefix. What would be the use case?
The best way to address prefixes is to do so indirectly, thru route-map/prefix-list/your preferred-feature-name
prefix/label/rd combination makes little sense to me, label per prefix is not really good thing unless there’s a need (we could go in details when), default mode - label per NH, perhaps with knobs per VRF (would require additional lookup if there are more than 1 NH’s), per-prefix, RD per prefix - see comment above
How would additional ext-comm added, think of RO/SOO -> having policies within import/export stanzas my be desirable 
Type 5 - I like Junos’s keyword - "ip-prefix-routes” with associated attributes 

my 0.2c

Cheers,
Jeff


> On Feb 6, 2017, at 01:45, Philippe Guibert <philippe.guibert@6wind.com> wrote:
> 
> Hello Lou, all,
> 
> On Fri, Feb 3, 2017 at 12:16 PM, Lou Berger <lberger@labn.net> wrote:
>>>>> a)
>>>>> global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
>>>>> [label <value>] [pref (0-255)]
>>>>> b)
>>>>> vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55
>>>> 
>>>> I had forgotten that this command even existed -- it is ancient and IMO
>>>> a historic appendage - deleting or moving to debug is a good idea.
>>> 
>>> 
>>> I can handle it, I just need to understand the following.
>>> 
>> 
>> Thanks!
> 
> I mean, I need to be able to configure prefixes before suppressing the
> command :-).
> 
> 
> 
>>> If I am referring to RD/RT document, I can see that route-map keyword
>>> has been removed.
>>> I have some remarks:
>>> o still possible to enter following commands. keeping all commands
>>> would suit me:
>>>  a)  rd <value> [prefix <prefix>|prefixlist <prefixlist>]
>>>  b)  label <value> [prefix <prefix>|prefixlist <prefixlist>]
>>>  c) prefix <prefix> [label <value>] [rd <value>]
>>> o route-map seems to have been suppressed, but I think it would be ok
>>> to integrate it with route-map.
>>> o I would propose a 4th command under vrf-policy. Would that be acceptable
>>> ?
>>>  c) prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
>>> o about next-hop self | A.B.C.D | A::B::C, I am pro keeping this command
>>> o is there a command that permits to consider the newly prefix as a
>>> vpnv4 entry or an encap entry ( or an evpn entry )?
>>> 
>> 
>> As I understood the group consensus on the call, specific routes would be
>> learned/configured in the context of a vrf (under bgp <as> vrf <vrf>) and
>> specific  RDs and the typical attributes could be set using typical route
>> map operations. -- here's the related portion for the Google doc:
>> 
> 
> 
>> router bgp XXX vrf <vrf-name>
>>   ! (address-family ipv4)
>>   network  1.2.3.0/24 route-map foo
>>   neighbor ... ! CE session (or alternately, VRF-lite session)
>>   !make vrf redistribution (import/export)the default
>>   redistribute static|ospf|vrf [route map] ...! CE setup for OSPF
>>   no redistribute vrf
>>   no export vrf
>>   export vrf [route map] ...
> 
> This solution fits with one BGP instance per VRF.
> I agree for that.
> 
> But the solution is not enough.
> It does not fit with one BGP instance for multiple VRF handling.
> 
> Is there any group consensus about supporting the following:
> specific routes to be added in the context of a VRF-policy by using
> following configuration method:
> 
> router bgp <ID>
> vrf-policy <vrf-policy-name>
>   rd <>
>   label <>
>   rt import <>
>   rt export <>
>  prefix <prefix> [label <value>] [nexthop <value>]
> exit-vrf-policy
> 
> Adding to the review, I would also expect a command that mentions the
> signalisation transport method ?
> If I set a prefix, how can I force the prefix to be advertised by
> VPNvx or EVPN ?
> In the EVPN Route type 5 method, the same
> 
> config term
> router bgp ....
> vrf-policy <vrf-name>
>    transport vpn | evpn | encap
> 
> 
>>>>> moved under debug rfapi-dev node ?
>>>> 
>>>> 
>>>> This predates the rfapi code removing it or making a debug is a good
>>>> idea.  Do you want to do it or should I?
>>> 
> 
> See https://github.com/freerangerouting/frr/pull/168
> 
> 
>> 
>>>>>>  - Notification of adds/withdrawals (both models)
>>> 
>> I did find on issue related to mpls call backs in reviewing / retesting the
>> code and this has been pushed.  Other tunnel types should have worked.
>> 
> I will check. Thanks.
> 
>>>>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>>>>> 
>>>>> I could then test ECMP with VNC.
>>>>> Whatever the selection criterium on global RIB ( multipath enabled or
>>>>> not), the entry is present in vnc registration list.
>>>>> show vnc registration
>>>>> 
>>>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>>>> Prefix               VN Address      UN Address      Cost Lifetime
>>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>>> 
> 
>> The rfapi does order the prefixes on query call back based on preference,
> 
> By using preference on BGP, the entries will not be considered as ECMP.
> 
>> but it up to the call back code to decide if only the best route is used.
>> This was explicitly done to support multi/and backup path forwarding.
> 
> 1) If I understand correctly, if it is up to the call back code, then
> I understand following scenario should be implemented:
> 
> On my case, the call back should instantiate a VRF RIB table.
> When ECMP entries are detected, an algorithm in the callback should be
> triggered to know which ECMP entry is valid.
> If there is a preference set that is greater in one of the ECMP
> entries, then it will be selected.
> If there is no preference difference, the difference will be based on
> the underlay nexthop attribute.
> 
> Reversely,  if a route is withdrawn, notitication call back would be
> called. an algorithm in the callback should be triggered too to know
> if there are still ECMP entries or not.
> If the entry with the best preference disappears, then the entry with
> the least preference would be selected.
> 
> 
> 2) I would prefer having an internal implementation of BGP best
> selection algorithm, and configure then notifications so as to inform
> only the selected entries.
> It would avoid having a second VRF RIB instance implemented in a second place.
> If I have a preference set for one route more than one other route,
> then only the preferred entry would be sent to the notification.
> 
> For 2), I would need :
> - a vrt command to configure multipath per vrf-policy
> config term
> router bgp ....
> vrf-policy <vrf-name>
>    transport vpn | evpn | encap
> - a vty command to change the notification procedure.
> config term
> router bgp ....
> ## callbacks would be advertised
> ## new entries that are set as selected ( ECMP or best prefrence for example)
> ## removed entries that are set as unselected ( entries that are no
> more unselected because of a new selected entry with best preference)
> vnc notification only-selected
> ## show vnc registration would show only the selected one
>  vnc display only-selected
> 
> Waiting for suggestions,
> 
> 
> 
> 
>> 
>> Again the output you were expecting is here:
>> 
>>> Here is the output
>>> 
>>> bgpd# show bgp ipv4 vpn
>>> BGP table version is 0, local router ID is 10.125.0.1
>>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>>> internal
>>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>>   Network          Next Hop            Metric LocPrf Weight Path
>>> Route Distinguisher: 64603:1111
>>> *=i11.11.0.0/16     10.10.10.1         0    100      0 i
>>>     EC{64603:1111} label=125 type=bgp, subtype=0
>>> *>i11.11.0.0/16     40.40.10.1         0    100      0 i
>>>     EC{64603:1111} label=125 type=bgp, subtype=0
>>> *>i22.22.0.0/16     20.20.10.1         0    100      0 i
>>>     EC{64603:1111} label=125 type=bgp, subtype=0
>>> *>i33.33.0.0/16     30.30.10.1         0    100      0 i
>>>     EC{64603:1111} label=125 type=bgp, subtype=0
>>> Displayed 4 routes and 5 total paths
>>> 
>>>> 
>>>>> Does that mean that all entries are taken into account without any
>>>>> 
>>>> This like got cut off.
>>> 
>>> 
>>> Does that mean that all entries are taken into account without any
>>> best selection algorithm within the VRF ?
>>> 
>> 
>> No they are ordered and available for downstream processing / selection by
>> the rfp code.
>> 
> 
> Best Regards,
> 
> Philippe
> 
> _______________________________________________
> frr mailing list
> frr@lists.nox.tf
> https://lists.nox.tf/listinfo/frr
Philippe Guibert Feb. 7, 2017, 11:05 a.m.
Hi,

On Mon, Feb 6, 2017 at 8:27 PM, Jeff Tantsura <jefftant@gmail.com> wrote:

> RD is usually configured in context of VRF, not per prefix. What would be the use case?

I agree with that. one RD per VRF.

> The best way to address prefixes is to do so indirectly, thru route-map/prefix-list/your preferred-feature-name

Using route-maps or prefix-list are good tools to apply some behaviour
on incoming our outgoing NLRI messages.

> prefix/label/rd combination makes little sense to me, label per prefix is not really good thing unless there’s a need (we could go in details when), default mode - label per NH, perhaps with knobs per VRF (would require additional lookup if there are more than 1 NH’s), per-prefix, RD per prefix - see comment above

Usage of route-maps has been proposed, and some more specification is
not yet achieved.
For more information, see:

https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/edit#

> How would additional ext-comm added, think of RO/SOO -> having policies within import/export stanzas my be desirable

Currently, there is a command available under route-map:

bgpd(config-route-map)# set extcommunity soo
  ASN:nn_or_IP-address:nn  VPN extended community


> Type 5 - I like Junos’s keyword - "ip-prefix-routes” with associated attributes
>
> my 0.2c
>
> Cheers,
> Jeff

Regards,
Philippe
Lou Berger Feb. 7, 2017, 11:41 a.m.
Hi Jeff,



On February 6, 2017 2:28:20 PM Jeff Tantsura <jefftant@gmail.com> wrote:

> Hi,
>
> RD is usually configured in context of VRF, not per prefix. What would be 
> the use case?

Usual is the key word here.  I agree that rd per vrf is the a common use 
case.  I have also seen and use rd to differentiate between multiple PEs  
(this may be pretty common too) and multiple NHs, ie support ecmp and 
backup routes within the VRF.  The specs and the code all allow this.

> The best way to address prefixes is to do so indirectly, thru 
> route-map/prefix-list/your preferred-feature-name

On the config side,I'm fine with using route maps applied between the bgp 
vrf instance and the core (bgp vpn) instance.

> prefix/label/rd combination makes little sense to me, label per prefix is 
> not really good thing unless there’s a need (we could go in details when), 
> default mode - label per NH, perhaps with knobs per VRF (would require 
> additional lookup if there are more than 1 NH’s), per-prefix, RD per prefix 
> - see comment above

Your input on this would be great - I think the next meeting is scheduled 
for 8am PT today - hope to see you there.   Stay tuned for Donalds mail 
announcing topics (and hopefully meeting url).

> How would additional ext-comm added, think of RO/SOO -> having policies 
> within import/export stanzas my be desirable
> Type 5 - I like Junos’s keyword - "ip-prefix-routes” with associated attributes
>
Can you provide a specific example of what you would propose for FRR?

Note copying CLI verbatim really isn't a good idea.  To avoid legal 
pitfalls I  will not look at other vendor manuals when designing commands....

Lou

> my 0.2c
>
> Cheers,
> Jeff
>
>
>> On Feb 6, 2017, at 01:45, Philippe Guibert <philippe.guibert@6wind.com> wrote:
>>
>> Hello Lou, all,
>>
>> On Fri, Feb 3, 2017 at 12:16 PM, Lou Berger <lberger@labn.net> wrote:
>>>>>> a)
>>>>>> global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
>>>>>> [label <value>] [pref (0-255)]
>>>>>> b)
>>>>>> vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55
>>>>>
>>>>> I had forgotten that this command even existed -- it is ancient and IMO
>>>>> a historic appendage - deleting or moving to debug is a good idea.
>>>>
>>>>
>>>> I can handle it, I just need to understand the following.
>>>>
>>>
>>> Thanks!
>>
>> I mean, I need to be able to configure prefixes before suppressing the
>> command :-).
>>
>>
>>
>>>> If I am referring to RD/RT document, I can see that route-map keyword
>>>> has been removed.
>>>> I have some remarks:
>>>> o still possible to enter following commands. keeping all commands
>>>> would suit me:
>>>>  a)  rd <value> [prefix <prefix>|prefixlist <prefixlist>]
>>>>  b)  label <value> [prefix <prefix>|prefixlist <prefixlist>]
>>>>  c) prefix <prefix> [label <value>] [rd <value>]
>>>> o route-map seems to have been suppressed, but I think it would be ok
>>>> to integrate it with route-map.
>>>> o I would propose a 4th command under vrf-policy. Would that be acceptable
>>>> ?
>>>>  c) prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
>>>> o about next-hop self | A.B.C.D | A::B::C, I am pro keeping this command
>>>> o is there a command that permits to consider the newly prefix as a
>>>> vpnv4 entry or an encap entry ( or an evpn entry )?
>>>>
>>>
>>> As I understood the group consensus on the call, specific routes would be
>>> learned/configured in the context of a vrf (under bgp <as> vrf <vrf>) and
>>> specific  RDs and the typical attributes could be set using typical route
>>> map operations. -- here's the related portion for the Google doc:
>>>
>>
>>
>>> router bgp XXX vrf <vrf-name>
>>>   ! (address-family ipv4)
>>>   network  1.2.3.0/24 route-map foo
>>>   neighbor ... ! CE session (or alternately, VRF-lite session)
>>>   !make vrf redistribution (import/export)the default
>>>   redistribute static|ospf|vrf [route map] ...! CE setup for OSPF
>>>   no redistribute vrf
>>>   no export vrf
>>>   export vrf [route map] ...
>>
>> This solution fits with one BGP instance per VRF.
>> I agree for that.
>>
>> But the solution is not enough.
>> It does not fit with one BGP instance for multiple VRF handling.
>>
>> Is there any group consensus about supporting the following:
>> specific routes to be added in the context of a VRF-policy by using
>> following configuration method:
>>
>> router bgp <ID>
>> vrf-policy <vrf-policy-name>
>>   rd <>
>>   label <>
>>   rt import <>
>>   rt export <>
>>  prefix <prefix> [label <value>] [nexthop <value>]
>> exit-vrf-policy
>>
>> Adding to the review, I would also expect a command that mentions the
>> signalisation transport method ?
>> If I set a prefix, how can I force the prefix to be advertised by
>> VPNvx or EVPN ?
>> In the EVPN Route type 5 method, the same
>>
>> config term
>> router bgp ....
>> vrf-policy <vrf-name>
>>    transport vpn | evpn | encap
>>
>>
>>>>>> moved under debug rfapi-dev node ?
>>>>>
>>>>>
>>>>> This predates the rfapi code removing it or making a debug is a good
>>>>> idea.  Do you want to do it or should I?
>>>>
>>
>> See https://github.com/freerangerouting/frr/pull/168
>>
>>
>>>
>>>>>>>  - Notification of adds/withdrawals (both models)
>>>>
>>> I did find on issue related to mpls call backs in reviewing / retesting the
>>> code and this has been pushed.  Other tunnel types should have worked.
>>>
>> I will check. Thanks.
>>
>>>>>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>>>>>>
>>>>>> I could then test ECMP with VNC.
>>>>>> Whatever the selection criterium on global RIB ( multipath enabled or
>>>>>> not), the entry is present in vnc registration list.
>>>>>> show vnc registration
>>>>>>
>>>>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>>>>> Prefix               VN Address      UN Address      Cost Lifetime
>>>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>>>>
>>
>>> The rfapi does order the prefixes on query call back based on preference,
>>
>> By using preference on BGP, the entries will not be considered as ECMP.
>>
>>> but it up to the call back code to decide if only the best route is used.
>>> This was explicitly done to support multi/and backup path forwarding.
>>
>> 1) If I understand correctly, if it is up to the call back code, then
>> I understand following scenario should be implemented:
>>
>> On my case, the call back should instantiate a VRF RIB table.
>> When ECMP entries are detected, an algorithm in the callback should be
>> triggered to know which ECMP entry is valid.
>> If there is a preference set that is greater in one of the ECMP
>> entries, then it will be selected.
>> If there is no preference difference, the difference will be based on
>> the underlay nexthop attribute.
>>
>> Reversely,  if a route is withdrawn, notitication call back would be
>> called. an algorithm in the callback should be triggered too to know
>> if there are still ECMP entries or not.
>> If the entry with the best preference disappears, then the entry with
>> the least preference would be selected.
>>
>>
>> 2) I would prefer having an internal implementation of BGP best
>> selection algorithm, and configure then notifications so as to inform
>> only the selected entries.
>> It would avoid having a second VRF RIB instance implemented in a second place.
>> If I have a preference set for one route more than one other route,
>> then only the preferred entry would be sent to the notification.
>>
>> For 2), I would need :
>> - a vrt command to configure multipath per vrf-policy
>> config term
>> router bgp ....
>> vrf-policy <vrf-name>
>>    transport vpn | evpn | encap
>> - a vty command to change the notification procedure.
>> config term
>> router bgp ....
>> ## callbacks would be advertised
>> ## new entries that are set as selected ( ECMP or best prefrence for example)
>> ## removed entries that are set as unselected ( entries that are no
>> more unselected because of a new selected entry with best preference)
>> vnc notification only-selected
>> ## show vnc registration would show only the selected one
>>  vnc display only-selected
>>
>> Waiting for suggestions,
>>
>>
>>
>>
>>>
>>> Again the output you were expecting is here:
>>>
>>>> Here is the output
>>>>
>>>> bgpd# show bgp ipv4 vpn
>>>> BGP table version is 0, local router ID is 10.125.0.1
>>>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>>>> internal
>>>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>>>   Network          Next Hop            Metric LocPrf Weight Path
>>>> Route Distinguisher: 64603:1111
>>>> *=i11.11.0.0/16     10.10.10.1         0    100      0 i
>>>>     EC{64603:1111} label=125 type=bgp, subtype=0
>>>> *>i11.11.0.0/16     40.40.10.1         0    100      0 i
>>>>     EC{64603:1111} label=125 type=bgp, subtype=0
>>>> *>i22.22.0.0/16     20.20.10.1         0    100      0 i
>>>>     EC{64603:1111} label=125 type=bgp, subtype=0
>>>> *>i33.33.0.0/16     30.30.10.1         0    100      0 i
>>>>     EC{64603:1111} label=125 type=bgp, subtype=0
>>>> Displayed 4 routes and 5 total paths
>>>>
>>>>>
>>>>>> Does that mean that all entries are taken into account without any
>>>>>>
>>>>> This like got cut off.
>>>>
>>>>
>>>> Does that mean that all entries are taken into account without any
>>>> best selection algorithm within the VRF ?
>>>>
>>>
>>> No they are ordered and available for downstream processing / selection by
>>> the rfp code.
>>>
>>
>> Best Regards,
>>
>> Philippe
>>
>> _______________________________________________
>> frr mailing list
>> frr@lists.nox.tf
>> https://lists.nox.tf/listinfo/frr
>
>
Lou Berger Feb. 7, 2017, 11:54 a.m.
Philippe

Your new proposal was  covered on the call (weren't on it? But either way, 
off/post call discussion is good.)

The agreement on the call was to put the route maps in the vrf bgp instance 
not the core instance's vrf-policy stanza:
   router bgp XXX vrf <vrf-name>
   ...
   redistribute static|ospf|vrf [route map] ...! CE setup for OSPF
   no redistribute vrf
   no export vrf
   export vrf [route map] ...

While this really is core instance policy (IMO at least) the group felt it 
was more consistent with the rest of frr - and therefore more 
understandable by the user - put it here.

Also under vrf policy, the organization of having the label and RD keyword 
first, and not prefix, was felt to be less confusing to the user.

These were points largely made by others.  For me, I'm pretty open on 
specifics as long as the technical capabilities are there...

So I think you need to raise this with the group on a call more than with me.

Lou

PS I do agree with you that nexthop vrf-policy is useful in the controller 
case.


On February 7, 2017 6:06:29 AM Philippe Guibert 
<philippe.guibert@6wind.com> wrote:

> Hi,
>
> On Mon, Feb 6, 2017 at 8:27 PM, Jeff Tantsura <jefftant@gmail.com> wrote:
>
>> RD is usually configured in context of VRF, not per prefix. What would be 
>> the use case?
>
> I agree with that. one RD per VRF.
>

See my previous mail.

>> The best way to address prefixes is to do so indirectly, thru 
>> route-map/prefix-list/your preferred-feature-name
>
> Using route-maps or prefix-list are good tools to apply some behaviour
> on incoming our outgoing NLRI messages.
>
>> prefix/label/rd combination makes little sense to me, label per prefix is 
>> not really good thing unless there’s a need (we could go in details when), 
>> default mode - label per NH, perhaps with knobs per VRF (would require 
>> additional lookup if there are more than 1 NH’s), per-prefix, RD per prefix 
>> - see comment above
>
> Usage of route-maps has been proposed, and some more specification is
> not yet achieved.
> For more information, see:
>
> https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/edit#
>
>> How would additional ext-comm added, think of RO/SOO -> having policies 
>> within import/export stanzas my be desirable
>
> Currently, there is a command available under route-map:
>
> bgpd(config-route-map)# set extcommunity soo
>   ASN:nn_or_IP-address:nn  VPN extended community
>
>
>> Type 5 - I like Junos’s keyword - "ip-prefix-routes” with associated attributes
>>
>> my 0.2c
>>
>> Cheers,
>> Jeff
>
> Regards,
> Philippe
>

Patch hide | download patch | download mbox

diff --git a/bgpd/bgp_route.c b/bgpd/bgp_route.c
index 66f375498870..1a9845392bb4 100644
--- a/bgpd/bgp_route.c
+++ b/bgpd/bgp_route.c
@@ -2030,10 +2030,57 @@  bgp_process_vrf_main (struct work_queue *wq, void *data)
 {
   struct bgp_process_queue *pq = data;
   struct bgp_node *rn = pq->rn;
+  struct bgp *bgp = pq->bgp;
+  afi_t afi = pq->afi;
+  safi_t safi = pq->safi;
+  struct bgp_info *new_select;
+  struct bgp_info *old_select;
+  struct bgp_info_pair old_and_new;
 
-  if (rn)
-    UNSET_FLAG (rn->flags, BGP_NODE_PROCESS_SCHEDULED);
+  /* Best path selection. */
+  bgp_best_selection (bgp, rn, &bgp->maxpaths[afi][safi], &old_and_new);
+  old_select = old_and_new.old;
+  new_select = old_and_new.new;
+
+  /* Nothing to do. */
+  if (old_select && old_select == new_select)
+    {
+      if (! CHECK_FLAG (old_select->flags, BGP_INFO_ATTR_CHANGED))
+        {
+          /* no zebra announce */
+	  UNSET_FLAG (old_select->flags, BGP_INFO_MULTIPATH_CHG);
+          UNSET_FLAG (rn->flags, BGP_NODE_PROCESS_SCHEDULED);
+          return WQ_SUCCESS;
+        }
+    }
+  if (old_select && new_select)
+    {
+      if(!CHECK_FLAG (new_select->flags, BGP_INFO_MULTIPATH_CHG) &&
+         !CHECK_FLAG (new_select->flags, BGP_INFO_ATTR_CHANGED))
+        {
+          UNSET_FLAG (rn->flags, BGP_NODE_PROCESS_SCHEDULED);
+          return WQ_SUCCESS;
+        }
+    }
+
+  if (old_select)
+    {
+      bgp_info_unset_flag (rn, old_select, BGP_INFO_SELECTED);
+    }
+  if (new_select)
+    {
+      bgp_info_set_flag (rn, new_select, BGP_INFO_SELECTED);
+      bgp_info_unset_flag (rn, new_select, BGP_INFO_ATTR_CHANGED);
+      UNSET_FLAG (new_select->flags, BGP_INFO_MULTIPATH_CHG);
+    }
+
+  /* Reap old select bgp_info, if it has been removed */
+  if (old_select && CHECK_FLAG (old_select->flags, BGP_INFO_REMOVED))
+    bgp_info_reap (rn, old_select);
+
+  UNSET_FLAG (rn->flags, BGP_NODE_PROCESS_SCHEDULED);
   return WQ_SUCCESS;
+  /* no announce */
 }
 
 static void
@@ -2088,10 +2135,9 @@  bgp_process_queue_init (void)
   bm->process_vrf_queue->spec.workfunc = &bgp_process_vrf_main;
   bm->process_vrf_queue->spec.del_item_data = &bgp_processq_del;
   bm->process_vrf_queue->spec.max_retries = 0;
-  bm->process_vrf_queue->spec.hold = 50;
+  bm->process_main_queue->spec.hold = 50;
   /* Use a higher yield value of 50ms for main queue processing */
   bm->process_vrf_queue->spec.yield = 50 * 1000L;
-
 }
 
 void
@@ -2257,7 +2303,7 @@  bgp_rib_remove (struct bgp_node *rn, struct bgp_info *ri, struct peer *peer,
   
   if (!CHECK_FLAG (ri->flags, BGP_INFO_HISTORY))
     bgp_info_delete (rn, ri); /* keep historical info */
-    
+
   bgp_process (peer->bgp, rn, afi, safi);
 }