Skip to main content
  • The new GREEN working group gets ready for an energy efficient Internet

    The Getting Ready for Energy-Efficient Networking (GREEN) working group will explore use cases, derive requirements, and provide solutions to optimize energy efficiency across the Internet.

    29 Oct 2024
  • IETF Annual Report 2023

    The IETF Annual Report 2023 provides a summary of Internet Engineering Task Force (IETF), Internet Architecture Board (IAB), Internet Research Task Force (IRTF), and RFC Editor community activities from last year.

    25 Oct 2024
  • IETF 122 Bangkok registration open

    Registration is now available for the IETF 122 Bangkok meeting scheduled for 15-21 March 2025, which is the first time registration for an IETF meeting has been open before the preceding meeting registration has closed.

    25 Oct 2024
  • First Impressions from the IAB AI-CONTROL workshop

    The Internet Architecture Board (IAB) organized a workshop on 19-20 September 2024 to discuss issues around and possibilities for practical mechanisms that publishers of data on the Internet could employ to opt out of use by the Large Language Models and other machine learning techniques used for Artificial Intelligence (AI).

    24 Oct 2024
  • New Participant activities at the IETF: Major expansion coming for IETF 122!

    The IETF New Participants program has a long history of helping people just starting out in the IETF be more effective. Based on feedback from program participants over the past two years, and in consultation with the Internet Engineering Steering Group (IESG), the program will be significantly enhanced starting with IETF 122 Bangkok.

    22 Oct 2024

Filter by topic and date

Filter by topic and date

Routing Area Directors’ Thoughts on IETF-96

3 Aug 2016

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.

IETF 96 fan

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 (rtg-ooam-dt@ietf.org). 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.


Share this page