On Tue, May 17, 2016 at 1:10 PM, Lou Berger <[email protected]> wrote:
Hi Lou, > This feature adds an L3 & L2 VPN application that makes use of the VPN > and Encap SAFIs. This code is currently used to support IETF NVO3 style > operation. In NVO3 terminology it provides the Network Virtualization > Authority (NVA) and the ability to import/export IP prefixes and MAC > addresses from Network Virtualization Edges (NVEs). The code supports > per-NVE tables. > > The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2 > (L2) forwarding information between NVAs and NVEs is referred to as the > Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. RFPs are > integrated with BGP via the RF API contained in the new "rfapi" BGP > sub-directory. Currently, only a simple example RFP is included in > Quagga. Developers may use this example as a starting point to integrate > Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code > also supports the ability import/export of routing information > between VNC and customer edge routers (CEs) operating within a virtual > network. Import/export may take place between BGP views or to the > default zebra VRF. > > BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN > information between NVAs. BGP based IP VPN support is defined in > RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659, > BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use > of both the Encapsulation Subsequent Address Family Identifier (SAFI) > and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation > Subsequent Address Family Identifier (SAFI) and the BGP Tunnel > Encapsulation Attribute, are supported. The code is tunnely type > agnostic. MAC address distribution does not follow any standard BGB > encoding, although it was inspired by the early IETF EVPN concepts. > The intent is that the RF API would not need to change with support > of standards-based EVPN. > > The feature is conditionally compiled and disabled by default. > Use the --enable-bgp-vnc configure option to enable. > > The majority of this code was authored by G. Paul Ziemba > <[email protected]>. After having played a bit with vnc, and looking at the code, it is really nice to see IP prefixes and MAC addresses exchanged between NVAs and/or between VNCs. I have however some comments: * It seems the RD_TYPE_EOI type surfaced again (see http://patchwork.quagga.net/patch/1728/ ), whereas I don't see where it is used. Is there a need to keep this flag ? * Is it still relevant to keep HAVE_IPV6 flag ? The IPV6 flag has been recently removed from quagga mainstream, as in 205e6744f2dc - bgpd: remove HAVE_IPV6 conditionals. * My doubt is about MAC address distribution. since the way the messages are carried is inherited from old EVPN draft (I don't know which one ?), which is not what is present in RFC7432. ** For instance, RFC7432 uses new afi/safi, whereas the implementation reuses current ENCAP and MPLSVPN safi. Will the internal call procedure be easy to change ? ** The naming convention will change. Hence, I wonder if the rfp API will change, because of that (ETHERNET segment id may replace logical net id ?). ** Less problematic, but present is the rework to be done if EVPN is ported. I understand there may be a huge number of lines to rework ? bgpd# grep SAFI_MPLS_VPN rfapi/* | wc -l 84 bgpd#grep SAFI_ENCAP rfapi/* | wc -l 37 My main concern is about MAC address distribution concern. This is the reason why I would nack the patch. Maybe it could be interesting to brace the relevant code with #ifdef DRAFT_EVPN_XXX / #endif /* #ifdef DRAFT_EVPN_XXX */ so as to better handle the standard from the non standard ? To sum up, with the current status, I would nack the patch. Best Regards, Philippe _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
