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

[Lou Berger]

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 at labn.net
> <mailto:lberger at 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