* 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 http://www.ietf.org/wg/bof-procedures.html.

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)
  • Does it require WebEX? If so, why?
  • Does it require Meetecho? If so, why?
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Template for BOF Entry

Timeframe IETF 90 (Toronto)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 2359 UTC Friday, June 6, 2014. 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 June 20.

Applications

General

IANAPLAN (Approved for IETF 90)

  • Long name and abbreviation: IANAPLAN
  • Description, including whether the BoF is intended to form a WG or not: Description, including whether the BoF is intended to form a WG or not: This meeting will discuss recent Internet-goverance related topics, this time mainly about IANA/NTIA transition. Unlike previous occurrences of this meeting, the IESG needs to discuss with the IAB whether this will be a true BOF and whether it might eventually form a WG. At some point an IETF discussion on the IANA topic is needed, including whether the IETF will have a consensus position on that topic, so we need to determine if a meeting slot is needed for that in Toronto. The default assumption is that this will be an IAB-only session and that any IETF discussion will happen on list and/or later.
  • The responsible Area Director (AD): Jari Arkko
  • BoF Chairs (or the ADs as placeholders): Marc Blanchet
  • Number of people expected to attend: 150
  • Length of session (1, 1.5, 2, or 2.5 hours): 2
  • Conflicts to avoid (whole Areas and/or WGs): Area meetings, RFCFORMAT
  • Does it require WebEX? If so, why? No
  • Does it require Meetecho? If so, why? Remote attendance support is preferred.
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.: http://www.iab.org/mailman/listinfo/internetgovtech[[BR]]

Internet

AECON (Not Approved for IETF 90)

  • Name: Application Enabled Collaborative Network (AECON)
  • Description:

Identification and treatment of application flows are important to many application providers and network operators. They often rely on these capabilities to deploy and/or support a wide range of applications. Network operators seek visibility of traffic usage and patterns for troubleshooting, capacity planning, user billing, and other off network workflows. Applications, and the packet flows they generate and consume, may require specific bandwidth, latency, etc., that can be better met if made known to the network.

Historically, there is no direct communication mechanism between applications and network that helps flow identification and treatment. This functionality has been implemented to the extent possible using heuristics, which inspect and infer flow characteristics. Heuristics may be based on port ranges, network separation (e.g. subnets or VLANs), Deep Flow Inspection (DFI), or Deep Packet Inspection (DPI). But many application flows in current usages are dynamic, adaptive, time-bound, encrypted, peer-to-peer, asymmetric, used on multipurpose devices, and have different priorities depending on direction of flow, user preferences, and other factors. Current heuristics lack in flexibility or granularity, impact performance due to inspection processing, and are often non-standard leading to inaccuracy and inconsistency across vendors. Any combination of these properties renders heuristic based techniques less effective and may result in compromised application security and/or user privacy.

The purpose of Application Enabled Collaborative Network (AECON) is to enable communication between applications and the network by active information exchange. Applications have the ability to opt-in to information exchanges that enable a more precise allocation of network resources and thus a better user experience. This exchange provides network nodes with visibility of the application flow characteristics, yet protects applications from unwanted information leakage. Network nodes may take action based on this visibility and/or contribute to the flow description. Feedback from the network to the application enables applications to willingly adjust their operation to better align with the prevailing network conditions. As the IETF establishes default behaviors that thwart pervasive surveillance, it will be important to provide such mechanisms for applications that want to have the network provide differential flow treatment for their data. The exchange of information should be considered as hints rather than explicit promises, providing potential for cooperation between application and network that is extensible and allows ad-hoc arrangements.

Initially the group will focus on the follow aspects:

  1. Identify problems and limitations of existing solutions.
  2. Investigate a set of realistic use cases for an AECON solution based on explicit communication between applications and the network.
  3. Specify a set of requirements for such a solution.
  4. Describe gaps between existing practices and desired functionalities.

After completing the above work the group will seek re-charter to address the solution scope, e.g. information that needs to be communicated between applications and the network, framework for providing such communication, protocol extension to support this framework, etc.

Operations and Management

UCAN (Approved for IETF 90)

  • Name: Use Cases for Autonomic Networking (UCAN)
  • Description:

The fundamental goal of Autonomic Networking (AN) is self-management, including self-configuration, self-optimization, self-healing and self-protection. AN aims at putting the intelligence of today's operations back into algorithms at the node level, to minimize dependency on human administrators and central management systems. Nodes capable of AN will need to discover information about the surrounding network and to negotiate parameter settings with their neighbors and other nodes. They may also have learning and cognitive capability, i.e. the ability for distributed entities to self-adapt their decision making process based on information and knowledge gained from their environment (sensing).

However, human administrators will still want to influence the network and set policy. Where devices require such input, it should be provided in a highly abstract, network-wide form referred to as "intent".

Autonomic Networking focuses on self-management of network elements. An autonomic function works in a distributed way across various network elements, allowing however central guidance and reporting. Autonomic functions already exist today, for example IGP routing protocols such as OSPF. However, all such functions have their own discovery, messaging and security mechanisms.

To transform this somewhat abstract Autonomic Networking concept into concrete, realisable requirements, the first stage, undertaken in the IRTF, was to define terminology and design goals, and to derive a high-level gap analysis. To take this further, there is a need for several realistic and specific use cases that can be used as a reference and as a plausibility test for developing requirements. Therefore, this BoF collects and analyses use cases for Autonomic Networking. The goal is to find commonalities between various use cases, to be able to determine generic requirements for Autonomic Networking functions and to conclude whether there is scope for a common, generic Autonomic Networking Infrastructure for all autonomic functions.

The UCAN BOF is intended to expose several use cases to community review and to identify other possible use cases. Several use cases assume that some sort of general discovery and negotiation protocol is available. The goal of the UCAN BoF is NOT to develop solutions for the use cases listed. However, the type of solution envisaged, its design goals, and sketches of solution approaches will be covered.

The next stage will be to consolidate the use cases and to to extract common requirements for an autonomic infrastructure. These requirements are in the following areas:

  • identity of nodes
  • a common security model
  • a discovery model (for autonomic nodes to discover other nodes)
  • a negotiation model (for cooperation between autonomic nodes)
  • a communication method
  • a policy model (for use cases that require policy)
  • a management model (because humans remain in the picture)

Preliminary directions for possible protocol work are indicated in a problem statement (draft-jiang-config-negotiation-ps) and strawman protocol (draft-jiang-config-negotiation-protocol) but these are indicative only.

TIME (Not Approved for IETF 90)

  • Name: Transport Independent OAM in Multi-Layer network Entity (TIME)
  • Draft agenda :
    • Administration (chairs: 5 mins)
    • Agenda bash (chairs: 5 mins)
    • Purpose of the BoF (AD: 5 mins)
    • Introduction to problem space (TBD: 15 mins)
    • Generic OAM possibilities (TBD: 15 mins)
    • OAM and SFC (TBD: 15 mins)
    • Open discussion (30 minutes)
    • Potential charter (chairs: 15 minutes)
    • Closing remarks (chairs: 7 minutes)
    • Closing remarks (AD: 8 minutes)
  • Description:

The basic concepts of Operations, Administration, and Maintenance (OAM) and the functional roles in monitoring and diagnosing the behavior of telecommunications networks have been long term studied at the Layer 1&2 & Layer 3 levels. The current practice is that many technologies and layers have their own OAM protocols. There is little or no re-use of software and hardware for each existing OAM protocol. Vendors and operators waste a lot through the whole OAM life-cycle when a new technology is introduced. Integration of OAM across multiple technologies is extremely difficult. When having networks with more than one technology, maintenance and troubleshooting are done per technology and layer, operation process can be very cumbersome. In many cases it is desirable to have a generic and integrated OAM to cover heterogeneous networking technologies. Generic and integrated OAM tools should be deployed over various encapsulating protocols, and in various medium types.

The goal of TIME Group is to :

  • Understand and discuss the times when an OAM protocol can be tuned and optimised for a specific data plane (for example, OAM in a packet network can be very different from OAM in a circuit switched network because of the different characteristics of the network)
  • Seek the best ways to
    • Exchange OAM information at the service layer atop of layer 3
    • Abstract OAM information common to different layer
    • Provide them via unified interface to management entities.
    • Set up Maintenance Domains (MD) and Maintenance Intermediate Points (MIP)
    • Enable OAM function at different layer in the multi-layer network
    • Activate OAM function a different layer and provide results to management entity

We have been aware that there is substantial interest in this topic from IETF NETMOD working group, NVO3 working group, SFC working group regarding Generic and integrated OAM. The TIME Group is intended to set out the problem statement and architecture for the Transport Independent OAM in the multi-layer network and outlines the problems encountered with existing OAM protocol variety and their impact on introduction of new technologies. In addition, the TIME Group will analyse and understand the different motivations and opportunities for optimisation of OAM in different technology networks, and the trade-offs between those optimisations and the overall advantage of a generic OAM mechanism.

An example of an environment in which a generic and integrated OAM protocol would be valuable is Service Function Chaining. A Service Function Chaining is composed by a series of service functions, that can act in different layers but providing an end-to-end chain or path from a source to destination in a given order. In service function chaining environment, it is necessary to provide end to end OAM across certain or all entities and involving many layers. OAM information should be exchanged between service functions in different layers while using various encapsulating protocols. In some cases OAM should cross different administration and/or maintenance domains.

NFVCON (Not Approved for IETF 90)

  • Name: Network Function Virtualisation Configuration (NFVCon)
  • Description: NFVCon BoF is going to discuss network function virtualision configurations. The problem space is limited to the issues related to the virtualisation characteristics of network functions, which make operations and management different from the physical applicances. But now, there lack of standard protocol(s) among network function providers, network function consumer, and NFV control and management plane for virtual network function lifecycle management, virtual network function migration, resource automatic scale-out/in, and virtual network function description (from the network function providers). The BoF can result in some protocol extensions in the existing IETF working groups (such like NetConf? or SFC) or a potential new working group.

RAI

Routing

ACTN (Approved for IETF 90)

  • Long name and abbreviation: Abstraction and Control of Transport Networks (ACTN)
  • Status: non-WG Forming
  • Description:

Network operators build and operate multi-domain networks. These domains may be collections of links and nodes each of a different technology, administrative zones, or vendor specific islands. Establishment of end-to-end connections spanning multiple domains is a perpetual problem for operators both because of operational concerns (control plane and management plane) and because of interoperability issues (control plane and data plane). Due to these issues, the introduction of new services, often requiring connections that traverse multiple domains, needs significant planning, and several manual operations to interface different vendor equipment and technology.

The aim of ACTN is to facilitate virtual network operation: the creation of a virtualized environment allowing operators to view and control multiple multi-subnet, multi-technology networks as a single virtualized network. Network abstraction of transport networks is also necessary for operators that consolidate their network services into multi-tenant virtual transport networks. This will accelerate rapid service deployment of new services, including more dynamic and elastic services, and will improve overall network operations and scaling of existing services. Discussion with operators has highlighted a need for virtual network operation based on the abstraction of underlying technology and vendor domains. This would be used for a variety of key use cases, including:

o Physical network infrastructure providers who want to build virtual network operations (VNO) infrastructure via a standards-based API that facilitates automation and operation of multiple virtual networks for both internal and external trust domains.

o Data Center operators that need to lease facility from a number of physical network infrastructure providers to offer their global data center applications and services. As they face multi-domain and diverse transport technology, interoperability based on standards-based abstraction will enable dynamic and flexible applications and services.

This BoF is a non-WG forming BoF. This BoF will be organized in such a way that gives operators an opportunity to express their current operational practices, highlighting operational pain points, network virtualization requirements and objectives, short-term goals, and longer-term aspirations.

Security

Transport

TCPINC (Approved for IETF 90)

  • Long name and abbreviation: TCP Increased security (TCPINC)
  • Description, including whether the BoF is intended to form a WG or not: this is intended as a WG forming BOF.

The TCP Inc. WG will develop the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams. The WG will define an unauthenticated key exchange mechanism. In addition, the WG will define the TCP extensions to utilize unauthenticated keys, resulting in encryption and integrity protection without authentication. This is better than plain-text because it thwarts passive eavesdropping, but is weaker than using authenticated keys, because it is vulnerable to man-in-the-middle attacks during the initial unathenticated key exchange. This work is part of the IETF effort to harness the Internet architecture given the latest events of pervasive monitoring (see draft-farrell-perpass-attack).

DTNWG (Approved for IETF 90)

  • Name: Delay Tolerant Networking Working Group (DTNWG)
  • Description:

The DTN BoF will investigate interest in transitioning technologies developed in the IRTF DTN research group into standards-track activities through the formation of a new IETF working group. The BoF will present a draft working group charter, including work items based on the DTN Bundle Protocol (BP). The goal of the BoF will be to discuss the draft charter and present the candidate work items, as well as to determine the level of support for conducting the work in the IETF. The desired end state is the formation of a new working group soon after IETF90.

VNFPOOL (Approved for IETF 90)

  • Name: Virtualized Network Function Pool (VNFPool)
  • Description:

Network functions such as firewalls, load balancers, and WAN optimizers are conventionally deployed as specialized hardware servers in both network operators' networks and data center networks as the building blocks of network services. There is a trend to implement such network functions as software instances running on general purpose servers, via a virtualization layer (i.e., hypervisors). These virtualized functions are called Virtualized Network Functions (VNFs), which can be used to build network services.

The use of VNFs introduces additional challenges to the reliability of the provided network services. A single VNF instance would typically not have built-in reliability mechanisms on its host (i.e., a general purpose server). Instead, there are more risk factors such as software failure at various levels including hypervisors and virtual machines, hardware failure, and instance migration that can make a VNF instance unreliable.

In order to achieve higher reliability, a VNF implementation may adopt a pooling mechanism, where a number of VNF instances with the same function can be grouped as a pool to provide the function. We call such a pool a VNF Pool. Conceptually, a Pool Manager is used to manage a VNF Pool, e.g., selects active/standby VNF instances, and potentially interacts with a service control entity. Such a service control entity is an entity that orchestrates a set of network functions to build network services. The major benefit of using VNF Pool is that reliability mechanisms such as redundancy model are achieved by the VNF Pool adopted by the VNF and thus not visible to the service control entity. A VNF Pool-enabled VNF still appears as a normal VNF when orchestrated by a service control entity.

Questions that are raised by the addition of a pooling mechanism to VNF include:

• How to manage the redundancy model, e.g., select active/standby VNF instances in a VNF Pool considering the infrastructure conditions, and scale a VNF instance in a VNF Pool?

• What pool states need to be maintained to support the pooling mechanism itself, and how are such states maintained?

• What information is exchanged between a VNF and a service control entity? For example, how can a VNF Pool be addressed by the service control entity?

• After a VNF instance failover, how does the Pool Manager notify the service control entity of some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?

The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of a same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed of both virtualized and non-virtualized functional instances may be included after further use case and requirements study. The WG will address the reliability of an individual VNF, but not the reliability related to the control or the routing between adjacent VNFs that can form a network service.

Specifically, the WG will study the following technical aspects:

• Redundancy management within a VNF Pool, such as the signaling between the Pool Manager and the instances in the pool for instance registration, backup instances selection, and switching between active and standby instances.

• Protocol between the Pool Manager and the underlying network to collect the network information required for appropriate placement/selection of backup instances.

• Protocol between a VNF and the service control entity to exchange operational information between a VNF Pool and the service control entity.

• Identification and analysis of reliable interfaces, such as transport protocol like MPTCP and SCTP for reliable delivery of the messages associated with the redundancy management within a VNF Pool.

• Analysis of pooling security characteristics and requirements to identify and mitigate threats against the pooling mechanism. Identification of an appropriate trust model between pool members, and between pool members and the Pool Manager.

The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and gap analysis of existing technologies including but not limited to RSerPool. We will rely heavily on existing IETF technologies, but that gaps will be found around problems like redundancy mechanisms, state maintenance solely for pooling purposes, reliable transport, and trust/security, all of which will need to be considered and addressed. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for VNF Pool. The WG will seek re-chartering before adopting any work to develop new, or extend existing, protocols.

We will work closely with the SFC WG, as we believe that SFC and VNF Pool are complementary. SFC would essentially see a VNF Pool-enabled VNF as a normal service function and therefore be able to merge it into an SFC just like any other service functions. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool.

TAPS (Approved for IETF 90)

  • Long name and abbreviation: Transport Services (TAPS)
  • Status: in charter review process
  • Description, including whether the BoF is intended to form a WG or not

Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism extend the number of transport services to applications in addition to the long-standing two services provided by TCP and UDP. For example, SCTP provides potentially faster reliable delivery for applications that can accept blocks of data out of order, and LEDBAT provides low-priority "scavenger" communication. For an application programmer, it is hard to use protocols other than TCP or UDP: not all protocols are available everywhere, hence a fall-back solution to e.g. TCP or UDP must be implemented. Some protocols provide the same services in different ways. Layering decisions must be made (e.g. should a protocol be used natively or over UDP?). Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP, and chances of benefiting from other transport protocols are lost.

There are many ways in which this problem could be addressed; while it may not yet be clear what the best way forward could be, any approach to provide a richer set of transport services to applications will have to begin with the identification of the services that current transport protocols provide.

The Working Group will: 1) identify services provided by existing IETF transport protocols and congestion control mechanisms. The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service. 2) specify a set of transport services that end systems supporting TAPS need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service. 3) specify experimental mechanisms to discover the availability of protocols on an interface (both end system and path support), in order to provide a basis for incremental deployment. This will explain how to select and engage a protocol to deliver a transport service.

APONF (Not Approved for IETF 90)

  • Long name and abbreviation: APONF (Application-based Policy for Network Functions)
  • Description, including whether the BoF is intended to form a WG or not (Intended to form a WG)

Today network operators are challenged to create an abstract view of their network infrastructure and help application developers on using and programming this abstraction rather than manipulating individual devices. An abstract view of a network infrastructure can be realized using a network service graph that describes the network service attributes, e.g., topology, flow treatment policy, Distributed Data Center policy, IPv6 transition policy, associated with a network management application. Network management applications are Operational Support System (OSS) like applications that help a communication service provider to monitor, control, analyze and manage a communication network. In this context, network management applications can be used to provide the required configuration and application programming interfaces to such application developers. Subsequently, a network management application can use the application based demands and possibly update its associated network service graph.

The main goal of APONF is to (1) enable the streaming transfer of bulk-variable/data of the up to date network service graphs between network management application systems and the network management and controlling systems, by using and extending an existing IETF specified signaling protocol, (2) map the attributes of the network service graph into specific network management policies, i.e., device level configuration models.

Work items related to APONF include:

  • specify the problem statement and use cases
  • produce an analysis identifying the gaps between existing signaling

protocols and the APONF requirements and use cases.

  • specify the APONF architecture
  • specify extensions to an existing IETF signaling protocol to distribute network service graphs between network management applications (e.g., OSS applications) and network management systems, the routing controlling system or other controlling systems. A possible candidate signaling protocol could be the IETF NSIS protocol framework.
  • specify mechanisms that can dynamically map the network service graphs into specific device level configuration models
  • specify the AAA method.

The following items are out of the APONF scope:

  • the generation of the abstract view of the network infrastructure using an network service graph
  • the necessary configuration interfaces to service developers to program the abstract view of a network infrastructure.
  • definition of the used network service graphs
  • the specification of the network management policies and their associated device configuration models

Milestones:

  • I-D 'Problem Statement and Use Cases' as an Informational RFC.
  • I-D 'APONF Gap Analysis as an Informational RFC.
  • I-D 'APONF Architecture' as an Informational RFC.
  • I-D 'Mapping network service graphs into specific device level configuration models' as an Informational RFC.
  • I-D 'APONF Protocol Specification' Standards Track RFC.

1)Problem Statement:

2)Architecture:

3) Use case drafts:

4) Gap analysis:

IAB Sessions

RFCFORMAT (Approved for IETF 90)

  • Long name and abbreviation: RFC Format Update (RFCFORMAT)
  • Description, including whether the BoF is intended to form a WG or not: This is non-WG forming meeting, sponsored by the Gen AD on a request from the RFC Editor. The purpose is to report out on the current drafts defining the requirements for the new RFC Format model.
  • The responsible Area Director (AD): Jari Arkko
  • BoF Chairs (or the ADs as placeholders): Heather Flanagan
  • Number of people expected to attend: 75, + or - 25
  • Length of session (1, 1.5, 2, or 2.5 hours): 1
  • Conflicts to avoid (whole Areas and/or WGs): Please avoid IPFIX and EMAN, and any IAB session.
  • Does it require WebEX? If so, why? No
  • Does it require Meetecho? If so, why? Yes, this is likely to be of interest of people unable to make it to the meeting.
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc: mailing list: http://www.rfc-editor.org/mailman/listinfo/rfc-interest[[BR]]

Previous meeting BOFs

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)