Monthly Archives: May 2017

IESG Retreat

Montreal skyline.

Montreal skyline. Photo by Taxiarchos228 CC BY 3.0

The IESG held its annual retreat last week, meeting one day jointly with the IAB and two days on our own in Montreal, Canada. With several new members joining us as of the last IETF meeting, it was a good opportunity for everyone to spend more intensive time discussing hot topics and getting to know one another.

We focused a significant amount of our time together discussing the interaction between increased use of encryption, information available to observers on the network path, and existing operational practices. This has been a frequent topic of conversation in a variety of venues in the IETF as of late, including the MaRNEW workshop, numerous BoFs, charter and document discussions in the QUIC, TLS, OPSAWG, SAAG, and RTCWEB working groups, and on the IETF discussion list.

We examined the topic from a variety of angles. With the IAB we talked about the relative merits of signaling information explicitly versus implicitly, whether replacing implicit signals (about, say, path resources) with explicit signals could be viewed as an architecturally sound design approach, and what the real-world impacts of such a shift might be. We followed that up with discussion amongst IESG members about how to recognize proposals early on in the IETF process that could carry with them significant implications for current approaches to network manageability. As a next step we agreed amongst ourselves to flag such proposals for each other during our bi-weekly informal telechats to increase the likelihood of early cross-area review. Finally, we debated an approach being taken in the security community towards encryption of “all the things” — not things as in IoT, but things as in everything, including identity information, IP-level routing information, operations on data at rest, and a number of other “things” for which the robust application of encryption is still in nascent stages. The discussion teased out differences in perspective about the notion of which entities on the network might be perceived as trusted, or be perceived as attackers, under different network scenarios (e.g., enterprise versus consumer). I can’t say that we ended up with consensus on the topic as a whole, but we did garner greater appreciation of each others’ perspectives, and individual ADs are likely to funnel our conversation into broader community discussions.

IESG at work.

IESG at work.

We also spent some time considering ideas to help spur further interaction between standards development in the IETF, development of running code, and open source efforts in the industry. In particular, we talked about ways to allow for working groups to iterate more quickly on YANG models, both from a tooling and a process perspective. We also had Charles Eckel and John Brzozowski join us remotely to brainstorm about future improvements to the IETF Hackathon and Bits-n-Bites events to support more opportunities for participants to collaborate on implementations and showcase works-in-progress. We don’t have concrete details to share on either of these fronts just yet, but we hope to have updates in the near future.

It wouldn’t have been an IESG retreat without some of our more typical housekeeping discussions. This year we touched on a number of IANA-related issues, discussed RFC sub-series, guidance concerning BoFs and side meetings, IETF communications, the future trajectory for remote participation, a suggestion to have more shorter WG meeting slots, and a variety of other issues. All in all, the retreat was a good opportunity for IESG members to gain insights into how we’re each approaching challenges and opportunities big and small in the IETF, and how we can collaborate for the benefit of the IETF community.

Alissa Cooper
IETF Chair

Routing Area Update after IETF 98

Overhead photo of the Circle Interchange in Chicago. Photo by Stratosphere. <a href="">(CC BY-SA 4.0)</a>

Overhead photo of the Circle Interchange in Chicago. Photo by Stratosphere. (CC BY-SA 4.0)

As Routing Area Directors, we have now made it a habit to share some of our thoughts after each IETF meeting.  This is a short summary of some of the highlights from the recent one in Chicago.

YANG continues to be a focus in routing and the IETF as a whole.  While in Chicago, many working groups had YANG models in their agenda and even specific sessions to review and move the work forward, as was the case for the joint meeting of the mpls, ccamp, pce and teas WGs.  The importance of some of this work is reflected in a recent IETF Journal article: Working Group Update: Microwave Modelling at CCAMP.

The netmod WG is making progress with the Network Management Datastore Architecture (NMDA) that will allow access to system-derived state (think of new interfaces learned by inserting a line-card) and cleaner access to operational state versus configuration by having explicit operational and intended datastores.  Knowing this future direction allows us to recommend how affected YANG models can be finalized in RFCs.

Along with the Operations and Management (OPS) ADs, we will be sending out precise guidance (thanks to lots of work from the NetMod DataStore Design Team and the Routing YANG Architecture Design Team) that should allow most YANG models to be completed and implemented without delay.  To summarize, the models should include all configuration and state in a single normative module to be NMDA-ready.  When needed, it should have an optional state module that provides access to the state not otherwise accessible until NMDA and the associated protocol work is implemented.  Of course, there are rarely one-size-fits-all rules and this guidance is no different; the exceptions will need to be individually discussed.

During the Routing Area Open Meeting we were lucky to hear from the two Applied Networking Research Prize (ANRP) winners for IETF 98.  Both presentations focused on BGP, one on a framework to analyze live and historical data (BGPStream), and the other on accelerating the deployment of BGP origin and path validation.  Both talks resulted in interesting conversations with the audience and continued interaction throughout the meeting and beyond.

In the period before IETF 98 the spring WG has accelerated the work on several of the key documents that will open the way for the segment routing-related extensions defined throughout the area, including use cases and the Segment Routing Architecture document. The chairs opened the discussion about which topics should be the subject of an updated charter for this WG.

The sidr WG is also close to finishing its charter – just a couple of documents remain.  While it didn’t meet in Chicago, the participants met as part of the new sidrops WG (in the OPS area).  This transition from the development of solutions (origin and path validation in this case) to the understanding that implementation and deployment should now take center stage is critical to this work, but also to the routing area in general.   Another good example of the same trend is the trill WG, which is also finishing up the currently chartered work; additional work based on strong operational needs may still be considered.

It is very important for the WGs in the area to keep a close eye on operational requirements, experience and feedback.  Besides sidrops, other WGs also deal specifically with the operations of routing-related technology, including grow and mboned.

One of the topics for discussion in rtgwg was “Routing in the DC”, which has several proposals on how to make routing in the data center more efficient, scalable and flexible.  This session served as a review of some of the proposals and the opportunity to listen to operators express their needs in response.  We look forward to a continued and tighter participation from the operations community.

The detnet WG is making good progress on their Deterministic Networking use cases, architecture, and selecting a data plane.  The DetNet Data Plane Design Team gave an update on their work and proposed their DetNet Data Plane solution document is ready for adoption.

The bier WG has made excellent progress with a unified encapsulation that will work for MPLS and Ethernet.  The WG took an important step forward in deciding to continue with the WGLC and eventual publication of their work as Experimental RFCs, instead of waiting for deployment experience and pursuing the Standards Track.  The decision was aided by the existing ability to do RFC Status Changes without impact to the IANA registries or even the RFC number.

The babel WG had a good discussion on adding unicast hellos to the protocol; several implementers have use-cases that need them.  The WG remains small but active with focused technical discussions and an emphasis on experimenting with ideas via implementations before agreeing on changes.

NVO3 discussed the recommendation of its Design Team to select an updated Geneve as the standards-track encapsulation.  The consensus is being verified on the mailing list.  For the second IETF meeting, nvo3 experimented with meeting twice and having small group discussions on data-plane, control-plane, and security.  The WG could use more folks interested in discussing security extensions and use-cases.

While we would like to walk through every WG in the area, this summary is meant to be just that, a summary.  If you want more information, please take a look at the IETF 98 Routing Area Working Group High-Level Summary that the WG Chairs put together.  Just a few more work items that are worth listing here:

  • The lisp wg is making progress with the transition of their core experimental documents, RFC 6830 and RFC 6833, to the Standards Track.
  • The teas wg has been refining the ACTN (Abstraction and Control of TE Networks) Framework and Requirements
  • The Stateful PCE work continues in the pce WG with the imminent publication of the PCEP Extensions for Stateful PCE

IPv6 is not optional – the need to specify, implement and deploy IPv6 is well understood by everyone.  During the Routing Area meeting we made a call for the WGs to consider the deployment of IPv6-only networks, and the transition to them from IPv4-only and dual-stack implementations.  The intent is to consciously find and fill any specification gaps as vendors and operators clearly work towards that goal.

As Area Directors, our interests go beyond the technical work and into, for example, the topics of outreach and remote participation.  To that effect, we are working on efforts to better characterize and eventually measure the participation at remote hubs, from new people to the IETF all the way to established contributors.  Also, we are currently involved in other IESG-wide topics including side meetings, BoFs and the application of the Note Well.  We welcome any comments or ideas about these topics or others that you think the IESG should be addressing.

Finally, the IETF meeting in Chicago marked the start of Deborah and Alvaro’s second term as Area Directors.  We are very happy to be able to continue to work together.

Alia, Alvaro, Deborah (Routing Area Directors)

Looking Ahead, Facing Change

About a month ago I officially took on the role of IETF Chair. My predecessor Jari Arkko noted upon beginning his term as chair just how much can change from one chair’s term to the next. As I’ve started settling into my new role over these last weeks, I’ve been thinking a lot about what has been changing and what has been staying the same in the IETF.

Past and present IETF Chairs with IETF Senior Meeting Planner Marcia Beaulieu. From left, Fred Baker, Jari Arkko, Alissa Cooper, Marcia Beaulieu, Russ Housley, and Harald Alvestrand.

Past and present IETF Chairs with IETF Senior Meeting Planner Marcia Beaulieu. From left, Fred Baker, Jari Arkko, Alissa Cooper, Marcia Beaulieu, Russ Housley, and Harald Alvestrand.

When I first started participating in the IETF, it didn’t take long for me to realize the importance of the IETF as a venue for creating the building blocks of the internet. The significance of the IETF derives from the combination of what we choose to work on and how we carry out that work. Producing core standardized protocols wouldn’t have nearly the same impact on the internet as the existing body of IETF work if it were done behind closed doors, if a single constituency could dictate the outcome, or if broad interoperability were not the main objective. To my eye, the core principles of the IETF process – open participation, cross-area review, and consensus – contribute to the success of IETF protocols in tandem with the design choices and technical trade-offs inherent in protocol design.

Of course, those process features are also often cited as drawbacks of IETF participation. “The IETF moves too slowly,” some people say. “They’re not adaptable,” “they can’t compete with open source,” “the biggest players aren’t interested in consensus.” Sound familiar? Sure, it’s true more often than not that if you’re trying to find agreement among a large, heterogeneous pool of people, that will require a different investment of work and time than deciding things among you and your close group of friends, or hacking something together all on your own. The challenge I see for the IETF in the coming years is to preserve the benefits of the essence of the IETF model while adapting to changes in the industry and the environment. With collaborative styles of engagement flourishing across both open source and standards development, there is a lot of opportunity for synergy.

How can we do a better job of integrating our work with open source development efforts? How can we evolve our tools and processes to align with how software is being developed and deployed today? How might we apply the model of cross-area review and consensus more broadly than to static text specifications? How can we evolve the administration of the IETF to give the community more flexibility and room to experiment? I have my own thoughts about these questions, but far more important are the ideas and efforts of the IETF community.

Personally I think we have many reasons to be optimistic about tackling these questions, based on recent IETF standards development work as well as ongoing community conversations and activities. Over the last several years we’ve seen protocol development efforts deeply intertwined with and informed by running code, with the concurrent development of 10 or more independent implementations, for instance in the case of HTTP/2 and TLS 1.3. We’ve seen broad interest across the industry in the kind of security expertise that has become a hallmark of the IETF, and resulting security and privacy improvements being developed for web, email, DNS, DHCP, real-time, and other kinds of traffic. We’ve seen tremendous energy behind the specification of YANG data models and their integration across the industry into standards processes. And community discussion and activity continues to grow around the IETF Hackathons, use of Github, remote participation, and IASA 2.0.

I’m excited to work with the community on how we face the changes around us while retaining the core of what makes the IETF most effective. We have lots of existing venues for discussions of specific aspects of this, but of course you can always send me your thoughts or post them to the IETF discussion list.