Re: [ippm] Review Questions for draft-ietf-ippm-route-04

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Tal,

Thanks for your prompt and accurate reply!
Four years is a long time for such memories
to persist – next time it goes in the Doc
Shepherd’s write-up ☺

Al


From: Tal Mizrahi [mailto:[e-mail]]
Sent: Thursday, October 31, 2019 3:40 AM
To: MORTON, ALFRED C (AL) <[e-mail]>
Cc: Foote, Footer (Nokia - CA) <[e-mail]>; [e-mail]
Subject: Re: Review Questions for draft-ietf-ippm-route-04

Hi Al,


>> 2) Section 4.1 makes reference to the experimental RFC7280 " UDP Checksum
>> Complement in  the One-Way Active Measurement Protocol (OWAMP) and Two-Way
>> Active Measurement Protocol (TWAMP)" is the a common accepted practice for
>> addressing UDP checksum considerations.  I do not know the history why
>> RFC7280 was Categorized as Experimental.
>[acm]
>I don't remember, and I was the document shepherd - nothing in the write-up:
>https://datatracker.ietf.org/doc/draft-ietf-ippm-checksum-trailer/shepherdwriteup/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dchecksum-2Dtrailer_shepherdwriteup_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=GqIqmAuH7z1ZhhJucyGzL9Wee9rtINynmBYZQwhfUkM&s=z7XQBLSWxqJveDQuEj6IWkyqoyQCJ5G_3phk6wuh2k8&e=>
>
>Perhaps Tal can help us, if he remembers.

I found this related message:
https://mailarchive.ietf.org/arch/msg/ippm/rHZSjVgNre5ewJ4PcDWNdLq3e4k<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_ippm_rHZSjVgNre5ewJ4PcDWNdLq3e4k&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=GqIqmAuH7z1ZhhJucyGzL9Wee9rtINynmBYZQwhfUkM&s=OL02DdJ0BlWZvuwG1dhVqX233UI5KI2R5qtMvyyHnX8&e=>

Originally the draft was Informational, but its status was changed to Experimental since it was proposed to align it with the status of the somewhat related RFC 7821. The reason for RFC 7821 being Experimental was due to the fact that it relied on NTP extension fields, which were not commonly used at the time (this is gradually changing, by the way).

Cheers,
Tal.


On Thu, Oct 31, 2019 at 4:45 AM MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Footer,

Finally making a few minutes for your questions,
sorry for the delay, and thanks for your review.

@Tal, a question for you about the Experimental Status
of RFC 7820, at the end.

Please see below,
Al

> -----Original Message-----
> From: ippm [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Foote, Footer
> (Nokia - CA)
> Sent: Wednesday, July 24, 2019 11:06 AM
> To: [e-mail]<mailto:[e-mail]>
> Subject: [ippm] Review Questions for draft-ietf-ippm-route-04
>
> Between meetings, I read the draft draft-ietf-ippm-route-04, re-read the
> draft and read it once more.  I see value in the solidification of
> terminology, previous thread on the mailing list include many comments on
> this.   My initial thoughts on the draft, are interest in the work for
> link awareness for participating nodes, along the path and ability to
> relate metrics for the well identified path and members.  This will help
> correlate measurements to specific paths, at least those which are
> participating.
>
> A couple of quick questions;
>
> 1)  Section 3.6 Reporting Metric " The models need to be expanded to
> include these features, as well as Arrival Interface ID, Departure
> Interface ID, and Arrival Timestamp, when available."
> -   Should this specify some type of identification for how to interpret
> that timestamp format (NTP or PTP) .
[acm]
Since we concluded at IETF-105 to list requirements in this section,
and punt future work to a YANG model, I don't think we'll go into
the detail of formats for any of the new features. Probably avoid
the bitstream formats and go with something human-readable instead,
such as https://tools.ietf.org/html/rfc3339#section-5.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3339-23section-2D5.6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=GqIqmAuH7z1ZhhJucyGzL9Wee9rtINynmBYZQwhfUkM&s=MDLtbp3GAAV51YoGOyg8mIaMHye0MM8yEMwmr4a2Mhk&e=> in the
future YANG model.

>  -  Should departure Timestamp be included as well, would this address the
> concern about the Section 2 scope comment " unknown contribution of
> processing time at the host that generates the ICMP response."
[acm]
I don't think we have the protocol feature to carry the Departure timestamp
in ICMP from the remote host. We are focusing on the one-way aspects of
the route, so it makes sense to include the original sender's timestamp.
I'll add that.

>
>
> 2) Section 4.1 makes reference to the experimental RFC7280 " UDP Checksum
> Complement in  the One-Way Active Measurement Protocol (OWAMP) and Two-Way
> Active Measurement Protocol (TWAMP)" is the a common accepted practice for
> addressing UDP checksum considerations.  I do not know the history why
> RFC7280 was Categorized as Experimental.
[acm]
I don't remember, and I was the document shepherd - nothing in the write-up:
https://datatracker.ietf.org/doc/draft-ietf-ippm-checksum-trailer/shepherdwriteup/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dchecksum-2Dtrailer_shepherdwriteup_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=GqIqmAuH7z1ZhhJucyGzL9Wee9rtINynmBYZQwhfUkM&s=z7XQBLSWxqJveDQuEj6IWkyqoyQCJ5G_3phk6wuh2k8&e=>

Perhaps Tal can help us, if he remembers.

>
> Footer
>
>
>
>
>
>
>
>
>
> _______________________________________________
> ippm mailing list
> [e-mail]<mailto:[e-mail]>
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=_pDZtXzwgV0TTXCvaXCgEofTKu4go
> Qsl2hiHdVOrswQ&s=PA3aPrV94QkwD5QFlXV3B0-CRhn-diGvyrHq6NfEWpI&e=