Philippe,
see below. On 6/8/2016 1:55 PM, Philippe Guibert wrote: > On Tue, May 17, 2016 at 1:10 PM, Lou Berger <lber...@labn.net> 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 >> <pa...@labn.net>. > 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 ? This is used by the ethernet code, see below. > > * 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. No we can drop that. > * 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. you're analysis confirms what we said in the submission: > >> MAC address distribution does not follow any standard BGB >> encoding, although it was inspired by the early IETF EVPN concepts. > Will the internal call procedure > be easy to change ? We believe so. > ** 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 ?). Our expectation is that rfapi (rfapi.h) will not need to change when the swap is made to fully standard EVPN. > ** Less problematic, but present is the rework to be done if EVPN is > ported. Do you have an EVPN implementation to port? If not, I don't believe one yet exists, and it'll be radically easier to implement based on our code vs starting from scratch. Now if someone has an existing implementation of EVPN (beyond RR SAFI support), this would be a different discussion. > I understand there may be a huge number of lines to rework ? Yes, there are significant section of bgpd/rfapi that will need to change, but not the interface or rfapi.h. > bgpd# grep SAFI_MPLS_VPN rfapi/* | wc -l > 84 > bgpd#grep SAFI_ENCAP rfapi/* | wc -l > 3 > 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 ? It's certainly possible to break out the L2VPN code, but everyone we've talked to about it has said they'd much prefer to have quagga have some L2VPN capability than to wait for fully standard EVPN. Either way (keep, drop, ifdef), we will defer to community consensus on this. > To sum up, with the current status, I would nack the patch. Perhaps this would be a good discussion for the next monthly meeting. Lou > Best Regards, > > Philippe > _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
