Re: [ippm] New Version Notification for draft-ahuang-ippm-dex-timestamp-ext-00.txt

[Haoyu Song <[e-mail]>]

Hi Justin,

You are right. If we allow unknow flags to be set (typically it means a node is not updated to know the flag that has been defined) then we must assume all the option data to have the same size. 

Thanks,
Haoyu

-----Original Message-----
From: Justin Iurman <[e-mail]> 
Sent: Friday, March 10, 2023 10:11 AM
To: Haoyu Song <[e-mail]>; Alex Huang Feng <[e-mail]>
Cc: [e-mail]; Pierre Francois <[e-mail]>
Subject: Re: [ippm] New Version Notification for draft-ahuang-ippm-dex-timestamp-ext-00.txt

Haoyu,

Sorry for being late to the party, but Alex mentioned your reply (below) in another thread and I felt like I needed to answer this.

Actually, I don't think the limitation can be relaxed. The reason is
simple: backward compatibility with existing implementations. Let's say we do as you suggest (i.e., one bit for two 4-byte fields, which means one bit for one 8-byte field). In that case, you would break existing implementations since they do not implement the new flag yet. As per
RFC9326:

"An IOAM node that receives a DEX Option-Type with an unknown flag set to 1 MUST ignore the corresponding optional field."

So, existing implementations would skip 4 bytes for each unimplemented extension-flag to be compliant with the RFC (and to be forward compatible with future extension-flags). Which is definitely not what you want. This is exactly why consistency is required from the start, and it MUST be a 4-byte field (and so for all extension-flags, even new ones).

Thanks,
Justin

On 2/16/23 18:51, Haoyu Song wrote:
> As long as the optional fields are of fixed length (better to be 4 
> octets aligned) there will be no ambiguity. My personal opinion is 
> that the limitation can be relaxed.
> 
> Haoyu
> 
> *From:* Alex Huang Feng <[e-mail]>
> *Sent:* Thursday, February 16, 2023 2:01 AM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* [e-mail]; Pierre Francois <[e-mail]>
> *Subject:* Re: [ippm] New Version Notification for 
> draft-ahuang-ippm-dex-timestamp-ext-00.txt
> 
> Hi Haoyu,
> 
> Thanks for your feedback.
> 
> I actually agree with your statement but the only reason I did it 
> using
> 2 bits is because in IOAM DEX (RFC9326) section 3.2, there is a 
> statement saying each Optional field is 4 octets long:
> 
> *Optional fields:*
> 
> The optional fields, if present, reside after the Reserved field. The 
> order of the optional fields is according to the order of the 
> respective bits, starting from the most significant bit, that are 
> enabled in the Extension-Flags field. Each optional field is 4 octets long.
> 
> There is no MUST in the section, so I did not know how to interpret 
> this. Maybe you have more insights on this.
> 
> Cheers,
> 
> Alex
> 
> 
> 
>     On 15 Feb 2023, at 18:47, Haoyu Song <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>     Hi Alex,
> 
>     This method allows the direct delay measurement in data plane which
>     could be useful for some applications. The extension is also simple
>     and straightforward.
>     I have just one concern: the timestamp seconds and fraction are
>     defined as two optional field and the timestamp seconds could be the
>     only field used. However, I don't think it would be useful for delay
>     measurement if only the seconds appears. So maybe it's more
>     reasonable to consider them both as just one timestamp field and
>     save a flag bit.
> 
>     Thanks,
>     Haoyu
> 
>     -----Original Message-----
>     From: ippm <[e-mail] <mailto:[e-mail]>> On
>     Behalf Of Alex Huang Feng
>     Sent: Wednesday, February 15, 2023 3:30 AM
>     To:[e-mail] <mailto:[e-mail]>
>     Cc: Pierre Francois <[e-mail]
>     <mailto:[e-mail]>>
>     Subject: Re: [ippm] New Version Notification for
>     draft-ahuang-ippm-dex-timestamp-ext-00.txt
> 
>     Dear IPPM WG,
> 
>     I would like to present this draft which addresses a missing
>     timestamp in the IOAM Direct Export (DEX) option header.
> 
>     This timestamp extension allows computing the delay between the
>     encapsulation node and the transit or decapsulation node in IOAM DEX
>     Option.
> 
>     On behalf of the authors, I would like to request your feedback on
>     this draft.
> 
>     Cheers,
>     Alex
> 
> 
> 
>         On 15 Feb 2023, at 12:27, [e-mail]
>         <mailto:[e-mail]> wrote:
> 
> 
>         A new version of I-D, draft-ahuang-ippm-dex-timestamp-ext-00.txt
>         has been successfully submitted by Alex Huang Feng and posted to the
>         IETF repository.
> 
>         Name:draft-ahuang-ippm-dex-timestamp-ext
>         Revision:00
>         Title:Timestamp extension for In Situ Operations,
>         Administration, and Maintenance (IOAM) Direct Export
>         Document date:2023-02-15
>         Group:Individual Submission
>         Pages:6
>         URL:
>         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ahuang-ippm-dex-timestamp-ext-00.txt&data=05%7C01%7Chaoyu.song%40futurewei.com%7C9c5162eed5554b5cd92808db2192dba7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638140686897808671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HJRWRPszwTvx6jkfx4NbIkqFjjttTjlKMzpLVRUyhLI%3D&reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ahuang-ippm-dex-timestamp-ext-00.txt&data=05%7C01%7Chaoyu.song%40futurewei.com%7C9c5162eed5554b5cd92808db2192dba7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638140686897808671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HJRWRPszwTvx6jkfx4NbIkqFjjttTjlKMzpLVRUyhLI%3D&reserved=0>
>         Status:
>         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ahuang-ippm-dex-timestamp-ext%2F&data=05%7C01%7Chaoyu.song%40futurewei.com%7C9c5162eed5554b5cd92808db2192dba7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638140686897808671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d80c2M%2F0j2qLM2i1xvwUkvLxqQxNQmVEQ5yniVNeSoE%3D&reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ahuang-ippm-dex-timestamp-ext%2F&data=05%7C01%7Chaoyu.song%40futurewei.com%7C9c5162eed5554b5cd92808db2192dba7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638140686897808671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d80c2M%2F0j2qLM2i1xvwUkvLxqQxNQmVEQ5yniVNeSoE%3D&reserved=0>
>         Htmlized:
>         
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ahuang-ippm-dex-timestamp-ext&da
> ta=05%7C01%7Chaoyu.song%40futurewei.com%7C9c5162eed5554b5cd92808db2192
> dba7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638140686897808671%7
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lcaBP13Shjgx7SbO9ngu4Pq1p%2B
> dCgTF45RfQqbTRa8k%3D&reserved=0 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> atracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ahuang-ippm-dex-timestamp-ext&d
> ata=05%7C01%7Chaoyu.song%40futurewei.com%7C9c5162eed5554b5cd92808db219
> 2dba7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638140686897808671%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lcaBP13Shjgx7SbO9ngu4Pq1p%2
> BdCgTF45RfQqbTRa8k%3D&reserved=0>
> 
> 
>         Abstract:
>           This document extends the In Situ Operations, Administration, and
>           Maintenance (IOAM) Direct Export option type to support
>         timestamping
>           by adding and defining two optional timestamp fields and
>           corresponding flags.
> 
> 
> 
> 
> 
>         The IETF Secretariat
> 
> 
>     _______________________________________________
>     ippm mailing list
>     [e-mail] <mailto:[e-mail]>
>     
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fippm&data=05%7C01%7Chaoyu.song%40futur
> ewei.com%7C9c5162eed5554b5cd92808db2192dba7%7C0fee8ff2a3b240189c753a1d
> 5591fedc%7C1%7C0%7C638140686897808671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7C&sdata=cqWowp1knmCif8yyMvUoCwnzfWeRIrUeX0%2BvF80rJOY%3D&reserved=0 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fippm&data=05%7C01%7Chaoyu.song%40futu
> rewei.com%7C9c5162eed5554b5cd92808db2192dba7%7C0fee8ff2a3b240189c753a1
> d5591fedc%7C1%7C0%7C638140686897808671%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&sdata=cqWowp1knmCif8yyMvUoCwnzfWeRIrUeX0%2BvF80rJOY%3D&reserved=
> 0>
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fippm&data=05%7C01%7Chaoyu.song%40futur
> ewei.com%7C9c5162eed5554b5cd92808db2192dba7%7C0fee8ff2a3b240189c753a1d
> 5591fedc%7C1%7C0%7C638140686897964889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7C&sdata=PHgmVh81xX3zQUY%2F5XpZFbqQAyYcG0wyh3TbZNyCUGE%3D&reserved=0