Dear Authors,
I have read draft-lapukhov-dataplane-probe-1, and I have some comments. https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01 I believe that in-band telemetry is certainly a very interesting method, and the community can value from working on this draft. Major comments: * The draft seems to be related to the P4 In-band Network Telemetry spec (http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf). However, the two documents define different packet formats and different metadata fields. Do you plan to align the two documents? * The draft should probably include a background section that describes the environment. It should explain which entity adds the INT header, and which entity is supposed to receive the probe information and analyze it. It should also explain whether INT is applied to all data traffic, to a subset of the data traffic, or to probe traffic (or all of the above). * Since the telemetry header is modified at every hop, there should be some discussion about how this affects the L4 checksum of the overlay header when using protocols such as VXLAN, Geneve, or GUE. * The draft should include a "Security Considerations" section. It should discuss potential threats and vulnerabilities imposed by adding INT to the network. Other comments: * The abstract and introduction may need some rephrasing. For example, there should probably be more text about OAM protocols. Ping and Traceroute (which are currently mentioned in the draft) are tools that are used manually by network operators, but there is a vast number of OAM protocols that are used for automated proactive telemetry (fault detection, loss and delay measurement). * The INT spec is currently missing from the reference list: http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf * Section 2.1 says "This document does not prescribe any specific encapsulation for the data-plane probe." On the other hand, Figure 2 defines the <Probe Marker> fields, which appear to be encapsulation-specific. Moreover, the length of these fields is encapsulation-specific, right? Please consider removing the Probe Marker fields from this draft. * Section 3.2: "residence time is in 48-bits of nanoseconds" - please note that the IEEE 1588 standard uses a 64-bit format to represent the correctionField (residence time). It is recommended to use the same format here. * Section 3.3: the difference between the queueing delay and the residence time is (roughly) constant for a given switch. It would be worthwhile to explain why both are needed. * Section 3.5: the word 'analyzer' is mentioned here for the first time without being defined beforehand. * s/needs to made/needs to be made/ * Section 4: o "Swap the destination/source IP addresses in the transport header to send the packet back to the originator." - again, there is a slight conflict with section 2.1, which argues for encapsulation-independence. Moreover, swapping the IP addresses is typically not enough (L2 addresses, L4 ports...). o On the returning path - are devices expected to update the <Hop Count> field? o Since <Hop Count> is equal to zero, doesn't the analyzer loose the information about the number of hops until the loopback device? * Section 5.1: "Probe Id" is mentioned for the first time here without prior explanation, so the paragraph is not clear. * Section 6: router alert - again, a conflict with encapsulation independence... Regards, Tal Mizrahi.
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
