Skip to content

Meeting minutes: Feb 7, 2019

JK Lee edited this page Feb 10, 2019 · 5 revisions

Meeting Time and Location

10 am to 11:30 am PDT (GMT - 8), Barefoot Networks, 4750 Patrick Henry Dr, Santa Clara, CA 95054

Attendees

Barefoot Networks: JK Lee, Mickey Spiegel, Roberto Mari

Cisco Systems: Ramesh Sivakolundu

Interoperability challenges

Dataplane telemetry poses interoperability challenges in two areas:

  1. interop between reporting switches and report collectors, needed regardless of INT vs postcard
  2. interop between switches, needed for INT

The group agreed that the community/industry has spent too much efforts on the 2nd issue; and also agree that postcard is a good approach that simplifies the problem. Postcard needs to worry only about the 1st issue, which the WG is addressing with the YANG model.

One missing piece that the WG is not handling today is configuration. Postcard requires a big role of configuration since all the switches in the forwarding path should be configured to generate postcard reports in a consistent way so that the collector can reconcile the e2e path information. Ramesh proposed to cover the configuration aspect in the YANG model, Mickey pointed out that OCP SAI is the main forum today where telemetry configuration is being discussed. We decided to review the current SAI proposals first and decide the P4 Apps WG approach in the next meeting.

Scoping and renaming

There was a suggestion to rename postcard as 'INT hop-by-hop', since postcard provides the same information as INT while postcard generates reports from every hop (as opposed to generating reports only from INT sink devices), but this causes a conflict with the existing INT hop-by-hop type that collects INT metadata from every hop.

The group quickly realized the need to broaden out the scope of INT. INT was first introduced in P4.org (in 2015) as a dataplane technology that collects per-pkt telemetry information in data packets. Today, thanks to the success of INT, many people in the industry use INT as a more generic term to indicate various dataplane-oriented telemetry mechanisms. I.e., we observe the term INT is widely used as a synonym for 'dataplane telemetry'. (One participant in the meeting also called out 'INT domain' in the context of network-wide configuration for postcard.)

The P4 Apps WG has produced two specs and one model so far:

  • INT spec
  • Telemetry Report spec: generic mechanism for INT sink reports, postcards, drop reports, congestion reports
  • Yang model for telemetry metadata expressions and semantics used in the two specs

JK pointed out that the Telemetry Report spec can be conceived also as 'in-band' telemetry (or in-network telemetry) since it is about generating telemetry reports directly from dataplane for per-pkt event. In that sense, the Telemetry Report spec can be renamed to something like 'INT-Report' spec, INT-R in short. A question for the group is whether to keep the INT definition as it is of today -- 'In-band Network Telemetry' -- or should we change it to a broader definition such as 'In-Network Telemetry'. We will resume the discussion in the next meeting.

Next Steps

  • JK Lee will cut INT v1.1 from the current master.
  • Tentatively a longer meeting on Thursday February 28, 2019 to finalize the scope/term for INT, decide the WG approach for telemetry configuration, and to discuss details of Yang model.