-
Notifications
You must be signed in to change notification settings - Fork 46
Meeting Minutes: December 4, 2017
1:30 to 3 pm, Barefoot Networks, 4750 Patrick Henry Dr, Santa Clara, CA 95054
Barefoot Networks: Jeongkeun Lee, Changhoon Kim, Mickey Spiegel
Cisco Systems: Andy Fingerhut
Dell: Raja Jayakumar, Senthil Ganesan, Anoop Ghanwani
Netcope: Albert Ross, Petr Kastovsky
ONF: Carmelo Cascone
Technion: Itzik Ashken
VMware: Mukesh Hira
Slide deck from the meeting can be found here
Jeongkeun Lee continued with presentation of Telemetry dataplane specification, configuration model, and feedback gathered so far on the dataplane specification.
It was agreed to increase the width of version field to 4 bits. “Replication” and “Copy” bits would be retained, moved to a different position to make room for more version bits.
The INT role of a network element is typically a function of the location of the element in the network topology. Elements in the network core serve as INT transit hops. Elements at the edge of the network function as (i) INT source for a “watchlist” of traffic flows received from the workloads and/or (ii) INT sink for all traffic carrying INT headers received from the core of the network. However, some use-cases may require INT sink role to be configurable, i.e. a network element may add INT headers on some traffic whereas it strips the INT stack and serves as a sink for other traffic.
This is outside the scope of the dataplane specification, but a GitHub issue will be created for this to discuss the relevant use-cases and an appropriate approach to address the use-cases.
The dataplane specification currently assumes that the monitored traffic is received at the INT sink which creates INT reports sent to a set of collectors. For packets that are dropped and never reach the INT sink, it would be useful for the transit hop that drops a packet to create INT reports. The dataplane specification will be modified to address this.
It was also discussed that packet drops that occur before the forwarding pipeline stage that parses and acts on INT headers, may not be reported. This is a chip architecture and implementation specific matter, and outside the scope of the specification. The dataplane specification will allow a transit hop to generate INT reports based on events such as packet drops. Specific P4 targets may or may not be able to achieve this for all types of packet drops.
As transit INT devices expand the size of data packets by adding INT metadata to the packets, end hosts have to be able to discover path MTU accounting for INT. This aspect is not well addressed in the current specification. A desirable way of handling this would be for a INT transit hop at which packet size after adding INT metadata exceeds outgoing link MTU, to send an ICMP Destination Unreachable message with code = “fragmentation needed and DF set”, allowing end hosts to discover the right path MTU with INT being performed in the network. The specification will be modified to address the path MTU aspect.
Differentiating between physical and logical port IDs in INT metadata Certain use-cases would require reporting of logical port IDs (e.g. tunnel ID), while certain use-cases may require reporting of both logical and physical port IDs. A GitHub issue will be created to address this aspect.
- Telemetry dataplane specification and report format draft specification will be moved to p4lang/p4-applications repository in .mdk format.
- Communication over the mailing list and GitHub will continue. We will skip the working group meeting in second half of December as many people may be taking time off for the holidays.
- Next working group meeting will be held in the first week of January 2018. We shall discuss any issues around the dataplane specification, and move on to a presentation on telemetry report formats.