-
Notifications
You must be signed in to change notification settings - Fork 46
Meeting minutes: January 18, 2018
10 am to 11:30 am, Barefoot Networks, 4750 Patrick Henry Dr, Santa Clara, CA 95054
Alibaba - Heidi Ou
AT&T - Kenneth Duel, Steven Monetti, Shyam Parekh, Tzuu-yi Wang
Barefoot Networks - Jeongkeun Lee, Mickey Spiegel, Prem Jonnalogadda, Arkadiy Shapiro, Robert Soule
Bell Canada - Daniel Berner
Cisco - Benoit Claise, James Coole, Mario Baldi, Rajesh Sharma
Dell - Anoop Ghanwani
Netcope - Albert Ross, Petr Kastovsky
Netronome - Bapi Vinnakota
POSTECH - Jonghwan Hyun
VMware - Mukesh Hira
INT and Report format specifications as of the meeting date on January 18, 2018 were declared as version 0.5. Next revision will be v1.0, encompassing changes under discussion in the working group. Details regarding this versioning may be found here.
Mickey Spiegel from Barefoot Networks presented revisions to telemetry report format, based on discussions during the previous working group meeting. Slides can be found here.
The revised format uses an extensible bitmap to indicate network state information included in the report. There was some discussion on whether the report format should allow for a fixed-length metadata stack as this may be suitable for some switch architectures. Working group participants are encouraged to bring to the group's attention if this is an issue with their specific switch architectures.
Another comment was to investigate whether the telemetry report formats may be aligned with IPFIX report formats, allowing existing IPFIX collectors to adapt easily for processing INT telemetry report. It was felt that this goal may be achieved by writing a translator that translates telemetry report formats to formats tailored towards legacy IPFIX collectors.
Current INT spec presents two approaches to indicate presence of INT metadata in native TCP/UDP traffic - one approach uses a reserved bit/value in IPv4 DSCP or IPv6 traffic class field, another approach uses a reserved TCP/UDP destination port number. Neither approach is ideal, using a reserved TCP/UDP destination port number can result in the traffic taking a different ECMP path compared to the actual application being monitored. Using IPv4 DSCP bits should work in a large number of use-cases, except when all 64 values of DSCP bits are used for indicating QoS.
Two alternate approaches were presented to indicate presence of INT metadata following Layer 4 TCP/UDP headers.
Rajesh Sharma from Cisco Systems presented use of IP Header options field to indicate presence of telemetry metadata following L4 headers, please see slides here for details. Main concerns with this approach are (i) Getting an IP option number assigned by IANA (ii) Ensuring all legacy switches that do not implement this new option can be configured with IP options bypass, so as to not punt packets with this this option to the slow path.
Heidi Ou from Alibaba presented use of a 64-bit probe marker following Layer 4 header, to indicate presence of INT metadata. Heidi's slides may be accessed here.
The 64-bit magic value may be made configurable per deployment. This approach was implemented by an ASIC vendor based on an IETF draft (now expired), and used by Alibaba in their initial testing. This is a good approach. The only concern is that in the rare event that the magic value collides with real application data for an application flow at the same location in the packet, INT transit hops would end up mishandling such traffic and potentially cause the application to break.
- Please provide feedback regarding the proposed approaches for indicating presence of INT metadata in unencapsulated TCP/UDP traffic over the mailing list so the working group can make some decisions on the approaches to support in v1.0.
- The working group will meet again on Feb 1, 2018, 10 am to 11:30 am. Meeting location and agenda will be announced over the mailing list as always.