Subject: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

From: Tommy Pauly <[email-masked]>
Date: Thu, 14 May 2020 10:16:15 -0700

Hi IPPM,

At our virtual interim meeting, we decided to put draft-ietf-ippm-ioam-data through a second last call, based on the new revisions, in mid-May. This email starts a two-week WGLC for this draft.

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-09

This last call will end on Thursday, May 28. Please reply to [email-masked] with your reviews and comments.

Thanks,
Tommy & Ian

---

From: <[email-masked]>
Date: Fri, 15 May 2020 15:51:00 +0800 (CST)

Hi all,

I have a comment on this draft.

I was told by the implementers of my company that it's difficult to add accurate transit delay into the trace option data. The reason is that in order to calculate transit delay, the node firstly needs to obtain the time at which the packet is transmitted by the node, which is obtained at PHY layer, otherwise, the node can't do any calculation after the time is obtained.

If the above issue is common across different implementations, I suggest to substitute the "transit delay" with '"timestamp" of the time at which the packet is transmitted by the node.

Best Regards,

Xiao Min

原始邮件

发件人：TommyPauly <tpauly=[email-masked]>
收件人：IETF IPPM WG <[email-masked]>;
日 期 ：2020年05月15日 01:16
主 题 ：[ippm] Second WGLC for draft-ietf-ippm-ioam-data

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

Hi IPPM,

Thanks,

Tommy & Ian

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 25 May 2020 14:57:34 -0700

Dear Authors,
thank you for carefully and thoughtfully addressing my earlier comments,
much appreciated. I've found the document ready with single lonely nit that
is clearly non-blocking:

   - [I-D.lapukhov-dataplane-probe] is listed in the Informative References
   section but not used in the text.

Regards,
Greg

On Thu, May 14, 2020 at 10:16 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hi IPPM,
>
> At our virtual interim meeting, we decided to
> put draft-ietf-ippm-ioam-data through a second last call, based on the new
> revisions, in mid-May. This email starts a two-week WGLC for this draft.
>
> The latest version can be found here:
> https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-09
>
> This last call will end on *Thursday, May 28*. Please reply to
> [email-masked] with your reviews and comments.
>
> Thanks,
> Tommy & Ian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 28 May 2020 13:08:19 +0000

Hi Greg,

Thanks a lot for your comments and reviewing the latest version. Much appreciated.
We’ll make sure that the informative reference to I-D.lapukhov-dataplane-probe is removed in the next rev.

Cheers, Frank

From: ippm <[email-masked]> On Behalf Of Greg Mirsky
Sent: Montag, 25. Mai 2020 23:58
To: Tommy Pauly <tpauly=[email-masked]>
Cc: IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Dear Authors,
thank you for carefully and thoughtfully addressing my earlier comments, much appreciated. I've found the document ready with single lonely nit that is clearly non-blocking:

  *   [I-D.lapukhov-dataplane-probe] is listed in the Informative References section but not used in the text.

Regards,
Greg

On Thu, May 14, 2020 at 10:16 AM Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>> wrote:
Hi IPPM,

This last call will end on Thursday, May 28. Please reply to [email-masked]<mailto:[email-masked]> with your reviews and comments.

Thanks,
Tommy & Ian
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 28 May 2020 09:43:01 -0700

Our WGLC call for draft-ietf-ippm-ioam-data is now concluded! Thanks everyone.

I’ve marked the document as having WG consensus, and needing a revised I-D (to incorporate Martin’s comments). Once that is ready and we have the shepherd write-up, we’ll submit this to the IESG.

As a reminder, we are still in the WGLC for draft-ietf-ippm-stamp-option-tlv. Please review and comment if you have not already!

Thanks,
Tommy

> On May 14, 2020, at 10:16 AM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hi IPPM,
> 
> The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-09 <https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-09>
> 
> This last call will end on Thursday, May 28. Please reply to [email-masked] <mailto:[email-masked]> with your reviews and comments.
> 
> Thanks,
> Tommy & Ian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 29 May 2020 08:04:48 +0000

Hi Xiao Min,

my understanding is that there are devices which can calculate transit delay, which is why the field was introduced quite a while ago.
draft-ietf-ippm-ioam-data already includes an option to timestamp packets (see e.g. sections 4.4.2 and 4.6 in draft-ietf-ippm-ioam-data-09) which you can use exactly the same way as you propose below, i.e. you can use the timestamp field for the time, at which the packet was transmitted by the node. What draft-ietf-ippm-ioam-data asks you to do is to properly document when you timestamp the packet.

Cheers, Frank

From: ippm <[email-masked]> On Behalf Of [email-masked]
Sent: Freitag, 15. Mai 2020 09:51
To: [email-masked]; tpauly=[email-masked]
Subject: Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Hi all,

Best Regards,

Xiao Min
原始邮件
发件人：TommyPauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>
收件人：IETF IPPM WG <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年05月15日 01:16
主 题 ：[ippm] Second WGLC for draft-ietf-ippm-ioam-data
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

Hi IPPM,

Thanks,
Tommy & Ian

---

From: <[email-masked]>
Date: Fri, 29 May 2020 16:59:51 +0800 (CST)

Hi Frank,

Many thanks for your reply to my comment.

Please see my inline response with <XM>.

Best Regards,

Xiao Min

原始邮件

发件人：FrankBrockners(fbrockne) <[email-masked]>
收件人：肖敏10093570;[email-masked] <[email-masked]>;tpauly=[email-masked] <tpauly=[email-masked]>;
日 期 ：2020年05月29日 16:05
主 题 ：RE: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Hi Xiao Min,

<XM> OK, I see, then it's very reasonable to reserve this field of transit delay.

draft-ietf-ippm-ioam-data already includes an option to timestamp packets (see e.g. sections 4.4.2 and 4.6 in draft-ietf-ippm-ioam-data-09) which you can use exactly the same way as you propose below, i.e. you can use the timestamp field
 for the time, at which the packet was transmitted by the node. What draft-ietf-ippm-ioam-data asks you to do is to properly document when you timestamp the packet.

<XM> My suggestion might not be clear enough. Actually I want to have two timestamps carried in the hop-by-hop trace option data, one timestamp for the receiving time and another timestamp for the transmitting time, then after the IOAM Data is exported to the collecter, the collecter can use the two timestamps to calculate the transit delay of each IOAM transit node. Do you see it possible to add one more timestamp as IOAM node data field into section 4.4.2?

Cheers, Frank

 

Hi all,

I was told by the implementers of my company that it's difficult to add accurate transit delay into the trace option data. The reason is that in order to calculate transit delay, the node firstly
 needs to obtain the time at which the packet is transmitted by the node, which is obtained at PHY layer, otherwise, the node can't do any calculation after the time is obtained.

Best Regards,

Xiao Min

原始邮件

日期：2020年05月15日
 01:16

主题：[ippm] Second WGLC for draft-ietf-ippm-ioam-data

Hi IPPM,

 

 

This last call will end on Thursday, May 28. Please reply [email-masked] with your reviews and comments.

Thanks,

Tommy & Ian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 29 May 2020 11:00:04 +0000

Hi Xiao Min,

There have been quite a few proposals for additional data fields for IOAM tracing, see e.g. https://github.com/inband-oam/ietf/issues/154
What we agreed in the past IPPM meetings was that we’d focus on finalizing draft-ietf-ippm-ioam-data so that we have a stable foundation that we can build upon. The definition of new fields is to be covered by new drafts.

On your case for a second timestamp: This has been discussed in the past, and so far the consensus was that a timestamp field and a transit-delay field cover things quite flexibly, given that you can derive associated times with simple operations (e.g. if timestamp covers packet-egress time and you also capture transit-delay, you could easily calculate packet-ingress time).

Cheers, Frank

From: [email-masked] <[email-masked]>
Sent: Freitag, 29. Mai 2020 11:00
To: Frank Brockners (fbrockne) <[email-masked]>
Cc: [email-masked]; tpauly=[email-masked]
Subject: Re:[ippm] Second WGLC for draft-ietf-ippm-ioam-data

Hi Frank,

Best Regards,

Xiao Min
原始邮件
发件人：FrankBrockners(fbrockne) <[email-masked]<mailto:[email-masked]>>
收件人：肖敏10093570;[email-masked] <[email-masked]<mailto:[email-masked]>>;tpauly=[email-masked] <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>;
日 期 ：2020年05月29日 16:05
主 题 ：RE: [ippm] Second WGLC for draft-ietf-ippm-ioam-data
Hi Xiao Min,

Cheers, Frank

From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Freitag, 15. Mai 2020 09:51
To: [email-masked]<mailto:[email-masked]>; tpauly=[email-masked]<mailto:tpauly=[email-masked]>
Subject: Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Hi all,

Best Regards,

Xiao Min
原始邮件
日期：2020年05月15日 01:16

Hi IPPM,

This last call will end on Thursday, May 28. Please reply [email-masked]<mailto:[email-masked]> with your reviews and comments.

Thanks,
Tommy & Ian

---

From: <[email-masked]>
Date: Sat, 30 May 2020 15:41:29 +0800 (CST)

Hi Frank,

Please see my inline response with <XM2>.

Best Regards,

Xiao Min

原始邮件

发件人：FrankBrockners(fbrockne) <[email-masked]>
收件人：肖敏10093570;
抄送人：[email-masked] <[email-masked]>;tpauly=[email-masked] <tpauly=[email-masked]>;
日 期 ：2020年05月29日 19:00
主 题 ：RE: Re:[ippm] Second WGLC for draft-ietf-ippm-ioam-data

Hi Xiao Min,

There have been quite a few proposals for additional data fields for IOAM tracing, see e.g.https://github.com/inband-oam/ietf/issues/154

<XM2> I understand. It's reasonable, and by the way, I support its publication.

On your case for a second timestamp: This has been discussed in the past, and so far the consensus was that a timestamp field and a transit-delay field cover things quite flexibly, given that you can derive associated times with simple
 operations (e.g. if timestamp covers packet-egress time and you also capture transit-delay, you could easily calculate packet-ingress time).

<XM2> I understand your argument and it's acceptable to me, nevertheless, the current text in section 4.4.2 doesn't reflect your statement that timestamp can cover packet-egress time.

In section 4.4.2, it says:

 timestamp seconds: 4-octet unsigned integer. Absolute timestamp in
 seconds that specifies the time at which the packet was received
 by the node.

 timestamp subseconds: 4-octet unsigned integer. Absolute timestamp
 in subseconds that specifies the time at which the packet was
 received by the node.
Could you please direct me to the words in section 4.4.2 that say the timestamp can cover packet-egress time? 

Cheers, Frank

 

Hi Frank,

Best Regards,

Xiao Min

原始邮件

收件人：肖敏10093570;[email-masked]
 <[email-masked]>;tpauly=[email-masked] <tpauly=[email-masked]>;

日期：2020年05月29日
 16:05

主题：RE: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Hi Xiao Min,

 

<XM> My suggestion might not be clear enough. Actually I want to have two timestamps carried in the hop-by-hop trace option data, one timestamp for the receiving time and another timestamp for the transmitting time, then after the IOAM
 Data is exported to the collecter, the collecter can use the two timestamps to calculate the transit delay of each IOAM transit node. Do you see it possible to add one more timestamp as IOAM node data field into section 4.4.2?

Cheers, Frank

From: ippm <[email-masked]>On Behalf Of [email-masked]
Sent: Freitag, 15. Mai 2020 09:51
To: [email-masked]; tpauly=[email-masked]
Subject: Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Hi all,

Best Regards,

Xiao Min

原始邮件

日期：2020年05月15日
 01:16

主题：[ippm]
 Second WGLC for draft-ietf-ippm-ioam-data

Hi IPPM,

 

 

 

Thanks,

Tommy & Ian

---

From: Mickey Spiegel <[email-masked]>
Date: Sat, 30 May 2020 15:34:51 -0700

Frank and Xiao Min,

Please see comments inline with [MS].

On Sat, May 30, 2020 at 12:42 AM <[email-masked]> wrote:

> *发件人：*FrankBrockners(fbrockne) <[email-masked]>
> *收件人：*肖敏10093570;
> *抄送人：[email-masked] <[email-masked]>;tpauly=[email-masked]
> <tpauly=[email-masked]>;
> *日 期 ：*2020年05月29日 19:00
> *主 题 ：**RE: Re:[ippm] Second WGLC for draft-ietf-ippm-ioam-data*
>
> Hi Xiao Min,
>
>
>
> There have been quite a few proposals for additional data fields for IOAM
> tracing, see e.g.https://github.com/inband-oam/ietf/issues/154
>
> What we agreed in the past IPPM meetings was that we’d focus on finalizing
> draft-ietf-ippm-ioam-data so that we have a stable foundation that we can
> build upon. The definition of new fields is to be covered by new drafts.
>
> On your case for a second timestamp: This has been discussed in the past,
> and so far the consensus was that a timestamp field and a transit-delay
> field cover things quite flexibly, given that you can derive associated
> times with simple operations (e.g. if timestamp covers packet-egress time
> and you also capture transit-delay, you could easily calculate
> packet-ingress time).
>
> <XM2> I understand your argument and it's acceptable to me, nevertheless,
> the current text in section 4.4.2 doesn't reflect your statement that
> timestamp can cover packet-egress time.
>

[MS] In an earlier message, Frank wrote:

draft-ietf-ippm-ioam-data already includes an option to timestamp packets
> (see e.g. sections 4.4.2 and 4.6 in draft-ietf-ippm-ioam-data-09) which you
> can use exactly the same way as you propose below, i.e. you can use the
> timestamp field for the time, at which the packet was transmitted by the
> node. What draft-ietf-ippm-ioam-data asks you to do is to properly document
> when you timestamp the packet.

[MS] This is not correct. As Xiao Min pointed out, in the IOAM Trace, the
timestamp definition specifies "the time at which the packet was received
by the node".

[MS] In the IOAM Edge-to-Edge option, the timestamp behaves as described in
Frank's comment above, varying in different implementations.

[MS] Even with the timestamp fixed as an ingress timestamp, I agree with
Frank's main point. An egress timestamp can be derived from the ingress
timestamp plus the transit delay.

Mickey

>
>
>
> Cheers, Frank
>
>
>
> *From:* [email-masked] <[email-masked]>
> *Sent:* Freitag, 29. Mai 2020 11:00
> *To:* Frank Brockners (fbrockne) <[email-masked]>
> *Cc:* [email-masked]; tpauly=[email-masked]
> *Subject:* Re:[ippm] Second WGLC for draft-ietf-ippm-ioam-data
>
>
>
> Hi Frank,
>
>
>
> *发件人：*FrankBrockners(fbrockne) <[email-masked]>
>
> *收件人：*肖敏10093570;[email-masked] <[email-masked]>;tpauly=
> [email-masked] <tpauly=[email-masked]>;
>
> *日**期**：*2020年05月29日 16:05
>
> *主**题**：**RE: [ippm] Second WGLC for draft-ietf-ippm-ioam-data*
>
> Hi Xiao Min,
>
>
>
> my understanding is that there are devices which can calculate transit
> delay, which is why the field was introduced quite a while ago.
>
> draft-ietf-ippm-ioam-data already includes an option to timestamp packets
> (see e.g. sections 4.4.2 and 4.6 in draft-ietf-ippm-ioam-data-09) which you
> can use exactly the same way as you propose below, i.e. you can use the
> timestamp field for the time, at which the packet was transmitted by the
> node. What draft-ietf-ippm-ioam-data asks you to do is to properly document
> when you timestamp the packet.
>
> <XM> My suggestion might not be clear enough. Actually I want to have two
> timestamps carried in the hop-by-hop trace option data, one timestamp for
> the receiving time and another timestamp for the transmitting time, then
> after the IOAM Data is exported to the collecter, the collecter can use the
> two timestamps to calculate the transit delay of each IOAM transit node. Do
> you see it possible to add one more timestamp as IOAM node data field into
> section 4.4.2?
>
>
>
> Cheers, Frank
>
>
>
> *From:* ippm <[email-masked]>*On Behalf Of [email-masked]
> *Sent:* Freitag, 15. Mai 2020 09:51
> *To:* [email-masked]; tpauly=[email-masked]
> *Subject:* Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data
>
>
>
> Hi all,
>
>
>
> I was told by the implementers of my company that it's difficult to add
> accurate transit delay into the trace option data. The reason is that in
> order to calculate transit delay, the node firstly needs to obtain the time
> at which the packet is transmitted by the node, which is obtained at PHY
> layer, otherwise, the node can't do any calculation after the time is
> obtained.
>
> If the above issue is common across different implementations, I suggest
> to substitute the "transit delay" with '"timestamp" of the time at which
> the packet is transmitted by the node.
>
>
>
> Best Regards,
>
> Xiao Min
>
> 原始邮件
>
> *发件人：*TommyPauly <tpauly=[email-masked]>
>
> *收件人：*IETF IPPM WG <[email-masked]>;
>
> *日期：*2020年05月15日 01:16
>
> *主**题**：**[ippm] Second WGLC for draft-ietf-ippm-ioam-data*
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 31 May 2020 15:27:40 +0000

Hi Tommy and Draft ioam-data Authors,

After completing one pass through the memo in the role of Doc Shepherd,
I ended-up with a few comments that are more like WGLC comments than
those of the shepherd.  Since we are only a few days over WGLC closure,
I have uploaded the preliminary shepherd write-up and share
the comments for optional action below (I don’t think these comments
should have any special status, IOW).

It is clear that lots of work an negotiation went into the present text.
I appreciate that fact and thank all who participated for preparing
an excellent draft.

The current shepherd’s write-up [0] is available for comment, as well.

Al
(as doc shepherd)

[0] https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/shepherdwriteup/

Doc Shepherd's Comments:

Closed PR https://github.com/inband-oam/ietf/pull/96
Two Comments indicate the value of a Manageability Considerations section while resolving issues in the discussion. However, the -09 version still does not have this section a year later... The important topic discussed was congestion management, but there are no instances of "congest" in the -09 text.  (more, see below)

Section 3, Scope, etc. contains the topic:
Deployment domain (or scope) of in-situ OAM deployment:, in which many operational considerations are detailed that could be part of a Manageability Considerations: section.

4.4 Trace Option types
...
   ...The maximum number of hops and the minimum path MTU of the IOAM domain is assumed
   to be known.

What are the consequences when they are not known?
     Looks like the Flag Bit 0 O-bit handles this case for number of hops.  (Add this here?)

Or, is this knowledge highly likely, and expected to be violated only under the most unexpected conditions (restoration from multiple failures)?
See point below on "minimum path MTU".

4.4.1
RemainingLen:
...
      Given that the sender knows the minimum path MTU, the sender MAY
      set the initial value of RemainingLen according to the number of
      node data bytes allowed before exceeding the MTU.
"minimum path MTU" is the smallest Maximum Transmission Unit for all links in a path, or simply the Path MTU, PMTU, right?
https://en.wikipedia.org/wiki/Path_MTU_Discovery

4.5 Proof of Transit

Is there a Reference for "Shamir's Secret Sharing Schema (SSSS)" ?
Or, is it a secret?

7.  IANA Considerations
(apologies in advance for a long/recent/good experience with IANA, and the many other folks who try to help our friends at IANA)
This section appears to define a set of related registries.
The hierarchy could be named a bit more efficiently than:

7.1 In-Situ OAM Protocol Parameters Registry (IOAM) Protocol Parameters IANA registry

Suggest:
In-Situ OAM (IOAM) Protocol Parameters Group
7.1  IOAM Protocol Parameters Registry
     7.2  IOAM Option-Type Registry
     7.3  IOAM Trace-Type Registry
       ...

From: ippm [mailto:[email-masked]] On Behalf Of Tommy Pauly
Sent: Thursday, May 28, 2020 12:43 PM
To: Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Thanks,
Tommy

On May 14, 2020, at 10:16 AM, Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>> wrote:

Hi IPPM,

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-09<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dioam-2Ddata-2D09&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=YwMkvN3mqHRxnwcgkB4l4psDqQViP1UTeOxJeyv5T7k&s=_Lv2krlY6UiX1GbDsvMqDhkXEWZf66f0UkBcR3O3csg&e=>

Thanks,
Tommy & Ian
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=YwMkvN3mqHRxnwcgkB4l4psDqQViP1UTeOxJeyv5T7k&s=BSOHsMgZ_JR-B6_CAnlIGEEoEv1CXcvWQ-vOS7UsHRg&e=>