[dev] BGP Route Leaking for VRF-Lite and VPN's

[Lou Berger]

I suspect we should keep one instance of policy to cover the case of 
leaking core routes. I'll discuss with Paul Z...


On January 26, 2018 9:54:24 AM Philippe Guibert 
<philippe.guibert at 6wind.com> wrote:

> Lou, Donald,
>
> I only need to do kind of vrf route leak from default VRF to a named VRF.
>
> From BGP perspective, will it not be possible to avoid configuring BGP VRF
> instance ?
> I find vpn-policy or vrf-policy very useful.
>
> Philippe
>
>
> On Thu, Jan 25, 2018 at 12:17 PM, Lou Berger <lberger at labn.net> wrote:
>
>> Hi Philippe,
>>
>> Based on the discussion, I believe vpn-policy is going to move under the
>> bgp vrf instance config in the final syntax  - we're just need to finalize
>> syntax once vivek has his proposal ready.
>>
>> the bgp vrf instance Is already automatically associated with the
>> zebra/kernel vrf via name matching.
>>
>> Lou
>>
>> On January 25, 2018 4:32:23 AM Philippe Guibert <
>> philippe.guibert at 6wind.com> wrote:
>>
>>> Hi Lou, Donald,
>>>
>>> At first glance, the syntax proposed in [1] looks good.
>>> Does that mean that VRF configured under BGP node ( vpn-policy or
>>> vrf-policy) will be automatically "connected" to ZEBRA VRF ?
>>> Maybe an explicit additional command would make that relationship
>>> possible?
>>>
>>>
>>> Le 23 janv. 2018 7:40 PM, "Lou Berger" <lberger at labn.net> a écrit :
>>>
>>> Hi
>>>
>>>
>>>
>>> On 1/23/2018 12:09 PM, Philippe Guibert wrote:
>>>
>>>> Hi Donald, Lou,
>>>>
>>>> I could not attend the meeting.
>>>> Are there any notes, or presentation that could explain what will be the
>>>> strategy with BGP ?
>>>>
>>>> We're headed towards supporting VRF-lite route leaking and L3VPN over
>>> MPLS, with both using common RT and BGP VPN constructs.  Donald taking the
>>> lead on the zebra additions and Paul Z doing the bgp code changes.  Vivek
>>> is also looking at cli and will propose a revised syntax.  The syntax Paul
>>> is currently looking towards can be found at the top of [1], but again this
>>> is not finalized.
>>>
>>> [1] https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJ
>>> kwMmk_XN5yz33MMNNqM/edit#
>>>
>>>
>>> On a separate work, I came to face the issue where I need to redirect
>>>> flow to a specific VRF, based on route target input.
>>>> I was wondering if that work was crossing or not.
>>>>
>>>> I suspect yes.  How is the flow encapsulated over the core?
>>>
>>>
>>> I am in progress of having FlowSpec Client into FRR. More information
>>> Flowspec basically applies some kind of policy ( some rules describe
>>> which traffic, and what to do with) based on BGP Flowspec infomation.
>>>
>>> My setup is not finalised yet, I have the main traffic that is not
>>> encapsulated.
>>> For security reasons, BGP receives a BGP Flowspec message, including an
>>> extended community that asks to redirect that traffic to a VRF.
>>>
>>> I expect that BGP identifies the ZEBRA VRF, based on the incoming
>>> extended community ( made with Route Target).
>>> I also expect that the RD and RT concepts do not cross BGP/ZEBRA
>>> borderline. I expect that the matchine VRF_ID will be contained in the ZAPI
>>> message.
>>>
>>> Philippe
>>>
>>>
>>> Lou
>>>
>>> Thanks,
>>>>
>>>> Philippe
>>>>
>>>>
>>>> On Tue, Jan 16, 2018 at 4:08 PM, Donald Sharp <
>>>> sharpd at cumulusnetworks.com <mailto:sharpd at cumulusnetworks.com>> wrote:
>>>>
>>>>     All -
>>>>
>>>>     During discussions this morning w/ Lou we discovered that we are both
>>>>     working towards a BGP solution for Route Leaking.  We have enough
>>>>     differences between our approaches that we need to spend some time
>>>>     consolidating our approach.  The current plan is to have the meeting
>>>>     at 3:30 EDT this Friday Jan 19.  If you would like to attend please
>>>>     let me know and I will put you on the invite for it.
>>>>
>>>>     donald
>>>>
>>>>     _______________________________________________
>>>>     dev mailing list
>>>>     dev at lists.frrouting.org <mailto:dev at lists.frrouting.org>
>>>>     https://lists.frrouting.org/listinfo/dev
>>>>     <https://lists.frrouting.org/listinfo/dev>
>>>>
>>>>
>>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20180126/35379ac2/attachment.html>