<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 5, 2017 at 3:59 PM, Lou Berger <span dir="ltr"><<a href="mailto:lberger@labn.net" target="_blank">lberger@labn.net</a>></span> wrote:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><span style="font-size:12.8px">Hello Lou, all,</span><br style="font-size:12.8px"><div style="font-size:12.8px"></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I suspect that the VRF portion of this patch provides a subset of the<br>
functions already in the VNC code with the addition of vty/cli support.<br></blockquote><div><br></div><div class="gmail_quote" style="font-size:12.8px"><div>I briefly listed you on chat ( a few weeks ago) the main functionalities that the VRF portion does.<br></div><div>In this patch, the VRF portion does the following:<br>- VRF processing application to VPNv4 messages ( import to VRF)<br></div><div><div>- ability to enable Multipath, and configure the appropriate number of paths<br></div>- ability to handle ECMP entries coming from different BGP speakers<br></div>- each new modification in VRF RIB is linked to an informational message ( add/withdraw) <br></div><div class="gmail_quote" style="font-size:12.8px"><br></div><div class="gmail_quote" style="font-size:12.8px">Next to this, some code needs to be rebased with frr, related to VPNv6, and EVPN ( including EVPN IPv6 and IPv4).<br>- VRF import processing application to EVPN route type 5 and EVPN route type 2 messages<br></div><div class="gmail_quote" style="font-size:12.8px">- VRF import processing application to VPNv6 and EVPN IPv6 messages<br>- ability to perform VRF processing with route target <br></div><div class="gmail_quote" style="font-size:12.8px">- ability to configure VRF per layer. meaning define a layer 2 VRF or a layer 3 VRF<br></div><div class="gmail_quote" style="font-size:12.8px">- ability to handle EVPN entries coming from different BGP speakers<br></div><div class="gmail_quote" style="font-size:12.8px">- ability to filter specific L2 or L3 data from EVPN RT2 messages in appropriate VRF.<br></div><div class="gmail_quote" style="font-size:12.8px"><div>- ability to carry special ext. communities params ( router mac and encaps type)<br></div></div><div><span style="color:rgb(80,0,80);font-size:12.8px"> </span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Our plan was to add the vty functions for the VNC code once they were<br>
agreed to by the community (background in the link provided by<br>
Philippe).  It sounds to me that we should resume this discussion as<br>
well as discuss this patch in an upcoming technical meeting.<br>
<br></blockquote><div><br></div><div><div style="font-size:12.8px">From our exchange, I understand that the VNC feature implements the VRF portion of this patch.<br></div><div style="font-size:12.8px">The VNC also implements the NVO3 style forwarder. You are better placed than me to talk about the VNC feature.<br></div><div style="font-size:12.8px"><br>I don't know if there are plans for supporting the next features I mention ( EVPN, VPNv6) and when ?.<br></div><div style="font-size:12.8px"><br>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:<br></div><div style="font-size:12.8px">10 VRFs, 1000000 prefixes, and 8 peers configured.<br></div><br style="font-size:12.8px"><div style="font-size:12.8px">Best Regards,<br><br></div><div style="font-size:12.8px">Philippe</div></div></div></div></div>