A month before the meeting our steering group collects proposals for new working groups. We decide which ones are ready enough for the community to discuss the proposals in the meeting. We did this last week, and I wanted to report what new meetings will be held.
There are also a number of new working groups that have had their community consideration earlier, and are being considered to be created, or were recently created. I will also mention some of these working groups.
Here are the new meetings:
The QUIC working group has just been chartered, and will meet for the first time in Seoul. This working group is taking Google’s pre-standardization QUIC protocol that has been deployed in production for several years, and will use it as a starting point to develop a UDP-based, stream-multiplexing, encrypted transport protocol with standardized congestion control, TLS 1.3 by default, a mapping for HTTP/2 semantics over QUIC, and multipath extensions. This is the IETF’s first standardized always-encrypted transport protocol, so careful consideration of applicability and operational capabilities will be key for success.
DNSBUNDLED will be having a non-WG forming BOF in Seoul. The responsible AD is Terry Manderson, with Andrew Sullivan as the IAB Shepherd. DNSBUNDLED is concerned with a problem statement of mapping and maintaining one DNS domain and all of its underlying name structure into another domain. The following related use cases have been proposed: 1) map across TLDs such as example.com to example.net; 2) map different label within a TLD, i.e example1.com to example2.com; 3) map different labels across different TLDs, for instance example1.com to eaxmple2.net, and lastly 4) where multiple domains map to one domain such as example.com, example.net, example.org all map to example.gTLD. The mailing list for this BOF is here and one of the Internet Drafts on this topic is here.
BANdwidth Aggregation for interNet Access (BANANA) will be having a non-WG forming BOF in Seoul. BANANA is concerned with providing coordinated Internet Access to a device over multiple links of different types to allow for increased bandwidth utilization, load-balancing and/or higher reliability. The goal of this BoF is to come up with a shared understanding of the problems that the IETF would like to solve in this space, complementing on and in collaboration with work ongoing in the MPTCP working group and the Broadband Forum. The group’s mailing list is here.
IPWAVE is a new working group, focusing on communications in vehicular networks. Vehicles are increasingly connected to the Internet. Comfort-enhancing entertainment applications, road safety applications using bidirectional data flows, and connected automated driving are some of the few new features expected in this area. This group will work on use-cases where IP is well-suited as a networking technology and will develop an IPv6 based solution to establish direct and secure connectivity between a vehicle and other vehicles or stationary systems.
LPWAN is a new working group that is focused on running internet protocols on a Low Power Wide Area Networks. There are several very diverse LPWA lower layer technologies such as NB-IoT, SIGFOX, LoRa, and WI-SUN. and The goal of this working group is to converge these radio technologies towards a common hour glass model, with a highly compressed form of IPv6 and CoAP between the end-device and the network gateway. This will enable the creation of common mechanisms for management of the gateway and for providing secure, Internet-based services to the applications.
L2SM is a proposed working group, currently under consideration. It is intended as a short-lived WG, tasked to create a YANG data model that describes a L2VPN service (a L2VPN service model) that can be used for communication between customers and network operators, and to provide input to automated control and configuration applications. The working group will attempt to derive a single data model that includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624.
SECEVENT is a new working group. The group works on a mechanism to convey messages between systems in order to prevent or mitigate security risks, or to provide out-of-band information as necessary.
SIDROPS is another new working group currently under consideration to be created. This group discusses operational experiences around the global deployment of RPKI, Origin Validation of BGP announcements and BGPSEC, collectively called SIDR. This technology helps protect the Internet routing infrastructure against various kinds of attacks.
Join our meeting to discuss these and many other interesting topics! If you haven’t registered yet, you can do so on the IETF-97 web page.
Today marks the execution of the contracts and arrangements relating to the IANA stewardship transition. The US government has ended their role in this matter. I am happy about the transition, and happy that it is happening as specified by the IETF and other communities. For me, the key issue is that the communities are in charge.
A large number of people have worked hard in the communities to make this day possible. Thank you for your efforts!
This is a good day — but also in many ways just like previous days. It is what we are already doing. The Internet will continue to work as it has before. The communities continue to work with the IANA system to make sure it responds to the needs of the users, as we have. Networks and people co-operate, voluntarily, so that they can connect over the Internet. Just like what the world has been doing since the dawn of the Internet.
I asked Andrew Sullivan, IAB Chair, what he thinks. He said: “Like many things on the Internet, this is the result of many incremental steps by many people. It is incremental change that brings us the stability of the Internet.”
And I also asked Alissa Cooper, Chair of the IANA stewardship transition Coordination Group (ICG). She said: “We rarely get the opportunity to witness a global consensus as broad and diverse as the one in favor of this transition. Hundreds of people and organizations from across sectors and across the world had the courage and endurance to see this process through, and as a result the Internet is running as smoothly today as it did yesterday.”
I agree with them. This is business as usual: we will continue to be a part of the IANA system, and feel responsible for ensuring that it stays healthy and responds to community needs.
Jari Arkko, IETF Chair
Photo and graphics credits: www.wordle.net and Alain Durand
Standards organisations have their areas of work, but for many topics efforts affect multiple organisations, or even span across multiple organisations. Take the IETF and the IEEE for instance, as our efforts often interact. From the IETF perspective, the most relevant IEEE standards group is the IEEE 802 LAN/MAN Standards Committee. It develops and maintains networking standards and recommended practices for local, metropolitan, and other area networks.
IETF and IEEE 802 leadership and liaison managers are in contact regularly, and every couple of years we also meet in person to better understand what work is happening on the other side, and make sure we stay coordinated. Last week, we held our fourth such meeting, continuing our tradition of meeting in outskirts of large airports in nondescript hotels this time outside Charles-de-Gaulle airport in Paris.
But the surroundings don’t matter as much as the substance. Also, both organisations are very clear that the best way to collaborate is to make sure that there are joint participants who work through topics that are important for them, in both organisations. This collaboration cannot be done through the management chain, people actually doing the standards and implementing them have to be the ones in the driver’s seat.
However, light coordination is useful to understand what things are coming down the pipeline, understand the official situation on some topic, and so on. For this purpose, we’ve defined ways of working together in RFC 7241, we’ve set up a team for the coordination, have a mailing list (https://www.ietf.org/mailman/listinfo/ieee-ietf-coord), and hold monthly conference calls and meet at the IETFs. We also have official liaisons in place, as part of inter-organisation coordination being an official activity of the IAB. If you have any topic that needs the attention of the coordination team, please contact Dan and Pat for further information.
In our meeting last week, we talked about a number of interesting topics:
Internet of Things standardisation efforts. There are many joint or connected efforts here, for instance those relating to various 802.15.4 needs, such as the IETF 6TISCH WG. It was also interesting to learn that IEEE 802 is working on a couple of projects that deal with the local administration of MAC addresses, and has developed new cabling and Ethernet standards for low-speed, low cost/energy consumption markets. One example of these projects is the 10Mbit/s specification for Ethernet over a single twisted pair cable. More information IOT-related projects at IEEE can be found here.
Both organisations are pursuing better privacy in the Internet and networks connected to it. For instance, IEEE has worked on MAC privacy, which was also tested in IETF meeting networks, and both organisations are keen on continuing with further improvements.
The essence of the IETF is not that we write specs for some other people to implement. It is that we are a place for people who write code to write specs as well. With that in mind, a big part of our work is allowing for that code writing to happen. This happens at many levels: the IETF Hackathon focuses on open source projects and Internet technology, the CodeSprint is about IETF’s own tools and web services, interoperability events test specific pieces of technology, and so on.
We will be hosting these events also at IETF-97 which will take place in Seoul, South Korea, November 12-18, 2016. More specifically:
The CodeSprint runs on Saturday, November 12, and more information is available from the wiki. You can sign up here. The CodeSprint is open to all who want to help.
The IETF Hackathon runs from Saturday, November 12 to Sunday, November 13. Read more about it here, follow the mailing list, and sign up here. The Hackathon is free to attend and open to the public.
The IETF Bits-n-Bites event, Thursday November 17, will let people demonstrate what they are working on. See more here, and sign up to sponsor a demo table! The whole IETF community in Seoul will be joining you to eat, drink, socialise, and see your demos.
And remember that what you do at these events is up to you. You decide. You decide what is the coolest tech thing that you need to implement. You decide what IETF data tracker feature you need for your work.
So don’t be afraid to add your own project, gather a team, and come join us and take your ideas further!
I would also like to offer IETF-97 as a place for various interop and test events. We typically have several at every IETF. Many people travel to the IETF anyway, so it is a convenient place to spend some time testing. Sometimes that testing is just informal, something you do in the hallways or around the terminal room table. In other cases it is more organised.
Let us know if you are planning to do some testing. In some cases we can also help with rooms, network support, and help publicise your event to other participants. In any case, testing is immensely helpful for the Internet, and we’d be happy for you to work on that!
Kicking off IETF 96 in Berlin, Germany was the weekend’s IETF Hackathon. There is growing engagement between the Open Source communities and the IETF. The IETF Hackathon had more participants than ever and we experimented with having a place for it in the IETF Lounge all week.
From the Routing Area, several projects were included: (1) ACTN (Abstraction and Control of Traffic Engineered Networks) from the TEAS Working Group, (2) PCECC (PCE as Central Controller) from the PCE Working Group, (3) I2RS RIB and L3 Topology Models from the I2RS Working Group, (4) BGP-Flowspec/BGP-LS support for Segment Routing, and (5) SFC (Service Function Chaining). The work was mostly based on using the ONOS platform. In addition, the Routing ADs held an informal Routing Open Source get-together during the week which was well attended resulting in plans for a wiki and mailing list. The mailing list is already kicked off: https://www.ietf.org/mailman/listinfo/rtg-open-source.
The work on YANG models in the Routing Area continues with much passion; the amount of detail and the fact that the models differ in the abstractions applied makes this a very time-consuming and challenging work. Of course, that’s just a sign that the benefit of having a lot of common configuration and operational data easily accessible across many vendors is high. The goal is to do it once so that operationally it doesn’t have to be done over and over and over and over again. With Benoit Claise, the Routing ADs are pushing to have a coherent set of routing YANG models done in the next year. This is based on dependencies between them, of course, and also implementations to make certain that they connect well. There have been some issues around how intended state is represented in models; expect a guiding statement on this topic soon.
LIME, in OPS, is working on a common YANG model that can apply to different OAM solutions. Concern about the number of different OAM solutions needed is behind efforts to drive common OAM protocol mechanisms as well. Between SFC standardizing NSH, BIER with its encapsulation, and NVO3 considering VXLAN-GPE, GUE, and GENEVE, it is clear that having some common OAM protocol mechanisms that can be used by all of these would be very helpful. Naturally, common OAM protocol mechanisms can exist when the different encapsulations or layers are not trying to specifically differentiate and provide unique value in that space; in these cases, the benefits are seen elsewhere than OAM but there is always a need for good OAM and thus an opportunity for reuse. Good OAM is critical for actually deploying and running the technology; cross-layer OAM can provide even better visibility into the network and the interactions.
In Dec 2015, an Overlay OAM design team had been chartered to look at what’s possible for defining OAM for the different encapsulations coming from the NVO3 (GUE, VXLAN-GPE, GENEVE), SFC (NSH) and BIER working groups. There are three basic aspects to be considered. First is providing guidance for how many bits to allocate in a header for OAM and how they should be used. Second is considering a common OAM format and data that can be reused by multiple encapsulations. Third is examining cross-layer correlations and facilitating trouble-shooting where the number and ordering of layers isn’t as fixed as traditionally assumed; layer-transcending traceroute is an example approach. At this IETF, the design team closed; it is clear that a wider and more open discussion is desirable. A wider discussion of future developments in OAM and telemetry is encouraged to happen on the now open mailing list (email@example.com). Open questions exist around progressing pieces of this OAM work separately in different WGs with solid coordination or looking towards a BoF.
A few other highlights:
The Babel Working Group met for the first time and it was filled with enthusiasm, focus, and good discussion. Juliusz Chroboczek suggested a middle ground that didn’t immediately throw away backwards compatibility but offers the freedom for necessary improvements. Most of us really enjoy technology, so seeing Dave Taht’s presentation about Babel on hacker-boards was fun. Russ White and Donald Eastlake are the Chairs.
The work on Seamless BFD was published right before the meeting — it consisted of a group of 7 RFCs across 5 WG in the Area. This is a great example of cross-WG collaboration and coordination.
Deterministic Networking (DETNET) held its third meeting as a Working Group. It was well attended, more than 100 people participated. Making good progress on their foundation documents. Beginning discussion on
selecting a data plane.
The IDR WG continues discussions about the unification of several proposals to extend Flow Spec, which has become a very valuable tool for operators to act against DDoS attacks.
One of MPLS’s Working Group Chairs, Ross Callon, announced his retirement we wish you all the best Ross! Ross attended the first and many IETFs, he’s a well-known contributor, not only in the Routing Area but many other Areas, and he was previously a Routing Area Director. The Routing Area welcomes Nic Leymann as a new Co-Chair for MPLS.
NVO3 is deciding on how to progress the three different encapsulations (VXLAN-GPE, GENEVE, and GUE) that they’ve been considering. At the face-to-face meeting, there were technical objections raised to each of
them. On the mailing list, the discussion continues. It’s a challenge when there are entrenched technologies widely deployed; we need to look ahead to see that a useful impact on the industry can still occur even if it may be a few years out. Sam Aldrin recently accepted co-Chairing this WG.
The SPRING WG also has a new co-Chair: Martin Vigoureux took over the role from John Scudder right after the meeting in Berlin.
In RTGWG, Sam Aldrin from Google presented a draft defining the gRPC protocol; the use-cases included telemetry. Benoit Claise, the Management AD, will be guiding this work.
The Traffic Engineering Architecture and Signaling (TEAS) Working Group is making progress on formalizing controller based Traffic Engineering (TE) architectures. They are also making good progress on their multi-layer, hierarchical, TE topology YANG models which can be used to support either distributed or controller based solutions as well as looking towards PCE-based architectures.
SFC continues to focus on addressing issues to finish NSH, working on security and privacy concerns (those interested more than welcome), and better defining what and how the metadata is defined and handled.
We could go on for even longer about interesting work being done in all the Routing Area, and more – but you should go look for yourselves! The IETF Meeting Materials will be updated with presentations and all of the meeting reports. The Routing Area Wiki contains high level summaries of all the Routing Area Working Groups and more information on the Routing Area activities: https://trac.tools.ietf.org/area/rtg/trac/wiki.
Alia Atlas, Deborah Brungard, Alvaro Retana (Routing Area Directors)
We had a great meeting in Berlin, the IETF crowd clearly likes to meet there! As our meeting ended, we had 1424 people participating on site and 337 people remotely. Out of the registered remote participants, 79 were from USA, 73 from India, 52 from Brazil, and 13 from Japan.
But while the numbers are interesting, what matters more is whether our gatherings have an impact on the real-life Internet out there. I certainly felt that the topics handled during the week were very significant for the Internet’s evolution. But more on that in a bit.
Not Just about the IETF
I also wanted to observe that the IETF meetings are not just about the IETF. We typically get many other meetings happening around the IETF time as well. This time we had for instance 6LO interop event with ETSI, an applied networking research workshop, an informal gathering of the operators in the IEPG meeting, interaction between the RIOT summit and our working groups, and many others.
And of course the IETF meeting itself is not just talk and specifications. We also love running code, for it is what actually makes the Internet tick
One of the ways that we can focus on running code is through the IETF Hackathon, which started with the main gathering on Saturday and Sunday, but for the first time ran through the week in the lounge and at the Bits-n-Bites event. The Hackathon had more participants than ever, 158. But again the numbers are not as interesting as what the people were doing. You could feel the buzz of excitement and ongoing hacking just by entering the room.
The winning project hacked FD.io to make it do identifier-locator based forwarding on IPv6. Another project interop tested 7 implementations of TLS1.3. This has a direct impact on how well our browsers work.
But back to our technical program during the main meeting week. With 128 different meetings, I cannot report on everything, but here are some highlights:
The QUIC (Quick UDP Internet Connections) BOF was held to consider a proposal that has originally come from Google, and is already seeing widespread usage there. The basic idea is that an efficient and secure transport can be built by applications, encompassing both TCP and TLS functionality. The new transport would run on top of UDP, and promises the ability for protecting more of the session than TCP and TLS-based designs can, absorbing multipath- and mobility functionality, and be very efficient transport for web traffic.A standard in this space would likely see significant deployment in the Internet. For me the most interesting aspect of this design is that as an application level implementation, further evolution of the design is easy and can happen in a distributed manner.The BOF was the most well-attended IETF session during the week, or possibly ever. I’m very excited to see what comes out of it!
The transport community was also otherwise very active. For instance, the L4S BOF considered proposals for improved TCP performance on latency and scalability. The area is also still working to meet the needs for managing radio networks in an encrypted world that operators told us about in the IAB MARNEW workshop last fall, and any new encrypted transport protocol will have to find some way to address those needs.
The LEDGER meeting discussed standards for interoperability between payment systems, for instance the ability to make payments across multiple payment networks or Bitcoin-like systems. This would be a new area for the IETF, and I don’t know if we’ll be working on this yet. But some of the technical challenges here related to security, naming, and routing certainly appear familiar.One of the underlying primitives that LEDGER would need is something called Crypto Conditions, an ability to specify when a condition is fulfilled, for instance when a sufficient number of parties from a group have signed something. This is another topic that I’m interested to follow.
The HOMENET working group had observed a mistake that had been made with respect to a recently published RFC, RFC 7788. This RFC accidentally refers to the “.home” special use name, but doesn’t specify its semantics in other DNS systems and didn’t go through the process normally required for special use name allocations.While this problem has been recognised and there’s an approved erratum for the RFC, I believe it is important that a more permanent fix be developed by approving a new RFC without the reference in the near future. The assignment of possible special use names for HOMENET use can take place in parallel.
The NETMOD working group and the IETF Routing Area have been steadily working on producing YANG models. There have been several NETMOD refinements to aid in this, such as improved ways to combine data models. We are now focusing on how to get the YANG models – such as topology, BGP, IS-IS, OSPF, and MPLS – to be completed in the next year. Implementation experience on these is very welcome!
The LPWAN meeting discussed how to run IPv6 and higher layer Internet protocols such as CoAP on highly constrained low power wide area networks (LPWANs). The energy and packet size constraints on these networks require highly innovative solutions to just be able to run IP in these networks. Participants representing four of the major LPWAN technologies were present in the meeting and showed high levels of interest in both participating in as well as utilizing the output from this effort.
The recently-chartered SIPBRANDY working group met for the first time this week. The group is describing best practices for cryptographic protection of SIP-signaled real-time media. It hopes to solve keying issues that have so far prevented wide deployment of the Secure Realtime Protocol (SRTP).
Open source is a big part of our efforts. Some of the events beyond the IETF Hackathon included the first meeting of the BABEL working group, focused on a new routing protocol from the open source world, and a gathering of the open source developers from the routing area.
IETF Financing and Sponsors
I would very much like to thank Juniper Networks for hosting this successful meeting in Berlin. Juniper is one of our IETF Global Hosts, companies who are committed to supporting several meetings across 10 years.
I was also happy to hear that the IETF Endowment received over 3 million dollars from our friends at AfriNIC, ARIN, RIPE NCC, and ISOC. This is a major show of support for the IETF mission, and much, much appreciated. Thank you all.
I should also note that it is important that we evolve the IETF funding model. We’re very meeting focused in our funding that with regards to meeting fees from the participants and sponsor support. Re-balancing that to both meetings and other IETF’s work is important. The IETF Endowment is one step in this direction. For your information, ISOC will be holding an information and discussion session on the endowment on September 9, 2016 at 1400 UTC.
Finally, what’s next? Back to work, of course, on the mailing lists, virtual meetings, and design teams. Our next physical meeting is in Seoul, South Korea.
A brief version of this article exists also as a video:
Jari Arkko, IETF Chair
The author would like to acknowledge the help of Alia Atlas, Spencer Dawkins, Deborah Brungard, Stephen Farrell, Joe Hildebrand, Ari Keränen, Alissa Cooper, Suresh Krishnan, Ben Campbell and others in understanding what happened at IETF96 and writing this article
“There’s a huge problem with the Internet of Things and we need to do something about it.” That was the invitation that brought participants to the Internet of Things Software Update Workshop (IoTSU) held at Trinity College, Dublin on June 13 and 14.
The “huge problem” with many IoT devices is that they are un-patchable, and if they cannot be patched, they cannot be made secure. The IoT is on a growth path that is quickly leading to the ubiquitous deployment of unattended devices throughout our homes, offices, factories, and public spaces. All of them, by definition, are connected to the Internet and hackers will eventually discover and exploit the vulnerabilities in these devices. When that happens, there must be a way to detect the intrusion and deploy software updates to fix the security flaws. This is a hard problem to solve and it has the attention of the IoT industry as well as that of the Internet Architecture Board (IAB) and the Science Foundation Ireland-funded CONNECT Centre who sponsored this workshop.
The workshop materials and raw minutes are here. An IAB report will be published in the near future.
The participants at the IoTSU workshop submitted nearly 30 papers on topics covering analysis of past incidents, current practices, and proposals for future standards. The organizers classified the papers and the participants discussed them during four sessions across two days. The following summarizes just a few topics from the workshop that I felt were particularly significant.
Problem Scope and Technical Constraints: IoT devices are deployed on a range of hardware platforms, many of which are more highly constrained than others. At one end of the spectrum are the “System-On-Chip” devices with full memory management units (MMUs) running embedded Linux and full time access to mains power and a permanent Wi-Fi connection. At the other end of the spectrum are tiny “motes” connected via Low-Power and Lossy networks and required to run for years on battery power or harvest their own energy. The biggest software update challenges are with these highly constrained devices considering that all updates must be done securely and with zero risk of bricking the device. It seemed that most of the participants felt the greatest need was to first address the challenges at the lower end of this spectrum.
Photo: Hannes Tschofenig
IoT as a Service: When I buy a product, I have a certain set of expectations regarding ownership, control, and life expectancy for that product. An IoT device, however, is not a standalone product; it is highly dependent on the services it receives over the Internet and all of the technical, organizational, and policy infrastructure that underpin those services. Many of the IoT devices on the market are being sold today as products, and consumers are not always aware of the services those devices depend upon for their long term continued operation. Developers and vendors need to keep this perspective in mind when designing and marketing the IoT.
Full Lifecycle Requirements:
To properly address the challenges of the IoT software update problem, it is essential to consider the full lifecycle of the IoT device. This begins during manufacturing when the security credentials must be generated, allocated, and provisioned into the devices in a secure manner. It also incorporates the lifecycle of the device vendor who might be bought out or go bankrupt – we need to consider how to continue patching essential devices when the original manufacturer no longer exists. Finally, it ends with addressing various end-of-life scenarios such as how to decommission and recycle those devices that no longer can or should be supported.
The workshop concluded with a discussion about next steps. For starters, the organizers will publish an official workshop report. The participants also supported the concept of publishing a document to capture the current best practices in the IoT industry relative to software update. Some also brought up the need to clarify the scope of the workshop activities in terms of whether the focus should be on constrained devices or to also include other platforms or even networks of connected devices such as those found in vehicles. There may also be the opportunity for future standards work such as recommendations for certain minimum hardware requirements to address the need for random number generation, real time clock, and memory to support multiple binary images during an upgrade.
The participants at the IoTSU workshop came together because of their common concern about issues that could potentially threaten the long term success of the IoT. It was a good mix of representatives from both industry and academia who willingly and openly shared their experience and expertise. I believe the workshop was a good first step towards working together to address the common challenges that we are facing as the IoT continues to grow.
When the idea of participating in this hackathon came about, the goal was mostly to leverage FD.io’s Vector Packet Processor (VPP) as a platform and show its performance, capabilities, modularity and development simplicity. So we looked across existing IETF technologies and drafts which were not yet implemented in VPP and found out this new ILA technology (draft-herbert-nvo3-ila), which seemed to be a perfectly valid use-case for VPP used as a physical or virtual router.
What’s really fantastic is that the ILA draft author, Tom Herbert, as well as other very motivated people spontaneously volunteered to join the team. We ended up with a team consisting of folks in-between IETF standardization and Linux Foundation open-source software, and developed together from scratch, a full ILA implementation. In two days we went across many phases of standard implementation development, from understanding the draft, coding the first shot, testing it, to finally understanding the technology better and doing more with less code. Then testing again, and interoperating with an existing Linux implementation.
At the end of the second day of the hackathon, the newly created implementation, comprising most of the features specified in the ILA draft, was upstreamed to the main VPP repository. And performance tests of the yet-to-be-optimized code were showing promising results too.
Summarizing, this two-days project really showed how the IETF hackathon can facilitate joint collaboration between open-source and standardization people at very early stages of drafts and implementation development, taking advantage of their complementing experience and knowledge and resulting in better standards and optimized running code.
Pierre Pfister and Maciek Konstantynowicz
The ILA team was: Pierre Pfister, Tom Herbert, Maciek Konstantynowicz, Damjan Marion, Shwetha Bhandari, Bill Cerveny, Ignas Bagdonas, Ole Troan, Wolfgang Beck
I arrived in Berlin today, but there are many volunteers and support vendors who arrived days earlier to prepare for the meeting. It takes a lot of effort to setup the network, for instance. The team reports that the network is up and running, and that they have taken over the hotel network as well.
Some minor routing issues with some destinations were seen earlier on v6, but the team is fixing that. Everything should be running smoothly, but if not, please drop us a note.
We all are grateful for having this team work for us! Thank you!
Interestingly, at this IETF we’re for the first time implementing the BCP-38 (ingress filtering) policy on our routers; Jim Martin and Warren Kumari wrote a script to automate that setup. I talked to Jim a bit about the arrangements, and thought it was a good demonstration of how some good things in the Internet are fundamentally hard, and require some effort. There is no “apply BCP-38” button on most routers But maybe there should be?
The team has also deployed a monitoring mechanism to follow what’s going on in the network. You can see it on the left in the picture below, whereas on the right you see some nice art
I was also positively surprised by the amount of activity already going on in the hotel in other efforts, such as the MAMI network measurement project meeting, ETSI interop, the Cryptec meeting, and probably many things that I didn’t know about. One of the purposes of the IETF meeting is to be a place for all kinds of hallway conversations, testing, and other discussions to take place, alongside with the actual working group meetings.
For the weekend, I’d like to highlight the following activities:
IETF Hackathon: Come build your favourite new tech! The Hackathon runs mainly during Saturday and Sunday, but we’ve also reserved some space in the IETF lounge throughout the week of IETF to help and encourage people to continue to collaborate with their colleagues on various hackathon projects and activities. This is not meant to compete with sessions but rather to provide an opportunity for those without packed agendas to make better use of their otherwise free time. We will see how things go in Berlin, and we welcome your thoughts and suggestions on improving the Hackathon at any time. More information about the Hackathon can be found on the web, and more about the week-long Hackathon experiment here.
IETF Code Sprint is running on Saturday, please join and program the IETF tools that you need. See the Code Sprint web page for sign-up and other information.
Applied Networking Research Workshop (ANRW) runs on Saturday, and focuses on interesting research results. Join the workshop, details
at the workshop page.
Tutorials run on Sunday, and include both newcomer’s orientation to the IETF and discussion of new work in IEEE 802. The orientation is available both in English and German. See the agenda for the sessions.
For next week, the meeting rooms are ready. This is the plenary room: