-
Notifications
You must be signed in to change notification settings - Fork 46
Meeting minutes November 13, 2017
Room 202, Packard Electrical Engineering Building, Stanford University
Alibaba: Jianwen Pi
AT&T Tom Tofigh, Shyam Parekh
Barefoot Networks: Changhoon Kim, Jeongkeun Lee
Cisco Systems: Andy Fingerhut, Rajesh Sharma, Mario Baldi, Matthew Massey, Andy Keep
Dell: Raja Jayakumar, Senthil Ganesan
IXIA Communications: Chris Sommers
Mellanox: Alan Lo
Netcope Technologies: Albert Ross
ONF: Brian O'Connor
Postech: Jonghwan Hyun
VMware: Mukesh Hira
Xilinx: Gordon Brebner
Slide deck from the meeting can be found here
Mukesh Hira presented the working group charter and processes.
Question: While Telemetry is the initial area of focus for the working group, what is the plan for addressing other applications.
Response: Network Telemetry has a very high level of interest in the community, most of the meeting attendees expressed interest in Telemetry during the round of introductions. While Network Telemetry will be the initial application that the working group will focus on, group members interested in other applications who are ready to present their applications and use-cases are encouraged to send an email to the co-chairs. We will allocate brief presentation slots in subsequent meetings, and based on the level of interest in the community, will consider incorporating these applications into the working group's charter. We anticipate incorporating applications such as Connection Load Balancing, Source Routing, etc. into the working group's charter over time.
It was agreed that specifications should include human language specifications as well as relevant P4 expressions. It was decided that specifications should be posted in a raw format such as .md, allowing people to track history and diffs.
Initial focus would be to develop version 1.0 specifications and open source reference code for Network Telemetry. Subsequently, there were suggestions to do quarterly or six-monthly releases.
Jeongkeun Lee presented the current In-band Network Telemetry (INT) Dataplane specification that can be found here
There was discussion around whether it would be useful for the dataplane to write state to a local memory location, compared to assuming that the only use case is to send reports to a set of collectors.
There was discussion around whether there could be use-cases for sending certain network state information to the application (out of band, not in the data packets), in addition to sending reports to collectors.
There was discussion around whether the INT source should be able to encode collector information in the packets as compared to collector information configured out-of-band at the INT sink. The motivation was for the INT source to select a collector on a per-flow basis. A strong use-case was not clear as collectors would typically form a cluster, and INT sinks could shard network state reporting across the cluster by hashing a flow to a specific collector, or by using a sharding mechanism. This would be an implementation matter.
It was brought up that the dataplane specification assumes that INT packets reach the sink. The specification needs to account for packet drops due to congestion, port/link failures, routing issues, etc and allow the switch dropping packets to deliver reports even though it is not an INT sink.
There was discussion around whether INT source, sink roles should be configurable at run-time? The specification considers INT source, sink role to be defined by network topology (network edge devices typically function as INT sources and sinks). This may be useful for NFV use-cases where the INT domain stretches over a chain of virtual network functions that may grow and shrink dynamically.
The dataplane specification uses IP header DSCP bits to signal presence of INT headers following L4 payload. There was discussion that using a specific value of DSCP may not work well since one may want to trace packets with multiple code points being forwarded through different queues in a switch. It may be better to use a specific DSCP bit to indicate INT while the remaining bits may be used to map traffic to an output queue. There was general agreement that using DSCP for signaling presence of INT information is reasonable as there is no mandated standard for how DSCP bits are to be used, these are typically defined autonomously by network architects/administrators. The possibility of using IP header for INT was raised. However, it was clarified that the specification did not use IP headers for two main reasons - (i) Most legacy devices will punt any traffic with IP options to the slow path (ii) The length of IPv4 header without options is 20 bytes, and maximum length is 60 bytes, allowing for only 40 bytes of INT information that can be accommodated in the IPv4 header.
We shall continue with the INT dataplane specification, followed by INT report format specification that can be found here. It was suggested that it may be useful to cover control plane configuration aspects as well at the next meeting.
In terms of a meeting cadence, it was agreed that meeting once every two weeks would be good, with a pause mid-December to early January for the holidays. Some attendees offered to host the meeting at their organization. The working group meeting will be rotated over a few locations in the bay area. A Doodle poll will be sent out for picking a meeting time and location for the next meeting in the week of November 27.