> On 9 Jul 2019, at 01:23, Brian Dickson <brian.peter.dick...@gmail.com> wrote: > > > > On Mon, Jul 8, 2019 at 3:39 PM Damjan Marion <dmar...@me.com> wrote: > > > > On 8 Jul 2019, at 22:23, Brian Dickson <brian.peter.dick...@gmail.com> > > wrote: > > > > > > > > On Thu, Jul 4, 2019 at 1:19 PM Jim Thompson via Lists.Fd.Io > > <jim=netgate....@lists.fd.io> wrote: > > > > On Jul 1, 2019, at 4:44 AM, Steuer Heribert <ste...@patronas.com> wrote: > > > >> Hello, > >> > >> > >> > >> I am trying to understand what the current status of the router plugin in > >> vppsb is. It seems not to compile with any recent version of VPP. > >> > >> There is not much value in a data plane implementation without a proper > >> control plane. Can you guys please enlighten me about the current status > >> of the plugin or whether it was replaced by any other implementation that > >> enables tools like Bird or FRR to inject routes into the VPP FIB? > >> > >> > >> > >> Thanks lot for your help, > >> > >> Heri > >> > > > > Heri, > > > > First, your question has been asked and answered several times on vpp-dev: > > > > Well, I'd make a distinction between "received a response from someone on > > the list", and "answered". > > > > Thus far, the responses have been at best disappointing, and at worst, > > display a clear disconnect between the VPP developers, and the people using > > VPP (or intending on using VPP who cannot now due to lack of support for > > this project). > > So, did i get it right that you expect that "VPP developers" should start > working on feature which you "VPP user" need to address your disappointment? > > > It is unclear to outside observers (users and potential contributors) what > the official relationship is between vpp and vppsb (and in particular the > netlink and router plugins, or the plugin framework(s) generally.
SB in vppsb means sandbox, place where people play with technology. Out of that play you can get either some solid useful feature but that is not going to happen every time. It is just sandbox, everybody can put his software there but there is no commitment that we will keep it in sync with VPP. > If you had some good piece of documentation somewhere, there would be much > less frustration, I'm sure. > IMHO, the pre-existence of these plugins doesn't really rise to the level of > "start working" on a feature. In case when idea is good and realisation is bad, it makes sense to start working on it from scratch. > > I believe the main problems with the plugins not compiling has more to do > with the "meta" elements (makefiles or equivalent), plus parts that require > parallel maintenance (things like struct references, re-organization of > stuff). > These should be a lot less work for someone not familiar with the newer kinds > of build environments. I'm an old-school type that is familiar with > "./configure; make; make install" kinds of build steps. > I'm not averse to learning new things, but if someone already is doing this > routinely as part of the core VPP project, I think it would be a very light > load to keep netlink and router plug-ins in a "mostly un-supported except for > ensuring they compile" level of support. > > Also, note the references immediate below, by the previous respondent. They > newest of those was for 18.04, and many of them were 17.x release > work-arounds or instructions. > > AFAICT, nothing newer than 18.07 can be fixed without a lot of time and > effort, coming in cold. I believe that, but obviously nobody is interested to do so. Neither original authors or users of that code. > > > > > > > https://lists.fd.io/g/vpp-dev/topic/issue_in_installing_router/16635086?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,16635086 > > > > https://lists.fd.io/g/vpp-dev/topic/building_router_plugin/10641656?p=Created,,,20,1,0,0::,,,0,0,0,10641656 > > > > https://lists.fd.io/g/vppsb-dev/topic/questions_about_the_router/10642802?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,1,20,10642802 > > > > There is more of this type of thing in the archives. > > > > Second, several vendors maintain private forks of the router plugin, so > > it’s obviously possible to make it compile, and run. > > > > If you are aware of these specifically, can you provide (a) which vendors > > those are, (b) contacts, and (c) whether any submissions back to the main > > non-forked tree have been contributed (and either accepted or rejected)? > > > > > > This said, the router plugin is the “short path” to control plane > > functionality, but there are reasons it’s in the sandbox, and it will > > likely never be part of VPP proper. > > > > 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. > > 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. > > Most of the people who come here from that origin, are not looking to add BGP > to VPP. They are looking to add VPP to BGP. The BGP is not optional, but the > VPP very much is (it is basically a performance boost, but without BGP is > useless to them.) > > > 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/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
