-
Notifications
You must be signed in to change notification settings - Fork 46
Meeting Minutes: February 1, 2018
10 am to 11:30 am, VMware, 3425 Hillview Avenue, Palo Alto CA 94304
AT&T - Kenneth Duel, Shyam Parekh
Barefoot Networks - Jeongkeun Lee, Mickey Spiegel, Arkady Shapiro
Dell - Raja Jayakumar, Senthil Ganesan
Ixia - Chris Sommers
Marvell - Gidi Navon, Tal Mizrahi, Vitaly Vovnoboy
Netcope - Albert Ross
Netone - Yuki
Netronome - Bapi Vinnakota
Netsia - Madhu Kashyap
Surfnet - Ronald Vanderpol
UFRGS - Jonatas Marques
VMware - Mukesh Hira
No slides were presented at this meeting. The discussion focused on closing on the following open issues -
Using a single “Remaining Hop Count” field decremented at each INT hop would free up 8 bits in the INT header for future use. Meeting participants agreed with the change, no concerns were raised.
Action item: JK Lee/Mickey Spiegel to post a pull request with relevant changes to the spec.
In the event that an INT source is running a newer version than a particular INT transit hop, the transit hop may receive certain bits set that are “reserved” as per the INT version that it is running. The spec does not describe handling of such a situation. We went over the proposed edits, attendees agreed with the proposed edits.
Current version of the dataplane specification touches very briefly on handling of packet size growth with INT, and impact on MTU configuration. Mukesh Hira presented modifications to the specification to elaborate on this.
The proposal is to recommend configuration of a MTU differential between links preceding the INT source and links between INT source and sink. Optionally, instead of requiring a hard MTU differential, INT switches may aid in dynamic path MTU discovery by sending ICMP unreachable / ICMPv6 Packet too big message to the source.
A new “MTU exceeded” bit is added to the INT header to indicate that one or more INT hops did not append INT metadata to the packet because doing so would have caused the packet to exceed egress link MTU (obviously with a single bit only an indication of the event occurring at one or more hops can be encoded, which exact hops the event occurred at, or how many hops the event occurred at cannot be encoded).
The proposal also suggested that the switch at which “MTU exceeded” event occurred sends a report to the monitoring engine if it does not implement the optional feature of sending ICMP message back to the source. This would simplify identification of the switch(es) at which MTU settings need to be examined. However, this was deemed to be too heavy. The group agreed to require the bare minimum, i.e. setting the M bit in the header, leaving it up to the network operator to troubleshoot MTU settings if the monitoring engine receives INT reports with M bit set.
The group also agreed that requiring INT switches to fragment packets (with clear DF bit in Pv4 header) in order to be able to add INT metadata would be too heavy.
Action item: Mukesh to amend his pull request based on the discussion.
Certain metadata reported by INT switches, such as Timestamp and Queue occupancy may have different units at different hops. For example, some switches may report timestamp in nanoseconds, while others report in microseconds. Some switches may report queue occupancy in bytes while others may report in number of cells. Cell size in bytes may also vary from one switch to another.
The group agreed that the monitoring system needs a mechanism to identify the units being reported by each switch, but this would be an out-of-band mechanism. To start with, the INT spec should call out the metadata for which units need to be queried/reported out-of-band. The group can subsequently consider defining an API/query/report for this.
Action item: Mukesh/JK to edit the INT spec calling out the metadata requiring an out-of-band query for identifying unit used.
Mickey Spiegel has proposed edits to the report format specification, modifying the report formats as per his presentation at the previous meeting. His slides from the previous meeting are here. Pull request with the proposed edits is here.
- Please post comments/concerns on open issues or pull requests. We will incorporate comments over the next week, and merge the pull requests on Friday Feb 9 if no significant concerns are brought up.
- Next bi-weekly meeting will be on Thursday Feb 15, 2018, 10 am to 11:30 am. Meeting location and agenda will be announced over the meeting list closer to the meeting date.