This page lists the bar BOFs that we currently know of – feel free to add to this list!
NOTE WELL: Bar BOFs are not official IETF meetings. Please see http://tools.ietf.org/html/draft-eggert-successful-bar-bof-05 for some thoughts about how to make bar BOFs effective, and things to avoid when planning a bar BOF.
Bar BOFs may happen in bars, alcoholic beverages may be involved, and the meetings are not at all guaranteed to lead to any actual IETF work. Nevertheless, the NOTE WELL may apply.
Time: Monday, July 25th 2011, 20:00.
Description: In general, two networks service a data center. The first is entirely contained by the data center. The second is the ISP network(s) that connects the datacenter to the global Internet. The datacenter network usually covers a large number of servers, connected to an Ethernet fabric, in a single location, under the administrative control of a single organization.
We are proposing creating a group that will attempt to document the main architectures that are in use, the pros and cons of each and the best current practices for designing and, more importantly, operating, these networks.
This working group will identify requirements levied by the data centers upon those networks. It will also identify potential solutions if those solutions can be cobbled together from existing protocols. If solutions cannot be cobbled together from existing protocols, the WG will generate requirements to be thrown over the wall to a WG that is chartered to produce new protocols.
This WG will focus on networking issues that are characteristic of the data center. It will not address the following issues of data center operation:
Goal: The goal of the Bar BoF will be to generate a problem statement (obviously after gauging interest, discussing scope of the group, what sorts of issues folk are experiencing, etc.)
See http://tools.ietf.org/id/weirds for drafts.
WEIRDS is an effort to develop a whois-like RESTful service. The goal is to address internationalization, structured data, and authenticated access concerns. This is similar to the CRISP effort that led to IRIS, except that people seem to find IRIS too complicated to deploy. A RESTful approach will, we hope, address those complaints about complexity.