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] > -=-=-=-=-=-=-=-=-=-=-=- >
signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13465): https://lists.fd.io/g/vpp-dev/message/13465 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] -=-=-=-=-=-=-=-=-=-=-=-
