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.
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. 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. > > > > > > 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. 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. 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. 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. > > > > > 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. Thanks, Brian
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13459): https://lists.fd.io/g/vpp-dev/message/13459 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] -=-=-=-=-=-=-=-=-=-=-=-
