Ray, > I agree - but completely reinventing the wheel is not a the best course > either. These are tried and tested implementations and are worth reusing, I > do agree that integrating through the Linux Kernel is not ideal. > > We developed the router plugin to show that integration was possible we never > claimed that it was the 'best' way to integrate either. > > Plugging a Quagga/FRR/Bird etc into VPP/HC is definitely the better path. > Historically it has been hard with Quagga due to GPL licensing, I understand > that FRR is the easiest path.
Yes, I'm not proposing to reimplement the routing protocol implementation. Only the transport between network and application and how the RP programs the routes into the forwarding plane. Quite a few ways we can do this. I just took issue with the premise that we cannot change the RP implementations. (E.g. Sander did something very similar for the DHCPv6kit server). Of course BGP transport could run completely outside of VPP, assuming multi-hop BGP, but typical routing protocols need to be on-link, know the interface properties (p2p, broadcast, ...) and so on. See attached picture: Top left: Transport is across the punt socket / punt interface (which carries meta data about RX interface etc). UDP or direct in IP application (RIP, OSPF, Babel...). VPP API used to program routes. learn interface events, addresses etc. Pure user-land no involvement from kernel. Top middle: Same as above, but how you could support a TCP application like BGP. Top right: The current router plugin model. With all VPP interfaces mirrored into Linux. Unmodified RP application. Bottom: Bifurcation. Split the control traffic prior to VPP. Any alternatives in the solution space I've missed? Cheers, Ole
signature.asc
Description: Message signed with OpenPGP
