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 (firstname.lastname@example.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.