Getting new work started in the IETF usually requires a birds-of-a-feather (BoF) meeting to discuss goals for the work, the suitability of the IETF as a venue for pursuing the work, and the level of interest in and support for the work. In this article, we’ll review the BoFs that took place during IETF 88, including their intentions and outcomes. If you’re inspired to arrange a BoF meeting, please be sure to read RFC 5434: Considerations for Having a Successful Birds-of-a-Feather (BoF) Session.
By: Mat Ford
Internet Governance Update (igovupdate)
Description: This meeting provided the IETF community with an opportunity to hear about and discuss some Internet governance developments, especially as they relate to protocol development in the WEIRDS working group (WG). There was also an update on proceedings at the Internet Governance Forum.
Outcome: The meeting generated a lively discussion about the evolving Internet governance landscape, the issues that people believe need to addressed, and where those issues have touch points with the IETF.
RFC Format Design Team Update (rfcform)
Description: This will serve as a report out to the community and opportunity for discussion on the requirements for tool specifications for a revised RFC Format.
Outcome: The RFC Editor provided an update on the progress of the RFC Format Design Team. The community engaged in a detailed discussion of various open and ongoing issues.
Internet-wide Geo-Networking (geonet)
Description: Internet-wide geo-networking concerns IP-layer extensions that allow source nodes anywhere in the Internet to disseminate packets to all/any node(s) with geographic location awareness within a specified destination area. Use cases include environmental monitoring and vehicular networking.
Outcome: More work is required to narrow the scope of this proposed activity so that it more closely aligns with IETF work. Another BoF meeting seems necessary to achieve that. Approximately 20 attendees expressed interest in working on documents on this subject.
Handling Pervasive Monitoring in the IETF (perpass)
Description: The perpass BoF was for discussion of the privacy properties of IETF protocols and concrete ways in which those properties could be improved. The meeting was not intended to be a precursor to formation of a WG, but rather to, for example, discuss ways in which IETF protocols at any layer can be made more robust against pervasive passive monitoring. If subsequent protocol work is to be done in the IETF, it will likely happen in existing or new protocol-specific WGs.
Outcome: A lot of good discussion including identification of many potential work items for IETF, IAB, and others. The threat model is fairly mature. Discussion will continue on the perpass mailing list (https://www.ietf.org/mailman/listinfo/perpass).
Service Function Chaining (sfc)
Description: Network operators frequently utilize service functions such as packet filtering at firewalls, load-balancing, and transactional proxies (e.g., spam filters) in the delivery of services to end users. Delivery of these types of services is undergoing significant change with the introduction of virtualization, network overlays, and orchestration.
Deploying service functions to support service delivery is currently both a technical and an organizational challenge involving significant modification to the network configuration, impacting the speed at which services can be deployed, and increasing operational costs. Such services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within a network.
Today, common deployment models have service functions inserted on the data-forwarding path between communicating peers. Going forward, however, there is a need to move to a model in which service functions—physical or virtualized—are not required to reside on the direct data path and traffic is instead steered through required service functions wherever they are deployed.
For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated through selection of specific service function instances on specific network nodes to form a service graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (network layer, transport layer, application layer, etc.).
Outcome: This meeting was very well attended. The group of active participants have made considerable progress since their last meeting in Berlin (where they had a non-WG forming BoF). Lots of attendees volunteered to work on this topic and write documents. More work is required to define key terminology and more discussion will be required on the mailing list. (Editorial note: The Service Function Chaining working group was chartered on 20 December 2013).