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

[[e-mail]]

Hi Frank,






Please see my inline response with <XM2>.







Best Regards,


Xiao Min



原始邮件



发件人：FrankBrockners(fbrockne) <[e-mail]>
收件人：肖敏10093570;
抄送人：[e-mail] <[e-mail]>;tpauly=[e-mail] <tpauly=[e-mail]>;
日 期 ：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.


<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


 




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




 

Hi Frank,

 

Many thanks for your reply to my comment.

Please see my inline response with <XM>.

 

Best Regards,

Xiao Min


原始邮件



发件人：FrankBrockners(fbrockne) <[e-mail]>



收件人：肖敏10093570;[e-mail]
 <[e-mail]>;tpauly=[e-mail] <tpauly=[e-mail]>;



日期：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.


<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


 




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




 

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=[e-mail]>



收件人：IETF IPPM WG <[e-mail]>;



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



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




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

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 [e-mail] with your reviews and comments.



 


Thanks,



Tommy & Ian