-
Notifications
You must be signed in to change notification settings - Fork 45
Meeting minutes: Mar 21, 2019
NOTE @ June 25th: the INT nomenclature captured below was a draft, different from the final version. We keep this draft version and meeting notes for the record. The final version will be shared in the mailing list.
March 21, 2019 10:00 am to 11:30 am PDT (GMT - 8), Barefoot Networks, 4750 Patrick Henry Dr, Santa Clara, CA 95054
Barefoot Networks: JK Lee, Mickey Spiegel
Cisco Systems: Ramesh Sivakolundu
VMware : Mukesh Hira
We mostly discussed folding in various forms of dataplane telemetry under the INT umbrella. The major observation is that today the term INT is used by many people to indicate various dataplane telemetry technologies. For example, in the context of configuring postcard watchlist at every hop device, the working group was using the term 'INT domain'. We concluded that it makes sense to embrace the broad definition and multiple variations discussed in the industry.
Here is the new nomenclature discussed by the group.
- INT - In-Network Telemetry, as an umbrella technology
- INT - Direct: Telemetry Data sent directly to the collector from each node – Triggered by Watch List - INT-D
- INT - Inband : Telemetry Instructions in the actual packet – INT-I
- INT - Inband Stack : Packet contains instructions as well as per hop metadata stacked over the path - INT-IS
- INT - Inband Direct : Packet contains instructions, per hop metadata is sent directly to the collector from each node - INT-ID
- INT - Clone: Telemetry Instructions in a cloned packet. Telemetry data is also collected in the clone – INT-C
To categorize the variations and come up with the new nomenclature, we look at two dimensions of dataplane telemetry:
- Where to program telemetry instructions? This can be programed in the data packet by the source node, or configured as a match table on each network node. A third option is cloning a packet and program the instruction on the cloned copy.
- Which device sends a telemetry report to a collector? The telemetry data can be stacked in the packet and sent by designated devices such as INT Sink or the device that drops the packet. Or the data can be directly sent from each hop device to the collector instead being stacked in the packet.
| where to program instructions? \ who sends reports? | only sink | every hop |
|---|---|---|
| every hop watchlist | N/A | INT-D |
| in the actual packet (INT-I) | INT-IS | INT-ID |
| in a cloned packet | INT-C | N/A |
- Collect feedback and finalized on the namings
- The naming changes will be incorporated into INT 2.0
- Domain specific extensions also to be finalized for INT 2.0
- No specific need from the community for INT 1.x, next version will be 2.0
- Plan is for Barefoot and Cisco (Mickey and Ramesh) to open pull requests with above changes (pull request for domain specific extensions already exists), review at the next meeting on 4/11. We shall aim for finalizing these changes by the following meeting (4/25) and tag 2.0 before the P4 workshop on May 1.