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

[Philippe Guibert]

Hello Lou, all,

On Fri, Feb 3, 2017 at 12:16 PM, Lou Berger <lberger at 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