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

[Lou Berger]

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 at 6wind.com> wrote:

> Hi,
>
> On Mon, Feb 6, 2017 at 8:27 PM, Jeff Tantsura <jefftant at 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
>