(cross-posting to hicn-dev) By chance we were working on resurrecting the routing plugin in the hicn project and Masoud has just submitted a patch
https://gerrit.fd.io/r/#/c/20535/ This builds for VPP 19.04. Tested with FRR, OSPF only. If someone is interested in testing more please cherry-pick share results and cross-post in hicn-dev. We do not intend to design a new routing plugin as of now, so this is it, but I do understand that a clean-slate design would be desirable. On 7/9/19, 16:28, "vpp-dev@lists.fd.io on behalf of Ray Kinsella" <vpp-dev@lists.fd.io on behalf of m...@ashroe.eu> wrote: It is accurate to say it is bit-rotting, it not accurate to say it is orphaned. > > I believe that, but obviously nobody is interested to do so. Neither original authors or users of that code. Well that is not entirely accurate - I think that it is more accurate to say the authors are tired of fixing it and are thinking about a better way to fix this problem long term. It's something we are looking at, at the moment and are open to collaboration on it. >>> >>> So, I don't really have a problem with it not being in VPP proper, so long as it is maintained. >> >> So, you expect that somebody maintains it for you? why? what is his incentive to do so? People are typically maintaining some specific feature because they are interested in using it and they see a value in open source collaboration. >> >> I was under the impression that keeping unmodified code "in sync" would not be that difficult, and of great value to the larger community of folks using VPP. > > If it is not so difficult, please contribute. To be fair - we do see alot usage of the vRouter plugin - despite all it shortcomings, so we do have a desire & motivation to fix it. And it is also clear from the number of questions we get on it - that there is a strong desire from the community for functionality of this type - it just hasn't turned into action, so far. The question is do we invest time in fixing a design we know is inherently broken (again and again) or do we step back and take a breath. > >> >> The value of VPP is best measured by the number of folks using it. I believe a non-trivial number of folks have basically stumbled across VPP from the links shared from the FRR project (alternate forwarding planes). >> >> If you don't want those people using VPP, I don't understand your rationale. > > I will be happy that more people is using VPP and contribute back good quality features for everyone benefit. > I believe good integration between VPP and routing software like FRR is something we are really missing, but outdated sandbox experiment code > is not solution for that. Agreed, completely - trouble is I have never seen good integration between FRR and anything but Linux. >> It think best way to make feature maintained is to do the work right and convince others contributors that this is not throw-over-the-fence code. >> >> I was not the author of netlink or router plugins. I never threw that code anywhere. It is published in the vppsb, but has otherwise been left to rot. > > Yes, looks like original authors are not interested to keep it in sync and improve and also there is nobody to step in. > This is normal in open-source, Look at MAINTAINERS file in Linux kernel source tree and you will see how much things are declared as orphaned> >> >> The VPP coding practice requires a lot of investment up front to get to the meat of the matter. >> For what I am looking for in the immediate short term (getting the plugins to compile), that is a huge up-front cost for a very low pay-off. >> >> >> You will be happy as feature is maintained, we will be happy as we will have one valuable member of the community. >> >> IMHO, the VPP project's documentation (wiki and otherwise) is inadequate to allow new participants with lots of experience doing maintenance-level or porting-level modification of C code, to pick up the plug-ins and get the bugs fixed. >> >> >> Not being able to write code is not excuse, as you can always find somebody to do it for you. >> >> I can write code, that is not the issue at all. >> >> >>> >>> It serves a very specific purpose, and does so adequately, if/when it compiles. >>> >>> It has not been maintained to keep parity with VPP, and I think everyone asking about it, is interested in the minimum amount of effort to keep it viable in the short term. >> >> Who is "everyone" and why do you think think that any vpp contributor or committer should work on feature you are interested in instead of working on the feature that person is interested in. >> >> I was under the impression that there was a core team coordinating the efforts and ensuring project commit dates were met, and that any breakage was being fixed. >> If the existing netlink and router plugins were converted to part of the core of VPP (that's a big "if", I am aware), would it not be the case that you would assign someone to make sure it continued to compile and pass regression testing? >> >> I'd be happy to work on these, if the necessary alignment to current revisions of VPP were done first. I'm not going to work on a project that will always be drifting out of spec because VPP is moving and these plug-ins are not maintained. >> >> However, IF they get imported into the mainline VPP, I would very much be interested in re-torquing them so the whole "tap-inject" stuff could die a horrible death, and the "sniffing" could be altered to being a dedicated channel for FRR->VPP routing table management. >> >> >>> >>> >>> Basically: it’s architecturally ugly, and the more you try to fix it, the more difficult the problems become. As an example, you’ll eventually want to be able to mirror the interface state to bird or frr, as they see the tap interfaces. This rabbit hole of this type of issue goes very deep. >>> >>> This ugliness is addressable via multiple means. >>> >>> I think the complaints about support in the short term would probably diminish if long-term plans to provide *some* way of integrating with FRR (and possibly BIRD) were being discussed. >>> >>> I have seen complaints about the ugliness, but not any discussion on a way forward that addresses those issues. >>> >>> I have some suggestions on better solutions, which may already be feasible to do with a minimum of effort by someone familiar with the core of VPP itself (i.e. VPP developers.) >>> >>> Some of the possibilities (some of these have caveats or may not be feasible to be used in some environments): >>> • Bifurcated drivers - the NIC presents itself with two PCIe IDs instead of one ID. Have the VPP use one ID, have the host (and FRR) use the other ID. >>> • The downside is, two MACs are present, and two IP addresses are needed, one for FRR, one for VPP. >>> • This is NOT a good solution, especially for use on actual production routers, where restrictions on MAC addresses and IPs exist, like Internet Exchange Points (IXPs). >>> • Possibly using the "virtual function" modes of NICs, for intercepting the 5-tuples for specific protocols/ports (like BGP as TCP/179, plus other host-specific protocols like SSH >>> • This might be possible using a general mode on the basis of the host's IP addresses >>> • This is a low-level (driver) equivalent to the kernel's IPTABLES functionality >>> • I haven't played with this at all, so can't even be sure this would work >>> • Bridged connection to the host IP stack >>> • Needs to have some handling upstream, by VPP, to figure out where the frame is destined, based on destination IP address >>> • Or, may need to have internal hidden MAC addresses (MAC masquerading?) >>> • Ideally would use Ethernet link state propagation (not sure if that is the right term); transceivers often have this mechanism, for letting the device on one side of a link learn about the link state on the other side of the transceiver (which is technically a two-port bridge) >>> • Both (either) of these also require that the FRR (software router) "talk" to VPP, to pass updates to the routing table >>> • FRR already has built-in support for use of a separate device/socket for such communication; it is a configuration item for the running FRR router. >>> • There are two supported standards, one of which is "netlink" (which the "netlink" plug-in in vppsb has the code for), I don't recall the other one. >>> • This would be a dedicated socket/pipe rather than having to "sniff" /dev/netlink the way the plug-in does >>> • There might also be a need for some kind of internal-only "ethernet" link between the host stack and the VPP routing element(s), that the host can point its default route at, so it isn't necessary for FRR to install the BGP routes into the host's own routing table (this reduces the load on the OS/kernel, as well as avoids duplicating the netlink update packets) >>> At this point, I am interested in (a) seeing if the core VPP developers are interested/willing/able to take this on, and (b) how many folks on the mailing lists are interested in having this capability put into the CORE of VPP (rather than being a sandbox item). >>> >>> I recall seeing a request for router/netlink to be incorporated into the mainline vpp code, which was never approved. >> >> It was never "approved" as nobody was willing to invest his time and resources to do it right. >> >> So we have basic everybody vs nobody problem here. As you said everybody wants this functionality and nobody is willing to do the work. >> >> I'm willing to meet the VPP folks half-way. Get the plugins (netlink/router) to the point where they compile, and I'll work on making it work the right way, or at least providing a high level blueprint if anyone can assist on the VPP-isation of the code for implementing it. > > I don't see any problem here, assuming that there is still somebody around who can merge patch there. vpp commiters are not vppsb commiters. > Moving that code to main repo is different, bar is much higher... > >> >> >>> >>> So, saying this is an open source project is kind of disingenuous if the maintainers won't accept the contributed code. >> >> So you believe that any contributions must be accepted. That can be easily done by giving write permissions to repo, so anybody can merge his "contributions" and we will have real "open source" project. >> >>> >>> Implementing the code in isolation, rather than being accepted upstream, isn't really open source, since EVERYONE who wants this functionality would have to do the same work, independently, rather than being able to share their code via this project. >>> >>> And no, the protocol as a plug-in is not acceptable to the FRR/quagga/BIRD community. >>> >>> The routing update processing is a de-facto standard, supported by all the major software router projects: netlink. >>> >>> The netlink plug-in is there; this doesn't have to be via the tap-inject thing, it can be some other method (such as a socket or named pipe). All I'm asking for is to put into the main VPP code base, so it inherits updates to all the required parts, and will continue to compile as VPP gets updated. >>> >>> Right now, attempting to build these plugins fails, and folks actively using these plugins are STUCK on vpp 18.07 (the only one I am able to build, and then only with a fair bit of tweaking for some slight broken-ness.) >>> >>> Thanks for listening, and with all due respect. >> >> Thank you for sharing your frustration, maybe some good samaritan will feel your pain and decide to implement this functionality right so we can happily merge it into main repo. >> >> Is there someone running point on VPP at an architectural or directional level? >> I seem to recall some three-letter-acronyms for FD.IO but don't see any details on the main page that are at all recent, give any indication of long term plans, goals, or governance. >> It isn't only the code, it is also the process, in terms of transparency and direction. >> Or is the whole vpp thing just moving in whatever random direction that current committers individually decide? >> >> I just don't get that there should even be any question regarding the importance of control plane for IPv4 and IPv6 (i.e. routing) for providing the needed context for the data plane, i.e. VPP. >> Everything about VPP is modular, except routing. >> THAT is my frustration. > > VPP is mainly dataplane, and it was build with assumption that control plane stuff will be external entity which programs over officially supported binary APIs. We have few exceptions for simple protocols like arp, nd, dhcp, igmp which doesn’t fit under dataplane definition, but > all those protocols are native VPP implementations and they can be turned off if external implementation is used. > > Right thing to do will be to develop glue software which gets routing protocol packets over the punt/inject path and program VPP forwarding tables over the binary API. > That glue software can talk with FRR/BIRD/... directly or it can use netlink hacks but it should be separated from dataplane, which is not the case with the current plugin. We already have many FIB programming and forwarding tests which use binary API. Testing of that plugin as it is today will be nightmare. > > Hope this explains… > > — > Damjan > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#13462): https://lists.fd.io/g/vpp-dev/message/13462 > Mute This Topic: https://lists.fd.io/mt/32309215/675355 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [m...@ashroe.eu] > -=-=-=-=-=-=-=-=-=-=-=- >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13466): https://lists.fd.io/g/vpp-dev/message/13466 Mute This Topic: https://lists.fd.io/mt/32309215/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
