[Bpf] My thoughts on the BPF BOF

[Jari Arkko <[e-mail]>]

IAB members are asked to provide feedback on BOFs, and we do this, but it should be noted that the feedback is a personal opinion, and often from a generalist perspective. In other words, here’s some feedback, hopefully it is helpful, feel free to do what you want with it, including ignoring it :-) 

What: I attended the BPF/eBPF BOF today. BPF is a filtering technology and a mechanism for representing small, verifiable programs that can execute in time critical contexts such as packet processing on path. BPF is mature technology, but its use is expanding, both in terms of different implementations of the different system components and use in applications across basic networking tasks, cloud frameworks, or even things like storage systems.

There’s a suggestion to formalize the core pieces of BPF as a standard. Parts (perhaps majority) of a forum currently doing this work are looking for a place to do this standard, and IETF is their primary choice. The stated reason for the need for standards is the expanding ecosystem, e.g., increasing number of NIC vendors wishing to develop hardware support. 

Discussion:

For background, there’s previously been a question about whether there are copyright or license issues with regards to IETF doing some of this work, e.g., are there parts of the existing material under GPL which might be difficult to use in IETF documents. Just before the meeting IETF lawyers indicated that due to dual licensing, Linux documents can likely be used in the IETF using our standard contribution rights model. This needs to be checked in detail of course, but that’s separate work and ruled out of scope for the working. (There may be another question about being able to use future IETF specifications as machine-readable input to code generation in implementations; it would be good to understand if this will be acceptable for the implementations.) 

But the main discussion point in the meeting was whether this is work that fits the IETF well in terms of not having competing organizations doing the same effort, how the work with the open source and other parts of the community are arranged, and if there’s suitable expertise in the IETF. Joel Halpern brought up his concern that the IETF does not have expertise or track record to solve these kinds of problems that are more about compilers and languages than networking. Most others believed that there’s space for IETF work on this, given some overlap between the communities, the stable situation with the existing technology, and its relationship to topics closer to the IETF (such as packets).

The chairs asked if the room felt the problem was well defined and scoped. The meeting was almost unanimous that it was. Same for recommending to start the work. The community seems to want the work to go ahead by a larger level of consensus than we’re normally used to in IETF BOFs.

Conclusion: In my personal opinion there’s likely a possibility for the IETF to do successful work in this space, if it is rational and narrowly-scoped. There does seem to be a community of interested parties, including many with different parts of the expertise that is required and some who are willing to come to the IETF to do the work.

I do have one concern however. I think the meeting discussed the issues only in the abstract, and spent almost no time discussing the actual list of work items. There’s a draft list of work items in the charter (https://datatracker.ietf.org/doc/charter-ietf-bpf/) and the room hums seemed to say that the charter is acceptable. However, to what extent has this been discussed on list or somewhere else? I personally thought some items were quite clearly feasible while I wasn’t so sure of others. For instance, the basic definition of the instruction set seems clearly something that should and could be done. But at the same time, what about extensions or things built on top or architecture that relate to specific usage outside network, e.g., linux or storage systems? Also, the list is quite long and unordered. Perhaps step one (as also suggested in the meeting) is to publish specifications for the core BPF instruction set as currently defined, and then tackle the next steps. E.g., a next set of the instructions set with some new extensions, or some of the other activities suggested in the current version of the charter.

Jari