> 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? > > > 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. 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. You will be happy as feature is maintained, we will be happy as we will have one valuable member of the community. Not being able to write code is not excuse, as you can always find somebody to do it for you. > > 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. > > > 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. > > 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.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13458): https://lists.fd.io/g/vpp-dev/message/13458 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] -=-=-=-=-=-=-=-=-=-=-=-
