On Sun, Jul 3, 2016 at 11:51 AM, Petr Lapukhov <[email protected]> wrote: > Tal, thanks for the feedback! I will likely to take a stab at this next > week, though I think we are in lock-down before IETF already.
Nope, you still have a few days: 2016-07-08 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. (This is more for anyone procrastinating -- you still have time to update yer documents...) W > Not a big > worry though, I'm not making it to Berlin, but was planning on South Korea. > > > I'm looking to simplify it even further. Remy might comment on merging with > INT - I think the latter was coming from collaboration from VMware. > > > Petr > > ________________________________ > From: Tal Mizrahi <[email protected]> > Sent: Sunday, July 3, 2016 1:08:39 AM > To: Petr Lapukhov; Remy Chang ([email protected]); [email protected] > Subject: Comments about draft-lapukhov-dataplane-probe > > > 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 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
