* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Birds of a Feather Meetings (IETF Pre-WG Efforts)

This page provides one common place that lists "possible IETF pre-WG efforts", known as Birds of a Feather ("BoF") meetings. Anybody who proposes a BoF is strongly encouraged to register the BoF effort here at such time as appropriate; e.g., during steps 1 and 2 in RFC 5434. Also see https://www.ietf.org/wg/bof-procedures.html.

The IAB will also attempt to provide BoF Shepherds as described in their document on the subject only on request from the IESG. If you feel that your BoF would benefit from an IAB BoF Shepherd, please discuss this with your Area Director.

To allow the Secretariat to schedule a BoF slot if it is approved, each entry MUST include the following items:

  • Long name and abbreviation
  • Description, including whether the BoF is intended to form a WG or not
  • The responsible Area Director (AD)
  • BoF Chairs (or the ADs as placeholders)
  • Number of people expected to attend
  • Length of session (1, 1.5, 2, or 2.5 hours)
  • Conflicts to avoid (whole Areas and/or WGs)
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Template for BOF Entry =

Timeframe IETF 101 (London)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 2359 UTC Friday, 2018-02-02. The IAB and IESG will hold a joint teleconference to discuss the proposals. ADs will be expected to approve or disapprove the BOF request on that teleconference, ensuring that the Secretariat has all of the information to put the first draft of the agenda together on or before 2018-02-16.

Applications and Real-Time

General

IETF Administrative Support Activity 2.0 (IASA20) - APPROVED FOR IETF 101

Description:

The purpose of this non-WG-forming BOF is to continue discussions from IETF 98, 99, and 100 and the iasa20@ietf.org mailing list regarding refactoring the IETF Administrative Support Activity (IASA). There is currently legal work underway to analyze the range of options in which the community expressed interest at IETF 100. That analysis should be available for community discussion well in advance of IETF 101, so this session will provide an opportunity for high-bandwidth exchange about that.

The responsible Area Director (AD): Alissa Cooper
BoF Chairs: Jon Peterson
Number of people expected to attend: 100
Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
Conflicts to avoid (whole Areas and/or WGs): mtgvenue, all of sec area, stir, modern, tram, sipbrandy
Mailing List: ​https://www.ietf.org/mailman/listinfo/iasa20
Draft charter: n.a.
Relevant drafts:

BCP 101 is the key document that already exists in this space and that may be modified. Entirely new policies or documents may be required in the future depending on the outcome of the discussions.

Internet

IP Issues and Associated Gaps in Fifth Generation Networks (atick) - NOT APPROVED FOR IETF 101

-- Introduction to problem space – new network concepts require new approaches (Chairs)

-- Issues with and specifics of current tunneling approaches as e.g. 3GPP GTP (Alex)

-- Proposed approach in terms of basic framework for flexible path optimisation based on an extensible ID-Loc split protocol, e.g. ILNP (Saleem)

-- Essential features to be addressed in future steps (Arash) -- Proposed charter and milestones (chairs) -- Q&A -- Discussion

  • Full Description of BOF

-- Within future converged (wireless/wireline) communication systems based on IPv6 which attempt to provide revolutionary new network concepts (e.g. slicing) traditional approaches as Tunneling is still foreseen. Such protocols may create too much overhead and hide important information required for service-specific handling of data packet flows. Not only may the tunnel overhead exceed the payload by orders of magnitude (e.g. for some IoT messages) and result in MTU size issues and packet fragmentation but also create signaling related to tunnel management such as establishment, maintenance, and tear down, as well as tracking the state of the tunnels in all layers (see e.g. https://tools.ietf.org/html/draft-ietf-intarea-tunnels<https://tools.ietf.org/html/draft-ietf-intarea-tunnels%5D>).

-- Currently discussed Id-Loc split approach (e.g. LISP, ILNP, ILA) could be advantageous here especially with regard to simplifying routing by keeping Identity stable during a session/flow, allowing integration of multiple heterogeneous access technologies, being flexible to add functionalities only on-demand, and intrinsically supporting mobility. Such approaches also well fit to work in virtual environments (SDN/NFV) and can react dynamically to changes of locations of processing resources (e.g. for virtual machines executing VNFs).

-- Most Id-Loc split solutions need mapping server to look up efficiently for changes in locators of Identities as e.g. provided by DNS. Scalability and performance of such mapping systems will be in scope of future work.

-- Existing Id-Loc split approaches require extensions to allow for optimization of the routing path which could be derived from the mapping records if properly constructed and distributed.

-- As a first step, atick will address an analysis of the features the alternative protocol has to provide (e.g. what currently is built-in in GTP).

-- Specification of the complete protocol enhancements to support e.g. charging and policy enforcement, but also interoperability and migration from existing network structures will be in scope of future work items. Also the ultimate evaluation of a comparison to GTP in terms of performance and effort etc. can be reliably achieved only once the alternative protocol framework is fully specified.

-- Main scope of this BoF is to agree on a proper sized problem space and start on researching the solution space.

  • CONFLICTS you wish to avoid, please be as specific as possible: INTarea, dmm, lisp, 6man, nvo3, sfc
  • Expected Attendance (figures from the previous IETF meeting are included in the message that is sent when scheduling opens):100
  • Special requests:none
  • Number of sessions:1
  • Length of sessions: 1 hour

Identifier Locator Addressing (ILA) - APPROVED FOR IETF 101

Description:

ILA is a protocol to implement transparent network overlays without encapsulation. It addresses the need for network overlays in virtualization and mobility that are efficient, lightweight, performant, scalable, secure, provide seamless mobility, leverage and encourage use of IPv6, provide strong privacy, are interoperable with existing infrastructure, applicable to a variety of use cases, and have simplified control and management. While many solutions have been proposed, none seem to meet all these requirements.

ILA is a type of identifier/locator split that partitions an IPv6 address into identity and location components. Unlike previously defined identifier-locator protocols (e.g. 8+8, ILNP), ILA is wholly contained within the network layer. It is not required to be used end to end and requires no changes to transport layer protocols or applications. ILA modifies destination addresses in flight, however, unlike in NAT, any modification is reversed before delivery. Since ILA does not use encapsulation, issues with in-network tunneling-- such as MTU and fragmentation, ECN and diffserv propagation, zero UDPv6 checksum handling in UDP encapsulations-- are not relevant.

Identifier Locator Addressing use cases include mobile networks, datacenter virtualization, and network virtualization. A recent trend in the industry is to build converged networks containing all three of these to provide low latency and high availability. A single network overlay solution that works across multiple use cases is appealing.

There are two aspects to ILA: a data plane and control plane. The data plane includes the ILA address transformation mechanism and ancillary protocol support. The control plane’s main focus is a mapping system that maps identifier to locators. Major problems to be solved in a mapping system include 1) scaling to support billions of entries 2) securing privacy sensitive data about users. A task in this effort will be to evaluate the use of key-value store databases in a mapping system.

Scope of this BoF is to identify the problem and get direction on the proposed solution.

Responsible AD: Suresh Krishnan
BoF Chairs: TBD
Number of people expected to attend: 50
Length of session: 1 hour
Conflicts to avoid (whole Areas and/or WGs): INTarea, dmm, lisp, 6man, nvo3, sfc, idr
Draft charter: https://mailarchive.ietf.org/arch/msg/ila/zteb1NSpqBO22zwyQGjK6K4dYos
Mailing List: https://www.ietf.org/mailman/listinfo/ila
Agenda:

  • Problem Statement & Motivation
  • Supporting Drafts & Technical Solutions
  • Discussion
  • Wrap-up & Chair Questions

Relevant drafts:

Operations and Management

Common Operations and Management on network Slices (COMS) - APPROVED FOR IETF 101

Description:

A network slice is a set of infrastructure resources and service functions that has attributes specifically designed to meet the needs of an industry vertical or a service. Network slices may be instantiated in a single domain or across multiple domains, and they may use heterogeneous technologies. The goal of this group is to produce and promote a technology-independent and resource-centric management plane for network slices.

COMS will describe an overall architecture for network slicing, work on information model which further guide the design of service delivery interface (SDI) and customer service interface (CSI). COMS will also specify network slicing OAM, as well as management requirements and functionalities data plane entities as needed to enable the operation of network slices. However, COMS will not attempt to replicate existing device models and data plane technologies.

Status: WG Forming
Responsible AD: Benoit Claise
BoF Chairs: TBD
Number of people expected to attend: 150
Length of session: 2 hours
Conflicts to avoid (whole Areas and/or WGs): teas, detnet, sfc, nov3, opsarea
Mailing List: https://www.ietf.org/mailman/listinfo/netslices
Draft charter: https://mailarchive.ietf.org/arch/msg/netslices/-UeKDF3rPsBOsya1m6ytINKi4v4
Relevant drafts:

Agenda:

  • Admin [5 mins]
  • Problem Statement & Motivation [30 mins]
  • Supporting Drafts & Technical Solutions [20 mins]
  • Charter Discussion [30 mins]
  • Wrap-up & Chair Questions [35 mins]

YANG data model is one of the key existing practice in terms of modeling language in this problem space. New practice is required in the context of network slice operation and management. This may also lead to new protocols and modifications of existing protocols for the purpose of slice-level OAM.

Routing

Routing In Fat Trees (rift) - APPROVED AS A WG 2018-02-08

  • Description: WG in Formation (placeholder)
  • Responsible Area Director (AD): Alvaro Retana
  • Proposed WG Chairs: Jeffrey Zhang, Jeff Tantsura
  • Number of people expected to attend: 50
  • Length of session: 2 hours
  • Conflicts to avoid: babel, bier, idr, isis, ospf, lsr, rtgwg, rtgarea, bess, nvo3
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

https://datatracker.ietf.org/wg/rift/about/

Link State Vector Routing (lsvr) - APPROVED FOR IETF 101

  • Description: WG in Formation (placeholder)
  • Responsible Area Director (AD): Alvaro Retana
  • Proposed WG Chairs: Gunter Van de Velde, Victor Kuarsingh
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid: babel, bier, idr, isis, ospf, lsr, rtgwg, rtgarea, sidrops, opsec, spring, bess, grow, nvo3
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

https://datatracker.ietf.org/wg/lsvr/about/

Security

EAP Method Update (emu) - APPROVED FOR IETF 101

  • Description: Placeholder: looking to form a WG before London based on SecDispatch? feedback
  • The responsible Area Director (AD): Kathleen Moriarty
  • BoF Chairs: TBD
  • Number of people expected to attend: 30
  • Length of session: 1.5 hours - need to confirm
  • Conflicts to avoid: Will update
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc. https://datatracker.ietf.org/wg/emu/about/[[BR]]

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Trusted Execution Environment Provisioning (teep) - APPROVED FOR IETF 101

  • Description, including whether the BoF is intended to form a WG or not
  • The responsible Area Director (AD)
  • BoF Chairs: Dave Thaler and Nancy Cam-Winget)
  • Number of people expected to attend: 100
  • Length of session 2 hours
  • Conflicts to avoid: First Priority: suit ace core mile oauth, Second Priority: t2trg lwig saag tls opsawg anima, Third Priority: v6ops 6man intarea
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Security Dispatch (SECDISPATCH) - APPROVED FOR IETF 101

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Messaging Layer Security (mls) - APPROVED FOR IETF 101

  • Long name and abbreviation: Messaging Layer Security (MLS)
  • Description, including whether the BoF is intended to form a WG or not
    • The intent of this BoF is to form a WG
    • Several Internet applications have a need for a group key-establishment and message-protection protocol with the following properties:
      • Asynchronicity - Keys can be established without any two participants being online at the same time
      • Forward secrecy - Full compromise of a node at a point in time does not reveal past group keys
      • Post-compromise security - Full compromise of a node at a point in time does not reveal future group keys
      • Membership Authentication - Each participant can verify the set of members in the group
      • Message Authentication - Each message has an authenticated sender
      • Sub-linear scaling in the size of the group
    • Several widely-deployed applications have developed their own protocols to meet these needs. While these protocols are similar, no two are close enough to interoperate. As a result, each application vendor has had to maintain their own protocol stack and independently build trust in the quality of the protocol. The primary goal of this working group is to develop a standard security protocol so that applications can share code, and so that there can be shared shared validation of the protocol (as there has been with TLS 1.3). It is not a goal of this group to enable interoperability between messaging applications.
  • In developing this protocol, we will draw on lessons learned from several prior message-oriented security protocols, in addition to the proprietary protocols deployed within apps:
  • The responsible Area Director (AD): Kathleen Moriarty / Ben Kaduk
  • BoF Chairs: TBD
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid: TLS, DISPATCH, SECDISPATCH, SAAG, ACME, QUIC, PERC
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Application Transport LAyer Security - NOT APPROVED FOR IETF 101

  • Long name and abbreviation: Application Transport LAyer Security (ATLAS)
  • Description, including whether the BoF is intended to form a WG or not
    • The intent of this BoF is to form a WG or to use an existing working group
    • There is a need to offer application layer security where communication establishment is followed by an exchange of an arbitrary number of application data. This application layer security mechanism requires authentication of the endpoints, and a modern a key exchange protocol. The result of a positive handshake will lead to the establishment of keying material and negotiated algorithms for confidentiality, integrity and replay protection of application data. There is precedence for embedding TLS in "applications" and this group will develop specifications that define embeddings for different application protocols, such as CoAP, and HTTP.
  • The responsible Area Director (AD): Kathleen Moriarty / Ben Kaduk / Eric Rescorla
  • BoF Chairs: TBD
  • Number of people expected to attend: 70
  • Length of session: 2 hours
  • Conflicts to avoid: TLS, OAUTH, ACE, HTTPBIS, QUIC
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Cleartext JSON Object Signing and Encryption (jose)

  • Withdrawn

Transport

IAB Sessions

Previous meeting BOFs

Timeframe IETF 100 (Singapore)

Timeframe IETF 99 (Prague)

Timeframe IETF 98 (Chicago)

Timeframe IETF 97 (Seoul)

Timeframe IETF 96 (Berlin)

Timeframe IETF 95 (Buenos Aires)

Timeframe IETF 94 (Yokohama)

Timeframe IETF 93 (Prague)

Timeframe IETF 92 (Dallas)

Timeframe IETF 91 (Honolulu)

Timeframe IETF 90 (Toronto)

Timeframe IETF 89 (London)

Timeframe IETF 88 (Vancouver)

Timeframe IETF 87 (Berlin)

Timeframe IETF 86 (Orlando)

Timeframe IETF 85 (Atlanta)

Timeframe IETF 84 (Vancouver)

Timeframe IETF 83 (Paris)

Timeframe IETF 82 (Taipei)

Timeframe IETF 81 (Quebec City)

Timeframe IETF 80 (Prague)

Timeframe IETF 79 (Beijing)

Timeframe IETF 78 (Maastricht)

Timeframe IETF 77 (Anaheim)

Timeframe IETF 76 (Hiroshima)

Timeframe IETF 75 (Stockholm)

Timeframe IETF 74 (San Francisco)

Timeframe IETF 73 (Minneapolis)

Timeframe IETF 72 (Dublin)

Timeframe IETF 71 (Philadelphia)

Timeframe IETF 70 (Vancouver)

Timeframe IETF 69 (Chicago)

Timeframe IETF 68 (Prague)

Timeframe IETF 67 (San Diego)

Timeframe IETF 66 (Montreal)

Timeframe IETF 65 (Dallas)