Subject: [OPSAWG] Comments about draft-lapukhov-dataplane-probe

From: Tal Mizrahi <[email-masked]>
Date: Sun, 3 Jul 2016 08:08:39 +0000

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.

---

From: Petr Lapukhov <[email-masked]>
Date: Sun, 3 Jul 2016 15:51:15 +0000

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. 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-masked]>
Sent: Sunday, July 3, 2016 1:08:39 AM
To: Petr Lapukhov; Remy Chang ([email-masked]); [email-masked]
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dlapukhov-2Ddataplane-2Dprobe-2D01&d=CwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=LU_vJaM_EQu1Ssm35j2xlA&m=-l5C93wGQ6ihQjbi8uBNUsLhEYMjTq-LXCIzXLtm-mo&s=qXbHStmVxJkXIUwHatb3eeN0P2CgyZYNH_m0UsrjhoU&e=>

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__p4.org_wp-2Dcontent_uploads_fixed_INT_INT-2Dcurrent-2Dspec.pdf&d=CwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=LU_vJaM_EQu1Ssm35j2xlA&m=-l5C93wGQ6ihQjbi8uBNUsLhEYMjTq-LXCIzXLtm-mo&s=a-jIuzLofcRj1-7RvS9_clSIFCgkBV-Cv5fShtR-MyE&e=>). However, the two documents define different packet formats and different metadata fields. Do you plan to align the two documents?

Other comments:

*         The INT spec is currently missing from the reference list: http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__p4.org_wp-2Dcontent_uploads_fixed_INT_INT-2Dcurrent-2Dspec.pdf&d=CwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=LU_vJaM_EQu1Ssm35j2xlA&m=-l5C93wGQ6ihQjbi8uBNUsLhEYMjTq-LXCIzXLtm-mo&s=a-jIuzLofcRj1-7RvS9_clSIFCgkBV-Cv5fShtR-MyE&e=>

*         Section 4:

Regards,
Tal Mizrahi.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 3 Jul 2016 18:19:37 -0400

On Sun, Jul 3, 2016 at 11:51 AM, Petr Lapukhov <[email-masked]> 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
>
> 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-masked]
> 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