A recent Internet Draft noted the growing Free and Open Source Software movement as a trend that the IETF, as a community, can participate in by helping open source and open standards work together. As the draft states, “Open source and open standards have a natural and symbiotic relationship, and implementing open standards through open source projects strengthens the standards and the community at large.” IETF Hackathons, begun just last year, tangibly address this and promote the connection between open source and open standards by providing a focal point for developing open source implementations of standards developed in the IETF.
As a first measure of success, participation in the three IETF Hackathons held last year exceeded expectations and drew in contributors that weren’t already participating directly in the IETF itself. Perhaps even more importantly, work at IETF Hackathons has identified issues with standards still under development by IETF working groups, providing invaluable information about what worked and what didn’t work in real operating network environments. IETF Hackathons are not only an example of the “running code” that has been a touchstone of the IETF since the beginning, but they have also helped improve the standards as they are developed.
Therefore I’m very pleased that Huawei will be sponsoring the IETF Hackathon events associated with each IETF meeting throughout 2016. The first 2016 IETF Hackathon will be held just ahead of IETF 95 in Buenos Aires starting on Saturday April 1st. There are already more than 90 individuals registered for the event to tackle topics such as DNS (including DNSSEC and DANE), NETVC, TLS, and NETCONF/YANG.
And remember: it’s not too late to sign up to participate! Many Hackathon participants also attend and participate in the IETF meeting, but IETF attendance is not required, and participation in the Hackathon is free.
Of course, we’re also looking forward to the other IETF Hackathons for the rest of the year, in Berlin in July and in Seoul in November. I encourage you to share information about the IETF Hackathons to anyone you know who might be interested in helping to bring together open Internet standards and open source. I am looking forward to seeing everyone in Buenos Aires.
Barry Leiba, Huawei (also, an Applications and Real-Time Area Director at the IETF)
This morning I arrived in Buenos Aires, where volunteers and staff have been busy preparing for our 95th IETF meeting. It looks like everything is ready, the network is up and the hotel facilities look great.
I wanted to make a couple of observations. First, many volunteers arrive early to an IETF meeting to help make the meeting network work and the meeting a success. Thank you!
Secondly, I think we are being treated to a dose of real networking experiences around the world. The IETF network is as good as networks come anywhere, but we are far away. What does it feel like when you favourite data centre is no longer 10ms away? Big parts of the world are in that situation and have less intercontinental connectivity than we do in Europe or North America. It might be helpful for us to remember that and figure out if there are ways for us to improve our technologies to accommodate those situations even better than they do today.
In terms of travel, the immigration process at the Ezeiza airport seemed quick, queuing included well under ten minutes for me. The taxi ride from the airport to the city took an hour, given some traffic in the city end, and cost 500 Pesos. The city is sunny today, temperature now 23 degrees and rising. My luggage was left somewhere in Europe, but hey, as long as the network is up and there’ll be a t-shirt in this IETF, I should be fine 🙂
Looking forward to seeing you all soon here in person soon!
Or, if you have been unable to travel to the meeting, we would like to hear from you during the meeting, remotely. If you plan to participate remotely, please register and choose “Remote Participant” as your Registration Type. The remote participation facilities are listed here.
Jari Arkko, IETF Chair
The IETF is about interoperation. Yes, IETF participants like cleaner architecture, and more elegant solutions, and so on. But at bottom, both “rough consensus” and “running code” are all about making diverse things work together as much as possible. We need to make the pieces line up.
One of the places that things — or, in this case, “Things” — need to line up is in the application layer. For the Internet of Things (IoT) to become the reality many popular accounts would suggest, the various kinds of Things need to be able to talk to one another, and not only at the lowest levels. The promise of the Internet of Things is that the lights and the thermostat and the garage door can all collaborate to make your house more comfortable. Land use and transportation could be more efficient if cars and parking spaces — or people needing a ride — could find one another. Electrical supply and demand could be matched better if the different electrical appliances could talk to each other reliably to smooth consumption. And the whole system is likely to be better overall if each part works together no matter who made each device — just the way the Internet has grown and succeeded.
About a year ago, Dave Thaler and Hannes Tschofenig talked, at the IETF Technical Plenary, about architectural issues in the Internet of Things. A key theme there was the duplication and gratuitous difference arising from many organizations independently defining data models or schemas for each type of IoT device. For example, there were already many different definitions of what a light bulb was!
Facing this issue brought many people together — including but not only those who participate in the IETF, W3C, OMA, AllSeen Alliance, OCF, NIST, CableLabs, ZigBee, and ETSI. We convened at the IOTSI workshop in the Ericsson offices in Santa Clara, California. For two days, we tried to work out ways to improve semantic interoperability. How can diverse systems interoperate? Are better standards in information models or data models needed? Is a single framework necessary, or is some sort of mapping possible? What can you do when frameworks are formally incompatible? And what do we do about end to end security when intermediate security models are incompatible?
The really uplifting news from the workshop is that people from many different sectors of the industry all agree there is a serious problem to be solved. Some groups had already started developing common solutions for some things. But the level of information sharing across the group was quite encouraging. This is how interoperation works best: not by trying to impose a single model, but by people with different interests all recognizing a common problem.
There are security implications from all this, too. If different frameworks have radically different security models, then getting end to end security may be nearly impossible — especially if a translator is needed. In the presence of translators, data privacy will also be a problem. We recognized the challenge before us.
Of course, recognition is just a first step. We still need to get from that recognition to making Things work well together, at every layer. The workshop, and its results, will come in a workshop report — appearing soon in an Internet-Draft repository near you. But more important than the report are the follow-on activities. We agreed to start with a wiki to provide pointers to schema repositories as a first concrete step, with further developments to follow. We — in the IETF, in other SDOs, and in industry — have an opportunity to make interoperability in the Internet of Things the positive force that earlier Internet innovations were. Interoperation is what we do, so let’s do it again.
Dave Thaler, Member of the IAB, and Andrew Sullivan, Chair of the IAB
It’s almost time to pack our bags and head south to Argentina. This is the IETF’s first ever meeting in Latin America!
Buenos Aires sits in front of the majestic (220km wide!) Río de la Plata and the metropolitan area is home to approximately 15 million people (the second largest in South America). There is much to experience in a city known as the birthplace of the Tango: music, arts, theater, and even Avenida 9 de Julio, the widest avenue in the world — all sights and sounds to take in
Let’s not forget we’re making the trip to work! Yes, in between dulce de leche and Argentina’s famous asado the IETF has a full agenda to continue our mission of making the Internet work better. As always, our week starts on Saturday with the Code Sprint and the Hackathon, both great reminders of the importance of running code. The rest of the week is full of activities, including a significant number of BoFs and new research groups.
The IETF has been meeting for 30 years. It makes me very proud that a Latin American city was chosen as the site for IETF 95. Even though several current active participants are from the region, the opportunity to increase the participation and contribution has not been missed. To that end, LACNOG, with very strong support from the Internet Society and LACNIC, have been working tirelessly for the last 3 years to encourage the participation from people in the region in IETF processes and discussions (ietf-lac). The community of people aware, interested and actively participating has grown significantly through this effort.
One of the important effects of the evangelization work has been the proliferation of remote participation. Through the creation of remote hubs, run by local volunteers in universities and corporate sites, the attendance from Latin America has grown more than 10 times. This effect has now expanded and we now expect significant remote attendance not only from growth regions, but even from parts of the world where IETF participation is well established, the US for example. The meeting wiki will be collecting information about the remote hubs as they are confirmed.
Buenos Aires and its people are proud, open and welcoming. A wonderful representative of Latin America. Even though I was born more than 5500 km from the meeting site (hint: not in Argentina), I always feel at home in Buenos Aires. I am looking forward to all of us having a great meeting!
Alvaro Retana, Routing Area Director
Just before the IETF 95 in Buenos Aires, let’s analyze the current state of affairs in the YANG Data Models world.
As anticipated by the IESG some time ago (and for which the IESG reorganized itself), the YANG data models trend continue, with about 200 YANG data models in the IETF drafts now, on top of the already published ones.
This trend is also observed in different Standard Development Organization such as the BBF (Broadband Forum), the Metro Ethernet Forum (MEF), the Institute of Electrical and Electronics Engineers (IEEE), without forgetting the opensource projects OpenDaylight and Open Config.
In January, ETSI NFV organized an Information Modelling Workshop, which brought together participants from 3GPP, ATIS, Broadband Forum, DMTF, ETSI NFV, IETF, ITU-T SG15, MEF, OASIS/TOSCA, Open Cloud Connect, ONF, OpenDaylight, OPNFV and TM-Forum. The goal was to collaborate on the information model and data model in this SDN and NFV world. I participated as OPS AD, stressing the importance of data models and of YANG as THE data modeling language. Presentations can be downloaded here.
The YANG Model Coordination Group has been spending time on the inventory of those YANG models in the industry, the tooling aspects, the help with the compilation, the training & education (NETCONF, YANG, pyang), the coordination across SDOs/opensource, the model coordination with the IETF. On the tooling front, the YANG model extraction and compilation is now integrated in the IETF draft submission tool, thanks to Henrik Levkowetz. So no more excuses for producing YANG models that don’t compile.
The industry demands open YANG data models right now. Indeed, YANG data models is the basis for the data-model driven management which allows automation. So with so many YANG data models in IETF drafts right now, why does it take so long to publish the final RFCs? Let me expand on two reasons.
The first reason is that the NETMOD and NETCONF community has been busy with some key deliverables lately.
– YANG 1.1: Based on the development and implementation experience of some of the YANG models, the YANG version 1.1 is now being finalized. This new version is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.
– RESTCONF: HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF, and two companion documents: the YANG Patch Media Type and the YANG Module Library
– YANG Metadata: The definition of a YANG extension statement that allows for defining metadata annotations in YANG modules.
– NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively.
Now that those major deliverables are in their final stages, the NETMOD and NETCONF WG resources will be free to tackle the next challenge.
The second reason is the coordination of all these models. While all models are doing a great job of defining how a particular feature can be configured or monitored, they need to interact with each others. The end goal is to automate the creation of services (like the L3VPN service data model effort, which is almost complete), in a physical or virtual environment. If you consider the coordination of all the YANG data models within the IETF difficult, think twice, as the coordination is actually required for an entire industry. Before publishing the 200 YANG data models, we need to solve two important issues, which will influence the design of all standard data models:
- How to consistently model the operation status? NETMOD already collected the operational state requirements and now works on the solution space.
- How to structure all those models? As a practical example, how do we model the logical and virtual resource representations that may be present on a network device, such as Virtual Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs). Should all YANG data models contain a logical network element container, just in case a router supports a VRF or VSI? On that front, the NETMOD WG is currently working on “mount” solution, a mechanism to combine YANG modules into the schema defined in other YANG modules. This mechanism would allow a simplification of the device model, particularly for “lower-end” devices which are unlikely to support multiple network instances or logical network elements.
Once those two issues are resolved, this will for sure open the gate to publish all these much-needed models.
I’m not only a strong believer in data modeling driven management, but a strong believer in standard data models. The standard aspect, based on the consensus based approach, requires some time, but this is the price to pay for standard-based automation.
Benoit Claise, OPS Area Director
Many of us have been working over the last two years on a small change to the way the IANA functions are managed. Today, IANA is operated by the Internet Corporation for Assigned Names and Numbers (ICANN) under a contract from the US Department of Commerce (though the National Telecommunications and Information Administration, or NTIA). But the plan has always been for the NTIA to step out of that role, and about two years ago they asked the Internet community to put together the detailed proposal for how to complete the plan.
We have now passed an important milestone. The various operational communities — for names, numbers, and protocol parameters — have come together and produced a unified proposal under which IANA stewardship can be performed by the Internet community. The proposal keeps in place the same operational realities that have supported the Internet’s enormous growth since the 1990s. The arrangements are really the same ones that have always been in place: they work, and there is no reason to change them. The NTIA has the proposal, and is now following the procedure to evaluate it.
The proposal is yet another piece of evidence that the multi-stakeholder way works. We’re not done yet, of course, but we are very happy that the next phase of the transition process has begun.
Andrew Sullivan, IAB Chair
My previous blog post was about the IETF BoFs, but there are also new meetings in the research arm of the IETF, the IRTF. The proposed Measurement and Analysis for Protocols (MAPRG) research group is meeting for the first time in Buenos Aires. Another proposed research group, the Network Machine Learning (NMLRG) is also meeting in Buenos Aires, and this is their second meeting.
This is what the planned charter says about the role of the MAPRG:
Our Internet has grown into something that differs from what was envisioned. Its protocols sometimes operate in an environment other than than that for which they were designed. For instance, some network elements treat some protocols differently than others and those protocols themselves are sometimes reused and abused in ways initially unforeseen. The Measurement and Analysis for Protocols (MAP) Research Group (RG) explores such phenomena by measurement with the aim to inform protocol engineering and practice.
Many protocol engineering efforts in a standards development context, as well as best practices for the operation of IETF-defined protocols, can benefit from insight provided by Internet measurements of various kinds. Likewise, Internet measurement research efforts can stand to gain from contacts with the IETF. The Measurement and Analysis for Protocol Engineering (MAP) Research Group aims to provide a forum for interchange between these two communities.
And this is what the NMLRG plans to do:
Machine learning technologies can learn from historical data, and make predictions or decisions, rather than following strictly static program instructions. They can dynamically adapt to a changing situation and enhance their own intelligence with by learning from new data. This approach has been successful in image analysis, pattern recognition, language recognition, conversation simulation, and many other applications. It can learn and complete complicated tasks. It also has potential in the network technology area. It can be used to intelligently learn the various environments of networks and react to dynamic situations better than a fixed algorithm. When it becomes mature, it would be greatly accelerate the development of autonomic networking.
The Network Machine Learning Research Group (NMLRG) provides a forum for researchers to explore the potential of machine learning technologies for networks. In particular, the NMLRG will work on potential approaches that apply machine learning technologies in network control, network management, and supplying network data for upper-layer applications.
I think these are very exciting topics! Hopefully you all can join the meetings of these groups! The MAP RG is currently scheduled for Monday 15:50-17:20, but schedules may still change. The NMLRG is currently scheduled for Thursday 10:00-12:30. Registration for the meeting is open at the IETF meeting page. It is also possible to follow and participate the meeting remotely.
Jari Arkko, IETF Chair
With the preliminary agenda just published (or soon will be), I wanted to report what Birds-of-Feather (BoF) sessions there will be at IETF-95. This time there is quite a lot of work following up on a recent IAB workshop on the effect of encryption on network operators.
The BoF sessions are one way for IETF to adopt new work, typically discussing a problem or a need for new standards. The IESG has approved these sessions for the meeting.
SPINOFFS FROM THE MARNEW WORKSHOP
These topics are results of the MARNEW workshop held in September 2015 (minutes) to determine what could be done to help operators perform network management, even when the traffic carried in their networks is becoming increasingly encrypted.
Limited Use of Remote Keys (LURK). Communication protocols like IPsec, SSH or TLS provide means to authenticate the remote peer. Authentication is based on the proof of ownership of a private key. Today, the deployment of services on the current Internet largely relies on multiple distributed instances of a service and CDNs. Can a service be offloaded to a CDN without giving the CDN also a complete control of a private key?
Alternatives to Content Classification for Operator Resource Deployment (ACCORD). This proposal focuses on the ability of radio-based mobile access networks to perform some traffic classification for the purposes of managing radio resources efficiently, without exposing any privacy sensitive information. The increased use of TLS and other encrypted transports makes these types of classification attempts more difficult. This proposal suggests that it would be useful to examine both what specific network treatments need to be elicited for the efficient operation of radio access networks, if any, and what the minimal communication to elicit those treatments for encrypted traffic would be.
IAOC Meeting Venue Selection Criteria & Procedures (MTGVENUE) – the community has expressed a concern regarding the process followed when selecting a meeting venue. The IAOC and IAOC Meetings Committee have undertaken to document that process (currently in preparation) in an internet draft for community discussion. The IAOC would like to discuss it with the community. The draft will be posted soon.
NETWORK PLUMBING FOR THINGS, VEHICLES, AND HOMES
Intelligent Transportation Systems (ITS) – the goal is to standardize and/or profile IP protocols for establishing direct and secure connectivity between moving networks. A draft charter for the potential new working group has been suggested here.
Low-Power Wide Area Networks (LPWAN) – this proposal deals with long range low-power and lossy networks, many of which operating in license-exempt bands. Existing pilot deployments show promise, but the loose coupling with the Internet makes the device management and network operation complex and specific. As of today, there is little to no use of IETF technologies in LPWANs at large, and there is a need to evaluate their applicability.
Babel routing protocol (BABEL) – this distance vector routing protocol has been described in detail in RFCs 6126 and 7557, which are both Experimental. The goal of this proposed BoF is to discuss whether it is necessary to create a standards track successor these RFCs, including discussing what technical topics need attention as part of advancement.
Alternative Resolution Contexts for Internet Naming (ARCING). While the most common Internet names by far are those which are part of the domain name system, that set of names is not the whole. There are also independent naming and resolution contexts, such as onion routing or multicast DNS, Handles, and proprietary names such Twitter handles. This creates some ambiguities, and the proponents of this effort believe that the IETF should describe the architectural issue and document best practices for identifying alternative resolution contexts.
Jari Arkko, IETF Chair
Image credits by Wordle
Some time ago I mentioned the Internet of Things Semantic Interoperability (IOTSI) workshop organised by the IAB. This workshop is important for the work on application data formats, semantic definitions, and interoperability in the Internet of Things space. Can we ensure that this work gets completed and aligned across the industry?
I wanted to provide a small update, as the paper submission deadline has closed. The workshop proved very popular, with over 50 high-quality submissions from a diverse set of organisations and covering many different angles into the topic.
The accepted papers are available from the workshop page. Do read them, as they provide many interesting thoughts on where various standards organisations are on this topic and what problems remain.
Jari Arkko, IETF Chair
Image credits by Wordle
This blog post is not about technology. A while ago I asked for volunteers to help us understand some of the non-technical changes around the IETF. Some of these changes may affect how we should run our operations: changing participation, changing forms of co-operation, changing landscapes in the area of standards organisations, open source, and so on.
My goal was to set up a design team. This effort was inspired by involvement in various decisions that the IETF leadership has to take part in. I find myself often wishing to be able to draw more on the understanding trends and their impact on the IETF.
Alia Atlas, Avri Doria, Tobias Gondrom, Olaf Kolkman, Steve Olshansky, Benson Schliesser, Robert Sparks, Russ White joined the team (thank you!) and the first result from the team is now available as an Internet Draft.
You can read the full draft here, but I have copied some words from the abstract below:
While most of the work in the IETF is technical, the IETF should and does regularly examine itself, including its processes and goals, to determine if the technical community is truly serving the larger network engineering community effectively. Changes in this area tend to be incremental, as is fitting for an organization with decades of experience and history in developing and managing the process of building technical specifications.
The rapid and ongoing changes in the world have recently caused a number of IETF participants to examine the current processes and operation of the IETF, particularly in the context of the culture of the IETF. This memo discusses some cultural and global trends in relation to the IETF’s operating environment, how these trends might affect the operation of the IETF, and notes some topics for further exploration.
This memo is also input for discussion that the IETF community should have.
The memo has no particular official standing, nor does it claim to represent more than the authors’ thinking at the time of writing.
But our opinion is just that — our opinion. What do you all in the IETF community think about this? What changes do you foresee? Please direct discussion about this topic to the email@example.com mailing list.
As a side note, if you are interested in the picture, it is of an IESG meeting in 2010, held in Second Life. The setup was pioneered by Lisa Dusseault. And at least for me, the experience far surpassed phone conferences, at least as good as today’s high-quality Internet conference calls can be. The IETF also had its own island in Second Life. Where can we take the IESG or the IETF in 2016?
Jari Arkko, IETF Chair